【测试流程及规范】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 用例设计

测试用例设计是一切测试的基础，也是一个优秀测试人员的基本功，注意这里用的是“设计”而不是简单的“编写”，一份合格的测试用例一定是设计出来的，它需要从各个角度去思考以覆盖到所有可能的测试点，最终尽可能达到系统没有任何缺陷的完美程度。

3.3.1 用例基本规范

测试用例是测试过程中操作行为的方法指引，用例让整个测试过程有章可循，高效快捷，不至于有所疏漏，除以下情况外，其他需求都需设计测试用例。

可以不用设计用例&用例评审的场景：
生产修复上线Bug
不需要测试人员测试的需求（产品测试/开发测试）
小需求（UI、文案、交互、控件调整等小需求）

●功能需求有大有小，有的很小的需求甚至只是简单的改一行文字，这种简单的需求，测试的时候自然是不用画思维导图的，当然也不用设计测试用例，需要设计测试用例的往往是中等以及较大的系统功能，也就是实现逻辑复杂，所谓逻辑复杂站在测试的角度可以理解为，不能一眼就看到是否正确实现的功能，要验证其正确性往往需要在一定的条件下，进行一系列合理操作才能看到结果，这个时候我们就认为它是复杂的，需要画思维导图辅助设计测试用例。

3.3.2 用例设计规范

3.3.2.1 列大纲

在需求确认完成后，可以先列一个大纲，把所有的功能点或者流程全部梳理一遍，会对你写测试用例起到事半功倍的效果，这点主要是辅助测试用例设计，不作规范要求。

1）最好一个功能点写一个即可；

2）做到条理清楚、层次分明、简明扼要。

3.3.2.2 用例编写

测试用例编写可以按照功能划分或者业务划分来划分：
1）一个功能点最好只写一条用例，不要一个用例里面几个功能点糅合在一起，这样不方便用例执行；

2）若用例编写过程中需要立即确认的点，可以立即找产品确认；

3）若不需要立即确认，可以先标红表示，然后记录在需求确认清单再进行统一确认；

4）测试用例编写可以用 Xmind/Excel 模版编写；

5）测试用例需结合可视化，方便展示（增加流程图/原型截图）。

3.3.2.3 用例设计思路

一个测试对象的时候至少从以下六方面来考虑：
1）功能性
2）兼容性（钉钉、PC端）
3）易用性
4）可靠性、性能（考虑数据量大的情况加载数据是否较慢）
5）安全
●考虑页面权限、按钮操作权限、数据权限、导出权限等；
●考虑快速连续点击操作按钮，数据是否允许重复操作；
●考虑是否有安全漏洞。
6）生产历史数据兼容
以上考虑的点需在测试用例中体现。

3.3.3 用例模版、用例管理

测试用例管理在云效-测试管理-用例库，根据产品分别管理 。
在用例评审完成，修改为最终用例后，必须按模板导入云效对应产品用例库进行管理。（个别项目测试时间紧张的情况先把用例的Xmind文档线上化管理。）

用例需要根据模块-页面进行管理，导入数据时，注意根据云效支持的用例模版导入。

Xmind 用例模版示例：xxx项目_测试用例模版

Excel 用例导入模版：xxx项目_测试用例模版
请至钉钉文档查看附件《测试用例导入模板.xlsx》

如无需评审的用例，可以直接在云效-测试管理-用例库Web端编写用例，无需导入，提高效率。
云效导入用例帮助文档：https://help.aliyun.com/document_detail/323525.html#p-x3k-6og-8ra

3.4 用例评审

用例评审是测试流程中必备的环节。

3.4.1 用例评审流程

测试用例设计者组织用例评审会议，具体细则内容如下：
1）项目级开始用例评审工作前，测试人员需优先组织测试组成员开展内部用例评审工作，提前发现问题及时修改，为对外评审做好准备（涉及多位测试必须内部评审）；

2）非特殊情况，必须在开发提测之前，完成测试用例 & 组织测试用例评审；

3）预约用例评审时间与对应的产品经理、开发、测试、项目经理及项目组相关干系人提前确认沟通好，确认好之后在群内发布用例评审通知，创建日程&预约会议室，并提前把用例发至群内让大家查看；

4）用例评审会开展之前，测试人员需提前在会议室准备好设备，做好远程连接准备；

5）用例评审过程中测试人员评审记录问题问题，评审通过后对用例进行更新维护；

6）用例调整后，把用例（含冒烟用例）发至群内艾特对应人员，并将用例管理在云效上。

3.4.2 用例评审规范

测试用例设计者根据需要功能点宣读用例，内容包括：
1）时长最好控制在1H~1.5H左右，每次会议不得超过2H（如果是超2H，但每2H是不同开发参与，允许）；若东西太多，可以分多次评审；

2）用例评审时，表达要准确，思路清晰，语速适中，宣讲完一个模块后需要停下来问问大家是否有问题提出；

3）陈述时，要有主题和层级，若主题/层次切换，要有对应的语言过渡；

4）可视化结合：针对页面时，需先打开 对应的UI页面/原型/设计图；

5）评审过程中，参与人员会存在视觉和听觉疲劳，主讲人要抓住重点和重要人员；

6）根据原型、系统模块、功能点简要说明：重点评审业务模块复杂、需求优先级别高的模块；优先级较低的用例可不宣讲，内部已形成统一标准的用例可不宣讲（如有开发新人参加评审，已形成统一标准的用例也需要宣讲）

7）用例评审前，需要把有疑问的问题全部确认好，只保留产品经理无法敲定的问题才在用例评审会上讨论；

8）用例评审时，若有冒烟测试用例时，也需展示，简单宣读，并提及对应的开发。

3.4.3 用例修改

用例评审时相关人员必须全部到场，由测试人员进行组织。用例评审完成后测试人员把用例评审记录整理好，发送到钉钉群内，让相关研发人员查看一下还有没有遗漏或者记录错误的点。

1）测试用例评审通过或者未通过，需要做好相关记录。若未通过，请填写好未通过的原因。

2）若评审过程中有争议的地方，可以先记录在案。然后私下讨论，并把最后结果同步给项目组内成员。

3）若评审过程中修改的内容较小，可立即现场及时修改。

4）若评审过程中修改的内容较大，可以先记录，会议过后再修改。修改完成后，钉钉群里同步给相应的项目成员。

3.4.4 针对特殊情况说明

日常迭代工作中针对用例设计、用例评审的特殊情况，进行特殊处理，但是日常工作中必须尽量减少此类特殊情况，并且针对特殊情况，必须要有原因说明。（注：项目级必须有用例输出、用例评审环节，不做特殊处理。）

日常迭代工作中特殊情况举例：
1）临时插入测试执行任务，直接测试，无用例编写时间。
● 特殊处理：开发提测后，测试先冒烟保障主流程功能正常，边测试边梳理测试点，后期补上完整用例。
● 缺少流程节点：用例编写、用例评审、开发冒烟用例执行。

2）迭代前期已安排的中小型需求（非临时插入任务），用例编写期间时间不够（原因包括不限于：可能是其他任务插入导致的用例编写时间不够/其他任务优先级更高，需要并行处理），开发即将提测，测试执行时间不多。
● 特殊处理：测试可以先输出一份冒烟测试用例给到对应的开发执行，后期补上完整用例。
● 缺少流程节点：用例编写、用例评审。

3） 其他特殊情况，未一一说明，围绕：保障质量，把控风险，灵活应变，按期发布来调整，以上特殊情况都需与测试组长、产品经理说明。

3.5 测试准入

开发提测必须满足测试准入标准。

3.5.1 测试准入标准

1）填写提测申请，并提醒到相关干系人（产品经理、对应测试人员、开发组长、测试组长）
2）冒烟测试通过

3.5.2 提测申请要求

●提测申请填写要求
1）一个提测申请对应一个需求；
2）一个需求仅前端时，由前端开发人员编写；
3）一个需求仅后端时，由后端开发人员编写；
4）一个需求包含前后端开发时，需联调完成后一并提测，由后端开发人员编写；
5）填写完成之后，需要抄送给对应产品经理、对应测试负责人、开发组长、测试组长。
●提测申请包含内容
必须包括：提测需求名称、提测端、对应开发、对应分支名、自测情况。

3.5.3 提测申请内容形式

1.开发人员填写提测申请访问链接：（类似于调查问卷的方式填写）

2.开发人员填写申请提测需求、提测申请人、开发冒烟情况、提测端、提测分支、备注，提交表单（全部开发人员都可以填写，外部人员也可以填写）

3.填写完成后，钉钉群内可通知到大家（只能设置钉钉内部群通知）

不需要提测申请的需求场景：
1.生产紧急Bug
2.不需要冒烟测试的需求

3.6 测试执行

3.6.1 测试执行流程

测试用例编写+评审完成后，开发不一定马上会提测，在正式测试之前，以下工作测试有必要自己提前完成，推进开发完成：

1）测试数据准备完成（测试数据由测试、开发共同准备，日常迭代下，可以提前准备测试数据的情况下，需将数据准备好）；

2）在开发联调阶段，定期确认开发进度（风险前置预警，必须）
○提测前1-2天：开发进度是否正常，是否能按期提测
○联调当天：确认联调进度是否延误，是否正常进行
○自测当天：开发冒烟是否顺利
○提测当天：提测是否能按期提测
●测试负责人可以要求开发主动同步以上进度。

3）一旦上述情况发生，由测试负责人主导，群内提出风险点，讨论解决方案。必要时组织产品，研发，项目经理一起重新评估时间，确认是否适当增加测试时间，或延迟发布时间；

4）开发完成开发、自测、提测，测试环境搭建完毕。

测试执行阶段要做的事情：
① 冒烟测试 ② 测试执行 ③ 提交Bug，记录结果 ④ 验证Bug，回归测试 ⑤生成测试报告

3.6.2 冒烟测试

3.6.2.1 冒烟用例规范

1）用例编写时，需提取出冒烟测试用例，冒烟测试用例是总用例的 5-10%；
2）冒烟测试用例在用例评审的时候，需要宣讲并提醒对应执行开发；
3）冒烟测试用例评审后，修改无误后需给到对应的开发；
4）提测之后，测试也需执行同份冒烟用例，验证开发冒烟情况。
5）测试进行冒烟验证：
5.1）若冒烟不通过，立即打回，并记录冒烟不通过理由。
5.2）若冒烟通过，直接进入系统测试。

3.6.2.2 冒烟测试通过标准

开发冒烟用例执行通过率80%及以上，不通过则打回
无冒烟测试用例的，冒烟测试通过标准：主业务流程通过，增删改查操作正常，没有系统崩溃，页面跳转空白，主功能缺失，功能严重错误等阻塞问题，具体参照：《IT_开发提测标准规范_V1.0（正式运行）》

3.6.2.3 开发冒烟结果

1）测试需提前在 请至钉钉文档查看附件《IT_开发提测冒烟情况记录》填写开发冒烟的信息与用例条数；
2）推进开发执行冒烟用例，填写开发冒烟通过条数；
3）提测之后，测试执行冒烟用例，填写测试冒烟通过条数。

3.6.3 测试执行

3.6.3.1 测试执行规范

1）严格制定的测试计划、测试时间进行测试，满足质量优先，进度前紧后松原则；
2）测试执行中，评估测试执行时间不足，需及时上报风险；
3）测试执行需对用例描述的检查点逐一检查，避免遗漏；
4）执行过程中发现有前期设计遗漏用例，需补充到用例文档并执行验证；
5）执行过程中发现开发实现方案更优/实现效果与需求存在细小差别，但与需求不一致的情况，需与产品沟通确认；
6）用例的执行情况需要在用例管理工具中标明（用例通过、用例不通过、未执行、阻塞）；
7）使用测试管理工具记录、提交、跟踪缺陷，并督促开发人员复现、定位、修复缺陷，然后验证和关闭缺陷；
8）复杂需求（单个需求测试时间≥ 7个工作日），建议先内部测试后才能给到产品验收；
9）新人入职3个月内的测试任务项，建议先内部验收后才能给到产品验收；
10）产品协助测试：在需求评审期间/测试执行前期，若紧急插入任务，测试组内无资源协调完成测试，但产品又想按照某个特定日期上线，产品根据需求的优先级高：可以由自己来做测试 ； 也可以与用户需求澄清时，沟通降低需求优先级为低：来延后需求的上线时间，由测试人员来承担这部分的测试工作。（尽量减少产品来做测试的情况）

3.6.4 缺陷提交

测试环境缺陷统一在云效平台-需求管理项目-左侧进入缺陷，进行管理。
详情见：《测试规范_缺陷管理》测试环境缺陷管理

3.7 测试报告

测试报告是对测试的过程和结果进行详细记录的文件，是测试阶段最后的文档产出物。

3.7.1 项目

项目系统测试结束，要求输出测试报告。
项目的测试报告根据模版输出：《xxx项目_测试报告模板》

3.7.2 日常需求

日常需求测试结束，同样要求输出测试报告。
日常需求测试报告主要体现测试通过截图。
日常需求的测试报告根据模版输出：《xxx日常需求_测试报告》

可以不用输出测试报告的场景：
1.生产修复上线Bug
2.不需要测试人员测试的需求（产品测试/开发测试）
3.小需求（UI、文案、交互、控件调整等小需求）
4.紧急上线需求（来不及输出测试报告）
5.需求评审/用例评审中约定不需要输出测试报告

3.8 产品验收

日常：
1.产品可根据测试提供的测试报告、测试截图进行验收；
2.复杂功能有必要验收（复杂功能满足以下条件之一：单个需求测试时间>=3天/人，需求涉及3个以及3个以上部门）
3.复杂功能产品有必要到测试环境进行验收测试，尽量从主流程、测试报告未覆盖的场景、贯穿上下业务流程场景、用户习惯等角度进行验收，确保测试无遗漏；
4.日常验收以及打回标准见：《产品_内部验收通过标准_V1.0（试运行）》；

项目：
1.项目上线前，产品必须验收；
2.项目验收以及打回标准见：《产品_内部验收通过标准_V1.0（试运行）》；
3.验收问题需要记录：《验收项名称_验收问题模版示例》；

3.9 UAT验收测试

日常需求不做UAT验收测试强制要求，产品经理可以根据需求复杂程度、是否有必要UAT测试等多角度来看是否需要UAT验收测试，日常需求UAT测试全权由产品把控、负责、安排。测试人员负责UAT测试的问题复现、定位、提交、验证，反馈问题进度。

项目上线必须要有UAT测试环节。以下UAT准入标准、UAT测试细则、UAT准出标准均为 项目UAT验收测试标准。

3.9.1 UAT 准入要求

1）转UAT测试前提准备、资料齐全（需求文档/操作手册、UAT环境&数据准备、UAT场景用例、SIT测试问题解决情况）
2）UAT测试培训

3.9.2 UAT 测试细则

项目UAT测试分为以下5个行动项，各行动项下又细分为子项；

产品经理为UAT验收测试的主负责人，负责把控、推进UAT验收测试；

项目测试负责人、项目测试人员配合产品经理完成UAT验收测试中的细项，是UAT验收测试的次要负责人；

UAT业务测试人员主要负责业务数据确认、以及UAT测试执行；

3.9.3 UAT 准出要求

1）UAT测试用例执行率达到 100%（无效用例除外）；
2）所有发现的 BUG 都已记录在《问题登记表.sheet》并且全部修复完成、UAT验收通过；
3）UAT不修复/新需求/产品确认非 BUG 的需在《问题登记表.sheet》的【备注】中记录。

3.10 上线

需满足上线准入要求才可以上线。
日常&项目上线需发起：【IT004 系统发布管理流程】 以及测试通过/产品验收通过 ，项目需UAT测试通过。

3.10.1 日常需求

日常迭代上线前，产品需要走OA流程【IT004 系统发布管理流程】，目的：通知相关人员确认上线内容、分支。测试人员需要检查云效发布文档的内容是否为可上线的内容，上线后，需要对线上可验证的内容进行验证、相关数据字典配置等。

3.10.2 项目

项目上线前，参照项目的上线计划来安排上线验证计划，同样需要走OA流程【IT004 系统发布管理流程】，需上线后需要根据项目上线计划中的测试验证项来验证内容。

3.10.3 上线检查

1）开发在上线前需要检查有没有要删除的数据或者日志；
2）开发要申请的数据库，或者操作权限是否都已申请；
3）上线是否有上线顺序；例如：先system服务，后端才能上线。
4）上线是否有需要注意要的点；例如：先配置xx配置项，PC方可进行验证。
5）是否有历史数据需要处理；
6）数据字典、配置文件是否已配置；
7）相关账号是否已开通。

3.10.4 上线验证

上线后，测试人员需要对线上可验证的内容进行验证，确保上线后，生产环境正常运行，且本次发布内容成功上线。
验证需要关注本次上线内容成功上线，之前原有功能正常； 如果1个功能拆分为多个版本的，本次只更新某个版本，需要确保其他不上线的版本功能未被带上线。
如果无法验证的功能（比如：需要操作用户数据的操作）需要关注线上运行状态，观察是否有潜在的问题。

3.10.5 上线后缺陷处理

生产缺陷都需记录至IT服务台，详情见：《测试规范_缺陷管理》生产环境缺陷管理
●项目制的允许项目上线初期（1个月过渡平稳期）先表格登记，最终把表格内容导入到云效缺陷管理中。

上线后发现生产问题，若是测试发现/用户发现反馈到测试，需第一时间通知到产品，产品必须知晓。上线后发现缺陷，各自职责如下：
产品：了解缺陷、跟进上线事宜、IT服务台缺陷流转
测试：了解缺陷、复现、测试验证、IT服务台缺陷流转、上线验证
开发：定位、修复缺陷
运维：发布紧急生产hotfix

测试复现后，确定是Bug 或未排查到原因，需给到开发组长这边安排开发资源定位排查、修复。生产缺陷优先级最高，根据缺陷的严重程度，生产事故大小安排当天时间发布，或跟随最近一次发布迭代一起发布。