探索式测试的相关问题的个人理解

简介:

首先需要声明的是,目前我对探索式测试理论和实践的理解还停留在1到2年前的水平,很多内容都在《探索式测试实践之路》可以了解到的,但是需要告诉大家的是,虽然国内对ET的理论和实践进步不大,但是国外一些测试大师对ET的理论和实践都有很大的提高,包括工具、流程和总体解决方案。由于最近两年的主要精力不在这个上面,所以对国外这两年ET的发展了解不多,如果有说的不对的地方,欢迎指出来,也让我多学习和了解下。

     虽然很多人都看了《探索式测试实践之路》这本书,但是并不是所有人都能理解这里面的来龙去脉,我也在很多场合说明了自己的看法,但是还是会存在一些误读,加上崔老师提的关于ET的4个问题,我觉得非常好,很多看过拿本书的人都会或多或少有自己的看法,我趁这个机会,说下自己的看法,不一定正确。

(1)如何选择探索的深度?

   大家都应该知道,探索式测试的探索的涵义吧,基本上就是根据自己所得到的信息去挖掘更多的新的信息,从而判断系统出来是否正确和合理。但是时间是有限,我们到底要挖潜到什么时候呢?我们做测试也是一样的道理,测试不可能很全面,什么都想测试到,代码覆盖率100%等。但是我们应该要测试到什么程度呢,有哪些判断依据呢,很多时候就是平衡,我们需要抓住一些平衡,在一定的context范围内。

    我个人是这样理解的,首先我们必须非常清楚我们的任务具体是什么,了解我们现在做的charter和session到底是什么。然后,大家都知道session有自己的一些特点吧,很关键的一个就是 timebox,就是区间,在有限的时间区间内对被测系统就行测试设计和执行层面的探索,当然,这时候又涉及到之前划分session的原则和合理性,这个不在这里细说。

a. 在timebox内,测试人员对具体的任务进行探索,只要思维不枯竭,应该不存在是否需要继续探索的疑问。但如果不知道要测试什么了,该怎么办呢?首先:静下来,梳理之前得到的信息,整合系统处理逻辑和所有异常流程,再次check是否覆盖到所有的测试点;第二,使用通用的测试tips提醒,check自己是否考虑到类似的测试场景,比如session tester工具就有这样的tips;第三,正对被测模块的分析,check相应的探索式测试方法,进行场景方法层面的思维提醒;最后,和相关人进行交流和沟通,在交流的过程中,会得到别人的启发,从而看是否存在遗漏的测试场景。一旦存在,立即执行。

b. 假设在测试人员挖掘的信息比较多,测试的非常high,时间过得也快,也发现了一些问题,从而无形中增加提交bug的时间,减少了真正测试的时间,这个时候,测试人员该怎么办呢。我个人的看法是,首先减少提交bug的时间,采用关键字加截图的方式,快速记录bug;第二,测试人员会使用工具来进行时间提醒,原来确定的时间到了后,测试人员应该停下来,仔细思考我挖掘的是否足够,check前几次异常测试场景是否发现bug,思考开发实现代码逻辑和被测模块的整体质量,综合判断是否需要继续探索更新的信息和测试执行; 第三,如果确定了继续探索,需要考虑是否调配其他的session的测试时间,或者是否加班完成它;第四,如果能判断覆盖80%以上的代码覆盖率,且认可开发的质量,建议测试人员plugin out,去测试其他计划内的session。最后,对于整合信息并作出分析和判断,这个过程需要非常快速和高效的,这个可能就是一些经验的积累,建议大家多去尝试,然后看看结果,给自己增加信心或者教训。

(2)如何衡量探索式测试的有效性?

    这个问题其实有点大,个人觉得这个和你实践ET的方式有关,目前来说,大部分人认为ET就是ST的补充,但是补充的效果到底怎么样呢,很多人可能都没有去实践和分析具体的细节。

     对于如何衡量ET的效率,我前几年一直在思考这个问题,但是我真的没有得出很好的答案,我目前的看法是这样的:客观数据 + 主观感受。 客观数据,主要包括发现Bug的数量和认可的测试思路。主观感受就是个人在ET执行或设计过程中,对于SUT的探索的过程中的主观感受,是否真正扩展了你的思维,让你思考更多你之前没有思考过的角度。这里说到的bug数量不一定能说服人,因为你不可能一个人针对同一个项目使用ET 或 ST来进行测试,从而比较两个结果,这个只能是单维度的,是 谁用谁知道啊。说ET能提高效率,我采用的是单位时间内发现bug率,大家是否还记得我之前的很多分享都会说这些数据。FreeStyle ET的方式是2.45bug/hour、ET主导&ST辅助的方式是1.5bug/hour、ST主导&ET辅助的方式是1.0bug/hour、普通ST方式是0.46bug/hour。数据仅供参考。

     我之前也说过,如果仅仅把ET当做ST的补充,实践的策略不好的话,会造成一个问题,那就是ET的很多测试执行思路和之前ST做过的很多是重复的,这样不利于ET的发挥,同时在成本上是划不来的。我们这边是允许重复的,不可能做到完完全全的不重复,怎么减少这个重复度,是我们大家需要思考的一个问题,我的看法是,首先从意识上就要区别我们做的ET和ST是不一样的,测试思路和方法策略都不一样,但是结果(测试思路列表)可能会存在重复的,但不影响我们的思考的重点是什么,我们会分析和收集ET和ST在测试思维上的区别和测试集合,这些也许会帮助你找到ET设计和执行的重点;最后,多去分析传统测试设计方法和ET测试方法的区别和背景,了解到深层次的使用方法,做一些基础的积累,这个也会帮助大家减少这个重复度。

(3)如何避免与标准的测试流程冲突?

    这个问题就是标准的流程问题了,对于ET在项目中如何实践,如何和标准的ST流程融合,书中都有非常详细的流程说明和注意点。这里个人就说几个看法,敢于去尝试新的想法和东西,有时候不是坏事,也许就可能看到不一样的天空呢,再有,我们可以选择一些不太重要的项目进行实践,减低风险。

    这里我需要强调的是,无论你使用什么方式去实践ET,流程中的一些细节需要做到位,比如交叉测试的测试思路和方法,需要充分考虑自己的测试思维以及测试tips的作用。主要流程也许不会有大的区别,都需要做测试设计和测试执行,但是如何去做,会有一些细节的差别,请把这些细节做到位,再说实践后的效果,否则,很容易做到表面,没做到本质。

(4)如何避免只有测试精英才能执行探索式测试?

    这个问题,其实是那本书里面,史亮也说了自己的看法,建议大家再看一遍。ET执行,一方面是需要参考ET设计时的测试思路,另一方面就是现场发挥,也就是执行现场整合信息来创建更新的测试场景。

     其实我个人不太同意只有测试精英才能执行探索式测试,怎么去做探索式测试,这边会有一些基础流程和规则,不管你是精英还是菜鸟,只要掌握这些方法和策略,给一个产品的测试任务,大体上能有80%的重复程度。这里面简单说下这些基础规则包含的内容:

a. ET的基础测试方法以及应用

b. 执行现场测试的敏锐性

c. 现场整合信息的能力

d. 分析产品和评估风险的能力

另外需要说明的是,ET没有最佳实践,ET做的好与不好,不仅仅看测试工程师是否是精英,而要看很多相关的其他因素,这些情况都会或多或少影响着ET实践的数据产出,下面列出了比较重要的制约因素:

  • 这个项目的测试的具体任务(一般和测试类型和产品本来的特点)
  • 这个测试人员的角色(lead或SDET或STE)
  • 具体的测试人员(技能,天赋,擅长点)
  • 可用的测试工具和测试机器
  • 可用的时间
  • 可用的测试数据和文档
  • 从其他的人员获得的帮助
  • 当前的测试策略
  • 同一个产品已经经过测试后的状态

其实我们可以总结影响ET的基本因素为:时间,测试人员,产品,任务。我们还可以分析下ET过程中的几个关键的因素,其实也就是一个优秀的ET测试人员所具备的基本能力:

测试设计:一个优秀的测试设计师,一般有如下几个能力:首先是分析这个产品;评估产品的所有的风险;使用现有的工具去分析或记录;测试设计技术的熟练使用。

细心观察:一个优秀的ET测试人员必须比一般的人甚至是做ST的测试人员更具有细心观察细节的能力。ET测试人员必须去观察一切看似不正常或有疑问的地方,他还要能仔细的在推论和其他一些的假设中辨别出真理何在。

批判性思考:一个优秀的ET测试人员能够快速的评审和解释他们的思考逻辑,并能在独立思考中需找错误。这在重现bug的时候非常重要。

丰富的想法:一个优秀的ET测试人员能够比一般人产生更多且更好的想法。但通过什么来产生这么多且好的idea呢?这个也是ET的核心了,目前ET的牛人们创立了一个叫Heuristics的方法,这个方法比较抽象且实践过程在国内几乎空白,后续讨论下。

丰富的资源:一个优秀的ET测试人员能够构建一个集测试工具,信息资源,测试数据,同仁的一个储存室。这样在测试的时候,可以很快的应用这些资源 

这些能力的培训和培养,只要方法和策略得当,可以在1-2个月内达到一定的水平,所以这个时候,和所谓的测试精英一起来对某个产品进行ET,不会有大的区别,至少80%以上是没问题的。

转载自:http://blog.sina.com.cn/s/blog_6cf812be0101f0wf.html

作者:JerryGao

目录
相关文章
|
19天前
Capgemini测试
Capgemini测试文档
|
2月前
|
数据挖掘 测试技术 UED
A/B测试
【10月更文挑战第10天】A/B测试
21 2
|
2月前
|
人工智能 Serverless 网络安全
测试
本方案利用阿里云函数计算、文件存储NAS和专有网络VPC,快速部署基于大模型的应用服务。首先,确保拥有阿里云账号并注册ModelScope账号,完成函数计算与NAS服务开通。接着,通过函数计算3.0控制台应用模板,轻松部署魔搭社区的大模型。最后,在环境详情页面访问应用域名,输入文本并提交即可体验。使用完毕后记得清理相关资源。
33 0
|
7月前
|
人工智能 Java 测试技术
耐力测试
耐力测试
|
测试技术 定位技术 开发者
从测试看需求
从测试看需求
117 0
从测试看需求
|
安全 数据挖掘 Java
如何进行有效的探索测试?
如何进行有效的探索测试?
|
NoSQL 测试技术 Redis
|
监控 测试技术
测试-亚英1021
测试-亚英1021
95 0