探索性测试揭秘

最近看了不少有关探索性测试的讨论和观点,老实说越看越糊涂。所以忍不住吐槽一下,在这里和大家讨论一下探索性测试。希望对于想学习和尝试探索性测试的朋友有所帮助澄清,或者是更加糊涂,^_^。

  探索性测试有很多很多的定义:

  百度百科的定义:“同时设计测试和执行测试”。 嗯。。什么意思?

   Cem 老人家的正式定义:“a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project”。啊。。 糊涂了。。。

  有人说:“手工测试就是探索性测试”。  更糊涂了。。。

  又有人说:“探索性测试就是一边探索一边测试”。 彻底糊涂了。。。。

  。。。。。

  那么探索性测试到底是啥玩意啊?

   我们先来看一个例子吧。很多人都玩过猜数字的游戏吧。我心里想一个数字,你来猜。你可以问任何问题,我回答“是”还是“不是”。然后你通过不断问问题和 我的回答来最终猜到我心想的数字。在猜对的情况下问的问题越少得分越高。比如,我心里想了一个数字。你可以问“大于零?”,我说“是”。你现在知道是正数 了,你然后问“小于100?”,我说“是”。你现在知道是小于100的正数,你然后问“小于50?”,我说“不是”。你现在知道是介于50和100间的 数。你继续再问几次后因该就能猜对了。

  在这个简单的游戏中有两个策略至关重要:

  1、你要根据前面问题的答案来分析和设计下一个问题。第一个问题可能不着边,但是第二个问题会让你跟接近你想要的答案。第三个会更加靠近,以此类推。

   2、仅仅根据前面问题的答案来设计下一个问题可以最终帮你猜对数字,但是要想用最少的问题来猜对数字不仅要根据前面问题的答案,而且需要对问题本身其它 知识加以综合运用使用其它策略和技术。比如在知道是小于100的正数后,你可以使用binary search,最多猜6次就可以猜对;如果你不知道binary search,你可以猜是否小??90?小于80?小于70?… 猜上十几次也可以猜对;或者猜是否小于99?小于98?小于97?… 猜上几十次也可以猜对。所以采用不同策略直接决定你猜对的速度。

  所以两个关键因素:前面问题的答案+有效的策略。

   探索性测试和猜数字游戏完全一样。在这里要猜的数字就是你要找的bug。你问的问题就是你做的测试,每个问题的答案就是你测试过程中产品的输出。第一轮 你只有一个非常模糊的范围比如测试某个模块的某个功能。在你测试的时候通过观察产品的反应和输出来判断分析下一步做什么会发现bug。当然实际测试中不会 像猜数字那样直接和简单。

  下面我们来看一下一个真实的测试例子。有一次我在测试一个用户界面的录入页面。用户可以输入比如姓名,年龄,等等很多信息,最后系统根据输入的内容处理保存到数据库中。 当然我对每一个输入框都会尝试不同的数据比如空值,很长的字符串,空格等等,系统都没有问题。但是我注意到每次保存的时候系统都会生成一个本地文件,该文 件的名字是其中一个输入框的我的输入。该输入框的唯一限制就是不可以为空不可以超过255个字符。我想到文件名字中不可以有斜杠“\”,于是我就在该输入 框中如入“ab\cd”,它通过了输入校验,但是保存的时候系统就崩溃了。这就是探索性测试一个非常典型的例子,通过观察分析上一次测试的产品反应和输出 来判断系统会有问题的地方,然后设计调整步骤和测试数据反复尝试直到完全验证模块没有问题或找到bug.

  探索性测试和手工测试的区别: 手工测试通常是指完全按照预先设计好的步骤一步一步人工测试直到验证了所要验证的功能。如果结果和预期结果一致,则验证通过;如果不一致,则是bug.可 以看出手工测试过程单调没有思考没有变通。在上面的猜数字的游戏中你明明已经知道是正数,你还在按照游戏开始前设计的步骤问大于-100? 大于-90?。。。。当然现实生活中 没有这样的傻子,在你“手工”测试的时候你或多或少已经使用“探索性”了,只不过你没有意识到罢了。所以很多人误认为探索性测试是个时髦新测试技术,研究 了半天又不知道到底新在那里和自己一致做的有什么不同。或者恍然大悟原来自己已经探索了很多年了。但是探索性测试有效率高和效率低之分,所以有人干脆就把 效率高ET的才叫ET, 效率低的ET叫手工测试。这也是让人糊涂的原因之一吧。

  测试自动化就是把手工测试的每个步骤有测试自动化工具来完成。好处是不用人做了,缺点是测试过程中仍然没有思考没有变通。

  Ad-hoc测试(随机测试):没有预先设计好的步骤,也没有明确目标,也没有策略。在上面猜数字的游戏中你明明知道是正数,你还在东一榔头,西一棒槌的乱猜等于100?等于-100?等于0?。。。当然也有可能被你一不小心蒙对了。

  探索性测试和测试自动化各有各的优缺点。至于什么时候开始测试自动化,什么时候开始ET,先测试自动化后ET,还是先ET后测试自动化需要看项目产品具体情况了。没有绝对对错,以尽早发现bug,发现更多的的bug为宗旨。另外既然ET和测试自动化的各自优缺点,微软有 些组最近两年在尝试“探索性测试自动化”的方式来把探索性测试和测试自动化相结合,充分发挥各自的优点。看到这里你可能要恨我了,我刚学会测试自动化,你 又提倡ET了;我刚搞清楚ET,你又开始提倡探索性测试自动化了。。。 呵呵,人类发展过程就是通过社会分工,扬长避短。专注于做自己擅长的事情,把自己不擅长做的事情交给擅长的人去做。社会发展是如此,云计算是 如此,测试也是如此。有人说过:“The computer is incredibly fast, accurate, and stupid (test automation). Man is unbelievably slow, inaccurate, and brilliant (exploratory test). The marriage of the two is a force  beyond calculation。”

  其实我们可以看到探索性测试入门容易或者你已经在做了多年了,难得是有效地探索性测试,或者做效率高的 ET(否则被别人不屑为手工测试了J)。那么如何根据前面的测试结果来分析和思考,如何才能敏锐地嗅觉到通向bug的种种线索?当然有多种方式来训练自己 这方面的能力。还有如何衡量考核ET的效率,投入和产出比率?欲知详情,请听下回分解。。。。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/ 

时间: 2024-09-19 11:57:06

探索性测试揭秘的相关文章

探索性测试(四):探索性测试并不是快速测试

快速测试也是一种测试的方法,它既可以照本宣科的进行,亦可以探索的方式进行.尽管一个使用高度探索性方法进行测试的测试员可能会执行很多快速测试,而快速测试也通常是运用探索性测试方法时的重要因素.但是,快速测试和探索性测试并不是一样的. 快速测试是需要少量时间或一点精力去准备和执行的廉价测试.这类测试甚至不需要具备与待测试的应用程序相关的大量知识或相关的业务领域知识,但它们有助于快速地获取新的信息.快速测试不是强调广泛和完整,它的目的是用最低的成本快速揭示信息. 快速测试是了解产品.识别区域风险及薄弱

《移动App测试的22条军规》——第23章,第19节对微信App进行自动化测试和探索性测试

23.19 对微信App进行自动化测试和探索性测试 我们在对微信App进行测试时,必然会进行自动化和探索性测试. (1)在编写微信App的自动化测试时,我们还是选用Appium来帮助我们录制对应的脚本:而基于测试金字塔的测试架构设计,我们对于Appium的自动化测试,选择编写"用户登录微信后,在通讯录中添加招商银行公众号"这个用户旅程(如图23.45-图23.55所示). 打开微信App的主界面(如图23.45所示). 打开"Contacts"(通讯录)页面(如图2

自动化测试(AT)与探索性测试(ET)

软件自动化测试 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程.通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较.在此过程中,为了节省人力.时间或硬件资源,提高测试效率,便引入了自动化测试的概念. 前提条件 实施自动化测试之前需要对软件开发过程进行分析,以观察其是否适合使用自动化测试.通常需要同时满足以下条件: 1)软件需求变动不频繁 测试脚本的稳定性决定了自动化测试的维护成本.如果软件需求变动过于频繁,测试人员需要

寻找用户轨迹的“探索性测试”

国内的大部分公司在做交互设计的时候很大部分都是处于探索阶段,但是因为产品的商业价值很难允许失败,所以很多设计师对于交互设计的结果都很难确定,甚至会因此屈服于商业价值,从而导致了一个恶心循环. 在上次的D4设计论坛中,针对于口碑网改版的设计方法,UT斯达康的设计经理提到了利用新旧入口的方式来进行用户测试,并提出了使用新界面提供老界面入口的方式进行用户测试.在我们设计产品的时候其实也可以利用产品的特性进行一些"探索性测试". 测试大致可以分成几种:一种是验证性的测试,在知道结果的前提下进行

易用性测试和探索性测试

近些年来,随着敏捷开发方法和互联网企业的发展,易用性测试和探索性测试被越来越受到关注. 客户也经常提这样的概念或者尝试实践.有些客户可能只做易用性测试,有些客户则关注探索性测试.还很少看到两者都做得.这里简单诠释下两者的相同和不同,如果有不同意的地方,敬请指正. 相同点 1. 易用性测试和探索性测试都是面向业务的测试.所谓面向业务的测试是区别于面向技术的测试,它更多关注用户感受,逻辑是否合理,流程是否正确,功能是否有遗漏等. 2. 两者属于手工测试范畴.虽然有时候用户也可以用工具辅助做探索性,但

探索性测试的18个总结

1)探索性测试与脚本化测试的主要区别:1)探索性测试将更多更高的认知水平的工作放在测试执行,而脚本化测试则更关注测试设计:2)前者更强调测试活动的并行和相互反馈(学习.设计.执行与结果分析等),而后者的测试活动是相对串行的. 2)脚本化测试的主要优点是:1)尽早发现缺陷:2)不同利益相关者参与评审:3)可重用性:4)测试覆盖率评估. 3)脚本化测试强调测试的尽早介入,如尽早设计测试用例.但是测试人员越早设计测试用例,对测试对象的了解越少,对风险的了解也越少.测试人员对测试对象的了解是一个逐步的过

《移动App测试的22条军规》—App测试综合案例分析23.19节对微信App进行自动化测试和探索性测试

23.19 对微信App进行自动化测试和探索性测试我们在对微信App进行测试时,必然会进行自动化和探索性测试. (1)在编写微信App的自动化测试时,我们还是选用Appium来帮助我们录制对应的脚本:而基于测试金字塔的测试架构设计,我们对于Appium的自动化测试,选择编写"用户登录微信后,在通讯录中添加招商银行公众号"这个用户旅程(如图23.45-图23.55所示). 打开微信App的主界面(如图23.45所示).打开"Contacts"(通讯录)页面(如图23.

基于会话的探索性测试管理

探索性测试是一个特殊的测试过程,它的测试活动和测试内容是动态变化的,更多的是通过测试执行的结果来指导后续的测试活动,花在文档上的时间很少,这也就意味着探索性测试的可管理性不强,对于每个测试人员执行的测试活动的进度和效果很难监控.为了更好地开展探索性测试,Jonathan Bach提出了一种"基于会话的测试管理(Session-basedtest management,缩写为SBTM)"方法,这种方法可以对探索性测试进行更好地管理,把探索性测试的优势更好地发挥出来. 基于会话的测试管理是

初探团队基于session的探索性测试

如果你是一名测试人员,那么不管你对探索性测试的了解是多是少,我肯定你一定用过探索性测试的方法.想想看,你是否曾经这样测试过?不仅仅按照测试案例或者脚本上写什么,就完全使用那一套相同的数据.一模一样的流程,而是根据你执行时的所见,临时有所想和所动,进行一定程度的自由发挥?我想你肯定有过,这就是探索性测试,它将你的测试与纯基于脚本的测试(script. based testing)区分开来.而这种自由发挥,因为是有大致方向和范围的,所以也与完全盲目乱点的猴子测试(monkey testing)不同.