扫码阅读
手机扫码阅读
自动化测试技术笔记(三):如何编写技术方案
214 2023-08-25
背景现状:当前的业务、技术表现,遇到了什么问题; 痛点挑战:这些问题对业务和技术带来了哪些痛点,要解决痛点面临哪些挑战; 落地方案:为了解决上述的痛点和挑战,打算从哪些方面用什么手段在什么时间来解决; 产出价值:产出是什么,从哪些维度衡量产出,用哪些指标评估问题的解决程度和创造的价值; 总体规划:整体规划是什么,短中长期里程碑是什么,要投入哪些资源,需要谁协同配合,对业务和团队价值;
阐述背景现状
当前问题是偶发问题还是频发问题; 类似的问题在其他团队/场景是否存在; 除了方案A,有没有方案B或者方案C来解决问题; 如果不做该方案,当前问题造成的损失是否可以接受;
避免陷入技术陷阱,在低层次挣扎; 找到更高维度的解决方案,解决更大更多的问题; 降低重复解决低级问题而带来的资源浪费和精力分散;
业务范围大,业务场景复杂,每次发版要回归的case太多; 业务趋于稳定,但测试时间较少,可能无法发现更多更细节的问题; 迭代周期比较快,测试人力资源不足,回归测试无法覆盖更多的场景;
列举痛点挑战
测试case比较多,回归耗时(时间); 业务稳定但测试时间不足,容易漏侧(质量); 测试人力资源不足,会导致测试时间变长或加班赶工(成本);
说明落地方案
技术方案针对的需求或业务范围(比如核心业务,核心服务,高频流程); 技术方案的选型、对比结果和demo效果是否适合当前的团队(成熟稳定的工具+活跃的生态&丰富的文档+简单的上手难度+较低的维护和二次开发成本); 方案落地所需要投入的资源(人力+时间+购买的资源)、需要哪些团队&人协同配合(沟通协作管理成本); 方案落地有哪些关键节点&里程碑(落地步骤1-2-3-4-5,分别在什么时候达成什么效果解决什么问题); 不同里程碑阶段,用哪些指标度量评估问题得到了解决,项目达到了预期效果;
罗列产出价值
|
|||
|
|||
|
|||
|
|||
切忌面向指标/面向KPI做度量; 考虑到冗余成本,指标不宜过多; 制定指标是为了提升质量,而非做数据; 根据做自动化测试的目的来制定度量指标; 度量指标对比应该以是否解决了痛点为依据; 度量指标是辅助评估依据,并不是唯一正确的结果; 制定指标应考虑到哪些指标更实际有效,从解决问题角度出发; 度量指标不要单一的评估,应结合多个维度来综合评估开展质量度量;
概括总体规划
当前现状是A; 第一阶段要达成B效果,解决C问题; 未来半年要达到D效果,这样做的好处的E; 长期来看,遮掩做对业务和技术团队的价值是F;
原文链接:
http://mp.weixin.qq.com/s?__biz=Mzg2NDAwMjM1NQ==&mid=2247486452&idx=1&sn=99ba5f154c546e738f44d156874827aa&chksm=ce7143a8f906cabeda7562fb98d88962bccce30bc48ef054ca81b4a203d69cfc5479671bd9c2#rd
老张的求知思考世界的其他文章
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线