测试、测开场景类面试题（一）

最新推荐文章于 2025-03-06 01:05:13 发布

原创最新推荐文章于 2025-03-06 01:05:13 发布 · 659 阅读

CC 4.0 BY-SA版权

文章标签：

3 篇文章

订阅专栏

在参加测试或测试开发岗位的面试过程中，基本都会问到场景题，这类型问题如果回答的让面试官满意，也是加分项。该类型的题目和技术类型的题目不同，属于测试经验类型的题目，这对于未参加工作或转型测试的同学来说不太好回答。

暂停测试：面对需求偏差的时候，立即暂停相关模块的测试工作，避免人力资源成本的浪费；
确认问题：首先，明确需求文档、策划文档等设计与当前系统的实现存在哪些不一致的点，确认需求是否发生变更但未及时同步 QA 同学；带着问题和相关开发人员、PM 进行核对，明确是需求本身有歧义还是开发或者 QA 的理解错误；
问题反馈与记录：记录需求差异点，包括需求文档相关的截图、系统实际表现截图、沟通记录，标明该需求偏差影响的范围，包括功能模块、用户体验、其他可能关联的需求等；
制定并推动问题的解决方案：首先再次对需求进行确认，由 PM 明确最终的需求，更新需求文档并同步所有相关方；如果是开发人员的理解错误，则推动开发团队进行修复，打回并同步重新提测的时间点；QA 同学可以根据最新确认的需求调整或优化测试用例，准备执行测试工作；

需求阶段：首先，QA 同学在需求评审阶段需要更加敏锐的洞察出一些可能模糊的需求，在需求阶段提前沟通解决，避免后续的资源和人力浪费；其次，确保需求文档和策划的设计基线化，确认后在项目管理中进行记录，明确所有相关人员，有任何改动需要及时同步，用该基线作为开发和QA同学后续开发和测试的唯一依据和标准；
严格把控需求变更管理：对于需求的变更，一定要有严格的变更流程，避免口头形式的沟通引起的遗漏，变更后由 PM 及时同步更新文档并同步给开发和 QA 同学；
测试准入检查：该类型问题一般都会在测试准入的时候发现，因此，在测试准入的时候，增加需求一致性核对的环节，特殊情况或特殊时期可以提前介入测试，也能更好的和开发确认需求理解的一致性，对需求的理解多一次保证，若有异议也可以尽早发现，避免损失最大化；
文档沉淀和总结：对于该类型的问题，可以在解决之后进行文档沉淀和总结，在团队内外都可以进行经验分享，警醒整个产研团队在以后的工作过程中避免该类型问题的发生；

首先，和开发同学进行沟通，明确开发进度与预期的偏差，如完成率、完成剩余工作所需的pd数；其次，让开发开出进度低于预期的具体原因，如需求频繁变更、需求模糊或需求排期冲突等，技术层面实现困难，人力不足，开发项目管理层面计划过于乐观、进度监控不合理、无风险预案等；

优化开发流程：要求开发进行严格的细化任务管理，避免排期不准，提升执行性；
加强相关人员沟通：QA 同学可以每日主 R 对齐进度，避免理解偏差的同时也可以提前发现开发进度的风险；需求管理中可以建立严格的风险预警机制，如进度落后 10%-20% 则报风险；
总结分享：最后也可以在 QA 内部进行该类型问题的总结分享，避免之后的需求发生这类型的问题，或者更高效率的解决该类型的问题，提高团队效率和需求质量；

首先，第一时间标明 p0 级别bug，要求开发最高优先级修复，并且由 QA 同学给出最低接受修复时间，否则会影响测试进度；
对于阻塞性bug，拉相关人员建立临时沟通机制，测试人员演示问题并由开发人员评估修复时间；
若是开发不好解决或者到时间限制还未解决，则给需求相关人员抛出风险，沟通解决方案，QA要做到对需求负责，质量更是整个需求团队共同的责任，我们QA不推锅，但是也不揽锅~；

首先，需要明确为什么会有阻塞性 bug，从经验来看，阻塞性 bug 就可以定性为不符合提测准入条件，同时，开发也未进行充分自测；
对于开发未进行充分自测的原因，QA 需要要求开发给出具体原因，排期太紧？需求太多、频繁变更？又或者是个人原因？
若是需求频繁变更，则需要 PM 给出变更原因，需要进行严格的需求评审；
最后，对于 QA 而言，我们需要严格把控提测质量，可以提供高质量的核心 case 让开发进行严格自测，另外，QA 也可以提前介入测试，这样也可以在开发阶段就发现一些严重问题，避免过多资源浪费和损失；QA 在整个需求期间，可以活跃的把控项目质量，不限于提测之后，因此，作为 QA 需要进行更加严格的需求管理机制，这样也能更好地避免这类问题出现；