关于精准测试左移设计方案的思考

每天进步一点点，关注我们哦，每天分享测试技术文章

本文章出自【码同学软件测试】

码同学公众号：自动化软件测试，领取资料可加：magetest

码同学抖音号：小码哥聊软件测试

背景：最近团队在和业务线一起共建精准测试，以提效和能力升级为目标，把回归测效率提升上去，借着这个机会机梳理了对精准测试的认识。

01测试左移

在讨论测试未来发展的过程中，经常被提到的一个点就是测试左移。那么什么是测试左移，左移什么？本文从工程效率的角度，借着《不测的秘密：精准测试之路》这本书的引发的思考，浅析一下测试左移，以及精准回归。

在说测试左移之前，先说一下现实的质量要求和测试成本之间的矛盾，现实情况中经常会遇到的一个场景，测试需求变更频繁，交付问题多，测试被催促。这样的背景下，大家已经慢慢对需求变更习以为常，延迟开发计划，压缩测试时间，测试效率还能提高吗？

测试左移本质上是要尽早的发现，预防问题，使用必要的测试手段在软件开发周期的早些阶段发现问题。

有个Global的效能和质量分析图，图上分别介绍了软件开发的5个阶段：

Coding(编码)
Unit Test(单元测试)
Function Test(功能测试)
System Test(系统集成测试)
Release(集成测试)

可以看到，大部分的问题在编码阶段引入，而几乎很少在编码阶段发现

在集成阶段发现问题的修复成本是编码阶段修复成本的40倍！造成修复成本高的原因有几类：

出现一个线上问题，如何定位，多团队如何配合，如何确定根因？
免费领取码同学软件测试课程笔记+超多学习资料+完整视频+面试题，可加微信：magetest
线上问题，集成问题牵扯到多个模块，如何复现？如何模拟真实环境？多线程的场景？
如何确定修复方案，谁来修，临时方案还是长久，是否是架构问题，多个模块都需要修复会增加再一次间接引入问题成本，修复会不会引入其他问题？

从不重视代码质量的第一天开始，就埋下了问题修复，定位的成本和修复问题再次引入问题的成本。所以需要测试左移，左移，需要一个重要的基础，工程习惯，SDLC成熟度，测试分层，持续集成，链路上延展发布的节奏，纵深上需要贴合业务的专精领域的深度探索，代码扫描（规范，问题，安全，异常等），CR，代码提交行为分析，test double（mock ， fake， stub，dummy）， UT，自动化，验收测试等。

如何左移？

1、代码扫描，单元测试，发现问题不是关键，关键是在质量意识的生态闭环中，不断减少存量问题，进而不断减少问题的发生。可以引入javacoco做单元测试覆盖率统计