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

《航空订票系统软件测试报告》由会员分享，可在线阅读，更多相关《航空订票系统软件测试报告（20页珍藏版）》请在装配图网上搜索。

1、软件工程航空订票系统测试计划说明书目录1引言31.1编写目的31.2测试计划概述31.3被测试系统概述31.4测试计划制定依据41.5预期读者42任务概述42.1目标42.2运行环境42.3需求概述43测试范围53.1测试用例63.2测试特性与软件需求的对应关系83.3被测试特性94术语定义94.1软件错误与缺陷定义94.2其他术语的定义105测试目标与策略105.1测试目标105.2测试方法105.3测试工具105.4测试地点106测试状态转换标准和再启动要求117测试通过准则118应提供的测试文档119测试资源需求119.1硬件需求119.2软件需求119.3网络需求129.4人员需求12

2、9.5其他需求1210人员、职责及培训要求1210.1人员组成1210.2人员分工与职责1210.3培训要求1211测试进度1312风险和应急1312.1影响计划的潜在因素1312.2应急措施1413测试的局限性1414计划的批准1415参考文档15附录 软件错误与缺陷的定义16附录 测试状态转换标准和再启动要求17附录 测试通过准则20附录 人员分工与职责211 引言1.1 编写目的为保证飞机订票系统的测试工作有序进行，保证飞机订票系统正确实现需求规格说明书中的功能定义，特制本计划供软件测试相关人员执行。1.2 测试计划概述计划名称：航空订票系统测试计划文档编号：ticket/2009-06

3、-11测试部门：软件测试部计划作者：金振方 赵豪 王山计划审核：在windows平台下运行航空订票系统,针对该项目中各个模块应实现的不同功能,生成测试用例文档,再手动进行测试。/* 此部分主要对测试计划的名称、背景、目标、制定依据以及执行部门，测试的方法、工具、范围作一个简明扼要的阐述。*/1.3 被测试系统概述产品名称：航空订票系统开发部门：软件开发部测试版本：v 1.0最新版本：v 1.0系统概述：该系统主要实现了预订机票的功能,并生成订单便于查询和修改,主要针对用户登录模块和生成订单模块进行测试。/* 此部分主要对被测试系统的基本用途、功能、特性以及计划测试的软件项进行简要的描述。 */

4、1.4 测试计划制定依据对测试计划的制定依据给以说明。测试计划的制定依据本系统的软件需求规格说明书，另外还可能包括开发部提供的软件测试需求说明书、被测试系统的用户手册、使用说明书以及软件系统自身特性，有时还需要参考用户的意见和建议。另外测试计划的制定要与被测试系统的质量保证计划相一致。1.5 预期读者主要可能包括以下人员：项目管理人员、测试人员、系统开发人员，有时还会包括部分用户。2 任务概述2.1 目标在功能测试的基础上，对照系统需求说明书，对系统做确认测试，包括数据采集、数据统计、数据查询。在真实应用环境下进行测试。2.2 运行环境Windows XP/Windows 2007，Micro

5、soft SQL Server 20052.3 需求概述1) 用户验证让参与测评的用户选择自己的标识进入测评系统，以便测评系统记录该用户是否行使了自己的测评权，对系统内的每种测评类型进行测评，一个用户有一次的测评机会。2) 评价对飞机票订票系统，系统根据客户的乘机日期、起飞时间和目的地将列出航班号、起飞时间、到达时间和航空公司，然后根据客户的票数和机票单价自动算出总额。3) 评价结果存储系统管理员所列被测对象的各项测评子项后，点击“Insert Order”按钮，系统将其提交的被测对象编号、测评类型编号、测评子项名称、子项测评分值存储到后台数据库中。4) 结果统计统管理员可随时统计制定的测评类

6、型的测评结果数据。通常这项工作应在该类测评结果后，将该测评类型取消其可测评状态后再进行，以统计出最终测评结果。5) 结果查询系统管理员可查询所有测评类型，所有被评测人员的统计数据。可查询的数据包括按测评类型分类的被评人员总分。并以测评类型为单位按总分对参评人员进行排序。3 测试范围在这一部分中，要定义需要测试和不需要测试的内容，定义与测试计划执行有关的重要术语和缩略语，并决定与测试子项目有关的测试工作所发生的场合。严格按照软件需求规格说明书中的功能、性能等要求，同时兼顾软件系统自身特性、用户的意见和建议、被测试系统的质量保证计划等，对软件系统的被测试特性和不被测试特性以下表的格式详细列出。被测

7、试模块被测试特性用户登录模块Input usernameInput password生成订单模块Date of FlightFlightsnameInsert orderUpdate orderDelete order菜单栏FileEditAnalysisHelp工具栏Insert orderOpen orderDelete orderGraphReport Help航空订票系统的测试范围3.1 测试用例测试用例见下表正确显示登录页面（包括美观性、验证需求字段）结果通过测试输入正确用户名、正确密码、正确验证码、点击“登录“按钮登录成功快捷键测试输入正确用户名、正确密码、正确验证码、点击“Ent

8、er“按钮登录成功同时性问题两个人在不同机器上用同一个账号登录登录成功并把第一的登录挤掉用户名大小写验证用户名正确但为区分大小写，其余正确登录失败错误用户名和未注册用户登录错误的用户名和用未注册的用户名登录失败密码次数用户名和验证码正确，密码第一次输入错误登录失败，提示密码错误，并清空用户名和验证码正确，密码第二次输入错误登录失败，提示密码错误，并清空用户名和验证码正确，密码第三次输入错误登录失败，提示密码错误次数太多，不能再登录输入组合错误错误的用户名和错误的密码，验证码正确登录失败，提示用户名不存在用户名和密码正确，验证码错误登录失败，提示验证码错误空输入用户名为空，验证码正确，点登录登录

9、失败并提示输入用户名用户名和验证码正确，密码为空，点登录登录失败并提示密码不能为空用户名和密码正确，验证码为空，点登录登录失败并提示验证码错误用户名和密码都为空，验证码正确，点登录登录失败并提示必填项不能为空密码和验证码都空，用户名正确，点登录登录失败并提示必填项不能为空用户名和验证码都空，密码正确，点登录登录失败并提示必填项不能为空都空，点登录登录失败并提示必填项不能为空空格用户名正确但后面多输入一个或多个空格，其他正确登录成功密码正确但后面多输入一个或多个空格，其他正确登录错误，提示密码错误并清空密码验证码正确但后面多输入一个或多个空格，其他正确登录错误并提示验证码错误验证码功能点击验证码

10、图片图片显示新的字符串验证码时间输入用户名，切换到其它程序，过一段时间再切换回来光标停留在原处功能键Tab键 光标在用户框内，被Tab键两次光标可一次移动到密码输入框和验证码输入框左右箭头 用户名框中使用左右箭头光标必须能跟踪到相应位置Delete键 用户名文本框中使用该键正常删除双击鼠标 在用户名输入框内双击鼠标文本框被选中3.2 测试特性与软件需求的对应关系本部分详细说明在本次测试中计划测试的内容与软件需求规格说明书的对应关系，对照需求计划测试的内容。3.3 被测试特性1. 用户登录模块：测试用户名和密码的有效性，主要包括文本框中所输入文本的长度，类型，格式，密码的显示状态以及用户名与密码

11、的一致性，还有是否能实现控件所标注的功能。2生成订单模块：1) 测试机票订单的有效性，主要包括航班日期，航班路线和详细信息，以及预定者的姓名。2) 测试是否能实现与订单相关其他的功能，主要包括插入订单，修改订单以及删除订单。3) 测试各种控件的组合使用，主要包括整个界面的布局以及风格，控件间的相互作用，Tab键的顺序，热键的使用，回车键和ESC键的使用，控件组合后功能的实现。以及文本框是否可输入，下拉列表是否可选，单选框是否有默认值且不能多选，按钮是否有默认值等。3菜单栏：测试是否能够正确实现菜单栏中各菜单项指明的功能。4工具栏：测试是否能够正确实现工具栏中指明的各项功能。/*指明所有要被测试

12、的软件特性及其组合，指明每个特性或特性组合有关的测试设计说明。*/4 术语定义此部分定义与测试计划执行有关的重要术语和缩略语，其中主要对软件错误与缺陷的划分标准进行定义。4.1 软件错误与缺陷定义软件错误与缺陷定义见附录。4.2 其他术语的定义5 测试目标与策略5.1 测试目标通过对该系统中各个模块的测试，找出系统中可能存在的缺陷，确保该系统的可用性和稳定性。5.2 测试方法该系统用到得测试方法有：1.界面测试：主要针对系统中的登录界面和生成订单界面，如各个控件的摆放次序是否规范,是否存在中英文混杂的问题。2.功能测试：对菜单栏和工具栏的测试大部分都是功能测试，主要用来确定是否完整的实现了模块

13、的功能。3 控件测试：既要对单个控件的功能进行测试，也要看控件是否符合自身的需求,如:单选框是否有默认值等,还要看各控件组合起来是否实现了其对应的功能。5.3 测试工具对于测试中用到的测试工具给以简单的介绍，对使用测试工具准备进行的测试种类给以简明的描述。5.4 测试地点郑州大学工学院3号楼。6 测试状态转换标准和再启动要求测试状态转换标准和再启动要求见附录。7 测试通过准则测试通过准则参见附录。8 应提供的测试文档1) 软件产品提交测试委托书2) 软件测试需求说明书3) 测试计划4) 测试用例设计与执行报告5) 测试结果报告6) 测试分析报告9 测试资源需求9.1 硬件需求/* 对于测试所必

14、备的和希望有的硬件设备及其配置给以说明。并指出目前还不能得到的硬件设备及其配置。 */9.2 软件需求操作系统：WindowsXP/Windows2000/Window7/* 对于测试所必备的和希望有的软件（包括所需要的测试工具软件）给以说明，并指出目前还不能得到的软件。 */9.3 网络需求对于测试所必备的和希望有的网络环境给以说明。9.4 人员需求对于测试所需人员及其应具备的知识给予说明。9.5 其他需求 对于上面没有涉及到的其他需求给以说明。10 人员、职责及培训要求10.1 人员组成对参与测试活动的所有人员的姓名及其工作角色给以清楚的说明。参与测试的人员通常由项目负责人、质量人员、测试

15、负责人、测试人员、项目开发组负责人或项目开发人员组成，有时还包括用户等参与测试的其他人员。10.2 人员分工与职责人员分工与职责见附录。10.3 培训要求指出测试人员开展和完成测试所需要进行的培训活动。培训活动主要包括被测试系统、被测试系统的支撑系统以及测试工具的培训。同时对每一项培训的负责人给以明确的说明。1) 测试工具的培训通常由测试部内部委派人员来完成。2) 被测试系统及其支撑系统的培训通常由被测试系统开发部委派人员来完成。11 测试进度此部分要明确给出测试活动中主要事件的计划表。估计完成每项测试任务所需的时间，为每项测试任务和测试里程碑规定进度。测试进度可以以下表的格式给出。测试进度计

16、划表起止日期测试任务2009-6-11用户登录模块, 生成订单模块2009-6-12菜单模块,工具栏模块12 风险和应急12.1 影响计划的潜在因素在测试计划的执行过程中，对可能存在的影响计划按时完成的风险因素进行分析。在测试计划执行过程中，通常可能存在以下因素影响计划的按时完成，其中第一点和第三点是影响测试进度的最大可能因素：1) 测试人员对被测试产品的熟悉进度较慢；2) 测试人员对测试工具的使用熟悉程度不够；3) 被测试产品存在重大错误，以致于测试无法继续，需要开发部进行额外的调试和修改才能继续；4) 硬件、软件或网络环境出现故障等。12.2 应急措施对潜在风险因素的应急措施逐项给以明确规

17、定。通常的应急措施有：1) 通过适当加班来保证计划的按时完成；2) 如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。13 测试的局限性对由各种因素（包括测试方法、使用的工具、测试环境及测试人员的素质等）引起的测试局限性进行简要的分析。影响测试完全的因素通常包括：1) 系统硬件配置存在不可预测的问题；2) 测试范围不能覆盖所有的可能情况；3) 测试时间的限制；4) 测试数据可能不全面；5) 测试工具自身的缺陷；6) 测试人员的失误。14 计划的批准规定本计划必须由哪些人(姓名和职务)审批，并为签名和日期留出位置。15 参考文档列出本测试计划引用的其他文档，

18、如产品使用说明书、用户手册、产品需求分析、质量风险分析文档、测试需求方案，以及其他相关信息。列出这些文档可以避免大量重复其内容。附录 软件错误与缺陷的定义对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别：1) 致命性错误2) 数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。3) 严重性错误4) 应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功能不能正确实现或不完整。5) 一般性错误6) 规定的非主要功能没有实现或不完整、影响系统的运行； 设计不合理造成性能低下。7) 告警性错误8) 不影响业务运行的功能问

19、题。9) 建议10) 软件设计和功能实现等不完全合理之处提出建议。 附录 测试状态转换标准和再启动要求“测试状态转换标准”用于开始、暂停或结束全部或部分与本计划有关的测试项的测试活动的标准，这三种标准通常指启动标准、暂停标准和退出标准。“测试再启动要求”规定当测试重启动时必须重复的测试活动。2 测试启动标准1) 测试部由公司管理层领导，具体由总工负责领导职能。各软件产品或项目组提交测试需经过公司管理层书面指派。2) 公司所研发的各项面向市场的软件系统均需通过测试，才能对外发布，特殊情况由公司管理层书面认可。3) 公司各项软件产品的开发计划书中均需要列出交付测试时间和测试时间，以及相应的修改和回

20、归测试时间。测试部基于各开发计划制定相应的测试计划，软件系统开发计划的变更必须变更相关的测试安排。4) 软件产品或项目提交测试部进行测试必须满足以下条件：（1） 提交测试的软件系统必须是一个稳定的、待发布的版本，必须明确定义系统版本号（即在系统各部分，系统本身、用户手册等方面均表明该版本），如果本版本还没有开发完成或将进行大量的修改，不能提交测试；（2） 软件产品或项目在提交测试之前，本产品或项目组必须在内部进行自己的单元测试和集成测试；（3） 提交测试的软件系统必须是商品化包装的，并需附有： 用户手册、使用说明书（至少两者必备其一）； 软件需求说明书； 其它最好还能够提交相关培训教材、演示程

21、序等电子文档。（4） 软件系统开发组必须向测试部提供足够的培训和技术指导，以便测试工作的顺利开展。在测试期间，开发组必须指定一名骨干开发人员，帮助测试部解决相关问题。（5） 若是对将发布的产品或将验收的项目进行测试，则必须给测试留出足够的时间，以保证测试的质量。（6） 提交测试的软件系统版本在测试期间保持稳定，即测试部只对初始提交的系统版本进行测试，产品或项目组在测试期间的修改只在下一轮测试中进行测试。特殊情况（即提交版本无法继续测试，如安装程序错误等问题）下，可以在测试期间更换版本，但必须经过测试部的同意。（7） 回归测试是指不包含功能修改（含界面修改等）情况下测试部对原来测出的问题进行的再

22、次测试。若引入新功能超过10%，则认为是新的系统测试，测试部必须进行全面测试。3 测试暂停标准当在测试过程中出现下列情况之一，则测试将暂停：1) 对于某类测试，测试环境变得（或者测试中发现）没有准备好，则暂停此类测试；2) 对于提交测试的版本而言，如果其预计的功能修改量超过总功能的10%，产品或项目组应即时通报测试部，并向公司相关负责人汇报，测试部有权利向公司领导建议暂停或取消本轮测试，避免测试的无效劳动，避免造成人力、财力等资源的浪费。3) 发现被测试系统有大量错误或非常严重错误，以至于测试不能继续或继续测试没有意义，则测试部应向总工提交报告，由总工决定是否暂停整个系统测试。4) 当系统中某

23、个功能模块有非常严重的错误，以致于不能完成预期的功能，则暂停此功能模块的测试。4 测试退出标准当出现下列情况之一则退出此系统的本次测试：1) 测试计划中所有规定的测试内容和回归测试都已经运行完成。2) 根据上级主管对测试结果的意见，要求结束本次测试。5 启动要求当测试重新启动时，必须重复的主要测试活动有：1) 当是某功能模块的测试重新启动时，则此功能模块的所有测试用例都要重新运行，并且调用此功能模块的其他功能模块的相关测试用例也要重新运行。2) 当是整个系统的测试重新启动时，则发生修改的部分和与之相关联的部分的测试用例都要重新运行。附录 测试通过准则1 测试项通过标准测试项的通过标准目前定义为

24、：当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，则认为此项测试通过。2 系统测试通过标准系统测试的通过标准目前定义为：对于每一类测试，当没有发现致命性错误和严重性错误、一般性错误数量小于测试用例总数的2%，告警性错误数量小于测试用例总数的5%，则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。附录 人员分工与职责1 项目总负责1) 负责审定和批准软件测试计划；2) 负责审定其他测试文档，包括：测试用例设计及执行报告、测试结果报告、测试分析报告；3) 负责测试状态转换（进入、暂停、退出）的最终审定和批准。2 测试负责人1) 负责制定系统测试计划；2)

25、 负责组织实施测试计划；3) 负责整个测试过程的管理工作；4) 负责对被测试产品的评价工作，并编写测试分析报告；5) 负责与开发组交流测试结果和测试进展情况，并协调错误的修改和测试的矛盾；6) 负责对测试人员进行测试工具的培训；7) 负责组织被测试产品的培训；8) 负责的所有测试文档的管理。3 测试人员1) 负责设计测试用例；2) 负责执行测试；3) 负责测试用例原始文档的保存和整理工作；4) 负责错误的分类和测试结果的统计工作；5) 负责编写测试用例设计与执行报告。4 开发人员1) 负责软件问题分析、确认；2) 进行被测试系统的培训；3) 填写测试结果报告中相应的栏目。5 测试用例的评审测试用例评审会主要由测试部、开发部相关人员组成，必要时包括质量部。如果是验收测试还要包括客户、最终用户的有关人员。特殊情况下，包括有公司相关领导及有关专家。测试用例评审结果报项目总负责人批准。6 测试结果的评审测试结果评审会主要由测试组相关人员、开发组相关人员和质量部组成，如果是验收测试还要包括客户、最终用户的有关人员。如果是重要的项目或产品发布前的测试结果评审，还包括有公司相关领导及有关专家。20 / 20飞机订票系统软件测试计划说明书