飞机票订票系统功能测试项目 - 图文

更新时间:2023-09-24 16:00:01 阅读量: IT计算机 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

项目

项目简介

3

飞机票订票系统功能测试项目

飞机票订票软件项目组完成了系统的集成工作,根据开发计划将要将程序交给测试组进行功能测试。测试小组该如何对该软件进行功能测试呢?

项目目标与要求

(1)能制订飞机票订票系统功能测试的测试计划

(2)能根系统需求分析报告编制飞机票订票软件的功能测试的测试用例 (3)能根据测试用例,熟练地对系统的订票功能进行手工测试

(4)能根据测试用例,熟练使用QTP工具,完成系统的打开订票功能的测试 (5)能熟练使用Excel工具管理测试中发现的缺陷(BUG) (6)能写功能测试报告

项目工作任务

(1)阅读飞机票订票系统的需求分析报告,完成测试小组内容的内容分工,制订单元测试计划

(2)根据飞机票订票系统的需求分析报告,编写订票、查询、修改、删除、打印报表功能的测试用例

(3)根据订票功能的测试用例,用手工的方式进行测试,记录测试结果 (4)根据查询功能的测试用例,使用QTP工具,完成测试工作

(5)用Excel软件完成测试工作日志,用Excel软件管理测试中发现的软件缺陷,并完成功能测试的测试报告

功能测试基本过程

制订功能测试计划 阅读需求分析报告 确定测试策略 搭建测试环境 编写功能测试用例和测试数据 录制测试脚本 设置检查点 手工执行测试 执行测试脚本 测试报告 BUG跟踪表 功能测试总结

图3-1 功能测试基本过程

模块一 制订功能测试计划

学习目标 1、理解订票系统的需求分析报告 2、理解功能测试的一般过程、主要方法和策略

工作任务

1、阅读订票系统的需求分析报告 2、选择功能测试的策略

3、编写订票系统功能测试的计划

任务1:阅读订票系统需求规格说明书

读一读: 订票系统需求规格说明书

一、系统登录功能

系统启动后先显示登录窗体,必须通过输入正确的帐户和对应的密码才能进入系统,如果不正确则给出相应的提示信息。

二、订票功能

1、登录成功后系统自动进入新增订票窗体,同时可以通过“新订票”按钮,或菜单进入新增订票窗框体。

2、在新增订票窗体中,依次输入订票日期、出发地、到达地、航班、订票顾客姓名、订票张数、座位类型,系统能够自动根据用户选择的航班显示航班号、航空公司、志飞时间到达时间和单价,系统能够根据订票的票数、类型和单价自动计算出订单的总计金额。对用户输入的订票日期要进行验证,对于不满足条件的给出明确的提示信息。出发地、到达地、航班系统自动显示,用户只要选择就可以。

3、单击“insert order”按钮,系统保存相关信息并生成并显示此订单的订单号,并给出保存是否成功的信息。

4、当按了“insert order”按钮后,update order和delete order按钮可用(没有保存前这二个按钮是不可用的),通过这二个按钮可以对新增加的订单进行修改或删除操作,具体操作同修改订单和删除订单功能。

三、查询订单功能

1、登录成功后在新增订票窗体,可以通过单击“打开订单”按钮,或者菜单,进入查询订单条件对话框。

2、在查询对话框中提供按“顾客姓名”、“订票日期”和订单号三种查询模式。 3、按姓名查询:输入顾客姓名(能够模糊查询,只要输入姓名的一部分),系统以列表方式结出查询的结果纪录,用鼠标在列表双击(或者选取后,单击OK按钮)所要的订单,系统将在订票主窗口中显示具体的订单信息。根据需要可以进行修改、删除等操作。如果没有找到则显示“没有发现订单,请再试一次”。

4、按订票日期查询:输入具体的订票日期(只能输入数字,日期不完整,“OK”按钮

无效),能够对日期的合法性进行检查,如果查到对应的订票则显示一个“查询结果”的列表,用鼠标在列表双击(或者选取后,单击OK按钮)所要的订单,系统将在订票主窗口中显示具体的订单信息。根据需要可以进行修改、删除等操作。如果没有找到则显示“没有发现订单,请再试一次”。

5、姓名和日期组合查询:选择取姓名和日期,在姓名栏输入查询的姓名,在日期栏输入查询的日期,操作同4和5。

6、按订单号查询:输入指定的订单号(只能输入数字),单击“OK”进行查询,如果查到对应的订票则系统将在订票界面上显示具体的订单信息,根据需要可以进行修改、删除等操作。如果没有找到则显示“不存在这个数字”。

四、修改订单

1、打开指定的订单(open order操作, 新增订单单击”insert order”按钮后也可以)。 2、在订单主窗口中,修改订票日期、出发机场、到达机场、航班信息、顾客姓名和订票张数等(要求与新增订票中相似)

3、单击“update order”按钮保存修改结果(不单击“update order”按钮系统不会保存修改结果)。

4、如果对订单信息进行了修改,没有单击“update order”按钮,进行“新建订单”或“打开订单”按钮时系统会提示“信息已修改,是否要保存”。 确认后保存,取消则返回订单主窗口中,不保存则进入“新建订单”界面或“打开订单”界面。

五、删除订单

1、打开指定的订单(open order操作, 新增订单单击”insert order”按钮后也可以)。 2、在订单主窗口中,单击“delete order”按钮或者“删除工具”删除当前订单。 3、系统给出提示“是否要删除此订单?”,确认后删除,取消则不删除

六、报表统计功能 1、登录成功后在新增订票窗体,单击“报表”的按钮或在“Analysis”菜单中选择”Report”项

2、用纯文本的方式以行的方式(二行一条订单信息,和一行为主要信息,第二为到达时间和到达机场)显示登录代理帐户所有订单的报表,并给出汇总数据。

七、图表统计功能

1、登录成功后在新增订票窗体,单击“图表”按钮或在“Analysis”菜单中选择”Graph”项

2、通过Graph窗体以订单日期为单位显示订单数量。用户可以选择图表的形式(三维柱形图表、二维柱形图表和三维饼图)显示按订单日期的订票数量统计。

八、系统帮助功能

1、登录成功后在新增订票窗体,单击“帮助”按钮或在“Help”菜单中选择”contents”项

2、系统自动打开”Flight Reservation Help Version 1.0”帮助窗框体,为用户提供有关系统的操作说明。

九、系统版权说明功能

1、登录成功后在新增订票窗体,在“Help”菜单中选择”About??”项 2、系统显示一个窗体,用以显示本系统的版本说明信息。

任务2:制订订票系统的功能测试计划

做一做: 功能测试也叫黑盒子测试或数据驱动测试, 根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。软件的功能测试,用于验证应用程序或网站对目标用户能正确工作,使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。功能测试只需考虑各个功能,不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发,按照用户需求编写出来的测试用例,输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。

根据系统的需求规格说明书,可以看出这是一个规模比较小的系统,可以采用手工测试和自动化测试相结合的方式进行测试。可以采用场景法、成效价类划分法、边界类法和常见错误法来编写测试用例。本系统有8个功能点要测试,比较复杂的功能点是新增订票、查询订票和修改订票三个功能点,每个功能点大约需求10个测试用例,其它均为2-5个测试用例,初步估计有50个测试用例,约有3人天的工作量,执行测试则有8人天的工作量(包括编写测试脚本)。所需求人员和工作计划如下(回归测试不包括在内): 订票系统功能测试项目小组成员:

甲:测试小组组长 乙:测试工程师 丙:测试员 丁:测试员

订票系统功能测试计划:

序号 1 安排日期 星期一上午 工作内容 编写测试计划 测试项目会议 分配工作任务 确定测试策略 阅读需求分析 编写测试数据 编写测试用例 搭建测试环境 输入部分测试数据 测试用例评审会 测试环境验收 执行测试 记录测试缺陷 测试分析 负责人 甲 备注 全体参与 项目培训 软件开发项目经理 2 星期一下午至星期二下午 星期一下午至星期二下午 周三上午 周四、周五、第二周周一、第二周周二全天 第二周三 乙 3 4 5 丙、丁 甲 丙、丁 全体参加 软件开发项目经理 乙进行指导 6 乙

撰写功能测试报告 7 8

第二周周四上午 第二周周四下午 提交测试报告 项目小结 甲 甲 交软件开发项目经理 全体人员参与 模块二 编写功能测试的测试用例

学习目标 1、掌握等价类划分、边界值、场景等编写功能测试测试用例的方法 2、掌握测试用例的主要内容、编写格式

工作任务

1、根据需求报告编写登录功能的测试用例 2、根据需求报告编写订票功能的测试用例 3、根据需求报告编写查询功能的测试用例

任务1:编写登录功能的测试用例

做一做:

根据系统需求规格说明书的要求,采用场景法设计测试用例,在订票系统中可以设置登录、新增订票、查询、修改订票、删除订票、打印报表、显示统计图表和帮助等8个大的应用场景。同时考虑不同的运行环境,如win98/win2000/winXP/win vastar/win7等不同的操作系统,对于不同的操作系统,可以使用相同的测试用例(操作系统地栏不同)。

对于登录场景可以采用有效等价类法编写测试用例,将测试用例分成错误和正确二大类,在正确类中设立用户名和密码小写和大写都正确的2个测试用例。在错误类中采用边界值法设立用户名和密码为空、用户名小于4个字符、密码小于4个字符、用户名不正确、密码不正确等6个测试用例。通过采用等价类法和边界值法可以保证测试用例能够覆盖到所有的测试项,测试用例汇总表如下: 测试用主要测试内容 例编号 F_L_1 F_L_2 F_L_3 F_L_4 F_L_5 F_L_6 F_L_7 F_L_7 用户名、密码为空 预期结果 显示帐户或者密码不对 测试结果 用户名少于4个字符,显示姓名字符不少于4个字符 密码正确 用户名正确,密码少于显示密码字符不少于4个字符 4个字符 用户名不正确,密码正确 用户名正确,密码不正确 用户名、密码正确(小写) 用户名、密码正确(大写) 显示帐户或者密码不对 显示帐户或者密码不对 用户名正确、密码不对 显示帐户或者密码不对 成功,显示订票窗体 成功,显示订票窗体 注:这是一个测试用例的汇总表,在Excel中放在第一个工作表中,表的名称为“登录

功能测试用例汇总表”,最后一栏是测试完成后填写,用于总后的统计。

根据测试用例汇总表,编写测试数据,具体如下: 输入项目 正确的用户名和密码 错误的用户名和密码 不足4个字符的用户名和密码 测试数据 test和mercury admin和admin te和mer

根据测试用例汇总表、CMMI3对测试用例的格式要求和测试数据表,在Excel中逐个编写测试用例(以用例编号作为工作表的表名)。下面是F_L_2测试用例的具体内容:

测试用例编号 测试内容 操作系统 操作过程: F_L_2 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 用户名少于4个字符,密码正确 winXP 1、双击C:\\Program Files\\Mercury Interactive\\QuickTest Professional\\samples\\ flight\\app目录下的Flight4a.exe 2、在代理帐户栏中输入“te”,在密码栏中输入”Mercury” 3、单击OK按钮 显示错误对话框“Agent name must be at least 4 characters long” F_L_7 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 测试时间 是否有缺陷 预期结果 实际运行结果 测试人 缺陷描述 测试用例编号 测试内容 操作系统 操作过程: 下面是F_L_7测试用例的具体内容: 用户名密码正确 winXP 1、双击C:\\Program Files\\Mercury Interactive\\QuickTest Professional\\samples\\ flight\\app目录下的Flight4a.exe 2、在代理帐户栏中输入“test”,在密码栏中输入”Mercury” 3、单击OK按钮 自动进入系统订票窗体 测试时间 是否有缺陷 预期结果 实际运行结果 测试人 缺陷描述 测试用例的重点是操作过程和预期运行结果,操作过程根据需求规格说明书、常规应用程序的操作过程和编写的测试数据来编写,要求操作过程明确,先操作什么后操作什么,在哪儿输入,输入什么都要十分明确,测试人员可以根据这个操作步骤完成登录工作。在F_L_2中操作过程的三个步骤是一般有软件登录的操作过程,操作过程中输入的te,mercury则来自测试数据表。预期结果是根据规格说明书和常用软件开发中惯例和系统界面设计而确定的(提示信息的具体内容是根据系统界面设计来确定的)。实际运行结果、测试人、测试时间、是否是缺陷和缺陷描述是由执行测试的人填写的。

练一练:

参考上述的二个例子,根据测试用例汇总表和测试数据表自己完成F_L_1、F_L_4、F_L_7。

读一读:

1、等价类划分

等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法。 划分等价类

等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类。

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类:与有效等价类的定义恰巧相反。

设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。 设计测试用例

在确立了等价类后,可建立等价类表,列出所有划分出的等价类:输入条件有效等价类、无效等价类??,然后从划分出的等价类中按以下三个原则设计测试用例: ①为每一个等价类规定一个唯一的编号。

②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止。

③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止。

2、边界值分析法

边界值分析方法是对等价类划分方法的补充。 (1)边界值分析方法的考虑:

长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

(2)基于边界值分析方法选择测试用例的原则:

1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少1,比最大个数多1的数作为测试数据。

3)根据规格说明的每个输出条件,使用前面的原则1)。 4)根据规格说明的每个输出条件,应用前面的原则2)。

5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

7)分析规格说明,找出其它可能的边界条件。

任务2:编写订票功能的测试用例

根据需求规格说明书,可以看出订票功能界面和内部逻辑都比较复杂,为了提高测试的覆盖度,可以采用法设计测试用例,主要包括正确类和不正确类,对于日期栏应采用边界值法来设计测试用例,对于出发地、到达地和航班采用场景法来设计测试用例。测试用例的汇总表如下: 测试用例编号 F_N_1 主要测试内容 输入非法日期(日超过31) 输入非法月份(月超过12) 输入今天以前的日期 输入正确日期,保存 输入正确日期和出发地,保存 输入正确日期、出发地和到达地,保存 输入正确日期、出发地、到达地和航班,保存 输入正确日期、出发地、到达地、航班和顾客姓名,保存 预期结果 测试结果 显示“Invalid day Entered .The day be valid for the given month.”对话框 显示“Invalid month Entered .The month be greater than 01 and less than 12.”对话框 显示“Valid flight dates are after 02/10/11” 对话框 没有选择出发地 没有选择到达地 没有选择航班 没有输入姓名 F_N_2 F_N_3 F_N_4 F_N_5 F_N_6 F_N_7 F_N_8 成功保存 F_N_9 修改顾客姓名、票数,总价变化,成功保存 保存 单价、总价变化,成功保存 单价、总价变化,成功保存 航班信息清空,没有选择航班 航班信息清空,没有选择到达地 航班信息清空,没有选择到达地 成功保存 F_N_10 修改座位类别,保存 F_N_11 修改航班,保存 F_N_12 修改到达地,保存 F_N_13 修改出发地,保存 F_N_14 修改日期,保存 F_N_15 修改日期、出发地、到达地、航班、票数、顾客姓名和座位类别,保

存 根据订票测试用例汇总表,编写测试数据,具体如下:

输入项目 用户名 密码 日期 日期(日错误) 日期(月错误) 出发地 到达地 起发时间(自动显示) 降落时间(自动显示) 航空公司名称(自动显示) 顾客姓名 票数 座位类别 单价(自动显示) 输入数据 test mercury 03/02/11 03/32/11 13/02/11 Denver London 10:21AM 05:23PM AA Mark Jon 1 Economy $112.20 修改数据1(没保存) 修改数据2(保存) 03/03/11 Paris LosAngeles 20253 8:12AM 03:23PM AA $224.40 $448.80 03/03/11 Paris Denver 17077 10:24AM 12:54AM AF Mark Li 2 Business $222.94 $445.88 日期(在今天之前) 02/02/11 航班号(自动显示) 20262 总金额(自动显示) $112.20 订单号(自动显示,11 保存后才显示)

注:由于系统日期不同,在具体测试时要根据实际情况对日期进行调整,或者将系统日期改为02/05/11,这样才能保证测试数据是有效的。

根据测试用例汇总表、CMMI3对测试用例的格式要求和测试数据表,在Excel中逐个编写测试用例(以用例编号作为工作表的表名)。下面是F_N_1测试用例的具体内容: 测试用例编号 测试内容 操作系统 操作过程: F_N_1 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 日期输入错误(日超过31) winXP 1、 启动Flight4a.exe程序,帐户名输入test,密码输入mercury,进入订票系统窗体 2、 在date of flight中输入:03/32/10 3、 在Fly From中选择“Denver” 显示“Invalid day Entered .The day be valid for the given month.”对话框 预期结果 实际运行结果 测试人 缺陷描述 测试时间 是否有缺陷 下面是F_N_8测试用例的具体内容: 测试用例编号 测试内容 操作系统 操作过程: F_N_8 成功订票 winXP 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 1、 启动Flight4a.exe程序,帐户名输入test,密码输入mercury,进入订票系统窗体 2、 在date of Flight中输入:03/02/11 3、 在Fly From中选择“Denver” 4、 在Fly To:中选择”London” 5、 单击Flights按钮,选择“20262”航班 6、 在name栏中输入:Mark Jon 7、 在Tickets栏中输入:1 8、 在Class栏中选择:Economy 9、 单击“insert order”按钮 单价和总价显示:$112.20,状态栏显示:Insert Done,Order N0显示:11 显示“inserting order.”对话框(此对话框大约5秒钟后自动消失) 数据库中增加相应的订单记录 测试时间 是否有缺陷 预期结果 实际运行结果 测试人 缺陷描述 下面是F_N_12测试用例的具体内容: 测试用例编号 测试内容 操作系统 操作过程: 预期结果 实际运行结果 测试人 缺陷描述 F_N_12 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 保存后修改到达地 winXP 1、 接着F_N_11的界面 2、 在Fly To:中选择”LosAngeles” 3、 单击“Update order”按钮 到达地、航班信息、座位类别、单价和合计清空 弹出“请选择到达城市” 测试时间 是否有缺陷 练一练:

参照上面二个测试用例,自己课后完成F_N_3、F_N_7、F_N_15测试用例。

读一读: 场景法:

通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果。场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。

下面是场景法的基本设计步骤

1. 根据说明,描述出程序的基本流及各项备选流 2. 根据基本流和各项备选流生成不同的场景 3. 对每一个场景生成相应的测试用例

4. 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值。

任务3:编写查询订票功能的测试用例

根据需求规格说明书,可以看出查询订票功能界面和内部逻辑都比较复杂,为了提高测试的覆盖度,可以采用场景法设计测试用例,主要包括按姓名查询、按日期查询、按订单号查询和按姓名日期联合查询4种场景。对于日期查询用可用有效类和边界值法来设计具体的测试用例,对于姓名和订单号查询应采用等价类法来设计测试用例,对于日期和姓名组合查询要采用判定表法设计测试用例。测试用例的汇总表如下: 测试用例编号 F_O_1 F_O_2 F_O_3 F_O_4 F_O_5 F_O_6 F_O_7 F_O_8 F_O_9 主要测试内容 按姓名查询(数据库中没有的姓名) 按姓名查询(正确的姓名) 按姓名查询(姓名的一部分) 按日期查询(输入错误天数) 按日期查询(输入错误月份) 预期结果 显示“没有记录”对话框 显示满足条件的“订票记录”列表框 显示满足条件的“订票记录”列表框 显示日期错误对话框 显示日期错误对话框 测试结果 按日期查询(输入以前显示满足条件的“订票记录”列表框 的正确日期,有记录) 按日期查询(输入以后显示满足条件的“订票记录”列表框 的正确日期,有记录) 按日期查询(输入以后显示“没有记录”对话框 的正确日期,无记录) 按订单号查询(输入不存在的订单号) 显示“没有记录”对话框 显示满足条件的“订票记录”列表框 显示满足条件的“订票记录”列表框 F_O_10 按订单号查询(输入存在的订单号) F_O_11 按日期与姓名组合查询(输入正确的姓名和日期) F_O_12 按日期与姓名组合查询(输入不存在的姓名和日期) F_O_13 按日期与姓名组合查询(输入正确的姓名和没有订票的日期) 显示“没有记录”对话框 显示“没有记录”对话框 根据订票测试用例汇总表,编写测试数据,具体如下: 输入项目 能查询到的顾客姓名 能查询到的顾客姓名的一部分 不能查询到的顾客姓名 日期(天错误) 日期(月错误) 输入数据 Bob Johnson John ZhaoHangtao 03/32/11 13/02/11 可以查到记录的日期(在今天之前) 02/12/11 可以查到记录的日期(在今天之后) 03/02/11 不能查到记录的合法日期 存在的订单号 不存在的订单号 组合查询1(可查到记录) 组合查询2(姓名对日期不对) 组合查询3(姓名不对日期对) 04/02/11 2 30 Jon Baker,02/12/11 Jon,04/02/11 ZhaoHangtao,02/12/11

注:由于系统日期不同,在具体测试时要根据软件的安装情况对日期进行调整,这样才能保证测试数据是有效的。

根据测试用例汇总表、CMMI3对测试用例的格式要求和测试数据表,在Excel中逐个编写测试用例(以用例编号作为工作表的表名)。下面是F_N_1测试用例的具体内容: 测试用例编号 测试内容 操作系统 操作过程: F_O_1 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 日期输入错误(日超过31) winXP 1、 启动Flight4a.exe程序,帐户名输入test,密码输入mercury,进入订票系统窗体 2、 单击“open order”按钮 3、 在“open order”对话框中,选择“Customer Name”选项 4、 在Customer Name栏中输入: ZhaoHangtao,单击“OK”按钮 显示“No orders found.Please try again” 测试时间 是否有缺陷 预期结果 实际运行结果 测试人 缺陷描述 下面是F_O_7测试用例的具体内容: 测试用例编号 测试内容 操作系统 操作过程: F_O_7 成功订票 winXP 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 1、 启动Flight4a.exe程序,帐户名输入test,密码输入mercury,进入订票系统窗体 2、 单击“open order”按钮 3、 在“open order”对话框中,选择“Flight Date”选项 4、 在Flight Date栏中输入:03/02/11,单击“OK”按钮 弹出“Search Results”列表框,其中包含Mark jon和zhao hang等4条订票记录 F_O_10 编写人 赵航涛 编写日期 项目名称 2011-1-20 登录功能 测试时间 是否有缺陷 预期结果 实际运行结果 测试人 缺陷描述 测试用例编号 测试内容 操作系统 操作过程: 下面是F_O_10测试用例的具体内容: 保存后修改到达地 winXP 1、 启动Flight4a.exe程序,帐户名输入test,密码输入mercury,进入订票系统窗体 2、 单击“open order”按钮 3、 在“open order”对话框中,选择“Order No”选项 4、 在Order No栏中输入2,单击“OK”按钮 弹出“Search Results”列表框,其中包含Mark jon和zhao hang等4条订票记录其中包含Fred Smith在2011/2/12订的3张4295航班的机票。 预期结果 实际运行结果 测试人 缺陷描述 测试时间 是否有缺陷 练一练:

参照上面三个测试用例,自己课后完成F_O_3、F_N_6、F_N_110测试用例。

读一读:

判定表法:判定表(Decision Table),它是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期,判定表就已被当做编写程序的辅助工具了。由于判定表测试严格,能够将复杂的逻辑关系和多种条件组合的情况表达得既具体又明确,针对不同的逻辑条件组合值,分别执行不同的操作,因此,使用判定表能够设计出完整的测试用例集合。判定表是一种针对存在条件、动作关系或者因果关系的特性测试的用例设计方法。

判定表通常由4个部分组成。

需求覆盖率计算:测试通过数目/需求总数 ×100% <2>测试覆盖 功能 用例个数 执行总数 未执行 未/漏测分析和原因 测试覆盖率计算:执行数/用例总数 ×100%

6、缺陷统计 <1>缺陷汇总 按功能点统计 功能名称 按缺陷严重程度 非常严重 较严重 一般 微小 集成测试 系统及验收测试 回归测试 <2>缺陷分析

缺陷密度 = 缺陷总数/功能点总数 严重缺陷摘要: 缺陷编号 <3>遗留缺陷 测试结果与预期缺陷编号 简要描述 结果偏差 分析原因 预防改进措施 简要描述 分析结果 备注 7、测试结论与建议 <1>测试结论

测试执行是否充分(可以增加对安全性、可靠性、可维护性和功能性描述) 对测试风险的控制措施和成效 测试目标是否完成 测试是否通过

是否可以进入下一阶段项目目标 <2>测试建议

对系统存在问题的说明,描述测试所揭露的软件缺陷和不足,以及可能给软件实施和运行带来的影响

可能存在的潜在缺陷和后续工作 对缺陷修改和产品设计的建议 对过程改进方面的建议

8、评审意见 审核人 项目经理

签名 日期

图3-11 QTP中设置数据库检查点

在“DdataBase Query Wizard”对话框中单击“Create”按钮,弹出“选择数据源”对话框,单击“机器数据源”项,在列表中选择”QT_Flight2”,单击确认按钮,如图3-12:

图3-12 QTP中设置数据库检查点

系统打开“Database Checkpoint Properties”对话框,单击表格左上角的“全选”按钮,单击“取消选择”按钮,如下左图,单击20行的行标记,选取19行(测试用例F_N_4新

增加的订单),单击“OK”按钮,如图3-13:

图3-13 QTP中设置数据库检查点

7、单击工具栏的“SAVE”按钮,保存脚本。

任务3:执行新增订票测试脚本并分析测试报告

在QTP主窗体上单击工具栏中的“RUN”按钮,在弹出的对话框中单击“确认”,系统自动启动Flight,根据脚本自动进行测试(本脚本的运行时间大约是1分钟),如图3-14,脚本运行结束后关闭Flight系统。

.

图3-14 QTP脚本运行图

脚本执行完成后,自动打开“Test Results”功能测试报告窗体,如图3-15:

图3-15 QTP自动测试测试报告

“Test Results”功能测试报告窗体的右侧为检查总结,显示本脚本的名称,运行时间及脚本中名检查点的通过、失败、出错的数量。失败和出错的数量就是软件缺陷的数量。“Test Results”功能测试报告窗体的左侧为“脚本的测试关键字”,单击+号可以展开,在每个检查

点的前面有一个钩或叉,钩代表这个检查点通过测试,叉代表这个检查没有通过测试,也就是在这个检查点上软件存在缺陷。对于每个失败或者出错均可以在此单击。察看或者出错的详细信息,以便我们进一步确认缺陷。

读一读:

一、自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试的概念。

二、自动化测试的实施条件

实施自动化测试之前需要对软件开发过程进行分析,以观察其是否适合使用自动化测试。通常需要同时满足以下条件:

1) 软件需求变动不频繁。

测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试,必要的时候还要修改自动化测试的框架,如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。

项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。

2) 项目周期足够长。

由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程,需要较长的时间来完成。如果项目的周期比较短,没有足够的时间去支持这样一个过程,那么自动化测试便成为笑谈。

3) 自动化测试脚本可重复使用。

如果费尽心思开发了一套近乎完美的自动化测试脚本,但是脚本的重复使用率很低,致使其间所耗费的成本大于所创造的经济价值,自动化测试便成为了测试人员的练手之作,而并非是真正可产生效益的测试手段了。

另外,在手工测试无法完成,需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

通常适合于软件测试自动化的场合: (1)回归测试,重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费;

(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具;

(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性; (4)自动化工具能够确定测试用例的覆盖路径,确定测试用例集对程序逻辑流程和控制流程的覆盖;

三、主流的自动化测试工具

1、HP公司(前身是Mercury):qtp,winrunner :QTP和WinRunner是企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行,自动执行重复任务并优化测试

工作,从而缩短测试时间。通过自动录制、检测和回放用户的应用操作,从而提高测试效率。

2、IBM公司(前身是Rational):robot rft(rational functional test) :Robot属于Rational TestSuite中的一员,对于Visual studio 6编写的程序支持的非常好,同时还支持Java Applet、HTML、Oracle Forms、People Tools应用程序的支持。要支持Delphi程序的测试还必须下载插件。Rational Robot的语法使用Basic语法,它的语言使用SQABasic。 Functional Tester它是Robot的Java实现版本,在Rational被IBM收购后发布的。在Java的浪潮下,Robot被移植到了Eclipse平台,并完全支持Java和.net。可以使用VB.net和Java进行脚本的编写,当然了录下脚本让后做做修改是最爽的事情了。由于支持Java,那么对测试脚本进行测试也变成了可能。更多的信息请到IBM developerworks上查看,另外还提供试用版本下载。

3、Borland公司(前身是segue):silktest:SilkTest 是面向Web应用、Java应用和传统的C/S应用,进行自动化的功能测试和回归测试的工具。它提供了用于测试的创建和定制的工作流设置、测试计划和管理、直接的数据库访问及校验等功能,使用户能够高效率地进行软件自动化测试。为提高测试效率,SilkTest提供多种手段来提高测试的自动化程度,包括:从测试脚本的生成、测试数据的组织、测试过程的自动化、测试结果的分析等方面。在测试脚本的生成过程中,SilkTest通过动态录制技术,录制用户的操作过程,快速生成测试脚本。在测试过程中,SilkTest还提供了独有的恢复系统(Recovery System),允许测试可在24×7×365全天候无人看管条件下运行。在测试过程中一些错误导致被测应用崩溃时,错误可被发现并记录下来,之后,被测应用可以被恢复到它原来的基本状态,以便进行下一个测试用例的测试。SilkTest 是一种用于目前全球企业应用的先进的基于标准的测试平台。凭借SilkTest,Segue通过为用户提供跨多语言、多平台和多个Web浏览器实施单个脚本、对本地化应用进行同步测试的能力,使其领先的SilkTest?功能测试产品的功能得到了扩展。

4、Compuware公司:QArun :QARun一款自动回归测试工具,与Winrunner比较学习成本要低很多。不过要安装QARun必须安装.net环境,另外它还提供与TestTrack Pro的集成。

5、360WebTester是一款Web功能测试和回归测试工具,以ruby作为脚本语言,可以作为watir IDE,简单易用,学习成本低,中文文档丰富,拥有强大的web对象查看器。可以通过自动录制、检测和回放用户的应用操作,也可以编写测试脚本实现复杂的测试逻辑。 6、AutoIT 这是一个使用类似BASIC脚本语言的免费软件,它设计用于Windows GUI(图形用户界面)中进行自动化操作.它利用模拟键盘按键,鼠标移动和窗口/控件的组合来实现自动化任务.而这是其它语言不可能做到或无可靠方法实现的(例如VBScript和SendKeys)。

7、TestComplete是AutomatedQA公司开发的一套支持自动测试软件的工具,为Windows、.NET、Java和Web应用程序提供了一个特性全面的自动测试环境。将开发人员和QA部门人员从繁琐耗时的人工测试中解脱出来, TestComplete测试具有系统化、自动化和结构化特性,支持.NET,Java,Visual C++, Visual Basic, Delphi, C++Builder 和web应用程序。

8、Selenium 基于Web的开源的功能测试工具,有三种方式或者工具:Selenium IDE,Selenium Core 和 Selenium Remote Control; Selenium IDE ,一个FireFox plugin,能自动记录用户的操作,生成测试脚本。生成的测试脚本可以用Selenium Core手工执行,也能基于Selenium RC放入Java,C#,Ruby的单元测试用例中自动运行。

四、QTP功能简介

QTP(QuickTest Professional)是HP公司(原为Mercury公司)推出的自动化功能测试软件,用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。

本文来源:https://www.bwwdw.com/article/24sd.html

Top