生命有限,测试无限!

关于探索性测试

上一篇 / 下一篇  2007-12-12 16:06:09 / 个人分类:工作

前几天与同事在MSN上聊天时,不知不觉地就聊到了关于探索性测试,这个名词我不熟悉,只能现从网络上google一下啦(有网络就是好,但老是中毒就不好啦),具体解释如下:

摘抄51testing:

探索性软件测试是一种强大和有趣的测试方法。在某些情况下,它比剧本化的测试更高效。其实,每个测试员都在不知不觉地在用到探索性测试方法,但是很少有人学习和重视这种方法。现在是时候认识一下探索性测试方法了:科学的实时的思考。

 
ConcurrentTestDesign and Execution
同时设计测试和执行测试
        对探索性测试的最直白的定义是:同时设计测试和执行测试。这与剧本化的测试方法相反(预先定义好测试步骤)。探索性测试不像剧本化的测试,不会预先定义,不会严格按照计划开展。然而,即使是精确定义的测试步骤也会有很多有趣的细节遗留给测试员(例如:在键盘上敲击的速度、怎样的行为才认为是错误);即使是方式非常自由的探索性测试也会对测试产品的哪些部分作出规定,或规定采用什么测试策略。
 
        好的探索性测试者会把测试的想法写下来,并应用在后来的测试循环中。这些记录下来的东西看起来有点像测试脚本。
 
        探索性测试有时候会与即兴测试(ad hoc testing)混淆。即兴测试通常是指临时准备的、即席的bug搜索的测试过程。从定义可以看出,谁都可以做即兴测试。由Cem Kaner提出的探索性测试,相比即兴测试是一种精致的、有思想的过程。
 
Balancing Exploratory Testing With scrīpted Testing
平衡探索性测试与剧本化测试
        如果做到了下一项测试被我们所做的上一测试的结果所影响,那么我们就是在做探索性测试。当我们在测试循环之前不知道应该运行什么测试时,或者我们还没机会创建测试,我们应该更多地探索。
 
        如果我们正在执行剧本化的测试的时候,新的信息提示我们可以有更好的测试策略,我们应该转成探索模式(例如发现了新的错误需要进行调查)。
 
        相反地,当我们非常清楚我们要做什么测试以及怎样做时,我们应该采取剧本化的测试方法。新的测试相对没那么重要,执行测试的效率和可靠性的需要使得测试值得剧本化,值得我们把它们文档化并维护。
 
        探索性的测试结果与剧本化的测试并没有根本性的区别,两种测试方式是完全兼容的。像Nortel和微软这样的公司通常在项目中两种方法都使用。
 
Why Do Exploratory Testing?
为什么要做探索性测试?
        在有效的探索性测试循环管理中的重复主题是:测试、测试策略、测试报告和测试任务。测试剧本化的方式企图将测试过程机械化,从测试设计者的脑袋中把测试的思想抽取出来并放到纸面上。这种测试方法的好处很多。
 
        但是探索性测试者持这样的观点:把测试剧本化地写下来并按照它们来测试会破坏快速寻找重要问题这一智力的过程。这一智力的过程越丰富、越流畅,我们越有机会在正确的时间执行正确的测试。这就是探索性测试的威力所在:测试过程的丰富性只是受限于我们的思维的广度和深度,还有我们对测试产品的洞察能力。
 
        剧本化的测试是有它存在的意义的,我可以想象测试的效率和可重复性是那么的重要,所以我们应该剧本化或自动化测试。在测试环境间歇有效的情况下,例如C/S结构的项目,只有几个配置的服务器有效并且要在测试和开发之间共享。这种情形下我们应该把测试小心仔细地提前剧本化,以便能充分利用有限的测试执行时间。
 
        探索性测试在复杂的测试情况下会特别有用,对产品了解甚少的情况下会特别有用,或者作为准备剧本化测试的一部分测试。基本规则是:应该在你准备进行的下一次测试内容并不明确的情况下进行探索性测试,或者你希望把这些不明确的因素明确了。
 
    看了以上的解释,我能理解的就是一句话:先使用,再边测试边写用例
    我并不知道这样是不是最好的方案,但在实际工作中,我却是主要使用的方法,但我对这种方法也是一种无奈的选择,知道从软件工程上来说,应该先有设计才能去实施,但理论永远是赶不上实际的变化,理论永远只是理论,在考试中也许很有用处,但实际工作中还是得找出真正适合于自己的方法。
    其实对于测试去搞什么探索性方法论,个人认为不如好好去想想如果保证项目的过程,这样来得更有价值,测试中是项目过程中的一个部分,无论测试专业人员去发现如何如何多的可以提高测试的方法,但如果这个项目的赛程本来就有很大的漏洞,那测试再好出来的东西也没有价值,就是所谓的“皮之不存,毛之焉覆”。
    不过话说回来,对于测试人员来说,考虑到这一点是应该的,但是为什么不能再把要考虑的东西提高一点呢!项目过程可能都只认为是那几个部分,无非是需求,设计,开发,测试,运行!虽然现在有很多项目过程都把测试提前了,保证尽早尽快的测试,但在实际中真正实施的却不多,原因也许都很心知肚明的,需求的不断变化,客户的要求不明确等等,难道这是无法解决的癌症吗?我想应该不是吧?我不知道。
    写到这里,我也不太明白自己到底要干什么了,一方面我在实施着探索性测试,另一方面我的心里却很排斥这种方法,真不懂自己要的是什么,但是我有一点很清楚,那就是测试只能是对项目过程中的一个环节,项目做得好不好,得要靠过程中所有环节的共同进步。

TAG: 工作

老鼠不偷米的测试空间 引用 删除 m2b2x   /   2008-12-30 20:05:22
这么看来,我做的好像也是探索性测试了,因为我们根本就没有专门的人设计测试用例,就是自己看着需求直接编测试脚本,先有个大概思路试一遍,没问题就补充完善,有问题就集中解决问题
 

评分:0

我来说两句

Open Toolbar