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

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

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

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

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

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

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

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

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

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

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

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

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

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

仅供参考：

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

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

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

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

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

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

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

反正我觉得我越过越穷

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

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

没有跳槽涨薪选项哇

先分析，如果一点头绪都没，就堆量呗。

那你就要去维护前端扫描脚本了。

安全啊 ，学好终生不愁，还会被国家收编。

多几个角度，随便能说一大堆
把影响质量稳定的因素挨个说一遍。
什么过程质量、结果质量、提测质量、需求质量、文档质量、技术支撑等等
影响质量的一些条件也可以说说啊，比如人员、环境、竞品等等

1.如何做一位合格优秀的业务测试？
熟悉业务，根据自身业务知识能快速准确分解需求，找到需求问题，并辅助技术做业务的设计。可取带性和合格优秀是两个维度的概念。

2.业务测试在一线城市有封顶薪资吗？
看平台和赛道。门槛高、壁垒强的行业更具竞争力。有些公司某些技术就是他们的业务。

3.业务测试如何去发展自身的特长，也就是职业发展？
多元化角色，多维度技能，或者某方面专家。

4.如何让技术循循渐进的进步？
选择目标->学习 + 实践->总结 + 分享。

说的是线上缺陷吧。你统计数据这个没啥意义。

1. 数据不一定准确（比如我随便编一个，有什么参考价值？）
2. 别人的项目，从某种意义上来说，可比性并不高。项目基本情况不一样，对线上缺陷的容忍度不同，团队能力、环境、资源、进度压力都不同。对部分团队来说，线上缺陷只有 0 和 1，对部分团队来说，线上缺陷慢慢改都行。

大家的规避措施倒是可以参考下。

学习了