软件测试工作流程规范

软件测试工作流程规范 The manuscript was revised on the evening of 2021 软件测试工作流程规范

xxxxx有限公司 2017年4月20日

修订历史记录 版本 日期 修订模块 修订者 说明 文档新建 Ivy Zhang 目录 1. 目的 通过规范公司测试流程，确保测试工作的规范性和有效性，以验证软件产品的质量满足用户的需求。测试作为质量控制的一种有效手段，运行测试用例找出软件中潜在的各种缺陷，通过协助开发人员修正缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和降低质量成本。通过测试管理为产品与过程改进提供可靠的数据分析，起到缺陷预防的作用。 本过程的方针： ➢ 实施测试策划活动

➢ ➢ 根据测试策划所规定的要求编写测试需求与用例，实施相关的测试活动 ➢ 管理测试活动中发现的产品缺陷

2. 工作范围 测试人员在软件开发过程中的任务：

1) 参与评估软件需求，编写测试需求； 2) 根据用户需求，编写软件测试用例； 3) 在开发人员完成单元测试后，进行模块测试，以期尽早发现bug； 4) 根据软件测试用例，执行集成测试，寻找尽可能多的bug； 5) 6) 对bug进行追踪与分析，保证bug及时得到修复； 7) 对软件性能进行衡量，并进行测试总结，提交软件测试报告书。

3. 工作职责 工作内容 输出文档 提交每天工时申报 OA工时登记 提交每周工作周报 工作周报 每月5号前提交上月工作考核评价表 月工作考核评价表 若有加班/请假/调休，在OA上走相应流程 加班/请假/调休登记 测试组长，测试计划阶段提交测试计划、测试用例 测试计划、测试用例 测试执行阶段提交测试报告 系统测试报告 测试评估阶段提交遗留问题分析报告 测试遗留问题分析报告

4. 测试流程

产品需求人员 开发人员

需求分析  需求分析 需求分析由产品人员制定，细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。

 需求评审 所有参与项目人员进行，开发人员、测试人员、QA人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需求了解需求。

 开发人员编写排期 开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。  测试计划排期 测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

 编写测试用例 根据详细的需求分档，开始进行用例的编写。  用例评审 在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。 然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。

 执行测试 测试人员第一轮测试，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，完成第一轮测试后，需要写测试结论，发到相关人员。然后进行第二轮测试，第二轮会对第一轮中发现的问题进行重点回归。

 测试通过 经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。 验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。 5. 测试准备

5.1 测试计划 根据需求文档和项目计划制定测试计划。测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划完成后应该在项目组内进行评审。 5.2 测试用例

测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题。

依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例，发现需求与设计中的问题后，与需求作者及时沟通确认。 5.2.1 测试用例设计方法

5.2.2 测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试。

在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。 5.2.3 测试用例操作步骤

5.2.4 1) 在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用例，在原有测试用例的基础上依据系统需求文档对测试用例的进行修改、更新，评审通过后将使用该测试用例测试被测系统。 2) 3) 在测试的执行过程中和进行回归测试后，对已设计的测试用例进行维护更新。 5.2.5 测试用例选择准则 5.2.6 ➢ 测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等； ➢ ➢ 测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的； ➢ ➢ 测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。 5.3 测试环境 5.4 根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境，完成对测试项目所需软硬件资源的准备工作，使软硬件资源得到满足。

5.5 测试数据准备 5.6 完成对测试项目基本数据的准备操作，包括数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关的测试数据。 6. 测试执行

6.1 测试准入条件 6.2 1) 不接受无详细需求文档和开发说明的项目； 2) 需要测试的项目至少提前2个工作日提交测试进行需求分析； 3) 开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是可以正常使用。 6.3 项目测试阶段 6.4 测试人员依据测试计划和测试用例进行测试活动。测试一般分为两个阶段： 1) 测试执行阶段：该阶段测试人员测试出bug后将缺陷提交至缺陷管理库。

2) 回归阶段：开发修改完bug之后，测试进行验证回归。 3) 6.5 测试退出标准 6.6 1) 全部的测试用例执行完毕； 2) 按照系统测试计划完成了系统测试，系统测试的功能覆盖率达100％； 3) 系统的功能和性能满足产品需求规格说明书的要求； 4) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准； 5) 系统测试后不存在1、2类缺陷； 6) 3类缺陷允许存在，不超过总缺陷的10％。

6.7 测试变更 当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需时间，提出变更风险。如变更情况被项目组通过，测试人员将按上述流程进行变更测试。 7. 缺陷管理 7.1 BUG管理流程

7.2 BUG状态  激活  1) 新创建的bug； 2) 3) 已解决但验证未通过的bug； 4) 已关闭的bug重新出现需要再次激活。  已解决  开发已经修改完成的bug。

 关闭  已验证通过的bug或系统工程师确认转为需求的bug。 7.3 BUG解决方案

 已解决  Bug已经被修改，待测试进行验证。  设计如此

 测试人员理解错误，无需改动，即无效bug。

重新打开 （Reopen）

提交BUG （New）

确认BUG

修复 BUG

关闭BUG （Closed）

是否延期 BUG验证 保留

BUG

Y

N N

Y N

Y  重复bug?  已经有同样的bug，需标明重复bug号。

 无法重现  根据测试写的重现步骤，无法重现bug。

 延期处理  确实是bug，但现在不解决，以后处理。

 新增/变更需求  分析确实是存在问题，但需求没有描述清晰，应指派给需求确认，进行需求的新增或变更。 7.4 BUG优先级

 高 阻止与此密切相关功能的进一步测试，需要立即修复。  中

 必须修改，不一定马上修改，必须修改，发版前必须修正。  低

 对系统的影响较小，如果时间允许应该修改。 7.5 BUG严重等级

 严重（一类） 不能执行正常工作功能或重要功能，因软件原因导致系统死机等，须马上修正致命错误。 通常有如下情况： 1) 系统停机（含软件、硬件）或非法退出，且无法通过重启恢复；

2) 系统死循环； 3) 与数据库连接错误； 4) 数据库发生死锁或程序原因导致数据库断连； 5) 数据通讯错误或接口不通； 6) 重要功能无法正常使用、功能不符合用户需求。  一般（二类） 影响系统功能或操作，应用模块错误使业务中止无法进行后续操作，主要功能存在严重缺陷，影响到产品的使用，但不会影响到系统稳定性。 具体基本上可分为： 1) 业务流程错误或不完整；

2) 业务数据来源不正确、业务数据紊乱或丢失；