【集成测试】

业界对集成测试有一定的定义，这里主要讲下我对集成测试的理解。集成测试主要是把模块，代码片段衔接起来的测试。在阿里巴巴核心系统，从代码可行性出发，也是从业务的角度设计集成测试的用例，也是集成测试的用例主要是面向业务的。
【反对者】
不管啥东西，肯定都有反对的声音的，目前主要的反对的声音有：
1、维护难，维护成本较高
2、集成测试的成果怎么评估。
3、集成构建时间长，开发不容易专注。
在互联网上也有人（如：J.B. Rainsberger）说集成测试是一个阴谋。
【集成测试解决方案】
为此，近有同学组织了专门针对集成测试执行问题的讨论。以下是会议纪要，我大致整理下，红色字体是我的一些补充及观点。
1、集成测试做什么、目的？
集成测试是一种基于测试用例，业务驱动的自动化测试方法；通过与单元测试合理分工，解决单元测试、集成测试边界不清、占比少、单元测试因对数据库依赖、加载spring时运行时间过长的问题。【基本靠谱，但是好不要脱离集成测试的本质思想，他是集成各个系统的各个模块，各个代码片段的。当然可以针对业务场景，业务用例case来实现】
2、价值在哪里？【以下总结还行的，其实以前是缺乏集成测试的，或者没有好的指导方法。】
1）减少手工测试执行比，实现代码质量的短反馈；【可以自动】
2）测试人员提前介入测试；
3）界定单元测试、集成测试边界；
4）解决UI自动化运行慢、不稳定、对环境依赖性强的问题；
5）可在项目结束后持续集成、对代码重构、代码核心业务功能的正常、稳定运行提供质量保证；
6）测试代码的可读性强；
7）在编码过程中，发现代码不可测或难于测试，提高业务代码的可测性；
3、开发、测试如何协同？【其实在很多的公司，如google，开发对系统的质量负有全部责任的。测试同学更多是提供一种测试的支持，测试更多是一个角色，不是一个岗位，阿里目前部分团队还是有专门的测试同学的，导致开发很大程度上面把系统的质量交给测试了。】
1）开发同学对集成测试代码进行codeReview;
2）通过协商，使单元测试、集成测试实现合理分工，避免重复测试、无效测试；
3）开发同学的设计文档中，对接近web层代码、service层接口详细描述，并说明相关的交互场景、交互流程；
4）开发同学协助测试人员搭建集成测试框架，重点包括：子工程目录设计、antx.properties文件、intergration.xml文件、pom.xml文件等相关配置文件；
4、集成测试可行性参考因素【集成测试本身是没有问题，关键在于测试的用例设计，不要把case设计得过于细，对于一些user story，case比较多，是可以考虑把部分的case放到单元测试实现，个人感觉对于一个user story的case，4个用在集成测试下，应该是比较好的。user story的case比较多，那是否考虑，user story的合理性了。关于与单元测试的关系，单元测试主要关注代码片段的逻辑。更本不存在与单元测试重复的问题， 如果重复也应该是单元测试写的有问题。】
1）对核心、稳定（业务相对稳定）功能进行集成测试；
2）不与现有单元测试覆盖功能重复；
3）能减少手工测试执行时间、缩短项目周期；
5、会不会延长项目周期【此点在前期，框架不完善、测试开发对此不熟悉的情况下，还是可能会增加项目的工时的，但是等测试已经形成一定的规模后，还是可缩短测试时间的，特别是一些底层框架的升级，基本不需要测试手工运行测试了。】
     不会，QA提前介入、减少手工回归测试范围；
6、代码编写、维护成本如何减少？【当然第一靠case的质量，第二看开发者的抽象的能力，第三靠框架了。】
框架优化，公司目前有专门的框架支持的。


以上基本可以回答反对者的担心的问题了，还有一点是集成测试构建时间的问题，对于单个case，可能需要几分钟，此点可以通过框架层解决。如：延迟加载等技术。对于测试集成慢，可以分阶段集成，可以参考‘参考资料’。
【再此思考】
我们还是记住测试的黄金三角图形，单元测试是保证代码片段的质量的。集成测试主要以业务case的角度来编写测试的，保障核心的业务功能。希望能通过自动化的集成测试，减少测试的手工测试成本。关于验收测试，基本是客户体验，PD验证了，此主要是通过手工验证的。
后强调地是集成测试也并非银弹，没有一种实践能解决所有的问题，必须合理把一些实践合理地分工，才能解决大部分问题。