探索性测试

探索性测试是一种测试风格，强调快速学习、测试设计和测试执行的循环。探索性测试不是试图验证软件是否符合预先编写的测试脚本，而是探索软件的特性，发现新的行为，然后将其归类为合理行为或故障。

探索性测试的思维方式与脚本测试形成对比。在**脚本测试**中，测试设计人员创建测试脚本，其中软件的每次操作都记录下来，以及软件的预期行为。这些脚本被单独执行，通常执行多次，并且通常由与编写脚本的人员不同的执行者执行。如果任何测试显示的行为与测试设计人员设计的预期行为不符，那么我们认为这是一个故障。

长期以来，脚本测试通常由测试人员执行，你会看到很多相对初级的员工坐在隔间里，按照脚本点击屏幕，检查结果。很大程度上由于像极限编程这样的社区的影响，人们开始转向自动化脚本测试。这使得测试能够更快地执行，并且消除了评估预期行为中的人为错误。我一直是这种自动化测试的坚定倡导者，并且亲眼见证了它的使用极大地减少了 bug。

但即使是最坚定地进行自动化测试的测试人员也意识到，这种技术存在着根本性的局限性，这是任何形式的脚本测试的局限性。脚本测试只能验证脚本中的内容，只能捕获已知的情况。这些测试可以是一个精细的网，可以捕获任何试图通过它的 bug，但我们如何知道这个网覆盖了它应该覆盖的所有内容呢？

探索性测试试图测试这个网的边界，找到任何脚本中都没有的新行为。它通常会发现新的故障，可以添加到脚本中，有时它会暴露一些良性的行为，甚至受欢迎的行为，但之前没有想到。

探索性测试比脚本测试要灵活得多，也更非正式，但它仍然需要纪律才能做好。一个好的方法是在时间盒式会话中进行探索性测试。这些会话专注于软件的特定方面。一个识别会话目标和希望找到的信息的章程是一个很好的机制，可以提供这种焦点。

这样的章程可以作为焦点，但不要试图定义会话中会发生的事情的细节。探索性测试包括尝试事物，更多地了解软件的功能，将这些知识应用于生成问题和假设，以及在当下生成新的测试以收集更多信息。这通常会激发章程范围之外的问题，这些问题可以在以后的会话中探索。

探索性测试需要熟练且好奇的测试人员，他们对了解软件并能在会话期间提出新的测试设计感到舒适。他们还需要善于观察，注意任何看起来奇怪的行为，值得进一步调查。然而，他们通常不必是全职测试人员。一些团队喜欢让整个团队进行探索性测试，也许是成对或以单个团队的形式。

探索性测试应该成为贯穿整个软件开发过程的常规活动。遗憾的是，很难找到任何关于在项目中应该进行多少探索性测试的指南。我建议每隔几周进行一次一小时的会话，看看这些会话发现了哪些信息。一些团队喜欢在完成一个故事后安排大约半小时的探索性测试。

如果你发现 bug 正在进入生产环境，这表明测试方案中存在漏洞。值得查看任何逃逸到生产环境的 bug，并思考可以采取哪些措施来防止 bug 进入生产环境，或者在生产环境中快速检测到 bug。这种分析将帮助你决定是否需要更多探索性测试。请记住，如果你以前没有进行过太多探索性测试，那么需要时间才能培养做好探索性测试的技能。

如果一个团队根本没有进行探索性测试，我会认为这是一个危险信号——即使他们的自动化测试非常出色。即使是最好的自动化测试本质上也是脚本测试——而这本身还不够好。