测试建模：功能列表（Function List）

标签：

功能列表（Function                           List）是一种功能测试（Function Testing）的建模方法，在启发式测试策略模型（Heuristic                           Test Strategy Model）中位于 HTSM -> Product Elements                            –> Function 分支中。虽然它只覆盖了很小的测试领域，不适合作为主要的测试方法，但是仍不失为一种有启发、有帮助的测试建模技术。本文将简介功能列表及其应用。

什么是功能列表？

Cem Kaner在Black Box Software Testing                            中将功能列表定义为：程序功能的大纲（ an outline of the                           program‘s capabilities）。对于PowerPoint的图片功能，测试人员可以建立如下功能列表:

限于篇幅，该功能列表只列出了PowerPoint图片的部分功能（真实的测试需要更详细的功能列表），但是它很好的体现了功能列表的特点。第一，它列出了图片的主要功能：输入、操作、应用、输出、打印和文件读写，使得测试人员能够在整体上把握被测领域。第二，它的层次结构提供了可扩展的框架，测试人员可以持续地补充细节：具体的功能和针对该功能的测试想法。第三，它为功能覆盖提供了覆盖目标，为制定测试计划提供了有益的信息。第四，功能列表可以包含一些助记符（如标签）和链接。作为大纲，它可以指向更多的资料；作为测试触发器（trigger），它可以启发测试思路。

功能列表的形式

我习惯用符号列表（bulleted list）制作功能列表，因为符号列表被大量的文档编辑器和文档格式所支持，能够快速地编辑、修改和发布。

此外，许多测试人员喜欢用思维导图（Mind Map）记录功能列表、测试设计和测试计划，也获得了很好的效果。下图是思维导图形式的功能列表。                         

功能列表与漫游测试

漫游测试（Tour Testing）是一组以漫游隐喻为核心的测试方法。在应用漫游测试时，测试人员常常会游历被测产品的结构、功能或数据，在此期间运用他的技能和经验去发掘产品的缺陷。

功能列表为功能漫游（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

测试建模：功能列表（Function List）

标签：

原文地址：http://www.cnblogs.com/aliceliu626/p/4813870.html