什么是探索性测试?(技术、示例)
顾名思义,探索性测试是关于观察和了解程序,它做什么,它不做什么,什么有效,什么无效。测试人员始终在决定接下来检查什么以及在哪里投入他或她(有限的)时间。当没有或很少有需求并且速度至关重要时,此方法特别有用。
探索性测试可以与其他方法结合使用。
什么是探索性测试?
探索性测试是一种实践方法,测试人员尽可能少地进行准备,尽可能多地进行测试执行。
测试计划过程从生成测试章程开始,测试章程是对一个简短的(1 到 2 小时)时间盒测试尝试范围的简要陈述,以及要使用的目标和潜在方法。
通常,测试设计和执行操作同时进行,不记录测试条件、测试用例或测试脚本。但这并不排除使用其他更正式的测试程序。例如,测试人员可以选择进行边界值分析,但只会考虑和测试最关键的边界值,而不会将其写下来。在探索性测试会话期间,会做一些笔记,以便稍后进行审查。
在执行测试时,会进行测试记录,记录已检查内容的基本部分、发现的任何缺陷以及关于未来可能测试的任何建议。
它还可以用来补充其他更正式的测试,从而增加对程序的信任。在这种方法中,探索性测试可以作为对正式测试过程的检查,帮助发现最关键的问题。
[Kaner,2002] 和 [Copeland,2003] 讨论了探索性测试。[Whittaker,2002] 描述了更多探索性测试方法(“攻击”)。
何时使用探索性测试?
探索性测试在 SDLC(软件开发生命周期)的早期阶段非常有用,此时程序正在经历频繁的修改。
开发人员可以使用此方法运行单元测试,而测试人员可以使用此方法熟悉应用程序。
探索性测试专业知识可能有助于在软件开发生命周期的后期编写测试脚本并进行更多测试。
在敏捷开发环境中,冲刺周期很短,构建严格的测试设计和脚本存在设计时间限制。由于能够跟上短冲刺周期,探索性测试非常适合敏捷环境。
在进行探索性测试时,测试设计是在过程中创建的,这为测试人员节省了大量时间。可以在每个冲刺周期结束时收集关键的探索性测试,以供将来的冲刺使用。
Explore our latest online courses and learn new skills at your own pace. Enroll and become a certified expert to boost your career.
测试方法 - 如何进行探索性测试?
要进行测试,请利用测试人员自行调整事物的能力。
测试用例的计划和实施是同时进行的。
由于测试人员的发现,测试用例的数量不断增加。
测试人员将他们学到的东西应用到考试中。
等价划分、错误猜测、决策表测试、边界值分析和其他测试方法可以与探索性测试集成。
测试人员可以在专注于任务的同时将他们的想法付诸实践。
探索性测试不使用测试自动化,而是依靠测试人员的专业知识、洞察力和技能。
探索性测试可以基于会话来保持注意力并提供结构。
探索性测试的优点
需要最少的准备,并且可以快速发现关键错误。
建议进行批判性思考并快速响应,并且可以发现更多缺陷。
对于测试人员来说,更加注重扩展他们的专业知识和理解。
它可以用来检查其他测试人员的工作。
探索性测试可以发现测试用例中可能未被发现的缺陷。
当时间紧迫时,可以使用探索性测试来评估新功能,而可以使用回归测试来评估现有功能。
探索性测试的缺点
由于测试是随机创建和执行的,因此无法事先检查,并且可能难以确定必须执行哪些测试。
测试依赖于测试人员的专业知识、才能和经验。
熟悉应用程序需要一些时间,因此如果测试人员不熟悉网站或程序,则有可能忽略问题。
探索性测试示例
假设某人在没有地图的情况下驾驶车辆到新区域的某个地点。驾驶汽车的人将采用各种标准策略到达那里,包括:
获取周边区域的地图
随机方向行驶以找到位置
联系朋友并询问路线
前往附近的加油站询问路线
类似的概念可以应用于探索性测试。
假设您已获得对医院管理系统进行探索性测试的任务。
探索性测试有多种方法。
猜测
猜测用于识别软件中更可能包含错误的区域。先前在类似产品/软件/技术上的工作经验有助于猜测。
在医院管理系统的示例中,您可以预期付款组件会存在更多错误,因为它必须连接到支付网关;如果未正确管理,交易可能会超时并导致问题。
架构图和用例
架构图描绘了不同组件和模块之间存在的连接和链接。用例从用户的角度提供了对产品功能的了解。
这些图纸和用例可用于探索方法中以测试产品。
医院管理系统 - 您回想起一个用例,其中许多人可以使用相同的电话号码,并且应用程序必须允许它;您决定测试这种情况。
您还从架构图中回想起,报告功能与主应用程序单独部署,并且生成和发送给用户需要几分钟时间,因此您决定对其进行测试,以确保生成报告并正确配置电子邮件功能。
过去的缺陷
检查过去版本中遇到的问题有助于识别程序哪些方面最可能存在缺陷。
以前,医院管理系统的报告模块曾经占用大量 RAM 并存在各种错误,因此您决定对其进行测试。
错误处理
错误处理是在系统发生故障时启动必要措施的代码部分。可以使用各种场景执行探索性测试以验证友好的错误处理。
医院管理系统的报告模块会占用大量内存,有时会崩溃。您决定对其进行测试,以确保即使出现问题,也能够尽快生成已保存到生产环境中的结果。
讨论
探索性测试也可以根据项目讨论和简报中对软件的理解来制定。
问题和清单
诸如“什么、何时、如何、谁和为什么”之类的问题可能会为探索性软件测试提供提示。
探索性测试的类别
自由式探索性测试
在自由式探索性测试中,应用程序是自发地检查的,几乎没有标准或流程。但是,探索性测试在以下情况下可能会有所帮助:
测试人员必须快速熟悉程序。
测试人员必须确认其他测试人员的工作。
测试人员必须调查缺陷。
测试人员希望尽快完成冒烟测试。
基于场景的探索性测试
基于场景的探索性测试涉及根据场景执行测试。场景可能由客户提供或由测试团队创建。在早期测试之后,测试人员可以根据新获得的信息和能力开发测试。
基于策略的探索性测试
基于策略的探索性测试将决策表测试、因果图和错误猜测等常见测试方法与探索性测试相结合。此类测试的优秀测试人员将是熟悉应用程序的人。
敏捷中的探索性测试
敏捷方法使用大约一个月长的短冲刺,并有非常严格的时间表。由于时间短且注重即时结果,探索性测试在敏捷中非常有效。一旦测试人员理解了标准,他或她就可以根据其专业知识和理解进行测试。
随着测试人员越来越熟悉应用程序的功能和操作,他将能够为将来的测试设计额外的测试用例,并可能发现更多缺陷。
由于敏捷中的探索性测试独立于正式程序和文档要求,因此测试人员不需要为所有内容保留文档,但保留尝试过的对象、检测到的问题等的简要报告以供将来参考将很有用。
敏捷中探索性测试的优点
可以向开发团队提供有关项目的即时反馈。
可以发现各种各样的缺陷。
由于每个人可能拥有不同的视角,并且没有特定的测试用例,因此开发人员、测试人员、设计师和业务分析师可能会进行探索性测试。
如果当前需求不可靠,则探索性测试可能有助于在有限的时间范围内评估新需求。
探索性测试与自动化/脚本测试的区别
探索性测试 | 自动化/脚本测试 |
---|---|
在探索性测试的情况下,不需要保留文档。 | 在进行自动化测试时,需要大量的文档。 |
这种方法在测试执行之前几乎不需要或不需要准备时间。 | 在此策略中,在测试开始之前必须经过大量的时间。 |
生成文档和阅读文档都没有成本。 | 在测试执行之前,编写测试脚本和开发文档需要大量工作。 |
在探索性测试中,没有明显的或可量化的测试覆盖率。 | 为了验证测试覆盖率,可以将测试脚本追溯到原始标准和需求。 |
根据测试人员对应用程序如何运行的了解和信息来评估应用程序。 | 根据标准测试应用程序。 |
在此方法中,只能复制问题;不能进行测试。 | 测试可以简单地复制。 |
探索性测试的实际示例
在处理实时项目时,可能会要求测试人员进行实时探索性测试,以任意测试程序的各个方面以发现问题。探索性测试方法可用于评估来自任何领域的应用程序,例如电信、医疗保健和金融。换句话说,探索性测试方法不是特定于领域的。
通常,当测试人员希望测试程序的某些功能时,探索性测试最有用,这些功能在开发团队给定代码版本中未解决任何问题。换句话说,探索性测试在现实环境中进行健全性检查更有益。
探索性测试面试问题
什么是探索性测试,以及何时应该进行探索性测试?
您如何进行探索性测试?
探索性测试的主要优点和缺点是什么?
探索性测试的多种类型是什么?
探索性测试与自动化/脚本测试的主要区别是什么?
提供探索性测试的示例。
探索性测试总结
探索性测试不是一种传统的测试方法,但它是一种非常有效的应用程序测试方法。
它鼓励称职的测试人员跳出框框,为问题检测创建实时测试场景。由于探索性测试是非结构化的,因此可以在任何需要最少文档的流程上进行,无论它是在使用敏捷方法、瀑布模型还是任何其他软件开发生命周期原型。