个人自动化实现速度
理想的情况是，工程师的速度应该保持在预期的最小测试用例数和最大测试用例数之间。
如果低于红线，这意味着：
- 工程师被某些问题耽误或阻挡，影响了速度
- 由于业务需要，工程师被抽调到一些其他的工作中，比如维护由于应用程序工作流程的变化而导致的脚本的变化。
- 工程师的表现没有达到其他团队成员的标准，原因是缺乏产品知识或自动化工具知识
- 工程师将无法达到目标。
- 滞后的工程师会给团队中的其他工程师带来过重的负担。
这将有助于管理层：
- 估算工作完成的速度和完成工作所需的时间。
- 分析项目中是否需要增加或减少资源。
- 奖励执行者，培养非执行者，让他们像执行者一样提供服务。
- 关注每个工程师的成长
工程师任务分布
理想情况下，在自动化的初始阶段工程师应该花更多的时间在Framework开发上。，然后在测试用例自动化中。只有在出现以下情况时，才应将时间花在suite的维护上。比如应用功能或工作流程的改变。
如果工程师花更多的时间在其他领域，例如，工程师3的大部分时间都花在了修复同行评审。这意味着工程师3写的代码效率不高。
根据这个图表，管理层可以：
- 根据每个工程师的表现为他们设定目标：
- 利用这些数据来激励工程师，以获得更好的业绩。
自动化覆盖率
这张图可以帮助管理层确定：
- 自动化产品的百分比
- 确定人工测试团队的规模
参考资料
- 本讲座目录
- 本文pdf完整版本下载
- 代码地址 https://github.com/china-testing/python-testing-examples/tree/master/pytest_projects 建议拷贝到浏览器访问
- 本文涉及的python测试开发库 谢谢点赞！
- 本文相关海量书籍下载
自动化进度
如果实际自动化的测试用例数量出现了偏差。可能是：
- 由于其他高度优先的问题，自动化任务被搁置了。
- 团队不能有效地规划各项工作
- 产品存在偏差
该图可以帮助管理层：
- 显示团队的进展情况与预期的时间表相比，以及重新调配资源，按时完成任务
- 为自动化团队制定战略和规划未来的发展方向。
自动化问题的趋势
评估问题的类型，如脚本问题、产品问题等。
理想的情况是，随着项目的进展，总的失败次数应该逐渐减少。这
如果有增加：
- 脚本问题 - 脚本创建需要改进
- 产品问题--应用程序代码不稳定
- 假阳性问题--那么在批处理过程中可能会出现任何不可预见的问题。执行，如定时/等待问题，或环境预设条件问题。
图表可以帮助管理层：
- 信任自动化的结果，并做出发布产品的决定，如果脚本问题和误报率极低
-提高自动化代码质量。
自动化成本分析
理想：理想的情况是，节省的人工劳动量应超过自动化程度。30-50%的增长，以实现积极的投资回报率。
如果未来6个月内节省的人工成本等于或小于的自动化成本，那么该产品或模块就不适合自动化。
测试用例自动化比例
随着时间的推移，测试用例的自动化数量逐渐增加，因为测试用例的自动化数量会随着时间的推移而增加。
如果没有增加这可能是因为：
- 自动化任务因其他高度优先问题而被搁置。
- 团队未能有效规划工作
- 产品存在偏差
这张图可以帮助管理层。
- 判断自动化是否以及如何最适合项目。
- 更好的为自动化团队制定战略和规划未来的路线图。
自动化后节省的工作
理想的情况是：人工逐步下降。
如果没有下降：
- 根据项目要求，自动化团队成员被转移到手工团队
- 自动功能被淘汰
- 是否有任何基础设施阻挡了自动化测试的运行？
利用这个图表，管理人员可以做出以下决策：
- 重组团队或为自动化分配适当的资源
- 升级测试执行所需的基础设施
网友评论