软件测试规范

一、目标

	制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。最终的目标是实现软件测试的规范化、标准化。

二、测试流程及说明

1、流程

2、说明

1）测试的依据：

《需求规格说明书》、《详细设计》、《概要设计》和界面原型图。

2）需求分析

（1）测试需求是制订测试计划的基本依据，只有确定了的测试需求才能够为测试计划提供客观依据;
（2）测试需求是设计测试用例的指导，只有确定了要测什么、需要测哪些方面，才能有针对性的设计测试用例;
（3）测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖。

3）需求评审

参与人员：产品、开发人员、测试人员
产品提出项目需求。
开发人员考虑功能实现的方案与可行性。
测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。

4）开发编写排期

开发人员需要根据需求功能点进行排期，然后将开发计划发送给参与项目的所有人员。

5）测试计划排期

测试人员根据开发计划，安排测试的具体测试时间，然后将测试计划发送给参与项目的所有人员。

6）编写测试用例

根据详细的需求文档，开始进行用例的编写。

7）用例评审

用例评审前，先将用例发送给相关人员，以便他们先了解用例将对哪些功能进行验证以及验证的细节。
在用例评审中，参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。

8）提交基线

开发人员完成所有功能后，对自己的功能进行一个自测。自测完成后提交测试进行基线。

9）转测

转测是开发把所有需求都开发完成，并自测完毕。
如果预测试不通过，打回，开发组返工，如果通过，测试组开始第一轮系统测试。
(1)第一轮系统转测试，测试组会执行所有测试用例，发现缺陷提交问题单，并每日汇报测试进展。第一轮测试结束后，测试组将所有的问题单跟踪提交给开发人员，由他们进行修改。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。
(2)在开发修复bug期间，测试组会根据第一轮系统测试对测试组写的测试用例进行修改和增加，开发修改bug结束，提交一个新的版本给测试组。
首先是回归缺陷，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问题继续提交缺陷进行修复，直到缺陷率低于用户要求，测试组将进行最后一轮的大版本测试，结束系统测试。具体测试轮次根据版本质量和项目复杂度而决定。

10）测试通过

经过两到三轮或四轮的测试后，直到没发现新的问题、或暂时无法解决、或不紧急的问题，通过上级确认，可以通过，编写测试报告。

11）测试报告

测试报告包括对软件功能的结论，说明该项目软件的开发是否达到预定目标，是否可以交付使用。总结测试工作的资源消耗数据：如工作人员的水平级别数量、机时消耗等，记录测试结果与发现及本项目测试工作所得到的各项输出的承载体，根据输入与计划、要求的对比来总结此次项目所获得的经验。

三、Bug的管理流程

1.bug生命周期及状态（对于bug的状态要实时更新）

New:（新的）
Assigned（已指派的）
Open（打开的）
Fixed（已修复的）
Pending Reset（待在测试的）
Reset(再测试)
Closed（已关闭的）
Reopen（再次打开的）
Pending Reject（拒绝中）
Rejected(被拒绝的)
Postponed（延期）

2.bug等级划分

1）致命：造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题；
2）严重：系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，以及功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启，自动退出，关联程序间调用冲突，安全问题、稳定性等；
3）一般：功能没有完全实现但不影响使用，功能菜单存在缺陷但不影响系统稳定性；
4）建议：界面，性能缺陷，建议类问题，不影响操作功能的执行等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。

3. 提交bug的书写规范

bug包含的内容：包含了所属项目，所属模块，版本，指派给相应的人员，BUG标题，步骤，优先级，以及bug环境、附件（可以附上出现的缺陷截图）等。
注意事项
1）开发、测试双方有争议的bug，必须与产品确认才可进行下一步的操作；
2）测试需及时验证已修复bug；
3）谁提交的bug要由谁验证关闭。

四、测试中输出的文档

1、测试计划

内容：

1. 引言：目的、背景、范围、定义、参考资料；
2. 测试内容：测试功能清单；
3. 测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具；
4. 测试环境：硬件环境、软件环境、特定测试环境要求；
5. 项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结；
6. 实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件；
7. 风险管理。

2、测试方案

内容：

1. 项目简介：概括的对这个系统做一个描述，让别人知道系统是做什么的，简洁而有重点；
2. 测试目标：对于本次系统测试要达到什么样的标准，缺陷率应该控制在多少以内，定一个合理的目标；
3. 测试策略：这个部分主要包括（1）数据流图描述；（2）本项目的测试难点；（3）本项目测试的关键点；（4）需要特别申请的测试资源；（5）性能测试；
4. 测试的内容和方法：这部分主要包括：（1）场景测试；（2）功能测试；（3）功能模块衔接测试；（4）接口测试；（5）界面测试；（6）兼容性测试；（7）性能测试；（8）兼容性测试；（9）安全性测试；（10）可靠性测试。
5. 测试数据：包括（1）系统参数；（2）存量环境数据；（3）业务参数；（4）交易参数；（5）接口文本数据；
6. 测试环境：（1）各应用测试环境的版本基础；（2）测试环境硬件要求；（3）测试环境连接图；
7. 测试工具及其模拟器：根据项目实际是否使用
8. 测试人员安排：
9. 测试计划：（1）主要工作安排；（2）测试轮次安排；（3）批量计划；
10. 人力资源评估；
11. 风险及依赖。

3、测试用例

1）内容

包括用例编号、测试项目、测试标题、预置条件、测试输入、测试步骤、预期结果、实际结果等。

2）用例级别划分

对测试用例进行优先级的划分，一般需要从三个方面考虑：
P1：确保系统基本功能及主要功能的测试用例
P2：确保系统功能的完善方面的测试用例
P3：关于用户体验，输入输出的验证以及其他较少使用或辅助功能的测试用例对应的，我们可以对测试用例分为三个级别：高、中、低
高（优先执行）：即关键路径的测试用例，包括最常执行的功能、基本流程的输入以及界面数据有效性校验作为高级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件功能渐趋稳定；
中（次级执行）：即可接收级测试的用例，包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件可以进行发布了；
低（最后执行）：即建议执行的测试用例，也就是说该级别的测试用例不是不重要，而是该级别的用例在整个项目的生命周期内不是常常被运行，包括：GUI、界面显示、错误信息提示不统一、可用性、压力和性能测试等。

4、测试报告

内容：

1.概述：一般会在概述中添加项目背景、需求描述等信息；
2. 测试过程：主要包含评审记录、测试范围、测试用例；
3. 功能实现清单：列出是否已按本次测试计划实现功能；
4. 测试统计：包括资源统计、执行情况、问题统计、问题列表、遗留问题；
5. 测试总结：主要总结本次测试测了哪些内容、用例覆盖程度、bug解决程度等，以及最终是否决定通过本次测试。