关闭

如果解决测试之痛<特别是单元、集成测试之痛>

315人阅读 评论(0) 收藏 举报
 
【概念】
说到测试,最主要的是,检测代码是否满足特定的逻辑,检测代码是否满足业务的需求。
测试还需要有一些附加特性,如:快速响应、可重复运行、可持续维护等。
目前的测试基本可以分为:
单元测试:检测代码片段的测试,基本是以代码结构为衡量,属于百盒测试。
集成测试:集成各个系统的各个模块,各个代码片段的,主要以业务为角度。属于黑盒测试。
验收测试:主要是人工页面验证,用户演示,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/2011/02/ci-test-triangle
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1853308次
    • 积分:16495
    • 等级:
    • 排名:第614名
    • 原创:29篇
    • 转载:817篇
    • 译文:0篇
    • 评论:147条
    最新评论
    database