软件测试的经济学

上一篇 / 下一篇  2012-07-19 14:40:37 / 个人分类:Theory

    摘自论坛
 
    给出了软件测试的适当定义之后,下一步就是确定软件测试是否能够发现“所有”的错误。我们将证明答案是否定的,即使是规模很小的程序。一般说来,要发现程序中的所有错误也是不切实际的,常常也是不可能的。这个基本的问题反过来暗示出软件测试的经济学问题、测试人员对被测软件的期望,以及测试用例的设计方式。

  为了应对测试经济学的挑战,应该在开始测试之前建立某些策略。黑盒测试白盒测试是两种昀普遍的策略,我们将在下面两节中讨论。

  黑盒测试

  黑盒测试是一种重要的测试策略,又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时,将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关,而是将重点集中放在发现程序不按其规范正确运行的环境条件。

  在这种方法中,测试数据完全来源于软件规范(换句话说,不需要去了解程序的内部结构)。如果想用这种方法来发现程序的所有错误,判定的标准就是“穷举输入测试”,将所有可能的输入条件都作为测试用例。为什么这样做?比如说在三角形测试的程序中,试过了三个等边三角形的测试用例。这不能确保正确地判断出所有的等边三角形。程序中可能包含对边长为 3842,3842,3842的特殊检查,并指出此三角形为不规则三角形。由于程序是个黑盒子,因此能够确定此条语句存在的惟一方法,就是试验所有的输入情况。

  要穷举测试这个三角形程序,可能需要为所有有效的三角形创建测试用例,只要三角形边长在开发语言允许的昀大整数值范围内。这些测试用例本身就是天文数字,但这还决不是所谓穷尽的,当程序指出 -3,4,5是一个不规则三角形或 2,A, 2是一个等腰三角形时,问题就暴露出来了,为了确保能够发现所有这样的错误,不仅得用所有有效的输入,而且还得用所有可能的输入进行测试。因此,为了穷举测试三角形程序,实际上需要创建无限的测试用例:这当然是不可能的。

  如果测试这个三角形程序都这么难的话,那么要穷举测试一个稍大些的程序的难度就更大了,设想一下,如果要对一个 C++编译器进行黑盒穷举测试,不仅要创建代表所有有效 C++程序的测试用例(实际上,这又是个无穷数),还需要创建代表所有无效 C++程序的测试用例(无穷数),以确保编译器能够检测出它们是无效的。也就是说,编译器必须进行测试,确保其不会执行不应执行的操作——如顺利地编译成功一个语法上不正确的程序。

  如果程序使用到数据存储,如操作系统数据库应用程序,这个问题会变得尤为严重。举例来说,在航班预定系统这样的数据库应用程序中,诸如数据库查询、航班预约这样的事务处理需要随上次事务的执行情况而定,因此,不仅要测试所有有效的和无效的事务处理,还要测试所有可能的事务处理顺序。

  上述讨论说明,穷举输入测试是无法实现的,这有两方面的含义,一是我们无法测试一个程序以确保它是无错的,二是软件测试中需要考虑的一个基本问题是软件测试的经济学。也就是说,由于穷举测试是不可能的,测试投人的目标在于通过有限的测试用例,昀大限度地提高发现的问题的数量,以取得昀好的测试效果。除了其他因素之外,要实现这个目标,还需要能够窥见软件的内部,对程序作些合理但非无懈可击的假设(例如,如果三角形程序将 2,2,2视为等边三角形,那就有理由认为程序对 3,3,3也作同样判断)。

  白盒测试

  另一种测试策略称为白盒测试或称逻辑驱动的测试,允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构迸行检查,从中获取测试数据(遗憾的是,常常忽略了程序的规范)。

  在这里我们的目标是针对达种测试策略,建立起与黑盒测试中穷举输入测试相似的测试方法。也许有一个解决的办法,即将程序中的每条语句至少执行一次。但是我们不难证明,这还是远远不够的。这种方法通常称为穷举路径测试,以后将进一步进行深入探讨,在这里就不多加叙述。所谓穷举路径测试,即如果使用测试用例执行了程序中所有可能的控制流路径,那么程序有可能得到了完全测试。

  然而,这个论断存在两个问题。首先,程序中不同逻辑路径的数昀可能达到天文数字。图 2-1所示的小程序显示了这一点。该图是一个控制流图,每一个结点或圆圈都代表一个按顺序执行的语句段,通常以一个分支语句结束。每一条边或弧线表示语句段之间的控制(分支)的转换。图 2-1描述的是一个有着 10~20行语句的程序,包含一个迭代 20次的 DO循环。在 DO循环体中,包含一系列嵌套的 IF语句。要确定不同逻辑路径的数量,也相当于要确定从点 a~点 b之间所有不同路径的数量(假定程序中所有的判断语句都是相互独立的)。这个数量大约是 1014,即 100万亿,是从 520+519…十 51计算而来,5是循环体内的路径数量。由于大多数的人难以对这个数字有一个直观的概念,不妨设想一下:如果在每五分钟内可以编写、执行和确认一个测试用例,那么需要大约 10亿年才能测试完所有的路径。假如可以快上 300倍,每秒就完成一次测试,也得用漫长的 320万年才能完成这项工作

图2-1 一个小型程序的控制流图

当然,在实际程序中,判断并非都是彼此独立的,这意味着可能实际执行的路径数量要稍微少一些。但是,从另一方面来讲,实际应用的程序要比图 2-1所描述的简单程序复杂得多。因此,穷举路径测试就如同穷举输入测试,非但不可能,也是不切实际的。

  “穷举路径测试即完全的测试”论断存在的第二个问题是,虽然我们可以测试到程序中的所有路径,但是程序可能仍然存在着错误。这有三个原因。

  第一,即使是穷举路径测试也决不能保证程序符合其设计规范。举例来说,如果要编写一个升序排序程序,但却错误地编成了一个降序排序程序,那么穷举路径测试就没多大价值了;程序仍然存在着一个缺陷:它是个错误的程序因为不符合设计的规范。

  第二,程序可能会因为缺少某些路径而存在问题。穷举路径测试当然不能发现缺少了哪些必需路径。

  第三,穷举路径测试可能不会暴露数据敏感错误。这样的例子有很多,举一个简单的例子就能说明问题。假设在某个程序中要比较两个数值是否收敛,也就是检查两个数值之间的差异是否小于某个既定的值。比如,我们可能会这样编一条 Java 语言的 IF语句:

  if (a – b < c)System.Out.println(“a-b<c”); 当然,这条语句包含一个错误,因为它可能将 c与 a-b的绝对值进行比较。然而,要找出这样的错误,取决于 a和 b所取的值,而仅仅执行程序中的每条路径并不一定能找出错误来。

  总之,尽管穷举输入测试要强于穷举路径测试,但两者都不是有效的方法,因为这两种方法都不可行。那么,也许存在别的方法,将黑盒测试和白盒测试的要素结合起来,形成一个合理但并不十分完美的测试策略。


TAG:

temp20121017的个人空间 引用 删除 temp20121017   /   2012-12-18 21:12:13
这个是测试经济学吗
temp20121017的个人空间 引用 删除 temp20121017   /   2012-12-18 21:11:13
这个是经济学
 

评分:0

我来说两句

日历

« 2024-05-14  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 9562
  • 日志数: 23
  • 建立时间: 2012-04-12
  • 更新时间: 2012-08-20

RSS订阅

Open Toolbar