航空订票系统(软件测试报告)

航空订票系统测试计划说明书

目录

1引言 (3)

1.1编写目的 (3)

1.2测试计划概述 (3)

1.3被测试系统概述 (3)

1.4测试计划制定依据 (4)

1.5预期读者 (4)

2任务概述 (4)

2.1目标 (4)

2.2运行环境 (4)

2.3需求概述 (4)

3测试范围 (5)

3.1测试用例 (6)

3.2测试特性与软件需求的对应关系 (8)

3.3被测试特性 (9)

4术语定义 (9)

4.1软件错误与缺陷定义 (9)

4.2其他术语的定义 (10)

5测试目标与策略 (10)

5.1测试目标 (10)

5.2测试方法 (10)

5.3测试工具 (10)

5.4测试地点 (10)

6测试状态转换标准和再启动要求 (11)

7测试通过准则 (11)

8应提供的测试文档 (11)

9测试资源需求 (11)

9.1硬件需求 (11)

9.2软件需求 (11)

9.3网络需求 (12)

9.4人员需求 (12)

9.5其他需求 (12)

10人员、职责及培训要求 (12)

10.1人员组成 (12)

10.2人员分工与职责 (12)

10.3培训要求 (12)

11测试进度 (13)

12风险和应急 (13)

12.1影响计划的潜在因素 (13)

12.2应急措施 (13)

13测试的局限性 (14)

14计划的批准 (14)

15参考文档 (14)

附录Ⅰ软件错误与缺陷的定义 (15)

附录Ⅱ测试状态转换标准和再启动要求 (16)

附录Ⅲ测试通过准则 (18)

附录Ⅳ人员分工与职责 (19)

2 / 20

1引言

1.1 编写目的

为保证《飞机订票系统》的测试工作有序进行，保证《飞机订票系统》正确实现需求规格说明书中的功能定义，特制本计划供软件测试相关人员执行。

1.2 测试计划概述

计划名称：航空订票系统测试计划

文档编号：ticket/2009-06-11

测试部门：软件测试部

计划作者：金振方赵豪王山

计划审核：在windows平台下运行航空订票系统,针对该项目中各个模块应实现的不同功能,生成测试用例文档,再手动进行测试。

/* 此部分主要对测试计划的名称、背景、目标、制定依据以及执行部门，测试的方法、工具、范围作一个简明扼要的阐述。*/

1.3 被测试系统概述

产品名称：航空订票系统

开发部门：软件开发部

测试版本：v 1.0

最新版本：v 1.0

系统概述：该系统主要实现了预订机票的功能,并生成订单便于查询和修改,主要针对用户登录模块和生成订单模块进行测试。

3 / 20

/* 此部分主要对被测试系统的基本用途、功能、特性以及计划测试的软件项进行简要的描述。*/

1.4 测试计划制定依据

对测试计划的制定依据给以说明。

测试计划的制定依据本系统的《软件需求规格说明书》，另外还可能包括开发部提供的《软件测试需求说明书》、被测试系统的用户手册、使用说明书以及软件系统自身特性，有时还需要参考用户的意见和建议。另外测试计划的制定要与被测试系统的质量保证计划相一致。

1.5 预期读者

主要可能包括以下人员：项目管理人员、测试人员、系统开发人员，有时还会包括部分用户。

2任务概述

2.1 目标

在功能测试的基础上，对照系统需求说明书，对系统做确认测试，包括数据采集、数据统计、数据查询。在真实应用环境下进行测试。

2.2 运行环境

Windows XP/Windows 2007，Microsoft SQL Server 2005

2.3 需求概述

1)用户验证

让参与测评的用户选择自己的标识进入测评系统，以便测评系统记录该用户是否行使了自己的测评权，对系统内的每种测评类型进行测评，一个用户有一次的测评机会。

2)评价

对飞机票订票系统，系统根据客户的乘机日期、起飞时间和目的地将列出航

4 / 20

班号、起飞时间、到达时间和航空公司，然后根据客户的票数和机票单价自动算出总额。

3)评价结果存储

系统管理员所列被测对象的各项测评子项后，点击“Insert Order”按钮，系统将其提交的被测对象编号、测评类型编号、测评子项名称、子项测评分值存储到后台数据库中。

4)结果统计

统管理员可随时统计制定的测评类型的测评结果数据。通常这项工作应在该类测评结果后，将该测评类型取消其可测评状态后再进行，以统计出最终测评结果。

5)结果查询

系统管理员可查询所有测评类型，所有被评测人员的统计数据。可查询的数据包括按测评类型分类的被评人员总分。并以测评类型为单位按总分对参评人员进行排序。

3测试范围

在这一部分中，要定义需要测试和不需要测试的内容，定义与测试计划执行有关的重要术语和缩略语，并决定与测试子项目有关的测试工作所发生的场合。

严格按照《软件需求规格说明书》中的功能、性能等要求，同时兼顾软件系统自身特性、用户的意见和建议、被测试系统的质量保证计划等，对软件系统的被测试特性和不被测试特性以下表的格式详细列出。

5 / 20

航空订票系统的测试范围

3.1 测试用例

测试用例见下表

6 / 20

3.2 测试特性与软件需求的对应关系

本部分详细说明在本次测试中计划测试的内容与《软件需求规格说明书》的

8 / 20

对应关系，对照需求计划测试的内容。

3.3 被测试特性

1.用户登录模块：

测试用户名和密码的有效性，主要包括文本框中所输入文本的长度，类

型，格式，密码的显示状态以及用户名与密码的一致性，还有是否能实

现控件所标注的功能。

2．生成订单模块：

1)测试机票订单的有效性，主要包括航班日期，航班路线和详细信息，

以及预定者的姓名。

2)测试是否能实现与订单相关其他的功能，主要包括插入订单，修改订

单以及删除订单。

3)测试各种控件的组合使用，主要包括整个界面的布局以及风格，控件

间的相互作用，Tab键的顺序，热键的使用，回车键和ESC键的使用，

控件组合后功能的实现。以及文本框是否可输入，下拉列表是否可选，

单选框是否有默认值且不能多选，按钮是否有默认值等。

3．菜单栏：

测试是否能够正确实现菜单栏中各菜单项指明的功能。

4．工具栏：

测试是否能够正确实现工具栏中指明的各项功能。

/*指明所有要被测试的软件特性及其组合，指明每个特性或特性组合有关的测试设计说明。*/

4术语定义

此部分定义与测试计划执行有关的重要术语和缩略语，其中主要对软件错误与缺陷的划分标准进行定义。

4.1 软件错误与缺陷定义

软件错误与缺陷定义见附录Ⅰ。

9 / 20

4.2 其他术语的定义

5测试目标与策略

5.1 测试目标

通过对该系统中各个模块的测试，找出系统中可能存在的缺陷，确保该系统的可用性和稳定性。

5.2 测试方法

该系统用到得测试方法有：

1.界面测试：主要针对系统中的登录界面和生成订单界面，如各个控件的摆

放次序是否规范,是否存在中英文混杂的问题。

2.功能测试：对菜单栏和工具栏的测试大部分都是功能测试，主要用来确定

是否完整的实现了模块的功能。

3 控件测试：既要对单个控件的功能进行测试，也要看控件是否符合自身的

需求,如:单选框是否有默认值等,还要看各控件组合起来是否

实现了其对应的功能。

5.3 测试工具

对于测试中用到的测试工具给以简单的介绍，对使用测试工具准备进行的测试种类给以简明的描述。

5.4 测试地点

郑州大学工学院3号楼。

10 / 20

6测试状态转换标准和再启动要求

测试状态转换标准和再启动要求见附录Ⅱ。

7测试通过准则

测试通过准则参见附录Ⅲ。

8应提供的测试文档

1) 《软件产品提交测试委托书》

2) 《软件测试需求说明书》

3) 《测试计划》

4) 《测试用例设计与执行报告》

5) 《测试结果报告》

6) 《测试分析报告》

9测试资源需求

9.1 硬件需求

/* 对于测试所必备的和希望有的硬件设备及其配置给以说明。并指出目前还不能得到的硬件设备及其配置。 */

9.2 软件需求

操作系统：WindowsXP/Windows2000/Window7

/* 对于测试所必备的和希望有的软件（包括所需要的测试工具软件）给以说明，并指出目前还不能得到的软件。 */

11 / 20

9.3 网络需求

对于测试所必备的和希望有的网络环境给以说明。

9.4 人员需求

对于测试所需人员及其应具备的知识给予说明。

9.5 其他需求

对于上面没有涉及到的其他需求给以说明。

10人员、职责及培训要求

10.1 人员组成

对参与测试活动的所有人员的姓名及其工作角色给以清楚的说明。

参与测试的人员通常由项目负责人、质量人员、测试负责人、测试人员、项目开发组负责人或项目开发人员组成，有时还包括用户等参与测试的其他人员。

10.2 人员分工与职责

人员分工与职责见附录Ⅳ。

10.3 培训要求

指出测试人员开展和完成测试所需要进行的培训活动。培训活动主要包括被测试系统、被测试系统的支撑系统以及测试工具的培训。同时对每一项培训的负责人给以明确的说明。

1)测试工具的培训通常由测试部内部委派人员来完成。

2)被测试系统及其支撑系统的培训通常由被测试系统开发部委派人员来

完成。

12 / 20

11测试进度

此部分要明确给出测试活动中主要事件的计划表。估计完成每项测试任务所需的时间，为每项测试任务和测试里程碑规定进度。

测试进度可以以下表的格式给出。

测试进度计划表

起止日期测试任务

2009-6-11 用户登录模块, 生成订单模块

2009-6-12 菜单模块,工具栏模块

12风险和应急

12.1 影响计划的潜在因素

在测试计划的执行过程中，对可能存在的影响计划按时完成的风险因素进行分析。

在测试计划执行过程中，通常可能存在以下因素影响计划的按时完成，其中第一点和第三点是影响测试进度的最大可能因素：

1)测试人员对被测试产品的熟悉进度较慢；

2)测试人员对测试工具的使用熟悉程度不够；

3)被测试产品存在重大错误，以致于测试无法继续，需要开发部进行额外

的调试和修改才能继续；

4)硬件、软件或网络环境出现故障等。

12.2 应急措施

对潜在风险因素的应急措施逐项给以明确规定。

13 / 20

通常的应急措施有：

1)通过适当加班来保证计划的按时完成；

2)如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照

测试暂停标准来暂停该测试。

13测试的局限性

对由各种因素（包括测试方法、使用的工具、测试环境及测试人员的素质等）引起的测试局限性进行简要的分析。

影响测试完全的因素通常包括：

1) 系统硬件配置存在不可预测的问题；

2) 测试范围不能覆盖所有的可能情况；

3) 测试时间的限制；

4) 测试数据可能不全面；

5) 测试工具自身的缺陷；

6)测试人员的失误。

14计划的批准

规定本计划必须由哪些人(姓名和职务)审批，并为签名和日期留出位置。

15参考文档

列出本测试计划引用的其他文档，如产品使用说明书、用户手册、产品需求分析、质量风险分析文档、测试需求方案，以及其他相关信息。

列出这些文档可以避免大量重复其内容。

14 / 20

附录Ⅰ软件错误与缺陷的定义

对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别：

1)致命性错误

2)数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操

作系统或其他支撑系统崩溃、非正常关闭和非正常死机。

3)严重性错误

4)应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主

要功能不能正确实现或不完整。

15 / 20

5)一般性错误

6)规定的非主要功能没有实现或不完整、影响系统的运行；设计不合理造

成性能低下。

7)告警性错误

8)不影响业务运行的功能问题。

9)建议

10)软件设计和功能实现等不完全合理之处提出建议。

附录Ⅱ测试状态转换标准和再启动要求

“测试状态转换标准”用于开始、暂停或结束全部或部分与本计划有关的测试项的测试活动的标准，这三种标准通常指启动标准、暂停标准和退出标准。

“测试再启动要求”规定当测试重启动时必须重复的测试活动。

2测试启动标准

1)测试部由公司管理层领导，具体由总工负责领导职能。各软件产品或项目

组提交测试需经过公司管理层书面指派。

2)公司所研发的各项面向市场的软件系统均需通过测试，才能对外发布，特

殊情况由公司管理层书面认可。

3)公司各项软件产品的开发计划书中均需要列出交付测试时间和测试时间，

以及相应的修改和回归测试时间。测试部基于各开发计划制定相应的测试计划，软件系统开发计划的变更必须变更相关的测试安排。

4)软件产品或项目提交测试部进行测试必须满足以下条件：

（1）提交测试的软件系统必须是一个稳定的、待发布的版本，必须明确定义系统版本号（即在系统各部分，系统本身、用户手册等方面均

16 / 20

表明该版本），如果本版本还没有开发完成或将进行大量的修改，不能

提交测试；

（2）软件产品或项目在提交测试之前，本产品或项目组必须在内部进行自己的单元测试和集成测试；

（3）提交测试的软件系统必须是商品化包装的，并需附有：

①用户手册、使用说明书（至少两者必备其一）；

②软件需求说明书；

③其它最好还能够提交相关培训教材、演示程序等电子文档。

（4）软件系统开发组必须向测试部提供足够的培训和技术指导，以便测试工作的顺利开展。在测试期间，开发组必须指定一名骨干开发人

员，帮助测试部解决相关问题。

（5）若是对将发布的产品或将验收的项目进行测试，则必须给测试留出足够的时间，以保证测试的质量。

（6）提交测试的软件系统版本在测试期间保持稳定，即测试部只对初始提交的系统版本进行测试，产品或项目组在测试期间的修改只在下

一轮测试中进行测试。特殊情况（即提交版本无法继续测试，如安装

程序错误等问题）下，可以在测试期间更换版本，但必须经过测试部

的同意。

（7）回归测试是指不包含功能修改（含界面修改等）情况下测试部对原来测出的问题进行的再次测试。若引入新功能超过10%，则认为是

新的系统测试，测试部必须进行全面测试。

3测试暂停标准

当在测试过程中出现下列情况之一，则测试将暂停：

1)对于某类测试，测试环境变得（或者测试中发现）没有准备好，则暂

停此类测试；

2)对于提交测试的版本而言，如果其预计的功能修改量超过总功能的

10%，产品或项目组应即时通报测试部，并向公司相关负责人汇报，测

试部有权利向公司领导建议暂停或取消本轮测试，避免测试的无效劳

动，避免造成人力、财力等资源的浪费。

17 / 20

3)发现被测试系统有大量错误或非常严重错误，以至于测试不能继续或

继续测试没有意义，则测试部应向总工提交报告，由总工决定是否暂

停整个系统测试。

4)当系统中某个功能模块有非常严重的错误，以致于不能完成预期的功

能，则暂停此功能模块的测试。

4测试退出标准

当出现下列情况之一则退出此系统的本次测试：

1)测试计划中所有规定的测试内容和回归测试都已经运行完成。

2)根据上级主管对测试结果的意见，要求结束本次测试。

5启动要求

当测试重新启动时，必须重复的主要测试活动有：

1)当是某功能模块的测试重新启动时，则此功能模块的所有测试用例都

要重新运行，并且调用此功能模块的其他功能模块的相关测试用例也

要重新运行。

2)当是整个系统的测试重新启动时，则发生修改的部分和与之相关联的

部分的测试用例都要重新运行。

附录Ⅲ测试通过准则

1测试项通过标准

测试项的通过标准目前定义为：

当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，则认为此项测试通过。

2系统测试通过标准

系统测试的通过标准目前定义为：

对于每一类测试，当没有发现致命性错误和严重性错误、一般性错误数量小

18 / 20

于测试用例总数的2%，告警性错误数量小于测试用例总数的5%，则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。

附录Ⅳ人员分工与职责

1项目总负责

1)负责审定和批准《软件测试计划》；

2)负责审定其他测试文档，包括：《测试用例设计及执行报告》、《测试结果

报告》、《测试分析报告》；

3)负责测试状态转换（进入、暂停、退出）的最终审定和批准。

2测试负责人

1)负责制定系统测试计划；

2)负责组织实施测试计划；

19 / 20

3)负责整个测试过程的管理工作；

4)负责对被测试产品的评价工作，并编写《测试分析报告》；

5)负责与开发组交流测试结果和测试进展情况，并协调错误的修改和测试的

矛盾；

6)负责对测试人员进行测试工具的培训；

7)负责组织被测试产品的培训；

8)负责的所有测试文档的管理。

3测试人员

1) 负责设计测试用例；

2) 负责执行测试；

3) 负责测试用例原始文档的保存和整理工作；

4) 负责错误的分类和测试结果的统计工作；

5) 负责编写《测试用例设计与执行报告》。

4开发人员

1) 负责软件问题分析、确认；

2) 进行被测试系统的培训；

3)填写《测试结果报告》中相应的栏目。

5测试用例的评审

测试用例评审会主要由测试部、开发部相关人员组成，必要时包括质量部。如果是验收测试还要包括客户、最终用户的有关人员。特殊情况下，包括有公司相关领导及有关专家。

测试用例评审结果报项目总负责人批准。

6测试结果的评审

测试结果评审会主要由测试组相关人员、开发组相关人员和质量部组成，如果是验收测试还要包括客户、最终用户的有关人员。如果是重要的项目或产品发布前的测试结果评审，还包括有公司相关领导及有关专家。

20 / 20