谈谈软件测试的梅氏七原则

发表于:2020-1-02 09:47

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

 作者:肖哥shelwin    来源:测试不将就

  今天,和大家聊聊一篇题为《软件测试七大原则》的文章。文章作者Bertrand Meyer(贝特朗.梅耶)是位杰出的软件工程专家,编程语言Eiffel发明人,契约编程(contract programming)之父,出版过多本关于面向对象编程,敏捷和编程理论的畅销技术书籍。
  在这篇文章中,梅耶提出了七个关于软件测试的原则,姑且将其简称为梅氏七原则。下面肖哥就来逐一介绍这些原则,并谈一些自己的体会。
  梅氏第一原则是关于软件测试定位的。梅耶反对将软件测试的价值拔高到质量评估和质量保证层面上来,而主张测试仅仅是一个努力让软件失败的过程而已。测试的核心意图不是为了证明软件能够正常工作,而是通过触发软件失败(failure)来暴露软件bug(缺陷)。
  这一原则与计算机大师Dijkstra(就是他发明了计算机领域无人不知的Dijkstra最短路径算法)关于软件测试的著名格言不谋而合。这个格言就是:软件测试只能证明软件有bug,不能证明软件没有bug。
  在学术界,测试有一个被广泛接受的定义,即测试是对软件执行的抽样观测。梅耶认为,与软件可能存在的执行样本(或执行路径)数量相比,再多的测试用例也只是沧海一粟。因此,即使测试用例成功率已经100%,也无法说明软件就没有bug了。
  关于测试与bug,测试与质量之间的关系,一些经典软件测试书籍中均可以找到类似的观点。例如:
  1) "发现软件bug的策略与确保软件工作的策略是不同的,后者致力于验证软件行为是否符合特定需求,而前者致力于在任意条件下破坏软件行为" —— Glenford Myers,《软件测试的艺术》,2011
  2) "你不可能通过软件测试来确保软件没有bug" —— Boris Beizer,《软件测试技术大全》,1995
  3) "即使投入无限的时间和金钱,测试者也无法发现软件所包含的全部bug" —— Bill Hetzel,《软件测试指南》,1993
  由于篇幅限制,这些经典观点背后的论据就不具体阐述。基于这些观点,可以发现前段时间网络上流行的所谓软件测试灵魂三问之一,"为什么这个bug测不出来?",其实是经不起反驳的,毕竟测试遗漏bug从来都是一件客观上无法避免的事情。
  强调测试的这一性质,既不是为了贬低测试,也不是为了帮助测试"甩锅",而是希望形成正确的测试认知,并以此指导测试实践。例如:
  1) 既然测试无法发现所有bug,那么我们应该区分严重bug与普通bug,致力于减少严重bug被遗漏的机会。
  2) 既然bug是发现不完的,那么我们无法以"剩余bug数"这一指标作为测试可停止或软件可交付的标准,而应该考虑"已发现bug数","单位时间新发现的bug数"等其他指标。
  梅氏第二原则是关于测试驱动开发(TDD)的。梅耶认为,在TDD中,测试用例并不能取代软件说明(或软件描述, specification)。这是因为,软件说明是一种抽象,而测试用例是一种具象,是软件说明的实例化。
  遵照测试用例来实现软件功能的最大风险在于:测试用例与软件说明可能不完全等价。因此,在TDD中,传统软件开发所依赖的软件说明是不能被摒弃的,仍然是开发过程中需要遵守的规约。
  梅氏第三原则是关于测试改进的。其内容是,任何失败的软件执行必须产生一个新的测试用例或检查点。
  在上文中,我们提到测试是对软件执行的抽样观测。既然是抽样,那么必然存在不完善之处,而完善测试的方法之一就是从失败中学习。
  对于每一个发生在测试阶段之外的软件失败,都应该检查测试用例,分析为什么失败没有被测试用例捕获到,并有针对性地进行弥补。
  在《度量测试覆盖率的三种方式》一文中,我总结了测试覆盖率的三种形式,即代码覆盖率,需求覆盖率和bug覆盖率。现在我想加上第四种,那就是bug-fix(bug修复)覆盖率。
  具体来说,我们要看看在修复每一个用户场景或端到端测试阶段发现的软件bug时,是否也对上游测试阶段进行了针对性的用例新增或修改。这样,当同一bug再次出现时,就可以更早发现它。
  梅氏第四原则是关于测试预言(test oracle)的。梅耶认为,测试预言必须被自动化。
  在软件测试中,测试预言可以说是一个十分低调的概念。在暗地里,它被使用得很多;但在明面上,它被谈论得很少。
  根据维基百科的定义,测试预言是一种确定软件期望输出的机制。大家知道,软件测试的基本方法是将软件实际输出与期望输出进行比较,由此来判断软件行为是否存在异常(即是否有bug)。
  这个基本方法依赖于软件期望输出这一先验知识。那么,如何提前知晓软件的期望输出呢?这就需要借助测试预言的能力。在我看来,测试预言这个名词之所以会被创造出来,与它的表现形式多样化存在关联。
  下面举两个简单的例子,帮助大家认识测试预言的多样化性质。
  例子一,我们要测试某个加法函数sum(a, b)。为此,我们设计了一个a=1, b=2的测试用例,以测试该函数的实际输出sum(1, 2)是否等于期望值。显然,在开始测试之前,我们需要知道1和2相加的期望结果。
  这时,我们可以依靠在幼儿园就掌握了的四则运算能力,算出期望结果为3。此时,测试预言是人的一种专业能力。测试用例可以表示为:
 assert sum(1, 2) == 3
  当然,我们还可以依靠编程语言内置的加法运算符+来实现测试预言。此时,测试语言是另外一个等价程序。测试用例可以表示为:
 assert sum(1, 2) == 1 + 2
  例子二,我们要测试某个登陆页面,并且设计了一个用户名与密码不匹配的测试用例。通过阅读软件需求文档,我们了解到这种用户场景下的期望结果是登陆页面弹出一个"用户名或密码错误"的提示框。此时,测试预言是一个软件需求文档。
  仅仅从这两个简单的例子,我们就了解到三种差异巨大的软件期望结果生成机制。测试预言作为一个抽象概念,就是用来统一描述这个机制的。
  测试预言最大的问题在于它往往是人工生成的,一般依赖于测试者的专业能力或测试者对软件需求的理解。由于每个测试检查点都对应着一个测试预言,因此人工生成测试预言成本高,扩展性差,并且易于产生偏差。
  这就不难理解为什么梅耶认为测试预言必须被自动化。当然,自动化测试预言谈何容易。梅耶之所以对自动化测试预言信心十足,我猜测可能与他提出的契约编程思想有关。
  在契约编程中,会给每个软件组件定义正式,精确和可验证的接口,并且将契约(前置条件,后置条件,不变式)嵌入到代码之中。这样,我们既无需编写测试用例,也无需设计测试预言。它们都是自动化的。从测试成本角度来看,契约编程确实有独到之处。
  "一个高效的测试过程,既需要包括人工生成的测试用例,也需要包括自动化生成的测试用例"。这就是梅氏第五原则。梅耶认为,人工生成用例的优势在于深度,而自动化生成用例的优势在于广度。
  注意到,这里的人工和自动化,形容的是用例生成,而不是用例执行。对我个人来说,除了录制回放,其他的用例生成技术,例如由文档生成用例,由代码生成用例等,真正落地经验很少,因此不便多评论。总体感觉是也许自动生成用例一时爽快,但是用例后期维护成本不容忽视。
  梅氏第六原则认为,无论某个测试策略在理论上如何有吸引力,都应该经过有明确标准的客观实践检验。比如,梅耶就认为,简单的随机化测试效果,往往不输于一些精心设计的测试策略。
  他举了蜜蜂与苍蝇的著名生物学实验为例。在这个实验中,把一群蜜蜂和苍蝇装进玻璃瓶,将瓶子横平放置,并让瓶底朝着光源。这时候,被认为智商更高的蜜蜂不停地往封闭的瓶底飞,企图找到出口,直到力尽而死。而苍蝇到处乱窜,反而很快就都从瓶口逃出。
  参照这个实验,梅耶认为,精心设计的测试策略和测试用例不一定效果就好,而随机化的,漫游式的,探索性的策略和用例不一定效果就差。评价一个测试策略或用例是否好坏,最终看的是结果,而不是表象。
  那么,如何客观评价一个测试策略的好坏呢?梅氏第七原则指出,一个测试策略最重要的属性是它的时间-bug数曲线。什么是时间-bug数曲线呢?它反映的是随着时间的推进,测试所发现的软件bug的累计数量的趋势图。
  梅耶认为,比起测试用例数量和测试覆盖率,时间-bug数曲线无疑更有意义。它既能体现测试的有效性,即发现更多的bug,又能体现测试的效率,即在单位时间里发现更多的bug。
  另外,这个曲线既可以用来评价测试策略的好坏,也可以用来预测软件质量。在软件测试过程中,根据时间-bug数曲线,并结合bug修复的速度,我们可以很容易构造出一个预测未来某个时间点缺陷存量的模型。
  以上就是梅氏七原则的主要内容。需要说明的是,梅氏七原则不是软件测试原则的全部,还有些重要的原则并不涉及,例如:
  1) 测试不可穷尽原则:软件测试不可能穷尽所有测试用例。
  2) 二八原则:80%的缺陷来自20%的代码模块。
  3) 场景依赖原则: 软件测试高度依赖于测试场景。例如APP测试,web测试,接口测试等都是场景相关的,它们具备十分不同的测试方法和工具。
  另外,以上原则不是标准,软件测试也没有标准。这些原则只是从经验中提炼出的最佳实践,仅供大家参考。

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号