为可测性而设计

 

为可测性而设计

原文：Design for Testability - Bret Pettichord

 

摘要

本文提供若干实用的建议，帮助项目组开发出可测性更强的软件产品。

本文对可测性（Testability）的定义为可见性和可控制性。可见性是我们能观察被测软件的状态、输出、资源利用和其它影响的程度；可控制性是我们能向被测软件输入或把它设置到某个特定状态的程度。

 

可见性基础

可见性的基本方面是能访问代码、设计文档和更改记录。这些是对大部分可测性进行改进的前提条件。

测试人员需要知道如何阅读代码，以及如何理解设计模型所采用的语言。在测试人员能提出测试接口、错误注入钩子或其它可测性特性之前，他们需要对系统设计有基本的理解。

可测性的改进需要测试人员和开发人员都使用共同的语言。

 

详细的输出

很多程序都有详细输出模式，这是可测性的很好的例子，它让人可以看到软件运转的细节。Unix的Mail程序就是其中一个例子：

 

mail -v bret@pettichord.com

Subject: testability example

Sample text.

.

Cc:

bret@pettichord.com... Connecting to mx.io.com. via relay... 220-deliverator.io.com

ESMTP Sendmail 8.9.3/8.9.3; Fri, 12 Jan 2001 15:34:36 -00 220 Welcome to

Illuminati Online, Fnord!

>>> EHLO eris.io.com

250-deliverator.io.com Hello IDENT:wazmo@eris.io.com [199.170.88.11], pleased tu

250-8BITMIME

250-SIZE 5000000

250-DSN

250-ONEX

250-ETRN

250-XUSR

250 HELP

>>> MAIL From: <wazmo@eris.io.com> SIZE=67

250 <wazmo@eris.io.com>... Sender ok

>>> RCPT To: <bret@pettichord.com>

250 <bret@pettichord.com>... Recipient ok

>>> DATA

354 Enter mail, end with “.” on a line by itself

>>> .

250 PAA07752 Message accepted for delivery bret@pettichord.com... Sent (PAA07752

Message accepted for delivery) Closing connection to mx.io.com.

>>> QUIT

221 deliverator.io.com closing connection

 

 

这些详细的输出信息可以帮助测试人员了解客户端和服务器端之间的通讯过程，从而帮助设计出测试用例来测试服务器的错误处理能力。同时这些信息可以帮助暴露问题出现的地方。

 

日志

详细的输出信息是记录软件事件的其中一种技术。日志可以帮助测试人员更容易理解软件的运转情况。也可以帮助发现一些容易忽略的bug。当bug出现，日志可以帮助定位到错误的代码和帮助调试。

 

诊断、监视和错误注入

断言是一种普遍的诊断。断言是使程序对处理的输入的假设更加清晰明确的额外代码行。当断言被违反了（假设不成立），错误或异常就自动出现。所以断言被违反就意味着bug。

如果没有断言，你可能不会注意到bug已经发生，因为内部数据可能已经被破坏，但是只有当进一步的测试访问到这些数据时才出错。断言也可以帮助定位错误出现的代码位置。

 

查找内存泄漏问题的有效的方法是监视内存使用。有很多工具可以做到这点。如果能监视内部内存设置会使测试更容易。例如在Netscape输入“about:config”能把所有设置输出。对于于配置问题的追踪会有很大帮助，尤其是某些问题只是在特定的机器才会出现。

 

有时候测试人员需要访问内部数据。“测试点”可以让测试人员在系统的某个点检查数据或插入数据。这种方法对于数据流应用程序特别有用。

错误注入特性可以帮助测试错误处理代码。有很多环境错误是很难让它出现，特别是以可预见、可重复的方式出现的。例如：磁盘满、坏介质、断网等。错误注入技术就是加入钩子用于注入这些错误并触发软件的错误处理代码。

 

另外一种错误注入的方法是使用工具HEAT或Holodeck，它们扮演的是程序和操作系统之间的中介者角色。由于它所处的位置，所以它可以控制操作系统给程序提供的各种服务，包括内存、磁盘空间、网络等，从而触发各种环境问题，看程序的处理能力如何。

 

测试接口

手工测试比较容易使用GUI接口。自动化测试则使用编程接口容易些。

Excel的早期版本包含一个测试接口。因为数学计算的准确性是一个关键的需求，所以能用自动化的方式频繁地运行测试变得非常重要。后来Excel的测试接口公开给用户，我们现在都可以通过VB来访问。

 

用户接口可测性

GUI自动化测试工具面临的一个普遍问题是个性化控件。个性化控件是指那些不被GUI测试工具所识别的控件。

评估和确保软件产品在指定的GUI测试工具下的可测性的过程如下：

1、 尽早测试GUI测试工具和开发工具的兼容性

2、 定义用户界面元素的命名标准

3、 查找个性化控件。如果有，计划提供可测性支持

A、确保工具可以用名称、类型和位置识别控件对象

B、确保控件使用的名字是唯一的。否则如果多个窗体或控件使用相同的标识可能导致工具识别不出来

C、确保工具可以检查控件的内容。能访问文本框的文本。能确认某个check box是否选中

D、确保工具可以控制控件。能点按钮。能选择需要的菜单项

 

通常需要反复试验才能找到操作个性化控件的方法和技巧，例如：

1、 键盘操作

2、 初始化控件

3、 鼠标事件

4、 字符识别

5、 Clipboard访问

6、 外部访问

 

结论：可测性选择

自动化需要可测性。

成功的自动化需要关注可测性。

编程接口比用户接口提供更高效率的自动化测试支持。

 

结论：让可测性发生

测试人员必须认识到可测性需要他们清楚了解软件设计，评审现有的设计文档和阅读代码。

测试人员通常因为害怕他们的请求会被拒绝而不愿意要求可测性。但是通常会发现，请求的可测性实际上已经在某些地方存在或者由于其他原因已经计划要做。