前面两篇笔记我介绍了自动化测试前期调研注意事项和前置准备阶段切入点，有同学在后台提问：
“做完前期的调研和准备工作，领导要求写一个落地方案并评审，自动化测试的落地方案该怎么写”？
首先这个要求我觉得挺正常，一方面评审可以查漏补缺完善细节，另一方面也可以考察具体的落地经验和能力。
其次，我认为技术方案其实有个通用的模版，或者说抽象的经验参考，这也是本篇文章我想聊的话题。
结合个人的工作实践和思考，我认为构成一个技术方案，有如下五点要素：
- 背景现状：当前的业务、技术表现，遇到了什么问题；
- 痛点挑战：这些问题对业务和技术带来了哪些痛点，要解决痛点面临哪些挑战；
- 落地方案：为了解决上述的痛点和挑战，打算从哪些方面用什么手段在什么时间来解决；
- 产出价值：产出是什么，从哪些维度衡量产出，用哪些指标评估问题的解决程度和创造的价值；
- 总体规划：整体规划是什么，短中长期里程碑是什么，要投入哪些资源，需要谁协同配合，对业务和团队价值；
下面的内容，我会从上述五点要素来展开说明。
阐述背景现状
首先，在编写技术方案的时候，第一也是最重要的一点，一定要阐述清楚项目背景或当前现状。
我发现很多同学有所谓的技术偏执，遇到问题第一反应是解决问题，拿着锤子满世界都是钉子。
但其实，我更建议在遇到问题时，首先应该考虑如下几点：
- 当前问题是偶发问题还是频发问题；
- 类似的问题在其他团队/场景是否存在；
- 除了方案A，有没有方案B或者方案C来解决问题；
- 如果不做该方案，当前问题造成的损失是否可以接受；
这样思考问题的好处在于：
- 避免陷入技术陷阱，在低层次挣扎；
- 找到更高维度的解决方案，解决更大更多的问题；
- 降低重复解决低级问题而带来的资源浪费和精力分散；
那如果要落地自动化测试，背景或者说现状怎么写呢？可以参考如下例子：
- 业务范围大，业务场景复杂，每次发版要回归的case太多；
- 业务趋于稳定，但测试时间较少，可能无法发现更多更细节的问题；
- 迭代周期比较快，测试人力资源不足，回归测试无法覆盖更多的场景；
如上例子仅供参考，阐述背景的原因在于体现当前面临的问题，以便引出后续的解决方案，这是有的放矢。
列举痛点挑战
上面列举了三条当前现状的例子，从中可以发现，当前的现状带来了哪些痛点和挑战。总结如下：
- 测试case比较多，回归耗时（时间）；
- 业务稳定但测试时间不足，容易漏侧（质量）；
- 测试人力资源不足，会导致测试时间变长或加班赶工（成本）；
还记得之前我在软件工程的文章中提到的质量三要素吗？他们分别是时间+范围+成本。
当然，日常工作中还有可能有其他痛点，比如测试用例中很多前置动作都是重复性场景，比如日常测试效率不高需要提高测试过程效率，再比如测试团队的技术建设等原因。
列举痛点和挑战的目的在于，即承接了上面的现状和问题，又可以为后续的技术方案铺路，整体逻辑要清晰合理。
说明落地方案
阐述了现状背景，列举了痛点挑战后，接下来就是要说明通过什么方式来解决这些问题，这就是落地方案。
一般在编写技术方案时，我个人的经验是如下几点必须重点说明：
- 技术方案针对的需求或业务范围（比如核心业务，核心服务，高频流程）；
- 技术方案的选型、对比结果和demo效果是否适合当前的团队（成熟稳定的工具+活跃的生态&丰富的文档+简单的上手难度+较低的维护和二次开发成本）；
- 方案落地所需要投入的资源（人力+时间+购买的资源）、需要哪些团队&人协同配合（沟通协作管理成本）；
- 方案落地有哪些关键节点&里程碑（落地步骤1-2-3-4-5，分别在什么时候达成什么效果解决什么问题）；
- 不同里程碑阶段，用哪些指标度量评估问题得到了解决，项目达到了预期效果；
技术方案编写完成后，一定要拉上领导和相关同学以及配合方进行评审。一方面是查漏补缺，另一方面也体现出自己的专业能力，当然有的时候最好能和协作团队达成利益一致，这样可以获得更好的支持配合。
罗列产出价值
具体的落地方案评审结束，接下来就要重点聊聊项目产出和价值了。
产出决定了你的工作量，价值决定了你的KPI和年终绩效，因此这点还是很有必要重点说明的。
当然，衡量产出和价值，一定需要具体的可量化的指标，否则无法量化的东西无法谈价值。
以自动化测试为例，我个人的观点是基于实际的目的出发来制定度量指标。举例：
|
自动化测试目的 |
细分类型 |
度量指标 |
如何度量 |
|
效率 |
造数据效率 |
|
和手动造数耗时对比 |
|
冒烟测试效率 |
冒烟执行耗时 |
和手动冒烟测试耗时对比 |
|
|
线上回归效率 |
回归执行耗时 |
和手动回归测试耗时对比 |
|
|
覆盖率 |
接口覆盖率 |
|
梳理核心接口，投入最多资源精力 |
|
用例覆盖率 |
|
梳理核心case，投入最多资源精力 |
|
|
业务场景覆盖率 |
|
根据业务场景，case by case度量 |
|
|
过程质量 |
构建执行成功率 |
自动化任务执行成功率 |
低于某个阈值判定脚本质量不通过 |
|
用例执行通过率 |
自动化case执行成功率 |
低于某个阈值判定提测质量不通过 |
制定度量指标时，建议遵循如下几点：
- 切忌面向指标/面向KPI做度量；
- 考虑到冗余成本，指标不宜过多；
- 制定指标是为了提升质量，而非做数据；
- 根据做自动化测试的目的来制定度量指标；
- 度量指标对比应该以是否解决了痛点为依据；
- 度量指标是辅助评估依据，并不是唯一正确的结果；
- 制定指标应考虑到哪些指标更实际有效，从解决问题角度出发；
- 度量指标不要单一的评估，应结合多个维度来综合评估开展质量度量；
概括总体规划
聊完产出和价值，方案基本就算完成了，但为了锦上添花，大家可以考虑阐述自己对于项目的总体规划和构思。比如：
- 当前现状是A；
- 第一阶段要达成B效果，解决C问题；
- 未来半年要达到D效果，这样做的好处的E；
- 长期来看，遮掩做对业务和技术团队的价值是F；
有句话我觉得说的挺对的，惠而不费的话要多说&事要多做。
关于自动化的技术笔记，到这里就整理完了。后续我会更新关于性能测试的一些技术笔记，大家敬请期待。
标签：方案,痛点,技术,笔记,指标,测试,编写,度量 From： https://www.cnblogs.com/imyalost/p/16997259.html