如何在不减慢速度的情况下有效地记录探索性测试会话以供将来重用？

Question

背景:在使用探索性测试时，高度赞扬自动化测试，每个测试人员都以个人方式在快速时间箱会话中以个人方式记录他/她的观察结果，这在发现关键错误方面效果很好。

问:如何有效地以正式测试用例的形式记录探索性测试会议的观察结果，以供其他团队成员将来再使用？

管理观点:从长远来看，这些测试用例的很大一部分也可以成为自动化的好候选。

关注点: QA组收到的一个重大关注是，如果他们开始在正式的测试用例中记录这些会话输出，他们将失去速度的优势，因为记录每个测试用例需要一步一步的时间。有时比测试会话本身的时间更长。

Answer 1

我建议选择一个免费的浏览器插件或者其他一些可以在后台运行的免费工具，而您的测试人员则运行他们的探索性会话。

我将以这样的方式对待工具的输出：

• 如果没有发现任何问题，就放弃日志吧--探索性测试的本质需要直觉、猜测和相当数量的巧合。如果会话没有发现任何问题，并且您的自动检查没有发现问题，那么您有合理的证据表明正在探索的系统中的部分适合使用。
• 如果存在问题，请使用日志生成再现步骤--测试人员可能不记得问题发生时他们做了什么，因此日志将有助于隔离和最小化再现步骤。
• 如果任何日志看起来可能是自动化候选文件，那么保留它--所需要的就是将会话保存在一个为潜在的自动化候选人员而设的专用位置，可能还会有一个说明，说明会话的哪一部分应该被考虑用于自动化。

像这样的轻量级系统不会给测试团队带来巨大的负担，可能有助于改进和报告错误，如果提出正确的方法，也可能足以满足您的管理团队。

我使用的替代方法是记录测试场景，而不是测试用例--也就是说，我有一个广泛的场景列表，我记录了这些场景。它们可能很简单，如“具有完全权限的有效登录”、“具有经理权限的有效登录”、“带有出纳权限的有效登录”、“无效用户名”、“无效密码”。它们也可能更加复杂，比如“经理为新产品类型创建订单，使用C税，每月支付发票”，甚至“经理创建的订单与出纳订单”--这取决于我在执行测试时所需的详细程度。

Answer 2

关注点: QA组收到的一个重大关注是，如果他们开始在正式的测试用例中记录这些会话输出，他们将失去速度的优势，因为记录每个测试用例需要一步一步的时间。有时比测试会话本身的时间更长。

工具支持:在我们的案例中，我们有类似的情况。因此，我们寻找一个工具，以满足我们的需求有关的探索性测试。因此，我们没有决定使用像HP ALM这样的工具，而是决定使用一个名为QASymhpony的工具，因为它适合我们的需要，在执行测试用例时直接创建测试用例。所以不需要创建测试用例，因为这是在测试执行过程中完成的(当然，我们必须进行一些调整，但它运行得很顺利)。因此，我认为探索性测试也取决于您拥有的测试工具。

Mob测试/对测试:此外，您还可以做一些与对测试几乎相同的暴徒测试。我们与我们的产品负责人和/或开发人员进行了联系，并在应用程序上进行了测试。所以我们没有记录任何东西，因为这个工具已经记录了测试步骤。如果你没有这个工具，你可以很容易地写笔记，并把它们钉在板上，这也是我们收集想法，如何进行测试的方法。如果我们发现了缺陷或错误，那么我们就创建了测试用例，以确保我们不会重复相同的缺陷。这样您就可以减少相关的测试用例。更多关于配对测试的信息，您可以在Lisa页面中找到，它非常有用，并提供了一些输入！巴林求学。

邀请业务部门减少测试用例:此外，我们还邀请了业务部门进行测试。我们非常惊讶他们是如何测试的。因为我们主要是从用户故事和业务部门的角度进行测试，所以我们从客户的角度来检查其他内容(比如：试探性测试实例目录 )。因此，我认为邀请业务部门进行测试(甚至潜在客户)对于创建测试用例来说是一个很好的建议。当然，我们并不是为来自业务部门测试用例的每个人创建的，只是为了防止检测到bug。这帮助我们减少了测试用例的数量(我们实际上想要创建这些测试用例)。

Answer 3

选择一些用于培训的示例，但不要为所有

添加更多的过程

我建议不要为将来的重复使用记录所有探索性测试的细节，因为尝试编写脚本，本质上是一次探索之旅，并不是探索性测试的本质。这方面的主要例外是获得培训和教育方面的例子。

相反，我将侧重于教授好的探索性测试方法、技术和技能，包括上面提到的培训。例如，确保您的探索性测试章程得到了很好的维护和发布。

永远记住“敏捷宣言”，特别是：

• 过程和工具上的个人和交互
• 基于综合文档的工作软件

这比看上去更难，因为我们都喜欢过程的真正优势