冒烟测试的笔记

作者：Steve Rowe

BVT（Build Verification Test，构建验证测试）是微软内部的一个标准说法，指的是每天都要运行的测试，以确保前一天入库的内容没有破坏重要功能。先前我曾写过一篇文章说明保持BVT整洁的重要性（文章稍后翻译）。在那些持续通过的测试中，哪些应放入BVT中呢？BVT失败时，应该是你要立即去处理的。也就是说，BVT中失败的测试必须是非常重要的。基于这一观点，以下是一些有关BVT的准则：

• 测试重要场景，而非次要场景。如果一个重要功能失败了，那么应当立即解决。而如果失败的是一个次要场景，那么只是要引起重视，可能需要推到以后再去处理。
• 测试主要用例，而非次要用例。对3个功能模块相互交互的测试不应放在BVT中。对最常见使用场景之外的测试不应放在BVT中。虽然每本测试书籍都说要测试边界值，但BVT不应用来测这些东西。BVT测试的是最常见的输入值和使用场景。
• 做“正常(positive)”测试而非“异常”(negative)测试。不要测试边界外的条件和异常值。当然做这些测试都是必要的，但不应在BVT中做。传递一个空指针而导致的API失效当然要进行修复，但可以放到下周嘛。

BVT应当是一组仔细选取过的测试。它们应当能够快速、一致地运行，其结果要非常重要。始终坚持这些原则的话，BVT就非常有效果，因为任何失败都会受到足够重视。将BVT限制在最重要的场景将保证测试结果能够得到恰当的处理。。

当冒烟测试发生在集成测试的子系统间集成和系统测试的时候，这个时候，人们常常把冒烟测试等同为BVT（Build Verification Testing），也就是所谓的小版本验证测试。

 冒烟测试一般是由程序员来执行；冒烟测试带有一定的随机性，它不需要去设计正式的测试用例，这个活动在开发部门内开展；

系统预测试也叫“转系统测试”（有的地方把“转系统测试”看作为是针对“系统测试预测试报告”等输入文档的评审活动，其实大可不必去抠两个词汇的区分，这样做意义不大），一般是由Tester来实施的，也可以在开发人员的配合之下开展，如果是这种情况下，系统预测试就是敏捷开发极限编程中的“结对编程、结对测试”了；

系统预测试是个别规范的大公司才有的流程，在微软内部与之类似的有个“Buddy Test（合伙测试）”，指的是开发人员提交软件版本后申请转系统测试之前的功能性验证（可能还包括其他方面的验证），目的是确保系统的基本功能确实没有问题，使得后续的系统测试能够顺利开展，不至于出现主要功能有致命问题，大量的用例被堵塞，导致系统测试无法继续下去。

从顺序上来说，是UT--IT--Pre ST--ST。也就是说PM（或开发人员）提出转系统测试申请后，测试部门的Testers会进行系统预测试，完成后由测试主管组织测试部门人员进行这次转系统测试评审。