对于一台榨汁机的需求阶段，需求还没有整理出来，测试人员先行介入，测试人员应该从哪些方面考虑测试用例？

我不知道是哪位仁兄出的这道题目，也不知道这位仁兄的原意如何。但是如果要我来回答，那我的答案是：“无可奉告”。

我们先来回顾一下软件测试的定义。现在一般分为两派，一派认为软件测试是为了证明软件“可以工作”，另外一派认为软件测试是为了证明软件“不能工作”。好，不管是那派，他们都需要有一个可以测试的东西作为基础，才能开始下面的证明工作。出题目的仁兄告诉我们，“需求还没整理出来”，测试人员就“先行介入”了。如果不是题目的陷阱，那只能认为这个项目的团队“有问题”。在需求还不明确的前提下，测试人员可以做的事情有两个：一是学习和项目有关的基础知识，剩下的就是等待。（需要指出的是，在需求不明确的前提下，开发人员是无法开始做high level design的，更加谈不上让测试人员参与design的讨论）

回到题目上来，我们假设题目有所改变，该榨汁机是一台普通的榨汁机，插电后放入水果或者蔬菜，按动开关，就可以榨汁。（和市面上能买到的差不多）那么需要如何考虑测试用例？虽然没实际用过榨汁机，但是靠想象应该也差不多。

1. 考虑90%以上用户的使用习惯，确保最基本的功能-榨汁能够正常运作。

• 通常的水果：西瓜、番茄、黄瓜、苹果、草莓、香蕉、李子、甘蔗等单独作为输入。
• 非常见：玉米
• 水果的混编作为输入。
• 在输入容器所能容纳的情况下，输出的量杯是否足够大能容纳榨出的液体。
• 在水果较硬的情况下，是否能正常工作。
• 水果较软的情况下，是否能正常工作。
• 如果有按钮或开关调节，测试按钮或开关的可用性和有效性。

2. 易用性测试

• 榨汁机的外观是否美观。这是用户选择的关键。
• 榨汁机的电源线长度是否足够。
• 量杯大小测试

3. Force Error测试

• 在空转情况（无输入）下做榨汁
• 在有异物（如蔬果的枝叶）的情况下做榨汁
• 在榨汁过程中停电，看是否能恢复
• 110v电源输入测试
• 在高温的情况是否能正常工作（40度以上）
• 在周围有磁场的情况下是否能正常工作
• 掉落测试

4. Security 测试

• 是否有儿童手指保护措施？
• 在榨汁有漏出的情况下，是否会有漏电？

5. 耐用性测试

• 刀片耐用度测试
• 平均无故障时间统计
• 按钮或开关耐用度测试
• 榨汁机使用寿命测试
• 榨汁机本体容器压强测试

基本上来讲，就是这些，对于一个只在电视上看过，从来没用过的人已经是一件不容易的事情了。

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

====================================================================================
关于测试的故事
在产品周期中， 有三位测试人员根据要求开始测试软件。
测试员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.