《微软的软件测试之道》读书笔记 之 结构测试技术

《微软的软件测试之道》读书笔记 之 结构测试技术

2014-07-18

我们需要结构测试吗?

微软的一项试验说明了结构测试的在代码覆盖中起到的效果:

超过3000名测试员参与了这项实验,每25人一组,实验结果在所有组中都是一致的。在这项研究中,

  • 脚本化测试:根据样式书设计的脚本化测试在被测程序上达到了标称83%的代码覆盖率。
  • 探索性测试:然后,实验参与者允许进行每人15分钟,累计5小时的探索性测试。令人惊讶的是,代码覆盖率平均只增加了3个百分点。
  • 结构测试:但是,当实验参与者能够分析探测过的(Instrumented)代码的运行结果并使用白盒技术设计测试以后,不到20分钟的时间代码覆盖率就提高到了 91%(这是不使用代码突变或故障注入所能达到的最大实际代码覆盖率)。同时,测试员们也能够更好的从代价和收益的角度解释为什么剩下的9%未覆盖代码是不可测试的。

下图显示了不同测试技术的代码覆盖效果。

图1 不同测试技术的代码覆盖效果

块测试



此书把块测试、决策测试、条件测试、基础路径测试都归入结构测试技术。这里主要讲一下块测试。

块覆盖和语句覆盖

  • 语句覆盖测量一个程序在测试过程中被执行过的语句的数量。
  • 块覆盖测量无分支的连续语句组的数量。导致控制流程转向分支的条件语句可以包含若干块。

这个看起来似乎只是一个极小的区别,然而,语句测试和块测试的区分是相当重要的。因为相较于语句测试,块测试对控制流程提供了更好的敏感度。

?代码块的计算

块测试小结

块测试是用于单元测试的一种普遍方法:

优势:它非常适合于迅速地评估某函数的基本功能。对于设计用于执行switch/case语句和异常处理程序控制流程的测试来说,它也是一个很有价值的技术。

劣势:然而,块测试是健壮的结构测试中相对较弱的标准,它还可能漏掉控制流程的一些重要的分支。此外,块测试还容易忽略一些潜在的问题,特别是在我们测试的目的只是要提高代码覆盖率而不是要仔细分析被测试代码的情况下。

《微软的软件测试之道》读书笔记 之 结构测试技术

时间: 2024-10-01 06:55:20

《微软的软件测试之道》读书笔记 之 结构测试技术的相关文章

读《微软的软件测试之道》有感(上)

在这个电子书漫天飞的年代,我居然仍然喜欢读纸书,喜欢一边读一遍闻书的味道,就像品尝一顿美味的大餐一样.最近得了一本<微软的软件测试之道>,啃了一段时间了,每次重新拿起来看就觉得里面的内容忘得一干二净了,想起之前有位领导总是教导我们:“要不断总结,要累积,这样才会进步!”之前每次听这话都觉得烦,后来工作久了才知道总结有多重要,如今为了记住这本书的内容,我决定写个读后感,想到哪里写到哪里. 第一部分: 第一章<微软的软件工程> 第二章<微软的软件测试工程师> 第三章<

测试技术的思考 ---- 读《微软的软件测试之道》有感系列

假期期间,带着复习巩固测试基础理论的目的,开始阅读<微软的软件测试之道>,阅读过程中有不少启发,遂将自己的思考及学到的知识在此处做个总结记录. 1. 为什么阅读这本书? ????做了几年测试工作,随着对测试理解的加深,我发现测试理论对于日常的测试工作有较大的帮助与影响.待测系统复杂多样性的增加,要求我们也逐步去思考,如何测试,才能保证待测系统的质量,这期间就需要测试理论的支撑. ????我个人的一个观点是,一个优秀的测试工程师,或一个优秀的软件开发测试工程师,需要在三个方面持续的打磨: 理论

Google软件测试之道(二):测试工程师

一种面向用户的测试角色 一种用户开发者,TE首先必须是工程师,Google的TE他综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力.在研发的早期阶段,功能还在不断变化,最终功能列表和范畴还没有确定,通常TE没有太多工作可做.在TE进入产品时,需要考虑以下问题: 当前软件薄弱点在哪里? 有没有安全.隐私.性能.可靠性.可用性.兼容性.全球化和其他方面的问题? 主用户场景是否功能正常?对于全世界不同国家的用户都是这样吗? 这个产品能与其他产品互操作吗? 当发生问题时,

软件测试之路再谈(三年测试风雨)

碧水涟涟,夏至未至,秋风依依,梅花落时,已是一生 一初衷: 为什么写这篇博客? 个人性别偏于低调,最近换了新工作,坐标成都,就任于一家T系公司. 1.公司是以项目为单位,有测试团队但没有测试部这个概念,测试团队人数大概60人左右,但都基本跟你没任何关系,只有项目上的其他两个成员跟你有交集,缺少后方养分,差异性,一时间不太适应, 2.业务划分很精细,能接触到的东西十分有限,还有各模块之间弱化了连接测试,担忧.已经发现过问题,而且也和组员讨论过他们也赞同这种方式容易出现质量弱化 基于以上有些迷茫吧.

VC++编程之道读书笔记(2)

第三篇 技术细节 第七章:细说开发人员必知必会的39个开发细节 细节36:单例模式的应用 在开发程序时,往往需要在整个工程中只需要一个类的实例.而这个实例一旦被创建就不能被其他的实例再创建了,通常我们称这个实现过程为单例模式. 既然要保证类只有一个实例,那么就需要其他的类不能使用实例化该类.因此,需要将其构造方法设为私有的,即使用private关键字修饰.同时,类中提供一个静态方法,该方法的返回值是该类的一个实例.这样就只能使用该静态方法来获取类的实例了,从而保证了唯一性. 下面通过具体代码来实

转《Google软件测试之道》

<Google软件测试之道>,一直听朋友讲起这本书,出于琐事太多,一直没机会拜读,最近部门架构觉得我们IT部门的技术太low,就给我们挑选了一些书籍,让我们多看看... 个人的一种学习习惯吧,就做了笔记,将自己的学习理解感触写下来... 预计会分为五部分写这些学习笔记,分别是Google软件测试基础介绍.软件测试开发工程师.软件测试工程师.测试经理以及附录其他部分... 快乐阅读,快乐测试,祝愿你总能发现(并修复)BUG... ----James Whittaker.Jason Arbon.J

VC++编程之道读书笔记

第二篇 缪误21:位图数据是按照红绿蓝顺序存储的 大家都知道位图的颜色是由红.绿.蓝三个分量构成的,但是位图颜色数据存储的方式则不是按照这个顺序存储的,而是按照蓝.绿.红的顺序存储的.并且对于真彩色位图来说,位图的颜色数据是倒序存储的,即位图的第一行数据位于位图数据的最底部. 第三篇 细节12 :内存中的数组 在C++中通过数组可以操作内存,创建数组时需要为数组分配内存空间,操作数组时就是对内存空间中的数组元素进行操作.数组创建后,数组引用和数组元素分别存储在栈内存和堆内存中,并通过数组引用与数

《Google软件测试之道》测试开发工程师

拖延了将近半年的草稿,断断续续的写完了.之前草草翻看完这本书,关注点主要在TE上,而关于SET的部分则只是浏览,最近后知后觉,又翻出了这本书,重新看了一遍,又有新收获. 就说说Google的SET是如何做的,以及个人的一些思考和收获吧,寥有慰藉... Google的测试流程可以简练的概括为:让每个工程师都注重质量.而在工作流程引入过程中也伴随着一些致命的缺陷,下面简述下Google是如何解决以及其测试流程的是如何进化的. ①.测试并不能保证产品质量.需要一直谨记的一点:质量是内建的,而不是外加的

《软件需求》读书笔记3

<软件需求>读书笔记之三 需求来源.需求收集方法 软件需求可以来自方方面面,这取决于所开发产品的性质和开发环境.需从不同用户代表和来源收集需求,这说明了需求工程是以相互交流为核心的性质.下面是几个软件需求的典型来源. 1). 访问并与有潜力的用户探讨为找出新软件产品的用户需求,最直截了当的方法是询问他们. 2). 把对目前的或竞争产品的描述写成文档 文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则. 3). 系统需求规格说明 一个包含软.硬件的产品需要一个高档次的系统需求规格说