探索性测试和发现新错误的策略和技术？

#1 楼

探索性测试的一般推荐策略和技术是什么？


ET推荐策略：




使用探索性宪章来指导您的工作。即使您不花时间进行探索，章程也会为您提供足够有用的详细信息。


发展您撰写优秀章程的能力还需要时间。从cr脚的人开始，然后逐步改善他们。随着您变得更加舒适，这变得越容易。


记下基本注释，以帮助您总结和学习章程。无论这些是思维导图还是简单的注释等。
时间限制了您的章程进入会议。这是基于会话的测试管理（SBTM）的基础。
继续练习，尝试新事物并吸收反馈。

ET技术：

您可以探索性地使用任何测试技术：


功能，领域（边界和等效性分析），方案，可用性，性能等。
您甚至可以探索性的方式使用自动化。

其他ET /混合方法：

您提到了配对测试，您绝对可以通过探索的方式进行。我建议您使用宪章，然后在谁进行驾驶（动手）的一对驾驶员之间关闭。

#2 楼

聚集具有广泛背景和专业知识的听众


不同背景的不同人提供不同的思维方式。令人惊讶的是，旁边的人如何提供新的思维方式。

与聚集的人群一起进行头脑风暴会议


当人们一起工作时，它们互相激励，可以更快地获得更好的想法。

头脑风暴的想法可以用作探索性的测试方法。


发展一种文化也有好处关于头脑风暴的探索性测试想法。
在头脑风暴的会议中，我更喜欢让每个人先在一张纸上写下他们的测试想法，而不向任何人展示。这样，人们受他人逻辑影响的可能性就较小，因此思想的传播范围也更大。当然，每个人在给定的头脑风暴会议上都用尽了创造力后，测试想法就会在每个人之间共享。

某些工具可能会有所帮助


思维导图可以有助于可视化测试构想之间的关系。您可能会在视觉上发现新的测试思路等。

不需要测试计划


通常，探索性测试不需要预先编写的测试计划；有些人会认为测试计划总是有助于簿记目的。以我个人的经验，我不希望在探索性测试完成之前没有书面的测试计划。

配对测试甚至小组测试


在小组工作时，人们会激励彼此之间，通常可以更有效地管理时间。

#3 楼

“自由式测试在很大程度上取决于测试人员的创造力以及他们对被测产品或功能的了解程度。”

我会用“经验和培训”来切换“创造力”（我在Wikipedia上也看到了）。他们对产品的了解程度绝对有帮助。

我分解这样的探索性测试：

不同的路径：


快乐-用户正确输入所有内容并单击正确的按钮和链接
悲伤-用户输入无效数据或输入数据失败-应正确完成向最终用户的错误报告-正确的标记，不依赖红色，等等。
可选-许多站点都有“可选”功能。例如额外的订单，第二送货地址，不同的付款方式等。可选的工作流程中也会有喜忧参半的流程

因此，以上内容适用于工作流程。现在检查单个元素（字段，按钮，文本等）：
要测试以下各项：


所需数据
无效的数据类型（字符串日期，用于日期的整数等）。
使用了无效的数据格式
数据验证，例如“添加日期”必须是过去的日期，“ dob”必须是> 1900，等等。
边界测试（1个在限制之下，在限制，在1个超出限制等）
数据之间的有效关系

我认为探索性测试的“自由式”主要部分是发现以前或最近未测试的新功能或更改功能。
方法的一部分可以包括“我仅检查”每5次运行x次，我每周仅检查y次，每月仅检查一次z，而我本人也使用了这种方法。它使测试人员可以涵盖更多的测试内容，并有助于实现单调，无聊和死记硬背之间的人类平衡，以及需要全面测试。

测试人员的经验和态度可能与创造力有关。例如，我认识一个探索性的测试人员，其目标往往是赞成发布。我认识的另一位测试人员经常将他们的使命看作是“总有我可以打破的东西，我只需要尽力而为”，他们几乎总是设法找到某种错误-尽管通常很小，而且不一定与最近的变化有关。他们甚至说，发布测试通常是检查产品总体健康和功能的好借口。探索性测试的很大一部分还在于，您每次参加一次会议都会学到更多，并且以后的会议中您的大脑会使用这些知识，而无需更新任何脚本。

更广泛的目标是“查找更多错误，我还建议您详细了解以下内容：


您所在的行业
产品用户的特征
产品及其使用方式作为其他流程的一部分
贵公司的业务目标和目的
'新用户'测试服务，例如用户测试和可用性科学

#4 楼

因为开发人员通常只是测试“幸福的道路”，所以任何绕开它的道路都可能发现潜伏的问题。省略一些输入字段。以不同的顺序输入字段。在页面之间来回移动。更改页面大小。输入无效的输入。

幸福的道路应该是自动化的（包括检查标准错误），但是人类在如何偏离幸福的道路时如何破坏系统方面具有很大的创造力。

经验，您会发现破坏某些页面的方法-机会是，其他页面也无法处理此类破坏。

查看OP配置文件，并以诸如https://stackoverflow.com/questions/ 30600738 /不带硒的差动量角器：OP是一个非常有经验的测试员，因此像OP这样的基本答案可能对OP没有太大价值-但它可能会使其他人受益。

#5 楼

预编写的测试用例通常将根据规范编写，并涵盖预期的方案。通常这些事情会起作用，因为开发人员已经检查了基本功能。

探索性测试发现更多错误的原因在于，很难完全解释功能之间的微妙交互或代码在异常情况下做出的错误假设。例如，如果从用户流中取消，也许应用程序假定一些最终没有输入的数据。

您还可以拥有根本无法预期的用户方案，例如，如果应用程序允许我输入的输入数量是无限的，最终会导致问题。

在实践中，探索性测试感觉是随机的，但是我认为我实际上是在尝试查找应用程序允许的内容，但这是出乎意料的。