获取负面测试用例的技术

发表于:2016-02-17来源:uml.org.cn作者:不详点击数: 标签:测试用例
负面测试在BS7925-1中的英国标准定义是采用Beizer的定义,其定义负面测试为“旨在说明软件不能工作的测试”(原文:Testing aimed at showing software does not work)。它可以带出一系列补充性的和

  1.负面测试的目的

  负面测试在BS7925-1中的英国标准定义是采用Beizer的定义,其定义负面测试为“旨在说明软件不能工作的测试”(原文:Testing aimed at showing software does not work)。它可以带出一系列补充性的和竞争性的目的。

  发现导致重大失效、崩溃、破坏和安全漏洞的故障

  观察和度量系统对外界问题的响应

  揭露软件的弱点和开发的潜力

  虽然有个一个公正的定义,但是它离被普遍接受还差的很远。负面测试是一个紧跟着被重新定义的术语,有时甚至是各小组的。一个常见的方法,其实践和英国标准定义不同的是它包括旨在使用专门对付失效的功能的测试。

  输入验证,拒绝和重新请求的功能(人工输入和外界系统)

  内部数据验证和拒绝

  应付缺乏的,缓慢的或坏掉的外界资源

  错误处理功能,例如消息,日志,监视功能

  恢复功能,例如故障恢复,回滚和恢复

  2.获取测试用例的技术

  负面测试不是一种测试设计技术,说是一种方法或分类更加合适。使用许多正式的测试设计技术来获取那些能够被划分为‘负面测试’的测试是很有可能。这一节详述了各种各样的知名技术的应用。

  边界值分析和等价类划分Boundary Value Analysis and Equivalence Class Partitioning

  状态转换测试State Transition testing

  逆着已知的约束测试Test against known constraints

  故障模式和结果分析Failure Mode and Effects analysis

  并发Concurrency

  用例和误用的用例Use cases and mis-use cases

  2.1.边界值分析和等价类划分

  有两种基于输入和输出数据和系统行为期望的技术。

  边界值分析(BVA:Boundary Value Analysis)利用关于预知系统行为转换位置的边界的需求和设计来检查那些能够带出一连贯范围数值的数据元素。

  这个方法用于产生三个数值-一个就是边界本身,另外两个在前者的两边(尽可能的和数字相接近)。如果边界在有效和无效范围之间,使用无效数值的测试用例将成为一个负面测试用例。例如,使用66在只接受从18~65数值的年龄字段。

  等价类划分(ECP:Equivalence Class Partitioning)着眼于边界之间的范围。给出的等价类中的每个成员应该在一个已知测试的环境里,使系统做同样的事情-这样测试员不必要测试在等价类中每一个数值。无效输入数据的范围可以被看成为负面测试-例如,一个年龄字段可能被期望用相同的方法拒绝所有的负数。

  ECP一般被延伸到包括非连续数值的集合,胜于连续的数值范围。要注意一些输入可能看上去等价,但是实际上出现很多不同的行为。例如,一个简单web的表单的输入是为空或者太长时可能会被拒绝,但是控制字符的正确组合可能危害潜在web服务器的安全。

  2.2. 状态转换测试

  假设有一个状态转换图或者一个与其等价的理解,那么就很容易获得可以明确地检查不可到达的状态是否真的不可到达的测试用例。与这种方法相同的变种称为n-switch 测试,在一套已知的转换之后,那些不可到达的状态仍然是不可到达吗?图形工具,例如Compendium-TA [4]能够帮助你获得这样的测试。

  2.3. 逆着已知的约束测试

  大多数的系统有明确的和含蓄的限制和约束。如同需求一样对待这些约束(参加Robinson+Robinson, [5]))就可以得到各种负面测试。例如:

  “The site is designed to be viewed with Internet Explorer 4.5 or later” – 负面测试可以使用IE3.0或Netscape.

  “No more than five users will use the system at the same time” –负面测试可以尝试6个,然后8。

  概括来说,测试包括度量和观察系统的行为胜于直接逆着期望结果测试。这只能在系统的操作参数之外工作时被使用,并且这种观察可能导致对系统的进一步了解。

  2.4. 故障模式和结果分析

  从对潜在的技术,实现和已知故障的分析来预见系统特有的故障是很有可能的。这种分析是观察在故障条件下系统行为的测试基础。捕获和文档化这种信息是非常重要的-特别是如果他们允许诊断数据和环境。对于那些监视他们系统并且拥有在系统被使用时(例如银行,电话公司)可以采取行动的技术专家的组织而言,这些文档通常是测试的必要输出。 另一方面,对于更广泛的分布式软件包来说,这些信息也可以成为FAQ或故障诊断指南的一部分。

原文转自:http://www.ltesting.net

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)