Evan置顶2022-07-051、先做稳定的主业务流程的自动化。 2、再做手工执行次数高的自动化。 3、尽量少做/不做页面变动频繁的自动化。 以上三点可以覆盖这三个问题： 1、根据（执行次数*执行时间）/开发时间 来比较回答。 2、ROI公式甩出去 3、根据ROI公式节省的时间与业界普遍的测试薪资挂钩，给出一个实际价值LOL。作者回复: 哈，直接又清楚的回答！ 尤其最后一句话，是重点！一定想办法把这个价值表达出来！
1
羊羊置顶2022-04-19在实际工作中，我们是先从技术实现的角度，筛选出可以实现自动化的case，然后按照case的优先级排序，再计算开发脚本的时间，分批自动化case。学习了老师这节课程，终于找到理论依据了作者回复: 是的，现在你的思考过程，是“归纳法”，从实践中总结出规律，然后就可以使用“演绎法”，从规律推导出更多的最佳实践！
3- 李慧文2022-03-21ROI 是一个自动化测试项目的隐式命脉，说的太对了，可以说现在所有的工作，包括计算机行业外的工作，都完全离不开ROI
作者回复: 是的，本专栏是想帮助同学们在工作实践中 “做最好性价比的自动化测试”，把我们有限的精力，投入到ROI最高的地方。不要做“重复的”，“无效的”自动化测试。
6 
who am i2022-03-31问题1“产品要上线了，QA 人手紧，能不能搞一下测试自动化，减少点人手?” ，重点是产品要上线了是时间成本限制问题，临近上线时间节点和投入自动化开发时间是否符合，如果不符合不能搞自动化，且自动化主要是用来回归测试，产品上线功能是都是稳定还是待定作者回复: 是的！在ROI公式里，自动化测试是长收益模型，所谓远水解不了近渴。
4
太匆匆2022-03-22冒烟测试进行自动化确实是最合理的选择，现在有了ROI这个武器，拒绝自动化测试无限扩大就有底气了。天下苦无限自动化测试久矣！作者回复: 说得好！
4- 闲不住的令狐冲2022-04-21既然作者的公式提到了d，那么我也分享一下个人在工作中的心得。因为本人做过十多年开发，代码功底凑合，所以在加入测试团队后，根据产品特点（注意这个），重构了团队自动化框架，大幅减小了d（当然也因为更好的可维护性和可扩展性顺带缩短了m），收益也非常明显，特别是在迭代的流量项目中。 所以，我建议有余力同时也想在工作中脱颖而出的tester们，抽空学习一下经典开发框架的原理和设计模式。
作者回复: 感谢分享观点！希望在第三模块的“job设计”，能和你思路碰撞！
3 
willwchen2022-03-23自动化测试提升节约了多少测试时间的度量标准，感觉只适用于测试团队内部度量，怎么把这种价值传递到整个业务团队，能让业务团队感知到自动化对业务带来的价值，这个是目前最大的挑战，现实是业务团队对提升的测试效率感知不强，不感兴趣，2个100万的自动化工程师，对业务团队的感知提升，可能不如4个50万的业务测试工程师，对比衡量，是不是4个50万业务测试工程师价值更大，这4个业务测试工程师除了本身测试工作，还能再完成70%-80%自动化测试工程师的工作，这是尴尬之处作者回复: 看出来可能你负责的是领域性软件，业务性比较强。测试人员在团队种被赋予了业务专家的属性，这时，能引起团队共鸣的一个自动化测试价值，是把业务知识规则化表达出来，先让知识可表达，可存储。我在1.5里会说到这个！
共 2 条评论2
追风筝的人2022-03-22note 1. 自动化测试是用来做回归测试的 2.软件发布周期变短是自动化测试 ROI 提升的产物。 3.ROI 是一个自动化测试项目的隐式命脉。作者回复: 非常到位！
2
萧瑟2022-05-04按照目前所在公司的实际情况，产品已经要准备上线了，能不能搞一下自动化，我会说不能搞，因为手工回归测试的时间成本要远小于自动化脚本的开发工作（因为熟悉程度高，手工回归更加快速）作者回复: 没错，就是这个道理。一般地，自动化测试是长期回报的，所谓远水解不了近渴。
1
Even2022-03-27ROI=(n×t)/(d+m)。编辑回复: 剧透一下，抓住重点了，后面这个公式还会常常出现、花样使用的，敬请期待～
1