落地前：分析因素

从我个人的工作实践经验来看，在决定是否引入新的技术框架或者开展技术项目前，足够详尽的分析调研必不可少。

这样做的好处在于一方面可以避免重复建设；另一方面，尽可能确保投入的资源能获得足够的收益。落地自动化测试之前，主要有如下几点因素需要考量。

1、当前面临的痛点是什么？

引入自动化测试是为了解决工作过程中遇到的问题或痛点，所以在引入之前第一个要考虑的是当前面临的痛点是什么。

比如：线上功能bug频发，人力资源时间不足导致团队加班太多，版本迭代快/多版本并行等，且这些痛点都已经严重影响到了团队的日常工作效率和氛围。

先将面临的问题和痛点列出来，按照影响范围和优先级排序，然后分析背后的原因。

2、痛点背后的原因有哪些？

线上功能bug频发，可能的原因有漏测/case覆盖率不足/需求变更快/发布流程不规范等原因。

人力或者时间不足，背后的原因可能有团队同学能力不足/团队效率不高/管理混乱/缺乏提效手段和工具。

版本迭代快多版本并行的情况，背后的原因就更复杂了，涉及到流程/管理/业务成熟度/企业所处阶段等多种因素。

3、有什么可以解决问题的方案？

分析出团队面临的痛点以及背后的原因，我的建议是将原因列出来进行归类，比如：

资源问题：人手不足/工时评估不合理；

流程问题：研发交付流程混乱，发布不可控；

管理问题：团队效率不高，管理混乱，职责不清；

技术建设问题：缺乏CI/CD工具&需求/代码/case/bug管理工具，团队同学缺乏相关经验；

4、自动化是不是最合适的解决方案？

问题分类和排优先级之后，就是case by case的分析有哪些解决方案了。假设某部分问题可以通过自动化测试来解决或者改善，那就可以着手进行下一步分析。

5、当前的情况是否适合开展自动化测试？

“自动化测试适用于重复度较高的工作，且不是一蹴而就即插即用就能解决问题的。需要相对稳定的业务需求迭代、比较成熟稳定的研发团队和一定的技术基础设施建设，以及较为规范的流程才能更好的落地，达到提效的目的”。

举个例子：某创业公司，当前处于产品初创和快速迭代期，追求的是快速推出MVP产品推向市场，业务不稳定，人力资源紧张，技术基础设施很差，那这个时候是不适合做开展自动化测试的。

开展前：评估价值

罗列问题，分析原因，制定优化方案后，接下来就是项目立项及调研了。自动化测试的调研，主要关注如下几点：

工具框架选型：业内有哪些自动化测试工具或框架？功能是否满足需求？产品稳定性如何？社区活跃度如何？是否有足够详细的说明文档和使用案例。

选定试点范围：选择哪个业务或者团队进行试点？试点对场景覆盖范围和case的粒度要求是什么？

团队成员技术栈匹配度：如果工具需要一定的代码开发，团队成员编码能力如何？对哪种语言熟悉？培训和学习成本？

要投入多少人力时间资源：确定范围和case粒度后，预期需要投入多少人日/工时才能达到预期结果？

预期的投入产出比是多少：投入预期的人日/工时后，预期的效果如何？是否能解决当前面临的痛点问题？

落地过程：解决问题

其实到了研发落地阶段，只需要遇到问题解决问题即可。自动化工具或框架落地过程中，常见的问题有：

学习培训：工具或框架对于团队同学来说需要一定学习成本，建议提供使用说明手册并开展几次培训。

案例演示：其实自动化case或者脚本写起来很简单，但还是建议提供一些demo或者案例，能让其他同学更快速上手。

二次开发：很多开源的自动化工具已经具备了大部分常见功能，但落地过程中还是要解决一些定制化功能，或者修复开源工具的一些bug，这就需要一定的开发能力对工具进行二次开发或者优化。

构建效率：自动化测试并不是拿着工具把case写好就完事了，要考虑到自动化落地的初衷就是解决效率问题，因此落地后的构建执行效率是重点关注的因素。

构建成功率：除了关注构建执行效率，每次构建执行的成功率也要高度关注，否则会耗费大量时间在排查问题上。

推广运营：关注反馈&输出价值

项目落地后，真正的挑战才开始。

假设你是自动化测试落地的负责人，如何让其他团队的测试同学也能很好的用起来，并且真的解决他们的问题？

如何衡量这个项目的投入和产出，用哪些指标度量？关于这点，我建议大家从下面两点去考虑：

业务运营：解决了业务什么痛点，对业务目标达成的促进；

技术运营：用户体验、交付效率、质量提升、用户满意度。

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取