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

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

　　答案是否定的。

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

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

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

　　b）没有释放资源。

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

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

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

　　构建验证测试（BVT：Build Verification Test）

　　望文生义，构建验证测试是指在一个构建完成之后，团队自动运行的一套验证系统基本功能的测试。在大多数情况下，这一套系统都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

　　问：一个系统有这么多功能点，什么是基本的功能，什么不是基本的功能？

　　答：第一，必须能安装；第二，必须能够实现一组核心场景。例如，对于字处理软件来说，必须能打开/编辑/保存一个文档文件，但是一些高级功能，如文本自动纠错，则不在其中；又如，对于网站系统，用户可以注册/上传/下载信息，但是一些高级功能，如删除用户，列出用户参与的所有讨论，则不在其中。

　　在运行BVT之前，可以运行所有的单元测试，这样可以保证系统的单元测试和程序员的单元测试版本一致。在不少情况下，开发人员修改了程序和单元测试，但是忘了把修改过的单元测试也同时签入源代码库中。

　　通过BVT的构建可以称为可测（Self-test），意思是说团队可以用这一版本进行各种测试，因为它的基本功能都是可用的。通不过BVT的构建称为“不可测”（Self-hosed）。

　　如果构建测试不能通过，那么自动测试框架会自动对每一个失败的测试产生一个Bug（小强）。一般的做法下这些小强都有高优先级，开发人员要首先修改这些小强。大家知道维持每日构建，并产生一个可测的版本是软件开发过程中质量控制的基础。对于导致问题的小强，我们该怎么办？答案是——

　　（1）找到导致失败的原因，如果原因很简单，程序员可以马上修改，然后直接提交。

　　（2）找到导致失败的原因的修改集，把此修改集剔出此版本（程序员必须修改好后再重新提交到源代码库中）。

　　（3）程序员必须在下一个构建开始前把此小强修理好。

　　方法（1）和（2）都可以使的构建成为“可测”，但是有时各方面的修改互相依赖，不能在短时间内解决所有问题，那只能采用第三种方法了。

　　问：有人提到一种“Smoke Test”，冒烟测试，是怎么回事？

　　答：事实上这是一种基本验证测试，据说是从硬件设计行业流传过来的说法。当年设计电路板的时候，很多情况下，新的电路板一插上电源冒起白烟，烧坏了，如果插上电源后没有冒烟，那是通过了“冒烟测试”，可以进一步测试电路板的功能了。我们正在讨论的BVT也是一种冒烟测试。

　　验收测试（Acceptance Test）

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

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

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

　　当所有的测试人员完成对场景的测试，我们自然地得出了表7-5。

表7-5  场景测试报告