探索式软件测试的精华

1.局部探索式测试法

2.基于场景的探索式测试法

3.实践中的探索式测试法
3.1 Dynamics AX 客户端 (Nicole Haugen 的体会)
Dynamics AX 是企业资源规划 (ERP) 解决方案，这些程序都是在 20 多年前全部采用 C++ 语言实现的。。作为客户端团队，在这里，我们需要通过图形用户界面 (GUI) 来测试 Dynamics AX，在此之前，我的团队主要测试公共应用程序接口 (API)，所以，这对我们是一种思维方式的转变。在这个转变过程中，我们学到以下几件事情。

• 很多缺陷都不是通过测试设计中所定义的测试用例找到的
• GUI 测试引入的场景和复杂的用户交互似乎无穷尽，不容易使用自动化测试
• 不管测试是手动的还是自动的，都必须放到回归测试中加以维护。团队中有成千上万的测试用例，所以必须不断地考虑每一个新测试用例所带来的投资回报率
• Dynamics AX 是一个大型的应用程序，我们并不清楚其中的每一部分，更不用说应该如何对它进行测试。 探索式测试有助于我们解决以上所有的问题。最终我们是用下面的方法把它融入到我们的流程中。
• 在每个功能迁入 (check in) 之前，测试人员对代码执行探索式测试。这样做是为了在迁入前更快、更好地找到重要错误。如果代码修复的是关键性的或高风险的缺陷，我们对他们也采取了同样的做法。
• 探索式测试用于帮助我们在测试设计中开发出测试用例，它也可以帮助我们发现在孤帆说明书中可能漏掉的用户场景。
• 手工测试阶段，我们从测试脚本出发，然后引入探索式测试。个人经验是，未经改动的手工测试很少能检测到新问题；但是对现有测试做哪怕是最细微的改动都可能发现许多缺陷。
• 在缺陷” 大扫除”(bug bash) 时，我们采取了探索式测试，以引导我们到当前功能以外的地方去发现相关的缺陷。

有用的探索漫游

收藏家测试法和收集缺陷

漫游测试攻略

3.2 利用漫游查找隐错 (David GorenaElizondo 的体会)

3.3 在 Windows Mobile 设备中的漫游实践 (Shawn Brown 的体会)
2000 年微软发布一项产品，它是一种便携式的设备，可移植性很多全功能计算机上才有的功能。这个设备叫做 Pocket PC，它开启了 Windows Mobile 系列 (2009 年，微软将其更名为 Windows Phone) 版本的发布。随着 Windows Mobile 系列的发布，它的功能也越来越多。在我的 Windows Mobile 职业生涯期间，我负责测试连接管理器，一些较早版本的 Office 应用程序，还有就是我的最爱 ----- 打电话功能。
进行 3 小时的野外游，根据用户的实际环境进行测试。目标是发现 20 个缺陷，结果他们找到了 25 个缺陷。且发现破坏测试法、超模测试法和强迫症测试法最为有用。

3.4 Windows 媒体播放器的漫游测试实践 (Bola Agbonile 的体会)

3.5 停车场测试法及其在 Visual Studio Team System 测试版的应用 (Geoff Staneff 的体会)

• 1. 拿到版本之后，先做简短的停车场漫游来了解应用程序的各个部分是如何协同工作的，再把那些值得关注和后续测试的区域记录下来，下一步任务的重点是针对每个特性进行测试，通常在测试中还会有意识的加强某一方面的测试，例如可访问性，或处罚所有的错误对话框，或强迫采用所有的默认值…… 一般情况下，上述执行之后，最明显的缺陷基本都会被找到。
• 2. 进行更有针对性，也更加彻底的一轮测试。主要采用深巷测试法和强迫症测试法，这些测试方法都是基于过去几天对产品行为的观察和理解，以及和开发人员关于具体代码实现的相互交流。 另外和开发人员约定一种低开销的工作模式：如果开发人员可以再本周末前修复缺陷，那么测试人员就不会正式记录该缺陷。对开发和测试人员都有好处：产品质量可以迅速提高，没有人需要花额外的时间去上报缺陷和写缺陷文档。但是如果缺陷的周转要好几天而不是几小时，那么就要上报缺陷。
• 3. 通过分析缺陷和找到它们时使用的测试方法，对所找到的缺陷进行分类，结果如下：
  • 9%，出租车测试法 (键盘、鼠标等)
  • 9%，遍历测试法 (释放或者消除资源后，在进行检查)-----------------------严重缺陷
  • 15%，深巷测试法 (试图进行某种已知的不良操作，如关闭对话框两次) -------严重缺陷
  • 18%，强迫症测试法
  • 19%，地标测试法
  • 30%，超模测试法 ----------------------------------------------------- 大多不是严重缺陷

附录 2. JW 的专业博客摘录

软件诫律

• 1. 汝应使用大量输入反复锤炼汝之应用程序

用大规模随机测试来面对无穷尽的排列组合的输入。测试人员无论如何都要打起精神来面对无穷。这是每个测试人员工具箱里必备的一个工具。极少测试项目能够没有它。
大规模测试必须是自动化的。虽然第一次做总是有些难度，但是随着项目的积累会越来越简单，最终变为机械的工作。它可能不会找到大量的缺陷，但是它是对剩余测试用例的一种极好的健全性检查，随机测试有时能找到一些高质量 (尽管数量上很少) 的缺陷；仅仅在编写大规模随机测试计划的过程中，我几乎总能找到缺陷或是想到一些很好的测试点子。

• 2. 汝应贪图汝之邻居的应用程序

不要将应用程序孤立起来测试。否则很可能陷入” 应用程序兼容性” 的噩梦里。一种方法是储备一些应用程序 (旧的，新的，借来的……并且保证在运行应用程序的同时也运行这些程序。当然针对操作系统也要进行这项工作。例如安装某个操作系统升级服务包之后因公用程序无法运行……。所以我们要开始贪图那些应用程序和服务包，越多越好。

• 3. 汝应亲自寻找睿智的预言家

我们测试软件的时候需要知道该软件是否按照既定的方式回应我们的输入。如果无法验证，测试就无法有效进行。测试人员在谈到知道所有答案的睿智的预言家时，称其为” 预言家难题”(oracle problem)。这需要我们的预言家 (也就是测试的基准) 清楚地了解在给定特定输入和环境条件组合的情况下，应用程序应有的行为。将测试基准进行自动化是很困难的一件事，但是很值得去追求，因为这不仅仅可以创建一个很有价值的测试工具，其本身也是一个启迪智慧的追求过程。无论你最终是否成功的是测试基准自动化了，强迫你自己像它一样思考，常常比你可能选择做其他任何事更有工作效率。

• 4. 汝不应崇拜无法重现的失效

这条诫律的教育意义是双向的。第一，尽你最大的努力注意并记住 (或记录下来) 对软件才去的动作次序，同时记住应用程序的响应。第二，考虑使用调试器之类的能追踪动作和软件状态的工具。

• 5. 汝应尊重你的模型和自动化测试

诫律 1 是关于随机测试的重要性 ------ 重点在于随机。而这条诫律是关于智能的随机测试 ------ 重点在于智能。把智能和自动化测试合二为一，其结果就是基于模型的测试 (model-based testing)。这是主导未来的自动化测试技术。
好的模型可以使自动化测试足够聪明，能响应错误和覆盖那些笨拙的自动化测试无法覆盖的代码。哪怕你没有耐心实现自动化建模，进行建模的过程也至少能让你更好地准备测试。

• 6. 汝应利用开发人员的过错与他们作对

如果开发人员编写某个模块时犯了一个错误，我们应该假设其它开发人员在类似的模块中可能会犯同样的错误。如果某个开发人员倾向于写死循环，那么我们需要保证在该开发人员编写的每个模块都需要测试这类错误。这就是” 从经验中学习”，我们的任务是保证我们的开发人员采取正确的行为：理解他们的错误模式，从而避免那些错误。

• 7. 汝应醉心于谋杀应用程序

作者清楚地记得他的第一个蓝屏缺陷，它好像就发生在昨天。任何一个缺陷不能不进行深入调查就轻易放过。这条诫律的教育意义是在每一个好的缺陷背后，都可能隐藏这一个更好的缺陷。在确实了解缺陷的影响程度和破坏力之前永远不要停止探索。

• 8. 汝应保持安息日的圣洁

作为测试人员，我们只是需要在给定的时间之内完成尽可能多的工作。我们不应该抱怨发布日期，而是应该提前警告后果。这是我们的职责范围，也是我们应该担心的范围。

• 9. 汝应贪图开发人员的源代码

如果可以接触到源代码，就好好利用它。我们应该像一个测试人员而不是像开发人员那样利用源代码。阅读源代码可以学习到很多东西。阅读源代码时，我工作列表上的第一项就是寻找错误处理代码和能为我们指明错误代码正在执行的对话框。从用户界面上最难见到或得到的代码就是错误处理代码。花时间理解代码中写了哪些错误处理，哪些输入能触发它们，这样做是值得的。