软件测试系列二《软件测试流程规范》

Posted 2022-04-16 再见孙悟空_

​​1. 目标 ​​

​​2. 背景 ​​

​​3. 测试工作总要求 ​​

​​4. 测试流程概述 ​​

​​4.1. 需求评审 ​​

​​4.2. 测试设计阶段 ​​

​​4.2.1. 测试计划编写 ​​

​​4.2.2. 设计测试用例 ​​

​​4.3. 计划/用例/方案评审 ​​

​​4.4. 测试实施阶段 ​​

​​4.4.1. 提交测试 ​​

​​4.4.2. 冒烟测试 ​​

​​4.4.3. 实施测试 ​​

​​4.4.4. 交叉测试 ​​

​​4.4.5. 系统测试 ​​

​​4.4.6. 测试总结 ​​

​​4.4.7. 出口准则 ​​

​​4.4.8. 软件测试暂停标准 ​​

​​5. 其他规范 ​​

​​5.1. 缺陷管理 ​​

​​5.1.1. 缺陷属性 ​​

​​5.1.2. 缺陷严重程度 ​​

​​5.1.3. Bug填写规范 ​​

​​5.2. 版本管理 ​​

​​5.3. 测试环境 ​​

​​5.4. 测试用例设计方法 ​​

​​5.5. 安全测试 ​​

​​5.6. 文档管理 ​​

​​5.7. 线上问题跟踪 ​​

​​5.8. 月度会议 ​​

1.目标

持续建设能够保证事业部产品质量的测试队伍和体系。

2.背景

测试团队刚成立，测试工作还没有形成一个完善的体系，为此编写此文档，旨在规范测试流程，明确产品各个阶段的测试工作，逐渐形成一个完善的测试体系，真正实现对产品质量的保证。

3.测试工作总要求

1. 建立支撑事业部的测试团队；
2. 新产品对外发布、发布后产品的缺陷修改发布（补丁），均需测试通过方可执行。紧急情况需对外发布时，需注明未测试。
3. 研发团队依据测试过程中定义的职责进行测试过程中的工作；
4. 测试团队对测试过程执行情况进行跟进并执行过程改进；
5. 测试团队依据《测试流程规范》开展工作；
6. 完善支撑事业部测试开展的《测试流程规范》；
7. 建立支撑事业部测试团队运行的软硬件环境；

4.测试流程概述

根据软件开发流程，各个阶段中测试工作以及对应的输出如下：

4.1需求评审

过程要点	详细说明
输入条件	需求定义完成
工作内容	测试团队成员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题，相关人员解答并确认。
输出条件	所有人员对需求无异议
参与人员	需求调研人员、产品经理、项目经理、开发组、测试组

注： 需求定义基本完成，此时应在评审会议召开之前发给测试团队，预留时间给测试相关人员熟悉、理解。

4.2测试设计阶段

4.2.1测试计划编写

针对需求分析文档和产品开发计划文档，测试组需要编写测试计划文档、制定测试策略及预估测试过程中的风险，并设计出合理的规避风险的策略，为后续的测试工作提供直接的指导。

过程要点	详细说明
输入条件	产品需求文档，产品开发计划完成。
工作内容	1.根据产品的需求文档、设计文档，按照测试计划文档模板编写测试计划。 测试计划中应该至少包括以下关键内容： 依据产品背景及要求，确定测试环境。 测试需求——需要测试组测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级 测试策略——确定产品的测试计划内容，整体测试的测试方法和每个测试需求的测试方法，同时做好测试进度安排及人员调整。 测试资源——本次测试所需要用到的人力、硬件、软件、技术的资源 输出文件——包括测试计划、测试报告等等 风险管理——列举出测试工作所可能出现的风险，归入到风险管理中 测试计划编写完毕后，必须提交给产品组全体成员，并由产品组组中各个角色组联合评审。 2.产品中编写测试方案要求： 所属产品中存在性能测试或安全测试，但在测试用例中无法描述，请编写测试方案，例如：《##性能测试方案》。 如果产品中单独执行性能测试或安全测试，则需要编写测试方案
输出条件	产品的《测试计划》/《测试方案》由产品组评审并通过. 在产品开发过程中，要适时的对测试计划进行跟踪，以及评估此计划的完整性、可行性，在产品结束时还要最后评估一下测试计划的质量。
责任人	项目组测试负责人

4.2.2设计测试用例

在需求分析文档评审确认后，测试组需要针对产品的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准，在出现线上问题后，测试用例会作为问题是否测试遗漏的依据。在用例的编写过程中，具体的任务和责任人如下：

过程要点	详细说明
输入条件	需求明确，测试计划明确
工作内容	1.根据需求说明书或需求规格说明书分析形成测试需求，再根据测试需求分解成测试项，根据测试项编写测试要点； 2.根据测试计划、测试需求/测试要点设计测试用例，设计参考方法： 等价类划分 边界值分析 错误推测等 因果图方法 判定表方法、场景法 业务知识及相关流程
输出条件	《测试用例》需要覆盖所有的测试需求 《测试用例》需要进行评审并通过 产品进行过程中，适时的根据需求变更来对测试用例进行维护。
责任人	测试组成员

备注：

测试过程中，根据实际执行情况，进行用例的完善，包括新增、修改、删除用例。

4.3计划/用例/方案评审

测试计划、测试用例、方案的设计工作完成后，需通知产品组相关成员召开评审会议。在这之前需要将待评审的内容发给相关人员熟悉和理解。

过程要点	详细说明
输入条件	测试计划、测试用例、方案完成
工作内容	评审测试计划、方案内容的正确性及合理性： 测试环境、测试资源； 测试需求范围，各个测试需求的优先级； 测试策略及风险管理等； 评审测试用例： 测试用例优先级 测试用例集基于需求的覆盖程度 评审方式： 当测试小组为多人时，可以讨论方式或者测试组负责人进行评审 当测试小组只有一个人的时候，建议将相关文档提交产品经理与产品组员进行评审。 测试计划评审责任人：项目经理、产品经理、测试组 测试用例评审：项目经理、产品经理、测试组、开发干系人员
输出条件	测试计划、测试用例、方案评审通过。
责任人	测试组，项目经理。

4.4测试实施阶段

提交测试：当开发完成需求的实现并自测试通过后，按照提交测试的流程规范将软件提交测试组进行测试；测试组接收测试软件包后，检查提交的文件是否正确、完整，不满足条件打回，开发重新提交。

冒烟测试：在确认提交软件可测后，执行冒烟测试。冒烟测试即对系统的主功能、基本业务流程进行测试，验证基本功能是否实现。冒烟测试通过，开始进行测试；冒烟测试不通过，打回版本包，开发修改再提交；

测试实施：根据测试用例、需求进行测试，将发现的问题提交到相应的管理工具，同时在测试用例中记录测试结果；测试完成一轮后，开发修改问题后，再次将版本提交测试，测试人员对之前的问题进行验证，同时对以前测试过的功能进行回归测试；根据实际产品中问题解决的情况进行多轮测试，直至问题解决。

交叉测试：功能测试完成，问题都修改以后，测试人员A将功能交由测试人员B进行交叉测试，这样可以避免单个人员测试存在漏测问题；

系统测试：每次版本发布前，需要对系统的主要功能（包含本次没有修改的功能）进行回归测试，保证主业务流程可以正常使用。

测试总结：测试完成以后，编写测试报告，对所测系统进行问题总结。

测试过程中的流程如下图：

4.4.1提交测试

过程要点	详细说明
输入条件	测试设计内容（测试用例、测试计划/测试方案）评审完毕，开发团队编码工作完成，并已完成内部测试；
工作内容	开发组根据测试计划上所规定的内容，将测试材料提交到SVN。 产品测试组负责人从SVN中获得提交的测试内容。 产品测试组检查提交部件的完整性和可测性； 检查测试提交单是否按照规范填写 能否正确安装/卸载； 检查提测的软件是否完整，能否进行测试
输出条件	提交部件经产品测试组检验通过，包含以下内容 （1）软件测试申请表（包含需求文档、设计文档、程序包等信息，明确标明已完成功能、未完成功能） （2）邮件通知相关人员 （3）提测功能涉及的安装部署操作手册（根据具体功能而定）
责任人	项目经理，项目组测试负责人

4.4.2冒烟测试

提交测试软件在冒烟测试时，若发现致命级别错误（大于等于2）、严重界面错误（大于等于6），则暂停测试返回开发；提交测试软件功能点少于计划范围内功能模块数的需要暂停，并与产品经理协商处理。

4.4.3实施测试

实施测试将花费测试组大部分时间，这些工作都是建立在前期很多计划工作的基础上。

过程要点	详细描述
输入条件	测试用例、被测软件的需求文件
工作内容	测试人员根据测试计划中分配给自己的测试任务和提供的测试用例，执行相应的测试工作。此过程可能需要分为多个轮次进行；每轮测试除了验证问题，还需要对所测功能进行回归测试； 记录测试用例的结果； 提交缺陷。
输出条件	测试用例中的所有任务被执行，结果被记录。
责任人	测试组成员

4.4.4交叉测试

过程要点	详细描述
输入条件	测试用例；被测功能所有问题已修改
工作内容	测试人员交换功能进行测试，对主要功能进行测试，同时根据个人测试习惯对主要功能进行测试。 记录测试用例的结果。 提交缺陷。
输出条件	交叉测试结果。
责任人	测试组成员

 4.4.5系统测试

过程要点	详细描述
输入条件	所有功能模块已经测试通过，问题已修改
软件测试系列二《软件测试流程规范》 ——软件测试流程和规范 重点部分总结 ——软件测试流程和规范 重点部分总结 ——软件测试流程和规范 重点部分总结 学习软件测试软件缺陷 图解测试之稳定性-如何开始稳定性测试