功能测试因素

作者简介如下：   

Michael Bolton lives in Toronto and teaches

heuristics and exploratory testing inCanada,

the United States, and other countries aspart

of James Bach’s Rapid Software Testing

course. Michael is also program chair forthe

Toronto Association of System and Software

Quality. He is a regular contributor to Better

Software magazine. Contact Michael at

mb@developsense.com.

翻译文章如下：

在上一期中，我介绍了詹姆士在他启发式测试策略名字模型中的九个测试技术。在这篇文章中，我将主要关注功能测试，它可能是这些技术中使用最广泛的。

功能测试中，我们测试项目做什么，最基本的策略是定义项目的每一个功能，然后测试它所支持的每一个功能和不支持功能。听起来很容易，不是吗？但是事实并非如此。

一个原因是可能有很多方法去实现一个功能，例如，我可以通过以下途径使MW打印一个文档：

按ctrl+p

选择文件，然后从主菜单上打印

在资源管理器中右击一个word文档，从下拉菜单中选择打印

从一个应用程序中应用Visual Basic应用程序选择word打印功能。

作为一个练习，想下其他能实现word打印功能的途径，在你想到12种方法之前不要停止。下一步，想想一个应用中你要测试的一些功能和有多少途径可以实现那些功能。

功能测试需要有严格的原则或者机制，使我们承认一个问题。一个oracle可能是一个定义了一些期望答案的参考性文件。它可能是我们运行前或者测试后比较一些功能结果时的参考项目。它也可能是一个准则，当我们点击一个取消按钮时，我们希望这个操作停止或者当前对话框消失。快速测试人员另外使用“live oracles”，如采访一个商人和我们坐在一起行使该项目的功能，这次结合操作和观察的谈话是一个很实用的测试技术。

我喜欢把一些事情的发生响应另一些事情的发生定义一个功能。一些功能看起来是被用户引起的，我说“看起来”是因为用户进行一些操作，特别是鼠标和按键，但是那操作并不直接影响我们的项目。一个按键会引起一系列事件：来自键盘操控者的一条信息，一次操作系统中断，操作系统中的一条处理程序，，操作系统向我们项目发来的一条信息。当信息到达后，我们的程序可能会自动采取一些步骤去完成这个功能。在它自己的定义中，这些步骤中的每一步都可以看成是一个功能。

被开发者称为的单元测试，对于证明功能测试在最早时间，最底层次，最大程度上是可行的，是一个强有力的论据。单元，像功能，在大小和范围上有点不同，我将在这把我们所关心项目的最小部分定义为单元。每个任意小的子功能都有潜在的错误。每个功能的自动化单元测试，在测试驱动情况发展之前，它是书面的，在一定程度上，至少为每个函数满足一些要求提供一些保障。在单元测试层面上，oracles更趋向于机械的，基于开发者在写这个功能初衷时的单一准则。

以我的经验，开发者写这些单元测试，测试者经常不会进入这一层的测试。对于测试者和开发者有不同的动机，它可能不错。开发者功能测试的目标往往是确定这些功能可以实现和一些改变不会影响已存在的功能，这种测试被设计成快速频繁，彻底交易，简单和可重复性的变异。当测试者执行功能测试时，目标更接近用户的任务，关注的是更多调查，寻找特殊的案例和未预料到的行为。相比于自动单元测试这需要更宽的覆盖面和更大的变化，可以通过破坏它涉及苛刻的测试旨在探寻系统的弱点。发散的思维是很有价值的，测试者和开发者可以从相互身上学到很多，EH和JK在关于如何加强合作以促进更好的单元测试的演讲和著作是令人信服的。

功能单元形成高层次功能的积木，在那程序接触到更广泛的数据，平台，操作概况，时序关系。快速测试者用HTSM去激发测试想法，我们通过观察项目的结构和功能应用它们，在不同层面上，另一个方法定义功能是用JW的关于四个项目用户的想法：一般用户，操作系统，文件系统，交互的应用软件。

在最高层次上，建立一个项目的功能模型，试着定义一个用户可以做的所有事情。观察屏幕上的每一部分，触发弹出式窗口和对话框，选择其中的选项，从下拉菜单中选择，输入文字，执行计算，并引发现场更新。通过键盘，指定设备或者更间接的如API检查事情能够完成。在给定情境下，选择oracle去确定哪一种输入方式应该被支持。程序往往运行在不同的平台上（对于快速测试仪，一个平台是我们项目依赖的一切，但是这在我们目前的项目范围之外。）在我们程序中的某些功能可能是自主的，别人可能仅仅要求来自平台一些服务，还有一些可能在调用程序的同时做了一些工作相互之间的通话。一些平台可能要求不一样，不仅要求我们测试复合功能还要求我们在复杂平台上测试。

对于每一个功能，不仅注意到输出还要查看结果-----Boris Beizer在他的书《黑盒软件测试》中对其有很好的区别。输出是直接的，我们观察到功能的明显结果，例如我们的基础问题的答案，在空白领域出现的数据，打印的文件。结果是一个远不止那些的东西，它是我们测试功能结束后系统的整个状态。一些功能没有直接的输出，但肯定会有一个结果。有时我们想测试去证明系统状态发生一些改变，然而另一些我们想去确定它们并没有发生有影响的变化。用工具去识别可能是无形的结果。对于Windows，我发现了免费的Sysinternals工具，对于监控文件系统，注册表，进程表特别方便。

在任何有意义的一个项目中鉴别和测试每一个功能是不可能的，因为功能的数量，我们可以使用的不同数据等等。那么我们怎么选择哪个功能运行测试？一种方法是评估风险。在初级阶段，功能测试可能看起来是开发者编码错误引起的。在更高阶段上，它们可能是商业风险和与用户执行的任务有关的问题。

最后，我们不一定仅仅依赖于功能测试。其他测试技术运用于项目的功能来应对功能测试可能会错过的风险。通过多元化的测试策略可以加强测试，所以执行大量的功能测试，但不离开功能测试目标。

翻译的有点粗糙，大家勉强看吧。也可以直接看原文，标题：The Fators of Function Testing ,百度之就OK了