测试过程文档导读

修订记录

所有权声明：

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

1 前言

随着测试过程的越来越完善，产生的各种测试过程文档也越来越多，这些文档都与相关的测试活动有紧密的联系，它们分布在公司软件过程改进库和测试组配置库中不同的目录下，编写本文档的目的就是为了引导不同的读者能方便快捷地找到自己所需的测试文档，并且在适当的时候使用好它们，同时对整个测试过程管理体系的具体实施过程有一个框架性的了解。

本文按照各个关键测试活动来进行编写，在每个测试活动中使用到的文档详见“文件清单”。

2 文件结构

测试过程管理体系文件主要包括三大类：模板、规范和支持性文件。模板如：测试计划、测试任务单和测试报告等；规范中有系统测试用例、用户手册和自动化测试脚本等编写规范；支持性文件是进行各类测试技术评审活动使用的检查表、各类测试方法和测试活动中所用到工具的关键使用说明等参考文件。

模板

支持性文件

规范

3 文件清单

注：

testSCM为测试组配置库，在129.129.5.7上；SEPG为公司软件过程改进库，在129.129.5.4上。SEPG库中“test”文件夹下的三个目录：Checklist（检查表）、Standard（规范）、Template（模板）中的文件在测试组的配置库中也有相同的拷贝。有关测试方法等一些支持性文件（Support File）只存放在测试组的配置库中。

4 关键测试活动

4.1 测试策划

项目开发计划和开发进度计划评审后，测试组成员以此为依据，编写系统测试计划和系统测试进度计划。

《系统测试计划》是可裁剪的，《系统测试进度计划》是必须的（小项目除外）。

不管有没有编写系统测试计划，都需要对系统测试进度计划进行评审，以确保时间上能与开发进度相一致，并且保证整个软件测试活动是有序的。系统测试进度计划除了使用Project进行编写外，还需要放入工作管理系统中进行实时管理。

《系统测试计划》的评审需要软件工程组各类成员的代表共同参与，评审的具体形式可根据项目开发计划中的要求进行。对《系统测试进度计划》的评审形式一般为走查。

4.2 创建缺陷库

所有的项目在开发过程中所产生的各类缺陷（包括测试发现的和评审走查等发现的缺陷）都需要使用TestDirector来进行记录和跟踪管理，所以在项目组成立后就需要建立该项目的TD库。

由项目经理确定项目组成员名单和相关权限，填写《新建/修改TD库申请表》并提交给TD管理员。TD管理员根据一般建库流程来进行建库，然后加入公用的定制信息，并给相关人员授权。

TD管理员在建好TD库以后，及时反馈给项目经理，项目经理确认后，TD库建立完成。

4.3 测试设计

系统测试设计是测试工作的指导，是软件测试执行中必须遵守的准则，更是软件测试质量稳定的根本保障，所以写好测试用例至关重要。

系统测试用例在项目组的TestDirector库中进行编写。

测试人员需要熟读并理解系统的需求，并把系统需求转化成相应的测试需求，录入到TD的“Requirements”中进行管理。

测试用例的设计可参考《黑盒测试技术》中提到的几种设计方法进行设计，编写方式参见《系统测试用例编写规范》，测试用例在TD的“test plan”中进行编写。

项目结束时，必须把系统测试用例导成word文档，可参考支持性文件中的《TD导出测试用例操作说明》，导出模板采用《系统测试用例》，导出后放在项目组的配置库中。

4.4 技术评审

技术评审的目的是在评审过程中发现错误，从而防止错误被传播到软件过程的后续阶段。一些测试文档是测试工作开展的重要依据，也是整个项目文件的重要组成部分，所以更要强调评审的重要性。

需要进行评审或走查的测试文档至少为：《系统测试进度计划》、《系统测试用例》和《用户手册》。《系统测试计划》是可裁剪的，当有《系统测试计划》时，则必须评审。

对测试文档的评审或走查分为两种情况：一种是项目组层面上需要对测试文件进行评审或走查，这种情况主要由项目组进行主导，具体的过程可参见《技术评审规程》。另一种是测试组内部的评审或走查，主要是对测试用例和用户手册的设计、编写情况进行内部走查。

根据公司的实际情况，测试用例的编写和评审都将采取迭代的方式进行，逐步完善；在整个设计过程中，可以阶段性的部分评审，但在正式测试前应至少完成一次项目组内的整体性评审。评审时，测试人员应讲解测试用例的编写思路，主要的关键点，并提出不能确定的问题，由熟悉需求和设计的人员进行确认和补充，以达到系统测试用例有效覆盖系统需求的目的。

项目组对测试用例和用户手册的评审是非常关键的，评审时要有熟悉需求和设计的人员参加，确保正确性和完整性。项目组内走查需填写《技术评审报告》。

测试组内部进行走查时，测试用例要使用《系统测试用例检查表》，用户手册使用《用户手册检查表》。走查发现的缺陷都需录入TD库中进行跟踪。测试组内部的走查录入测试组的TD库中，项目组内走查发现的缺陷录入项目组的TD库中。

4.5 被测系统的交接

在系统测试正式开始实施之前，项目组和测试组需要对被测系统进行交接，目的主要是证明该系统是可测试的。演示任务必须在测试环境中执行，项目组需要将程序发布到测试组的服务器上，在一次测试当中程序不允许更新，具体可参见《系统测试环境发布流程》。

由项目经理将本次测试的范围进行功能演示，一般情况下要有SQA在场，演示后开发、测试双方对系统的可测试性、时间要求等情况进行沟通，并在《系统功能测试任务单》上进行签名确认。在对系统进行第一次演示时，项目组需要结合需求说明的PPT文档，先对测试人员介绍系统需求以及业务逻辑关系，然后再开始系统的操作演示。

被测系统的交接分为以下几个主要的步骤：

项目经理将《系统功能测试任务单》提交到测试组。

测试人员仔细阅读任务单，了解测试范围、时间等方面的要求。

项目经理对本次测试范围进行功能演示，演示时测试人员可以边看边记录自己的问题，在演示后请项目经理进行回答，也可边看边提问；项目经理也需要在演示的同时将主要的测试点，关键业务逻辑关系告知测试人员。

演示完成，双方对系统的可测试性进行确认。演示通过的要求参见《软件系统测试规程》上的具体描

述，如果达成一致可以测试，则执行步骤5；如果达成一致不可测试，则本次任务直接关闭，等待下次再启动；如果对可测试性达不成一致的意见，则项目经理可以先与测试组组长沟通，如果仍不能形成双方都可接受的处理方法，则可进一步向高级经理反应情况。

由测试人员开始执行测试。

4.6 测试执行

测试执行目前主要有三种类型：功能测试、兼容性测试和性能测试。每一种类型的测试任务都由相应的测试任务单来启动。

系统架构主要是B/S结构，测试方法可参考支持性文件中的《基于Web的系统测试方法》。

4.6.1 功能测试

正常或临时的功能测试任务的执行都需要《系统功能测试任务单》来实际启动。一轮测试任务从开始到结束按以下三个主要步骤来执行：

在测试正式开始实施前，由项目经理填写测试范围、要求、时间等关键信息，将任务单提交到测试组。项目经理（或项目组成员）对被测系统进行功能演示。

测试成员执行测试，测试人员在执行功能测试时，根据测试用例，同时结合《功能测试方法》、《界面测试方法》等支持性文件中的测试点进行测试，使测试更全面、更彻底。公司的《web应用界面设计规范》也是测试时的一个依据。

任务完成后，及时将测试情况和缺陷统计填写在任务单上并反馈给项目经理，项目经理电子签名确认后，标志着本次测试任务的结束。测试任务单需存放在各项目组的配置库中，同时入测试组配置库。

4.6.2 性能测试

性能测试任务的执行都要由《性能测试任务单》来启动。

项目经理填写测试模块及功能、并发用户数、基础数据准备等关键信息，将任务单提交到测试组。

测试人员编写《性能测试计划》、准备测试脚本和基础数据，基础数据量大时可由项目组协助增加。执行性能测试，性能测试一般由项目组成员和测试组成员共同参加，将观察情况填写在性能测试计划上。

任务完成后，测试组人员对参加性能测试成员的填写情况进行汇总，填写在任务单上并反馈给项目经理，项目经理电子签名确认后，标志着本次测试任务的结束。测试任务单需存放在各项目组的配置库中，同时入测试组配置库。

4.6.3 兼容性测试

兼容性测试任务的执行都要由《兼容性测试任务单》来启动。

项目经理填写测试环境等关键信息，将任务单提交到测试组。

测试组人员准备兼容性测试环境，必要时可向项目组人员或公司网络管理员进行协助。

执行兼容性测试。

测试成员执行测试，任务完成后及时将测试情况和缺陷统计填写在任务单上并反馈给项目经理，项目经理电子签名确认后，标志着本次测试任务的结束。测试任务单需存放在各项目组的配置库中，同时入测试组配置库。

4.7 填写缺陷

填写一条好的缺陷可以减少测试人员和开发人员的沟通成本，加快缺陷修复的速度，同时也增加测试的可信度。

执行系统测试时，测试人员发现的缺陷录入项目组的TD库中。

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

测试进行到一定阶段，测试人员将一些有争议的缺陷导出Excel，采用《缺陷记录跟踪表》的格式，整理好后反馈给项目经理或高级经理。

4.8 编写用户手册

好的用户手册可以帮助用户快速入门，是用户正确、充分使用软件的前提。所以必须按照既定的规范认真写好用户手册。

在线帮助统一用Robohelp来进行编写，采用统一的《在线帮助》模板。编写方式参见《Robohelp 使用说明》和《用户手册编写规范》。

生成html和chm两种格式提供给项目组。

在项目结束时需从Robohelp中导成word文档。导出的word格式并不能符合我们的要求，必须进行修改格式、插入图片和建立图表索引等，具体参照《用户手册》的模板进行修改。导出word方法可参考支持性文件中的《Robohelp导出word操作说明》。

4.9 测试总结

测试报告是测试结果的体现，所以也是比较关键的测试文档。一般在测试完成后编写、总结、提交。目前有三类测试报告：

《出厂测试报告》是可对外提交的测试报告，各项内容的测试结果在报告中已经注明，表明该系统已经在公司内完成测试。

《现场测试报告》是可对外提交的测试报告，但各项内容的测试结果是留给用户去填写的，该报告一般由公司的成员去用户现场做现场确认测试的时候使用。

《测试总结报告》是公司内部的测试报告，一般不对外提交。里程碑会议上需提交阶段性测试总结报告，项目完成后对整体测试情况进行的总结，比如测试用例的统计、测试情况的分析、缺陷的统计、经验的总结等。如果从项目开始或从上里程碑到当前里程碑没有软件测试活动，则里程碑会议上测试组可以不提交测试总结报告。

4.10 自动化测试

自动化测试工具包括功能测试工具WinRunner、性能测试工具LoadRunner和诊断工具Diagnostics。WinRunner作为自动的功能测试工具，可以在回归测试中发挥较大的作用，主要用于取代人工来执行经常需要重复的操作。目前我们主要对经常重复的关键业务流程或功能用WinRunner来进行回归测试。WinRunner脚本的编写要求请参见《WinRunner编程规范》。

LoadRunner作为性能测试工具，主要用于并发用户的测试，它可以通过组合不同功能的脚本和不同的访问人数来模拟真实的大批量用户并发使用系统时的情况，并可以监控当时的一些性能数据，如响应时间、访问量等。LoadRunner脚本的编写要求请参见《LoadRunner编程规范》。

Diagnostics作为性能诊断工具，在LoadRunner并发测试时，监视服务端响应情况，在并发结束时，将收集到的数据以图表和数据的方式反馈给用户，让用户了解各层和各个事务的时间消耗情况，并指出各个事务中时间消耗比重较大的方法，有的还能定位到具体的SQL语句。Diagnostics的安装请参见支持性文件中的《Diagnostics的安装步骤》。目前Diagnostics诊断工具由技术研究部进行使用，为项目组的性能问题诊断提供服务。