修订历史

image.png

正文目录

1. 概述... 1
1.1 范围... 1
1.2 发布... 1
1.3 综述... 1
2. 参考... 1
3. 定义... 1
3.1 术语... 1
3.2 约束... 1
4. 软件测试流程... 2
4.1 软件测试流程图... 2
4.2 软件测试流程说明... 2
5. 软件测试分类... 3
5.1 分类方式一... 3
5.2 分类方式二... 3
6. 软件测试方法... 3
6.1 静态测试方法... 3
6.2 动态测试方法... 3
6.2.1 黑盒测试... 3
6.2.2 白盒测试... 4
7. 软件缺陷管理... 4
7.1 BUG定义... 4
7.2 管理工具... 5
7.3 流程说明... 5
8. 软件测试文档... 5
8.1 测试计划... 5
8.1.1 计划说明... 5
8.1.2 计划要素... 6
8.2 测试用例... 8
8.2.1 设计原则... 8
8.2.2 用例要素... 8
8.3 测试报告... 9
8.3.1 缺陷管理... 9
8.3.2 报告要素... 9
8.4 用户手册... 9
9. 附录... 9
9.1 附录一：测试计划模板... 9
9.2 附录二：测试用例模板... 9
9.3 附录三：测试报告模板... 10
9.4 附录四：用户手册模板... 10

表格目录

表格1 术语表... 1
表格 2 BUG分类表... 5
表格 3 测试目标表... 6
表格 4 硬件测试环境... 6
表格 5 软件测试环境... 6
表格 6 测试风险表... 6
表格 7 测试需求样表一... 7
表格 8 测试需求样表二... 7
表格 9 测试需求样表三... 7
表格 10 测试需求样表四... 7
表格 11 测试计划安排... 8

软件测试流程规范指导文件

1. 概述

1.1 范围

软件测试流程规范指导文件。

1.2 发布

测试组所有成员。

1.3 综述

本文档旨在，指导测试人员工作，逐渐形成测试规范流程。

2. 参考

1. 《GB/T 25000.51-2016 系统与软件工程》
2. 《GBT 15532-2008 计算机软件测试规范》
3. 《软件测试规范》

3. 定义

3.1 术语

3.2 约束

无

4. 软件测试流程

4.1 软件测试流程图

image.png

4.2 软件测试流程说明

1. 测试人员应尽早参与需求分析和原型设计；
2. 测试人员应根据软件项目需求制定并确认《测试计划》。
3. 测试人员根据《软件需求规格说明书》和《测试计划》，制定并确认《测试用例》；
4. 开发人员完成编码工作后，提交待测软件；
5. 测试人员执行测试工作；
6. 测试通过，即未产生BUG或仅有建议性BUG，则对测试结果进行汇总分析，并编写《测试报告》；
7. 测试不通过，即产生BUG，测试人员将BUG提交给开发人员进行修改，直至BUG全部修改完成，并经过验证，未产生BUG或仅有建议性BUG，则对测试结果进行汇总分析，并编写《测试报告》；
8. 根据系统逻辑功能及业务功能，编写《用户书册》；
9. 将所有测试文档进行归档，如客户需要时，提供相关测试文档；
10. 如项目组或客户需要时，配合相关工作。

5. 软件测试分类

分类方式不局限于5.1和5.2两种，实际运用过程中可以择优选择。

5.1 分类方式一

1. 单元测试
2. 集成测试
3. 系统测试
4. 验收测试

5.2 分类方式二

1. 功能测试
2. 性能测试
3. 接口测试
4. 安全性测试
5. 易用性测试
6. 安装测试
7. 兼容性测试
8. 数据库测试
9. 业务测试
10. 回归测试

6. 软件测试方法

测试方法不局限于6.1和6.2两种，实际运用过程中可以择优选择。

6.1 静态测试方法

1. 代码审查
2. 代码走查
3. 静态分析

6.2 动态测试方法

6.2.1 黑盒测试

1. 等价类划分
2. 边界值分析
3. 判定表
4. 因果图
5. 随机测试
6. 猜错法
7. 正交实验法

6.2.2 白盒测试

1. 控制流测试
2. 数据流测试
3. 程序变异
4. 程序插装
5. 域测试
6. 符号求值

7. 软件缺陷管理

7.1 BUG定义

image.png

image.png

注：上表中举例描述未包含全部，后续可以调整补充。

7.2 管理工具

根据测试用例，执行测试过程中，若产生BUG，可以使用相关测试管理工具进行BUG记录跟踪，如：禅道、JIRA、Bugtags、BugFree、QC等。
根据我司现有情况，推荐使用JIRA工具，进行BUG状态跟踪。

7.3 流程说明

1. 测试人员提交BUG入库，状态设置为：“New”；
2. 开发人员在规定周期内解决问题，在测试环境中验证无误后，状态置为：Resolved；
3. 测试人员在Resolved版本上验证，验证已解决，在规定周期内关闭，状态置为：Closed；
4. 测试人员在Resolved版本上验证，验证没解决，周期内执行Reopen操作，状态重置为：Reopened，重复上述2）3）4）；
5. 测试人员在进行回归测试中产生BUG，步骤同上。

8. 软件测试文档

8.1 测试计划

8.1.1 计划说明

image.png

测试人员可以根据具体需求，选择合适的测试类型进行相应的文档编制工作。

8.1.2 计划要素

1. 测试目标

   
   
   image.png

2. 测试环境
   a) 硬件环境

   
   
   image.png
   
   

   b) 软件环境

   
   
   image.png

3. 测试风险

   
   
   image.png

4. 测试需求
   a) 单元测试

   
   
   image.png
   
   

   b) 集成测试

   
   
   image.png
   
   c) 系统测试
   
   image.png
   
   d) 验收测试
   
   image.png

5. 测试安排

   
   
   image.png
6. 测试管理
   a) 测试文档
   b) 测试用例
   c) 测试报告
   d) 用户手册
7. 缺陷管理
8. 用户手册

8.2 测试用例

8.2.1 设计原则

1. 基于测试需求的原则：应按照不同的需求，设计测试用例；
2. 基于测试方法的原则：应明确采用的测试用例设计方法，如等价类划分、边界值分析、猜错法、因果图等方法；
3. 兼顾测试充分性和效率的原则：应考虑测试用例内容的覆盖性、完整性、以及可操作性；
4. 测试执行的可再现性原则：应保证测试用例执行的可再现性。

8.2.2 用例要素

1. 用例名称：每个用例应具有唯一的名称；
2. 用例编号：每个用例应具有唯一的编号标识；
3. 测试追溯：每个用例均应和需求和测试计划中功能点关联；
4. 测试说明：简要描述测试方法、测试过程终止条件（正常终止、异常终止）、测试结果通过准则；
5. 前置条件：包括前提条件和约束条件，若存在特别限制、参数偏差或异常处理，应标识处理，并说明它们对测试用例的影响；
6. 测试输入：描述按顺序实施测试用例的执行步骤；
7. 预期输出：描述用例执行所产生的期望结果，即经过验证，认为正确的结果；
8. 实际输出：与预期输出比较是否一致，若一致则测试通过，反正测试不通过；
9. 测试结论：即通过、不通过；
10. 备注：补充说明等。

8.3 测试报告

8.3.1 缺陷管理

1. BUG定义
2. 流程说明

8.3.2 报告要素

1. 测试环境：硬件环境、软件环境等；
2. 测试版本：待测试软件版本；
3. 测试安排：测试人员、测试时间、报告时间等；
4. 未测试的内容：未测试项、原因等；
5. 测试问题说明：BUG级别、数据分析、BUG数量、测试结果等；
6. 测试结论：描述测试结果通过、不通过。

8.4 用户手册

用户手册是详细描述软件的功能、性能和用户界面，使用户了解到如何使用该软件。

9. 变更管理

若需求或原型设计存在变更，测试人员有权要求产品或需求人员提供相关变更记录文档，并进行相关测试记录文件变更，归档工作。

10. 附录

10.1 附录一：测试计划模板

image.png

10.2 附录二：测试用例模板

image.png

image.png

10.3 附录三：测试报告模板

image.png

10.4 附录四：用户手册模板

用户手册编写，参考：

1. http://www.jtsyjc.net/upimages/%E7%B3%BB%E7%BB%9F%E7%94%A8%E6%88%B7%E4%BD%BF%E7%94%A8%E6%89%8B%E5%86%8C.pdf
2. http://www.kyyec.com/front/html/service/learn-online