从一个测试实验想到的-Utilize the information after each test run

我为了研究测试思维,曾经就同一个被测对象和不同的人结对分别做测试执行(我们做的是探索性测试,实际上还不能称为结对测试,因为只是别人在测试的同时,我在一旁观察),慢慢地,发现一些很有趣的现象。

尽管我自己也事先测试了一回,发现了一些bug,对被测对象有了一些了解,不过,我发现,每次我和一个新的人员结对测试时,总是能带给我一些关于被测对象质量的新的信息:比如又发现了一个新的功能,或者又发现了一个新的缺陷。久而久之,每当要开展一次新的结对测试时,我就充满了期待:“这次又能发现什么新的我不知道的信息呢?” 我不知道这种状况会持续多久,至少目前为止,对同一个被测对象测试了7、8轮了,仍然不断地有惊喜冒出来,我还没有碰到过一次“测试执行结束了,没有任何新的有价值的信息涌现出来”的情形。

我想,在实际项目中,很少有团队会对同一个特性连续测试7、8轮吧,也就是说,在实际项目中,我们几乎可以确信,每一轮测试执行都会带来一些新的、有价值的、关于产品质量的信息出来

假设,我上述的这些实验不是采用的探索性测试方法(ET),而是采用脚本化测试方法(ST),事先编写好测试用例,然后依次让7、8个人依据测试用例开展测试,每一轮测试结束后,是否也会带来额外的新的信息呢?我不得而知。不过,我想,当你希望通过测试执行收获更多的新的你所不知道的信息时,ET显然比ST更具有优越性

当然,每一次测试执行带给我的信息,他们的“质量”还是有所不同的。有的信息很重要,比如我知道了“原来用户正常情况下使用这个被测对象还有可能导致程序崩溃掉”,而有的信息就不那么重要,比如“在使用这个特性的某个功能时,界面显示的格式有可能不正确”。假如我是测试经理,拿到这些信息,就会作出相应的测试策略的调整 -基于风险的测试,不同的信息对后续测试策略的影响程度是不同的。不过,反观实际项目中的测试情况,很多并不是这样。在采用某个正规的项目开发流程时,比如PRINCE2或者CMMI,管理者们一般习惯于在项目的阶段点上(GATE点或者TR评审点)考虑这些质量相关的风险,制定或调整下一个阶段点的测试策略。而在两个阶段点之间,可能有多轮测试执行发生,每一轮测试结束后,管理者们会看看发现了哪些bug,是否有根据这些bug(客观的质量信息)和测试员的感受(主观的质量信息)及时调整下一轮的测试策略呢?是调整测试用例的优先级,调整测试用例执行顺序的优先级?还是,缺陷回归测试完,继续按照原有的计划开展用例的测试,只关注什么时候已经设计的用例可以被执行完?是的,发现的这些bug会被修复、重新测试,但是这些bug带给我们的信息可远不止这些bug本身。应该及时利用bug(客观的质量信息)和测试员的感受(主观的质量信息)这些信息,这些是产品质量相关的风险,是我们开展基于风险测试的很重要的基础

一般而言,比较有经验的人员善于发现一些重要的信息。同样是开展一轮测试的时间,我是安排一个有经验的人去测试,还是安排一个测试新手去测试呢?何时安排什么样的人员?这取决于我的目的以及项目的进展。假如当前已经测试了几轮,我希望再获得一些关于被测对象更多的质量的信息 ,这时安排一个有经验的人比较合适。因为,缺乏经验的测试人员很可能提供的都是你所知道的信息。所以,为了发现更多有价值的信息,后期不易采用测试新手。假如你想对一个测试新手进行辅导,提升其测试技能,那么比较好的方式是,先通过自己测试或者通过让有经验的人测试获得一些信息后,带着这些信息,去观察这个测试新手的测试,看他/她能否发现你已经知道的这些信息、能发现多少你所不知道的信息,通过对比的方式,很容易发现他/她的测试优缺点。所以,为了培养新人的目的,前期不易采用测试新手

有些人发现的bug影响很严重,比如程序的崩溃,但是他是在一系列非常复杂的操作后才触发的。如果我的程序在测试几轮后就要交付用户使用,我是不建议优先安排这类异常的测试的 - 因为缺陷发生的可能性很小。而对那些用户经常使用的功能和操作,就要优先安排测试、优先探索,尽管缺陷影响不是那么大。所以,考虑测试的优先级时,包括探索性测试的优先级,当你用高、中、低来衡量一个风险的可能性和影响程度时,“可能性为H×影响程度为L”的风险要比“可能性为L×影响程度为H”的风险高些

如果说你是通过测试早期的活动比如review、test design获得一些风险的认识,基于这些风险设计用例,制定测试计划;那么,测试执行开始后,你获得的风险更加真实,要及时地利用这些风险信息,调整你的测试策略-Utilize the information after each test run!



从一个测试实验想到的-Utilize the information after each test run》有 2 条评论

  1. Alex说:

    学习了!

    有没有可能测试人员出现这样一个分化,一部分人专注于“需求分析,测试用例设计,脚本化测试”,另一部分人专注于“用户行为,系统设计和实现,探索性测试”。而测试经理或者架构师需要协调两部分的资源,从而获得最大化的输出。

    从我自己的感受来讲,需求一般只是从业务角度罗列出期望的功能,所以需要测试人员对需求进行分析。脚本化测试在保证满足需求这一点上具有天然的优势。通过需求分析,测试用例设计和测试执行,我们能很好的将需求和被测系统联系起来。当然,测试团队一定要有独立的需求分析和用例设计,才能有效地规避不满足需求的风险,毕竟开发和测试在对于需求的理解上都是有各自的局限性的。另一方面,作为测试人员,在测试过程中除了需要保证系统是满足需求的之外,很重要的一点是去发现系统在设计和实现上的错误和缺陷,这个时候,我们需要从终端用户的角度,真实的模拟用户的行为,同时深入的了解设计和实现的细节,才能更有效地发现设计和实现的错误。


    • 邰晓梅说:

      “一部分人专注于脚本化测试,一部分人专注于探索性测试”,这是一种实施方法;原则是ST和ET能相辅相成即可。

Comment Box is loading comments...