软件系统测试规程

comtop-st-stprd

深圳市康拓普信息技术有限公司

Shenzhen Comtop Information Technology Co.,Ltd.

修订记录

深圳市康拓普信息技术有限公司

版权所有  不得复制

Copyright © 2007 by Shenzhen Comtop Information Technology Co., Ltd.

目   录

1    目的    1

2    适用范围    1

3    图例说明    1

4    规程文档结构    1

5    规程    2

5.1    进入准则    2

5.2    测试策划    2

5.2.1    流程图    2

5.2.2    活动描述    3

5.3    测试设计    3

5.3.1    流程图    3

5.3.2    活动描述    4

5.4    测试执行    4

5.4.1    流程图    4

5.4.2    活动描述    5

5.5    缺陷管理    6

5.5.1    流程图    6

5.5.2    活动描述    7

5.5.3    缺陷等级    8

5.5.4    缺陷状态    8

5.6    变更管理    9

5.7    退出准则    9

5.8    规程接口    9

6    文件清单    9

7    图表索引    10

1目的

使软件系统测试活动是规范和有计划的

及时对软件产品进行系统测试，验证系统是否满足需求规格的定义，找出与需求规格不相符合或与之矛盾的地方

测试中发现的缺陷保证被记录、跟踪直到关闭；对项目的缺陷数据进行量化的分析

2适用范围

本规程适用于以下人员

项目经理

软件测试组

软件项目组

配置管理工程师

3图例说明

在本文中用到了以下图例，特此说明：

        过程：用于描述要执行的活动和过程；

        判定点：用于描述流程中是否满足某个条件后的分流点；

        接口：用于描述引用的接口规程；

        文档：用于描述输入、输出的文档；

        开始节点：用于表示流程的入口；

        结束节点：用于表示流程的结束；

4规程文档结构

图表1：规程文件结构

文档结构图说明：

1．《系统测试计划》是根据项目的规模和重要性来确定，是可裁减的。一般来说，《系统测试进度计划》是必须的。但对于公司认定的小项目，可以没有《系统测试进度计划》，具体要求按照公司的相关规定《小项目软件过程管理指南》执行；

2．《系统测试用例》在测试管理工具TestDirector中进行编写和管理，可以根据需要导出到Word；

3．项目组可根据系统的实际需要，通过提交功能或兼容性或性能测试任务单来启动相应的测试任务，后二者的测试一般都需要在完成功能测试的基础上才可执行；

4．《缺陷记录跟踪表》是指从TestDirector里导出缺陷记录到Excel时的文件格式，测试中发现的缺陷都将使用TestDirector来进行记录、跟踪和管理；

5规程

5.1进入准则

项目启动，并由项目经理与部门（高级）经理、测试组组长商量，确定此项目需要安排的测试人员加入。

5.2测试策划

5.2.1流程图  

图表2：测试策划流程

5.2.2活动描述

《系统测试计划》或《系统测试进度计划》都需要项目组提供相关的项目文档作为主要编写依据；

《系统测试计划》是可裁剪的，《系统测试进度计划》是必须的（小项目除外）；不管有没有编写《系统测试计划》，都需要对《系统测试进度计划》进行评审，以确保时间上能与开发进度相一致，并且保证整个软件测试活动是有序的；

《系统测试计划》的评审需要软件工程组各类成员的代表共同参与（限于篇幅在图中没有表达出来，特在此说明），评审的具体形式可根据项目开发计划中的要求进行；对《系统测试进度计划》的评审形式一般为走查；

5.3测试设计

5.3.1流程图

图表3：测试设计流程

5.3.2活动描述

《系统测试用例》的评审需要软件工程组各类成员的代表共同参与，特别是熟悉需求和设计的代表必须参加，评审的具体形式可根据项目开发计划中的要求进行；

编写《系统测试用例》的时候，需要遵循《系统测试用例编写规范》上的具体要求。应以《系统需求规格说明书》作为主要的依据，设计文档、实际可运行的程序雏形都可作为编写的辅助材料。在编写过程中，应多与分析、设计人员沟通，不明确的地方以项目经理的答案作为衡量标准；

根据公司的实际情况，测试用例的编写和评审都将采取迭代的方式进行，逐步完善；在整个设计过程中，可以阶段性的部分评审，但在正式测试前应至少完成一次整体性的评审；

《系统测试用例》评审时，测试人员应讲解测试用例的编写思路，主要的关键点，并提出不能确定的问题，由熟悉需求和设计的人员进行确认和补充，以达到确保《系统测试用例》有效覆盖系统需求的目的；

测试组内部走查的时候，需要使用《系统测试用例检查表》。

5.4测试执行

5.4.1流程图

图表4：测试执行流程

5.4.2活动描述

项目组在单元测试完成后，可提交系统测试的任务。项目经理应在演示前提交《系统功能测试任务单》，任务单上应列出该版本修改了哪些特征项，以及指明测试的要点和时间要求；

测试评估是指，由项目经理或指定人员把《系统功能测试任务单》上的本次测试的范围在测试系统中进行功能演示，在演示的同时进行业务重点的讲解。在对系统进行第一次演示时，项目组需要结合需求说明的PPT文档，先对测试人员介绍系统需求以及业务逻辑关系，然后再开始系统的操作演示。双方对系统的可测试性达成一致后，即可开始测试；如果双方对可测试性无法达成一致时，则应及时向高级经理反映，并相互协商解决问题；

系统提交测试时，一般都需要演示，如果项目组认为不需要演示，则必须经过测试组组长的同意

演示任务必须在测试环境中执行，项目组需要将程序发布到测试组的服务器上，在一次测试当中程序不允许更新，具体可参见《系统测试环境发布流程》。

测试组接收测试任务前系统演示要达到的要求：1）演示时没有任何明显的错误；2）上次测试发现的缺陷都已修改。

项目组给测试组系统测试计划预留时间至少为2天。

一轮测试结束后，测试人员应及时将测试结果及主要情况、缺陷统计反馈填写在《系统功能测试任务单》上，并提交给项目经理审核，电子签名确认，标志着一轮测试任务的结束。测试任务单需存放在各项目组的配置库中，同时入测试组配置库。

在一个项目中进行多次测试时，每次测试的结果都反馈在《系统功能测试任务单》上，在整个项目的测试工作完成后，应编写《系统测试总结报告》；在项目开里程碑会议的时候，需要提交阶段性的《系统测试总结报告》；

测试组组长应对各个项目的《系统测试总结报告》进行审核，项目组也应对各类测试报告进行走查；

测试人员应严格按照测试进度计划的安排，进行测试工作，如果根据项目的实际情况，时间上有差异的，则应尽力配合项目组方面的时间安排，有需要时应主动采取加班等方式来保证按时按质地完成测试任务，必要时可向测试组组长申请加派人手增援；

测试人员应严格按照测试用例执行测试，并在测试中不断对测试用例进行完善和补充；

项目组可根据系统的实际需要，向测试组提出功能测试以外的测试请求，比如：兼容性测试和性能测试，需要提交相应的《兼容性测试任务单》或《性能测试任务单》，这两种类型的测试不需要演示，只要具备测试条件（一般在完成功能测试的前提下）即可进行。

执行性能测试前需要编写《性能测试计划》，跟项目经理或主要开发人员确定性能测试的范围和各项性能预期指标，编写性能测试脚本，组织和执行性能测试，并作好观察和记录。性能测试一般需要2天的准备时间，所以项目组有性能测试需求时，可尽量提前一些通知测试组，以方便做准备工作。

5.5缺陷管理

5.5.1流程图

图表5：缺陷管理流程

5.5.2活动描述

在TD的缺陷库中新增一个缺陷之前，应先检查有没有类似的缺陷已经存在，避免重复。缺陷填写的详细要求请参照《缺陷填写规范》；

在任何情况下，“拒绝”、“暂缓”和“冻结”缺陷的时候，都需要在TD的备注中填写“拒绝”、“暂缓”或“冻结”的原因；并与测试人员当面沟通，避免因为理解上的偏差或系统版本的偏差等原因而随意地放过一个缺陷；暂缓缺陷和冻结缺陷，需要经过评审，由产品经理对缺陷定位和解决.在缺陷管理中只有产品经理有权限对缺陷进行“冻结”。

对”拒绝”和”暂缓”的缺陷有争议，测试组可以在系统演示时向项目组提出。对于每条暂缓的缺陷，项目组与测试组协商确定是否需要再测试此类缺陷。

原来暂缓和拒绝的缺陷，如果缺陷不存在了，由测试组关闭。测试组每两个月进行批量关闭。

在项目组中只有项目经理具有“Rejected”缺陷的权限；对每一条缺陷需要填写“原因分析”；

当测试人员对项目经理“拒绝”的缺陷有争议并无法达成一致的时候，可向评审委员会提出申请。评审委员会，是指由高级经理、项目经理、开发、测试以及其他相关的专家组成的评审小组，对有争议的缺陷进行最终的确认。（评审委员会的成员并不是固定的，而是根据实际情况的需要组成）；

从上面的流程图可以看出，对缺陷的管理实际上就是通过TestDirector来对缺陷的状态进行变化；也就是说缺陷从产生到关闭都是在TD里进行的，如果需要将缺陷记录形成文件，可以通过TD来导出到Excel或其他格式的文件；

5.5.3缺陷等级

严重程度

图表6：缺陷等级

5.5.4缺陷状态

说明：该缺陷状态的划分是参考MI公司的测试工具产品TestDirector中对缺陷的管理。

5.6变更管理

在项目的开发过程中，当有影响到测试的变更（如需求变更、开发进度变更）发生的时候，项目经理应及时通知相关的测试人员，测试人员接到变更通知后，应对该次变更情况作出分析，然后根据分析结果，对《测试进度计划》或《系统测试用例》等测试资源进行修改或补充（即将变更部分重新走测试策划、设计、执行的流程），并采取走查方式跟相关的开发人员进行确认；

项目上线后一个月集中以会议形式给测试组演示需求/功能上的变更，在演示后，测试人员根据演示情况更新测试用例。

5.7退出准则

系统测试用例通过了评审，测试用例达到了有效覆盖系统所有可测试的需求（功能/特征项）；

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

测试结果，系统满足需求规格说明书的要求；

在系统测试中发现的缺陷都已经得到合理地处理（理论上只要不是“Rejected”和“frozen”的缺陷都应该被“Closed”）

5.8规程接口

《配置管理规程》

《技术评审规程》

6文件清单

图表1：规程文件结构    2

图表2：测试策划流程    3

图表3：测试设计流程    4

图表4：测试执行流程    5

图表5：缺陷管理流程    7

图表6：缺陷等级    8

图表7：缺陷状态    9