王云鹏,何肖慧
(中铁信弘远(北京)软件科技有限责任公司 技术管理部,北京 100844)
在软件开发的生命周期中,软件测试是一个至关重要的环节。软件测试是软件质量保证工作的一个重要组成部分,也是重要的质量控制手段。为了保证所提交的软件产品能够满足客户的需求,以及在使用中的可靠性,就必须对所开发的软件进行系统而全面的测试。
为了保证软件产品的质量,需要对测试过程进行控制,软件测试管理就是通过一定的管理方法和工具来对整个软件测试过程进行监控,从而提高软件测试的工作效率。
随着各企业软件测试工作的不断深入,传统使用Word进行测试管理的工作方式既无法实现对需求的覆盖分析、又不能对测试执行情况进行监控,不能对测试结果、缺陷、测试效率进行统计分析,已远不能满足测试人员需要,为了更好的对软件测试过程进行监控管理,保证软件产品的质量,逐渐引出了测试管理的问题。
软件测试工作也有流程,流程的定义将影响整个测试过程,QC是在一个基于浏览器的应用中,将测试过程流水化,实现从测试需求,测试计划,测试执行,到测试缺陷的双向跟踪;它可以通过各种图表完成对测试需求、测试用例、测试缺陷的分析,提高了测试的工作效率,使测试人员、开发人员可以在一个集中的测试管理系统中参与到整个测试过程。 QC测试流程如图1所示。
图1 QC测试流程
测试需求是整个测试的基础,来源于软件需求规格说明书,驱动整个测试过程。QC 的Web界面简化了需求管理过程。测试人员通过对软件需求的理解,整理软件需求为测试需求,在QC的需求管理功能中,通过测试需求树建立一个详细的测试需求列表,这样,即方便测试人员理解整个系统的构成,又可以通过将测试需求转换为测试计划,创建该需求对测试用例的追踪,根据生成的报告和图表辅助分析创建的测试需求,检验需求是否适用于测试范围。
2.1.1 建立测试需求
测试需求可以分为测试、需求、未定义、文件夹、业务、组6种类型。测试需求的种类,可以在创建需求树时,通过选择需求类型下拉菜单中的相应值来确定。
QC中,通过【需求】功能中的“新建需求”操作,创建测试需求,测试需求不同于测试用例,不需要具体到每个详细的测试步骤和期望结果,只要归纳出要测的各个功能点,在每条需求的详细信息页面中进行简单描述即可。
这样的测试需求简单明了,便于开发人员和测人员进行讨论,确定最终的测试范围,也便于整个项目的管理团队进行查阅。
2.1.2 建立需求关联
制定测试需求后,需要把每条测试需求和相应的测试用例相关联,从而保证所有的测试需求都有测试用例进行覆盖,每个功能点都能被测到。
需求详细信息视图中,通过“测试范围”页签中“选择测试用例”的方式建立需求与测试用例的关联。
QC的需求管理模块除了提供树状视图外,还另外提供了范围分析和需求网格视图模式。测试人员将需求和测试用例关联后,通过范围分析视图在测试执行阶段可以查阅每个功能的现状,从而了解当前的测试进度。范围分析视图以不同的颜色标出了当前该功能下测试用例的执行情况,由于该视图能显示失败、没有完成、没有执行和通过4种状态的测试用例数目和比例,因此,便于测试人员和管理人员了解当前每个功能的测试状态。从而对项目进度进行控制。
网格视图是需求管理的另一种视图模式。它可以列出测试需求的一些相关属性,便于对测试需求进行查询和过滤。
通过使用QC的需求管理功能,可以将不同的需求分类,并通过需求与测试用例建立关联,跟踪需求到测试过程的每一个步骤,如果需求变更,可以确定哪些测试用例和缺陷受到影响,保证整个测试过程的可追溯,缩短了需求评审和测试管理的时间。
QC通过测试计划功能创建和管理测试用例,测试用例是整个测试过程比较重要的内容,是测试执行的依据。测试人员在QC中,将需求细化,转化为测试用例,创建测试步骤,描述所要执行的操作和预期结果。
测试计划功能用来设计和管理静态的测试用例。它提供测试网格和测试计划树两种视图模式。树状视图便于对所有测试用例的结构和每个测试用例的内容进行管理。数据表格视图对于测试用例的属性维护和查询过滤比较方便。用户可以通过页面菜单进行视图切换。
2.2.1 创建测试用例
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。QC在使用上对于测试用例设计没有统一标准,用户可以根据需要自己制定相应的测试用例管理标准。
【测试计划】功能中,通过“新建测试”操作创建测试用例,对测试输入数据、测试步骤、预期结果进行说明。
2.2.2 建立需求覆盖
设计测试用例后,每个测试用例需要和测试需求进行关联,这样才能在测试需求的覆盖视图上体现出每个需求的覆盖情况。
通过为需求定义测试覆盖,建立测试和需求之间的追踪关系,QC还可以将测试用例与缺陷建立关联,实现从需求到测试再到缺陷的完整追踪。
测试执行的过程也就是运行测试用例以发现软件缺陷的过程,有时在测试执行阶段,同一个测试用例需要反复运行多次,也就是多轮测试。为了使测试用例支持多轮测试,我们需要将测试用例设计和测试用例执行分开。
2.3.1 创建测试集
QC在测试实验室功能中创建测试集(测试执行),每一轮测试可以创建一个测试集,相同的测试用例可以创建不同的测试集,每个测试集可以包含相同或不同的测试用例。
QC的【测试实验室】功能中,通过“新建测试集”操作将测试用例创建到每一轮次的测试执行中。
测试实验室中,提供了5种不同的状态来跟踪测试用例的运行状况。
(1)No Run:该用例本轮测试未被运行;(2)Pass:该用例本轮测试已经执行通过,未发现缺陷;
(3)Failed:该用例本轮测试执行失败,发现了一个或多个软件缺陷;
(4)Not Completed:当前条件下,还不能成功运行这条用例,即:该用例的所有步骤中,有一步或几步还没有运行。
(5)N/A:用例设计有问题或者需求已经改变,该用例无法运行。
测试用例每个步骤在执行时状态,分别为:(6)No Run:该步骤还未被执行;
(7)Pass:该步骤本轮测试执行通过;
(8)Failed:该步骤本轮测试执行失败,发现了一个或多个软件缺陷。
2.3.2 执行测试集
测试集创建成功后,通过执行测试集完成对测试用例的执行,同时验证测试用例的设计效率,简化了测试记录的过程。测试人员在执行测试集时添加Bug,使缺陷直接关联到相应测试用例,充分保证了测试覆盖。
QC将测试用例的执行定义为以下5种状态。测试人员执行测试时,根据实际执行情况将执行结果设置为不同的状态。
(1)Failed:该用例执行失败,执行失败的用例,测试人员通过“新建缺陷”操作添加缺陷;
(2)N/A:该用例不适用;
(3)No Run:该用例尚未执行,用例设计成功后,默认状态均为No Run;
(4)Not Completed:该用例未执行完成;
(5) Passed:该用例执行通过。
在使用测试管理工具以前,所有的缺陷都是通过Excel文件来进行统计和管理的。测试人员发现缺陷后,直接在缺陷跟踪表中填写,然后通过电子邮件和开发人员沟通。这样的缺陷管理方式非常不方便,而且很多缺陷统计信息无法采集。
QC的缺陷管理贯穿作用于测试的全过程,它可以提供管理系统终端到终端的缺陷跟踪,实现从发现缺陷到修复缺陷再到回归验证修复结果的闭环管理。QC基于浏览器的Web特征,能让多个用户同时通过浏览器查询系统缺陷情况。
QC通过缺陷的状态转换实现其整个生命周期内的闭环管理。用户可以根据需要自己定制缺陷状态,也可以使用QC中原有的缺陷状态。常用的缺陷状态有:新建、拒绝、遗留、已关闭、已修正、重新开放。
测试人员将缺陷提交至QC后,通过缺陷状态同开发人员进行交互,实现缺陷的闭环管理。
QC的【缺陷】功能中,通过“新建缺陷”操作建立新缺陷。
当测试人员通过测试集添加缺陷时,该缺陷自动关联到相应测试用例,当通过【缺陷】标签页添加缺陷时,需要选择“项目”字段关联到相关测试用例。
QC还提供了各种图表功能帮助测试人员对测试状态进行统计和分析,从而发现存在的问题,进行有针对性的解决。
2.5.1 需求-概要图
根据指定条件显示当前项目的需求数,用户可以指定X轴的数据类型以及用作数据分组依据的需求信息,如图2所示。
图2 测试分析-需求概要图
2.5.2 需求-进度图
显示当前项目在某个时间段特定时间点的累积需求数。根据用户指定的条件显示需求数。用户可以指定沿 X 轴显示的时间间隔,以及用作数据分组依据的需求信息。还可以指定是否要查看选定数据字段的历史记录,以及是否要查看需求数或需求数的变化,进度图如图3所示。
图3 测试分析-进度图
2.5.3 需求-范围图
根据需求的测试覆盖范围状态显示当前项目中的需求数,如图4所示。
图4 需求-范围图
2.5.4 测试计划-概要图
显示当前项目的测试用例数。可根据用户指定的条件显示用例个数,测试计划如图5所示。
图5 测试计划-概要图
2.5.5 测试执行-概要图
显示属于当前测试集的测试用例数,测试执行如图6所示。
图6 测试执行-概要图
2.5.6 缺陷-进度图
显示当前项目中在某个时间段特定时间点缺陷的累积情况,或修复这些缺陷所花费的时间量,缺陷进度图如图7所示。
图7 缺陷-进度图
软件必须经过测试,测试是验证软件是否达到期望功能的唯一有效方法,也是软件开发过程中必不可少的一环。通过测试管理工具QC对测试过程的管理,可以使测试流程更加规范、测试管理工作更加细致、高效,从而,更好的保证了软件系统的测试质量。
[1] (美)加瑞特(Garrett,T.),(美)高夫(Gauf,B)自动化软件测试实施指南/(美)达斯汀(Dustin,E.)[M].余昭晖,译.北京:机械工业出版社,2010,4.
[2]柳胜编.软件自动化测试框架设计与实践[M].北京:人民邮电出版社,2009,11.