二、测试工程师在工作中遇到的种种难题
我们接着来聊一聊测试工程师的工作，除去工作本身，我们会通常与人打交道，因为一个项目迭代的完成是很多部门很多人一起来完成的，这个时候会出现一些有意思的碰撞。我来浅聊一下我的看法，我的思维模式一般都是当下、后续、长期，所以我的回答也会按照这个格式来
1、产品需求文档过于简陋，堪比毛坯房
目前怎么解决：
评估可测性：这个需求虽然比较毛坯，还是需要看下能否正常支撑测试工作的展开，如果需求毛坯到我都不知道这个需求想干啥，我测试用例都写不了，那说明这个prd不具备可测性。
梳理问题清单并组织二次确认：把需求问题列出来，拉相关产品开发测试聊一下，这几个地方有歧义、有问题，最好拉个会议，把问题逐个确认并同步，确保大家都对需求理解一致
形成书面确认并留痕：这个时候需求疑问基本都确认了，一定一定要求产品更新需求文档，给出变更记录和链接，这是你后续沟通的依据
调整测试计划和做好风险评估：需求补充或者变更了，需要看些这次调整是否影响原有的测试计划安排，如果对于工期估时有影响，那需要同步一下，如果有其他风险，也要说出来
后续怎么处理：
建议需求文档规范化：建议产品leader对于需求文档，建立一些基本的文档模板规范，包括图文格式、场景覆盖、影响范围等
做好产品需求内审：一般需求写完了公审之前产品内部会有一个内审，这是一个优化的方向。这个也需要你看看怎么和产品方沟通这个事情
长期怎么优化：
可以灵活想一些优化方案，就比如说沉淀一下产品知识库，使用ai方案什么的，这个探讨空间比较大。测试可能更加关注当前怎么做或者后续怎么优化处理
2、开发提测质量不佳
当下：
冒烟测试并评估可测性：可以通过冒烟测试评估当前整体质量是否影响正常进测，如果不太影响的话，可以适当灵活调整下测试方案与策略
质量卡点与打回：如果真的太差了，核心功能用不了，主要流程走不通，明确给出问题表现与打回原因，同步所有相关人员，必要时要求重新开发、重新提测
同步风险并留痕：如果确定打回重新提测，那原定工期必然会受到影响，此时需要向项目管理说明现状情况和排期风险
后续：
推动开发自测：开发是需要有自测这个环节的，无论是单元测试或者是集成测试，都需要给出自测结论和说明，并且公开化
建立提测准入机制：有的时候开发的自测和测试的自测可能理解不一样，测试可以在测试用例编写完成之后从全量用例中抽取一部分比较精炼的用例作为开发自测用例，并且需要制定通过标准（通过率、自测报告、静态扫描结果），如果可以，开发的自测结果需要公开化
长期：
自由发挥一下，比如测试可以介入技术评审、代码审查，或者给开发特别标注重要场景处理等等
3、提单一个问题，开发说不是问题给我打回了
当下：
明确问题：根据现有的prd、单据、问题表现判断，这到底是缺陷还是产品设计问题，又或者说是交互问题
分类处理：如果是缺陷问题，那没什么说的，prd需求预期、复现路径、问题表现、沟通记录全都记录在工单里面，并且评估问题的优先级和严重程度，标注预期修复时间；如果是产品设计漏洞或者体验问题，工单流转到产品方，同样给出实际结果、询问预期结果，看下当前表现是否修改，修改方案是什么，并且要补充到prd
后续：
规范记录与留痕：我一直觉得bug单不是一个简单的记录，而是代表着每一个bug的生命周期，可以看到bug的产生、经过、和结果。回到这个问题上面，开发无故拒绝修复这是不好的，如果拒绝修复的bug在打回给测试时一定要给出拒绝原因并标注说明，这个bug涉及到的相关人员一定要通知到位。
建立bug判定标准：bug的创建需要标注这个bug的类型，程序bug是bug，需求bug也是bug，开发和产品都可以是bug的解决方。
长期：
这个场景更多体现的是沟通交流的场景，其实在这个方面上可以建立一下部门协作的信任
4、测试时间不够/测试工作量太多，但是项目马上必须上线
当前：
紧急盘点评估与测试范围分级：看下目前还有多少工作量、多少时间，剩余工作量主要是P0、1、2、3中的哪些，占比大概多少。
测试方案调整：看下哪些回归场景可以用脚本代替、或者代码批量校验、或者日志监控代替，合理分配时间。
资源申请与加班协商：能否借用当前其他测试人力，又或者能否借用开发、产品人力来协助测试，又或者说能否借用产品验收的时间，另外也评估下当前工作通过加班是否能完成。
产品需求方案调整：给出当前有质量风险的功能模块的测试情况，看下协商部分产品功能能否砍掉，或者调整为其他简易方案。
如果以上都行不通，直接向项目经理、各个leader给出结论，无法承诺高质量上线，项目风险很大。
如果项目经理说，就要上，就问题就有问题，没事，作为一个测试工程师，我还有招，来接着说
量化风险并通知到位：你要告诉所有人上线风险是必然存在的，列出没有覆盖的功能点、未执行的测试用例、未修复的缺陷清单、可能对业务造成的影响。看下上级领导在知情的情况下怎么决策处理。
项目经理说，有问题那咋了，我一定要上，好，继续
推动可控的上线方案：比如采用灰度发布、分批上线、功能开关、兜底方案，避免全量开放引发灾难。
制定线上事故补救预案：提前准备好紧急回滚方案、热修复方案、数据修复脚本、监控告警机制，确保出问题之后第一时间能快速响应解决。
后续：
复盘根因与流程改进：出现这种情况，线上事故肯定少不了。一定要明白为什么出现了这个事情，是开发提测质量不佳、产品需求变更频繁、测试方案错误、又或者说是排期估时不合理，哪里不合理我们就优化改进。
长期的话，我觉得还是规范流程比较重要