功能列表为功能漫游（Feature Tour）提供了有益的信息。它像一幅地图，既描绘了产品的概况，又提供了必要的细节，为探索者提供了指南与参考。测试人员可以漫游功能列表上的所有元素，以实施全面探索；也可以选择遍历某个功能子集，以实施专项测试。

    在测试之初，测试人员对被测产品尚不了解，他可以通过功能漫游来建立功能列表。从这个角度，漫游的过程是测试建模的过程，功能列表是漫游测试的产出。Cem Kaner建议，在软件尚不成熟时，测试人员应该同情地测试（test sympathetically）。此时，测试的目的不是发现所有缺陷，而是提交重大问题，发现风险区域，建立测试模型，为今后的测试奠定基础。对此，测试专家Michael Bolton有一番精彩的论述：

    同情的测试非常重要，虽然一些测试人员会发现它的反面（全力寻找缺陷）难以拒绝。Jon Bach（测试专家，其兄弟James Bach也是测试专家）指出在探索式测试的早期，他通过测试来发现产品的优点（benefits）。我觉得这很奇怪，直到他指出寻找并记录缺陷使得他不能专注地漫游产品并构建产品的模型。

    测试人员需要建立产品的大局观，同时掌握产品的优点、缺点、概念模型和实现逻辑。漫游测试是很好的学习过程，功能列表是一个有益的学习成果。

用功能列表启发测试设计

    在测试设计时，测试人员可以将功能列表视作覆盖率指南。他逐个检查每个功能，阅读相关的测试想法，从而设计测试策略。在此过程，他可以自问：

  • 该功能与当前测试任务相关吗？
  • 该功能存在什么风险？可能会有什么缺陷？
  • 通过什么测试可以发现这些缺陷？
  • 在上次测试中，该功能表现如何？已有的测试想法，哪些值得再次尝试？哪些不必再测？
  • 依据当前的进度和资源，如何实施这些测试？
  • 功能列表是否充分？有没有漏掉一些功能？

    另一种更有威力的方法是综合功能列表中的多个元素，开发测试策略，以测试它们的交互和影响。随着产品逐渐成熟，隐蔽的缺陷往往存在于功能的组合，暴露于复杂的流程。这要求测试人员综合多方面的信息，来更深入、更多样地测试系统。当测试人员考虑功能的组合时，他可以自问：

  • 该功能与哪些功能相关？
  • 功能的组合有没有揭示出新的风险？可能会有什么缺陷？
  • 哪些功能访问同一批数据？哪些是生产者？哪些是消费者？
  • 如何设计测试，以同时测试这些功能？
  • 如何构造一个（有意义的）业务流程，它能够访问尽可能多的功能与数据？
  • 对于相互依赖的功能，某个功能的失败是否对其他功能造成恶劣影响？

    在回归测试时，功能列表是很好的参考。例如，测试人员可以按如下测试策略对PowerPoint的图片功能进行回归测试。

1.新建一个PowerPoint文档

2.向文档中插入图片

1.覆盖所有支持的图片格式

2.覆盖典型的图片尺寸

3.覆盖来自单反相机的大型图片（该条目显示随着硬件的发展，测试策略也需要变化）

3.操作文档中的图片

1.覆盖Picture Tools下的所有命令

2.一些图片只被一个命令修改

3.一些图片被多个命令修改

4.一些图片不被修改

4.应用文档中的图片

1.将图片与其他元素组合使用

2.覆盖文本框、形状、SmartArt、图表等

5.将文档中的元素另存为图片

1.覆盖所有可以被输出的元素：图片、形状、SmartArt、图表等

2.覆盖所有支持的图片格式

6.打印该文档

1.打印到（黑白和彩色）打印机

2.打印到PDF文档

3.打印到XPS文档

7.另存该文档并重新打开

1.另存为所有支持的格式

2.用PowerPoint打开生成的文档

3.用旧版本PowerPoint打开生成的文档

    利用该测试策略，测试人员可以用一个很长的流程覆盖大多数的图片功能，不但可以测试图片功能的组合，还可以顺便测试程序的稳定性和资源占用。测试结束时，测试人员可以获得一个大型的PowerPoint文档，它包含各种图片和相关元素，为今后的回归测试提供了良好的素材。

参考资料

Cem Kaner: Black Box Software Testing （第48~56页）

Darren McMillan: Mind Map 101

Michael Bolton: Of Testing Tours and Dashboards