前面两篇笔记我介绍了自动化测试前期调研注意事项和前置准备阶段切入点,有同学在后台提问:“做完前期的调研和准备工作,领导要求写一个落地方案并评审,自动化测试的落地方案该怎么写”?
首先这个要求我觉得挺正常,一方面评审可以查漏补缺完善细节,另一方面也可以考察具体的落地经验和能力。其次,我认为技术方案其实有个通用的模版,或者说抽象的经验参考,这也是本篇文章我想聊的话题。
结合个人的工作实践和思考,我认为构成一个技术方案,有如下五点要素:
下面的内容,我会从上述五点要素来展开说明。
首先,在编写技术方案的时候,第一也是最重要的一点,一定要阐述清楚项目背景或当前现状。我发现很多同学有所谓的技术偏执,遇到问题第一反应是解决问题,拿着锤子满世界都是钉子。
但其实,我更建议在遇到问题时,首先应该考虑如下几点:
这样思考问题的好处在于:
那如果要落地自动化测试,背景或者说现状怎么写呢?可以参考如下例子:
如上例子仅供参考,阐述背景的原因在于体现当前面临的问题,以便引出后续的解决方案,这是有的放矢。
上面列举了三条例子,从中可以发现,当前的现状带来了哪些痛点和挑战。总结如下:
还记得之前我在软件工程的文章中提到的质量三要素吗?他们分别是时间+范围+成本。
当然,日常工作中还有可能有其他痛点,比如测试用例中很多前置动作都是重复性场景,比如日常测试效率不高需要提高测试过程效率,再比如测试团队的技术建设等原因。
列举痛点和挑战的目的在于,即承接了上面的现状和问题,又可以为后续的技术方案铺路,整体逻辑要清晰合理。
阐述了现状背景,列举了痛点挑战后,接下来就是要说明通过什么方式来解决这些问题,这就是落地方案。一般在编写技术方案时,我个人的经验是如下几点必须重点说明:
技术方案编写完成后,一定要拉上领导和相关同学以及配合方进行评审。一方面是查漏补缺,另一方面也体现出自己的专业能力,当然有的时候最好能和协作团队达成利益一致,这样可以获得更好的支持配合。
具体的落地方案评审结束,接下来就要重点聊聊项目产出和价值了。
产出决定了你的工作量,价值决定了你的KPI和年终绩效,因此这点还是很有必要重点说明的。当然,衡量产出和价值,一定需要具体的可量化的指标,否则无法量化的东西无法谈价值。
以自动化测试为例,我个人的观点是基于实际的目的出发来制定度量指标。举例:
自动化测试目的 | 细分类型 | 度量指标 | 如何度量 |
---|---|---|---|
效率 | 造数据效率 | 每周造数条数平均造数耗时造数任务调用量 | 和手动造数耗时对比 |
冒烟测试效率 | 冒烟执行耗时 | 和手动冒烟测试耗时对比 | |
线上回归效率 | 回归执行耗时 | 和手动回归测试耗时对比 | |
覆盖率 | 接口覆盖率 | P0/P1接口覆盖率总体接口覆盖率 | 梳理核心接口,投入最多资源精力 |
用例覆盖率 | P0case覆盖率P1case覆盖率 | 梳理核心case,投入最多资源精力 | |
业务场景覆盖率 | 正向场景覆盖率逆向场景覆盖率核心场景覆盖率 | 根据业务场景,case by case度量 | |
过程质量 | 构建执行成功率 | 自动化任务执行成功率 | 低于某个阈值判定脚本质量不通过 |
用例执行通过率 | 自动化case执行成功率 | 低于某个阈值判定提测质量不通过 |
和手动造数耗时对比冒烟测试效率冒烟执行耗时和手动冒烟测试耗时对比线上回归效率回归执行耗时和手动回归测试耗时对比覆盖率接口覆盖率
梳理核心接口,投入最多资源精力用例覆盖率
梳理核心case,投入最多资源精力业务场景覆盖率
根据业务场景,case by case度量过程质量构建执行成功率自动化任务执行成功率低于某个阈值判定脚本质量不通过用例执行通过率自动化case执行成功率低于某个阈值判定提测质量不通过
制定度量指标时,建议遵循如下几点:
聊完产出和价值,方案基本就算完成了,但为了锦上添花,大家可以考虑阐述自己对于项目的总体规划和构思。比如:
有句话我觉得说的挺对的,惠而不费的话要多说&事要多做。
关于自动化的技术笔记,到这里就整理完了。
后续我会更新关于性能测试的一些技术笔记,大家敬请期待。