在我们的工作中,为了提高测试效率或者做出测试团队的业绩来,都不得不做很多的自动化,当然这包括测试环境搭建,测试数据构造,测试执行,压力及安全测试等等,但是在各个阶段中,应该怎么样做好自动化满足我们的业务发展需要呢?今天主要谈谈单元和集成测试。
自动化投入产出比
一个被简化的公式:
自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
或者如果假设迭代次数和维护次数近视相等,这个在某些情况下可以成立,比如一个比较新的产品:
自动化的收益 = 迭代次数 * (全手动执行成本 - 维护成本) - 首次自动化成本
对此公式,我们可以解读一下:
自动化的收益与迭代次数成正比;
自动化收益可能为负,即维护成本和首次自动化成本比全手工执行成本还高的时候;
很多时候首次自动化成本并不比手工测试成本高,但是维护成本很高.
实际上,这个公式的确被简化了,原因是只是关注了其付出的时间,忽略了带来的效果,比如给项目周期缩短上带来的成效,对于质量保障的成效等等,对于项目周期上的评判则可以用以下公式:
缩短周期=手工测试时间-自动化测试时间
而且该周期都是针对同一个已经被自动化的模块评估的.
此外,很多时候我们关注自动化对于质量的贡献时,都是关注其发现了多少个bug,实际上自动化并不能帮我们发现更多的bug,都只是在原先预先设定好的程序上重复执行,所以根本不可能做到100%的自动化,测试人员的经验,逻辑判断和探索性的测试方法都不能被有效自动化.
什么样的项目适合做自动化?
通过上面的公式也可以看出:
一个快速发展,变更频繁的项目不适合做过多的自动化,而处于后期维护阶段,自动化收益会更高;
对于接口类的产品;
手工测试非常费时费力,甚至无法达到测试目的的项目,比如对于大数据量大并发下的压力测试等.
什么时候介入?
如果对于早期,开发设计还未稳定,界面还会经常变化,接口还未明确的情况下,是不适合做自动化的,即使做了,也会频繁的修改,这个时候手工测试可能效率更高,能快速发现问题反馈给开发人员.而如果有了稳定的界面,明确的接口设计,明确的数据结构之后,自动化再介入可以自动化收益.
今天我们重点介绍一下单元测试,集成测试部分.
谁来写单元测试
在一个软件工程团队里,的确没有必要明确到底应该谁来写,比较好的做法是依据团队人员配置而定.单元测试普遍采用白盒测试的方法,离不开深入理解被测对象的代码,同时还需要构造驱动模块、桩函数,因此开展单元测试需要较好的开发知识。从人员的知识结构、对代码的熟悉程度考虑,开发人员具有一定的优势,其最大的优点是快速,且能更好的实现。
但是从单元测试效果的角度考虑,保证测试组参与单元测试也有其优势,这是因为:
首先,从目前国内企业普遍现状来看,测试人员质量意识要高于开发人员,测试人员参与单元测试能够提高测试质量。
其次,对被测系统越了解,测试才有可能越深入,测试人员参与单元测试,将使得测试人员能够从代码级熟悉被测系统,这对测试组后期集成测试和系统测试活动非常有帮助,可以很快速的评估影响范围,进而可以非常准确的制定回归测试策略,而不用满盘回归.
测试组以何种方式参与单元测试,应该结合人员配置情况来定。如果软件组织测试资源充分,测试人员对开发人员的比例较高,那么可以由测试人员独立承担部分重要模块的单元测试工作,比如微软这样的公司,开发测试比1:1,那么测试人员就需要进行较为充分的单元测试;如果测试资源不足,测试人员对开发人员的比例较低,那么单元测试的实现和执行由开发人员来完成,但测试组至少应该参与开发组的各相关设计文档评审,以及code review保证质量。
单元测试的现状
可以把这种现状结合业务情况来看分为两种:
1)在业务快速发展迭代频繁的团队,追求高覆盖的单元测试是一件奢侈而且不可取的事情,毕竟把单元测试做好的话可能需要写比开发代码还要多的测试代码,这就需要持续的投入,包括人力和时间上,这也就是为什么微软有那么多测试同学的原因,对于传统软件而言可能值得这样的投入,也就是软件测试工程中的正三角模型。
2)而互联网时代,短平快是赢得市场的重要理念,为了获得快速的迭代,大家都没有过度的追求单元测试的覆盖率,但是我了解到在百度一些产品线,迭代并不频繁的项目,还是有强制要求对单元测试的覆盖率的,不达到标准是需要打回给开发继续完善单测的,但是我们大多数公司要么是开发一点都不做或者做的不够好,我想这是目前的窘况,这也给我们测试工作量带来了很大的压力,经常会为了项目按期上线加班加点做回归。同时,也有些公司在区分单元测试和集成测试策略和范围时就比较模糊,本应该单元测试解决的放到集成测试了,甚至是单元测试就按照集成测试的思路来做的,包含了很多业务很细的case,那么就成立下面这种情况,而且更多的就是这样的现状:
单元和集成测试并行开展
单元测试更侧重于逻辑代码片段,粒度更细,可能不同的开发人员各自写自己那部分的方法,自己做方法的单元测试,若需要调用别人代码或被调用时,就自己写桩或者驱动函数,把对应的内容mock掉。单元测试不应该关注上层侧重业务的case,也就是说每个user story应该只有少量的case用来做集成测试,把更细粒度的case应该放到单元测试中去做,这样可以避免单元测试和集成测试的重复性工作,为了达到这样很好的组合,就需要开发与测试同学密切配合,提前设计好产品并有文档化的设计资料。如果单元测试和集成测试能很好的区分并且履行好各自职责的话,这对于产品的质量一定能带来非常积极的作用。
那问题来了:
1)这样会不会延长项目周期呢?
在前期,框架不完善,大家对项目都不熟悉的情况下,要想做起来,必然会增加一定工期的,但是在各方面都比较成熟之后,特别是自动化case达到一定量之后,就会缩短项目工期。
2)如果单元测试开展的不够好怎么办?
我想,在目前大多数互联网公司,甚少有把单元测试做的好的,并且迫于较低的测试开发比,测试人员根本没有精力来做单元测试,那在这种情况下,测试人员要想进一步保证代码质量的话,就只有通过设计评审,静态代码扫描和code reivew来保证方法的质量,而测试人员可以把精力放到集成测试或接口测试上,只不过这个时候集成测试就需要把更多更细的case包含进去。
面对现实,随机应变
最后我们不得不无奈的面对现实,如果真的没办法实现正三角形模型的测试架构的话,也不用过于学术化非要按照模型来做,但我们也要竭力避免让系统测试成为我们最大的工作量和包袱。应Google的一句话,大意是当软件产品没有bug的时候,说明它发布的晚了。这也指我们对于产品质量所做的一定妥协,为了业务快速往前,我们何不因此而变呢?
文章同步发布在我的个人博客:www.oktest.me上,可点击进入查看,同时收录全网海量测试相关文章,欢迎阅读。
如果觉得《论新时代软件测试人员的工作之道(四)自动化测试之单元及集成测试》对你有帮助,请点赞、收藏,并留下你的观点哦!