可复用测试用例研究(3)

　　本文提出了基于复用的软件测试模型。该模型面向一个软件测试项目，但不同于以往的测试模型，主要表现在模型中融合了面向复用的测试用例设计以及对测试用例的复用上，模型如图2所示。

　　“测试需求分析和共性分析”中，测试人员一方面要根据被测试软件需求分析、设计说明等文档或软件代码梳理出被测软件的测试需求，另一方面要针对被测软件所属领域及软件类型进行面向复用的共性分析。

　　“定义测试策略”中，测试人员根据测试目标和上一步的结果定义测试策略，包括测试方法、测试类型、测试环境等内容。

　　“定义测试用例”中，测试人员根据测试需求和共性分析结果及所定义的测试策略，定义所需要的测试用例。这里定义的测试用例只是给出一个测试用例名称及其测试目的。

　　“查询可复用测试用例库”中，测试人员用多字段检索功能从可复用测试用例库中查找满足要求的测试用例。对测试用例的查询是不确定的，查询结果通常是一个相似的测试用例集合。如果可以找到，则“提取测试用例”并对其进行分析，确定出最合适的测试用例;如果没有，则“设计”新的测试用例。找到的测试用例，往往因其通用性，并不能完全满足测试需求，要对其“补充完善”。在设计新的测试用例时，要考虑到上节“设计测试用例”要求。

　　在传统模型评审的基础上，本模型“测试评审”还包括对新设计的可复用测试用例是否满足要求的审查;对复用的测试用例是否补充完善的审查;所有测试用例是否满足被测软件的测试需求的审查。

　　“执行测试用例”中，测试人员将所设计的测试用例逐用例逐步骤地执行。在执行过程中，认真观察并详实地记录测试过程、测试结果和发现的错误，形成测试记录。如果在执行过程中发现测试用例有不正确和不完善之处，则纠正;如果测试用例不充分，则补充。

　　测试人员在“测试总结”中对所有测试结果进行分析总结，将通过测试执行验证的可复用测试用例放入可复用测试用例库中，以便后续复用。

　　该模型的优点为：1)对已有的可复用的测试用例进行了复用，避免了大量的重复性工作，提高了测试质量和效率;2)考虑了面向复用的测试用例设计，避免再次产生大量的不可复用的测试用例。

　　4、可复用测试用例描述要素

　　测试用例的输入、操作、预期结果和评估标准、前提条件是测试用例不可少的要素，但对于可复用测试用例而言，这是不够的。本文在文献规定的测试用例要素基础上，增加了新的内容。从而从多个角度完整地对可复用测试用例进行了描述，为可复用测试用例的标准化提供了模板，为建立可复用测试用例库并对测试用例实施有效管理提供了基础，也为测试用例检索提供了多个检索字段。

　　1)测试用例名称：名称能清晰且简洁地表达测试用例的功能。

　　2)ID：该ID在数据库中是唯一的。

　　3)版本号：用于测试用例的版本管理，每个测试用例应按照定义的规则设定一个版本号。

　　4)测试需求：对要验证的测试需求的描述和测试要求，例如，功能、性能等。

　　5)测试阶段：被测软件所处的测试阶段，包括单元测试、部件测试、配置项测试、系统测试，或者单元测试、集成测试、确认测试、系统测试。

　　6)测试方法：黑盒测试中的等价类划分、因果图，白盒测试中的语句覆盖、分支覆盖等。

　　7)测试类型：有功能测试、性能测试、安全测试、用户界面测试、接口测试、安装测试等，可选择多项。

　　8)应用领域：说明被测软件所属领域。

　　9)系统类型：描述被测软件所在系统的架构，如B/S、C/S、嵌入式软件、非嵌入式软件等。

　　lO)软件编码：描述被测软件的编码语言。

　　11)测试环境：描述该测试用例执行的软硬件环境。

　　12)前提条件：测试用例执行前必须满足的条件，或称之为约束条件。

　　13)测试输入：对输入值的抽象描述或参数化描述，不能是具体的数据值。

　　14)操作步骤：说明执行该测试用例的一系列相关联的操作。

　　15)预期结果：说明测试用例执行后的期望结果。每一操作步骤也可有自己的预期结果。

原文转自：http://www.uml.org.cn/Test/201308143.asp