一种基于模型的软件测试方法

摘要

一种基于模型的软件测试方法，包括如下步骤：S1.分析被测试软件，确定测试对象和测试特征;S2.选择和构造UML模型；S3.对UML模型进行验证，确保UML模型的正确性；S4.通过深度优先搜索算法遍历UML模型，自动生成测试用例，根据语句覆盖准则、判定覆盖准则、条件覆盖准则及路径覆盖准则等充分性准则计算相关的覆盖率，完成对测试用例的评估；S5.根据待测程序和所述UML模型得到的测试用例生成测试脚本，自动执行所述测试脚本，并保存执行测试脚本得到的实际输出结果；S6.根据测试用例的实际输出与预期输出的比较，得出测试结果，再根据测试目标与预先设定好的停止准则，决定是否需要修改模型或修改待测程序。

说明书

技术领域

本发明涉及测试技术领域，具体来讲是一种基于模型的软件测试 方法。

背景技术

近几年来，随着计算机软硬件技术的迅猛发展，各种各样的软件 系统应运而生，社会各行各业对软件系统的依赖越来越强，软件系统 的规模越来越大，复杂性也越来越高，对软件系统的质量要求也显得 更为重要。软件测试和验证，是保证软件正确性和提高软件可靠性的 最基本、最重要的手段。为了尽量减少花费在软件产品测试上的时间 和精力，大量研究机构开始投入到软件测试方法与测试工具的研究上。 目前，软件测试领域中的一个关键的、同时也是极为困难的问题就是： 如何设计和生成有效的测试用例。

随着面向对象软件开发技术的广泛应用和软件测试自动化的要 求，基于模型的软件测试逐渐得到重视。目前，软件测试技术大体上 可分为两大类：一类是白盒测试技术，另一类是黑盒测试技术。

白盒测试技术是把程序看成装在一个白盒子里，即完全了解程序 的内部结构和处理过程，按照程序内部的逻辑结构，检验程序中的每 条通路是否都按照预定要求正确工作。白盒测试从考察程序的结构和 逻辑出发，验证所构造的程序是否符合设计要求，白盒测试包括逻辑 覆盖、域测试、符号测试、路径分析、程序插桩及程序变异等。

白盒测试技术的缺点在于，白盒测试只根据程序的内部结构进行 测试，而不考虑程序的外部特征，如果程序结构本身有问题，比如程 序逻辑有误或是有纰漏，就无法发现错误。另外，即使将程序中的每 条路径都测试了仍然可能有错误，原因在于：第一，穷举路径测试不 能查出程序违反了设计规范；第二，穷举路径测试不可能查出程序中 因纰漏路径而出现的错误；第三，穷举路径测试可能发现不了一些与 数据相关的错误。

黑盒测试技术，又称为功能测试技术，与白盒测试技术恰恰相反， 它把程序看成一个黑盒子，完全不用考虑程序的内部结构和处理过程。 黑盒测试是在程序接口进行的测试，它只检查程序功能是否按照预先 的要求正常工作，即接收输入数据是否产生正确的输出结果。黑盒测 试技术包括边界值分析技术、等价分类技术及因果图技术等。

黑盒测试技术的缺点在于，黑盒测试是一种穷举输入的测试方法， 不仅要穷举所有合法的输入，还要穷举那些不合法但是可能的输入进 行测试。但是根据软件测试的局限性，不太可能完全覆盖所有的输入 情况，测试代价太大。黑盒测试的研究重点在于如何从输入域中选择 适当数量的、对发现错误具有代表性的测试输入来有效的进行测试。

白盒测试方法是从开发者的角度在源代码级使用软件分析和理 解技术，对程序的内部逻辑结构进行分析来测试系统，而黑盒测试方 法通过从用户的角度测试软件系统是否符合需求规格，这两类方法各 有侧重，在测试的实践中是互补的。但它们又各有缺点，并且不能在 方法内部进行完善来解决，而且在面向对象语境下，软件的设计思路 和软件的结构，与传统的面向过程的软件相比有了很大的变化，而传 统的软件测试方法不能适应这样的变化。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种基于模 型的软件测试方法，通过UML（unified modeling language，统一 建模语言）模型图自动生成满足一定覆盖准则的测试用例，从而快速 有效的完成软件测试，适应软件的设计思路和软件的结构、与传统的 面向过程的软件之间的变化，弥补白盒测试和黑盒测试的不足。

为达到以上目的，本发明采取的技术方案，一种基于模型的软件 测试方法，其特征在于，包括如下步骤：

S1.分析被测试软件，根据测试目的，确定测试对象和测试特征；

S2.选择和构造UML模型，该UML模型表述了需求所表述的所有 可能行为；

S3.对UML模型进行验证，排查UML模型构造时可能出现的有界 性、安全性、死锁和状态可达性，确保UML模型的正确性；

S4.通过深度优先搜索算法遍历UML模型，自动生成测试用例， 根据充分性准则计算相关的覆盖率，完成对测试用例的评估；

S5.根据待测程序和所述UML模型得到的测试用例生成测试脚本， 自动执行所述测试脚本，并保存执行测试脚本得到的实际输出结果；

S6.根据测试用例的实际输出与预期输出的比较，得出测试结果， 再根据测试目标与预先设定好的停止准则，决定是否需要修改模型或 修改待测程序。

在上述技术方案的基础上，所述充分性准则包括：

基于控制流的充分性准则：语句覆盖准则、条件覆盖准则和判断 覆盖准则；

基于数据流的充分性准则：定义引用覆盖准则、上下文覆盖准则；

基于故障的充分性准则：弱变异覆盖准则、强变异覆盖准则。

在上述技术方案的基础上，所述覆盖率用来度量测试完整性和充 分性，其包括：逻辑覆盖、函数覆盖以及功能覆盖，其中逻辑覆盖包 括：语句覆盖、判定覆盖、条件覆盖以及路径覆盖。

在上述技术方案的基础上，所述S1中分析被测试软件包括：被 测试软件是面向对象的开发技术或者是面向过程的开发技术、被测试 软件所采用的开发语言、被测试软件开发的系统环境。

在上述技术方案的基础上，所述UML模型为机器可读的模型，用 于对被测试软件进行描述、可视化处理、构造和建立软件系统的文档。

在上述技术方案的基础上，所述S3中，对UML模型进行有界性、 安全性、死锁及状态可达性验证。

在上述技术方案的基础上，所述停止准则包括实际输出结果与测 试用例的预期输出结果相同，程序所具有的功能与UML模型所具有的 功能一致。

在上述技术方案的基础上，所述测试用例主要包括三部分：测试 场景、测试输入数据和预期输出序列，测试用例的生成方法主要针对 所述三部分相关信息的获取。

在上述技术方案的基础上，所述测试脚本为可以被自动化测试工 具执行的指令，所述测试脚本可以被创建，或使用测试自动化工具自 动生成，或用编程语言编程来完成，或通过创建、用测试自动化工具 自动生成及用编程语言编程共同完成。

在上述技术方案的基础上，所述测试脚本包括以下功能：

a.驱动程序执行，包括编译程序执行和运行程序执行；

b.检测程序的执行过程；

c.向程序传递所需的输入，并得到程序的执行输出。

本发明的有益效果在于：

1、本发明基于模型的软件测试方法，使得基于UML的用例生成 方法的流程更加规范，更加易于生成满足高覆盖要求的测试用例。

2.所述生成测试用例均是通过UML模型得到的，并且可以通过结 合待测程序自动执行测试，故而大大提高了测试的自动化水平。

3、在基于模型的软件测试中，测试用例的生成仅仅依赖于UML 模型，并不依赖于被测试的软件，因此测试用例的生成可以在软件开 发完成前进行。

4、系统的模型是根据系统功能需求构建的，所以通过模型生成 的测试用例可以直接覆盖系统的需求，减少测试用例的冗余。

5、当需求或者系统发生更改时，基于模型的软件测试只需要根 据改变后的模型重新生成测试用例，易于维护。

附图说明

图1为本发明实施例基于模型的软件测试方法流程图。

图2为本发明步骤S4流程图；

图3为本发明步骤S5流程图；

图4为本发明步骤S6流程图。

具体实施方式

以下结合附图及实施例对本发明作进一步详细说明。

如图1所示，本发明为一种基于模型的软件测试方法，所述方法 包括以下步骤：

S1：充分了解软件需求规范和设计文档、用户手册，了解被测系 统，根据测试目标确定被测组件及其功能特征。分析被测试软件，根 据测试目的，确定测试对象和测试特征；

S2：选择和构造UML模型，该UML模型表述了需求所表述的所有 可能行为；通过软件的系统特征和各个模型的特征，选择并建立合适 的模型作为测试用例生成的模型。

S3：模型验证：

基于形式化方法与可视化UML相结合的建模思想，设计一套从 UML模型到Promela模型的转换规则，开发由UML模型自动生成 Promela代码的转换工具。在转换工具中通过调用SPIN自动验证 Promela代码，来验证UML模型，排查模型构造时可能出现的问题， 以确保UML模型正确性。

S4：测试用例自动生成：具体请参考图2，测试用例主要包含了 测试场景、测试输入数据和预期输出序列这三部分内容，测试用例的 生成主要针对自动获取这三部分的相关信息。在生成测试用例时，我 们首先需要将由步骤S2、S3得到的UML模型转化为形式化模型，通 过深度优先搜索算法，得到所有的测试场景，再由测试人员根据软件 系统的需求在测试场景上添加输入数据等所需的信息，完成测试用例 的生成。

在生成测试用例的过程中，需要对于选择和循环等进行处理，找 出形式化模型上所有的路径，每条路径即是一个测试场景。

S5：请参考图3，测试用例自动执行：测试用例的自动执行是软 件测试自动化的关键步骤，以下为具体实施过程：

分析由S4得到的测试用例，若能从UML模型得到的测试用例中 得到输入数据和预期输出，则采用由UML模型得到的测试数据，否则 根据被测程序建立约束系统，然后通过随机法、静态法、动态法或者 试探法，求解约束系统，得到测试数据。

测试脚本生成：根据软件测试自动化系统的特点，编写一个脚 本生成工具。使用脚本生成工具，分析待测程序代码，提取各模块结 构信息，如类、函数（方法）、变量，提供简单的选择界面，便于用 户选择测试模块、输入数据、期望结果等，由脚本生成工具生成测试 脚本。

利用程序插桩技术，对待测程序进行插桩，以便在运行插桩后 程序的过程中，提取插桩信息，获得执行的路径信息和执行结果信息， 进而可以分析得到软件的结构。

执行上述测试脚本，以驱动插桩后的待测程序执行，获得并且 保存相关的执行路径信息和执行结果信息。

所述测试脚本的任务主要是：

a)驱动程序执行，包括编译和运行；

b)检测程序的执行过程；

c)向程序传递所需的输入，并得到程序的执行输出。

S6：请参考图4，比较测试结果：将实际结果与预期结果相比较， 若结果符合停止准则,测试执行结束；若结果不符合停止准则，则检 查模型是否有问题。若模型存在问题，则修改模型；若模型没有问 题，则修改程序。所述停止准则包括，实际输出结果与测试用例的 预期输出结果相同，程序所具有的功能与UML模型所具有的功能一 致。

本发明基于模型的软件测试方法，使得基于UML的用例生成方法 的流程更加规范，更加易于生成满足高覆盖要求的测试用例。生成测 试用例均是通过UML模型得到的，并且可以通过结合待测程序自动执 行测试，故而大大提高了测试的自动化水平。在基于模型的软件测试 中，测试用例的生成仅仅依赖于UML模型，并不依赖于被测试的软件， 因此测试用例的生成可以在软件开发完成前进行。系统的模型是根据 系统功能需求构建的，所以通过模型生成的测试用例可以直接覆盖系 统的需求，减少测试用例的冗余。当需求或者系统发生更改时，基于 模型的软件测试只需要根据改变后的模型重新生成测试用例，易于维 护。

本发明不局限于上述实施方式，对于本技术领域的普通技术人员 来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰， 这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细 描述的内容属于本领域专业技术人员公知的现有技术。