我的软件测试观

编程小猪猪

已于 2022-08-04 15:00:13 修改

阅读量169

点赞数 1

分类专栏：软件测试文章标签：测试用例

于 2022-08-04 14:58:44 首次发布

本文链接：https://blog.csdn.net/I_am_testing/article/details/126159060

版权

软件测试专栏收录该内容

10 篇文章 1 订阅

订阅专栏

软件测试的定义

软件测试顾名思义就是对软件进行测试，就好像只要确定软件能运行就行了，其实这样的说法并不是很准确，因为，我们想要的不仅仅是软件能够正常运行出这个结果，还要它在从无到有的整个过程都符合需求，就好像培养一个孩子，发现成长过程中的各种问题，共同解决，茁壮成长。

确认

在软件测试过程中，我们不能盲目的去测，软件的功能那么多，一头扎进去反而容易迷失，在软件测试过程中有一个重要的原则就是不要过早的深入细节，要有一个整体的概括，因此我们需要将测试这个过程分解一下，首先第一步，我们要先确定要测的功能是否存在。

如果连功能都没有又何谈测试呢。比如，我们要测软件的登录功能，我们第一步要做的就是打开软件看一看有没有这个登录功能。这就是确认的过程。

验证

仅仅确认了软件的功能还是不够的，还有走第二步，那就是试一试这个功能能不能用，所谓的能用，并不是在软件写好的那一刻才确定的，能用是在软件编写之前就已经规定好的，在软件编写之前的规定就是我们所说的需求，满足需求就是能用，毕竟软件是照着需求写的，我们照着需求测就行了。比如，软件的登录功能，需求中规定，登录名不能为空，我们就可以使用一个不为空的用户名测试以下能否满足需求，这个过程就是验证。

软件测试的目的

我们已经知道了软件测试分两步走，第一步确认功能，第二步验证需求。可是我们为什么要做这些事呢，这大热天的，吹吹空调不香吗？针对这种丧(gan)心(de)病(piao)狂(liang)的摸鱼行为，领导就有话说了，软件测试的目的就是为了省钱。

你想想啊，一个软件费尽心力的写出来就交给客户了，正当我们要举杯欢庆的时候，客户的催命连环call就打来了，有bug，要扣钱，真的是笑着笑着就哭了。这时候，测试来了，软件太平了，测试来了，马内就有啦！测试在软件交给用户之前，就找出了软件里的bug，确保bug得以修复，领导、客户、程序员各个方面美滋滋。

在计算机中，面对复杂的问题，最有效的解决方法就是加一层，这一层隔绝了下层的复杂，同时又给上层提供适宜的使用体验，软件测试就是用户和程序员之间的这一层，可口的三明治谁人不爱呢！

领导意犹未尽，提到省钱，仿佛打开了话匣子。他说，每一个成功都是用钱堆出来的，并不是说花钱就能买来成功，只能是花钱买教训，甚至同样的教训还要重复买几次，这真是极大的浪费，但是软件测试就不同了，每发现一个bug就积累了解决这个bug的经验，后面的软件遇到同样的bug，拿来就用就行了。当然了，也不能为了省钱就失去了面对新bug的勇气，公司鼓励勇敢探索，但是不鼓励重蹈覆辙。

调试

程序员看到软件测试员被领导这么一顿猛夸，心里犯起了嘀咕，软件测试我也能做。领导果然是领导，读心技能准的吓人，转过头对程序员说，我明白你可能心有不服，你们只是分工不同，软件测试员更多是“谋定而后动，知止而有得”，他们在开始测试之前已经把条件过程和结果都确定了下来，测试的内容很明确，有就有，没有就没有，反正就那些活，做完就完事。

程序员就不同了，他们在编码的过程中也会测试代码，他们的测试不同于软件测试人员的测试，甚至说测试都不太准确，因为代码能不能运行出结果，大多数是无法预料，比如程序里不小心写了死循环，cpu都跑冒烟了，就是出不来结果，只能对着代码一遍遍的调，一遍遍的试，找到问题所在，才能跑通，因此这个过程可以亲切的叫调试。调试的尽头是正确的输出，没有正确输出前，漫漫调试路，血战到天明。他们从未知的bug而来，又走向未知的加班，属实辛苦。

软件危机

在计算机刚开始使用的时候，初代程序员就开始在计算机上编写程序，能写个九九乘法表就喜滋滋了，这时候的软件仅仅是程序员的个人作品。他们开发的软件更多的是满足个人定制化的需求，最少也就几百行代码，哪一行代码出现了问题，闭着眼睛也知道该怎么改。
后来，编写程序的计算机发生了变化，单车变摩托了，容量和计算速度拔高了几个量级，在这么高性能的计算机上写九九乘法表，就说不过去了。以糙快猛的开发方式产生了大量的复杂的应用软件，一款软件的功能不再单一，少则几十多则上百个功能集中到一起，相互协作。

这软件背后的代码也突破了百万行，就是看个百万字的小说也要花上个几个星期的时间，更别提这百万行代码的任务量了。关键是代码与代码之间相互调用，在组织不良好的情况下，乱拉电话线的情况比比皆是，在这密密麻麻一团乱麻中，针都插不进去，更别提再扯一条线出来加上新的功能，这时候，日均万行代码的程序员，一行代码也写不出了，无人可问，无本可查，进度一拖再拖，成本一涨再涨，各方面矛盾加剧，危机爆发。这就是软件危机。

软件工程

如果说软件危机的原因是因为代码量过大导致的，其实并不准确，更多的是旧的生产方式已经满足不了新的需求，比如在旧的生产方式中，软件没有对应的开发文档可参考，啥都在程序员的脑子里，程序员成了土皇帝，啥都是自己说了算。

在这种救世主情节的影响下，用户与程序员矛盾重重，用户认为就加个很简单的功能，程序员看了一眼几百MB的代码文件说办不到。或者功能虽加上了，用户却说不是他想要的，这时候，委屈，不理解，相互怀疑的情绪蔓延。

作坊式的软件开发方式落后于时代了，面对复杂的问题，工程化的思想应运而生，所谓的工程化就是技术和管理的结合，管理通过软件质量介入到技术上，软件编程不再是个人的英雄行为，团队开发成为主流，为了提升团队的效率，引入了软件开发的方法学，软件开发不再高深，封装了复杂的底层实现，对外提供简单的API接口，程序员的工作内容成了API的调用者，可供个人发挥的空间少了，话语权少了，扯皮的事情也就少了。

在此基础上，进一步引入了工业化的分工，分工即效率，专业的人做专业的事，有的人做前端，有的人做后端，有的人做测试，即保证了开发进度，又能控制住软件质量。其实软件测试是软件工程的最小实现，测前编好测试用例，测中验证用例，测后提交结果，整个过程有理有据，界限分明，进度可控。

软件质量

在测试的过程中，我们对代码测试的依据就是软件需求，符合需求的软件就是好的软件，但是程序员又比较较真，一句好的软件并不能让人信服，这太模棱两可了，好到底好在哪里？好到什么程度？好的标准是什么？为此我们需要对这个“好的软件”进行重新定义叫“软件质量”。一个软件的软件质量怎么样可以从以下6个特性进行衡量：功能性，可靠性，易用性，效率，维护性与可移植性。