望文生义，构建验证测试是指在一个构建完成之后，团队自动运行的一套验证系统的基本功能的测试。大多数情况下，这一套系统都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。
问：一个系统有这么多功能点，什么是基本，什么是不基本的？
答：第一，必须能安装；第二，必须能够实现一组核心场景（例如：对于字处理软件来说，必须能打开/编辑/保存一个文档文件，但是一些高级功能，如:文本自动纠错,则不在其中；又如，网站系统，用户可以注册/上载/下载信息，但是一些高级功能，如删除用户，列出用户参与的所有讨论，则不在其中。
通过BVT的构建可以称为：可测（self-test）,意思是说团队可以用这一版本进行各种测试–因为它的基本功能都是可用的。通不过BVT的构建称为“不可测”（self-hosed）
如果构建测试不能通过，那么自动测试框架会自动对每一个失败的测试产生一个bug（小强）。一般的做法这些小强都是有最高优先级，是开发人员要首先修改这些小强。大家知道维持每日构建，并产生一个可测的版本是软件开发过程质量控制的基础。对于导致问题的小强，我们该怎么办？
1．找到导致失败的原因，如果原因很简单，程序员可以马上修改，然后直接提交。
2．找到导致失败的原因的修改集，把此修改集剔出此版本（程序员必须修改好后再重新提交到源代码库中）。
3．程序员必须在下一个构建开始前把此小强修理好。
方法1/2都可以使今天的构建成为“可测”，但是有时各方面的修改互相依赖，不能在短时间内解决所有问题，只能采用第三个办法。
问：有人提到一种“smoke test”，冒烟测试，是什么回事？
答：这事实上是一种基本验证测试，据说是从硬件设计行业流传过来的说法–当年设计电路板的时候，很多情况下，新的电路板一插上电源就冒起白烟，烧坏了，如果插上电源后没有冒烟，那就是通过了“冒烟测试”，可以进一步测试电路板的功能了。我们正在讨论的BVT也是一种冒烟测试。
1.6 功能测试（functional test）
测试团队拿到一个“可测”等级的构建，他们就会按照测试计划，测试各自负责的模块和功能，这个过程可能会产生总共10来个bug，也可能产生100个以上的bug，那么如何保证我们有效地测试了软件，同时我们在这一步怎样衡量构建的质量？
在“基本场景”的基础上，我们把所有系统目前理论上支持的场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明“成功”，否则，就标明“失败”，并且把失败的情况用一个（或几个）“小强”/bug来表示。
当所有的测试人员完成对场景的测试，我们自然地就得出了一个表：
|
场景ID |
场景名 |
测试结果 |
Bug/小强id |
|
3024 |
用户登录 |
成功 |
|
|
3026 |
用户按价格排序 |
失败 |
5032 |
|
3027 |
用户按名字搜索 |
失败 |
5033 |
|
…
|
… |
… |
… |
