【测试流程及规范】8000字超详细完整版

前言：

1. 首先注明该文由本人原创，转载时需注明出处；
2. 团队背景：测试团队加上我一共5名，Java开发10多位，前端3位，产品4位，还有架构工程师、运维等；
3. 公司IT团队开发的系统仅供内部员工使用（500人内）
4. 测试流程及规范 仅供大家借鉴哈，不建议直接照搬，实际情况请根据团队情况进行删减补充~

一、目的

规范测试流程，提高测试效率和测试质量。

二、背景

测试流程是开展测试工作的基础，本规范对测试流程中的关键节点进行约定，明确测试时必须进行的工作项，所有测试任务必须按照本规范执行。

本流程只适用于测试部内部，测试组所有参与的项目或者任务都可以参照此流程，可根据实际的项目情况对此流程中操作步骤进行删减。

三、测试流程

3.1 需求评审

3.1.1 提前查阅需求文档

需求评审未开始前，产品经理需要输出需求文档提前（至少提前1天）同步给到对应开发、测试人员。

1）若产品经理未提前给到需求文档，测试人员需推进产品经理在评审前把需求文档给到大家，并且有权拒绝临时加塞的需求评审。（临时加塞的需求评审是指：未提前沟通时间，未提前给到需求文档的需求评审，或者是 临时给到需求文档，立马开会的需求评审，这种会议效率极低）

2）测试人员需要在需求评审前查阅需求，尽可能的发现需求中的问题，描述不清晰的地方，可以让产品经理细化需求。

3.1.2 整理需求确认清单

需求评审未开始前 / 过程中 / 结束后，有什么需求不明白的地方，可以全部汇总在一起，整理为一个需求清单然后统一发给产品确认。
1）若有需要紧急确认的需求，可以直接先找产品确认。
2）若不需要紧急确认的需求，可以一起给产品确认。
3）若当前产品不能及时确认的需求，需产品给出最后确认时间。
4）若需求清单确认完成后，测试需要将需求确认清单发送在钉钉群里同步给相应的开发，减少二次确认成本。

3.1.3 不进行需求评审的需求

对于非必要需求评审的小需求、小优化项，产品经理需要提前说明，测试人员也可以主动确认是否需要需求评审。

1）对于不开展需求评审的需求，测试人员同样需要充分理解需求，对于有争议且无法在钉钉群内沟通达成一致的需求，有必要让产品组织评审确认。

2）有什么需求不明白的地方，同样需要整理需求确认清单，确认完成后发送在钉钉群里同步给相应的开发，避免开发实现与需求不一致。

3.1.4 需求评审期间对需求进行“测试”

1）明确测试在需求评审阶段已经开始。测试工作是贯穿于项目的整个流程中的，并不是在开发完成编码提测后才开始的。需求阶段要进行需求评审，每个阶段都有测试需要做的工作，测试人员首先要有这个意识。

2）认真听取需求评审过程中不同的意见，相关内容及修改的地方。参加需求评审的过程中，必须认真地听取需求讲解的内容，大家讨论的不同意见。

3）积极从以往的经验中提出自己不同的意见。在需求评审的过程中，根据自己以往的测试经验，对业务的掌握情况，用户使用的习惯，对本次需求提出不同的意见。从需求评审阶段对需求进行测试，及早地发现需求中存在的问题。

4）督促大家对所有异议达成一致。需求评审时难免出现不同的意见，大家需要进行讨论一下，从而找到最优的解决方案。当然也有对异议达不成一致地方，测试需要协助会议的组织者督促大家达成一致，或是给出解决方案的时间节点。

5）根据需求内容明确测试范围。确定本次需求需要保证的内容，可能影响的原有业务，是否需要其他业务的支持等。

3.2 测试计划

计划与控制是测试第一个阶段的内容，后面所有的工作都是以测试计划为指导进行的，所以测试计划中的时间、任务和资源的安排显得很重要。

3.2.1 项目

项目的测试计划是归属在项目计划中的。
1）测试主要负责人需要根据项目需求情况、预估填写测试时间；

2）预估后测试组长、产品经理会根据预估情况进行调整，敲定后以测试计划为准；

3）测试计划实施过程中，如有延期风险的情况，需要提前及时提出&说明原因（开发提测延期/冒烟不通过可能会导致延期/测试执行延期/并行任务冲突可能会导致延期），再协商应对方案（资源协助/测试时间调整/测试任务调整等）

3.2.2 日常需求

日常需求的测试计划是根据对应迭代的上线时间来安排的。
1）测试组长会根据组员对需求的熟悉程度、工作饱和度等情况来安排任务指定给测试人员（一般需求的测试只会安排一位测试人员）；

2）需求的测试任务的截止时间为一般统一为上线前1-2天，测试人员需要根据自己的任务合理安排每一个测试任务，确保测试按时保质完成，输出测试报告，并给到产品验收的时间；

3）测试计划实施过程中，如有延期风险的情况，需要提前及时提出&说明原因（开发提测延期/冒烟不通过可能会导致延期/测试执行延期/并行任务冲突可能会导致延期），再协商应对方案（资源协助/测试时间调整/测试任务调整等）

3.3 用例设计

测试用例设