有几个问题：1.自动化测试建设的进度跟不上版本发版的进度，怎么办？2.要做动态数据的自动化吗？对应的断言校验又要怎么处理呢？3.陈老师这边接口自动化建设的规模如何，效果如何，每次执行通过率如何，不通过的都是什么原因呢？

1. 为什么会跟不上版本进度呢？没有时间写脚本？在我的团队，迭代周期中的测试内容就会包含自动化测试的时间，而且通过工程能力的建设，所需要花费的时间也不会很长，基本上都是要求在迭代内完成对应新版本的接口自动化设计；

2. 需要做对应的断言，具体的断言要求可参考 ：https://testerhome.com/topics/36216

3. 我辅导过多家公司的自动化测试落地，规模基本在 30~50 人的测试团队之间。效果还行吧，至少现在大家都还在坚持着做。通过率不好评估，具体问题具体分析吧。主要还是脚本和数据的问题。环境的问题通过技术手段基本上不太出现了

感谢老师的解答，我这边也和测试团队一起做了多年的自动化测试，感触颇深，因此还有些问题想继续和老师探讨:
1.关于 1 自动化跟不上版本进度的问题，您所在团队迭代周期中，自动化测试用例调试编写的时间在总测试时间的占比是多少？写不写手工用例？写的手工用例能否直接转为自动化用例？
2.关于通过率，如果自动化的通过率/稳定性堪忧，如何能让人信服自动化的测试结果呢？所以我才问您所在团队的自动化通过率是多少。
3.对于一次非 100% 通过的自动化测试，这次结果怎么算？那些没有通过的用例，又是怎么处理的呢？是要把这些用例改对，还是认为是误报？
4.自动化测试发现过缺陷吗？发现缺陷的频率大概有多高？
5.咱这边接口串联场景引用接口数量的中位数大概为多少？最大为多少？
盼望您的具体回答，最好能列举具体示例，少些 “政治正确、套路正确” 的表述

完全当 kpi 做，回归用例不合格、本身对自动化没信心、完全不花时间运营 ，普罗大众工作赚钱吃饭，自动化和手点完全不影响吃饭

1. 自动化脚本的编写在一个迭代内基本上一天搞定，会有基本的用例设计，再动手写脚本；

2. 通过率不好算，基本上有问题就马上排查解决，如果是误报或者数据错误，需要及时修复脚本。我们对于自动化用例有降级机制，连续失败 5 次后，就会被踢出用例集，进入修复库，这个修复库会邮件通报的。所以解决问题的速率还行。

3.对于报错，人工分析是什么原因，不自动上报，是 BUG,就是 BUG,是误报，就按 2 处理；

1. 肯定发现过缺陷，特别是接口变动没有通知上下游的，导致关联业务报错。但不会很多，因为也不是自动化的主要目标；

2. 接口场景的接口数在 15~20 之间吧，长的也有 40+ 的，再多就建议拆分了

以上，不知道对你是否有帮助。可以加微信细聊

感谢陈老师的回复，我仍然关注一些具体数据，具体疑问如下：
1.“您所在团队迭代周期中，自动化测试用例调试编写的时间在总测试时间的占比是多少？” 您回复说 “在一个迭代内基本上一天搞定”，并没有直接回复比例，您所在团队一个迭代周期是多久？2 周吗？所以我关注占比，想看看能力优秀的团队做自动化到底会花费多少项目资源，我们目前距离优秀团队还有多少差距。
2.如果有问题立刻就解决，为什么通过率会不好算呢？难道每次执行都会有不通过的用例吗？连续五次执行失败会进入修复库，这种需要修复的用例的平均修复时间大概是多久呢（从进入修复库到修复完成）？
3.咱们的自动化执行频率又是如何呢？每次全量执行，耗时大概多久呢？
4.您所在团队的自动化用例是否考虑异常场景？如考虑，异常场景会考虑到什么程度？
盼望老师的解答。

1. 双周迭代
2. 为什么要算通过率呢？这并不是个很有用的指标，通过率的高低并不能说明什么，我们没关注这个指标；如果执行失败，我们的要求是 2 天内必须解决。
3. 执行频率是分等级的，对于 P0 的级别的，集成到流水线上，每次 Merge 到保护分支都会触发，其它级别的每天至少运行一次；
4. 会考虑异常场景，验证是否做了足够友好的提示，我们原则上不允许直接抛出代码异常。

确实是优秀团队的能做出来的理想情况了，给您和您的团队点赞

精彩的对话 为两位老师点赞

自动化提效不能带来降本，这都说不过去，上层是没办法理解的。

精彩的对话，很受用

我之前给老板打过一个比喻，可能不是很正确：就像你平时公交上班，今年买了个车。是提效了，不管去哪里都方便，也能省出点时间做别的。但是，成本肯定是增加了。和自动化一样，它能提效，能在更多的地方发挥作用，但肯定是无法降本的。

如果是出于降本的考虑，有其它更多更快速的办法，不是么？都懂的。

提效的逻辑，收益的地方能有量化的指标出来，业务方认都好说。现实并不是这样的，成本之间的关系都很难理清，更别说考虑你自动化的提效了。所以最直观就是既然提效了，如果说你提效 50%，那我就可以减掉你 0.5 个人。

同意恒温，我们这边的提效的最终目标，也是铆定优化研发测试比去搞的（如降低外包同学的数量，从而节省人力的经济成本），或者在相同的人口和保持相同质量的前提下接更多的活干。但研发数量不变的前提下，测试活就这么多，业务盘子也不会突然增大，所以更多时候还是选择优化研发测试比。

【提效从来不意味着降本，如果你是想通过自动化测试，来减少测试人员的数量，节约人力成本，以此为目标的话，大概率是失败的。个人认为，自动化测试的意义在于构建快速反馈的能力，不论是集成在 CICD 流水线上，还是作为线上巡检的一部分，都能够提升质量反馈的速度。在敏捷研发的大环境下，快速反馈能力是必不可少的。不能让测试执行成为团队交付瓶颈】

对于这段话，我的理解不太一样。

1. 注意主语是【自动化测试】，然后才泛化成【提效】。自动化早期建设它反而会带来成本，要建设就需要人力代价，而收益也只会在建设完成之后才会拿到。来到现实上，很多自动化建设因为里程碑拆分不清晰，或者阶段性建设没想清楚，往往都是憋大招的形式去搞，周期长难度大，但凡中间翻车了就是 0 收益，剩余的全是成本。所以才会给人带来一种错觉：自动化建设需要很大的成本，而这个成本往往大于收益（因为收益根本就没出来过）。

2. 自动化测试确实构建了快速反馈的能力。举个例子，有一个未知的线上问题，因为自动化巡检，让研发测试提前于用户发现出来并修复，这里面包含质量和效率的双重收益。【质量】体现于早于用户发现问题然后解决，那对于用户来说这个问题就不存在了，质量就更好；【效率】体现于因为自动化建设，有了明确的复现路径，不需要很费力排查与定位。那这种【快速反馈的能力】是不是就是提效，是不是就能让本来 2 个人做的事情缩减成 1 个人做的事情？所以换句话说，做自动化就是提效->降本的一种路径，当然它不是唯一路径。

3. 举的例子存在我个人认知的局限性。以互联网的常规操作说，多数先从获取流量开始，然后考虑变现。获取流量需要在短时间内快速占领市场，这种行为本身有巨大成本，包括但不限于招聘超出业务所需的人来迅速支撑业务盘子。当业务发展起来，大环境如果不好，就面临一个多少有点卸磨杀驴的问题：“早期为了业务发展搭建了偏冗余的团队，造成相对大的信息流通和决策执行成本，现在希望通过精简团队的方式来让团队对市场响应更敏捷，决策落地更迅速，同时增大业务利润率，我能通过什么方式来让同样的钱做更多的事/节省开支？”，大概率不会是 “我是不是要花更多钱招人，把质量做好，从而获客更多”。之所以这么说，我认为当产品质量到达一个阈值之后，再提升质量 ROI 就很低，所以质量和效率在业务不同阶段各有侧重，效率引出来就是人力成本。【第 3 点有些跑题，但是刚好联想到，试着探讨了做自动化的一些前因后果】

大佬们 对于存在业务逻辑的线上巡检 不可避免的要对正式环境进行增删改操作，会影响正式环境的数据，那应该怎么避免呢？使用一些字段的特殊数据（如联单号字段 写为 testnumber）吗？

可能是行业不太一样吧，我所在行业是制造业的 IT 部门，所以没有那么紧迫的本成压力，所以自动化的目标并不是以减少人员为目标来展来的。聊下自己的观点，仅供参考：

1. 关于自动化平台的建设周期，在很早的文章里有提到过，是围绕能用 -- 好用 -- 优化使用 来构建的，每个阶段都会有具体的产出和收益，个人也比较反对一上来就规划太多的功能，把平台做的太大，周期太长。

2. 快速反馈的能力是提效的表现，但也不太可能因此就把 2 个人做的事缩减成 1 人，因数快速反馈的能力构建本身也是有成本的，无非就是看把成本花在哪，是花在人力验证上，还是花在维护自动化上。可能成本是一样的，但是带来的效果是不一样的。

3. 你提到的案例我也经历过，不同阶段的产品形态对质量的要求是不一样的，对团队的组织结构也是不一样的。这个是肯定的，所以测试人员也需要学会识别业务对质量的要求，并不一定非要开展自动化。

或许你可以换个方式想，用车的成本能节约你多少时间？假设你的工资是 250 元/小时，开车让你上班少了 1 个小时的时间，产生的费用是 30 元的油费，那你是节省 220 元的成本。

1. 操作数据的账号是被标记的测试账号，其数据库增删改权限有限制，产生的数据可以通过账号来辨识以跟踪，实现和线上真实用户的数据隔离
2. 操作数据本身是有明确测试特征的数据，可被辨识并删除

谢谢大佬解答 普通有界面的增删改可以使用 1 ；来自于消息队列的数据就可以使用 2 了

如果是游戏行业主要用的是 TCP 协议的有什么办法能上手吗