探索式测试--第四章(全局探索式测试法)--读书笔记

本章的内容则是关于测试人员在全局方面所必须做出的各种决定,比如在考虑特性交互、数据流以及在应用程序的用户界面上如何选择不同路径来完成某个实际功能时。探索式测试人员在实际开始测试前,需要建立起这样一个全局目标,用于指导以后的测试过程。在这里,我们借鉴旅游行业的概念,使用传统旅游者的各种工具,比如旅行团、旅行指南、地图和当地信息等,来类比软件探索测试过程中的各种方法。这些方法可以帮助测试人员明确测试的目的,指导他们在测试过程中做出正确决定。

我们想要达到如下目标:使用比喻来指导测试人员选择正确的输入、数据、状态、代码路径和环境设置,从而在其测试时间和测试预算之间获得最大产出。

对于探索者来说,有的放矢肯定远远胜于毫无目地的乱逛。如果一个比喻产生的目标能让测试者做出某些全局或局部的决定,那么测试人员就不会漫无目的的测试本章通篇都在使用比喻的方法,特别是使用游客来类比测试中的一些全局决定,这些全局决定确立了总体探索策略和产品特性的测试方法。

探索式测试有下面几个目标:

  • 理解应用程序如何工作,它的接口看起来怎样,它实现了哪些功能

新加入项目的测试人员经常采用这个目标,有经验的测试人员也会使用这个目标来探索应用程序。

  • 强迫软件展示其全部能力

它的目的是设法使软件努力运行。

  • 找到缺陷

探索应用程序的各种极端情况从而发现潜在的问题是探索式测试的专长。

真正的探险家很少在不制定详细策略和周密计划之前就开始探险;探索式测试人员也一样,对于那些功能比较复杂的特性、用户可能用到的功能以及缺陷最可能存在的地方,测试人员必须要尽可能地覆盖它们。我所想到的最好比喻是把它看成一个旅游者要去新的目的地探险。我把它称为“漫游测试”以纪念阿兰.图灵,是他提出了最初的图灵测试概念。

旅游者比喻

即使用上全世界所有的资金也不能保证可以测全软件的所有方面。

旅游者的目的对实际策略的选用起着举足轻重的作用。

作为测试人员,我们并不是经常能有机会在将来重新测试该应用程序,我们的第一次拜访很可能会成为唯一一次挖掘和探索应用程序的机会。我们负担不起漫无目的的游荡,因为这会导致错过重要功能和缺陷。我们必须使我们的每次访问都有收获。

有组织有目标的旅游和自由风格漫无目的的闲逛紧密地结合起来。

漫游测试

我们这里所说的特定测试通常要求把应用程序的多个特性和功能以崭新的方式组合起来,而且这种组合方式是那些严格以特性为基础的传统测试模式无法做到的。

旅游指南手册通常会把目的地划分成各种区域,有商业区、娱乐区、剧院区和红灯区等。对于软件测试来说,这种分割只是从逻辑上划分了应用程序的特征。软件测试人员应该探索应用程序的运行路径,以不同的顺序执行许多特性。因此,在进行类比测试时,我们对旅游指南做了一些修改。

下面是对所有的区域以及和它们相关的各类测试法的一个概述。

商业区:对软件来说,商业区同样指的是“在那里完成实际业务”,它位于软件的启动及关闭代码之间,并包含用户所使用的软件特性和功能。商业区就是软件包装盒上描述的那些特征,还包括市场商业活动或者销售演示中的各种特性和实现这些特征的程序代码。

历史区:对软件来说,历史就是它从前版本遗留下代码,还有那些曾经出现较多缺陷的特性和功能,正如真正的历史,遗留代码通常难以理解,包含、修改或使用遗留代码时,通常需要我们做出很多假设。对这个区域进行测试的目的就是测试遗留代码。

旅游区:许多城市设有只有旅行者才去的区域,本地人会避开这些拥挤的地方。软件也类似,有些特性和功能对新用户非常有吸引力,然而老用户不再使用它们。

娱乐区:软件也同样有这种辅助的特性和功能,适用于娱乐区的测试法可以用来测试这些功能,还可以补充其他区域中各种测试的不足,使得测试计划更加完善。

旅馆区:软件“休息”时,它实际上还是非常忙碌。适用于旅馆区的测试法就是要测试软件的这种特性。

破旧区:可是破旧区对测试人员来说是必须要去的,因为这里可能存在非常令人讨厌的漏洞。

商业区测试类型

商业区测试类型侧重于测试这些重要特性,并指导测试人员如何对执行这些特性的软件代码路径进行测试。

指南测试法

测试的角度来看,测试这样的热门区域非常重要,而且这种测试在任何一个测试策略中都属于非常重要的一部分。

相对于旅游手册,探索式测试使用的是用户说明书,可以是打印的版本或者是在线帮助。对于这个测试法,我们会像一个谨慎的旅游者,遵循用户手册的建议,从不偏离引导。

指南测试法要求测试人员通过阅读用户手册并严格遵照手册的建议执行操作。因此这个测试法不仅可以验证软件确实实现了手册所描述的各种特征,同时也验证了用户手册的准确性。

这个测试法的一个变种是博客测试法,这种方法要求测试人员遵循第三方的建议来测试,还有一种是专家测试法,这种方法要求测试人员根据那些怒气冲冲的评论者的抱怨来创建测试用例。另一个有用的变种是竞争对手测试法(使用竞争对手的使用手册来测试自己的应用程序),这种方法要求测试人员遵循这些专家或者博客为竞争对手们提供的建议来测试。

指南测试法用于测试软件是否题提供了与广告中所宣传的特性。强迫测试人员按用户的使用方式把软件特性串起来测试,同时还要求这些特性按用户的真实使用方式相互交互。所以这时发现的任何缺陷都很可能是极其重要的问题。

卖点测试法

软件也一样:用户买它自然是有其原因的。销售人员都是为卖点测试法提供信息的绝佳来源。

进行卖点测试法的测试人员应该观摩那些销售演示,观看销售录像并跟着销售人员一起拜访客户。在执行测试时,按照产品演示的步骤自己来执行一遍,并看看有没有发生问题。

这个测试法的一个重要变种是质疑测试法,就是在测试人员执行卖点测试法时,假想有一个爱问问题的客户,他不断地打断演示,提出一些苛刻的问题,这种情况在用户演示中经常发生。这种测试法对于创建那些最终用户非常在意的测试用例时非常有用。

地标测试法

地标测试法也使用类似的方法,我们先选择地标,然后在软件中执行类似于在森林中地标间跳跃的动作。在微软公司,通过使用指南针测试法和卖点测试法,可以提前确定那些关键的软件特性,也就是这里的地标。在选择完地标后,需要确定它们的前后顺序,然后从一个地标执行到另一个地标来探索应用程序,直到访问了列表中的所有地标。测试人员使用这个测试法为基础还可以创建出许多的变种。比如可以在执行测试法之前选择多个起始地标,并开始执行测试方法,或是在测试开始后增加新的地标,还可以改变各个地标的前后访问顺序。

地标测试法是最受欢迎的测试法,其次是极限测试法。

极限测试法

极限测试法采用的途径是向软件提出很多难以回答的问题。这个测试法对每个应用程序都不同,但是想法是一样的:向软件提出最困难的问题,这样就有可能发现软件的应有能力和这些能力的具体逻辑实现之间的差异。

这个测试法有一个变种,就是找麻烦测试法。测试时,该方法要求测试人员故意设置各种障碍来看软件如何应对。所做的一切不一定要有什么实际意义,这么做的原因只是运维软件允许这么做。

快递测试法

在这个测试法中,测试人员必须专注于数据。应该确认那些被存储起来的输入数据并跟随他们走遍软件。测试人员应该参与数据生命周期的每个阶段。

深夜测试法

软件中的卖点测试特性的代码可能不运行了,但还有其他应用程序在工作。它们执行各种维护任务,将数据挖掘,备份文件,等等。有时应用程序自动做这些事情,有时测试人员可以强制它去做,深夜测试法就是提醒我们应该要去测试这些事情。

这个测试法的变种是清晨测试法,目的是测试软件的启动过程和脚本。

遍历测试法

遍历测试法通过选定一个目标,然后使用可以发现的最短路径来访问目标包含的所有对象。

历史区测试类型

软件中的历史区指的是那些遗留代码,或是在前几个版本就已经存在的软件特性,也指那些用于修复已知缺陷的代码。重新测试那些曾含有很多缺陷的代码特别重要。

恶邻测试法

软件也有这样的情况--就是指那些缺陷横行的代码段。随着测试的深入,发现和报告越来越多的缺陷后,就可以把缺陷数目同产品特性联系起来,从而可以跟踪究竟在哪些地方会出现产品缺陷。由于缺陷通常扎堆儿出现,因此产品缺陷的地方值得反复测试。一旦确定了某个代码区域缺陷很多,我建议对邻近功能使用遍历测试法进行测试,以此来验证那些修复已知缺陷的代码没有引入新的缺陷。

博物馆测试法

软件中的古董指的是那些遗留代码。测试人员稍加研究就能发现那些最近被修改过的老代码。在这个测试法中,测试人员应该找出那些遗留代码和老的可执行文件,并确保它们在测试中受到和新代码同样的待遇。

上一版测试法

如果当前产品构造是对先前版本的更新,很重要的一点就是必须允许先前版本上支持的所有场景和测试用例。

娱乐区测试类型

大多数软件有满足这些需求的类似特性。

娱乐区测试法帮助测试人员测试那些辅助特性,而不是主线特性,并确保这两种特性能够实用而又有意义地结合在一起。

配角测试法

配角测试法鼓励测试人员专注于某些特定的特性,它们虽然不是那种我们希望用户使用的主要特性,但和那些主要的内容一同出现在显示器上。它们越紧邻那些主要功能,越容易被人注意,所以我们必须给予这些特性足够的重视,不能犯忽视它们的错误。

不管其他人从什么角度测试,把自己的注意力向左或向右调整几度,以确保配角得到应用的重视。

深巷测试法

在探索式测试的术语里,它指的是最不可能被用到的或是那些最不吸引用户的特性。

深巷测试法就是建议测试人员应该测试该使用情况列表中排在最下面的几项特性。如果测试部门跟踪了代码的覆盖率,这个测试法就是要求测试人员想办法测试那些还没有被测试到的代码。

存在一个有趣的变种,叫混合测试法,试着把最流行和最不流行的特性放在一起混着测。也可以把这些想象为在地标测试法中,把重要的地标和不重要的地标交替混合起来进行测试。

通宵测试法

这个测试法背后的逻辑是永远不要关闭程序。这个概念也可以引申为连续不断地使用某些特征或将文件一直保持在打开的状态。

旅游区测试类型

这种旅游不关心软件是否工作,它关心的是快速访问软件的各种功能,其目的只是为了到此一游。

收藏家测试法

探索式测试人员也收集东西并努力做到能把东西收集全。建议我们收集软件的输出,收集的越多越好。这个测试法背后的想法是测试人员到达所有那些可到达的地方并把观察到的输出结果记录下来。

这种测试法很庞大,通常最好是以小组为单位来进行,在小组成员之间分派特性或者安排某些测试人员专职收集某些输出。

长路径测试法

其想法是访问离应用程序开始点尽可能远的特性。这里的主要指导思想是到达目的地之前尽量多地在应用程序中穿行。选择长的路径而不选择短的,把那个埋在应用程序最深处的界面作为测试目标。

超模测试法

使用这个测试法时,要求测试人员只关心那些表面的东西。不论测什么,不要超出表面皮肤的深度。超模测试法中,重点不是在功能或测试功能间真正的相互作用,而只是测试界面。

测一送一测试法

非常简单,它只测试同时运行同一应用程序多个拷贝的情况。测试时运行一个应用程序,然后运行应用程序的另外一个拷贝,然后再运行一个拷贝。

苏格兰酒吧测试法

特别适用于大规模的复杂应用程序。在这些应用程序中的有些地方,测试人员需要事先知道如何去找到它们。

旅馆区测试类型

软件测试人员放过那些主要的和受欢迎的功能,而去测试一些经常被忽视和或者在测试计划中较少描述的次要及辅助功能。

取消测试法

取消测试法的思想是启动操作然后停止它。探索式测试人员必须寻找应用程序中最耗时的操作来充分实施这种攻击方法。这个测试法中,测试人员见到的失败绝大多数与应用程序自我清除能力不足有关。我们应该假定用户偶尔会取消一些操作,但是他可能马上又重新做一次相同的操作。

懒汉测试法

懒汉可以是非常有效的测试人员。测试人员没做很多事情并不意味着软件也不做事情。懒汉测试法是指测试人员做尽量少的实际工作。意味着接受所有默认值,如果程序中有选择可以走这边或者那边,懒汉总是走最不费力的一边。

编程中经常会出现没有对默认值进行处理的情况。

破旧区测试类型

输入恶邻数据以破坏软件和做一些通常有害的事情会让人生厌,但在这里很合适。

破坏者

我们会试图利用每个可能的机会暗中破坏应用程序。

对该测试法的直观总结如下:强迫软件做一些操作;掌握软件成功完成操作必须使用的资源;在不同程度上移除那些资源或限制使用那些资源。在这个测试法中,测试人员会发现很多方法可以操纵环境使它变得更为恶劣。

反叛测试法

探索式测试人员人员经常试图破坏东西,变得反叛一点必有收获。反叛测试法要求输入最不可能的数据,或者已知的恶意输入。

有三个专门的方法可以实现反叛行为,总结如下:

逆向测试法:每次都输入那些最不可能的数据。这么做,是在测试应用程序的错误处理能力,可以把它想象成在测试应用程序的忍耐力,这样就比较容易理解。

歹徒测试法:这是关于如何处理非法输入的测试法。基本想法是输入一些不应该出现的数据。测试人员可以输入错误的类型、错误的格式、太长的输入或者太短的输入等。

错序测试法:要求测试人员以错误的顺序做事情。选择一组合法的行为,将它们混在一起,造成前后顺序不合法。

强迫症测试法

在强迫症测试法中,患有强迫症的测试人员一遍又一遍地输入同样的数据,它们会反复执行同样的操作。他们重复、重做、拷贝、粘贴和借用,然后多次重复做这些事情。最重要的是重复。开发人员通常认为用户应该按照特定的顺序做事情,有目的地使用软件。

漫游测试法实战

前述这些漫游测试法为测试提供了一个架构,它可以帮助测试人员创建出比使用自由发挥的方式更有趣、也更有针对性的用户场景。

在实际应用中,我发现可重复性是使用本书测试法的另一个好处。相比之下,使用有些测试法很可能比其他一些能发现更多的问题。漫游测试法还是在测试组成员之间分配测试任务的一个极好方法。从许多方面来讲,测试的目的就是在这次测试中尽最大努力,同时确保下次可以做得更好。旅游者比喻有助于我们对测试进行分类以达到目的。

小结

漫游测试法既能帮助测试人员思考如何测试应用程序,又能帮助他们组织实际的测试。这一系列的测试法可以编成一张测试核对表,这样可以避免测试人员遗漏某些测试类型,它还可以帮助测试人员把应用程序的功能和适合这些功能的测试技术相匹配。

此外,测试法还可以帮助测试人员作出无数的决定,如何决定测试路径,如何选择输入值,使用哪些参数进行测试。

最后,在微软,漫游测试法被看作汇总各部门间测试经验的一种机制,通过这一机制,一些测试法最终会被证明是很成功的。

猜你喜欢

转载自blog.csdn.net/zimingzim/article/details/81069570
今日推荐