找BUG是软件测试工程师的天职

前一讲提过，每个人对同一件事或同一个事物的理解能力是不一样的。说到软件测试，那么同一个需求，客户、产品经理、开发人员和测试人员四个角色对它的理解很多时候也是不一样的。特别是开发人员与测试人员理解更有可能千差万别。但是，在很多公司，尤其是小软件公司，就没有专门的软件测试人员。开发出来的软件，开发人员自测一下，就发布了。发布之后，客户用的有问题，就马上修改，修改完了再发布。对于小软件公司，没有测试人员无可厚非，但是掌握一点软件测试理念也许会提升你的软件开发质量。

软件测试工程师的主要职责就是找出软件的BUG，要用放大镜那样去找。因为在软件发布前找出的BUG远比软件发布后再发现BUG，成本低得多的多。

我刚开始参加工作的时候，当时我还是一名开发新人。当时参与的项目非常紧张。代码都是在客户现场编写，一个屋子里，塞满了产品经理、开发人员、测试人员、实施人员、集成人员等等。当时的那位软件测试经理对他的测试人员说：我们的目标就是使劲的找BUG，每人每个需求起码给我找出XX个BUG。于是测试人员提的BUG单就像潮水一样涌来。项目组规定，当日X点提的BUG单，必须当日解决。结果就是开发人员拼命改BUG，改完第二天发现又有一堆BUG等着他改。就这样经过大约一个月，BUG终于收敛了。当然项目也成功商用了。

那么，如何才能找到又多又有效的BUG呢？

有时候需求发布商用后，客户试用时经常会发现，正常情况下使用软件一点问题都没有。但是稍有一点变化，就开始各种报错。客户就抱怨软件不好用。老板得到客户反馈，第一想到的就是：这个BUG你们测试部门怎么没有测试出来？此时，你作为测试部门老大，你就会找各种理由了。找的最多的理由就是测试环境与真实环境的差异。比如：测试环境不具备这种场景；测试环境没有这种测试数据；测试环境与互联网不通......可这个时候老板会听你这些解释吗？这些测试环境不具备，提前为什么不说？还是测试人员根本就没有测试异常场景？

正常来说，拿到一个需求，需要先编写测试用例。那么测试用例的编写是考验测试人员能力的时候了。正常流程的测试用例大家都会写，也都能写得出来。可是，有些测试人员写完正常的测试用例(或者称之为：正向用例)，就不会去想异常情况(或者称之为：反向用例)。举个例子：某系统有缴费功能，需要手工输入缴费金额，正常的测试用例缴费金额是正数。这个用例大家都写得出来，可是就有很多软件测试工程师不会去想是不是可以输入负数或者零。这就是缺乏逆向思考的能力。

除了异常的测试用例需要设计，还需要设计相关联的用例。我们还是拿上面这个缴费的功能来说。正向与反向的测试用例都写了，也都测试了。一般的测试人员觉得就可以算测试通过了。可是有经验的测试人员还会设计相关联的测试用例。比如：缴费后，客户账户上的余额是否增加了？增加的金额是否就是缴费的金额？缴费成功后，能否查询到缴费记录？如果客户账户本身就有欠费(一般字体用红色标注)，缴费成功后，客户账户还显示欠费吗？如果在系统中有多处可以显示余额的地方，数据是否都同步了？......这些都属于相关联的测试用例。

还有一种情况也是会遇到的，也是测试人员很容易忘记测试。在一些大型的复杂的软件系统中，某个功能，它具有开关。一般是有后台代码0和1控制。一般0代表开关关闭，即功能不开启；1代表开关开启，即功能开启。很多测试人员往往只测试开关开启的功能，没有测试开关关闭的功能(开关关闭的功能一般就是保持原来的逻辑不变)。结果一发布到生产环境，发现开关根本就不起作用，像个摆设。

以上种种情况，要是没有一个测试报告模板来提醒测试人员测试用例是否齐全，就会把很多BUG带入生产系统，会给客户带来较差的体验，最终会返工，会给公司增加成本。

那么，现在我就来提供一个通用的软件测试报告模板。

一个通用的软件测试报告模板

标题：XXXX需求测试报告

一、需求是否有开关？

1、有开关，开关：XXXX，开关打开，测试步骤如下：

(这里就是测试人员的测试过程，要有图有数据)

测试结果：通过/不通过。

2、没有开关，忽略。

二、正向测试用例

测试用例1：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

测试用例2：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

...

测试用例N：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

三、反向测试用例

测试用例1：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

测试用例2：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

...

测试用例N：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

四、相关测试用例

测试用例1：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

测试用例2：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

...

测试用例N：

测试用例：XXXXXX

测试过程：这里就是测试人员的测试过程，要有图有数据

测试结果：通过/不通过。

五、测试结论：通过/不通过。

一般正向、反向、相关测试用例都有的话，基本上一个需求就能覆盖完整了。当然如果某些软件有特殊情况，也可以酌情增加。

这一讲的重点就是提醒软件测试管理者和软件测试人员，不要仅仅只关注正常的(正向的)测试用例，反向和相关的测试用例同样重要，同样需求测试。

牢记一句话：没有经过测试的功能，即使再简单，也会有BUG。