测试过程控制及样例.docx

测试过程控制及样例.docx

《测试过程控制及样例.docx》由会员分享，可在线阅读，更多相关《测试过程控制及样例.docx（17页珍藏版）》请在冰点文库上搜索。

测试过程控制及样例

测试过程控制及样例 

1目的

确保测试的有效性和验证结果的可靠性，从而保证软件实现阶段质量和最终质量。

并作为验证及确认软件版本发布、项目验收的依据。

2适用范围

部门：

应用开发事业部总监、系统测试部、软件部门、业务部门。

业务：

模块测试、系统测试，β测试及试运行测试结果的收集。

3职责

1）   系统测试部经理负责组织测试人员编写测试工作计划和测试大纲，审核测试记录和测试报告，申请发布测试版或软件试运行。

2）   测试人员按照测试工作计划和测试大纲进行测试，填写测试记录，编写系统测试报告和用户测试报告。

3）   业务部门负责提供用户测试名单，系统测试部收集测试结果

4）   应用开发事业部（副）总监审批测试报告，批准测试版发布或软件试运行，通知业务部门。

5）   市场部为产品发布做准备。

6）   总经理批准紧急放行。

7）   系统测试部负责解释和修订本程序文件。

4工作程序

1）         测试准备

除单元测试外，在进行各种测试前应准备做好如下准备：

●   配备测试用硬件环境；

●   建立相应的运行环境和网络环境；

●                   准备测试数据；

2）         测试依据

测试依据主要包括：

测试工作计划、测试大纲、上阶段测试记录、上版软件产品用户反馈意见记录等。

3）         测试工作计划及测试大纲

系统测试部经理组织测试人员按照/3-07/QR/001《测试工作计划》编写测试工作计划，测试工作计划应主要包括测试进度、人员安排、设备环境的建立等。

测试工作计划经应用开发事业部（副）总监批准后实施。

系统测试部经理组织测试人员，根据软件《需求分析规格说明书》、《软件设计说明书》，按照/3-07/QR/002《测试大纲编写指南》编写测试大纲。

测试大纲作为测试的主要依据，测试大纲经应用开发事业部（副）总监批准后实施。

4）         测试实施

●     模块测试：

由测试人员依据《测试大纲》进行测试。

在测试过程中，测试人员应作好测试记录，填写测试问题记录表，确认模块测试是否通过。

如模块测试通过，可提交系统联调测试。

如模块测试未通过，测试人员应将测试问题记录表及时反馈给软件部门进行修改。

●     系统测试：

模块测试通过后，由测试负责人依据《测试大纲》进行系统联调测试。

在测试过程中，测试人员应作好测试记录，填写测试问题记录，确认系统测试是否通过。

如系统测试通过，产品可申请发布测试版，系统可申请试运行。

如系统测试未通过，测试人员应将测试问题记录表及时反馈给软件部门进行修改。

●     测试负责人应及时总结测试过程中的问题，按照/3-07/QR/004《测试报告编写指南》编写系统测试报告，《系统测试报告》经系统测试部经理审核后，提交应用开发事业部（副）总监批准。

经批准的《系统测试报告》由应用开发事业部和咨询部备案。

●     应用开发事业部（副）总监根据《系统测试报告》，必要时对软件产品进行抽测，批准产品是否发布版或是否进入试运行。

如批准版测试，则应及时通知市场部，同时提交用户手册初稿；如批准进入试运行，则应及时通知系统测试部建立试运行环境。

●     市场部为产品发布应做如下准备：

●     产品包装、各类手册、宣传资料等设计制作及产品宣传策划等工作

●     业务部门提供测试用户名单，制作版，并发给测试用户。

系统测试部应主动收集测试的记录和问题，并由测试负责人编制《测试报告》，经系统测试部经理审核后，提交给应用开发事业部（副）总监。

同时系统测试部经理根据系统测试和用户测试情况，提交正式版本发布申请。

●     试运行期间，系统测试部应主动收集测试的记录和问题，并由测试负责人编制《试运行测试报告》，经系统测试部经理审核后，进行项目提交。

5）         测试状态标识

各级测试必须在其测试记录上明显标识测试状态。

各级测试人员必须审核测试状态，标明“不通过”的软件项不能进行入下一阶段的开发或测试。

测试状态两类：

●   “通过”：

测试通过，可以转入下一阶段工作。

●   “不通过”：

测试没通过，不能转入下一阶段工作。

6）         紧急放行规定

紧急情况下，测试中出现的某项“不通过”，在不影响下一阶段开发、不影响软件产品结构、不影响用户使用的情况下，经应用开发事业部（副）总监审核后，由总经理批准后，可以放行进行下一阶段开发或提交发版。

但测试人员必须做好记录，并采取措施进行跟踪或后续版本发版后及时给用户予以更换。

7）         测试记录、测试报告保存期限

系统测试部应完好地保存测试记录和测试报告，并保存至下一版本发版后。

8）         系统测试部应按照/4-04《软件度量程序》进行软件开发过程度量。

5相关文件

内部质量审核程序

/3-03软件质量计划程序

/3-04软件需求程序

/3-05软件设计程序

/3-06软件实现程序

/4-05评审、验证和确认程序

/3-08软件产品发布确认程序

/4-02质量记录管理程序

/4-03软件度量程序

6质量记录

/3-07/QR/001测试工作计划

/3-07/QR/002软件测试大纲编写指南

/3-07/QR/003软件测试问题记录表

/3-07/QR/004测试报告编写指南

/3-07/QR/005版发版审批表

/3-07/QR/006试运行审批表

/3-07/QR/007用户测试报告表

7附录

/3-07/QR/001测试工作计划

测试工作计划

编号：

软件名称

版本号

系统测试部经理

编制日期

测试任务概述

所需资源

1．人员：

要求人数、时间、每人的专业技术水平

2．设备：

设备类型、应用阶段及时间

3．经费：

测试平台环境、工具描述

进度安排

描述测试人员工作的进度及人员分工

应用开发事业部（副）总监意见：

签字：

年月日

/3-07/QR/002软件测试大纲编写指南

软件测试大纲编写指南

1引言

11编写目的

说明本测试计划的具体编写目的，指出预期的读者范围。

12背景

说明：

a. 本测试计划所从属的软件系统的名称；

b. 该开发项目的历史，列出用户和执行此项目测试的计算中心，说明在开始执行本测试计划之前必须完成的各项工作。

13定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

14参考资料

列出要用到的参考资料，如：

a. 本项目的经核准的计划任务书或合同、上级机关的批文；

b. 属于本项目的其他已发表的文件；

c. 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。

列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2计划

21软件说明

提供一份图表，并逐项说明被测软件的功能、输入和输出等质量指标，作为叙述测试计划的提纲。

22测试内容

列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的，例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等。

23测试1（标识符）

给出这项测试内容的参与单位及被测试的部位。

231进度安排

给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准备输入数据等）。

232条件

陈述本项测试工作对资源的要求，包括：

a. 设备所用到的设备类型、数量和预定使用时间；

b. 软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，如测试驱动程序、测试监控程序、仿真程序、桩模块等等。

c. 人员列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数、技术水平及有关的预备知识，包括一些特殊要求，如倒班操作和数据健入人员。

233测试资料

列出本项测试所需的资料，如：

a. 有关本项任务的文件；

b. 被测试程序及其所在的媒体；

c. 测试的输入和输出举例；

d. 有关控制此项测试的方法、过程的图表。

234测试培训

说明或引用资料说明为被测软件的使用提供培训的计划。

规定培训的内容、受训的人员及从事培训的工作人员。

24测试2（标识符）

用与本测试计划23条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。

……

3测试设计说明

31测试1（标识符）

说明对第一项测试内容的测试设计考虑。

311控制

说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法。

312输入

说明本项测试中所使用的输入数据及选择这些输入数据的策略。

313输出

说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。

314过程

说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步骤和运行结束方式。

32测试2（标识符）

用与本测试计划31条相类似的方式说明第2项及其后各项测试工作的设计考虑。

……

4评价准则

41范围

说明所选择的测试用例能够检查的范围及其局限性。

42数据整理

陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同已知结果进行比较而要用到的转换处理技术，如手工方式或自动方式；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。

43尺度

说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。

应用开发事业部（副）总监意见：

签字：

年月日

/3-07/QR/003软件测试问题记录表

软件测试问题记录表

程序名称：

版本号：

测试人员报告

报告类型

严重程度

报告人

报告日期

问题描述

重现方法

修改建议

开发人员处理

出错位置

处理优先级

目前状态

出错原因

处理意见

新版本号

处理人

处理日期

处理后

测试人

测试日期

问题解决否

报告类型（1-6）：

1．代码错误2．设计错误3．建议

4．文档问题5．硬件问题6．疑问

严重程度（1-3）：

1．致命错误2．严重错误3．一般性错误

目前状态（1-2）：

1．尚未处理2．处理结束

处理优先级（1-4）：

1．尽快修改；2．一个测试阶段结束后再予修改；

3．如果有时间就改，没有时间可以暂时搁置；4．可忽略不改。

处理意见（1-9）：

1．暂时搁置2．修改完毕3．延期修改

4．测试人员弄错了5．不作修改

6．需要更多信息7．无法重现

8．无法修改9．不同意修改建议

/3-07/QR/004测试报告编写指南

测试报告编写指南

1引言

11编写目的

说明这份测试分析报告的具体编写目的，指出预期的阅读范围。

12背景

说明：

a. 被测试软件系统的名称；

b. 该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境之间可能存在的差异以及这些差异对测试结果的影响。

13定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

14参考资料

列出要用到的参考资料，如：

a. 本项目的经核准的计划任务书或合同、上级机关的批文；

b. 属于本项目的其他已发表的文件；

c. 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。

列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2测试概要

用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。

3测试结果及发现

31测试1（标识符）

把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。

32测试2（标识符）

用类似本报告31条的方式给出第2项及其后各项测试内容的测试结果和发现。

……

4对软件功能的结论

41功能1（标识符）

411能力

简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。

412限制

说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。

42功能2（标识符）

用类似本报告41的方式给出第2项及其后各项功能的测试结论。

……

5分析摘要

51能力

陈述经测试证实了的本软件的能力。

如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异对能力的测试所带来的影响。

52缺陷和限制

陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。

53建议

对每项缺陷提出改进建议，如：

a. 各项修改可采用的修改方法；

b. 各项修改的紧迫程度；

c. 各项修改预计的工作量；

d. 各项修改的负责人。

54评价

说明该项软件的开发是否已达到预定目标，能否交付使用。

6测试资源消耗

总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。

应用开发事业部（副）总监意见：

签字：

年月日

/3-07/QR/005版发版审批表

版发版审批表

编号：

软件名称

版本号

部门经理

申请日期

申请理由

应用开发事业部（副）总监意见：

签字：

年月日

/3-07/QR/006试运行审批表

试运行审批表

编号：

软件名称

版本号

部门经理

申请日期

申请理由

应用开发事业部（副）总监意见：

签字：

年月日

/3-07/QR/007用户测试报告表

用户测试报告表

报告人

姓名

电话

部门

问题：

文档界面业务功能

系统（模块）名称：

问题描述/影响：

附注及修改建议：

对软件的其他要求

计算机室签字：