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

没 HC 了，不用纠结了。

学习了

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

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

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

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

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

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

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

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

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

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

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

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

条件有限，只能自己动手，自己管理。

就是对后台架构、数据库、缓存系统、中间件、文件系统都很了解，知道各种配置的缘由，能找到问题。

postman 挨个跑一遍不就达到测试目的了~

纠结缺陷类型，其实是考核制度的锅。。。没有合理引导，大家关注点都不在提高质量上，都怕影响自身去了，这种风气长此以往会导致项目组内部矛盾重重，毫无团队气氛。。。。

只要是 bug，就应该重视和解决，有甩锅那时间，还不如多总结问题。对项目来说，外因和内因并没有什么区别。

bug 有外因和内因，但是无论是什么原因，bug 就是 bug。

你想表达的是你们认为是他们的原因，但是他们说是外部原因，有甩锅的嫌疑吧。

不过少提文件和少 sql 都能提测，感觉几乎没有自测就提测了，建议加入测试准入标准~~~

仅供参考：

1. 先摸清领导时间进度的需求，与他达成需求一致，这是大前提。过程包括面谈、会议等。如果达不成不一致，事先摆数据，讲事实说服领导。时间进度一定要把正常测试和遇到问题后的测试分开说。
2. 测试基础设施建设。比如造数平台、自动冒烟测试、自动回归测试等。缩短自身测试周期。
3. 改变项目管理方式。看你回复，应该是用了敏捷，但感觉是假敏捷（如果没有用，可以考虑引进下）~计划会上各方预估的时间没有统一。
4. 如果以上都弄了还是慢，那就是资源限制了。加钱加人。

其实吧，有时候测试的慢，新人太多也是一个原因。。。

开卷有益。
对，两个意思都对。

仅供参考。
质量的变化可能是多方面引起的，可从以下几个方面考虑：

1. 环境 需要对出现问题的各种环境进行总结，避免类似情况发生
2. 分类 对产品方案进行分类，比如把单独对只部署服务归为一类，此类的定价及提供的服务单独设置
3. 流程 根据上面的分类和以往经验，总结 checklist，各类情况的部署步骤、执行人员、用户培训、常见问题检查等，做好详细的方案。让用户及领导们对此类方案的实际情况有一定的预期。
4. 执行 执行过程尽量标准化，自动化，做好用户调研。评估用户的情况，需要在用户环境进行测试的，严格执行用户环境测试。

你这也太舔了，只适合上司人不错的情况，否则就是舔狗不得好死啊。。。

向上管理说的好的个人觉得是这篇帖子https://testerhome.com/topics/33077

反正我觉得我越过越穷

“多人多需求改动相同代码文件”——可以从这方面入手，让开发重构或者把需求拆解好一点。
我们一个 master 都没出你那些问题。

没裁，但是遇到行业寒冬，感觉在裁的边缘。

没有跳槽涨薪选项哇