人之常情。
说句不好听的，别人绩效不过关离职，应该是有怨气的，提了离职之后就不是你同事了，你随便找个有怨气路人帮你解决问题，这不是自找没趣嘛。

除非他平时是你的好兄弟。

接口测试都做了数据流向和边界测试了，正常跑几个主要流程就行了啊。

按你闭环的定义，就是走完一整个流程。

但是从单个功能来说，每个测试用例待测功能之前或者之后流程可能是相似或者一致的，并没有必要每个都闭环走一遍，浪费时间不说，也没有什么意义。

如果你对数据处理的一致性不确定（或者要保证某些流程），可以专门针对数据完整生命周期来做测试。这个功能哪类数据会导致后续流程处理有问题，单独分析和设计对应用例。

无脑闭环，在我看来并不可取，效率低下、成本高、测试质量也可能不符合预期。

从没听说过用例必须 “闭环” 的。我甚至不知道啥叫用例的闭环。

一般也叫符合性测试

如果很有前景，就跟着公司成长吧。。。

厕所待 5 小时算吧

参数都变了，那不就是新的接口测试了？为啥要调整以前的接口请求参数呢~

数据就不要谈感觉了。。。感觉是基于经验的，数据是基于实际的。

学习了。

这说的是如何提 BUG。。。并不是测试报告。

mock 吧，如果啥都没有，车窗响应其实也算一个未开发好的功能模块

嫉妒那些 PPT 做的好的人。哈哈

弄出一套体系，可视化的看到各类质量。应该就算深入了。

没 HC 了，不用纠结了。

学习了

1.优化用例质量
2.加资源

或者选择分层测试，UI 少做或者不做，放接口层做。

找工作难，导致工作的也开始更卷了。

都能测试完其实问题都不算太大，对整体项目质量都有一个预期了。

比较可怕的是都测不完就让上。一般根据实际情况调整测试策略，实在来不及就基于风险做测试。

保持自己的核心竞争力。静待~

时间精度关注的少，一般关注金额精度了，学习了。

严格管控，严禁口头沟通（口头沟通后也会补文档和邮件），所有需求必须经过评审，所有变更均有文档记录。

你领导管理有问题吧，需求管理这么大的漏洞，他竟然不关注，你应该先给他说清楚需求管理和质量的关系，转变下他的质量管理理念。
你们这种情况，可以要求新增或者修改需求，必须邮件通知，如果没有通知，可以给缺陷分组加个列个需求变更引起。统计一下因为需求管理导致的缺陷，用数据说话。

少了个过程内聚和外部耦合

工具框架几天就会了，剩下时间可以看工具的源码和思想。

才来多总结点文档，勇敢分享。（被喷有时候还是要点勇气，但是喷着喷着你就 NB 了）