做底层软硬件测试的人员都有这样的切身体会,硬件资源总是有限的,经常出现这2种场景:一种在研发试制阶段硬件单板很少(担心改板),经常1个单板多个部门间进行流动;后期版本发布上网后,自动化工厂测试用例的持续增加,原有自动化硬件物料无法在规定时间完成全量的自动化测试(当然笔者也遇到敢投入的主管,产品发布市场1年,在网存量硬件数量还没有实验室的多^-^);总之随着软件特性的不断迭代,自动化用例的规模不断增加,而硬件资源的增加总是缓慢的,要在规定时间完成全量的版本发布,需要新的解决方案。本文就从介绍一种解决方案,供自动化工厂运维的朋友们借鉴。
首先介绍下我们自动化的大体框架和逻辑:
- 用例管理服务器:存放测试用例和测试脚本,其中测试用例中有对环境约束配置;
- 用例调度层:并行分发测试用例到各个执行机,一般都采用云化的可灵活扩展的分布是架构,解决上层并发调度的问题;
- 执行机:各个执行机在逻辑的环境资源池中抢占满足用例需求的资源进行执行;
- 环境逻辑层:多个物理环境抽象为满足测试用例的环境(包含:设备,接口,连线等信息),1个逻辑环境可以由1到 N个物理环境组成。
- 物理层:抽象描述具体的物理环境供逻辑TOP使用;
从上面架构和说明中,可以看到在海量用例执行中,由于物理层受硬件研发进度或者项目经费原因不能及时扩容,就经常造成用例无法在规定时间完成。如我们部门所在领域需要1万+用例在12个小时内完成版本验证,发现问题的环境用于二天开发分析调度,或者自动化开发人员开发新的自动化用例,经过初步分析这1万+用例大概需要的环境情况如下:
用例数 | 一个用例平均 执行时长(分钟) | 可测试时间(分钟) | 需要并行可执行环境数 |
10068 | 3 | 600 | 6 |
注:由于部分用例需要多个环境才能验证,实际需要物理环境还大于6,这里只是举例说明.
在物理环境无法增加的情况下,测试时间也不能大幅增加下,可以采用优化单个用例执行时间或者一个物理环境中可以并行执行多个用例的方法解决,经过分析发现优化单个用例执行时间,需要投入大量人力花费数周才可能优化上线,并不能满足项目交付的需求。
那么在短时间内要达成物理环境不增加测试时间不显著增加,就只能从1个物理环境中能否同时执行多个用例出发来分析了。问题就变成哪些用例可以在相同物理环境执行而相互不影响进行分析,顺着这个思路,我们可以把用例分为2类,必须独占环境串行执行用例和可以并行执行用例,这两类用例大致说明如下:
- 串行用例:主要是对设备进行复位,上下电,设置信息可能影响其他用例的用例。
- 并行用例:特性完全解藕,并行执行中无相互影响的用例。
用例进行了分类,那我们在调度策略中就先执行串行用例,用例全部执行完成在执行并行用例,就可以提高测试执行时间了。
提高执行效率的思路有了,在实际配置中如何让物理环境上执行并行,这时可以在物理层和环境逻辑层进行复制来解决,注意在调度时,串行执行环境只选择一份原始环境TOP,只在调度并行执行阶段选择COPY出来的环境,优化后的用例构架效果如下:
注意红色的框,只是在软件配置逻辑中增加了一个虚拟的物理环境(如:物理环境2_COPY和物理环境2是对应同一套物理环境,及:具有相同的IP,板卡等信息),进而实现了环境的扩容。
同样测试规模用例,都需要在12小时完成执行,进行并行优化调度后,需要物理环境资源对比,优化前需要6套环境:
用例数 | 一个用例平均执行时长(分钟) | 可测试时间(分钟) | 需要环境数 |
10068 | 3 | 600 | 6 |
优化后只需要3套环境:
串行用例 | 可并行用例 | 一个用例平均执行时长(分钟) | 可测试时间(分钟) | 需要环境数 |
230 | 9838 | 3 | 600 | 3 |
再次总结下,在物理资源环境不增加的情况下,优化海量用例执行时间的思路:
- 优化用例执行时间:这里可以从优化每个用例执行入手,也可以从整个测试框架入手节省调度时间考虑。
- 在1个物理环境中同时执行多个用例:这里对用例的分析和分类很重要,要能快速分析出来哪些用例可以并发执行。