我厂的覆盖率，都是通过外部（上层/消费者）API 来调用执行测试，完了统计测试覆盖率，握了一把草~

匿名发帖，无处可通知，实名贴肯定会有通知的

抱歉，是我删的，原因确如恒捷所言，感觉没法让别人给到你什么有用的建议

结果校验的核心是 output data，自然交给 testdata-service 一起构造，这样需要维护的是每个功能的造数规则，这种规则只会随着业务功能的逻辑变化而变化，不会触及代码层面，而且可以通过录制（预先跑几遍）来构造，很简单。

补充说一下，既然问到了输出校验，接下来你肯定还会问，如果我这个接口/功能/步骤的测试根本不足以校验出这个改动是否影响到后续业务的正常开展，比如银行开户功能改了并且测试通过也不能保证这个改动不会导致后续取不出钱来，这种情况怎么办。这个就比较麻烦了，继续吹几句，仅供参考：

• 流程性、依赖性的自动测试需要 MBT 来配合实施，也就是业务流程建模，你可以简单的理解为把每个功能点作为一个节点，流程用有向图连起来，构造、画图用 proxy 挂 mock-server 录制就可以实现基本的画图了，后续根据实际业务稍加修改就行，然后每个节点做一下业务功能标注和描述，推荐使用 canvas/svg，之前一个小伙伴用 graghviz，卡在图的编辑上很久，而且也比较重了；
• 变更代码涉及到其中的某一个或者几个节点的时候，你可以遍历这张图找到所在的位置，DFS 也好、BFS 也罢，达到目标就行了，我记得去年字节有篇公众号文章写过他们做 app 端便利测试的时候提过类似的方法，反正就是基础图论应用；
• 根据涉及到的节点在这个有向图中的位置，向上溯源和向下延展，给出所有路径，让框架和 testdata-service 根据这几条通路帮你组织好前后依赖的所有数据，包含输入和输出；
• 测试框架生成这个全流程所有的 case，然后串联起来执行，多个流程在一个节点上是共用一份 case 还是每条路径重新生成就看你的机器资源和对效率的要求了。

基于代码变更的模型化测试，我管它叫 CMBT，以前几个伙伴搞过，无疾而终，并非实力不济，而是领导听不懂～

精准测试天生就不是手动的，手动用例还是通过沟通和基于风险策略去选择回归范围吧

那你精准测试要解决什么问题？

测试用例和代码关联这个思路本质上就是错的，永远走不到自动化的路上，需要人维护的东西终不会可靠

其实对于 springboot/springcloud 的应用来说精准测试的思路相对简单，其他技术栈就不是很清楚了：

• 如楼上恒捷所说，根据变更扫出调用链，找到最上层的@Component、@PostConstruct、@Controller/@RestController 这些组件里面对应的接口；
• 服务端无条件上 swagger，不配合就不要玩下去，要么自己实现一个类似的框架。根据用接口参数定义，扫出 required 的参数，用 testdata-service 构造出对应的数据，对于非 required 的参数，可以使用 pairwise/正交算法去组合，同样拿 testdata-service 构造出对应的数据，最后把数据拼装好；
• 在测试运行时，临时创建接口测试用例，这只是对框架要求稍微高一点而已，拿上数据去跑就行了；
• 总而言之，要精准测试，一定要放弃写脚本、写 case 去 mapping code 的错误思路，用框架在运行时临时创建可执行的内容，不理解的话请参考 swagger-ui 里面的 try-out 功能。

正因为我一直坚持这个观点，所以我在任何公司都不会搞用 web 页面管理自动化测试用例的这种测试平台，这种玩意对未来不友好，看起来傻极了——未来应该是 mr 提交，变更代码涉及到的接口/功能自动创建测试并且执行——当然，我说的这个方法，数据库层有业务逻辑代码（oracle、pg 的 package，各种数据库的 procedure、function）的不适用，变更的是配置而不是代码的不适用，因为测试通过并不能说明没有 bug～
补充一下：如果谁有种，把 bug 自动修复做了才算牛逼，据说 github 上有个搞这事的项目！

1、先做性能测试，拿齐测试数据和监控数据，具体怎么做请学习——要怎么测、用什么数据、什么场景，需要性能测试专家和架构师先帮你做测试方案
2、请你们架构师来做分析定位，而你则全程跟着学习、提问
3、自己尝试独立做这个分析定位，请架构师来评审、指导
4、……
问这个问题的，我猜第 1 步应该就不咋会。

肤白、貌美、胸大、英语发音标准，最关键的是……是个写 java 的，完美

onchange=calc(data) 或者 onblur 甚至 onmouseover 这些事件，可能后面的提交按钮绑定的事件没等这些前面的触发直接触发了……看起来用 onblur 和 onmouseover 的可能性比较大，onchange 速度快的多

涉费逻辑一律后端校验，不能依赖前端计算和检查，不用太过考虑性能问题
另外，如果 c 是最终提交金额，也需要测试一下这个只读域的前端篡改提交（F12，删除 disabled 属性或者 http post）问题，业务逻辑写在前端都是找死行为

我都 37 岁了，一样学习各种语言名称的拼写...

• 一般来说，你这里的登录是一个用例/场景里面的一个 step，而不是一个孤立的用例，互不依赖主要还是指多个相互不存在直接关系的业务场景的测试执行之间不能依赖；
• 如恒温所说，你这是集成测试，只不过是拿 API 测试的用例/脚本去做集成而已，没人说集成测试不能相互依赖，但是单纯的 API 测的确不应该存在相互依赖关系，因为不利于数据、环境治理，自动化稳定性和有效性不容易得到保证。

综上，“接口用例” 不能相互影响是你自己生造的概念或者你理解错了其他信息而产生的说法，只有相互依赖的测试执行场景，没有相互依赖的用例，用例天生独立。

看的是 core，只是个建议，算不得什么问题

666，佩服佩服
不过有点小建议，代码里太多这种了：

if (zzz) {
  do many things;
}
return xxx;

考虑一下这样写不是少很多三角缩进吗

if (!zzz) {
  return xxx;
}
do many things;

一看头像还以为是司总呢……
devops 平台不是一般测试开发有能力去做的，测开最多参与在里面做一下 CRUD，产品需求、架构设计，非专业开发 5 年 + 经验，做出来的恐怕都是自 High 型玩具

我厂研发测 pytorch、tensorflow 这些框架好像也用的是类似的手段，很多算子组合，一次测试跑几个小时，结果出几十万条

可以用在 fuzzing 和混沌测试中？

恒温家的应该改叫张小猫，而你家的才是陈小猫，谁让你是陈大猫呢～

反正不是我喷走的，我喷的很温和
主要有个别直接问候人家祖宗的，太脏了，不理解人家在说啥也不辩论，上来就骂，这种人估计现实生活里有诸多不顺吧，戾气超乎想象~

我觉得你实在太多执念了，我喷一下，你看是不是这么回事：

• 就因为你进入到 AI、芯片领域，接触到偏底层、偏硬件，就一定要在辩论里面举这些例子，甚至要别人摆脱 app、电商来 “发展”、“提升”？每个做测试的都需要懂算法？leetcode 上面我一道不会也不影响我职业发展啊……
• 你看到测试做的不好被人鄙视就是测试工作没技术含量、不成气候了吗，我身边也有一大群用 c 写 driver 的开发，多数不懂 CI/CD、不知道 pipeline、轻视流程规范，甚至有个别的连基础的字符串拼接 d% 都不知道啥意思，可怕吗？顶端永远只有那么百分之一二十，所以轻视测试的永远有——也有历史原因，被轻视的开发比例也不低，这不是拿来刺激测试工程师的有效手段。
• 你在 “反不反智” 帖子里陈述的观点基本没有问题，但是论证的方法实在不行，喜欢拿自己看到的情况来说，你去 NV 和高通、Marvell 去交流过吗，会不会只是因为你的公司太年轻，也没招到有经验的人呢？
• 行与不行只是阶段性的，把你们大部分人丢到 02 年的阿里去，就算成长不成多隆、鲁肃，应该也不会太差，成长需要环境和契机的，别看到几个水平不行的就把这个职业给踩碎了。

anyway，要我回头做测试我也是不干的，原因我在你那个帖子里面已经说过了，堆人、低效，导致没有挑战性和成就感，这个大环境就这个鸟样子。

是你自己先提的鄙视

这篇：https://testerhome.com/topics/30403

只有智……或……不智，不存在反不反智，扣帽子是 XX 行为，智不智不知道，反正社区戾气是够重的。