敏捷团队中需要写的是回归测试用例，当前迭代的内容可以通过 AC 或者自动化脚本的方式跟进，但是回归测试的用例还是需要适当补充

说下我的做法：

1. 记录每个接口上次正常运行的结果（主要是入参和出参的数据结构）
2. 定期自动回放接口，对比返回的结果，如果报错或者返回的数据结构不对应，则告警；
3. 更新测试用例 以上步骤做成接口测试平台中的一个功能点。对于新增的接口，如果没有提测，可以不需要关注。

参考我司的几点做法：

1. 聚焦：每次用例评审不超过 1 小时，只评审核心内容及测试设计思路，不对具体的每条用例展开评审，实际上这个意义确实不大，只要测试思路没什么问题，大体上也不会有偏差；

2. 事先准备：事先和研发及产品沟通，让他们提前阅读文档。在评审的时候，不需要拉上所有的人，只需要相关人员即可

3. 持续反馈：测试用例并不是一成不变的，哪怕是评审完。不能让测试用例成为一个借口（很多测试人员经常对其它人说为会不在评审的时候提出来，这种做法很不推荐，别人只是帮你 check，而不是让他来替你思考）

4. 给出行动项：需要修改的内容，及时修改并反馈，让大家有参与感，同时表示感谢。

5. 要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程，除非你们的测试团队特别年轻（哪怕真的都是刚入行的人，也不应该在评审时去逐条过，那是测试主管应该做的事，不要拉上整个团队）

6. 关于评审能给团队带来什么，个人的理解是这是又一次三方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的，避免更多可能出现的返工浪费。

可以的啊，没什么大问题。有机会一起多交流

上面大佬关于测开都回答的差不多了。我补充点关于测试开发本身的发展路线思考，详见：https://testerhome.com/topics/30771

给你点建议，仅供参考：

1. 夯实自己的代码能力。这个是高阶测试的必备技能。不仅仅限于能写简单的代码。至少要能够通过代码解决一些测试过程中的实际痛点和实际问题。能看懂常用测试框架的源码。

2. 性能专项是一个可以全面发展自己技能树的专项，但是要做好也很难。现在的框架都比较成熟了。能优化的东西无非就是使用的规范性。想要做出成绩（不能只会写脚本，至少要能定位问题并给出合理的解释），需要第 1 点的能力。

3. 安全其实是另一个领域的东西，和测试本身关系并不大，需要的更多的是心理学和社会工程学。用工具扫扫的都不能算是安全测试。

4. 自动化专项是当下最好出成绩的专项。不管是接口还是 UI，都有大量的成熟平台，不建议自己从 0 开始做，但可以看看别人的源码怎么写。在工作中以落地为主。

5. 做为测试人员，要培养好自己的测试思维，能够从业务而不是技术角度理解和处理问题，技术是你解决问题的工具，而不是你赖以生存的能力，否则要个开发不香么。

6. 综上。希望能帮助到你。最终下决定的还是靠你自己。行动起来才是最重要的。

嗯，在快节奏的迭代周期中，测试用例设计会包含相关的测试策略。但是个人感觉会有点滞后。一般在迭代计划会上确认迭代内容后，做为测试主力，就应该去整体考虑下风险和测试验点，提前做好规划，看看是否需要其它人的协助。也不需要每个迭代都去做。想先再做。

就是实践过，然后和很多同行沟通过，才感觉大家现在都在卷接口平台，但对于测试分层每层应该做什么都不太清楚。才写的这篇。改天把我们团队的实例拿出来说说

嗯，性能测试包含的内容很多，篇幅有限，没有具体展开讲，有机会单独一篇出来聊聊。
比如 APP 的性能，比如前端页面性能，比如全链路压测，都可以聊的。

其实呢，主要还是看你的需求是什么。如果是开发环境，每次都重构一次也不是什么大问题，容器化的构建时间基本上都是秒级的，又不是不可以接受。如果是测试环境，为了保障测试环境的稳定性，手动触发可能会更稳妥些。

因为这里面还会涉及到一个问题，就是你那些服务代码的提交频率是什么样的。如果说几个服务的提交频率都差不多，你做这个 Diff 就没什么意义。如果提交频率差异很大，人为判断下，不是更快么。

以解决问题为目标。不一定非得用技术手段去解决

拆成不同的任务去构建就好了呀。在不同的 Dockerfile 里配置不同服务的打包命令。例如一个 Dockerfile 只负责构建一个服务，然后对应不同的 Jenkins 的 JOB 就好了。如果需要全局构建，那就再建一个 JOB 统一调用一次就好。

专职的测试人员会逐渐减少。测试的职能会被分布到每个人身 。团队为质量共同负责，在质量内建的道路上越走越远。现在的测试人员，要么有能力为质量内建做一些底层能力的打通，例如各类自动化测试、专项测试等。要么为业务方多思考，构建更合理的测试策略，做好测试设计的工作，让团队都能为质量做一些贡献。
核心的测试还是会比较吃香的。其实开发也有类似的问题。现在低代码初见端倪，未来需要的可能更多的是架构级别的开发，而底层的研发也面临着分流的危险。
汽车发明后，马车的相关岗位也逐渐消失，但那些原来岗位上的人，还是会找到其它的出路。做为测试人，又何尝不可以呢。多观察多学习，大不了换个岗位。

首先得分清楚这个锅是具体是什么情况。

1. 简单易现的，测试的锅，没的跑；
2. 特定用户的特定场下，才能发现的问题，影响面也不大的。团队共同分析，解决就好，没太必要一定要让谁背锅。也解决不了问题，因为这不是换个测试就能解决的。
3. 深层次的偶发问题。一起背锅呗，权当积累经验喽；

第二，团队对质量的容忍度是怎么样的。并不是所有的产品都需要做到 BUG 的零容忍。成本还是要考虑的。

第三，做为测试的同学，需要提高自己的测试技能，不能因为了有了上面的借口，就放松了对被测对象的质量管理。不断精进自己的测试能力，没什么不好的。有时候背些锅，也不一定坏事。

可以加我微信哈，chenkl0804 一起交流进步，也可以关注我的公众号： CKL 的思考空间

已写： http://testerhome.com/topics/32084

对于负载机，主要关注的是 CPU 和内存的使用。没啥具体的计算方法。主要取决于脚本的复杂度

嗯，在实际的实践过程中会发现，提升测试人员代码能力很好的一种方式就是引入接口自动化（不是页面拖拉拽的那种），慢慢接触代码，提升代码能力。也能明白一些基本的代码实践，降低与开发的沟通成本。

这种其实就是对自动化的预期没想好，流于形式了

团队人员的能力会伴随着业务要求和团队的成长一起成长起来，这个是做为团队领导最想看到的。对于中小企业的测试团队来说，并不太需要高端的技能，借鉴一些优秀团队的实践，完成可以自己搞起来

现在有这类的落地案例了，但是这个要基于开发团队的配合，通过注解来实现测试用例的编写

暂时还没开源，后续会考虑，暂时还没想好怎么维护

作者你好，我比较好奇的是你是如何实现接口间的关系梳理的，是用户先写用例，然后你根据用例反向生成关系图，还是在哪里可以维护这份关系图呢？

契约测试还没有尝试过，同意你的观点，由测试来维护全量的 API，监听变更效率不高，而且没法通知到被调用方。
全流程冒烟测试有再做，但是出问题的往往都是细节，冒烟测试无法覆盖到