软件测试手段

发表于:2008-3-07 17:30

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:网络转载

分享:

  路径测试(path testing) 。一条路径包含测试员所执行的所有步骤,或程序为了得到正确状态所通过的所有语句。路径测试包括测试通过程序的很多路径。通过非平凡程序的所有路径是不可能的。因此,有些测试员进行子路径测试(subpath testing),测试很多部分路径。例如,基本路径测试(basis-path testing)包括测试一定类型(基本路径)的大多数或全部假设,这里采用的假设是如果测试了所有基本路径,那么几乎没有更长的路径会找出这些测试所遗漏的问题。

  语句与分支覆盖率(statement and branch coverage)。如果测试执行了程序中的所有语句(或代码行),则达到100%的语句覆盖率。如果执行了所有语句和一个语句到另一个语句之间的所有分支,则达到100%的语句和分支覆盖率。设计自己的测试,达到高的语句与分支覆盖率,有时叫做“基于覆盖率的测试(coverage-based testing)” 。(达到覆盖率目标后,可以停止测试,或停止设计更多的测试) 。把它叫做语句与分支覆盖率,是为了与关注其他类型覆盖率的测试相区别。配置覆盖率就是一个很好例子,这种手段执行同一条语句很多次,但是潜在产生非常不同的结果。其他例子还有很多很多(Kaner 1995a) 。关注达到高语句与分支覆盖率的测试往往遗漏很多类型的问题,例如(但不限于)与以下因素有关的程序错误:遗漏代码、边界值处理不正确、时序问题、硬件和软件配置兼容件问题,诸如指针越界、内存泄漏或栈破坏等最终导致栈溢出的滞后暴露问题、可使用性问题,以及其他方面没有满足客户需求的问题。这种手段在标识不完备测试方面(哪些代码还没有侧试过)要更有价值得多,而不是在所需测试量的最低标准方圆。的确,让测试员停止测试只是因为达到了X%的覆盖率,这样做很危险(Marick 1999) 。

  配置覆盖率(configuration coverage) 。如果必须测试100台打印饥的兼容性,并且已经测试了10台,就达到10%的打印机覆盖率。更一般地,配置覆盖率度量测试员已经运行(并且程序已经通过)的配置测试占计划运行的配置测试总数的百分比。为什么要把它叫做测试手段?一般我们只是将它看作是已经完成了多少一定类型测试的度量。但是,有些测试员完成的一系列特殊测试,可以更快、更容易地完成大量配置测试。对于他们来说,优化工作以达到高的覆盖率,是一种测试手段。

  基于规格说明的测试(specification-based testing) 。这种测试关注验证在规格说明中所做的有关产品的每个事实声明。(事实声明是可以用真或假表示的任何语句。)常常包括手册、市场开发文档或广告、技术支持人员寄给客户的印刷品中的所有声明。

  基于需求的测试(requirements-based testing) 。测试关注证明程序满足需求文档中的所有需求(或关注逐个需求地证明某个需求没有被满足。)

  组合测试(combination testing) 。相互组合测试两个或更多变量。本章最后的“测试手段附录”还要讨论这个问题。组合测试很重要,但是很多测试员对这种测试研究得还很不够。通过程序得到的大部分好处都基于很多变量的交互。如果不在测试中一起改变这些变量,就会遗漏由不同的组合(而不是不同的单个取值)触发的错误。

  经验51,关注测试原因(针对风险测试)的基于问题的测试手段

  基于风险的测试(risk-based testing)至少有两个主要含义。

  Amland (1999)提出了一种基于风险测试管理的很好描述。根据这种观点,进行风险分析是为了确定下一步要做的测试。要根据程序中某个功能失效的可能性,以及如果失效确实发生可能造成的损失,确定测试的优先级。昂贵失效的可能性越高,尽早、尽可能仔细地测试该功能就越重要。

  另一个含义是我们更关注的,即为了发现错误进行风险分析。当研究产品的某个功能时,我们要研究它会怎样失效。这个问题又可以分解为很多额外问题,例如:失效外观是怎样的?这个功能为什么会失效?什么样的风险因素可能影响这个功能?本章“测试手段附录”将描述我们的基于风险测试方法。

  这两种基于风险测试的方法也在《James Bach论基于风险的测试》(1999)中做了描述。

  Whittaker和Jorgensen(1999和2000)做了精彩的讨论,给出了涉及约束冲突的各类错误的例子:

  输入约束(input constraint) 。限制程序可以处理的内容的约束。例如,如果程序只能处理32位数字(或小于32位数字),则程序员应该提供保护性例程检测并拒绝超出32位数字限制的输入。如果没有这样的保护,当程序试图处理它不能处理的输人数据时就会失效。

  输出约束(output constraint)。输入是合法的,但是会导致产生程序所不能处理的输出值。当程序试图显示、打印或保存输出值时会失效。

  计算约束(computation constraint)。输入和输出没有问题,但是在计算某个值(会产生一个输出)时,程序失效。例如,将两个很大的数乘在一起,积太大,程序不能处理。

  存储(或数据)约束(storage(or data) constraint)。输入、输出和计算都是合法的,但是操作使程序耗尽内存,或产生的数据文件太大,程序不能处理。

  Whittaker (2002)针对这些约束提出了详细建议。

  以下是基于风险测试设计的一些补充提示:

·如果进行基于风险的测试,还必须做相当量的非基于风险的测试,以针对了解还不够,还不能做出正确决策的风险进行测试。

·针对时序的测试。令人奇怪的是,很多接受美式教育的测试员都没有想到时序问题。一些经典时序问题包括竞争条件和其他事件意外发生顺序。

·在创建测试时,总要创建测试过程,以强制程序使用测试员输入的测试数据,从而能够确定程序是否不正确地使用了这些数据。
经验52,关注测试方法的基于活动的测试手段

  回归测试(regression testing)。回归测试涉及相同测试的重用,使得在软件变更以后可以重新执行(这些测试) 。共有三种回归测试。报告了程序错误,在该程序错误得到更正之后,这时的测试叫做程序错误更正回归(bug fix regression) 。其目标是证明该更正有误。老程序错误回归(old bugs regression)测试用来证明对软件的变更使老的程序错误更正变成未更正。副作用回归(side-effect regression)测试又叫做稳定性回归(stability regression)测试,要重新测试产品的很大一部分,其目标是证明该变更使得曾经没有问题的东西现在有问题了。

  脚本测试(scripted testing) 。手工测试,采用由更高级的测试员编写的测试过程步骤,一般由低级程序员执行。

  冒烟测试(smoke testing) 。这种副作用回归测试的目标,是证明新版本不值得测试。从一个软件版本到下一个版本,冒烟测试常常是自动化、标准化的。这种测试检查预期没有问题的内容,如果不是这样,就要怀疑该程序是用错误文件或基本上有问题的东西构建的。

  探索式测试(exploratory testing) 。我们期望测试员在整个项目过程中,都要了解产品、产品的市场、产品的风险和怎样没有通过以前的测试。不断创建并使用新测试。新测试比老测试更有力,因为新测试是建立在测试员持续增长的知识基础之上的。

  游击式测试(guerilla testing) 。对程序快速、有力的攻击。这是一种探索式测试,通常有时间限制,并由有探索式测试经验的测试员承担。例如,高级测试员花一天时间测试否则会被忽略的部分。测试员要进行最有力的攻击。如果发现严重问题,则对这部分要重新做预算,并且可能会影响整个测试计划。如果没有发现严重问题,这部分可以忽略,或只做少量测试。

  场景测试(scenario testing)。场景测试(顾名思义)一般要涉及四个属性。(1)测试必须是现实的,应该反映客户实际要做的事。(2)测试应该是复合的,要以能够对程序构成一定挑战的方式包含多个功能。(3)应该能够容易并且快速地显示出程序是否通过测试。(4)如果程序没有通过测试,有关人员会强烈要求修改程序。具有这四种属性的测试会很有说服力,如果程序不能通过测试,一般会导致修改程序错误。但是,测试员可能需要花几天的时间开发出色的场景测试。

  场景测试(scenario testing) 。通过用例导出的测试,又叫作测试试验(Jacobson 1992),Collard 1999)或用例流试验(use case flow test) 。(很多人把这些测试归到基于覆盖率的测试中,并注重要用例的覆盖率。)

  安装测试(installation testing) 。以各种方式,在可以安装该软件的不同类型系统上安装该软件。检查在磁盘上增加或修改了哪些文件。安装后的软件能够正常运行码?再卸载时会出现什么情况?

  负载测试(load testing) 。通过在面临很多资源要求的系统上运行,攻击被测程序或系统。在足够高的负载下,系统可能会失效,但是导致这种失效的事件模式会指出被测软件或系统中的弱点,这些弱点可能在被测软件的更一般的使用中暴露。Asbock(2000)对负载测试做了精彩介绍。

  长序列测试(long sequence testing) 。测试要持续一夜,甚至几天,几周,目标是发现短序列测试遗漏的错误。这种测试经常发现的错误包括越界指针,内存泄漏,栈溢出,超过两个特性之间的错误交互等。(长序列测试有时叫做持久测试(duration testing),可靠性测试(reliability testing)或耐力测试(endurance testing) 。)

  性能测试(Performance testing) 。运行这些测试通常要确定程序运行有多快,以便确定是否需要优化。不过这种测试也可以暴露很多其他程序错误。如果与的一个版本相比出现显著性能变化,则这可能是编码错误作用的反映。例如,在试验今天运行一个简单功能测试需要多长时间,明天在同一台机器上运行同样的测试需要多长时间时.如果两次运行时间相差三倍以上,则可能需要与程序员进行核对,或编写错误报告。更慢和更快两种情况都要警惕.因为程序的基本内容发生了变化。①

  ①  Sam Guckenheimer指出, “性能差距还可能反映第三方组件或配置的变化。例如,JDK不同版本的JVM变化,会导致性能显著变化。由于这是客户可更新的组件,因此即使代码根本没有改变,性能测试也可能产生令人惊讶的结果”!

32/3<123>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号