今日收到一位测试经理的问题如下:
晓南老师,最近做测试遇到了2个困惑点。
困惑一,当前测试都是底座替换类,如数据库、中间件的替换,开发分析影响范围就是全量,但是其实全量是浪费的,如何精准是一个问题。
第二个困惑,在这种底座替换测试中,是没有业务类需求的,我们对于业务功能的测试如果积累的资产少自动化也少,对比测试也无法覆盖全部场景,有没有什么好办法~
我觉得这俩问题很好,覆盖了回归测试中的一些典型痛点。为了更好的回答问题,我写了这篇文章,刘冉老师对此文的内容产出亦有贡献。
理想方案:结合代码影响范围和业务优先级的全量测试
都是底座替换类,确实影响范围是全量的,但是全量并不代表全都重要,可以结合底座和业务的耦合程度,根据集成点来分析功能回归的优先级,针对不同优先级来进行不同程度的分层回归。
理想情况是结合代码影响范围和业务优先级来综合评估。
代码影响范围:由开发出具代码变更多功能模块的影响分析矩阵(Impact Analysis Matrix),如果说所有代码全都影响,优先级一样,这就是无效的分析,需要给出有效的分析结果。可以通过 code diff 或 code dependency 的工具来自动生成影响范围结果。
业务优先级:由业务/产品和测试一起出具业务场景的优先级列表,针对不同优先级来分层测试。
如果很清楚集成点,可以根据集成点的优先级来定回归策略。
如果很难分析清楚集成点,就可以参考日常回归优先级策略,比如核心主流程的 happy path, sad path, exception path 全回归,其他选择性回归。
另外注意日常积累测试用例,如果不是自动化的,至少也需要有基于业务优先级的用例积累。
退一步讲,就算没有底层的变化,我们也应该有一些常规的冒烟测试、健壮性测试、业务关键路径测试,这与底层变不变是解耦的。可以在日常多积累这些测试点,重复执行多了也比较容易自动化。
现实方案:由测试和研发共同出具可行的回归范围
有经验的同学应该发现理想方案的问题了。
首先,研发很难给出全量的代码变更影响范围。这个范围会受到各种因素的影响,如技术架构实现、技术栈选型、代码分析工具等等,有的技术栈支持给出部分影响范围,有的则不支持。
结论是哪怕在各种因素都积极的情况下,研发也只能给出部分的代码变更影响范围。测试同学要充分理解这一现实约束。
好了,我们可以接受研发给出部分代码变更影响范围,而不是全量影响范围。那么业务优先级就能在短期内由业务/产品和测试快速确定下来吗?
但凡有跨角色协作经验的同学都知道大概率定不了,因为业务优先级的确定周期会无限延长,尤其在没有业务积累的场景下,这几乎是不可能完成的任务。
所以业务优先级这一部分也会打折,比较现实可行的方法是,由资深的测试同学出具基于业务优先级的回归用例集合,应包含核心业务场景的全量回归和其他典型的回归测试集合。
最终能落地的方案是:
- 回归范围:研发给出的部分代码变更影响范围 + 测试给出的基于业务优先级的回归范围,这两个集合取并集。
- 多方共识:产研测就这一回归范围达成共识,由于现实约束,理想方案折中执行,我们共同承担质量职责和风险。
关于采用什么测试方法和工具,契约测试、接口测试、UI自动化,这些都是在确定方案之后的实现途径,在此不做过多展开了。
关于缺乏业务用例的积累,除了一点一滴积累以外,没有什么捷径。如果之前毫无积累可供参考,就从现在马上开始积累。
额外想说的
偿还技术债:这类问题产生的背后原因往往是架构设计问题,如系统前后端不分离的大单体架构;同时由于架构缺陷,很难低成本自动化,以至于持续缺乏自动化测试。这时由于痛点明显,是投资技术债管理的合适时机。
可尝试引入AI:AI在IT领域的一个应用场景是遗留代码重构,成本和企业内部条件允许的话,可以尝试引用AI做重构后的影响范围分析,因为以往由于人力受限产生的约束,对于AI来说可能并不存在。只是我们对效果不要报以过高期望就好。
多方合作共赢:这个例子充分体现了团队全员对质量负责的理念,一旦多方开始责任共担,那么彼此的风险都会降低。
“其实团队全员对质量负责的理论基础是博弈论。” ——刘冉