---

前言

常见的几种情况：
1、项目周期短，测试时间赶；
2、转测时间一延再延，测试时间不断挤压；
3、需求一变再变，导致开发、测试时间不够；
4、开发质量太差，类似的问题反反复复出现，导致测试时间不够。

在这些情况下，项目仍要如期发布该怎么办？
事已至此，哪怕再怎么抱怨、吐槽也没用，项目总是要上的。

此时，一定要拉到项目负责人：
定下测试优先级，测试策略，即优先测试哪些功能，是不是保主要流程和界面样式，其他分支流程和细节可以留待后面测试优化？

bug是不是只确保严重等级以上的完全修复，其他尽量修复，不行留待后续版本解决？

人员是不是可以借用，比如拉上产品、运营一起测试？

协调好万分无奈的加班计划，尽可能给测试留下时间。
测试内部尽量做好测试左移工作，包括简化用例，预测bug并找时间与开发验证猜测，把更多时间放在接口测试等。

分析成因及做好规避措施
第一种情况，往往由以下原因导致：
前期时间评估不足；
上级拍脑袋定死时间；
抢占市场，赶产品发布会等。
不能让不正常成为常态。给领导做好反馈：此次虽然上了线，但实际产品存在很多隐患，需要安排时间及时处理。

第二种情况，往往由以下原因导致：
前期时间评估不足，技术难度远超预期；
需求有了增加；
面对第一个原因，要让开发以后吸取教训，做好风险和问题评估；面对第二个原因，要找项目负责人反馈看法——非特别紧急的需求，不能随便加塞！

第三种情况，往往由以下原因导致：
前期需求设计不周全，导致后面频频改动；
因为客户、测试、开发陆续的反馈，产品直接把需求加上来；
反馈给项目负责人：今后如非必要，要杜绝需求经评审通过后，再进行更改，尽可能把新增需求安排到下期；就算修改，也要做好需求变更评估，衡量工作量、必要性后再做决定。

对于第四种情况，就要和项目负责人、开发负责人好好谈谈了（或者让上级出面），让开发加强功能自测、提高转测质量。绝对不要姑息，后面出了问题，追责时，测试必然首当直冲，你有再多的理由，别人都只会质疑测试的能力。

测试时提取测试需求？
测试需求主要分为显见需求和隐性需求

显见需求
我们能获取到的需求描述，产品经理根据用户需求转化为的软件需求规格说明书，原型设计等，都应该属于显见的需求。这些需求，遵循“尽可能满足用户需求”的宗旨，往往在开发过程中都会很好的去一一实现。

隐性需求
隐性需求，顾名思义就是没有明说，隐藏在用户期望之中的需求。比如通用业界标准，软件行业标准，约定俗成的规范处理等，都应该属于隐性需求。如果我们不认真对待这些需求，可能我们在软件的验收过程中就会碰到各种问题，最终影响软件的顺利交付。

那么作为一个合格的测试员，我们应该怎么去提取测试需求呢？

首先，我们应该基于用户需求、软件需求和原型设计等，去进行需求的拆分，使得拆分的每个点都可以作为一条验证确认项，并可用测试用例去覆盖。而通常，我们应该在过程中提取更多的隐藏需求，如不同类型的不符合预期的输入，系统应怎么正确去处理它？这些就是我们在测试用例里常说的，异常测试用例。

我们还应该遵从软件所属行业的标准

可能这些行业标准，用户在描述需求时会无意识的忽略，但如果我们没有去做这些处理，最终的结果就是：用户很生气，软件不满意，验收不容易。如涉及财务统计的功能，根据业界标准，金额应该靠右对齐，如果我们还是按一般的居中处理，既给财务对账带来麻烦，又使得整个软件显得不够专业。

所以，我们要做好一个软件的测试，还需要去了解具体的软件行业背景知识，这样我们在提取测试需求时才能做到尽可能的完整，使整个研发团队为之受益。这也不难理解，在测试招聘需求中，通常有“在某某行业有过多少年的工作经验”这一条了。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

当必须放弃时，就果断地放弃吧。放得下，才能走得远!有所放弃，才能有所追求。什么也不愿放弃的人，反而会失去最珍贵的东西。

不管你正经历着什么，开心或难过，低谷或高峰，都请记住这句话：如果事与愿违，就相信一定另有安排。

不怕没人并肩，就怕错信了一些人，一路遇见，一路告别。你是什么样的人，便会遇见什么样的人，你跟什么样的人靠近，便会成为什么样的人。