如何设计自动化测试落地方案
翻看之前学习自动化测试时记录的技术笔记，发现写了很多的落地方案文档，正好后台有同学私信问我，该如何设计一个自动化测试的落地方案。这篇文章，分享一下我对于自动化测试落地方案的想法和实践。
一般来说，工作中写这种技术落地方案，原因不外乎下面这几点：
- 技术实践落地，方案本身就是一个指引；
- 文档落地沉淀为知识库，便于其他同学查看学习；
- 梳理落地思路，经过评审才能获得团队和上级认同，进而有资源投入；
从个人经验来说，自动化测试落地方案或者技术方案，主要由下面几点构成。
实施背景和挑战
写技术落地方案时，优先级最高的是交代清楚为什么要做这件事，做这件事能解决什么问题。技术本身是无法直接等于价值的，而是通过技术解决问题才能间接创造价值。且任何技术方案的落地，势必都需要一定的成本投入，如果落地后能解决的问题所创造的价值还不如投入的资源，那这个技术案例就是失败的。
以自动化测试来说，自动化测试的本质是将手动执行的部分让机器或者工具自动执行，通过一定的规则和判断逻辑自动出具结果，提高执行的过程效率。那么自动化测试的落地背景，一定是当前遇到了影响交付效率的问题，比如多版本并行，回归测试范围大，重复内容多；比如业务场景太多，手动造数据太慢；比如有多种版本的兼容性问题，手工验证太慢，需要自动化来提高验证效率。
至于落地需要面临的挑战，常见的如：
- 从0开始建设需要一定的资源投入(人力+时间+实现难度)；
- 需求经常变更，且研发测试交付流程混乱，没有稳定的测试环境；
要明白一点：任何技术方案落地都需要成本投入，技术方案只能解决当前已知的部分问题，要落地可能还需要满足一定的前置条件。考虑清楚这些，再决定是否推进后续工作，而不是有个念头就直接框资源然后开搞，这样往往事倍功半。
技术选型和方案特点
目前业内自动化测试相关的框架和工具很多，成熟的方案也不少，但只有适合自己当前境况的才是最好的方案，而不是哪个知名度最高，哪个有大厂背书就用哪个。在技术选型和调研阶段，重点要考虑如下几点：
- 框架/工具本身的特性(开箱即用、支持多语言、维护成本低、社区生态活跃、有完善的技术文档)；
- 是否有典型的可参考落地案例(比如同类型或者类似的团队落地案例，遇到的问题以及如何解决的)；
- 框架/工具的学习曲线、上手难度、后期维护成本、是否开源和支持二次开发(决定落地推广的成本)；
通过调研选型对比，建议选择1-2个写个demo，这样一方面便于自己对框架/工具更为熟悉，还有一点则是在团队内部进行演示，听取该方案后续的使用者的建议，解答疑惑。同时通过演示可以进一步阐述选择该框架的原因以及优势，便于争取上级支持和资源，以便于更好的落地。
落地方式和关键节点
制定技术方案一定要考虑周全，但在落地过程中还是要注意落地的方式。
首先要避免的是蒙头憋大招，本身现代职场更讲究团队协作，落地技术项目也是为了解决问题。很多当下的问题，如果不能很快的解决，或者短期内没看到解决的希望，可能几个月后这些问题就会演变成其他问题。当你蒙头几个月的大招出来之后，你会发现已经失去了落地的场景，或者被其他方式解决了。
更好的方式则是，将大招拆成比较小的几个目标，以自动化测试来说：刚开始只覆盖核心业务场景的P0场景，先拿到好的结果，然后再扩大覆盖范围，细化case的粒度，直至最终目标。
从产品设计的角度来说，则是小步快跑，做出MVP结果(最小可行性方案)，用好的结果说服团队和上级，扩大覆盖范围，不断改进和优化自动化测试的提效效果。
从项目管理角度来说，则是制定自动化测试的落地里程碑，以及预期的交付时间和交付效果。比如第一周demo跑通，第一个月覆盖主流程P0场景，第二个月覆盖P0+P1场景，提升回归测试效率30%等。
技术落地方案一定要具备的特质：可落地可执行，有明确的落地时间+执行方式+预期结果。
预期效果和长期规划
预期效果很好理解，即不同阶段要交付的产物解决了什么问题，能带来的价值。比如提效30%，比如节省工时，比如降低维护成本等。要明白的一点是预期效果并不是画大饼，而是基于现状和调研的一种预期管理，合理的预期能争取到足够的资源来推动项目的落地。
长期规划即这个技术项目落地后，长期要做什么，能提供什么功能，解决什么问题，对团队能带来什么价值。以自动化测试为例：短期内可能就是提高回归测试的效率，长期来说能做的事情很多。比如：造数据、质量门禁、线上巡检、甚至成为CICD交付流水线的一部分。
腾讯云开发者
