可复用测试用例研究

第一篇：可复用测试用例研究

可复用测试用例研究

0、引言

软件测试的关键环节是设计和执行测试用例。测试用例的质量与测试人员的技能、经验以及对被测软件的理解密切相关。如果测试人员对被测软件不甚了解，很难在短时间内设计出有效的测试用例；有的测试用例虽然面面俱到，但冗余现象严重，浪费时间、人力和物力。

随着软件复用技术的发展，测试复用引起了人们的极大关注，特别是对测试用例复用的研究。所谓测试用例复用，就是对一个软件的已执行的测试用例，将其不同程度地应用于该软件新的测试中或其他软件的测试中。测试用例复用是可行和必要的，表现在：1）软件测试对测试人员的经验和技能要求高，通过复用，可提高测试人员技能，解决其经验不足的问题，同时提高软件测试质量；2）软件测试是当前保证软件质量的一种有效手段，但其占用软件开发周期时间长，通过复用，可避免大量重复性劳动，缩短测试周期，提高效率；3）伴随着同一个软件的生存周期，软件经历了单元测试、集成测试、确认测试和系统测试，这一过程产生了成百上千的经过执行确认的高质量的测试用例，在前一测试阶段执行过的一些测试用例可在后续测试阶段中使用，包括在回归测试、维护阶段的版本升级和纠错测试中都可使用；4）同一领域或相同系统架构的不同软件，存在着测试用例复用的可能性，且随着软件复用技术的发展，很多有价值的组件可供使用，这也使测试用例复用成为可能。

由于软件的抽象性、复杂性和多样性，使得软件测试成为一项复杂的、需要智慧和创造性的工作，要实现测试用例复用并不是一件简单的事情。但测试用例复用是软件测试发展的一个必然趋势。本文从可复用测试用例的评估、描述、设计和使用四个方面对测试用例进行了系统研究，提出了可复用测试用例应具有的特性，为评估测试用例的可复用性提供准则；给出了可复用测试用例的系统描述要素，为规范和使用可复用测试用例提供了基础；提出了面向复用的测试用例设计过程和基于复用的软件测试模型，为测试用例复用提供了方法和实现策略。本文的研究内容在某类实时系统软件测试中进行了应用，证明是有效和科学的。

1、可复用测试用例特性

文献中定义了可复用测试用例的六个特性：通用性、简洁性、独立性、有效性、灵活性和检索方便。本文对大量测试用例和测试用例复用的各种应用情况进行了分析，认为可复用测试用例应具有以下特性：通用性、有效性、独立性、标准化和完整性，它们对可复用测试用例而言是充分的也是必要的。上述特性可作为评判一个测试用例是否具有可复用性的准则。

1）通用性。通用性是指可复用测试用例并不局限于具体的应用，不过分依赖于被测软件的需求、设计和环境，能够在某一类型、某一领域的相似软件的测试中广泛使用。

当前绝大多数的测试用例都不具有通用性，这样的测试用例只能用于被测软件和其当前环境，不可能用到其他软件中。

2）有效性。测试用例的目标是发现软件问题，因此，可复用测试用例也必须是能够发现软件问题的，并且是可靠和高效的。

3）独立性。可复用测试用例的独立性是指，对于测试需求R1和R2，测试用例集分别为cl和C2，c1和c2的交集为空，并且，每个可复用测试用例能够独立运行。测试用例是否具有独立性，决定了测试用例可复用能力的强弱。

如果测试用例之间存在着相互联系，或测试用例的运行环境取决于其他测试用例的执行状态，那么，其中的测试用例不能复用时，与之相关的测试用例的可复用性也不复存在。

如何将测试用例的关联性降至最低，是设计可复用测试用例必须解决的问题。首先，每个测试用例的目标应尽量独立、单一；其次，测试用例不包含过多的具体实现细节。

4）标准化。测试用例通常用自然语言来描述，充分体现了测试人员的创造性和个人风格。但对于可复用测试用例，太多的个人风格不利于其他测试人员对测试用例的理解，必然影响其复用。因此可复用测试用例的标准化程度也反映了其易理解和可复用的能力。为此可复用测试用例应遵循统一或规范的格式或结构，规范的命名规则，使用术语、用简明、易懂、无歧义的语言来描述，并且具有详细的文档。

5）完整性。每个可复用测试用例应包括全部应有的要素，不能有缺失，并且每个要素的描述是充分的。文献规定了测试用例应包括的要素，但对于可复用测试用例而言是不够的，应加以补充。

2、面向复用的测试用例设计过程

当前，测试用例设计都砥向不同的具体应用，与被测软件是紧耦合的。考虑到复用的目的，测试用例的设计应不同于以往。本文提出了面向复用的测试用例设计过程，给出了设计过程中应实施的各项活动，主要包括被测软件（系统）共性分析、测试策略分析、设计测试用例、测试用例评审、测试用例执行和修改、测试用例入库共六个步骤，如图l所示。该过程对现有测试用例的复用处理也是适用的。

2．1共性分析

同一领域或相同架构的软件存在着共性需求。通过共性分析或领域分析，并结合任务分析等方法，梳理出被测软件所属领域或相同类型软件的相同或相似特征及需求，例如，工作流程、共性场景、功能、性能等，从而挖掘出可复用点，例如，相对独立且类似的功能、相同的构件、相似的业务流程。该步骤实质上要抽象出被测软件应用领域的概念，类似于设计模式中的共性分析。

这项活动需要领域专家、软件专家、设计人员、测试专家等人员参与。

2．2 测试策略分析

针对共性分析挖掘出的可复用点，分析各复用点的测试策略，包括测试类型、测试方法、测试环境、测试覆盖率等内容。

2．3 设计测试用例

根据前两个步骤的分析结果对每个可复用点设计测试用例。在设计时，应使所设计的测试用例满足可复用测试用例的特性，特别要注意以下几方面：

1）每个测试用例的目的要尽量独立、单一，以满足可复用测试用例独立性的要求。

2）对一项明确的测试需求，应关注“测试思想”，即测试思路，以满足可复用测试用例通用性要求。当前，为了使测试用例是可操作的、可复现的，一般都要求测试用例要设计得非常详细，例如，每一操作步骤的输入数据、操作等信息都要具体描述。这样的测试用例和被测软件是紧耦合的，只有在同一软件的回归测试和版本升级维护测试中可能会复用到，在其他情况下复用是很困难的。在设计可复用测试用例时，测试用例的可操作性、可复现性要弱化，即，对测试用例进行通用化处理，排除和特定应用相关的具体信息，以降低测试用例和被测软件的相关度，例如，参数化或公式来代替具体的输入数据，抽象出共同或关键的操作等。但为了加强测试用例的可操作性和可复现性，在设计可复用测试用例时，应对一些差异之处进行预测，即进行可变性分析mJ，并用适当的方式描述出来。只有这样，当复用该测试用例时，测试人员可以在原有基础上对其进行完善，使其能够满足特定的测试情况。

3）将设计出的测试用例用规范而精炼的自然语言清晰地描述出来，保证其完整、标准。软件评测组织或机构应定义本组织使用的规范和术语。

需要说明的是，对于一个具体的测试项目，因为面向复用，所以以上所设计的测试用例可能不完全满足被测软件的测试需求，为此，应针对被测软件的需求补充新的用例或对现有用例进行充实完善。

2．4 测试用例评审

可复用测试用例设计完成后，组织领域专家、软件专家、测试专家、软件设计人员对其进行评审，确保所设计的测试用例是正确的，满足可复用测试用例的特性。

评审同时应关注以下几点：每个共性需求的测试策略是否合适；每个共性需求是否被可复用测试用例所覆盖；每个共性需求是否被可复用测试用例进行了充分测试，例如，某一共性功能，不能仅测试正常情况，还应测试边界和异常情况。如果测试用例没有通过评审，则需要重新回到设计测试用例步骤。

2．5 测试用例执行和修改

将通过评审确认的测试用例用于被测软件，寻找其不正确或不完善之处并纠正完善。

2．6 测试用例入库

将经过测试执行确认的可复用测试用例统一纳入测试用例库中，供测试人员在后续软件测试或以后的项目中查询使用。测试用例库应是按照一定的组织结构形成的测试用例集合。

3、基于复用的软件测试模型

文献给出了一个测试用例复用流程：首先定义被测软件的测试用例类型；再根据所定义的从测试用例库中检索是否有适合的用例；如果可以找到，则提取出测试用例，程序结束；否则，需要设计测试用例，验证其正确性，如果正确，则添加到库中以便再次复用，程序结束。这个流程只适用于完全不需要进一步完善的可复用的测试用例，由于可复用测试用例的通用性，该流程显然不适用于实际情况。文献[12]给出了另一个测试用例复用模型，该模型建立在没有测试用例库的基础上，且将测试用例分为内外两类，本文认为这种划分是不必要的。

本文提出了基于复用的软件测试模型。该模型面向一个软件测试项目，但不同于以往的测试模型，主要表现在模型中融合了面向复用的测试用例设计以及对测试用例的复用上，模型如图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）预期结果：说明测试用例执行后的期望结果。每一操作步骤也可有自己的预期结果。

16）评估标准：描述评判测试用例执行中产生的中间和最后结果是否正确的准则。

17）附件：对测试用例附加的一些描述信息，可任意表示，例如文本、图像、模型、与测试用例有关的一些文档，方便测试人员进一步理解测试用例。

上述要素对可复用测试用例而言是必要的，不可缺少。而且要注意的是，测试人员在描述测试用例各要素时，应尽可能地使用规范语言和术语，以使测试用例规范化和易于理解。

5、应用

本文的研究内容在航天测控领域进行了应用。在航天测控计算机系统中，有一类实时系统软件。在不同型号任务中，该类软件的功能、性能、接口和运行环境都有区别，但不同任务对该类软件有共性需求。更多细节信息的子带图像予以了更多地保留，恢复了图像的边缘轮廓，而且经图像分解后的子带图像含有相同尺寸的大小，也更易于处理。本文算法的缺陷则是执行速度较慢，不如前三种算法，而且对分解后所得到系数处理也比较简单，这些都需作进一步的改进。

第二篇：自动售货机测试用例

题目：有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。1.分析这一段说明，列出原因和结果 原因：

1.售货机有零钱找 2.投入1元硬币 3.投入5角硬币

4.押下橙汁按钮 5.押下啤酒按钮

结果：

21.售货机〖零钱找完〗灯亮

22.退还1元硬币

23.退还5角硬币

24.送出橙汁饮料 25.送出啤酒饮料 2.画出因果图

如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

11.投入1元硬币且押下饮料按钮 12.押下〖橙汁〗或〖啤酒〗的按钮 13.应当找5角零钱并且售货机有零钱找 14.钱已付清

3.转换成判定表：

4.设计测试用例

1)在售货机有零钱找的情况下，投入1元硬币，押下橙汁按钮，找回5角硬币并送出橙汁饮料。

2)在售货机有零钱找的情况下，投入1元硬币，押下啤酒按钮，找回5角硬币并送出啤酒饮料。

3)在售货机有零钱找的情况下，投入1元硬币，系统不做任何处理。

4)在售货机有零钱找的情况下，投入5角硬币，押下橙汁按钮，送出橙汁饮料。5)在售货机有零钱找的情况下，投入5角硬币，押下啤酒按钮，送出啤酒饮料。6)在售货机有零钱找的情况下，投入5角硬币，系统不做任何处理。7)在售货机有零钱找的情况下，押下橙汁按钮，系统不做任何处理。8)在售货机有零钱找的情况下，押下啤酒按钮，系统不做任何处理。

9)在售货机没有零钱找的情况下，投入1元硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并退还1元硬币。

10)在售货机没有零钱找的情况下，投入1元硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并退还1元硬币。

11)在售货机没有零钱找的情况下，投入1元硬币，售货机“零钱找完”灯亮。

12)在售货机没有零钱找的情况下，投入5角硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并送出橙汁饮料。

13)在售货机没有零钱找的情况下，投入5角硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并送出啤酒饮料。

14)在售货机没有零钱找的情况下，投入5角硬币，售货机“零钱找完”灯亮。15)在售货机没有零钱找的情况下，押下橙汁按钮，售货机“零钱找完”灯亮。16)在售货机没有零钱找的情况下，押下啤酒按钮，售货机“零钱找完”灯亮。

第三篇：测试用例怎么写

怎么写测试用例我刚刚就业来到公司做软件测试我在学校没有太多的机会做测试，测试用例和测试报告应该怎么写。

● 测试用例编号

◇ 规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串◇ 约定：

系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX

集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX

● 测试项目

◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等◇ 约定：

系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话

集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口

单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char *pszFileName)

● 测试标题

规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。● 重要级别

规则

高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；中：重要程度介于高和低之间的测试用例；

低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。● 预置条件

规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件● 输入

规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等● 操作步骤

规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。● 预期输出

规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等

第四篇：测试用例书写标准

测试用例书写标准

在编写测试用例过程中，需要参考和规范一些基本的测试用例编写标准，在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下。

 标识符（identification）：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档/表格引用和参考的基本元素，这些文档/表格包括设计规格说明书、测试日志表、测试报告等。

 测试项（test item）：测试用例应该准确地描述所需要测试地项及其特征，测试项应该比测试设计说明书中所列出地特性描述更加具体，例如做windows计算器应用程序地窗口设计，测试对象是整个地应用程序用户界面，这样测试项就应该是应用程序地界面地特性要求，例如缩放测试、界面布局、菜单等。

 测试环境要求（test environment）：用来表征执行该测试用例需要地测试环境，一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。

 输入标准（input criteria）：用来执行测试用例的输入需求。这些输入可能包括数据、文件，或者操作（例如鼠标的左键单击，鼠标的按键处理等），必要的时候，相关的数据库、文件也必须被罗列。

 输出标准（output criteria）：标识按照指定的环境和输入标准得到的期望输出结果。如果可能的话，尽量提供适当的系统规格说明书来证明期望的结果。

 测试用例之间的关联：用来标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系，例如，用例A需要基于B的测试结果正确的基础上才能进行，此时需要在A的测试用例中表明对B的依赖性，从而保证测试用例的严谨性。

综上所述，如果使用一个数据库的表来表征测试用例的话，它应该有以下的格式：

例一：对Windows记事本程序进行测试，选取其中的一个测试项――文件菜单栏的测试 测试对象：记事本程序文件菜单栏（测试用例标识1000，下同），所包含的子测试用例描述如下：

|---------文件/新建（1001）

|---------文件/打开（1002）

|---------文件/保存（1003）

|---------文件/另存（1004）

|---------文件/页面设置（1005）

|---------文件/打印（1006）

|---------文件/退出（1007）

|---------菜单布局（1008）

|---------快捷键（1009）

选取其中的一个子测试用例――文件/退出（1007）作为例子，测试用例如下表所示：

通过这个例子了解了测试用例的组成方法。要组织成一个完整的良好测试用例，还需要更多的技巧，并要考虑一些常见的因素。

测试用例设计考虑因素

测试是不可能实现穷举测试的，因此试图用所有的测试用例来覆盖所有测试可能遇到的情形是不可能的，所以，在测试用例的编写、组织过程中，尽量考虑有代表性的典型的测试用例，来实现以点带面的穷举测试。这要求在测试用例设计中考虑一些基本因素：  测试用例必须具有代表性、典型性。

 测试用例设计时，要浓缩系统设计。

例二：常见的web登录页面，通过这个例子来阐述从功能规格说明书到具体测试用例编写的过程

A）用户登录的功能设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 用户登录

1．1满足基本页面布局（图示，略）

1．2当用户没有输入用户名和密码时，不立即弹出错误对话框，而是在页面上使用红色字体来提示，见2描述

1．3用户密码使用掩码号（*）来标识。

1．4*代表必选字段，将出现在输入文本框的后面。

2． 登录出现错误

当出现错误时，在页面的顶部会出现相应的错误提示。错误提示的内容见3。错误提示是高亮的红色字体实现。

3． 错误信息描述

3．1

3．2密码为空

3，3用户名/

（注：本例子中的页面图示，消息编号如WMSG001的描述均为给出。）

―――――――――――――――――――――――――――――――――――――――

B）通用安全性设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 安全性描述

1．1输入安全性：在用户登录或者信用卡验证过程中，如果三次输入不正确，页面将需要重新打开才能生效。

1．2密码：在所有的用户密码中，都必须使用掩码符号（*），数据在数据库中存储使用统一的加密和解密算法。

1．3Cookie：在信用卡信息验证，用户名输入时，Cookie都是被禁止的，当用户第一次输入后，浏览器将不再提供是否保存信息的提示，自动完成功能将被禁用。

1．4SSL校验：所有的站点访问时，都必须经过SSL校验。

2． 错误描述（略）

―――――――――――――――――――――――――――――――――――――――

C）测试用例

结合相关的规格说明书，理解和掌握测试用例设计的关键点，测试用例设计如下表所示。

 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分

析怎样使得这样的错误或者异常能够发生。

用户登录功能测试用例

完善的测试用例

 用户测试用例的设计，要多考虑用户实际使用场景。

第五篇：测试用例设计步骤

测试用例设计步骤

设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：

1、测试需求分析

从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

从业务流程上，应得到以下信息：

A、主流程是什么

B、条件备选流程是什么

C、数据流向是什么

D、关键的判断条件是什么

3、测试用例设计

完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：

功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。

适合的技术：由业务需求和设计说明导出的功能测试、等价类划分

边界测试：对某个功能的边界情况进行测试。

适合的技术：边界值划分

异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是

可能发生的，类似这样的情况需要书写相关的异常测试。

适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值

分析、内部边界值测试。

性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部

性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包

括响应时间，吞吐量等。

适合的技术：业务需求和设计说明导出的测试

压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不

同的平台，不同的工具，相同工具的不同版本下功能的兼容性。

4、测试用例评审

测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。

测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

5、测试用例更新完善

测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。