扫码阅读
手机扫码阅读
自动化测试技术笔记(二):准备工作的切入点
241 2023-08-25
测试环境选择和搭建
测试框架选型和设计
自动化测试类型:UI/API/UNIT,UI自动化要考虑web和移动端的区别,单元测试要考虑被测系统的开发语言; 框架自身的生态:框架支持的编程语言、社区活跃度、文档是否齐全、业内落地案例、测试同学自身的技术栈; 框架的学习成本:不能只考虑选择个人熟悉的,还要考虑后续的多人协同,团队其他同学的学习上手难度; 框架的维护成本:后期case多了或业务场景变更后,case的维护成本以及框架本身是否提供了更好的封装模块;
测试脚本和数据管理
测试范围和校验粒度
持续集成和测试报告
执行的频次和效率:比如1天可以执行100个功能case,那自动化最起码要在10分钟甚至1分钟内完成; 执行结果自动校验:功能测试可以人工来判断测试是否通过,自动化测试的通过率&成功率需要达到一定的成功率(比如90%以上),且失败的case可以重试验证,或者失败的结果和日志及时通知给相关人员; 无人值守自动运行:这点其实很多方法可以实现,比如定时任务,条件触发。当然做到这点还算不上自动化,必须考虑到如果出现重大问题还需要及时的发现和告警通知; 是否融入交付流水线:交付流水线即我们今天常说的CICD或者devops流水线,常见的场景有服务打包编译后的自动化单元测试,服务自动发布后的接口自动化和UI自动化测试,以及服务上线前和上线后的自动化冒烟和回归测试,甚至还可以加入线上的日常自动化巡检。
外部调用和多人协作
挡板&mock(最常用的手段); 流量染色+影子库(实现成本较大,技术复杂性较高); 和三方协商一致后配置专门的白名单或者渠道(很难协商);
测试数据专人统一维护,还是按需维护,提供专门的工具或者流程规范约束; 测试用例和测试脚本的维护,各管各的还是提供统一的规范demo,专人检查或者定时review; 测试范围的边界如何界定,重合部分如何区分职责;
原文链接:
http://mp.weixin.qq.com/s?__biz=Mzg2NDAwMjM1NQ==&mid=2247486448&idx=1&sn=80b7b1411a22044342f86022eb1a21c2&chksm=ce7143acf906cabaeed5e5d86cee4c446f1b30b7401d68c1c2a42ab4974b919aaed67a91538f#rd
老张的求知思考世界的其他文章
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线