望文生义，构建验证测试是指在一个构建完成之后，团队自动运行的一套验证系统基本功能的测试。在大多数情况下，这一套系统都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。
在运行BVT之前，可以运行所有的单元测试，这样可以保证系统的单元测试和程序员的单元测试版本一致。在不少情况下，开发人员修改了程序和单元测试，但是忘了把修改过的单元测试也同时签入源代码库中。
通过BVT的构建可以称为可测（Self-test），意思是说团队可以用这一版本进行各种测试，因为它的基本功能都是可用的。通不过BVT的构建称为“不可测”（Self-hosed）。
如果构建测试不能通过，那么自动测试框架会自动对每一个失败的测试产生一个Bug（小强）。一般的做法下这些小强都有最高优先级，开发人员要首先修改这些小强。大家知道维持每日构建，并产生一个可测的版本是软件开发过程中质量控制的基础。对于导致问题的小强，我们该怎么办？答案是——
测试团队拿到一个“可测”等级的构建，他们就会按照测试计划，测试各自负责的模块和功能，这个过程可能会产生总共10来个Bug，也可能产生100个以上的Bug，那么如何保证我们有效地测试软件，同时我们在这一步怎样衡量构建的质量？
在“基本场景”的基础上，把所有系统理论上目前支持的场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明“成功”，否则，就标明“失败”，并且把失败的情况用一个（或几个）“小强”/Bug来表示。
这样就能很快地报告“功能测试56%通过”等。如果所有场景都能通过，（有些情况下可以把此标准从100%降低到90%左右）则这个构建的质量是“可用”，意味着这一个版本可以给用户使用。在这种情况下，客户、合作伙伴可以得到这样的版本，这也是所谓“技术预览版”或“社区预览版”的由来。
但是，有一个重要的问题要大家注意：“可用”，并不是指软件的所有功能都没有问题，而是指在目前的用户场景中，按照场景的要求进行操作，都能得到预期的效果，注意以下两种情况：
如：在某一场景中，场景规定用户可以在最后付款前取消操作，回到上一步，如果一个测试人员发现在反复提交/取消同一访问多次后，网页出现问题，这并不能说明用户场景失败，当然对于这个极端的Bug，也必须找出原因并在适当的时间改正。
这种测试有时也被称为验收测试“Acceptance Test”，因为如果构建通过了这样的测试，这一个构建就被测试团队“接受了”。同时，还有对系统各个方面进行的“验收”测试，如系统的全球化验收测试，或者针对某一语言环境、某一个平台做的测试。
“探索式”的测试（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”发现的小强在正常使用软件中几乎不会出现，我们要不要花时间“Ad hoc”？
答：现在一些成功的通用软件的用户以百万计，按部就班的测试计划很难包括很多实际的场景，这时，“Ad hoc”测试能够发现重要的问题；另外一些风险很大的领域，例如安全性，一旦出了问题，威胁就会相当大，这时要多鼓励一些“Ad hoc”测试，以弥补普通测试的不足。从这个意义上说，“Ad hoc”测试可以用来衡量当前测试用例的完备性，如果你探索了半天，都没有发现什么在现有测试用例之外的问题，那就说明现有的测试用例是比较完备的。
“Ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“Ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级——可重复级。
作为管理人员来说，如果太多的小强是在“Ad hoc”出来的，那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善，等等。同时，要善于把看似“Ad hoc”的测试用例抽象出来，囊括到以后的测试计划中。
回归测试（Regression Test）
问：我听说不少关于Regression Test的介绍，但是它到底是怎么“回归”法？回归到哪里去？我还是没搞懂。
答：Regress的英语定义是： return to a worse or less developed state。是倒退、退化、退步的意思。
在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。
在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准（Baseline）。
假如，在3.1.5版本，模块A的测试用例125是通过的，但是测试人员发现在新的版本3.1.6，这个测试用例却失败了，这就是一个“倒退”。在新版本上运行所有已通过的测试用例以验证有没有“退化”情况发生，这个过程就是一个“Regression Test”。如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因）引起的，那么测试用例的基准就要修改，以便和新的功能保持一致。
针对一个Bug Fix（拖鞋），我们也要作Regression Test。
（1）验证新的代码的确把缺陷改正了。
（2）同时要验证新的代码没有把模块的现有功能破坏，没有Regression。
所以对于“回归测试”中的“回归”，我们可以理解为“回归到以前不正常的状态”。
回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。在微软的实践中，在一个项目的最后稳定阶段，所有人都要参加测试，以验证所有已经修复过的Bug的确得到了修复，并且没有在最后一个版本中“复发”，这是一个大规模的、全面的“回归测试”。
内部/外部公开测试（Alpha Test， Beta Test）
在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（Alpha/Beta用户）使用正处于开发过程中的版本，用户会通过特定的反馈渠道（E-mail、BBS）与开发者讨论使用中发现的问题，等等。这种做法成功地让部分用户心甘情愿地替开发团队测试产品并提出反馈。
从惯例上说，Alpha Test一般指在团队之外，公司内部进行的测试；Beta Test指把软件交给公司外部的用户进行测试，与之对应地，软件就有Alpha、Beta1、Beta2版本。在网络普及之前，做Beta Test是很花费人力物力的事情，现在由于网络的传播速度很快，与外部用户的联系渠道很畅通，很多外部用户都想先睹为快。因此最近开发团队增加了反馈的密度，不必再局限于Alpha或者Beta发布，而是不断地把一些中间版本发布出去以收集反馈，美其名曰“技术预览版本”（Technical Preview Release）或“社区预览版本”（Community Preview Release）。
易用性测试（Usability Test）
小燕：作为测试人员，我们是不是也要做易用性测试？
答：测试人员，以及其他的团队成员都可以对软件的可用性提出意见，包括以Bug的形式放在TFS中。软件的可用性并不神秘，就是让软件更好用，让用户更有效地完成工作。
但是我觉得“易用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是由对软件设计及对可用性有很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章，大家可以参考。
为了弄清软件的可用性，并了解用户的需求，移山公司的员工特地进行了一个易用性测试——
小飞学了很酷的Web“WPF/我佩服”界面技术，然后做了一个小游戏——3D挖雷。大家用了之后，都觉得不错，用鼠标单击/双击，左键/右键都可以进行各种不同的操作。于是他们迫不及待地找一个“典型用户”来做易用性测试。
王屋村的村民，石头他爹刚好路过，他被移山公司的小伙子们拉了进来，成为第一个“典型用户”。
大家七嘴八舌地介绍了游戏的功能，就让石头他爹试一试。石头他爹看到鼠标，说，这个怎么和俺家里的不一样？小飞说：这是光电鼠标，好用得很！
三分钟过去了，游戏还没有开始；
五分钟，十分钟过去了，游戏还是没有进展。
阿超走过去看看到底怎么回事——
原来，石头他爹手指不灵活，在按鼠标的时候鼠标的位置会稍稍移动，导致程序无法捕捉鼠标双击事件。问题是在小飞设计的游戏中，鼠标单击、双击都可以，而且是不同的功能。
同时，有些功能还只能够通过右键弹出菜单来执行。
石头他爹看起来很迷惑。这时，小飞说：左键/右键/单击/双击都可以。
从此之后，石头他爹对每一个操作都问：是按左键还是按右键？是按一下还是两下？
小飞露出了“faint”的表情。
半个小时后，大家送走了石头他爹，同时送他一个鼠标垫作为礼物。
阿超：（目送石头他爹的背影）幸好……
小飞：幸好啥？
阿超：幸好你还没有介绍你那超级功能，要按住Ctrl键，同时拖动鼠标才能使用。否则我们还要花半个小时陪石头他爹一起学习玩这个游戏。
场景/集成/系统测试（Scenario/ Integration / System Test）
在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，在各方面都能满足用户的要求。这时的测试叫系统/集成测试。
问：有一种测试叫Scenario Test，是什么意思？
答：就是以场景为驱动的集成测试，关于“场景”，大家可以看专门的介绍。这一方法的核心思想是：当用户使用一个软件的时候，他/她并不会独立使用各个模块，而是把软件作为一个整体来使用的。我们在做场景测试的时候，就需要考虑在现实环境中用户使用软件的流程是怎样的，然后模拟这个流程，看看软件能不能达到用户的需求。这样，能使软件符合用户使用的实际需求。
以一个数字照片编辑软件为例，这个软件的各个模块都是独立开发的，可是用户有一定的典型流程，如果这个流程走得不好，哪怕某个模块的质量再高，用户也不会满意。用户的典型流程是：
（1）把照相机的储存卡插入电脑。
（2）程序会弹出窗口提示用户导入照片。
（3）用户根据提示导入照片。
（4）对照片进行快速编辑。
a）调整颜色；
b）调整亮度，对比度；
c）修改红眼。
（5）选择其中几幅照片，用E-mail发送。
这里面哪一步出了问题，都会影响用户对这一产品的使用。如果这里面各个模块的用户界面不一致（即使是“确认” 和 “取消” 按钮的次序不同），用户使用起来也会很不方便。这些问题都是在单独模块的测试中不容易发现的。
问：什么时候做集成测试？是不是越快越好？
答：原则上是当一个模块稳定的时候，就可以把它集成到系统中，和整个系统一起进行测试。在模块本身稳定之前就提早做集成测试，可能会报告出很多Bug，但是这些由于提早测试而发现的Bug有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭——有点像噪音。我们还是要等到适当的时机再开始集成测试。
问：但是开发人员也想早日发现并修复所有的Bug，软件工程的目标不就是要早发现并修正问题么？总是要等待，听起来好像没有多少效率。
答：对，这就要提到在微软内部流行的另一种测试——Buddy Test伙伴测试。
伙伴测试（Buddy Test）
如上所述，在开发一个复杂系统的过程中，当一个新的模块（或者旧模块的新版本）加入系统中时，往往会出现下列情况。
（1）导致整个系统稳定性下降。不光影响自己的模块，更麻烦的是阻碍团队其他人员的工作。
（2）产生很多Bug。这些Bug都要被输入到数据库中，经过层层会诊（Triage），然后交给开发人员，然后再经历一系列Bug的旅行，才能最后修复，这样成本变得很高。
如何改进？一个方法当然是写好单元测试，或者运用重构技术以保证稳定性等，我们要讲的伙伴测试是指开发人员可以找一个测试人员作为伙伴（Buddy），在新代码签入之前，开发人员做一个私人构建（Private Build），其中包括了新的模块，测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接和开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。
在项目的后期，签入代码的门槛变得越来越高，大部分团队都要求Bug fix必须得到了伙伴测试的验证后才能签入到代码库中。
“小强”大扫荡（Bug Bash）
问：我们已经讲了太多的测试了，好像微软还有一个叫“Bug Bash”的活动，是啥意思？
答：Bug Bash，或者叫Bug Hunt，简而言之，就是大家一起来找小强的活动——小强大扫荡。一般是安排出一段时间（一天），所有测试人员（有时也加入其他角色）放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找得最多和最厉害的小强的员工。
问：这是不是可以看做是“全体动员Ad hoc”？
答：一般情况下是的，但是并不是全体人员用键盘鼠标一通乱敲乱点就可以搞定，大扫荡的内容也应该事先安排好。
这种活动，如果运用得好，会带来这样的功效：
◆ 鼓励大家做探索试的测试，开阔思路；
◆ 鼓励测试队伍学习并应用新的测试方法，例如在做完“软件安全性测试”培训后，立马做一个针对“安全性”的小强大扫荡，或者为“全球化/本地化测试”做一个小强大扫荡也是很常见的；
◆ 找到很多小强，让开发人员忙一阵子。
当然，小强大扫荡也有一些副作用：
◆ 扰乱正常的测试工作；
◆ 如果过分重视奖励，会导致一些数量至上，滥竽充数的做法。
因此，两个需要提醒的细节是：
（1）一定要让“小强大扫荡”有明确的目标、明了的技术支持。
（2）一定要让表现突出的人介绍经验，让别人学习。
要记住，最好的测试，是能够防止小强的出现。
讨论
1、十八般兵器
阿毛：超总，我的脑袋好像装不下了！听了这么多，我感觉像是身上扛着十八般兵器，它们互相碰撞，叮叮当当。我累得半死，但是不知道什么时候，对哪一种敌人用哪一种兵器，能不能总结一下！
阿超：好，我们用软件开发的生命周期来说明一下不同的测试在不同阶段的使用。
1）远景和计划阶段
此时，测试只是处于计划阶段，我们要讨论测试计划和测试设计说明书，同时要收集用户对于软件非功能性的需求，如效能、可用性、国际化等。一些“小强大扫荡”的类型也可以在这个时候初步安排。
2）开发阶段。
开发人员要写单元测试，测试人员要写BVT。
对于每一个成功的构建，测试人员要运行功能测试/场景测试，同时建立回归测试基准以便开始回归测试。各类测试人员要进行探索式测试以求尽早发现问题。
随着软件功能的逐步完善，测试人员要进行集成测试。这时，团队可以开展对程序非功能性特性的测试，如效能/压力测试、国际化/本地化测试、安全性测试、可用性、适用性测试等。在这个时候，可以考虑分析各个模块的代码覆盖率，以增加测试的有效性。根据计划，各种类型的“小强大扫荡”会以适当的频率发生。
3）稳定阶段。
到了一个开发阶段的尾声，这时测试团队就可以依据以前制定的验收标准，对软件逐项进行验收测试。按照测试计划，各个方面的测试都会宣布“测试完成”——所有想到的测试都做了，所有问题都发现了。在此阶段，团队也可以把软件发布给外部进行Alpha/Beta测试。
这时，伙伴测试会用于保证新代码签入前能得到足够的检测。
一般情况下，测试队伍要把迄今为止发现的所有小强都重新试一遍，确保它们都在最后的版本中被清除了，没有一个“回归”出现。
4）发布阶段。
测试队伍要把尽可能多的测试用例自动化，并为下一个版本的测试工作做好准备。
2、怎样写测试计划
这会在后面的章节中讨论。测试计划的模板在移山社区网站上有下载。
3、如果一个Bug在实际应用中根本不可能发生，这还是一个Bug么
看这里：http：//www.testingcraft.com/Bug-in-forest.pdf。
另外，要知道这世界上有各种各样的用户，有些用户“亡软件之心不死”，IE和Windows的许多安全漏洞，都在这些用户的努力下被发现并且被利用了。很多人当初会说“缓冲区溢出？这是根本不会发生的事，用户怎么会在字符串后面加这么多乱七八糟的东西？！”。
4、Bug的数量和测试人员的工作效率有关么？和开发人员的工作绩效有关么
阿亨：当然有关！我们会在以后的实践中碰到这些问题。
阿超：有关，但是也不是太有关。一个极端的例子，如果一个开发人员写的模块没有任何Bug，那测试人员的工作效率如何衡量？我们以后再说。
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，数据文件在不同软件中使用，就会有很头痛的兼容性问题。
总之，这个问题就这样一直留下来了。中间也有人想改过，你要注意看Excel 的 Options 设置，就会发现有这样一个设置——使用1904年开始的日期计算系统 （use 1904 date system）（如图7-1所示），但是一般的用户谁没事在这里打一个勾？
图7-1