大话人生

7.1.1 从测试设计的方法分类

测试设计有两类方法：Black box（黑箱）、White box（白箱）。

这是每个接触过软件测试的人都会给出的答案。但这只是整个软件测试的入门知识。可以跳过去，直接讨论下面的内容。

问：我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础，还有哪一个更难，哪一个更有前途，等等。据说河曲数码在搞“灰箱测试”，是不是更高级？能不能简单讲一讲？

阿超：大家都有这些问题么？

杂曰：[略去对此问题热烈的争论500字]

阿超：听了大家的争论，看来我们的确得花不少时间统一认识。 所谓黑箱/白箱，是指软件测试设计的方法，不是软件测试的方法！注意“设计”二字。

黑箱：在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral  Test Design”，从软件的行为，而不是内部结构出发来设计测试。

白箱：在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。

在实际工作中，我们不应画地为牢，严格只用某一种方法来设计测试方法。在实际的测试中，当然是对系统了解得越多越好。所谓“灰箱”的提法，正是这一反映。有些测试专家甚至希望我们忘记全部的“箱子”和它们的颜色。

问：如果我是一个开发者，我能做“黑箱”么？

答：并不是要禁止懂得程序内部结构的人员来进行黑箱测试设计，只不过是在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），通常要求由对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基 本模块的“行为”通常没有明确的定义。另一个例子是“易用性测试”，在设计此类测试的时候，没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件易用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和“白箱”没有简单的高低之分。

一旦测试用例写出来之后，大可以忘了它们是从哪种颜色的箱子里出来的，用它就可以了。

问：有人说“黑箱”，有人说“黑盒”，到底是“箱子”还是“盒子”？

答：在网上搜索了一下，“黑箱测试”有超过 100 万个记录，“黑盒测试”只有70多万。所以“箱子”赢了。 问：但是我听九条说他刚进公司实习的时候只能做“黑箱测试”，这是什么意思？

九条：我刚到公司实习的时候，两眼一摸黑，看到啥都是“黑箱”，即使测试用例是由懂得程序结构的开发人员写出来的，我还是只会机械地运行。我是知其然，不知其所以然，箱子当然是黑的。后来看得多了，学了一些东西，能够了解程序的结构和算法，箱子的颜色就变浅了，好像能看到箱子里的东西一样。

7.1.2 从测试的目的分类

1．功能测试

以下的测试术语主要是测试软件的功能。在表7-1所列的测试中，测试的范围由小到大，测试者也由内到外——从程序开发人员（单元测试）到测试人员，到一般用户（Alpha/Beta测试）。

表7-1  功能测试分类 

续表

2．非功能测试

一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“non-functional requirement”，或者“quality of service requirement”——服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段——基本功能完成后做这些测试。

如表7-2所示：

表7-2  非功能测试

7.1.3 按测试的时机和作用分类

在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否顺畅，这些测试如表7-3所示：

表7-3  烽火台

另一些测试名称，则是说明不同的测试方法，如表7-4所示：

表7-4  不同测试方法

7.2  单元测试（Unit Test）

二柱：我们也试过用单元测试来保证质量，要求每人都要写，在签入代码前必须通过单元测试。但是搞了几个星期就不了了之。

大家七嘴八舌地列举了单元测试的问题：

◆ 有时单元测试报了错，再运行一次就好了，后来大家就不想花时间改错，多运行几次，有一次通过就行了；

◆ 单元测试中好多错都和环境有关，在别人的机器都运行不成功；

◆ 花在单元测试上的时间要比写代码的时间还多，提高代码覆盖率到90%以上太难了；

◆ 单元测试中我们还要测试效能和压力，花了很多时间；

◆ 我们都这么费劲地测了，那还要测试人员干什么？

阿超：看来问题还不少，我们留到后面再谈（见后面“单元测试”的具体描述）。

7.3  代码覆盖率测试（Code Coverage Analysis）

前面单元测试中提到代码覆盖率，简单来说代码被执行过，就是“覆盖过”，如果一段程序运行了一组测试用例之后，100%的代码被执行了，那么是否就说明再也不用写新的测试用例了呢？

答案是否定的。

（1）不同代码是否执行，有很多组合，一行代码被执行过，没有问题，并不表明这一行程序在所有可能条件的组合下都能正确无误地运行。

（2）代码覆盖不能测出还没有写的代码（缺少的逻辑）导致的错误。

比如：

a. 没有检查过程调用的返回值；

b. 没有释放资源。

（3）代码覆盖不能测出效能问题。

（4）代码覆盖不能测出时序问题，由时序导致的程序错误（例如：线程之间的同步）。

（5）代码中和用户界面相关的功能不能简单地以代码覆盖率来衡量优劣。

7.5  验收测试（Acceptance Test）

测试团队拿到一个“可测”等级的构建，他们就会按照测试计划，测试各自负责的模块和功能，这个过程可能会产生总共 10 来个 Bug，也可能产生100个以上的Bug，那么如何保证我们有效地测试软件，同时我们在这一步怎样衡量构建的质量？

在MSF敏捷模式中，我们建议还是采用场景来规划测试工作。

在“基本场景”的基础上，把所有系统理论上目前支持的场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明“成功”，否则，就标明“失败”，并且把失败的情况用一个（或几个）“小强”/Bug来表示。当所有的测试人员完成对场景的测试，我们自然地就得出了表7-5。

表7-5  场景测试报告

这样就能很快地报告“功能测试56%通过”等。如果所有场景都能通过，（有些情况下可以把此标准从 100%降低到 90%左右）则这个构建的质量是“可用”，意味着这一个版本可以给用户使用。在这种情况下，客户、合作伙伴可以得到这样的版本，这也是所谓“技术预览版”或“社区预览版”的由来。

但是，有一个重要的问题要大家注意：“可用”，并不是指软件的所有功能都没有问题，而是指在目前的用户场景中，按照场景的要求进行操作，都能得到预期的效果，注意以下两种情况：

（1）在目前还没有定义的用户场景中，程序质量如何，还未得而知。例如：场景中没有考虑到多种语言设置。

（2）不按照场景的要求进行的操作，结果如何，还未得而知。如：在某一场景中，场景规定用户可以在最后付款前取消操作，回到上一步，如果一个测试人员发现在反复提交/取消同一访问多次后，网页出现问题，这并不能说明用户场景失败，当然对于这个极端的Bug，也必须找出原因并在适当的时间改正。

这种测试有时也被称为验收测试“Acceptance Test”，因为如果构建通过了这样的测试，这一个构建就被测试团队“接受了”。同时，还有对系统各个方面进行的“验收”测试，如系统的全球化验收测试，或者针对某一语言环境、某一个平台做的测试。

7.6  "探索式"的测试（Ad hoc Test）

“Ad hoc”原意是指“特定的，一次性的”。这样的测试也可以叫Exploratory Test。

什么叫“特定”测试？或者“探索式”的测试？

就是为了某一个特定目的进行的测试，就这一次，以后一般也不会重复测试。在软件工程的实践中，“Ad hoc”大部分是指随机进行的、探索性的测试。

比如：测试人员阿毛拿到了一个新的构建，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题，于是他就“Ad hoc”一把，居然在这一功能模块中发现了不少小强。

“Ad hoc”也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题……”，如果没问题，那么以后也不会再这么做了。

一般情况下，测试人员不会花很多时间进行特定测试，但是在一些缺乏管理的团队中，很多时候测试人员不知道自己此时应该做什么，只好做一些看似“Ad hoc”的测试，比如随机测试各个功能的各个方面。这些测试理论上都应该由测试管理人员规划好属于各个功能模块的测试用例。

在一个团队中，“Ad hoc”太多是一个管理不好的标志，因为“Ad hoc”是指那些一时想到要做，但是以后也没有计划经常重复的测试计划。

问：我听说有人是“Ad hoc”测试的高手，这是什么意思？

答：有很多测试人员会按部就班地进行测试，但是还有一些人头脑比较灵活，喜欢另辟蹊径，测试一些一般人不会想到的场景，这些人往往会发现更多的小强。开发人员对这样的“Ad hoc”高手是又爱又恨。

问：看问题要分两方面，有些“Ad hoc”发现的小强在正常使用软件中几乎不会出现，我们要不要花时间“Adhoc”？

答：现在一些成功的通用软件的用户以百万计，按部就班的测试计划很难包括很多实际的场景，这时，“Ad hoc”测试能够发现重要的问题；另外一些风险很大的领域，例如安全性，一旦出了问题，威胁就会相当大，这时要多鼓励一些“Ad hoc”测试，以弥补普通测试的不足。从这个意义上说，“Ad hoc”测试可以用来衡量当前测试用例的完备性，如果你探索了半天，都没有发现什么在现有测试用例之外的问题，那就说明现有的测试用例是比较完备的。

“Ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“Ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级——可重复级。

作为管理人员来说，如果太多的小强是在“Ad hoc”出来的，那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善，等等。同时，要善于把看似“Ad hoc”的测试用例抽象出来，囊括到以后的测试计划中。

7.7  回归测试（Regression Test）

问：我听说不少关于Regression Test的介绍，但是它到底是怎么“回归”法？回归到哪里去？我还是没搞懂。

答：Regress 的英语定义是：  return  to  a  worse  or  lessdeveloped state。是倒退、退化、退步的意思。

在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。

在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准（Baseline）。

假如，在3.1.5版本，模块A的测试用例125是通过的，但是测试人员发现在新的版本3.1.6，这个测试用例却失败了，这就是一个“倒退”。在新版本上运行所有已通过的测试用例以验证有没有“退化”情况发生，这个过程就是一个“Regression Test”。如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因）引起的，那么测试用例的基准就要修改，以便和新的功能保持一致。

针对一个Bug Fix（拖鞋），我们也要作Regression Test。

（1）验证新的代码的确把缺陷改正了。

（2）同时要验证新的代码没有把模块的现有功能破坏，没有Regression。

所以对于“回归测试”中的“回归”，我们可以理解为“回归到以前不正常的状态”。

回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。在微软的实践中，在一个项目的最后稳定阶段，所有人都要参加测试，以验证所有已经修复过的 Bug 的确得到了修复，并且没有在最后一个版本中“复发”，这是一个大规模的、全面的“回归测试”。

7.8  场景/集成/系统测试（Scenario/ Integration / System Test）

在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，在各方面都能满足用户的要求。这时的测试叫系统/集成测试。

问：有一种测试叫Scenario Test，是什么意思？

答：就是以场景为驱动的集成测试，关于“场景”，大家可以看专门的介绍。这一方法的核心思想是：当用户使用一个软件的时候，他/她并不会独立使用各个模块，而是把软件作为一个整体来使用的。我们在做场景测试的时候，就需要考虑在现实环境中用户使用软件的流程是怎样的，然后模拟这个流程，看看软件能不能达到用户的需求。这样，能使软件符合用户使用的实际需求。

以一个数字照片编辑软件为例，这个软件的各个模块都是独立开发的，可是用户有一定的典型流程，如果这个流程走得不好，哪怕某个模块的质量再高，用户也不会满意。用户的典型流程是：

（1）把照相机的储存卡插入电脑。

（2）程序会弹出窗口提示用户导入照片。

（3）用户根据提示导入照片。

（4）对照片进行快速编辑。

a. 调整颜色；

b. 调整亮度，对比度；

c. 修改红眼。

（5）选择其中几幅照片，用E-mail发送。

这里面哪一步出了问题，都会影响用户对这一产品的使用。如果这里面各个模块的用户界面不一致（即使是“确认” 和 “取消” 按钮的次序不同），用户使用起来也会很不方便。这些问题都是在单独模块的测试中不容易发现的。

问：什么时候做集成测试？是不是越快越好？

答：原则上是当一个模块稳定的时候，就可以把它集成到系统中，和整个系统一起进行测试。在模块本身稳定之前就提早做集成测试，可能会报告出很多 Bug，但是这些由于提早测试而发现的 Bug 有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭——有点像噪音。我们还是要等到适当的时机再开始集成测试。

问：但是开发人员也想早日发现并修复所有的 Bug，软件工程的目标不就是要早发现并修正问题么？总是要等待，听起来好像没有多少效率。

答：对，这就要提到在微软内部流行的另一种测试——Buddy Test伙伴测试。

7.9  伙伴测试（Buddy Test）

如上所述，在开发一个复杂系统的过程中，当一个新的模块（或者旧模块的新版本）加入系统中时，往往会出现下列情况。

（1）导致整个系统稳定性下降。不光影响自己的模块，更麻烦的是阻碍团队其他人员的工作。

（2）产生很多 Bug。这些 Bug都要被输入到数据库中，经过层层会诊（Triage），然后交给开发人员，然后再经历一系列Bug的旅行，才能最后修复，这样成本变得很高。

如何改进？一个方法当然是写好单元测试，或者运用重构技术以保证稳定性等，我们要讲的伙伴测试是指开发人员可以找一个测试人员作为伙伴（Buddy），在新代码签入之前，开发人员做一个私人构建（Private Build），其中包括了新的模块，测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接和开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。

在项目的后期，签入代码的门槛变得越来越高，大部分团队都要求Bugfix必须得到了伙伴测试的验证后才能签入到代码库中。

7.10  效能测试（Performance Test）

用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平，软件的效能是这些“非功能需求”，或者说“服务质量需求”的一部分。

效能测试要验证的问题是：软件在设计负载内能否提供令用户满意的服务质量。这里涉及如下两个概念。

1．设计负载

首先要定义什么是正常的设计负载。

从需求说明出发，可得出系统的正常负载。例如，一个购物网站，客户认为正常负载是每分钟承受20次客户请求。

2．令用户满意的服务质量

要定义什么样的质量是令用户满意的。

比如，同一个购物网站，用户满意的服务质量可以定义为：每个用户的请求都能在2秒钟内返回结果。

对以上两点还可以逐步细化。

1．设计负载的细化

上面我们只提到“承受 20 次客户请求”，那么这些客户的请求到底是什么，可以按请求发生的频率来分类：

（1）用户登录（10%）。

（2）用户查看某商品详情（50%）。

（3）用户比较两种商品（10%）。

（4）用户查看关于商品的反馈（20%）。

（5）用户购买商品，订单操作（5%）。

（6）所有其他请求（5%）。

2．服务质量的细化

有些请求，是要对数据作“写”操作，可以要求慢一些，比如“用户下订单，购买商品”，这一服务质量请求可以放宽为5秒钟，甚至更长。除了用户体验到的“2秒钟页面刷新”目标外，效能测试还要测试软件内部各模块的效能，这要求软件的模块能报告自身的各种效能指标，通过Perfmon或其他测试工具表现出来。

和别的测试不同，效能测试对硬件要有固定的要求，而且每次测试需要在相同的机器和网络环境中进行，这样才能避免外部随机因素的干扰，得到精准的效能数据。

问：我们以前做效能测试的时候，服务器上都没有任何负载，数据库里也没有几条记录，所以效能都很不错，可是当系统真的运行起来，就不行了。这些效能测试是自欺欺人的，对么？

答：在做效能测试的时候，的确要避免在不现实的环境中测试，例如要避免在没有任何用户、商品记录的系统上做测试；但是也没有必要为了追求真实而过分模拟随机的环境。

简单地说，现实的环境有如下两方面。

1．现实的静态数据

比如上面提到的数据库的各种记录，如果要模拟一个实际运行的商业网站，除了一定数量的用户和商品记录外，还得模拟在运行一段时间后产生的交易记录。

2．现实的动态数据

这就是负载，系统中总得有一些人在同时使用这一个系统。效能测试中要考虑到“负载”，可以分为：

（1）零负载，即只有静态数据，在这种情况下测试的结果应该是稳定的，可以不断地收集数据进行回归测试；

（2）加上负载，根据情况可以分负载等级进行测试。

同时，客户会问，“如果我的系统慢了，怎么办，我是增加机器的数量，还是提高每个机器的处理能力？”这是我们要回答的问题。效能测试的结果应该成为“发布指南”的一部分，给客户发布和改进系统提供参考。

在VSTS中如何进行效能测试在以后会详细讲解。

在进行负载测试的过程中，可以得到系统效能和负载的一个对应关系，这时，就可以看到能维持系统正常功能的最大负载。

如果负载足够大，或者过分的大，那就成了下一个测试的目标——压力测试。

7.11  压力测试（Stress Test）

压力测试严格地说不属于效能测试。压力测试要验证的问题是：软件在超过设计负载的情况下仍能够返回正常结果，没有产生严重的副作用或崩溃。

问：为啥不要求软件在这种情况下仍然在 2~3 秒钟内返回结果？

答：因为我们做不到。

提示：我们在这一部分要求“正常结果”，啥叫“正常”？我们也要和客户达成一致。比如，同一个购物网站，所有请求都能在网络返回“超时”错误前返回，就可以认为是“正常”。 或者网站返回“系统忙，请稍候”，也是正常结果。但是，如果用户提交的请求一部分执行，另一部分没有执行，或者用户信息丢失，这些都是不正常的结果，应该避免。

那我们怎样增加负载？对于网络服务软件来说，主要考虑以下两个方面。

1．沿着用户轴延长

以刚才的购物网站为例，正常的负载是20个请求/分钟，如果有更多的用户登录，怎么办？那么负载就会变成30、40、100个请求/分钟，或更高。

2．沿着时间轴延长

做过网络服务的同事都知道，网络的负载有时间性，负载压力波峰和波谷相差很大，那么如果每时每刻负载都处于峰值，程序会不会垮掉？这就是我们要做的第二点：沿着时间轴延长。一般要模拟 48 小时的高负载才能认为系统能通过测试。

与此同时，可以减少系统可用的资源，来增加压力。

注意，压力测试的重点是验证程序不崩溃或产生副作用。在超负载的情况下，我们的程序仍然能够正确地运行，而不会死机。在给程序加压的过程中，程序中的很多“小”问题就会被放大，暴露出来。最常见的问题是：

◆ 内存/资源泄漏，在压力下这会导致程序可用的资源枯竭，最后崩溃；

◆ 一些平时认为“足够好”的算法实现会出现问题。

比如，Windows Platform SDK有一个GetTickCount()的函数，它返回自系统启动后所经过的毫秒数，用 DWORD 来表示。经过 47.9 天之后DWORD 会溢出，GetTickCount()会从 0 开始重新计数，你的程序如果用了不同的 TickCount来计算时间，不要假设后来的 TickCount 一定会比先前的TickCount大，也许系统在运行一段时间后会出现莫名其妙的错误，但是系统重启动后，又找不到原因。

◆ 进程/线程的同步死锁问题，在压力下一些小概率事件会发生，看似完备的程序逻辑也会出现问题。

在VSTS中如何进行压力测试在以后的章节中会详细讲解。

7.12  内部/外部公开测试（Alpha Test, Beta Test）

在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（Alpha/Beta用户）使用正处于开发过程中的版本，用户会通过特定的反馈渠道（E-mail、BBS）与开发者讨论使用中发现的问题，等等。这种做法成功地让部分用户心甘情愿地替开发团队测试产品并提出反馈。

从惯例上说，Alpha Test一般指在团队之外，公司内部进行的测试；BetaTest指把软件交给公司外部的用户进行测试，与之对应地，软件就有Alpha、Beta1、Beta2版本。在网络普及之前，做Beta Test是很花费人力物力的事情，现在由于网络的传播速度很快，与外部用户的联系渠道很畅通，很多外部用户都想先睹为快。因此最近开发团队增加了反馈的密度，不必再局限于Alpha或者 Beta 发布，而是不断地把一些中间版本发布出去以收集反馈，美其名曰“技术预览版本”（Technical Preview Release）或“社区预览版本”（Community Preview Release）。

7.13  易用性测试（Usability Test）

小燕：作为测试人员，我们是不是也要做易用性测试?

答：测试人员，以及其他的团队成员都可以对软件的可用性提出意见，包括以Bug的形式放在TFS中。软件的可用性并不神秘，就是让软件更好用，让用户更有效地完成工作。

但是我觉得“易用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是由对软件设计及对可用性有很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章，大家可以参考。

为了弄清软件的可用性，并了解用户的需求，移山公司的员工特地进行了一个易用性测试——

小飞学了很酷的Web“WPF/我佩服”界面技术，然后做了一个小游戏——3D挖雷。大家用了之后，都觉得不错，用鼠标单击/双击，左键/右键都可以进行各种不同的操作。于是他们迫不及待地找一个“典型用户”来做易用性测试。

王屋村的村民，石头他爹刚好路过，他被移山公司的小伙子们拉了进来，成为第一个“典型用户”。

大家七嘴八舌地介绍了游戏的功能，就让石头他爹试一试。石头他爹看到鼠标，说，这个怎么和俺家里的不一样？小飞说：这是光电鼠标，好用得很！

三分钟过去了，游戏还没有开始；

五分钟，十分钟过去了，游戏还是没有进展。

阿超走过去看看到底怎么回事——

原来，石头他爹手指不灵活，在按鼠标的时候鼠标的位置会稍稍移动，导致程序无法捕捉鼠标双击事件。问题是在小飞设计的游戏中，鼠标单击、双击都可以，而且是不同的功能。

同时，有些功能还只能够通过右键弹出菜单来执行。

石头他爹看起来很迷惑。这时，小飞说：左键/右键/单击/双击都可以。

从此之后，石头他爹对每一个操作都问：是按左键还是按右键？是按一下还是两下？

小飞露出了“faint”的表情。

半个小时后，大家送走了石头他爹，同时送他一个鼠标垫作为礼物。

阿超：（目送石头他爹的背影）幸好……

小飞：幸好啥？

阿超：幸好你还没有介绍你那超级功能，要按住Ctrl键，同时拖动鼠标才能使用。否则我们还要花半个小时陪石头他爹一起学习玩这个游戏。

7.14  "小强"大扫荡（Bug Bash）

问：我们已经讲了太多的测试了，好像微软还有一个叫“BugBash”的活动，是啥意思？

答：Bug Bash，或者叫Bug Hunt，简而言之，就是大家一起来找小强的活动——小强大扫荡。一般是安排出一段时间（一天），所有测试人员（有时也加入其他角色）放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找得最多和最厉害的小强的员工。

问：这是不是可以看做是“全体动员Ad hoc”?

答：一般情况下是的，但是并不是全体人员用键盘鼠标一通乱敲乱点就可以搞定，大扫荡的内容也应该事先安排好。

这种活动，如果运用得好，会带来这样的功效：

◆ 鼓励大家做探索试的测试，开阔思路；

◆ 鼓励测试队伍学习并应用新的测试方法，例如在做完“软件安全性测试”培训后，立马做一个针对“安全性”的小强大扫荡，或者为“全球化/本地化测试”做一个小强大扫荡也是很常见的；

◆ 找到很多小强，让开发人员忙一阵子。

当然，小强大扫荡也有一些副作用：

◆ 扰乱正常的测试工作；

◆ 如果过分重视奖励，会导致一些数量至上，滥竽充数的做法。

因此，两个需要提醒的细节是：

（1）一定要让“小强大扫荡”有明确的目标、明了的技术支持。

（2）一定要让表现突出的人介绍经验，让别人学习。

要记住，最好的测试，是能够防止小强的出现。

7.15  讨论

7.15.1 十八般兵器

阿毛：超总，我的脑袋好像装不下了！听了这么多，我感觉像是身上扛着十八般兵器，它们互相碰撞，叮叮当当。我累得半死，但是不知道什么时候，对哪一种敌人用哪一种兵器，能不能总结一下！

阿超：好，我们用软件开发的生命周期来说明一下不同的测试在不同阶段的使用。

1．远景和计划阶段

此时，测试只是处于计划阶段，我们要讨论测试计划和测试设计说明书，同时要收集用户对于软件非功能性的需求，如效能、可用性、国际化等。一些“小强大扫荡”的类型也可以在这个时候初步安排。

2．开发阶段。

开发人员要写单元测试，测试人员要写BVT。

对于每一个成功的构建，测试人员要运行功能测试/场景测试，同时建立回归测试基准以便开始回归测试。各类测试人员要进行探索式测试以求尽早发现问题。

随着软件功能的逐步完善，测试人员要进行集成测试。这时，团队可以开展对程序非功能性特性的测试，如效能/压力测试、国际化/本地化测试、安全性测试、可用性、适用性测试等。在这个时候，可以考虑分析各个模块的代码覆盖率，以增加测试的有效性。根据计划，各种类型的“小强大扫荡”会以适当的频率发生。

3．稳定阶段。

到了一个开发阶段的尾声，这时测试团队就可以依据以前制定的验收标准，对软件逐项进行验收测试。按照测试计划，各个方面的测试都会宣布“测试完成”——所有想到的测试都做了，所有问题都发现了。在此阶段，团队也可以把软件发布给外部进行Alpha/Beta测试。

这时，伙伴测试会用于保证新代码签入前能得到足够的检测。

一般情况下，测试队伍要把迄今为止发现的所有小强都重新试一遍，确保它们都在最后的版本中被清除了，没有一个“回归”出现。

4．发布阶段。

测试队伍要把尽可能多的测试用例自动化，并为下一个版本的测试工作做好准备。

7.15.2 怎样写测试计划

这会在后面的章节中讨论。测试计划的模板在移山社区网站上有下载。

7.15.3 如果一个Bug在实际应用中根本不可能发生，这还是一个Bug么

看这里：http://www.testingcraft.com/Bug-in-forest.pdf。

另外，要知道这世界上有各种各样的用户，有些用户“亡软件之心不死”，IE 和 Windows 的许多安全漏洞，都在这些用户的努力下被发现并且被利用了。很多人当初会说“缓冲区溢出？这是根本不会发生的事，用户怎么会在字符串后面加这么多乱七八糟的东西？！”。

7.15.4 Bug的数量和测试人员的工作效率有关么？和工作人员的工作绩效有关么

阿亨：当然有关！我们会在以后的实践中碰到这些问题。

阿超：有关，但是也不是太有关。一个极端的例子，如果一个开发人员写的模块没有任何Bug，那测试人员的工作效率如何衡量？我们以后再说。

7.15.5 有错不改

果冻：微软的产品经过这么多版本的不断完善，应该是把所有问题都搞定，“止于至善”了吧？

阿超：那也不一定，在非常有名的电子表格软件Excel中，就有这样一个Bug：Excel 的日期计算功能认为1900年是一个闰年，这是不对的，但是它愣是一直没有改正这个错误。

众人：真的？为什么屡教不改呢？

阿超：故事是这样的，当时这类电子表格软件的市场领头羊是Lotus 1-2-3这一款软件。它的日期计算功能有一个Bug，就是把1900 年当作闰年。这类软件在内部把日期保存为“从1900/1/1 到当前日期的天数”这样的一个整数。Excel 作为后来者，要支持 Lotus 1-2-3 的数据文件格式，这样才能正确处理别的软件产生的格式文件。这个错误就这么延续下来了，每一版本都有人报告，但是都没有改正。我们可以在Excel中试试看：

在任意格子（cell）中输入“=DATE(1900,2,28)”，并且定义这个格子的格式为数字。大家可以看到数值变为：59。表明 1900/2/28 是1900/1/1开始的第59天。

输入“=DATE(1900,2,29)”，可以看到 60! 这是一个不存在的日期！

输入“=DATE(1900,3,1)”，数值是 61，事实上，这应该是 60。从这一天开始的所有日期都错了一天。

果冻：还是可以抓住机遇，促成飞跃，在某一个版本彻底改好，不就是一个数字嘛。

阿超：改这个问题，技术上一点问题都没有。但是在现实中会出现下列问题：

（1）几乎所有现存文件的日期数据都要减少一天，所有依赖于日期的Excel公式也要做检查和修改。这在现实生活中是很难办到的。

（2）Excel 的日期问题解决了，但是其他软件还是有这个 Bug，数据文件在不同软件中使用，就会有很头痛的兼容性问题。