什么是探索性测试?(技巧、例子)
正如标题所暗示的,探索性测试是关于观察和了解程序,它做什么,不做什么,什么有效,什么无效。测试人员总是决定接下来要检查什么以及将他或她的(有限)时间投入到哪里。当没有或几乎没有要求并且速度至关重要时,此方法特别有用。
探索性测试可以与其他方法一起使用。
什么是探索性测试?
探索性测试是一种实用的方法,在这种方法中,测试人员尽可能少地进行准备并尽可能多地执行测试。
测试计划过程从制定测试章程开始,该章程是对简短(1 到 2 小时)时间盒测试尝试范围的简要说明,以及要采用的目标和潜在方法。
通常,测试设计和执行操作是同时进行的,没有测试条件、测试用例或测试脚本的文档。这并不排除使用其他更正式的测试程序。例如,测试人员可能会选择进行边界值评估,但只会考虑和测试最关键的边界值而不将其写下来。在探索性测试期间,将记下某些笔记以供稍后编写评论。
执行测试时,会执行测试日志记录,记录已检查内容的重要部分、发现的任何缺陷以及有关可能的未来测试的任何建议。
它还可用于补充其他更正式的测试,从而增加对程序的信任。在这种方法中,探索性测试可以通过帮助发现最关键的问题来检查正式测试过程。
[Kaner, 2002] 和 [Copeland, 2003] 讨论了探索性测试。[Whittaker, 2002] 描述了更具探索性的测试方法(“攻击”)。
何时使用探索性测试?
在 SDLC 的早期阶段(软件开发生命周期),当程序经常修改时,探索性测试可能非常有用。
开发人员可以使用这种方法来运行单元测试,而测试人员可以使用它来熟悉应用程序。
探索性测试专业知识可能有助于编写测试脚本并在软件开发生命周期的后期进行更多测试。
在敏捷开发环境中,Scrum 周期很短,构建严格的测试设计和脚本存在设计时间限制。探索性测试是敏捷环境的理想选择,因为它能够跟上短冲刺周期的步伐。
在进行探索性测试时,测试设计是即时创建的,为测试人员节省了大量时间。可以在每个 Scrum 周期结束时为未来的 Scrum 收集关键的探索性测试。
测试方法 - 如何进行探索性测试?
要进行测试,请利用测试人员自行调整事物的能力。
测试用例的规划和实施是同时进行的。
由于测试人员的发现,测试用例的数量继续增加。
测试人员将他们学到的知识应用到考试中。
等价划分、错误猜测、决策表测试、边界值分析和其他测试方法可能与探索性测试相结合。
测试人员可以在保持专注于他们的任务的同时将他们的想法付诸实践。
探索性测试不采用测试自动化,而是依赖于测试人员的专业知识、洞察力和技能。
探索性测试可以基于会话以保持注意力并提供结构。
探索性测试的优势
只需要最少的准备,并且可以快速发现关键错误。
它被敦促批判性地思考并迅速做出反应,并且发现了更多的缺陷。
对于测试人员来说,更强调扩展他们的专业知识和理解。
它可用于检查另一个测试仪的性能。
探索性测试可以检测在测试用例中可能未被发现的缺陷。
当时间紧迫时,探索性测试可用于评估创新功能,而回归测试可用于评估现有功能。
探索性测试的缺点
由于测试是随机创建和进行的,因此无法事先检查它们,并且可能很难确定必须进行哪些测试。
测试依赖于测试人员的专业知识、才能和经验。
熟悉应用程序需要一些时间,因此如果测试人员不熟悉网站或程序,则可能会忽略问题。
探索性测试示例
假设有人在没有映射的情况下驾驶车辆前往新区域的某个位置。驾驶汽车的人将采用各种标准策略到达那里,包括 -
获取周边地区的映射
沿随机方向行驶以找到位置
联系好友并询问方向
前往邻近的加油站问路
类似的概念可以应用于探索性测试。
想象一下,您的任务是对医院管理系统进行探索性测试。
探索性测试有多种方法。
猜测
猜测用于识别软件中更可能包含错误的区域。之前在类似产品/软件/技术方面的工作经验有助于猜测。
在医院管理系统的例子中,你可以预期支付组件有更多的故障,因为它必须连接支付网关;如果管理不当,事务可能会超时并导致问题。
架构图和用例
架构图描绘了各种组件和模块之间存在的连接和链接。用例从消费者的角度提供有关产品功能的知识。
这些图纸和用例可用于探索方法来测试产品。
医院管理系统 - 您回忆一个用例,其中许多人可能使用相同的号码,并且应用程序必须允许它;您决定测试该场景。
您还可以从架构图中回忆起报告功能是从主应用程序单独部署的,生成并通过电子邮件发送给用户需要几分钟的时间,因此您决定对其进行测试以确保生成报告并电子邮件功能配置正确。
过去的缺陷
检查过去版本中遇到的问题有助于确定程序的哪些方面可能有最多的错误。
以前医院管理系统的上报模块,吃过很多RAM,出现各种错误,所以你也决定测试一下。
错误处理
错误处理是在系统发生故障时启动必要措施的代码部分。为了验证友好的错误处理,可以利用各种场景执行探索性测试。
医院管理系统中的报表模块会占用大量内存,偶尔会崩溃。您决定对其进行测试,以确保尽快创建已保留用于生产的结果,即使在此期间出现问题。
讨论
探索性测试也可以根据软件在项目会谈和简报期间的理解来制定。
问题和清单
诸如“什么、何时、如何、谁和为什么”之类的问题可能会为探索性软件测试提供提示。
探索性测试的类别
自由式探索性测试:
在自由式探索性测试中,应用程序是自发检查的,几乎没有标准或流程。但是,探索性测试在以下情况下可能是有益的 -
测试人员必须很快熟悉该程序。
测试人员必须确认其他测试人员的工作。
缺陷必须由测试人员调查。
测试人员渴望尽快完成冒烟测试。
基于场景的探索性测试:
基于场景的探索性测试涉及根据情况进行测试。场景可能由客户提供或由测试团队创建。在早期测试之后,测试人员可以根据新获得的信息和能力开发测试。
基于策略的探索性测试:
基于决策表的测试、因果图和错误猜测等常见测试方法与基于策略的探索性测试中的探索性测试相结合。这种测试形式的优秀测试人员应该是熟悉该应用程序的人员。
敏捷中的探索性测试
敏捷技术采用大约一个月的短冲刺,并有非常严格的时间表。由于时间短且强调即时结果,探索性测试在敏捷中非常有效。一旦测试人员理解了标准,他或她就可以根据他或她的专业知识和理解进行测试。
随着测试人员越来越熟悉应用程序的功能和操作,他将能够为未来的测试设计额外的测试用例,并且可能会发现更多的缺陷。
因为敏捷中的探索性测试独立于正式的程序和文档要求,所以测试人员不需要为所有事情保留文书工作,但保留一份关于尝试的对象、检测到的问题等的简要报告以供参考未来。
敏捷中探索性测试的优势
可以为开发团队提供对项目的即时输入。
可能会发现范围广泛的缺陷。
由于每个人可能有不同的观点,并且没有特定的测试用例,因此探索性测试可能由开发人员、测试人员、设计人员和业务分析师进行。
如果当前的需求不可靠,探索性测试可能有助于在有限的时间范围内评估新的需求。
探索性测试与自动化/脚本化测试之间的区别
探索性测试 | 自动化/脚本化测试 |
---|---|
There is no requirement to keep documentation in the case of exploratory testing. | 在进行自动化测试时,需要大量的文档。 |
This methodology demands little or no preparation time prior to test execution. | 在此策略中,必须经过大量时间才能开始测试。 |
There is no cost associated with generating documentation and no cost associated with reading it. | 在测试执行之前,主要工作是编写测试脚本和开发文档。 |
In exploratory testing, there is no obvious or quantifiable test coverage. | 为了验证测试覆盖率,可以将测试脚本追溯到原始标准和需求。 |
The application is evaluated against the tester's awareness and information of how the application should function. | 应用程序按照标准进行测试。 |
Only problems can be replicated in this method; testing cannot. | 测试可以简单地复制。 |
探索性测试的实时示例
测试人员可能会被要求在实时项目中实时进行探索性测试,以任意测试程序的各个方面以发现问题。探索性测试方法可用于评估来自任何领域的应用程序,例如电信、医疗保健和金融。换句话说,探索性测试方法不是特定于领域的。
一般来说,当测试人员希望测试开发团队在给定代码版本中没有解决任何问题的程序功能时,探索性测试是最有益的。换句话说,探索性测试更有利于在现实环境中进行健全性检查。
探索性测试面试问题
究竟什么是探索性测试,什么时候应该进行?
你如何进行探索性测试?
探索性测试的主要优点和缺点是什么?
探索性测试有哪几种?
探索性测试和自动化/脚本化测试之间的主要区别是什么?
提供一个探索性测试的例子。
探索性测试总结
探索性测试不是传统的测试方法,但却是一种非常有效的应用程序测试方法。
它鼓励有能力的测试人员走出界限,为问题检测创建实时测试场景。探索性测试,因为它是非结构化的,可以在任何需要最少文档的过程中进行,无论它是利用敏捷方法、瀑布模型还是任何其他软件开发生命周期原型。
以上是 什么是探索性测试?(技巧、例子) 的全部内容, 来源链接: utcz.com/z/353591.html