单元测试（转）

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）不与现有单元测试覆盖功能重复；

3）能减少手工测试执行时间、缩短项目周期；

5、会不会延长项目周期【此点在前期，框架不完善、测试开发对此不熟悉的情况下，还是可能会增加项目的工时的，但是等测试已经形成一定的规模后，还是可缩短测试时间的，特别是一些底层框架的升级，基本不需要测试手工运行测试了。】

     不会，QA提前介入、减少手工回归测试范围；

6、代码编写、维护成本如何减少？【当然第一靠case的质量，第二看开发者的抽象的能力，第三靠框架了。】

框架优化,公司目前有专门的框架支持的。

以上基本可以回答反对者的担心的问题了，还有一点就是集成测试构建时间的问题，对于单个case，可能需要几分钟，此点可以通过框架层解决。如：延迟加载等技术。对于测试集成慢，可以分阶段集成，可以参考‘参考资料’。

【再此思考】

我们还是记住测试的黄金三角图形，单元测试是保证代码片段的质量的。集成测试主要以业务case的角度来编写测试的，保障核心的业务功能。希望能通过自动化的集成测试，减少测试的手工测试成本。关于验收测试，基本是客户体验，PD验证了，此主要是通过手工验证的。

最后强调地是集成测试也并非银弹，没有一种实践能解决所有的问题，必须合理把一些实践合理地分工，才能解决大部分问题。

【参考资料】

集成测试是一个阴谋：http://www.infoq.com/cn/news/2009/04/jbrains-integration-test-scam

持续集成之“测试三角形与分段构建策略原则”：http://www.infoq.com/cn/news/2011/02/ci-test-triangle

Continuous Integration (original version):http://www.martinfowler.com/articles/originalContinuousIntegration.html

Continuous Integration:http://martinfowler.com/articles/continuousIntegration.html