上一章节中，小艾已经掌握了构建测试的基本知识，其实，构建测试也称为构建可接受性测试(Build Acceptance Test)，一般是在每一个测试产品生成之后，构建测试团队执行一组最基本的测试用例，来确定做成的测试产品的质量是否达到可以交到各个测试组来进行更全面、更深入的各项测试的要求。
构建测试用例的原则
构建测试的测试用例基本是功能测试用例，相对比较简短，应着重于产品的最基本、最重要的功能。原则有：
1. 只测试最重要的、最基本的功能，通过后可以开展其余各种测试。
2. 只测试已经测试过且相对稳定的用例。
只有构建测试的顺利通过，其他测试团队才可以使用新构建的测试产品进行测试。
重要性：
1. 可以让开发人员知道新版本的源码是否可以被成功构建成软件产品
2. 可以帮其他测试团队避免浪费时间在不稳定或不工作的测试产品上
构建测试步骤
1. 安装测试产品及其需要的其他软件
2. 进行产品所需要的系统配置
3. 测试几个最基本的产品功能
构建测试还包括对构建过程本身的检验，主要内容有：
1. 确认构建是否包括了源码文件新的变更
2. 检验构建的日志是否报错
3. 最终产品文件的大小是否有异常
在搭建构建测试环境时，需要考虑的常规步骤有：
1. 采用一些能实现系统配置自动化的工具，作为构建测试的一部分，自动安装所有构建测试需要的软件
2. 使用一些系统备份及恢复的工具：备份安装好构建测试所需软件的系统、备份构建环境本身
根据前文小艾从测试负责人那里学到的知识，小艾做了一些总结。
构建测试的配置
构建测试的目的是检验产品构建过程是否成功完成，构建出的测试产品是否有足够好的质量可以交给其他各个测试组进行更深、更广的测试。
只要测试产品可以在单节点系统配置环境上正常工作，它就可以发布给其他的测试组进行测试。
构建测试的用例(BVT Scenarios)
首先，在制定构建测试用例时，需要和其他的测试组保持良好的沟通，其次，应考虑根据需要改变构建测试的测试用例，最后，构建测试的测试用例的运行时间必须控制在合理的范围内。
综上所述，测试用例的选择应该有如下特点：最基本、最核心的功能，可变更但稳定的用例，运行的时间合理。
自动化的构建测试
自动化的构建测试可以保证测试过冲的准确性，避免构建测试过程中的人为错误，可以提高构建测试的效率，同时可以保证构建测试过程中的一致性和稳定性。
构建测试的环境再利用
以构建测试服务器为模板，通过系统备份及恢复的流程为各个测试小组创建出他们所需要的测试环境。
构建测试主要从功能的角度对构建测试产品进行验证。构建测试成功执行时其他测试开始的前提条件。
小艾总结完之后，工作的无意间，听到一个名词叫静态测试，他很好奇静态测试是什么测试，与构建测试有什么关系，如何做静态测试？为了弄清楚这个问题， 小艾再次找到了构建测试负责人。负责人就静态测试给小艾进行了较为简单的讲解。
静态测试
与构建测试进行的功能测试不同，静态测试是针对源文件直接做测试分析，发现问题。
静态测试的作用及环境
静态测试适用于在源文件中就能发现问题的情形。常见的静态测试用例有：用户化规则检验，语法及拼写检验，网页亲和力检验等。
看到这静态测试的概念，看到这静态测试用例的几个例子，相信大家脑子里朦胧地产生了一个词，代码走查……不用怀疑，代码走查就是静态测试的用例之一。
由于构建的环境上有所有最新的源文件，因而在构建系统上进行完整的静态测试通常是最为容易的。
虽然静态测试可以加入到构建过程中，但一般不这么考虑，因为加入构建测试会增加时间的消费。
自动化的静态测试
理想的静态测试过程应该运用自动化的工具来发现并报告静态测试中的问题：
上图中所有实线部分的过程一般都应该包含在自动静态测试中进行。
静态测试的频率
根据不同测试用例的需要来指定相应的测试频率，一般静态测试的频率比构建的频率低。如果静态测试作为构建过程的一部分，那么应将静态测试的任务设置为可以选择是否需要执行，来减少潜在的构建问题及构建时间。
不间断的构建与测试
不间断的构建与构建测试是指不间断、循环往复地进行构建和构建测试，这是一种理想化的模式，在这种模式下，构建过程和构建测试必须完全自动化。
上图显示了一个完整的构建及构建测试的循环过程。要实现这个循环过程的不间断，杜绝构建及构建测试失败是关键。
尾声
成功的构建测试需要所有开发人员和测试人员的共同努力，确保最新提交的源文件不会引起任何构建和构建测试失败。
小艾在构建测试组待的一段时间里，对构建测试有了一个全面且深入的了解，就在这时候，小艾测试的过程中，发现了一个令人抓狂的bug，最让小艾无法理解的是，开发人员居然会把这种具有最基本功能bug的代码提交出来。那么，故事到底是如何发展的呢？请听下回分解~
想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月
