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. 测试人员能力比较弱，技术型业务弄不了

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

只是数值上的对比的话想办法获取就行。不过一些前端渲染啊样式这些，还是得靠看。
另外如果重构方案你参与过评审的话，测起来可能更有头绪一点。

如果后端没变，仅仅是前端展示有变化，做个前端 diff 测试就行了吧。

本来该长一样的数据，结果变了，一下子就出来了。

可以问问自己以下两个问题：

1. 经过评审后的需求（如果有）是否明确要做验证？
2. 如果不做验证，会产生什么风险，这些风险是否可控？

有 SQL 注入风险，可以用 SQLMAP 扫一遍，用安全缺陷说话。
有功能上的缺陷，可以用功能缺陷来说话。

设计上的问题，我们可以给建议，但是建议最好有事实的依据，毕竟你不是产品，也不是设计者。

没测试过，不过如果我遇到，我应该把一些差不多大小的文件改成测试的图片音频格式直接上传来验证边界。
至于是否会产生文件损坏以及其他啥的，那是另外的测试了。