从QA视角谈谈“提测准入规范”应该是什么样

一、准入是什么？

1、准入测试是什么？

启动提测的准入条件。即在提测前，QA 会给一部分核心用例（P0 用例，包含性能自测用例）给研发，研发全部执行通过后，才能启动提测。

2、准入的意义在哪里？

• 提前发现问题：通过执行准入测试用例，可以在交付给测试团队之前发现和解决潜在的问题和缺陷，尽可能早的发现问题，节省成本。
• 确保提测标准：准入测试根据预先提供的核心用例，确保提测内容在交付给测试团队之前核心功能已经经过验证和测试。
• 优化研测流程：准入测试要求在开发完成后进行测试，鼓励团队在开发过程中注重质量和测试，以减少后期的 bugfix 工作。这有助于优化整个软件开发流程，提高开发效率和质量。

总的来说，准入测试对于确保项目质量、降低风险、提高开发效率和加强团队合作具有重要的意义和价值。

3、准入测试豁免原则

豁免确认角色：技术主R、测试主R
豁免之前应该进行充分的评估和讨论，以确保不会对系统的稳定性和质量造成不良影响。

• 未在开发提测前提供核心用例 case，QA 自行兜底；
• 优先级原则：如果某个功能或模块的紧急程度较高，可能会豁免准入测试，以便尽快提测上线。
• 重复测试原则：如果之前已经对某个功能或模块进行了充分的测试，并且没有发现问题，可能会豁免再次测试。
• 兼容性原则：如果某个功能或模块只在特定的操作系统、浏览器或设备上运行，并且已经在这些环境中进行了测试，可能会豁免在其他环境中进行测试。
• 可靠性原则：如果某个功能或模块已经在多个环境中进行了长时间的稳定性测试，并且没有出现问题，可能会豁免进一步的准入测试。
• 变更范围原则：如果某个功能或模块的变更范围较小，并且与其他部分的代码没有依赖关系，可能会豁免准入测试。

二、提测准入执行工作

1、准入如何做？

• QA 提供测试计划链接给研发，并分配自测准入用例。
• 研发执行准入用例，并标记执行结果，中途如果发现用例本身有问题，可联系 QA 沟通修改。阻塞或者未通过 case 需要通过文档记录。
• 研发发起 ShowCase。
• 研发执行准入用例通过后，在平台上发起提测。
• QA 执行准入用例：QA 在 kdev 测试计划上执行准入用例。
• 不符合准入标准，进行提测打回，后续重新发起提测

2、准入测试打回的标准以及原因都有哪些？

• 存在 P0 bug：P0 bug 大于 0 个即打回。
• 准入用例未执行：提供的 P0 准入用例没有执行。
• 夹带非本次需求代码：测试过程中发现了非本次需求的代码，即进行打回。
• 核心功能实现与需求不一致或未实现：需求理解有误差，实现与产品方案或设计方案不一致。
• 功能提测不完整：提测后发现有部分功能缺失或未实现，即使不是 P0 用例也要打回。
• 性能问题：频繁的崩溃或者 Crash，导致 block 后续工作。

三、测试用例的等级怎么划分？

影响 / 阻塞 P0 用例的成功执行的，都定义为 P0 bug。

在用例评审阶段，QA 团队需要对准入用例进行等级划分和同步，以确保研发和测试团队就当前需求的用例等级划分达成共识。

P0 用例需要占功能用例的比例：10% - 15%。

优先级	定义
P0	P0 表示最高优先级的准入用例，通常对应于核心业务功能或具有高风险（资金）的功能用例，确定此版本是否可测的用例。这些用例覆盖了最关键的业务场景和功能路径，必须通过自测才能进行提测。 1、此次需求核心功能用例，功能未实现或功能实现与需求严重不符，如果此功能失败，表示功能开发不完整。 2、此次需求的核心业务流用例，如果此用例失败，会阻塞其他用例的执行。
P1	P1 表示次高优先级的准入用例，涵盖了常见的业务流程和功能场景，但相对于 P0 用例来说，风险和影响程度可能稍低。P1 用例的执行和结果仍然非常重要，对系统的核心功能和用户体验有较大的影响。
P2	P2 表示中优先级测试用例，新功能的分支流程功能，反向用例功能，调用服务异常等检查用例。例如：上传素材时，错格、长度等的检查。页面操作后，页面提示的检查。调用服务阻塞或者异常时的处理情况等。
P3	P3 表示低优先级测试用例，异常场景的用例。例如：可用性问题。轻微的 UI 问题。

四、bug的等级怎么划分？

优先级	定义
P0	即主要核心功能受损，功能不可用，crash 问题，严重资源不足，闪退，无法测试，造成系统不稳定，且无法回退或绕过。 即 “马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
P1	即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 即 “急需解决”，表示问题的修复很要紧，很急迫，关系到系统的主要功能模块能否正常。
P2	即次要功能不可用，边界、异常未进行处理，界面、性能缺陷、兼容性等问题。 即 “高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
P3	即易用性问题，界面提示，小的性能问题。 即 “正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
P4	即建议性的问题。即 “低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。