测试的心理定势

 

岳晓东博士在中国版幸福课《幸福在我心》中,拿出一副达·芬奇的画作《蒙娜丽莎》让听众观察画里面还有什么。有的看出画里面有一只猫,有的看出画里 面还有一只狗,有的人除了蒙娜丽莎怎么也看不出来画里面还有什么。。。如果你看不出有什么动物,当休息一会儿,再看这幅画时,也许就能看到了。

这在心理学上称为“心理定势”,指的是一个人看问题一旦形成某种模式后,就不再思考了;但是如果暮然回首再回头看时,会觉得原来不是没得可为、不能再做什么事了,而是看待问题又有了新的突破。

这种心理现象在测试中是普遍存在的。

前 一段时间,我和另外几个人对同一被测对象各自单独进行了探索性测试。被测对象是Word2007的插入页码功能。在1小时的探索中,我测试了插入页码在页 面顶端、底端、页边距、当前位置,以及设置不同的页码格式、删除页码功能,发现缺陷集中在“在页面上编辑页码格式”( 比如放大页码格式的形状、移动其位置等等)以及对超大文件插入页码方面;由于页码删除功能比较简单,只测试了少许时间,认为其风险比较低。总体而言,我对 这次探索性测试比较满意。

可是,当我观察另外一个人的探索性测试时,我惊奇地发现,还有这样一个重要的功能完全不在我的视线范围之内:编辑 某种页码格式的属性。按如下的操作步骤:插入—页码—页面顶端—普通数字1—右键点击鼠标,选择“编辑属性。。。”,则弹出“修改构建基块”的对话框,用 户可以编辑修改此种页码格式相关的属性。同时我发现,她花费了较多的时间测试“删除页码”的功能,并且发现了一些问题。

为什么会出现如此的差异呢?这些功能和问题为什么我没有发现呢?

一个直接的原因就是,我把注意力集中在每种页码格式可能存在的问题上,每次选择一种页码后,直接点击鼠标左键,然后急于观察这种页码格式显示是否正确、当我改变其形状移动其位置后表现是否正确,从来没有想过点击鼠标右键。这么做,好的方面是,我找到一个点后,对这个点的测试会比较深入(Test in Depth);不好的方面是,测试宽度上(Test in Width)容易有所遗漏。

这里面有几个有趣的点值得深入探讨一下。

(1)心理定势

“总是直接点击鼠标左键、从来没有想过点击鼠标右键”,这虽然描述的是我的动作,但是一个人的行为取决于他/她(下文统一用“他”代替了)的思想和意识。

我的心理定势是:我认为插入页码的主要功能就是“插入各种格式的页码”,主要的风险也在这里,所以我的注意力也集中在“每种页码格式可能存在的问题上”。当我把这个集中的点进行了较充分的测试,并且真的发现了其中的一些问题,并且对这些问题进行了进一步的调查后,我就会认为:这次测试还是有些收获的、差不多可以结束了、主要的点基本都覆盖过了、应该没有什么大问题了,对那些可能被遗漏的点(比如“编辑属性”功能)和那些未知的缺陷(删除页码相关的缺陷)却浑然不觉。

当 然,如果我再进行一轮测试,很有可能会突破前一轮测试的思维定势,找到新的测试点、找到新的缺陷。所以,从测试的心理定势我想到的,为了保证更好的测试效 果,使不同的测试人员对同一个被测对象展开测试、或者同一个测试人员在不同时间对同一被测对象展开不只一次的测试,是很有必要的。

(2)深度测试与广度测试

注 意,在上面的分析中,我把“并且真的发现了其中的一些问题”重点强调了一下。如果我把注意力集中在“每种页码格式可能存在的问题上”,却什么问题也没有发 现,会怎么样呢?也许,我会怀疑之前自己对风险的假设,从而关注其他值得深入测试的点,也许就能发现上述的测试盲区。这说明,发现的缺陷往往会阻止缺陷的发现

这 句话的意思是,当我发现了一个缺陷,我就会花费时间去调查这个缺陷,它真的是个缺陷吗?还是我测试过程出现了问题?这个缺陷有可能导致什么问题?到底如何 触发这个缺陷的?有没有其他值得进一步挖掘的缺陷?对于一个优秀的测试人员来讲,解答这些问题的过程才是真正有趣的测试过程,就像一名猎手闻到猎物后开始 的一系列追踪的过程,充满希望和挑战!但测试也是充满矛盾的过程:测试需要这种深入的测试过程,深入的测试才能发现有价值的缺陷,可是发现了缺陷就会占用 你的测试时间、放缓你的测试脚步、“占用”你的测试思维,让你没有更多的时间、也无法能避免地忽视其他的缺陷,从而导致测试的遗漏,所以总是要在深度测试 和广度测试之间把握一定的平衡。

本文中提到的探索性测试的例子,我更偏向于深度测试,而另外一个人更偏向于广度测试。如果用那个沿着一条路 挖水井的例子做类比,我挖了很多坑,大部分都挖了100米,最终找到了4口井;她挖了更多的坑,都不超过50米,找到了2口井。其实,更好地平衡深度测试 与广度测试的话,我们都可以挖掘出更多的更有价值的井。

由深度测试与广度测试,还可以联想到另外一个测试中的矛盾点:你可以相信测试人员提 供的对被测对象质量的评价,但你又不能完全相信这个评价。深度测试更多与降低风险相关,广度测试更多与增加覆盖相关。无论测试人员做到怎样的平衡,都不能 同时做到100%的深度测试和100%的广度测试,也就是说,不可能既降低了所有的质量风险、又覆盖了所有应该覆盖的东西。我们知道,每个测试人员都是基 于他的测试情况给出他对被测系统质量的评价。比如,基于我的测试过程,我认为Word2007的插入页码功能在页数较多的大文件插入页码时存在质量风险、 系统对不同种类页码格式的处理有所不同(我的感觉)因而需要分别测试、对页码形状进行编辑等操作容易引起问题;而另外一名人员经过他的测试过程,认为 Word2007的插入页码功能质量不错,只有一些小的GUI界面提示性问题,没有什么大的问题,无需对每一种页码格式进行单独测试。作为测试管理者,你 应该相信每一位测试人员提供的质量评价,因为这个测试结论是测试人员基于他的测试过程对质量的真实理解,但是你显然不能尽信这个观点,因为这个真实的理解 并不代表真实的质量信息,只是目前测试人员能够觉察到的质量信息(Perceived Quality),你还要去了解这个观点是在什么样的测试宽度和测试广度下得出的结论。

(3)交替思维

怎么样克服测试的心理定势、避免测试的盲区呢?

也许你会说,我不用探索性测试,我用脚本化测试(Scripted Testing,这里对脚本化测试的理解与Cem Kaner在here里对Scripted Testing的描述是一致的)方法,测试前仔细阅读需求规格说明书,这样我就可以事先知道一共有多少个点需要测试了,就不会遗漏。

这样做其实并不能从根本上解决问题。

首先,需求一旦写成文档,就是不完整或不足够细致的需求了。你并不能依赖需求文档的完整性来避免漏测。而且,就算在测试执行之前,你已经了解了所有的需求,测试的心理定势以及其他一些因素仍然会致使你漏掉一些缺陷。

其 次,如果过于依赖脚本化测试方法,你的测试思路会不知不觉地受文档描述的影响。我们有另外一个人对插入页码功能也进行了测试。与我们的测试过程不同,他先 阅读插入页码的帮助,然后再开展测试。结果,我发现他的测试过程有很多“受文档影响的痕迹”。对于文档中没有提到的部分,他很少会关注。比如“对页码的形 状进行编辑”、“对过大的文件”来测试等等这样的操作”;而对于文档中提到的部分,他会关注较多,比如帮助中有这么一句话:“您可以将页码添加到文档的顶 部、底部或页边距。保存在页眉和页脚或页边距中的信息显示为灰色,并且不能与文档正文信息同时进行更改”,很显然这句话给他留下了深刻的印象,所以他在测 试中时不时地就会验证一下页码信息和正文信息是否可以同时修改。是的,我这里用的词是“验证”,也可以叫“检查”,可 以对应到英文的checking,我是说他的测试过程更偏向于checking,而不是testing。关于checking和testing的区别,可 以参考Michael Bolton的博文here。更偏重于checking的人,测试执行时会更倾向于去验证一下他之前认为的一个结果是否正确;而更偏重于testing的人,测试执行时会更多地想发现一些之前没有想到的情况、发现一些新的信息、获得对真实的系统更深一些的理解。

克 服心理定势、避免测试盲区,可能有很多种方法,比如运用系统性思维(Systems Thinking),散焦思维(Defocused Thinking),交替思维(Alternation Thinking)等,关于这些概念的更多信息,可以参考James Bach的书《Scerets of a Buccaneer-Scholar》,也可以参考这本书《经典思维50法》,里面有不少有趣的例子。限于篇幅,这里只分享一下我对交替思维的理解。

你 在测试时,是否有这样的时候,绞尽脑汁也发现不了什么问题、缺乏新的测试思路,或者感觉当前有点混乱、测试效率很低;或者当你读一本书的时候,读了一段时 间,发现大脑反应有点迟钝、阅读效果极差、感觉有点烦躁。这个时候,并不是你不专心高效测试了、不爱读书了,而是你的大脑给你传来一个信号:我已经接受了 太多的信息,请您休息片刻,让我消化消化,再继续工作。此时,是你运用交替思维的绝佳时机,你可以做些其他的事情转移当前的注意力,比如随便点击鼠标试试 其他的功能、比如整理一下你的测试记录、或者干脆休息一下。虽然你在休息,但你的大脑并没有休息,它在消化吸收刚才的信息,当你再次开始测试时,你会发现 测试效率提高了、测试思路打开了,往往会有意想不到的收获。

 

所以,下次测试的时候,不妨注意一下你是否也存在某种心理定势?这种心理定势是如何影响了你的测试效果?你的测试深度与测试广度又是如何平衡的?有意识地运用一下交替思维、系统性思维等思维方式,让你的测试更加高效起来!

 

本文发表于2012年第一期《测试人》电子杂志。



有 13 条评论

  1. 让测试飞起来说:
  2. 本文以页码为例,现在请看看新浪微博页码有什么问题?
    在现实中我发现有许多这样的情况:程序员“明知故犯”(能推断出),造成用户体验不好。哈哈


  3. 让测试飞起来说:

    看完第一段“心理定势”的例子令人叫好。同时把“有人能看出有猫,同一人在不同时候又看不出有猫或者有的人什么都看不出”的情况,极端地引申一下:如果所有人在之前就没有看到过猫,所有人什么都看不出。之所以如此引申,有人说ET需要有一定经验。我对ET一点不懂,无知者无畏地说:ET给人一种“玄”之感。
    举两个场景:
    1.郜老师在前面演讲,突然指向听众的身后并说道:“大家看…”,于是所有人回头仔细、仔细再仔细地观察,再回过头来面面相觑,不知何意。
    2.。。。。。。。。。。。。。。。。。。。。。:“最后排的灯为什么不亮了?”,于是大家回头“扫一眼”,果然是不亮,并进而去找原因。
    大家都知道这是一个关于科学是从观察还是从问题开始的一个例子。
    ET就像场景1,那ET有用吗?肯定有用,就像仔细观察有助于发现问题一样。但是,ET是不是最好的思维方式或方法论呢?不管是否,都可能是学习下一个的基础。 欢迎大家指点,拍转。


    • 邰晓梅说:

      只要你做过测试,就一定做过ET. 说”不懂”,可能是因为没有办法描述ET,更不知道如何把ET做得更有效吧. 绝大部分人都出于这个状态,James Bach发现了这点,专门研究了一番,让众人受益了.
      如果你从来没有见过猫,很可能是看不出猫来的. 这种情况下,用传统的ST(Scripted Testing)方法按部就班地也看不出猫,因为你在预期结果中,根本就不会写出”猫”这个字样. 当我们想发现新的信息时, 当我们不确定下一步要测试什么时,ET无疑比ST更适合,更有效.
      但凡谈到”XX是最好的XX”时,我都很谨慎,如果谁把这句话补充完整了,我下意识地就会用测试人员的心态去追根究底地反问,去逆向思考,去找出一个特例不是这样的,呵呵. 所以,作为测试人员,我不大相信”哪个方法会是最好,哪个技术是最佳实践”之类的话.


  4. 让测试飞起来说:

    哦。。。把极端引申反用于ST,即“ST(Scripted Testing)方法按部就班地也看不出猫,因为你在预期结果中,根本就不会写出”猫”这个字样. 当我们想发现新的信息时, 当我们不确定下一步要测试什么时,ET无疑比ST更适合,更有效.” 很受益!没想到用吾之矛攻己之盾, 呵呵。
    其实,用“最好。。。” 故意犯不谨慎错误,隐含着对ET的初识偏见(第一印象不好,不一定不好)。说白了,让热衷于ET的人也说出否定词(这个是我的不对)。对不确定下一步。。。到确定,最终倾向于场景2.(ST),发散,发散。。。收敛。
    这么快得到回复,非常感谢!!!
    -----------------
    马上回来是想表达测试人的无奈。
    文中提到右键,我测了一下word2003,右键弹不出窗口。这里我不想谈设计合理、增强功能等,而是想表达一个一个bug故事都是开发者一手编制而其本身又不知道 ,更说不清有多少。。。让一个旁观者去发现。无奈中感到测试不容易啊,再讨论是否需要测试人员就更乱了,哈哈。


  5. 让测试飞起来说:

    沙发上提的问题:本文以页码为例,现在请看看新浪微博页码有什么问题?
    发现新浪微博已改,新浪动作还挺快。 还有。。。
    -----------------------------
    本想描述一个场景,分析下bug产生原因,不在状态,今天先免了,就以调侃的方式,“晓”非“小”。。。不行了,调侃头脑也乱,正像文中所说的“。。。绞尽脑汁也发现不了什么问题、缺乏新的测试思路,或者感觉当前有点混乱、测试效率很低;。。。请您休息片刻,让我消化消化,再继续工作。” 遵命! 呵呵


  6. 让测试飞起来说:

    虽然选出测试word的典型例子(当然博主例子很多),但是也透露出ET也克服不了心理定势,甚至让更懂ET的人没有发现问题并反思:”……这些功能和问题为什么我没有发现呢?” 哈哈
    说明一下,对ET准备以逆向去了解和学习,言过之处,sorry!看了关于ST和ET的比较文章:http://blog.sina.com.cn/s/blog_6cf812be0100nlr4.html 不知道如何得出的数据,仅从数据上看似乎有编造的可能,极可能是我没看懂,数据好像出自:参考Juha ltkonen, Mika V. Mantyla and Casper Lassenius 《Defect Detection Efficiency: Test Case Based vs. Exploratory Testing》。这个就不深究了。
    至于什么时候ET,会在挖井例子和深、广度测试的讨论中再请教,请博主五一快乐!


  7. 让测试飞起来说:

    有始有终,把上面“至于什么时候ET,会在挖井例子和深、广度测试的讨论中再请教”话题结了。
    对文中的观点:
    1.本文中提到的探索性测试的例子,我更偏向于深度测试。。。
    是赞同的。产品类软件是需要深度测试的
    2.所以总是要在深度测试 和广度测试之间把握一定的平衡。
    也是赞同的,当时想用实例进行展开。

    都赞同,当时似乎要请教什么似的?

    是的。在这篇文章中我还没看出:“……,ET无疑比ST更适合,更有效”.(ET看不出猫,ST也描述不出猫)

    我想表达的是:如果参与测试人员的广泛性、多样性、时长等等the more ,发现bug越多,那以,ET想通过发散-》模拟广、多,我现在还是想不清楚能否更有效。时间上花了N倍时间,多找出一个bug,在现实中不可取,老板会生气的,哈哈。

    ET要求人员素质较高(有经验,有技能等),是不是有利于在广大测试人员中推广先不多谈了。

    我看到那个猜数字的例子了,有个电视节目猜价格很像。

    OK!随着时间慢慢再学习中。。。

    以上更多是出于有始有终。说的比较乱!

    最后,真心感谢下郜老师解惑和这篇文章,收获很多。

    PS:也许过了一年后,再回头读读,会不会产生此刻my 知之甚少。


    • 邰晓梅说:

      ET和ST是相辅相成的!
      在。。。场景下,ET比ST更有效,在。。。场景下,ST比ET更有效。
      多多去领悟。。。的含义吧。
      感觉你这篇博文的关注!


  8. thomas说:

    晓梅姐的描述的状况确实深有同感,但没有像晓梅姐那样抽象出来,谢谢这篇文章!

    我现在也逐渐养成一个习惯,当很兴奋或很充满激情的完成一个创意或者工作任务的时候,都强迫自己不要立刻把成果发出去,要等一天之后,自己再Review一遍,然后再发。

    这篇文章,也让我对ET测试也有了了解,我已经把这篇文章转给公司内从事测试过程改善的同事了…


  9. tiger说:

    再指点你一招吧。
    测试是一个三维的,不但有深度/广度,还有测试的重度。就是每一个测试点的权重。每个人的理解会不一样,在不同的测试阶段也会不一样。有时候是最容易出问题的地方,重度最高,有时候是用户最常使用的地方,重度最高。测试之前,想清楚你的测试广度,以及每个功能点的重度再去测试。
    PS,你在方法论里面陷得太深。


    • 邰晓梅说:

      多谢指点。我还是第一次听到“重度”的概念。不知你所说的重度是否指的是“基于风险的测试(RBT)”。因为RBT的运用在测试中无处不在,当我更关注人的测试思维时,并没有把Risk的因素也考虑进来。或者说,当你找到了一个测试点(比如ET中的charter确定后,当然这个测试点可大可小),已经大体判断了它的风险信息,去开始测试时,就可以围绕这个点用测试深度图去分析你的测试过程了,在这个过程中,你随时都会运用某个更具体的点的风险因素去解释你的测试行为(Reframe your testing),至于是否要把它也画到图中变成3维的形式,根据你的需要吧,我这里只是提出了一种方法而已。


      • tiger说:

        重度,通俗点讲就是Testcase的优先级。这个讲的话,讲太多了。通常的测试的话,我们测试用例的优先级可能是事先就定好的,这时候重度由什么决定呢?需求,key value。而在ET的时候,重度是随时变化的。(其实通常测试的时候,根据产品的不同阶段,也是需要变化的)举个例子,插入页码的Alpha版的ET测试顺序,一定和Fix了某个Bug之后的ET测试顺序不同。为什么?测试重度导致了你测试先后的改变,也会改变你在某个功能点上的测试深度。其中还涉及到测试成本等诸多考虑因素,比如我有十个测试点。A:5,B:5,C:3,D:2,E~J:1(冒号后为测试重度),一个人在一个小时内测试了A/B/C三个点,而另一位测试了D~J,你认为谁的测试更好呢?内容太多,不展开了。
        走了,还是我那句话,你在方法论里陷太深。方法是为解决问题而服务,单纯的方法研究没有任何意义。而且,方法论需要强大的IQ支持,不是每个人都合适的。如有冒犯,见谅。


        • 邰晓梅说:

          没想到竟然给人以“单纯的方法研究”的印象了,呵呵

Comment Box is loading comments...