测试用例设计指南b.docx
- 文档编号:2418561
- 上传时间:2022-10-29
- 格式:DOCX
- 页数:11
- 大小:23.37KB
测试用例设计指南b.docx
《测试用例设计指南b.docx》由会员分享,可在线阅读,更多相关《测试用例设计指南b.docx(11页珍藏版)》请在冰豆网上搜索。
测试用例设计指南b
1测试用例说明
项目组测试人员通过QC对测试用例进行管理,在初始化过程中,测试用例需要包括但不限于以下内容:
●提供输入的具体值和预期的输出值,采用特定的测试用例而引起的对测试步骤的限制
●测试用例规格说明标识
●测试项目
●输入规范
●输出规范
●环境要求
●特殊步骤要求
●交互用例的相关性
●每个测试用例清楚地阐述了正在进行评估的用例、用例场景、测试目标或条件的有关说明。
●每个测试用例都阐述预期结果和评估该结果的方法。
●对于每个测试需求,至少需要确定两个测试用例。
一个测试用例代表预期的条件,它可用于核实行为是否正确或符合预期(正面测试)。
另一个测试用例代表不可接受的、异常的或意外的条件,它可用于核实测试需求是否未以非预期方式执行(负面测试)。
在一般情况下,对于测试的每个需求来说,至少要有一个正面测试用例和为数较多的负面测试用例。
●测试用例已被确定用来执行测试目标中所有的产品需求行为,包括(视情况而定):
●功能
●数据确认
●业务规则实施
●测试目标工作流程或控制
●数据流
●对象状态
●性能(包括工作量、配置和强度)
●安全性/可访问性
●兼容性
●每个测试用例都说明/代表一个唯一的输入集或事件顺序,它能够产生唯一的测试目标行为。
复审那些产生相同行为的测试用例并判定它们是否等同,即它们是否都执行测试目标中的路径。
●每个测试用例(或每组相关的测试用例)确定初始的测试目标状态和测试数据状态。
●所有的测试用例名称和/或ID都与测试模块命名约定一致。
2具体示例
2.1功能测试(FunctionalTesting)
用于功能测试的测试用例来源于测试目标的用例。
应该为每个用例场景编制测试用例。
用例场景要通过描述流经用例的路径来确定,这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
在确定功能性测试用例时,确保满足下列条件:
●已经为每个用例场景确定了充足的正面和负面测试用例。
●测试用例可以处理用例所实施的所有业务规则,确保对于业务规则,无论是在内部、外部还是在边界条件/值上都存在测试用例。
●测试用例可以处理所有事件或动作排序(如在设计模型的序列图中确定的内容),还应能处理用户界面对象状态或条件。
●测试用例可以处理为用例所指定的任何特殊需求,如最佳/最差性能,有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。
5.2测试用例设计步骤
步骤1:
首先使被测单元运行
任何单元测试说明的第一个测试用例应该是以一种可能的简单方法执行被测单元。
看到被测单元第一个测试用例的运行成功可用增强人的自信心。
如果不能正确执行,最好选择一个尽可能简单的输入对被测单元进行测试/调试。
这个阶段适合的技术有:
模块设计导出的测试
对等区间划分
步骤2:
正面测试(PositiveTesting)
正面测试的测试用例用于验证被测单元能够执行应该完成的工作。
测试设计者应该查阅相关的设计说明;每个测试用例应该测试模块设计说明中一项或多项陈述。
如果涉及多个设计说明,最好使测试用例的序列对应一个模块单元的主设计说明。
适合的技术:
设计说明导出的测试
对等区间划分
状态转换测试
步骤3:
负面测试(NegativeTesting)
负面测试用于验证软件不执行其不应该完成的工作。
这一步骤主要依赖于错误猜测,需要依靠测试设计者的经验判断可能出现问题的位置。
适合的技术有:
错误猜测
边界值分析
内部边界值测试
状态转换测试
步骤4:
设计需求中其它测试特性用例设计
如果需要,应该针对性能、安全需求、保密需求等设计测试用例。
在有安全保密需求的情况下,重视安全保密分析和验证是方便的。
针对安全保密问题的测试用例应该在测试说明中进行标注。
同时应该加入更多的测试用例测试所有的保密和安全冒险问题。
适合的技术:
设计说明导出的测试
步骤5:
覆盖率测试用例设计
应该或已有测试用例所达到的代码覆盖率。
应该增加更多的测试用例到单元测试说明中
以达到特定测试的覆盖率目标。
一旦覆盖测试设计好,就可以构造测试过程和执行测试。
覆
盖率测试一般要求语句覆盖率和判断覆盖率。
适合的技术:
分支测试
条件测试
数据定义-使用测试
状态转换测试
步骤6:
测试执行
使用上述5个步骤设计的测试说明在大多少情况下可以实现一个比较完整的单元测试。
到这一步,就可以使用测试说明构造实际的测试过程和用于执行测试的测试过程。
该测试过
程可能是特定测试工具的一个测试脚本。
测试过程的执行可以查出模块单元的错误,然后进行修复和重新测试。
在测试过程中的动态分析可以产生代码覆盖率测量值,以指示覆盖目标已经达到。
因此需要在测试设计说明中需要增加一个完善代码覆盖率的步骤。
步骤7:
完善代码覆盖
由于模块单元的设计文档规范不一,测试设计中可能引入人为的错误,测试执行后,复
杂的决策条件、循环和分支的覆盖率目标可能并没有达到,这时需要进行分析找出原因,导
致一些重要执行路径没有被覆盖的可能原因有:
不可行路径或条件――应该标注测试说明证明该路径或条件没有测试的原因。
不可到达或冗余代码――正确处理方法是删除这种代码。
这种分析容易出错,特别是使用防卫式程序设计技术(DefensiveProgrammingTechniques)时,如有疑义,这些防卫性程序代码就不要删除。
测试用例不足――应该重新提炼测试用例,设计更多的测试用例添加到测试说明中以覆盖没有执行过的路径理想情况下,覆盖完善阶段应该在不阅读实际代码的情况下进行。
然而,实际上,为达到覆盖率目标,看一下实际代码也是需要的。
覆盖完善步骤的重要程度相对小一些。
最有效的测试来自于分析和说明,而不是来自于试验,依赖覆盖完善步骤补充一份不好的测试设计。
适合的技术:
分支测试
条件测试
设计定义――试验测试
状态转换测试
5.3用例设计的一般原则
注意到产生测试说明步骤可以用下面的方法完成:
通常应该避免依赖先前测试用例的输出,测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量;
测试用例设计过程中,包括作为试验执行这些测试用例时,常常可以在软件构建前就发现BUG。
还有可能在测试设计阶段比测试执行阶段发现更多的BUG。
在整个单元测试设计中,主要的输入应该是被测单元的设计文档。
在某些情况下,需要将试验实际代码作为测试设计过程的输入,测试设计者必须意识到不是在测试代码本身。
从代码构建出来的测试说明只能证明代码执行代码完成的工作,而不是代码应该完成的工作。
5.4测试用例设计技术
广义地分为两类:
黑盒测试:
使用单元接口和功能描述,不需了解被测单元的内部结构
白盒测试:
使用被测单元内部如何工作的信息
灰盒测试:
借助于源代码和测试工具等手段,通过黑盒和白盒测试相结合的方法进行测试的技术。
测试设计最重要的因素是经验和常识。
测试设计者不应该让某种测试技术阻碍经验和常识的
运用。
白盒测试用例设计:
使用程序设计的控制结构导出测试用例。
采用白盒测试的目的主要是:
保证一个模块中的所有独立路径至少被执行一次;
对所有的逻辑值均需要测试真、假两个分支;
在上下边界及可操作范围内运行所有循环;
检查内部数据结构以确保其有效性。
黑盒测试用例设计:
使用详细设计导出测试用例。
采用黑盒测试的目的主要是:
检查功能是否实现或遗漏;
检查人机界户是否错误;
数据结构或外部数据库访问错误;
性能等其它特性要求是否满足;
初始化盒终止错误。
5.4.1软件设计说明导出的测试
测试用例通过根据相关的软件设计说明文档进行设计。
每个测试用例测试设计说明中一项或多项陈述。
通常为被测单元设计说明的一系列陈述建立一系列对应的设计用例。
例1:
考虑下面计算实数平方根的函数的设计说明:
输入:
实数
输出:
实数
处理:
当输入0或大于0时,返回输入数的平方根;当输入小于0时,显示:
“Squareroot
error-illegalnegativeinput",并返回0;库函数Print_Line用于显示出错信息。
设计说明有3个陈述,可以2个测试用例来对应。
TestCase1:
输入4,返回2。
//执行第一个陈述
TestCase2:
输入-10,返回0,显示“Squarerooterror-illegalnegativeinput”//对应第二个和第三个陈述
设计说明导出的测试用例提供了与被测单元设计说明陈述序列很好的对应关系,增强了
测试说明的可读性和可维护性。
但有软件设计说明导出测试是正面的测试用例设计技术。
软
件设计说明导出的测试应该用负面测试用例进行补充,以提供一个完整的单元测试说明。
设计说明导出的测试设计技术还可用于安全分析、保密分析、软件冒险分析和其他给单
元设计的其他补充文档。
5.4.2基本路径测试
基本路径测试是一种白盒测试技术。
测试用例设计者导出一个过程设计的逻辑复杂性测
度,并使用改测度作为指南来定义执行路径的基本集,从该基本集导出的测试用例保证对程
序中的每一条执行语句至少执行一次。
5.4.3计算圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界。
独立路径必须包含一条在定义之前不曾用到的边。
有以下三种方法计算圈复杂度:
流程图中区域的数量对应于环型的复杂性;
给定流程图G的圈复杂度-V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中节点的数量;
给定流图G的圈复杂度-V(G),定义为V(G)=P+1,P是流图G中判定节点的数量。
5.4.4对等区间(等价类划分)
对等区间划分是一种黑盒测试方法,该方法也成为等价类划分;
对等区间划分是测试用例设计的非常形式化的方法。
它将被测软件的输入输出划分成一些区间,被测软件对一个特定区间的任何值都是等价的。
形成测试区间的数据不只是函数/过程的参数,也可以是软件可以访问的全局变量,系统资源等,这些变量或资源可以是以时间形式存在的数据,或以状态形式存在的输入输出序列。
对等区间划分假定位于单个区间的所有值对测试都是对等的,应该为每个区间的一个值设计一个测试用例。
5.4.5边界值分析法
边界值分析法:
指对输入的边界条件进行分析,设计出针对边界值的测试用例。
数值的边界值检验
字符的边界值检验
其他边界值检验
5.4.6因果图法
就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系,以设计测试用例的方法。
因果图法适合于检查程序输入条件的多种情况的组合,并最终生成判定表,来获得对应的测试用例。
5.4.7错误推测法
推测法主要依赖经验、直觉来作出简单的判断甚至是猜测,给出可能存在缺陷的条件、场景等,在找到缺陷后,设计出相应的测试用例。
5.4.8正交实验设计法
主要步骤是:
(1)对软件需求规格说明中的功能要求进行划分(层层分解与展开),分解成具体的、相对独立的基本功能。
(2)根据基本功能的质量需求,找出影响其功能实现的操作对象和外部因素,每个因素的取值可以看作水平,多个取值就存在多个水平。
(3)确定待测试软件中所有因素及其权值,这是测试用例设计的关键,确保全面、准确。
权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。
(4)加权筛选,生成因素分析表。
(5)利用正交表构造测试数据集,正交表的每一行,就是一条测试用例。
考虑交互作用不可忽略的处理因素和不可
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 设计 指南