http://blog.csdn.net/bxyz1203/article/details/7401205
2012-03-28 00:07
【概念】
说到测试，最主要的是，检测代码是否满足特定的逻辑,检测代码是否满足业务的需求。
测试还需要有一些附加特性，如：快速响应、可重复运行、可持续维护等。目前的测试基本可以分为：
单元测试：检测代码片段的测试，基本是以代码结构为衡量，属于百盒测试。集成测试：集成各个系统的各个模块，各个代码片段的，主要以业务为角度。属于黑盒测试。验收测试：主要是人工页面验证，用户演示，PD验证等，此主要是测试功能是否正确，以业务为出发点。一般是人工进行，比较难进行自动化。
【现状】
单元测试、集成测试、验收测试，三者之间合理的关系如下：
上图是测试的黄金三角，但是我们由于过去自动化测试只是弄了一个概念，叫单元测试，后大家写测试的时候，就弄成了如下的图形了。单元测试写的不成样子，成了一窝粥了。
如果把单元测试中写得像集成测试的抽出来当做集成测试的话，在系统中的测试算得上单元测试的基本没有多少了。那 就成了倒三角了。如下图所示：
疼一：单元测试没有发挥单元测试的作用，写得像集成测试的测试也写得四不像的。维护成本非常高，基本不可维护了。
为此，需要把单元测试中写得像集成测试的case，名正言顺的换了名称，叫做集成测试（不是直接改，做集成测试需要新的方法，这里只是笑谈罢了）。单元测试做好本职的工作，完成代码片段的测试。如果单元测试与集成测试的分工明确，测试代码的可读性也非常高。
疼二：验收测试成本非常高，大量的手工测试，不可重复运行。
【集成测试】此点也需要引入以业务为出发的集成测试，以业务为出发点，减少验收测试的比例。
最终：把我们倒三角，变成正三角。因为集成测试在其中起着非常重要的作用，下面讲下，集成测试的一些讨论及心得，
业界对集成测试有一定的定义，这里主要讲下我对集成测试的理解。集成测试主要是把模块，代码片段衔接起来的测试。在阿里巴巴核心系统，从代码可行性出发，也就是从业务的角度设计集成测试的用例，也就是集成测试的用例主要是面向业务的。
【反对者】
不管啥东西，肯定都有反对的声音的，目前主要的反对的声音有：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）不与现有单元测试覆盖功能重复；5、会不会延长项目周期【 此点在前期，框架不完善、测试开发对此不熟悉的情况下，还是可能会增加项目的工时的，但是等测试已经形成一定的规模后，还是可缩短测试时间的，特别是一些底层框架的升级，基本不需要测试手工运行测试了。】3）能减少手工测试执行时间、缩短项目周期；不会，QA提前介入、减少手工回归测试范围；6、代码编写、维护成本如何减少？【 当然第一靠case的质量，第二看开发者的抽象的能力，第三靠框架了。】框架优化,公司目前有专门的框架支持的。
以上基本可以回答反对者的担心的问题了，还有一点就是集成测试构建时间的问题，对于单个case，可能需要几分钟，此点可以通过框架层解决。如：延迟加载等技术。对于测试集成慢，可以分阶段集成，可以参考‘参考资料’。
【再此思考】
【参考资料】我们还是记住测试的黄金三角图形，单元测试是保证代码片段的质量的。集成测试主要以业务case的角度来编写测试的，保障核心的业务功能。希望能通过自动化的集成测试，减少测试的手工测试成本。关于验收测试，基本是客户体验，PD验证了，此主要是通过手工验证的。最后强调地是集成测试也并非银弹，没有一种实践能解决所有的问题，必须合理把一些实践合理地分工，才能解决大部分问题。
持续集成之“测试三角形与分段构建策略原则”： http://www.infoq.com/cn/news/2011/02/ci-test-triangleContinuous Integration (original version): http://www.martinfowler.com/articles/originalContinuousIntegration.htmlContinuous Integration: http://martinfowler.com/articles/continuousIntegration.html