How perfect you want a software to be?

今天看到一个有关测试的故事：

====================================================================================
关于测试的故事
在产品周期中， 有三位测试人员根据要求开始测试软件。
测试员1：
立即开始手动测试，并发现一些细微的错误。开发团队高兴的修复了这些错误， 然后提供一个新的软件版本以供测试。测试的越多，发现的错误越多， 修复的错误也就越多。
测试员1 觉得很有成就感，也就会感到快乐――至少一段时间是这样的。
经过几轮这种发现、修复的循环，他开始由于一遍遍的手动重复运行实质上一样的测试而感到乏味和反应迟钝。当测试员1 最终丧失积极性― ― 同时也就意味着失去耐性― ― 就会宣称软件可以发布了。用户发现它有太多的错误， 于是购买了竞争者的产品。
测试员2：
从手动测试开始，但很快就判定创建自动执行按键的测试脚本更有意义。仔细找出那些会使用到软件有用部分的测试后，测试员2 将操作记录到脚本中。这些脚本很快达到几百个。按下一个按钮后，这些脚本就被激活并按照步骤运行软件。
测试员2 觉得自己很聪明，也就会感到快乐――至少一段时间是这样的。
当软件发生变化时，这些脚本需要大量的维护。他花费数个星期开发人员争论，要求停止修改软件，因为这破坏了自动化测试。最和后， 脚本需要太多的维护以致留下太少的时间来进行测试。
当软件发布后，用户发现太多脚本未覆盖的错误。他们停止购买该产品而决定等待版本2 的发布。
测试员3
不想维护数以百计的自动化测试脚本。他编写了一个测试程序来在应用程序中到处随机点击和按按钮。这种“随机”测试程序不需要一直查看， 且发现了很多致命的错误。
测试员3 很享受发现这些引人注目的缺陷，也就会感到快乐－－至少一段时间是这样。
由于随机测试程序只能发现那些毁坏应用程序的错误，因此测试员3 仍然不得不做大量手动测试，并很快在这个过程中感到乏味和反应迟钝。当软件发布后用户在软件中发现如此多的功能性错误而对公司丧失信任， 于是停止购买这种软件。

评注：
测试员1 是一个典型的手动测试者， 从键盘手动运行所有的测试。手动测试在当前的工业界很普遍――它能提供直接的好处，但长时间的运行会让测试人员感到单调乏味， 对公司来讲成本高。
“我看到的最悲哀的景象之一就是一个人在键盘上手动操作一些可以自动运行的东西。这是悲哀的但也是有趣的。”
黑盒测试： 软件和系统功能测试技术

测试员2 实践的是我称为静态测试自动化的测试。静态自动化脚本每次根据同样的次序执行同样的命令序列。当应用程序发生变化时这些脚本的维护成本很高。测试是不断重复的；但由于它们总是执行相同的命令， 因此它们很难发现新的错误。
“高度重复的测试实际上将发现所有重要问题的几率最小化了，这和沿着别人的足迹前行将发现自己的天地的几率最小化的原因是一样的” “骗人的测试自动化”

测试员3 的操作接近于自动化测试的边缘。这些类型的随机测试程序被称为蠢猴因为它们就是毫无目的的敲打键盘。它们生成非常规的测试执行序列并发现很多致命的错误，但是想控制它们到应用程序中你想测试的部分却是很困难的。因为它们不知道自己在做什么，所以它们会漏过应用程序中很多明显的错误。
“猴子式的测试不能是你测试的全部。猴子不明白你的应用程序，由于它们的无知它们漏掉了很多错误。”
“使用猴子式的测试工具,”
小结：
测试员1 的方法需要他的手不停的在键盘上工作。最后测试员1精疲力竭。
测试员2 的静态脚本重复他的手已经执行过的那些键盘操作。
测试员3 的猴子式测试本质上是无目的的在键盘上乱敲。
Now ：what we should do to test more science and more effective ？
;)
====================================================================================

最后，作者问了一个问题。What we should do to test more science and more effective?

我想先问一个问题：How perfect you want a software to be?

作为一个测试人员，首先需要意识到一点，你测试的软件不是完美的，而且，也不可能通过你的测试使它变得完美。假设你找到了90%以上的bug，为了准时release，可能有一些bug还是会决定不被fix。在这种情况下，找到所有的bug的意义何在？

作为一个软件，在大部分情况下，这个软件的功能不是100%被用户用到。有些功能可能永远都不会被用到。这同样适合于硬件。假设你有一个手机，你是否用到了手机的所有功能？我想大部分用户给我的答案都是no。
所以，我们不妨有一个假设，软件也好，硬件也好，常用功能和不常用功能符合28原则的比例。那测试人员的value就在于，如何保证那最常用的20%的功能的最稳定的被使用。

我们可能按照priority和serverity把bug分成p1,p2,p3...和SA,SB,SC...，同样，我们假设品p1/p2/sa/sb的bug占有总bug的20%，那么测试人员的目标就是，如何找到这些20%的bug并让它们被开发人员fix掉。

测试包含很多种，在前期介入时和开发一起做的design review甚至code review， 这些称为Early Defect Finding。前期的介入虽然没有bug可以体现，但是同样是测试人员表现其价值的地方。聪明的项目经理可以意识到这一点，同样，mature的测试经理或lead会主动要求参加这样的活动。

当产品design完成，测试人员开始准备测试用例。这个时候，需要做好测试用例的review。有经验的测试经理会邀请开发人员共同做测试用例的review。

当第一个正式的build出来以后，测试人员才正式开始测试。在前期，主要是保证主要的feature能够工作正常。这个期间手动测试是最多的。可以发现的P1/P2/Sa/Sb的bug也最多。

然后，在daily build正常运转后，测试人员开始做一些简单的automation工作，保证daily build的有效性。同时，有一下explore测试和系统测试开始involve进来。

如果这个项目有L10n需求，那么开发人员需要做各个语言版本的build，测试人员开始做针对各个语言版本的测试。

一般来讲，high volume测试都是需要保证的，考虑到如果软件需要成天的被run而不能crash。

对于coverage测试，个人觉得需要每个测试成员来保证，他自己的test case能够cover到所有的fuction。这个回在后面的日志进行讨论。

Resource leak和Stress状态下的测试也是需要做的。

扯远了， 但是如果有这么多的activity需要做，身为一个测试人员，大概不会为每天的regression test而感觉到boring。

回来，作为测试人员，重要的一点是，"Do what user may do during your test"， 这样才做到了一个测试人员的最本分。至于如何做的更好，那需要：

• 学而时习之
  
• 举一反三

Anyway, Go ahead, it is interesting to be a tester.