基准回归包含中介变量吗基准回归检验

转载

doscommand 2024-08-05 09:08:40

文章标签 基准回归包含中介变量吗测试配置管理 java 优化 文章分类 机器学习人工智能

在大家的常识中，回归测试在范围的选择上，有如下四种方法：

测试全部用例——选择基线测试用例库中的全部测试用例，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高；
基于风险选择测试——可以基于一定的风险标准来从基线测试用例库中选择回归测试；
基于操作剖面选择测试——如果基线测试用例库的测试用例是基于软件操作剖面开发的，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障；
再测试修改的部分——当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。

我前一段时间在微博里发了一个号称“回归测试用例自动生成器”的设计图（如下），核心思路就是通过配置管理工具对版本差异的扫描来获取改动的文件，通过用代码扫描工具对改动文件的扫描得到改动的内容，再通过这些改动的内容扫描出关键字：

SP：cursor、function、procedure……
JAVA：method、interface、class、DAO、DTO……

最后通过这些关键字和系统功能点、回归测试用例库中的测试用例，这三者的映射关系来精确的找到每次移交之后所要进行的关联测试。其实后来经过大家的讨论，发现这种构思叫“回归测试范围界定选择器”更加合适，用“生成”二字有点歧义。我自己也没有想清楚到底如何实现，需要关注哪些问题，但是我做这种设想的理由很简单：

我厌倦了每次版本最后一次移交之后都需要的全面回归测试，这是一种无耻的浪费；
我厌倦了这种“瞎蒙”式的回归测试，不精确，而且所谓的全面回归也无法避免测试遗漏；
我不相信在没有足够的时间的情况下，所谓的回归测试剪裁，所谓基于风险的评估是无法保证规避一些重要的测试遗漏的；
我不相信coder兄弟们告诉我的，他们基于本次版本所有需求所修改的内容，因为他们其中个别人往往会稍带着做一些自认为“无伤大雅的优化”；
我憎恨任何一个把前期测试没有尽力却在出了测试遗漏的时候把责任推给回归测试的人，开发人员也好、测试人员也罢；

当然，这些只是我个人主观上的认知倾向，貌似我应该用更有说服力的数据来说明我这么思考和想做这件事情的理由，那么不妨让我算一笔账给大家看看：

前提：自动化开发和维护的成本撇开不算，因为有没有这个构思，自动化测试开发和维护都必须要做；
按照目前Selenium/WebDriver的自动化回归测试脚本的粒度算，假设一个系统平均Web页面回归测试用例1000个，其中80%是自动化的，20%是手动的；
这1000个Web页面测试Case的执行，总计约消耗12.67小时，其中人力是7人时：

受限与应用逻辑和环境效率，自动化平均每个可能要30s（现阶段全部门实际是100+，后续必须组织系统的优化），1000*80%*30=6.67小时；
手动的平均每个可能要执行1分钟到2分钟，按平均1分半计算：1000*20%*90=5小时；
自动化测试执行的6.67小时是机器时间，而我们需要关注和分析结果，同时硬件资源消耗在测试范围没有优化的情况下需要投入更多，这里将硬件资源的多余耗费也计入人力成本，则人力的总耗费大约为1.5+0.5=2小时；

参照历史数据，实际上每个版本涉及的改动功能点和分支，只是整个系统功能点的10%不到，大家可以自己回顾思考一下有没有超过这个比例的；
用10%的改动点，假设我们将回归测试用例挑选这件事情分三个步骤来做：

第一阶段：映射关系很粗糙，甚至只扫描到JAVA的独立文件和SP的独立文件，那么10%的改动点应该平均对应最多不过30%的回归测试用例的执行需求；
第二阶段：映射关系细化一层，JAVA改动点细化到.do/.screen，SP改动点细化到procedure，那么10%的改动点可能只涉及20%的回归测试用例的执行需求；
第三阶段：精确映射，加上关联影响的延伸，10%的改动点可能只会涉及15%左右的回归测试用例的执行需求；