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

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

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，对部分团队来说，线上缺陷慢慢改都行。

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

学习了

没怎么接触过，以下是我想到的：

1. 法律法规要求，例如欧盟 GDPR
2. 文化上，有没有踩坑的（这玩意儿最好找个当地人。。。）
3. 外观页面上的，如文本图片信息，有没有错漏、排版等问题
4. 易用性上，符不符合当地人习惯
5. 支付相关，货币类型、单位、支付方式等，适不适合当地人
6. 流程上，当地人的一般信息，是否支持你们的业务，例如注册、登录、验证、找回以及后续运维等等
7. 兼容性上，本地化的浏览器、app、机型等等的验证
8. 架构部署设计上，性能、安全等是否符合要求，特别是不同时区，有没有涉及时间的任务、日志等

先招招人的人，再招人 哈哈

好文！不过向上管理挺难的。特别是整个研发中心都是成本中心的情况下。

1. 挖掘新的质量关注点。比如安全，这个很好推进，一般正常点的领导都不会忽视安全的。安全测试、安全设计、渗透测试、安全攻防、secOps 等等
2. 建设强大有效易用的测试基建。
3. 对个人来说的话，你想获取工作中的正反馈，可以先做点团队里大家都不想干的脏活累活难活，能让这些活不脏不累不难，这就是价值。

一般这种情况有以下几个原因：

1. 开发人员比较闲
2. 业务承担风险能力比较强
3. 测试人员能力比较弱，技术型业务弄不了

测试的价值一直都在，测试人员的价值就得靠自己挖掘了，每个团队测试人员表现出来的价值是不同的。