CN1464399A

CN1464399A - 一种对软件可测试需求的分析方法

Info

Publication number: CN1464399A
Application number: CN 02122967
Authority: CN
Inventors: 迟晓东; 马翔; 张凯帆; 龙纲
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2002-06-13
Filing date: 2002-06-13
Publication date: 2003-12-31
Anticipated expiration: 2022-06-13
Also published as: CN100476754C

Abstract

本发明涉及一种对产品软件可测试性需求的分析方法。一种对软件可测试需求的分析方法，其特征是按下列步骤进行：步骤一，将产品软件特性的开发需求列出来；步骤二，对每一条开发需求，从二个控制点、至少一个观察点来分析产品软件的特性，并列出这些控制点和观察点的内容。提测试需求时要考虑这些需求的实现能够方便执行测试和正确定位。该分析方法可应用于产品软件的功能特性或结构，提出一种可行的可测试性需求，从而为产品软件后期测试开发、执行，问题的隔离与定位带来方便。

Description

一种对软件可测试需求的分析方法

技术领域

本发明涉及一种对产品软件可测试性需求的分析方法。该分析方法可应用于产品软件的功能特性或结构，提出一种可行的可测试性需求，从而为产品软件后期测试开发、执行，问题的隔离与定位带来方便。

技术背景

可测试性需求是为方便测试而提出的需求，它一般要求被测对象提供一定的可观察性和可控制性以达到易于测试、易于发现问题和定位问题的目的。当前业界比较成熟的是硬件的可测试性，在IEEE等规范里都有如何提高硬件可测试性方面的内容。而对于软件的可测试性则还没有可供参考的成熟的技术。在实际的产品软件研发过程中，针对开发的一个功能特性，需要提出使得该功能特性易于测试的需求。

当前对产品软件进行可测试性需求分析所采用的方法是从产品硬件的可测试性需求查表的方法中借用来的，是根据经验将以往的可测试性需求收集、整理、分类，形成一个大的表格，使用时从中挑出与某产品具体特性相对应的可测试性需求作为该产品软件的可测试性需求。该方法仅仅是重用以前类似的经验，而软件是与应用相关的，它的需求、设计总是在变化而且很复杂，新特性、新结构和新的实现方法层出不穷。现有的分析方法无法回答为什么要这样选择可测试性需求，而且由此方法得出的软件可测试性需求依然存在着粒度不一、不够系统、可实现性差、容易遗漏等缺陷。

发明内容

本发明的目的在于对产品软件可测试性需求建立一个模型，该模型与软件的粒度、实现等无关，同时只需要一个简单可行的方法来适应各种各样复杂的软件特性的可测试性需求分析，可对任何类型的软件进行简单有效的分析，同时生成高质量的可测试性需求，而不能仅仅通过收集、整理、重用来替代分析过程。本发明克服了现有软件分析方法可实现性差、容易遗漏等缺陷。

本发明是这样实现的：一种对软件可测试需求的分析方法，按下列步骤进行：

(1)、将产品软件特性的开发需求列出来，该需求可以是一层需求，如X1需求、X2需求，也可以是多于二层的分解需求，如Y1需求、Y2需求，Y1子需求、Y2子需求，Y1孙需求、Y2孙需求，其中：Y1、Y2子需求和Y1、Y2孙需求是对上一层需求的进一步细化和分解；

(2)对步骤(1)提出的一条开发需求，根据测试需求从两个控制点和至少一个观察点来分析并得出可测试性需求；

(3)重复步骤(2)，直到所有开发需求都被分析完成为止。

上述的控制点分布在输入部分。

上述的观察点分布在软件系统的各个部分。

上述的二个控制点为输入控制点和预置条件控制点。

上述的观察点可以为输入、预置条件、操作、状态、消息/事件、错误、资源、性能和输出等。

其中：

输入指通过边界传递给内部行为处理的数据，如：调用参数、消息、事件等；

预置条件指的是初始条件，包括数据配置、环境配置等；

操作指通过一系列的分支、循环、并发处理和函数/方法/接口等调用，以实现某一功能的行为；

状态是指使用状态机模型实现某一功能的行为，例如：进程调度中的等待、就绪、执行等；

消息/事件指系统中的消息、事件等通讯机制；

错误指系统中的错误处理、异常处理等行为；

资源指对系统中各种资源进行操作、处理的行为，包括OS资源、自定义资源、数据库资源等；

性能指可以直接反映系统性能约束的各种软件行为，包括流量、性能统计等；

输出指内部处理后，透过边界传出的各种数据，包括消息、事件、返回值等。

本发明可应用于所有的软件系统，应用对象不随软件系统的大小、规模变化而变化；提出的可测试性需求质量高，可实现性好。

附图说明

图1为本发明一种对软件可测试需求的分析方法流程图；

图2为可测试性需求分析示意表；

图3为T-IBO模型示意图。

具体实施方式

建立模型。参见图3，在T-IBO模型中，观察点分布在软件系统的各个部分，而控制点在输入部分，即：控制点：输入和预置条件。观察点：输入、预置条件、行为(包括操作、状态、性能、资源、消息/事件、错误)、输出。

其中：

输入指通过边界传递给内部行为处理的数据。如：调用参数、消息、事件等。

边界指区分内部行为和外部输入数据、输出数据的逻辑分界线。

预置条件指的是象数据配置、环境配置这类的初始条件。

行为指软件系统的内部处理，按照处理类型可以分为：操作、状态、性能、资源、消息/事件和错误。

操作指通过一系列的分支、循环、并发处理和函数/方法/接口等调用，以实现某一功能的行为。如：对于一个四则运算，+-^*/()就是其中的操作，它们的执行顺序就是操作序列。一般将完成某一功能所需要的一些关键的逻辑步骤定义为操作。如打电话时：摘机、拨号、通话、挂机就是一个功能所具有的操作。

状态是指使用状态机模型实现某一功能的行为，例如进程调度中的等待、就绪、执行等；

性能直接反映系统性能约束的各种软件行为。如：流量、性能统计等。

资源指对系统中各种资源进行操作、处理的行为。包括OS资源、自定义资源、数据库资源等等。

消息/事件指系统中的消息、事件等通讯机制。

错误指系统中的错误处理、异常处理等行为。

由于不能通过直接修改软件内部行为来提高可测试性，即不允许直接控制被测试对象的内部行为，这就要求被测软件遵循DFT(Design For Testability)设计，所有需要设置的预置条件，如全局变量、系统配置等(这些都属于预置条件)，能够通过一个接口，从外部方便的修改、设置，即模型中的预置条件控制点。

本发明的一个实施例是建立一个可测试的输入—行为—输出模型(即Testable Input-Behavior-Output，简称T-IBO)，该模型将软件的行为继续划分成了操作、状态等6种属性，同时在整个T-IBO模型中明确了九个观察点和二个控制点。然后对每一条开发需求进行分析，每条需求包括上述九个观察点和二个控制点。从测试的角度，考虑对每条开发需求测试时是否需要这些观察和控制，以方便执行测试和定位。

对于一个软件系统、子系统、功能、特性、模块等，都可以使用T-IBO模型来分析可测试性需求。

一种对软件可测试需求的分析方法，参见图1、图2，其中分析方法的流程图见图1，分析步骤见图2。

步骤一，对开发需求进行分析。需求的层次可以多于2层，如：XX需求，XX子需求，XX子子需求等；也可以只有一层需求，如：X1需求，X2需求。

一条开发需求可以分为多条子需求，这些子需求是对父需求的进一步细化和分解。图2表中第一行的内容指的是应从哪些方面来提可测试性需求，共有：输入控制、预置条件控制、输入观察、预置条件观察、操作观察、状态观察、消息/事件观察、错误观察、资源观察、性能观察和输出观察等11个点。这11个点全部来自于T-IBO模型，因此，交叉矩阵分析的核心就是利用T-IBO模型对软件的一个可测试性分解来提出可测试性需求。

步骤二，在图2表中对于每一个开发需求、子需求分别从测试角度来考虑，需要在输入控制、预置条件控制、输入观察、预置条件观察、操作观察、状态观察、消息/事件观察、错误观察、资源观察、性能观察和输出观察等方面提出需求并使测试过程中这些内容可观和可控。即逐个分析其中的9个观察点应该观察些什么内容，2个控制点上应该控制些什么内容。

实施例：假设一个开发需求是这样描述：

需求名：打电话

输入：电话号码

处理：根据电话号码，完成：号码分析、号码接续、语音通道建立、振铃。其中，号码分析时可能出现空号的错误情况，号码接续时可能出现被叫占线的错误情况。对性能的要求是希望从电话号码输入到振铃，整个过程不超过5秒钟。整个过程中时需要使用号码表和语音表这两个资源。

输出：振铃音(忙、接通)或语音(空号)。

一种对软件可测试需求的分析方法过程如下：

1、根据开发需求的描述，从给出的11个可测试性方面提出可测试性需求。提需求时要考虑到这些需求的实现能够方便执行测试。

说明事项：

1)这里记录的可测试性需求指明了测试开发的功能时所需要提供的观察点和控制点，以及这些点上需要观察和控制的内容。也就是说，例如，在“打电话”的输入控制处有一条需求，“能控制输入的电话号码”。那么在编码实现“打电话”需求时，就要在输入处设立一个控制点；通过这个控制点，可以方便的从键盘输入电话号码。

2)如果有特殊的观察、控制要求一定要写清楚。如：对某资源需要能够按单个用户统计，或者按IP地址、端口号统计等。这些要求一定要写清楚，才能得到实现。(这根本不是技术内容)

2、从根据11个可测试性方面提出的可测试性需求来分析产品软件的特性。

Claims

1.一种对软件可测试需求的分析方法，其特征在于所述方法按下列步骤进行：

(1)列出产品软件特性的至少一个开发需求；

(3)重复步骤(2)，直到所有开发需求都被分析完成为止。

2.根据权利要求1所述的一种对软件可测试需求的分析方法，其特征在于所述的开发需求可以是多个多层需求，如Y1需求、Y2需求，Y1子需求、Y2子需求，Y1孙需求、Y2孙需求，其中：Y1、Y2子需求和Y1、Y2孙需求是对上一层需求的进一步细化和分解。

3、根据权利要求1所述的一种对软件可测试需求的分析方法，其特征在于所述的控制点分布在输入部分。

4、根据权利要求1所述的一种对软件可测试需求的分析方法，其特征在于所述的观察点分布在软件系统的各个部分。

5.根据权利要求1所述的一种对软件可测试需求的分析方法，其特征在于所述的二个控制点为输入控制点和预置条件控制点。

6.根据权利要求1所述的一种对软件可测试需求的分析方法，其特征在于所述的观察点可以为输入、预置条件、操作、状态、消息/事件、错误、资源、性能和输出等。

7、根据权利要求6所述的一种对软件可测试需求的分析方法，其特征在于所述的输入指通过边界传递给内部行为处理的数据，包括调用参数、消息、事件等；预置条件指的是初始条件，包括数据配置、环境配置等；操作指通过一系列的分支、循环、并发处理和函数/方法/接口等调用，以实现某一功能的行为；

状态是指使用状态机模型实现某一功能的行为，例如进程调度中的等待、就绪、执行等；消息/事件指系统中的消息、事件等通讯机制；错误指系统中的错误处理、异常处理等行为；资源指对系统中各种资源进行操作、处理的行为，包括OS资源、自定义资源、数据库资源等；性能指可以直接反映系统性能约束的各种软件行为，包括流量、性能统计等；输出指内部处理后，透过边界传出的各种数据，包括消息、事件、返回值等。