再谈BVT及其处理方式

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

ps：自动化

 

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

答：第一，必须能安装；第二，必须能够实现一组核心场景。

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

 

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

ps：测试代码需要和程序代码同时版本管理。

 

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

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

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

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

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

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

ps：优先处理 + 维持每日构建，并产生一个可测的版本是软件开发过程中质量控制的基础