• 0
  • 0
分享
  • 探索性测试:关于发现的一切
  • 恬恬圈 2019-11-21 11:35:12 字数 3723 阅读 2786 收藏 0

随着技术的进步,每家企业都将其业务从实体办公室转移到网站和Web应用程序,从而实现在线发展。这带来了一系列更新的测试技术,以迎合最终用户的最佳产品或服务。在启动任何软件,网站或应用程序之前,许多测试技术(例如跨浏览器测试,用户验收测试,回归测试)已变得显而易见,为了确保最佳的用户体验和稳定的功能,还需要一种测试技术是探索性测试。

与其他测试技术不同,探索性测试没有测试人员必须遵循的一组固定方法,但是相反,测试人员拥有发现产品/服务随时间推移不断改进的完全自由。这更像是随着时间的推移以及网站或应用程序的开发而进行的持续改进。

让我们更进一步地探究探究性测试到底是什么,它为何如此重要,如何进行探究性测试,执行它所面临的挑战,优缺点和与其他脚本技术不同的原因的细节和临时测试及其未来。

什么是探索性测试?

顾名思义,探索性测试是基于测试者探索网站或应用程序的能力,以使其随着时间的推移而变得更好。这是敏捷软件开发中的一项重要活动,开发和测试周期是紧密结合的。

探索性测试虽然是黑盒测试,但从整体上考虑了该软件,而没有涉及构成该软件的各个元素的细节。这是一种非常自发的测试方法,测试人员以计划外的方式同时学习,理解,探索和测试软件。与通常在实践测试之前对测试计划,测试用例和测试步骤进行脚本化的脚本化测试相反,探索性测试随着测试人员自行发现和了解网站或应用程序而进行。

它强调测试人员的创造力,自主权和技能,这与其他测试方法遵循固定的方法论方法不同。

为什么探索性测试很重要

探索性测试是实践敏捷软件开发方法时的一项重要活动。在敏捷的冲刺中,该软件是在每几周的时间内发布多个版本而开发的。这意味着开发和测试的时间受到限制,并且需要在更短的时间内完成。因此,为了适应敏捷性,探索性测试的进行小迭代,因为它耗时较少,因此可以通过自动化测试来补充每个版本的软件的质量保证。

自动化测试负责回归测试,而探索性测试主要测试即将推出的版本的新功能。它通过不断学习和使用每个版本来确保强大的功能,更好的用户体验,并通知团队有关可能发生的问题。

如何进行探索性测试

探索性测试涉及发现,调查和学习的紧密结合。因为,它不是预先计划的,与脚本化测试不同,在脚本化测试中,在开始测试软件之前会先制定好测试计划,测试用例和测试步骤。

在探索性测试中,少量的时间用于计划。相反,将最大的时间专用于测试执行。要执行探索性测试,您需要做的就是突出显示您计划涵盖的方案,作为测试计划阶段的一部分。

虽然大多数重点放在测试执行上,但是在整个测试过程中同时进行的关键学习将在测试执行期间实施以增强软件。

在探索性测试执行过程中,通过探索和发现软件来确定关键功能,并记录下所报告的缺陷。这些缺陷将得到进一步分析,以解决和增强产品服务。

探索性测试以这种方式进行,用于敏捷软件开发的学习,测试设计,执行和分析。

有哪些不同类型的探索性测试?

基于该方法的探索性测试,以下是不同类型的探索性测试技术:

1.基于场景的探索性测试

基于场景的探索性测试是指用户浏览并测试特定场景或功能时的情况。基于对网站或应用程序的学习和观察及其功能,测试人员可以使用探索性测试技术来探索和发现不同情况下的缺陷。他们倾向于使用基于方案的探索性测试来检查不同的可能性。

2.基于策略的探索性测试

这种类型的探索性测试的方法基于诸如边界值分析,风险评估,等效技术之类的策略。要执行基于策略的探索性测试,测试人员必须熟悉网站或应用程序功能,以便能够高效地进行操作以获得更好的结果。

3.自由式探索性测试

自由式探索性测试主要用于测试人员想要进行快速冒烟测试的情况。顾名思义,它没有任何明确的测试方法,场景或测试范围,相反,测试人员以自由方式进行调查缺陷。为了能够有效地进行自由式探索性测试,测试人员必须熟悉网站或应用程序,才能在没有任何详细计划的情况下轻松掌握缺陷。

这样,作为测试人员,您可以使用不同类型的探索性测试技术来彻底检查网站或应用程序,以确保改进的产品或服务,以便在每个版本中获得更好的最终用户体验。

探索性测试的优缺点

探索性测试已成为一种现成的测试方法。以下是在测试您的应用或网站时使用探索性测试技术的优点:

  • 它不需要大量的测试计划,而这通常是很费时的,这会使整个过程变慢。

  • 它与产品/服务的业务可用性和领域非常一致。

  • 对于短期项目,探索性测试非常有效。

  • 它与敏捷软件开发并驾齐驱。

  • 它经常会包含在使用其他技术进行测试时仍未被发现的错误。

  • 当需求文档不可用时,这将是有益的。

探索性测试技术的最大缺点之一是,它完全依赖于测试人员的技能,因此,如果测试人员的技术水平不高,它就无法产生应有的效果。另一个缺点是由于缺少脚本,通常很难追溯到测试用例并再次进行测试。

是什么让探索性测试变得困难?

尽管探索性测试看似非常容易,但在执行过程中也面临着一系列挑战。这是在探索性测试期间遇到的一些挑战:

  • 由于缺乏文档,经常要追溯缺陷是一项艰巨的任务,尤其是经过一段时间之后。

  • 很多测试执行都取决于测试人员的技能,如果测试人员不那么勤奋,可能很难获得理想的结果。

  • 它可能不适用于时间表较长的大型项目,因为如果没有适当的正式文档,可能很难涵盖所有可能的范围。

  • 它需要具备良好的领域知识和更好的指令,才能深入研究产品并找出错误和缺陷。

  • 以后很难复查测试用例。

通过克服探索性测试期间面临的上述挑战,您可以使用敏捷方法来增强跨版本的产品/服务。

探索性测试的谬论

探索性测试有很多谬论。让我们揭穿与探索性测试有关的一些常见谬论。

1.探索性测试与临时测试相同

探索性测试是一个比较正式的型式试验,同时特设测试进行更上一个随机的一面。临时是基于需求的,而探索性是基于工作流的测试技术。探索性测试和即席测试之间的差异明显。

2.探索性测试无法量化

仅仅因为测试计划没有记录在案,并不意味着探索性测试没有任何文件且无法量化。实际上,它更侧重于测试执行,并且已探究的缺陷已得到充分记录。因此,探索性测试能得到了有效的量化。

3.根本没有计划进行探索性测试

只是在探索性测试中没有为测试计划分配太多时间和重要性,而是同时在探索性测试执行之前计划了场景和策略。由于与其他脚本技术不同,它们的文献记录很多,这根本并不意味着完全没有计划进行探索性测试。

4.探索性测试比脚本化测试花费更多的时间

关于探索性测试的一个普遍误解是,它比脚本化测试更耗时,但是实际上,探索性测试所需的时间更少,因为在探索性测试中节省了测试计划和脚本编写的全部时间。由于其消耗较少的特性,因此在敏捷方法中使用了探索性测试,其中两次敏捷冲刺之间的持续时间缩小为一周甚至更少。

5.探索性测试仅适用于小型团队

通常认为探索性测试仅限于小型团队,但这是一种误解。更大的团队也有效地进行了探索性测试,他们与敏捷软件开发的其他测试方法合作。

6.探索性测试仅适用于敏捷团队

尽管大多数敏捷团队都将探索性测试技术与自动化测试一起使用,但这显然并不意味着探索性测试仅限于敏捷团队。实际上,任何正在寻求快速测试会话,同时探索和了解网站/应用程序的议程的软件开发团队都可以有效地使用探索性测试。由于这个原因,探索性测试通常在初创企业中非常受欢迎。

不要与脚本测试技术相混淆

与传统的脚本测试技术不同,探索性测试是一种非常规的测试技术。尽管使用脚本化测试技术可以从需求文档中预先确定好测试用例,但对于探索性测试,则不遵循这些步骤。

与脚本测试主要依赖于确认的脚本测试不同,探索性测试更多地依赖于测试人员在浏览时调查网站/应用程序。探索性测试为测试人员提供了自由和自主的方式,可以按照自己的方式进行操作,而无需遵循与脚本化测试技术相反的任何脚本。与探索性测试不同,文档化仍然是脚本化测试技术的重点之一。

这种方式的探索性测试是一种免费的,即开即用的测试技术,该技术主要基于发现,并且涉及较少的计划和文档编制,从而减少了耗时,并且不同于脚本化测试技术。

不要与临时测试混淆

尽管由于其自由式测试,探索性测试可能看起来像临时测试,但实际上,探索性测试与临时测试有很大不同。尽管临时测试是完全随机的测试方法,但探索性测试更多地是在正式确定要测试的方案。

临时测试需要初步学习,而探索性测试只涉及浏览网站/应用程序,并与测试同时进行。对于临时测试,需要要求文档,而探索性测试则不需要。与临时测试不同,探索性测试需要工作流来执行测试。通过这种方式,探索性测试与临时测试不同。

探索性测试有未来吗?

脚本化测试方法是进行用户接受度测试的唯一方法的日子已经一去不复返了。随着技术朝着以用户为中心的方向发展,甚至测试技术也必须以相同的方式进行调整,以便能够在每个即将发布的版本中增强用户体验。这种以用户为中心的软件开发和敏捷方法,为探索性测试以及针对软件产品和服务的自动化测试提供了光明的未来。

鉴于发布新版本的时间紧迫,探索性测试将是与自动化测试一起使用的理想解决方案,以确保功能齐全,功能强大稳定且以用户为中心的软件的质量。


版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   常言道,名正则言顺。对于一个概念,如果它没有恰当的名字,就会增加理解的难度,甚至容易引起歧义。  在这些年,不管是写公众号还是与同行交流,我都发现软件测试中的一个重要概念存在着“名不正,言不顺”的问题。这个重要概念就是回归测试。  到底什么是回归测试?为什么叫回归测试?据我观察,许多的答案都不能让人信服。今天,是时候为“回归测试”正个名了。  要理解“回归测试”,先要理解“回归”。回归,是常用的汉语词汇。它有两种含义。第一种是归还,返回的意思。例如:香港回归祖国,北回归线,回归初心等。这种含义大家都非常熟悉。  另外一种含义,熟悉的人就少一些。它来自数学领域,表示研究随机变量相互关系的统计...
            10 10 867
            分享
          • 基于 Spring Boot 构建的 API因为基于 Spring Boot 从 0 到 1 构建一个 API,并不是本文的重点,为了不影响你对文章主要内容的把握,我直接采用了一个预先开发好的 Account API 为例展开讲解。你可以从https://github.com/SpectoLabs/spring-cloud-contract-blog下载完整的代码。这个 Account API 的功能非常简单,就是基于你提供的 ID 值创建一个 Account 对象,并返回这个新创建 Account 对象。比如,如果你的请求是“account/ID008”,那么返回的 response 就应该...
            0 0 1773
            分享
          •   功能测试对于测试人员来说并不陌生,功能测试执行的大体流程是根据需求说明书设计测试用例,测试执行,测试总结。同样性能测试的执行过程也是如此。然而,功能测试与性能测试的区别在于,功能测试是单用户,性能测试是多用户,是从1到N的量变。由于无法通过手工操作模拟多用户并发,因此需要借助工具来实现用户操作被测系统某场景的动作流程,也就是编写测试脚本。那么,如何开展性能测试呢?  1、需求分析  通常开发人员会提供接口文档以及非功能需求文档。标准的接口文档中描述了接口请求地址,请求方式,参数类型以及请求报文和响应报文示例。如果接口文档中描述内容不是很清楚,测试人员可以通过抓包工具比如Fiddler,Ch...
            13 13 1647
            分享
          •   1.Api文档导入  如果你的旧项目数据存储在其他软件上,那么迁移到apifox也很简单,apifox支持多种格式的接口文档的导入。  导入完毕之后,Apifox会将实体类数据自动生成一个数据结构,方便后面复用。  2.后端接口测试  成功导入后的项目API文档如图所示,接口的请求方法,url和参数 会自动填写到界面中,测试人员只需要手动修改相应的参数即可对单个接口进行测试。 对于接口测试常规涉及到的需求 1)校验接口传参是否合理(少传,漏传,多传,边界值测试和空值测试等); 2)response返回值是否符合api文档约定,数据是否存在异常,是否有做容错机制 3)接口的安全性测试等 Ap...
            0 0 1933
            分享
          • 1.安装JMeter的插件管理器下载地址https://jmeter-plugins.org/get/将下载的jar包放入 jmeter的 lib/ext目录中,然后重启jmeter。2.安装Websocket插件点击Options – Plugins Manager在Available Plugins标签下搜索websocket,选中WebSocket Samplers by Peter Doornbosch,然后点击Apply Changes and Restart JMeter按钮。3.添加Threads - Thread Group在Test Plan上点击右键,依次选择Add – T...
            11 12 764
            分享
      • 51testing软件测试圈微信