来！微信团队，你让我查查你们的数据库呗

完全不能同意，这是偷换概念……我调微信接口并不是我在测试微信接口，而是我自己的业务功能拿微信接口的返回结果作为数据源，默认微信接口的逻辑绝对不会有问题，这个 “不会有问题” 自然有微信团队的测试人员去验证，微信团队测试自己的接口的时候一样可以去数据库查数据验证的。
不然，按照虫师这种逻辑，我们要验证结果是否正确，要得给 oracle、mysql 这些数据库产品做一套完整的测试先保证数据库产品没有问题……

实在不清楚为什么要去 mysql，ES 里捞数据校验，我从查询接口去校验不是更符合业务测试场景么？

违反测试独立性原则，耦合了

我理解，楼主说的是神化，而不是神话……按道理，自动化是应该被神化的，但是暂时还没有得到足够的重视

那就是向量，而不是点了吧
另外，条件 1，“start 先于 end” 还是 “start 小于 end”，如果是 “先于”，那么 “先于” 的定义是什么？

理解不了，一个点怎么有起点和终点的……

用 pyhon 做业务系统后端可能比较适合那种精英小团队，中大厂很难看上你这个项目和技术栈的匹配度
要么你换 java、.net，要么就去做测试/运维小工具、测试框架、算法框架这些东西的开发~
你可以不认同这种观点，但是很多公司很多人的确就是这么想的，因为他们的主力中坚力量成长于 java 年代

对于你目前即成事实的情况，可以考虑减少或者合并简历中对技术栈、工具、杂事的罗列，增加对主干业务逻辑的阐述，如果你能把系统设计和业务逻辑搞得清清楚楚，面试官应该也不大会苛责你的技术，毕竟业务能力是比开发技术更稀缺的东西。

科普一下，楼主说的 BAT 其实就是 T

同意，天下苦这种玩意久矣

电梯爆炸之后，满电梯面试官的碎片如何收集也是可以有很多场景的~

我厂的覆盖率，都是通过外部（上层/消费者）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;