衡量指标:代码覆盖率，自动化测试占用率 (自动化测试案例:手动测试案例数)，节省人力时间，这个看你怎么做汇报的 ppt 。

提，这个是你的工作输出。亲身经历，甩锅时可用，不然死得很惨。

换电脑。

看着社区慢慢的做大，技术分享越来越好，值得称赞。

只要你性能做得足够深，我相信，面试的人不会看你的自动化测试的能力。

感觉上你性能也不太行。

stf service 被系统进程杀掉

所有没有需求文档的产品都是耍流氓，常见问题包括开发没流程，权责不明确，领导说了算，出问题妥妥测试背锅，这种公司不要去。

感觉上是让你自由发挥，看你要做些什么，然后深入问你，每个领域怎么做。比如 cs 架构比较重视安全，那么安全怎么做。比如 cs 架构的性能、高可用比较重要，那么又可以深入问你你会怎么做。

忍气吞声。

深圳有招吗？

请了解一下代码覆盖可以 exclude。另外，不要认为调用量为 0 就可以删除，有些老系统真的很少调用，但一旦调用就会出事故。我曾经遇到一个接口，半年内调用量为 0，但这个接口确实有人在用，幸好没删除，不然死翘翘。要下接口一定要有官方的流程，这样锅才能不上身。

来深圳后就没运动过，也不是天天加班。

测试案例很重要，但发现 bug 的往往不是用测试案例发现的。

这家是个好公司，但是在国外比较不方便。

不清楚你们是什么样的测试数据，居然能有这么大。出一个馊主意，多搞几台相同的数据库。
其实一般来说做自动化测试前需要有环境自动部署能力，这个能力是自动化测试重要环节。
使用 docker+k8s 可以快速部署环境（包括数据库），但我这边做不了，所以多搞几台服务器。

反正我是无论如何都还原数据库。不然各种数据不稳定，案例跑不下去。

要保证产品质量就老老实实写用例，自动化的非自动化的都一样。

个人经验，我们这边经常出这样的问题，哪怕你提了一堆 bug 也要有邮件或者其他记录而且要 @ 到那个人。干架的时候，只要不是你没有验证 bug，延期关你啥事，没提 bug 就是你的问题。要整改要布道也需要有个锲机，等出事故。

默默点赞，一针见血。

这种地方练的不是技术能力，而是怎么做事。怎么让你想要做的东西落地，这是你应该想的，包括如何说服开按着规范来做。最好的方法就是等出事故，再来整改。你要做的是如何撇清责任。

代码覆盖率