你不知道的软件测试那些事？
让我们详细地说明
作为开发人员，我们都知道我们应该测试我们的代码。我们应该写单元测试，但这也通常是
我们发现没时间时跳过的第一步。
作为团队的领导者或者管理者我们都知道测试是必要的，但是当截止日期临近的时候，我们
倾向于减少测试，而把更多的重点放到编码上。
这样看测试领域似乎很紧张。我们都知道测试对我们是有利的，但是一旦项目面临压力时我
们就不再测试了。
我们为什么测试?
EdsgerWDijkstra说过:测试可以用来找到显式的缺陷（bug），但是无法显示潜伏的软件
缺陷（bug）。
这意味着测试不能百分百保证你的软件没有缺陷（bug），但是它确实很有帮助。我们也可
以换种说法，如果我们不进行测试我们几乎可以百分百保证我们的软件会有缺陷（bug），
除非我们是在编写像“helloworld！”那样简单的程序。但是即使这么简单的程序你也会测试，
因为一旦你输入完你的代码你就会很好奇它的输出是不是真的是“helloworld！”。
而这就是第一类形式的测试，也是我们一直在做的:手工测试.我们编写程序，然后启动它
去检验运行结果。对于一个简单的“helloworld”这可能是足够的，但是对于复杂度更高的
程序这可能会导致时间的浪费，这是对一个已知的行为结果集的手工重复。这难道不是我们
发明计算机的初衷吗?
对于“helloworld”这不是大问题，但是当你创建一个web应用时，测试场景是在翻页十次，
点击某些按钮，在大量表单中输入（正确的）数据之后再测试某些特定条件，你就看到自动
化会节省大量的时间。大讲台，最实用的IT职业在线学习平台。如果你能通过测试运行器
（testrunner）直接执行你想要测试的函数，而不是必须花费半分钟手工执行到那个函数，
你会节省很多时间！
但这也意味着我们需要多一点点编程，而更多的编程意味着更多的时间和精力。所以它会花
费更多的时间而你的项目可能因此完工的晚些。
也许未必
让我们创建一个控制台应用程序来计算最大公约数(GCD)的两个整数。有很多方法可以解决
这个问题，但为简单起见，我们将
1.输入两个整数
2.不管其算法怎么样，计算一下GCD
3.显示输出
让我们浏览一下正常的开发周期。我们通常写一个main()函数，得到了两个整数，以及调
用一个函数来计算一下GCD，然后显示结果。
测试。在你的控制台中输入2个整数会花一些时间，这将变得相当无聊，如果你需要多次
重复你的代码。这也很容易在控制台应用程序中输入出错，导致程序崩溃。这意味着你必须
重新启动程序，输入两位数，然后再次验证结果。请你要记住，我们讨论的是一个控制台应
用程序，只需要两个输入值，不需要点击(在web应用程序中)，我们已经看到，这将需要
花费一些时间。
然后，我们很可能会想要测试一些更多意味着重启程序的值，进入两位数（正确地），然后
测试。。。所以我们即使看到也不会立即这样做，因为它要花费太多的时间。Edge案例将
会被遗忘，错误只会在生产中被发现！
此外，当我们改变一些我们需要再次运行所有的测试(手动)，使用一个被遗忘的，或者使用
快捷键的高风险的测试。
在那儿，不会有跟踪我们的测试工作。大讲台，最实用的IT职业在线学习平台。不写入日
志文件，在整个测试期间，除非你增加这个你做的事情列表工作(手动)。
消极反馈循环
通常，当项目（因为某种原因）延期了，则容易陷入一种消极反馈循环。有时我们会先决定
跳过编写测试代码，而这则会造成情况如下图所示：
项目延期，造成我们不得不去编写更多的代码。所以与其“浪费时间”去不停地测试代码，不
如不停地去开发项目。而这样做的结果就是代码质量进一步下降，并最终（或早或晚）导致
返工。返工又通常会在最有限的时间里变得十分紧急（有些人叫这种现象为“墨菲是个乐天
派！”）。其实返工什么也改变不了，项目现在只会进一步被延迟。很奇怪吧，我们编写越
多的代码，我们的项目完工越晚。一种常用应对措施是让更多的开发人员被参与到项目的研
发中，然而这样的作用也只是加剧消极反馈循环而已。
若项目缺乏测试，在验收和生产环境时，通常用户则会发现许多bug，这将会快速地降低用
户对项目的信任度，从而产生消极反馈。这种反馈传递给（工作过度的）开发人员，就造成
开发人员“疲劳”现象。后果就是开发人员工作积极性下降，开发人员离职，……，项目又进
一步延迟了。
打破消极循环
我想你已经想到有一个办法可以解决这种现象。让我们来绘制一幅不同的场景：
我们可以从一个理想计划“项目按时完工”开始。我们开发代码，然后立即测试它。测试最好
是自动化（编码实现）的，这样我们可以轻松有效的去执行它们。我们把开发和测试紧密的
结合在一起，每个开发测试循环可以很快速的执行。当一个开发测试循环结束时我们有信心
保证代码质量是很高的，因为它已经通过了测试。而且用户因为发现缺陷（bug）的数目变
少而对我们继续高度信任。即使他们发现了一个缺陷（这依然是有可能的），我们也可以扩
充我们的测试集合，去避免相关缺陷的重现。
如此下去，返工将不再是必须的，项目得有继续。
如果我们的项目已经延期了，就需要我们花些时间来采用这种方法论。对新功能的冻结也许
是必须的。停止开发新的代码，取而代之去为最严重的（恼人的－清晰的－高代价的）缺陷
编写测试。
项目延期的情况下再去为你完整的代码库编写测试是不可行的，只针对其中的一些部分就可
以，不要去浪费你的时间。但是要记住其它部分也还是需要编写测试的。我在这种情况下会
去找出最严重的问题（划分优先级），然后为它们编写测试。之后“快速”修改代码就会变的
更容易，并且可以保证在修改其他部分是它不会出错。自动化测试可以很频繁的执行，从而
降低了缺陷（bug）重现的风险。大讲台，最实用的IT职业在线学习平台。好了，现在可以
开始去有效的强健我们项目了
上面这些通常会要求进行代码重构，从而使它可测试化。我会在另一篇文章里介绍它。
总结
大部分的项目中，会考虑测试和编码之间的平衡。不过我希望大家都能清楚，测试其实是项
目的加速器，而不是在浪费时间。
下一篇文章我将带你进入测试驱动开发的领域，你会发现自己能变得更有效率！
测试愉快！
|
|
