软件测试实用指南

第1章指导软件测试的故障模型软件测试的目的好的测试员具有一种直觉，这种直觉引导他们彻底全面地思考测试场景。

使测试员产生这种直觉的技术术语就是故障模型，因为故障模型提供了一个模型或框架，用来讨论代码中的故障是如何以及为什么能在软件执行时引起软件失效。

对于测试员来说，重要的是能够构造出一个准确的故障模型，并在测试过程中使用该模型，确保能检查出隐错最可能隐藏的地方。

人们处于不同的动机去进行软件测试，其中绝大多数动机都可用一个名称来描述。

想要通过测试确定所在机构是否应该接受某个产品，这种测试成为符合型测试；想要通过测试确定某个产品是否易于使用，这种测试成为可用性测试。

这样列举下去，还会包括性能测试，可靠性测试，健壮性测试等等。

诸多种类的测试具有一些共同特性：每种测试都需要测试员按照产品行为描述来实施。

产品行为描述可以是书面的规格说明书、需求文档、产品文件或用户手册。

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

每种测试都要求以系统方法展示产品功能性，说明测试结果是肯定的还是否定的，以及是否课判断其中的区别。

真正区分失效测试和成功测试的关键在于：必须知道在寻找什么，并能说出何时找到了。

每种测试都包括上述特性，主要差别在于其目的和一些细节处理上的差别。

总之，抛开这些细节和目的不谈，软件测试需要以系统和智能的方式运行和展示产品的功能。

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

优秀的测试员不能依靠运气，而是必须为所测试的软件设定清晰、明确、可实现的目标以及所有错误纠正后的下一个测试目标。

有效测试的特点就是设定这样的目标，并进行系统的开发，直至目标达到。

理解软件行为开发具有影响力的软件是相当困难的，一旦投入使用环境，软件常常会失效。

开发人员必须找出能减少编程出错倾向的方法，测试员页必须把重点放在寻找测试方法上，通过测试说明软件能无效的完成它应该完成的功能。

让测试员深感遗憾的是，测试时有太多的输入，输入变量、输入组合以及软件状态。

还有一些功能必须保持未测状态。

测试的难题是选择哪些要进行测试以及哪些不需要测试。

要有效的完成这些关键的决策过程，测试员需要理解软件运行时正在做什么，哪些会引起软件失效。

我所知道的最好的测试员已经具有这种直觉，知道什么能使软件失效，这种直觉引导他们彻底全面的思考测试场景、换句话说，他们知道隐错一般隐藏在什么地方，如何有效的找出这些隐错。

使测试员产生这种直觉的技术术语就是故障模型，因为故障模型提供了一个模型或框架，用来讨论代码中的故障是如何以及为什么能在软件执行时引起软件失效。

对测试员来说，重要的是能够构造出准确的故障模型，并在测试过程中使用该模型，确保能检查出隐错最可能隐藏的地方。

也就是说，故障模型可以用来选择测试，该测试最可能暴露嵌入的软件故障。

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

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

软件环境比起“运行于计算机上的软件”更为复杂。

诚然，许多开发人员不能正确理解其编码运行的环境，他们相信了本不应相信的用户，当应进行数据确认时，他们却么有进行，他们从文件中读数据而没有对其内容的合法性进行调查，还有其他种种情况。

作为测试员，捕获这些错误是其职责；要做到这点，相对于开发人员，必须能更好的理解软件环境。

其次，测试员必须理解其应用程序具有的能力。

所有软件的存在都是为了向其用户提供某些功能和服务。

测试员必须了解这些功能，并弄清用户如何输入才能保证软件能完成预定任务。

软件输入的各种变化情况和软件运行结果行为的验证均属测试范围。

软件能力比从表面看起来要复杂一些。

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

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

理解软件环境软件在所处的环境中通过接受输入、产生输出与其用户进行通信。

大多数软件系统的用户不一定是人，尽管这一点与测试新手的直觉不吻合。

事实上，人们不能将输入直接提交给软件应用程序，而是利用硬件设备提交，输入由其设备驱动程序来进行处理。

这些输入传给操作系统的应用编程接口层，直到API产生事件，表明测试中的应用程序已经接受到了，实际上，应用软件仅通过操作系统接受输入。

1.人类用户对于软件来说，一般有两种界面：GUI和API1）通过GUI控件提交输入其中，对数据传送控件进行测试是个难题，因为在多数情况下，要使用单独的控件收集相关数据，所以测试员必须着重发现其中的关系，并对可能引起软件失效的相关数据进行测试。

另一个关键问题是使用GUI控件的次序。

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

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

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

2）通过程序提交输入一些应用程序公开其内部功能让其他程序能够调用，这样开发人员就变成了用户。

在这种情况下，软件开发人员就能编程运行受测应用程序，对这样的软件进行测试意味着必须编程对受测软件进行调用，并改变所允许的参数和调用序列。

测试员必须具备测试这种软件的编程能力。

用于测试API的策略和用于测试GUI的策略非常相似。

不同的是API测试员处理的是API调用和参数选择，而GUI测试员处理的是GUI控件和数据。

唯一的差别是传送机制：测试API的是程序，测试GUI的是键盘。

对于两种界面，测试员都面临着同样的难题，一个根本问题就是由太多的输入、输入组合和输入次序，而且要全部应用。

无论是将输入定义为GUI控件里的文本输入还是调用参数，都必须近乎无穷的选择一个具体的输入。

那么哪些输入是最重要的呢？必须选择用户最常用的输入。

然而，人类用户都很难进行这样的预测，并且猜测了错误的用户抛面，其风险也很大。

由于用户太多，以至于可以保证我们软件的客户将会用到软件的每个特性。

我们遇到的决策难题是：测试什么，或者不测试什么而心存侥幸。

2.文件系统用户几乎所有的软件都用到二进制或文本文件。

对于测试员来说，文件就是用户，其内容就是输入。

和已经讨论过的输入一样，文件内容可以是无效的。

除了创建和处理他们的应用程序的限制外，文件，甚至是二进制文件，很容易更改。

作为测试员，其职责是理解受测软件处理的文件及文件格式。

对相应的行为，测试员也必须能够用要求的内容组成文件来进行测试。

3.操作系统用户操作系统是直接与应用程序交互的唯一实体。

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

系统界面的根本问题与人类用户的根本问题不同，系统输入是反应式的。

换句话说，就是不能像用户那样，简单的只按键盘或单击鼠标。

系统输入不能由测试员直接控制，而是由软件对用户输入做出反应。

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

作为测试员，我们必须确保我门的应用程序能处理针对外部资源的预期行为，以及合理但非预期的行为。

这就是说，必须考虑传送给应用程序的数据、外部资源的返回值和错误代码、资源的可能失效场景。

当然因为处理的是软件，就能有把握的假定用户中有多个隐错与我们的应用程序相链接或相互通信的数据库，数学程序库和其他任何外部资源都可能产生失效。

环境也能影响我们的软件。

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

二、软件能力尽管软件具有复杂性非常高声誉，但他还是只能完成四项基本任务。

虽然这些任务本身很简单，但可以组合成一个软件系统来解决复杂的问题。

这样组合后的软件可能相当复杂，很难测试。

试图在大量正面测试中整体面对这些复杂性，收效甚微，并产生大量徒劳的工作。

测试员通过规划如何测试不可测试的软件即可掌握主动。

重点强调基本软件能力常被证明为非常有效。

这就是自由式测试的精髓；所有软件均具有的四种基本能力为：1）软件从其环境中接受输入2）软件生成输出，并将输出提交给它的环境3）软件内部以一种或多种数据结构形式存储数据4）软件使用输入和存储的数据执行计算指导测试员的故障模型很简单：如果软件在实施上述四个任务之一时出错，就说明软件失效。

借助输入和输出进行测试，传统上称为黑盒测试，因为设计攻击时不需要看见内部实现的细节。

数据和计算攻击通常归入白盒测试范畴。

因为部署这种攻击需要内部知识，但却不需要有关源代码的实现知识。

相反，我们要仔细检查GUI，大胆猜测其具体实现，以设计成功高校的攻击。

1.测试输入软件应该只接受它能处理的输入。

错误和非法输入必须由软件使用的界面或由嵌入在软件中的其他错误检查代码滤去。

软件也应该指导，一旦得到输入后应该做什么。

特别需要了解对哪些输入组合不能进行处理，即使每个输入值也许都是正确的。

我们的职责是测试软件能否防止接收无效值，并测试有效输入的非法组合迷惑该软件。

这是一项工作量很大的工作。

如果我们忽视了一个值，很可能就是迫使应用程序产生失效的值。

然而，问题是：有这么多可能的输入值，这些值的组合数几乎总是超出我们的测试资源。

2.测试输出与输入问题类似的是软件输出问题。

软件必须只能产生用户能接受的输出。

如果软件进行了API调用，就必须严格的规范调用格式，并只使用可能接受范围的参数。

如果我们的软件在输出设备上向人类用户显示数据，则数据必须在已定义的显示范围内，必要时，必须刷新屏幕。

输出不仅在格式和数量上应该是正确的，而且在逻辑上也应该是正确的。

测试员还有相当困难的工作。

我们必须对问题非常熟悉，以便能列举错误回答，并尽力保证不产生这样的错误回答。

3.测试数据软件能以一种或多种数据结构形式内部存储输入或计算结果。

可在计算或输出生成的使用中检索这些数据。

如果软件存储了无效数据，软件就自认为失败。

有关数据的主要测试问题在许多方面与输入类似。

单个数据值必须可接收，而且必须与受测应用程序存储的其他数据能够互相融合。

这样，许多为输入设计的测试用来测试存储数据也有效。

然而，存储数据特性是持久性的，他不仅可以进行存储，而且可以进行检索和修改。

因为软件系统庞大而复杂，许多内部程序通常都能修改特定的数据结构。

如果这些程序对数据可接收取值范围的规则不同或对这些值使用不同的修改，软件就会失效。

测试员的职责就是针对数据结构进行输入-往里增加、从中获取、将其上溢，将其下溢，并做一些操作，搅乱数据结构，从而使系统失效。