如何有效选择回归测试用例集

本文讨论一下在回归测试活动中如何选择测试用例集。已知前篇中回归测试用例集包括基本测试用例集原始用例迭代新增测试用例集修复故障引入的用例和新增功能引入的用例集。如假设开发周期D内原始测试用例集为T新增功能引入用例集为ΔT1修复故障引入的用例为ΔT2那么回归测试用例集T’TΔT1ΔT2。说到这里不知道你会不会有这样一个疑问如果我的原始测试用例集T包含大量的测试用例成百上千条难道回归测试时都要全部执行吗答案当然是否定的。首先回归测试是有时间限制的单纯人力执行上千条测试用例是很难完成的。即使有自动化测试的保障也难以保证100%的测试覆盖。因此我们进一步讨论下在原始用例集T中选择合适的测试用例加入回归测试尽量满足最优测试用例最小测试用例的标准。如何在原始用例集中挑选测试用例不妨我们再来设想和讨论几个问题1、某个测试用例在近期测试活动中通过稳定性较差测试结果频繁失败—成功交替那么在设计当次回归测试活动时你是否会考虑或重点关注呢2、某个测试用例已经实现自动化且加入日常CI维护那么在设计当次回归测试活动时你是否会考虑或重点关注呢3、某个测试用例已经长时间未执行那么在设计当次回归测试活动时你是否会考虑或重点关注呢4、某个测试用例最近一段时间内总是失败通过率很低那么设计当次回归测试活动时你是否会考虑或重点关注呢看到这几个问题有什么启发吗在问题1中我们讨论的是测试用例的稳定性在问题2中我们讨论的是测试用例的自动化率在问题3中我们讨论的是测试用例的执行率在问题4中我们讨论的是测试用例的通过率。稳定性、自动化率、执行率和通过率是我们制定测试策略选择测试用例时的重点考虑范围。因此回归测试活动中筛选原始用例集中的用例挑选高优先级用例组建回归测试用例集可以从测试用例的这几方面入手。具体实践考虑测试用例的稳定性、自动化率、时效性和有效性四个方面如果一个用例稳定性低、自动化率低、通过率低、执行率低那么在当次回归测试活动中这个用例可以且应该获得测试人员的关注纳入回归测试用例集中。此外如下表所示当用例稳定性和通过率低时执行率和自动化率则不需重点考虑此时测试用例优先级高应该纳入当次回归测试当用例稳定性和通过率中时低执行率和自动化率的测试用例可以考虑加入当次回归测试具体结论可视测试资源如人力和机器资源和测试时间充裕度考虑当用例稳定性和通过率高时即使用例执行率和自动化率低也不需要加入回归测试。为何制定如此测试策略呢因为对于测试用例的考评稳定性和通过率远大于执行率和自动化率。总结本文在“你真的了解回归测试吗”一文的基础上讲述了如何在原始用例集中筛选测试用例缩减原始用例集的大小组建最优最小用例集的测试策略。值得注意的是所谓的最优最小用例集理论上是不存在的俗话说没有最好只有更好不是么我们做的只是在一定限制内的优化。希望本文能对正在看的你有所启发~最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。