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

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.测试工作总要求

建立支撑事业部的测试团队；

新产品对外发布、发布后产品的缺陷修改发布（补丁），均需测试通过方可执行。紧急情况需对外发布时，需注明未测试。

研发团队依据测试过程中定义的职责进行测试过程中的工作；

测试团队对测试过程执行情况进行跟进并执行过程改进；

测试团队依据《测试流程规范》开展工作；

完善支撑事业部测试开展的《测试流程规范》；

建立支撑事业部测试团队运行的软硬件环境；

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系统测试

过程要点

详细描述

输入条件

所有功能模块已经测试通过，问题已修改

工作内容

根据系统测试用例，对系统的基本功能进行测试，确保新增功能没有影响原有功能的正常使用

输出条件

系统测试用例执行通过。

责任人

测试组成员

4.4.6测试总结

阶段性测试报告

在约定的测试周期（暂定每轮测试）完成之后，测试负责人需要总结此次测试的结果，编写阶段性测试报告。

过程要点

详细描述

输入条件

测试组完成了预定周期的测试任务

工作内容

测试负责人根据此轮测试的结果，编写阶段性测试报告，主要应包含以下内容：

测试报告的版本

测试的人员和时间

测试新发现的缺陷数量

上一版本活动缺陷的数量

经过此轮测试，所有活动缺陷的数量及其状态分类

测试评估——写明在这一版本中，哪些功能被实现了，哪些还没有实现，这里只需写明和上一版本不同之处即可。对测试发现的问题进行分析，指明导致问题的原因，提出改进意见

急待解决的问题——写明当前产品组中面临的最优先的问题，可以重复提出

输出条件

在每轮测试结束之后尽快将符合标准的测试报告发给产品组。

邮件发送产品组成员，并将报告上传SVN

责任人

项目组测试负责人

系统测试报告

测试工作结束或即将结束时，测试组就要开始着手准备系统测试报告，进行总结的工作。

过程要点

详细描述

输入条件

测试组完成了所有的测试实施工作

工作内容

测试负责人根据测试的结果，编写系统测试报告，系统测试报告必须包含以下重要内容：

测试资源概述——多少人、多长时间。

测试结果摘要——分别描述各个测试需求的测试结果，产品实现了哪些功能点，哪些还没有实现

缺陷分析——按照缺陷的属性分类进行分析

测试需求覆盖率——原先列举的测试需求的测试覆盖率，可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明

测试评估——从总体对产品质量进行评估

测试组建议——从测试组的角度为产品组提出工作建议

输出条件

测试负责人完成了符合标准的《系统测试报告》，发送给全项目组。

责任人

项目组测试负责人

4.4.7出口准则

测试用例设计已经通过评审并执行完毕；

按照系统测试计划完成了测试；

达到了测试计划中关于测试所规定的要求；

系统满足需求规格说明书的要求；

测试中发现的错误已经得到修改，各级缺陷修复率达到标准：

致命、严重缺陷修复率应达到100%

一般、轻微缺陷修复率应达到95%以上

建议类缺陷（确认修改的）修复率应达到60%以上

4.4.8软件测试暂停标准

提交测试软件在进行冒烟测试时，发现致命级别错误或者严重级别错误，需暂停测试返回开发；

提交测试软件功能点少于计划范围内功能模块数的需要暂停，并与产品经理协商处理；

软件产品需暂停以进行调整时，测试应随之暂停，并备份暂停点数据；

软件产品在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。

5.其他规范

5.1缺陷管理

在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。

所有的缺陷需要记录到jira中。

5.1.1缺陷属性

属性名称

描述

缺陷标识

缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。

缺陷严重程度

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

缺陷优先级

缺陷的优先级指缺陷必须被修复的紧急程度。

缺陷状态

缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

缺陷发现的阶段(缺陷起源)

缺陷来起源指缺陷引起的故障或事件第一次被检测到的阶段。

缺陷引入的活动(缺陷来源)

缺陷来源指引起缺陷的起因。

5.1.2缺陷严重程度

序号

缺陷严重等级

描述

1.

致命缺陷

致命缺陷通常是一些致命的错误，造成系统或应用程序崩溃，死机，系统悬挂，或造成数据丢失，主要功能组完全丧失。

2

严重缺陷

通常是产品不稳定、不安全、或产生缺陷结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。

3

一般缺陷

程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常。

4

轻微缺陷

5

建议

具有建设性的问题。

注：对于缺陷严重等级的具体解释

严重程度

说明

致命缺陷

（Fatal）

致命缺陷通常是一些致命的错误，不能完全满足系统要求，基本功能未完全实现，死机，系统悬挂，系统崩溃或挂起等导致系统不能继续运行，或造成数据丢失，主要功能组完全丧失。以下属于致命缺陷：

1.由于程序所引起的死机,非法退出 2.死循环 3.数据库发生死锁 4.因错误操作导致的程序中断 5.重大功能错误 6.与数据库连接错误 7.数据通讯错误。

例如：

（1）架构设计不合理，影响系统性能以及功能的合理实现；

（2）重要数据库表设计不合理，数据流混乱；

（3）用户需求理解重大歧义，严重不符合常规业务逻辑；需求中的重要功能未实现。

（4）程序实现与设计间存在严重不一致；

（5）造成系统崩溃、死机,并且不能通过其它方法实现功能；

（6）（6）与数据库连接错误或异常中断。

（7）（7）常规操作中发生程序非法退出、死循环、导致程序无法运行、通讯中断或异常，数据破坏丢失或数据库异常且不能通过其它方法实现功能的；

（8）C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。

（9）系统性能不能满足客户的需求，①并发用户数不能满足用户需求，系统出现宕机或停止响应；②多用户并发时，系统响应时间不满足用户需求；③多用户并发时，程序数据处理出现错误，例如生成的序号跳号；④重要功能的响应时间不能满足用户需求；

严重缺陷

（high）

通常是影响系统要求或基本功能的实现，系统不稳定、不安全、或产生缺陷结果，使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。而且是常规操作中经常发生或非常规操作中不可避免的主要问题。以下属于严重缺陷:

1.程序接口错误 2.因错误操作迫使程序中断3. 系统可被执行，但操作功能无法执行（含指令） 4. 单项操作功能可被执行，但在此功能中某些功能（含指令参数的使用）无法被执行（对系统非致命的） 5. 在功能项的某些产品（选项）使用无效（对系统非致命的） 6.业务流程不正确 7.功能实现不完整，如删除时没有考虑数据关联 8.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现 9. 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误）9.在测试过程中执行安全测试是发现的缺陷一律设置为严重级别.

例如：

（1）程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，如：次要功能不能正常实现；

（2）重要功能不能按正常操作实现，但可通过其它方法可实现；

（3）程序接口错误；

（4）数据库表中有过多的空字段；

（5）数据库的表、业务规则、缺省值未加完整性等约束条件；

（6）（功能错误，功能输出非预期结果（例如：出现编译错误或404错误）；功能冗余；功能虽实现但不够完整；功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误。

（7）非常规的操作，造成程序非法退出、死循环、导致程序无法运行、通讯中断或异常，数据破坏丢失或数据库异常且不能通过其它方法实现功能的；

（8）重要功能不能按正常操作实现，但可通过其它方法可实现；

（8） （9）重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；

（9） （10）硬件或通讯介质发生异常恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；

（11） 缺陷的波及面广，影响到其它重要功能正常实现。

（12）采用安全测试工具或手工执行安全测试时，出现以下漏洞,如：

A.注入类缺陷；B．失效的身份认证和会话管理；C．跨站脚本；D．安全配置错误；E.敏感数据暴露；F．功能级别访问控制缺失；G．跨站请求伪造；使用已知易受攻击组件；H. 未验证的重定向和转发

一般缺陷

（Medium）

程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题：

1.操作界面错误（包括数据窗口内列名定义、含义是否一致） 2.打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） 3.简单的输入限制未放在前台进行控制 4.删除操作未给出提示 5.虽然正确性不受影响，但系统性能和响应时间受到影响 6.不能定位焦点或定位有误，影响功能实现 7. 显示不正确但输出正确 8. 增删改功能，在本界面不能实现，但在另一界面可以补充实现。

例如：

系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；

或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。

（11）（3）密码明文显示；

（4）经过一段时间运行后，系统性能或响应时间会变慢；

（5）操作界面错误（包括数据窗口内列名定义、含义不一致）；打印内容、格式错误；查询错误，既定的查询条件不能得到预期结果；

（6）执行添加、编辑、删除操作造成数据保存或删除错误；

（7）（流程中）按非正常业务流程运行时程序非法或中断退出；因错误操作迫使程序中断；

（8）为空字段输入控制不满足要求，非空字段未输入值可以保存成功；未识别、剔除导入的非法数据，对系统后续操作造成影响；

（9）一般数据项或标志位字段赋值错误，影响系统后续运行；

轻微缺陷

（low）

1.界面不规范 2.辅助说明描述不清楚 3.输入输出不规范4.长时间操作未给用户提示 5.提示窗口文字未采用行业术语 6. 可输入区域和只读区域没有明显的区分标志 7. 必填项与非必填项应加以区别 8. 滚动条无效

9. 键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字 段，在不同界面支持不同的快捷方式 10. 界面不能及时刷新，影响功能实现

例如：

（1）（1）界面在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，如：界面不规范、辅助说明描述不清楚、输入输出不规范（包括输入长度，输入字符限制，特殊输入要求（例如:特殊字符处理错误，包括：“‘；<>等特殊字符）判断，图片上传限制错误和文件上传限制错误等）、界面存在文字错误；

（2）（2）模块间按钮名称、用途不一致；

（3）（3）系统整体界面风格不一致；

（4）（4）提示信息不一致，易造成操作歧义；（执行删除操作未给出提示，或只有提示单一确认项）；

（5）提示窗口文字未采用行业术语；

（6）可输入区域和只读区域没有明显的区分标志；

（7）简单的输入限制未放在前台进行控制；

（8）长时间操作未给用户提示（或长时间操作结束后提示没有消失）；

（9）（9）在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；( 如用户名第一位用数字或特殊字符)；

（10）选择记录数据时，无法按照类型排序，选择不方便。

建议类缺陷

（suggestion）

建议性的改进要求（包括功能操作，校验说明，相关文档等）。

5.1.3Bug填写规范

关键字段

填写要求

标题

描述清楚问题所在模块哪个界面入口，简单描述问题

重现步骤

前置条件：如果问题有提前条件需要描述清楚

步骤：对于复杂问题需要清晰的描写重现步骤；要做到开发根据操作步骤可以重现问题

结果：描述实际操作结果

期望结果：描述正确的结果

截图：可以截图的问题尽量截图，将截图贴到重现步骤中，方便开发查看

Bug类型

根据Bug进行判断，是属于哪一类问题

严重程度

依据缺陷严重程度标准进行bug严重程度选择

问题优先级

根据问题的紧急情况，设置优先级

5.2版本管理

版本号定义标准

测试版本号：

版本号构成：主版本.子版本.修正版本号

初始版本时V1.0或者V1.0.0

修改bug或者局部修改，修正版本号+1

增加部分功能，子版本号+1，修正版本号归0

重大修改或者局部修正积累较多，系统全局有所改变，主版本号+1

发布版本号：

发布时在原版本号后加_Release

在更新SQL中增加版本信息，参考下列信息

/*========== 2018-02-26版本结束标识 开始================================*/

INSERT INTO Sys_ManualUpdateHistory(Muh_Flag,Muh_Version,Muh_Updatelog)

VALUES('BOS','V1.3.0_release','变价生效时间问题修改');

/*=========== 2018-02-26版本结束标识  结束==============================*/

5.3测试环境

a) 测试环境由测试人员进行维护，不允许开发人员对测试环境进行修改

b) 测试环境与开发环境分离，包括数据库以及程序包，不允许出现类似开发测试共用一个数据库的情况。

c) 每次部署新包前，备份测试环境数据库。

5.4测试用例设计方法

详见《测试用例编写规范与设计方法.docx》

5.5安全测试

根据产品情况决定是否需要进行安全扫描。

5.6文档管理

测试完成后，所有测试文档需要上传到云盘空间指定的目录下。

5.7线上问题跟踪

由实施人员或者客户提出的问题，测试人员在测试环境上进行验证确认问题，确认为问题后需要录入jira中，问题要特殊标识为线上问题。

5.8月度会议

由测试人员统计本月bug分布解决情况，分析当前测试功能存在的问题；产品组人员一起参与会议，对问题进行分析，提出解决方案

责任人：项目组所有人员

单元测试 压力测试 移动应用测试 MobileAPPTest 自动化测试

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。