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

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

【技术实现步骤摘要】

本专利技术涉及一种对产品软件可测试性需求的分析方法。该分析方法可应用于产品软件的功能特性或结构，提出一种可行的可测试性需求，从而为产品软件后期测试开发、执行，问题的隔离与定位带来方便。当前对产品软件进行可测试性需求分析所采用的方法是从产品硬件的可测试性需求查表的方法中借用来的，是根据经验将以往的可测试性需求收集、整理、分类，形成一个大的表格，使用时从中挑出与某产品具体特性相对应的可测试性需求作为该产品软件的可测试性需求。该方法仅仅是重用以前类似的经验，而软件是与应用相关的，它的需求、设计总是在变化而且很复杂，新特性、新结构和新的实现方法层出不穷。现有的分析方法无法回答为什么要这样选择可测试性需求，而且由此方法得出的软件可测试性需求依然存在着粒度不一、不够系统、可实现性差、容易遗漏等缺陷。本专利技术是这样实现的，按下列步骤进行(1)、将产品软件特性的开发需求列出来，该需求可以是一层需求，如X1需求、X2需求，也可以是多于二层的分解需求，如Y1需求、Y2需求，Y1子需求、Y2子需求，Y1孙需求、Y2孙需求，其中Y1、Y2子需求和Y1、Y2孙需求是对上一层需求的进一步细化和分解；(2)对步骤(1)提出的一条开发需求，根据测试需求从两个控制点和至少一个观察点来分析并得出可测试性需求；(3)重复步骤(2)，直到所有开发需求都被分析完成为止。上述的控制点分布在输入部分。上述的观察点分布在软件系统的各个部分。上述的二个控制点为输入控制点和预置条件控制点。上述的观察点可以为输入、预置条件、操作、状态、消息/事件、错误、资源、性能和输出等。其中输入指通过边界传递给内部行为处理的数据，如调用参数、消息、事件等；预置条件指的是初始条件，包括数据配置、环境配置等；操作指通过一系列的分支、循环、并发处理和函数/方法/接口等调用，以实现某一功能的行为；状态是指使用状态机模型实现某一功能的行为，例如进程调度中的等待、就绪、执行等；消息/事件指系统中的消息、事件等通讯机制；错误指系统中的错误处理、异常处理等行为；资源指对系统中各种资源进行操作、处理的行为，包括OS资源、自定义资源、数据库资源等；性能指可以直接反映系统性能约束的各种软件行为，包括流量、性能统计等；输出指内部处理后，透过边界传出的各种数据，包括消息、事件、返回值等。本专利技术可应用于所有的软件系统，应用对象不随软件系统的大小、规模变化而变化；提出的可测试性需求质量高，可实现性好。具体实施例方式建立模型。参见图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个可测试性方面提出的可测试性需求来分析产品软件的特性。权利要求1.，其特征在于所述方法按下列步骤进行(1)列出产品软件特性的至少一个开发需求；(2)对步骤(1)提出的一条本文档来自技高网...

【技术保护点】
一种对软件可测试需求的分析方法，其特征在于所述方法按下列步骤进行：（１）列出产品软件特性的至少一个开发需求；（２）对步骤（１）提出的一条开发需求，根据测试需求从两个控制点和至少一个观察点来分析并得出可测试性需求；（３）重复步骤（ ２），直到所有开发需求都被分析完成为止。

【技术特征摘要】

【专利技术属性】
技术研发人员：迟晓东，马翔，张凯帆，龙纲，
申请(专利权)人：华为技术有限公司，
类型：发明
国别省市：94[中国|深圳]