|
|
简介
播报
编辑
测试用例
作用
播报
编辑
⒈指导测试的实施
测试用例主要适用于
集成测试
、
系统测试
和
回归测试
。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
[2]
⒉规划测试数据的准备
⒊编写测试脚本的"设计规格说明书"
完成测试实施后需要对测试结果进行评估，并且编制
测试报告
。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：
测试覆盖
率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作
度量
基准更加准确、有效。
[2]
通过收集
缺陷
，对比测试用例和缺陷
数据库
，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善
软件质量
。而已有相应测试用例，则反映实施测试或变更处理存在问题。
[2]
重要性
播报
编辑
软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标，每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
[2]
影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等。因为有些因素是客观存在，无法避免的；有些因素则是波动的、不稳定的。例如开发队伍是流动的，有经验的开发人员走了，新人不断补充进来；每个开发人员的工作也会受情绪影响，等等。有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量，从而把人为因素的影响减少。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
[2]
[5
]
因此，测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。
[2]
确定测试用例之所以很重要，原因有以下几方面。
[2]
(1)测试用例构成了设计和制定测试过程的基础。
[2]
(2)测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，测试人员对产品质量和测试流程也就越有信心。
[2]
(3)判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95%的关键测试用例已得以执行和验证”，远比“我们已完成95%的测试”更有意义。
[2]
(4)测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
[2]
(5)测试设计和开发的类型以及所需的资源主要都受控于测试用例。
[2]
(6)测试用例通常根据它们所关联的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。最佳方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
[2]
编制测试用例
播报
编辑
着重介绍一些编制测试用例的具体做法。
[2]
测试用例文档
编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
[2]
测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。
[2]
测试用例的设置
对于复杂操作的
程序
模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
[2]
但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个
子系统
有十余个或更多的模块，这些模块相互有关联。再采用
路径
分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么
子系统
模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合
模式
设置用例的由来。
[2]
设计测试用例
测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
[2]
设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯 一的，不允许重复。测试需要验证：字典新增
程序
中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的
软件缺陷
。
[2]
可以采用软件测试常用的基该方法：
等价类划分
法、
边界值分析法
、
错误推测法
、
因果图法
、
逻辑覆盖法
等设计测试用例。
视软件的不同性质采用不同的方法。如何灵活运用各种基该方法来设计完整的测试用例，并最终实现暴露隐藏的
缺陷
，全凭测试设计人员的丰富经验和精心设计。
[2]
测试用例设计
播报
编辑
设计原则
测试用例是一个文档，是执行的最小实体。测试用例包括输入、动作、时间和一个期望的结果，其目的是确定应用程序的某个特性是否可正常工作，并且达到程序所设计的结果，以便测试某个程序路径或核实是否满足某个特定需求般在进行
测试用例设计
前要全面了解被测试产品的功能、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术与方法等。测试用例设计一般遵循以下原则:
[3]
(1)正确性。输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
[3]
(2)全面性。覆盖所有的需求功能项;设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。
[3]
(3)连贯性。用例组织有条理、主次分明，尤其体现 在业务测试用例上;用例执行粒度尽量保持每个用例都有测点，不能同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。
[3]
(4)可判定性。测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。
[3]
(5)可操作性。测试用例中要写清楚测试的操作步骤，以及与不同的操作步骤相对应的测试结果。
[3]
设计方法
1、白盒法
白盒法又称
结构化方法
(结构测试)或
逻辑覆盖法
，其基本思想是把程序看作是路径的集合。这样，对程序的测试便转化为对程序中某些路径的测试，要设法让被测程序的“各处”均被执行到，使潜伏在程序每个角落的错误均有机会暴露出来。因此，白盒法实际上是一种选择通过指定路径的输入数据的分析方法。
[4]
2、测试覆盖率
采用白盒法可以用测试覆盖率作为测试彻底度的定量衡量标准。常用的覆盖率有:
[4]
(5)多重条件覆盖:又称条件的组合覆盖，是使程序中每个判定中的条件的各种组合都至少取到一次，并且每条语句至少执行一次。
[4]
此外，还有诸如路径覆盖(程序中每条路径至少执行一次)、基本路径覆盖(循环次数只考虑小于等于一次所组成的程序路径，每条基本路径至少执行一次)等。为了获取测试覆盖率(不论是哪一种覆盖率)需要有测试工具的帮助，且需要花费人力与机时去做测试工作(设计测试用例、输入测试数据、进行统计计算等)。
[4]
3、黑盒法
黑盒法又称为
功能测试
，是根据
软件需求说明书
上罗列的各项功能、性能指标，来构造测试用例的输入数据，实际执行被测软件，分析执行过程的行为与执行结果以便检查出被测软件的错误。在黑盒法测试中，测试者可以完全不关心程序的内部结构。可见，白盒法是一种逻辑驱动方法，而黑盒法是一种功能驱动方法。黑盒法是最常用的测试方法。
[4]
相关问题
播报
编辑
⒈测试用例的评审
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、
编程
、分析设计等有关人员组成，也可邀请客户代表参加。
[2]
⒉测试用例的修改更新
测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在
测试过程
中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的
软件缺陷
，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
[2]
一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。
[2]
⒊测试用例的管理软件
运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理
数据库
，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试
度量
值，
测试覆盖
表和测试通过或不通过的测试用例清单列表。
[2]
