谈谈集成测试（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）是集成测试一个特例，是将被测系统（包括全部的硬件和软件）做为一个总体来进行测试，所以属于彻底的黑盒测试。测试用例代码能够不运行于待测系统中，而运行于另外的测试系统中。测试系统经过被测系统提供的接口（好比硬件引脚、通讯信道，软件接口等），根据用户需求或者被测系统规格书，对被测系统进行测试。同通常的集成测试相似，若是能根据用户需求和系统规格书产生完整的用例文档，将极大的方便建立系统集成测试的测试用例。

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

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