谈谈集成测试（integration testing）

　　对于软件开发来说，软件测试是一个几乎贯穿所有阶段的活动，所以测试的重要性毋庸置疑。不同开发组织如何在不同的产品研发阶段进行测试，也在很大程度上反映了其研发能力和质量控制能力。软件测试有很多类型，包括单元测试，集成测试，压力测试... 其中，集成测试的投入产出比相对最高，因为它覆盖的基本上都是最常用的用例（用户影响权重高）。根据维基百科的定义，集成测试(integration testing)是将若干的软件模块组合起来，测试某项特定功能。不同于单元测试只孤立的测试软件模块，集成测试更关注不同软件模块之间的交互。冒烟测试可以被认为是最小化的集成测试。所以从广义角度来说，几乎所有开发组织都会做不同规模的集成测试。

　　集成测试策略基本分为4种：大爆炸测试（big-bang），自顶而下测试(Top-down)，自底而上测试(Bottom-up)，三明治测试。大爆炸测试就是把大部分软件模块在同一时间组合在一起进行测试。很明显，这种测试策略总体上来说是非常低效的，也违背迭代式开发的基本原则。问题会在同一时间大量爆发，并且因为每个模块都可能存在严重问题，问题定位也将非常艰难，从而使项目进度和质量都不可控制。因此，大爆炸测试是最糟糕的测试策略。自顶而下测试(Top-down）是先测试最低层模块，然后向上逐级测试更高级的模块。自底而上测试(Bottom-up)则与之相反。三明治测试是把自顶而下测试(Top-down)和自底而上测试(Bottom-up)结合在一起的测试策略。在四种策略中，三明治测试应该最优先被采用，因为它兼具高效性和可控性，使得开发并行性成为可能。

　　集成测试的测试用例（test case）必须基于用例(use case)进行开发。一个用例对应一个或多个集成测试用例。（用例属于需求分析的范畴，不在本文讨论之列，可参阅相关资料）。覆盖用例的主要路径（happy path）当然是测试用例的最基本要求。对用例的异常路径（exceptions）的覆盖程度，则是提高软件质量的重要因子。因此，提高测试用例覆盖度的首要前提，是提高用例的完备度。在现实中，一些开发组织不做正式的需求分析，有些即使做需求分析但是不对用例进行文档化，造成的结果是集成测试甚至不能保证覆盖所有的主要路径。不同于单元测试可运行于宿主开发机或模拟器系统（针对嵌入式开发），集成测试必须运行于真实的目标系统，因为集成测试属于功能测试。集成测试一般基于API级别，介于白盒测试和黑盒测试之间。除了基于用例的路径覆盖，也应采取等价类测试和边界测试等功能测试方法，以提高测试覆盖度。

　　系统集成测试（System integration testing）是集成测试一个特例，是将被测系统（包括所有的硬件和软件）作为一个整体来进行测试，因此属于完全的黑盒测试。测试用例代码可以不运行于待测系统中，而运行于另外的测试系统中。测试系统通过被测系统提供的接口（比如硬件引脚、通信信道，软件接口等），根据用户需求或者被测系统规格书，对被测系统进行测试。同一般的集成测试类似，如果能根据用户需求和系统规格书产生完整的用例文档，将极大的方便创建系统集成测试的测试用例。

　　虽然某些系统集成测试也可以手动进行，但是集成测试应尽可能的自动化。测试用例需要周期性的运行，相比于手动测试，自动化测试可极大的缩短测试时间和减少人力成本。同时，测试用例代码应同功能代码一起统一管理和维护。也就是说，测试用例代码应达到或接近功能代码的质量要求。否则如果测试用例代码本身的问题反而会托慢开发进程，甚至应不被信任被抛弃。

　　综上所述，集成测试对于任何软件开发组织都是必选项，因此对于集成测试的任何改善都能极大的帮助质量控制水平。需求分析和用例文档是集成测试的重要前提，应重视测试用例的代码质量。开发组织可根据其特点，选择合适自身的集成测试策略。