软件测试实用指南

第1章指导软件测试的故障模型

软件测试的目的

好的测试员具有一种直觉，这种直觉引导他们彻底全面地思考测试场景。使测试员产生这种直觉的技术术语就是故障模型，因为故障模型提供了一个模型或框架，用来讨论代码中的故障是如何以及为什么能在软件执行时引起软件失效。对于测试员来说，重要的是能够构造出一个准确的故障模型，并在测试过程中使用该模型，确保能检查出隐错最可能隐藏的地方。

人们处于不同的动机去进行软件测试，其中绝大多数动机都可用一个名称来描述。想要通过测试确定所在机构是否应该接受某个产品，这种测试成为符合型测试；想要通过测试确定某个产品是否易于使用，这种测试成为可用性测试。这样列举下去，还会包括性能测试，可靠性测试，健壮性测试等等。

诸多种类的测试具有一些共同特性：

每种测试都需要测试员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书、需求文档、产品文件或用户手册。

每种测试都需要产品运行于真实或模拟环境下。

每种测试都要求以系统方法展示产品功能性，说明测试结果是肯定的还是否定的，以及是否课判断其中的区别。真正区分失效测试和成功测试的关键在于：必须知道在寻找什么，并能说出何时找到了。

每种测试都包括上述特性，主要差别在于其目的和一些细节处理上的差别。总之，抛开这些细节和目的不谈，软件测试需要以系统和智能的方式运行和展示产品的功能。

软件测试应具有智能性，有关于应用程序如何运行的加精盐，规程和知识及可能会出现的故障知道测试员实施测试。

优秀的测试员不能依靠运气，而是必须为所测试的软件设定清晰、明确、可实现的目标以及所有错误纠正后的下一个测试目标。有效测试的特点就是设定这样的目标，并进行系统的开发，直至目标达到。

理解软件行为

开发具有影响力的软件是相当困难的，一旦投入使用环境，软件常常会失效。开发人员必须找出能减少编程出错倾向的方法，测试员页必须把重点放在寻找测试方法上，通过测试说明软件能无效的完成它应该完成的功能。让测试员深感遗憾的是，测试时有太多的输入，输入变量、输入组合以及软件状态。还有一些功能必须保持未测状态。测试的难题是选择哪些要进行测试以及哪些不需要测试。

要有效的完成这些关键的决策过程，测试员需要理解软件运行时正在做什么，哪些会引起软件失效。我所知道的最好的测试员已经具有这种直觉，知道什么能使软件失效，这种直觉引导他们彻底全面的思考测试场景、换句话说，他们知道隐错一般隐藏在什么地方，如何有效的找出这些隐错。

使测试员产生这种直觉的技术术语就是故障模型，因为故障模型提供了一个模型或框架，用来讨论代码中的故障是如何以及为什么能在软件执行时引起软件失效。对测试员来说，重要的是能够构造出准确的故障模型，并在测试过程中使用该模型，确保能检查出隐错最可能隐藏的地方。也就是说，故障模型可以用来选择测试，该测试最可能暴露嵌入的软件故障。

测试员需要学习和吸收的故障模型是基于与受测软件相关的两个问题。

首先，熟悉软件操作的环境，必须理解与应用程序通信的其他系统以及通信的具体方式，通常引起软件方面失效的原因是软件及其所在环境之间的误通信。

软件环境比起“运行于计算机上的软件”更为复杂。诚然，许多开发人员不能正确理解其编码运行的环境，他们相信了本不应相信的用户，当应进行数据确认时，他们却么有进行，他们从文件中读数据而没有对其内容的合法性进行调查，还有其他种种情况。作为测试员，捕获这些错误是其职责；要做到这点，相对于开发人员，必须能更好的理解软件环境。

其次，测试员必须理解其应用程序具有的能力。所有软件的存在都是为了向其用户提供某些功能和服务。测试员必须了解这些功能，并弄清用户如何输入才能保证软件能完成预定任务。软件输入的各种变化情况和软件运行结果行为的验证均属测试范围。

软件能力比从表面看起来要复杂一些。软件到底能做什么？哪些是用于建造软件的构造块？软件不仅仅只由谓语语句和赋值语句组成，如果能理解软件能力，就能更好，更全面的实施测试。

故障模型基于两个基本问题：软件环境和软件能力。

理解软件环境

软件在所处的环境中通过接受输入、产生输出与其用户进行通信。大多数软件系统的用户不一定是人，尽管这一点与测试新手的直觉不吻合。事实上，人们不能将输入直接提交给软件应用程序，而是利用硬件设备提交，输入由其设备驱动程序来进行处理。这些输入传给操作系统的应用编程接口层，直到API产生事件，表明测试中的应用程序已经接受到了，实际上，应用软件仅通过操作系统接受输入。

1.人类用户

对于软件来说，一般有两种界面：GUI和API

1）通过GUI控件提交输入

其中，对数据传送控件进行测试是个难题，因为在多数情况下，要使用单独的控件收集相关数据，所以测试员必须着重发现其中的关系，并对可能引起软件失效的相关数据进行测试。

另一个关键问题是使用GUI控件的次序。开发人员要确定用户运行软件时应遵循的固定次序——也就是说用户应在使用其他控件前使用的某些控件——并在假设用户会按此规则使用的前提下编写代码。

测试员必须确保开发人员使用了适当的假定，并保证由预定的输入序列软件不会轻易地由于改变调用次序而使之失效。

作为测试员，其职责是了解人类用户发出的事件和数据，并保证所有关心的情况都顺利通过了。

2）通过程序提交输入

一些应用程序公开其内部功能让其他程序能够调用，这样开发人员就变成了用户。在这种情况下，软件开发人员就能编程运行受测应用程序，对这样的软件进行测试意味着必须编程对受测软件进行调用，并改变所允许的参数和调用序列。测试员必须具备测试这种软

件的编程能力。

用于测试API的策略和用于测试GUI的策略非常相似。不同的是API测试员处理的是API调用和参数选择，而GUI测试员处理的是GUI控件和数据。唯一的差别是传送机制：测试API的是程序，测试GUI的是键盘。

对于两种界面，测试员都面临着同样的难题，一个根本问题就是由太多的输入、输入组合和输入次序，而且要全部应用。无论是将输入定义为GUI控件里的文本输入还是调用参数，都必须近乎无穷的选择一个具体的输入。

那么哪些输入是最重要的呢？必须选择用户最常用的输入。然而，人类用户都很难进行这样的预测，并且猜测了错误的用户抛面，其风险也很大。由于用户太多，以至于可以保证我们软件的客户将会用到软件的每个特性。我们遇到的决策难题是：测试什么，或者不测试什么而心存侥幸。

2.文件系统用户

几乎所有的软件都用到二进制或文本文件。对于测试员来说，文件就是用户，其内容就是输入。和已经讨论过的输入一样，文件内容可以是无效的。除了创建和处理他们的应用程序的限制外，文件，甚至是二进制文件，很容易更改。

作为测试员，其职责是理解受测软件处理的文件及文件格式。对相应的行为，测试员也必须能够用要求的内容组成文件来进行测试。

3.操作系统用户

操作系统是直接与应用程序交互的唯一实体。它是所有实际用户与应用程序之间的中介，通过提供内存、文件处理、堆空间等直接与应用程序交互，操作系统的这个部分就是内核。

系统界面的根本问题与人类用户的根本问题不同，系统输入是反应式的。换句话说，就是不能像用户那样，简单的只按键盘或单击鼠标。系统输入不能由测试员直接控制，而是由软件对用户输入做出反应。

4.软件用户

和操作系统用户一样，使用外部软件来存储数据，为一个应用程序执行不同的、各种各样的任务。

作为测试员，我们必须确保我门的应用程序能处理针对外部资源的预期行为，以及合理但非预期的行为。这就是说，必须考虑传送给应用程序的数据、外部资源的返回值和错误代码、资源的可能失效场景。当然因为处理的是软件，就能有把握的假定用户中有多个隐错与我们的应用程序相链接或相互通信的数据库，数学程序库和其他任何外部资源都可能产生失效。

环境也能影响我们的软件。磁盘可能满了，网络可能拥塞了，如果我们关注的是这种环境压力下的软件运行，就必须能在实验室里再建这些环境，而且不让我们的用户再对可能结果无知的情况下首次面对这种情况。

二、软件能力

尽管软件具有复杂性非常高声誉，但他还是只能完成四项基本任务。虽然这些任务本身很简单，但可以组合成一个软件系统来解决复杂的问题。这样组合后的软件可能相当复杂，