CN105550110A - 软件图形用户人机接口测试用例的自动生成方法 - Google Patents

Abstract

本发明涉及软件图形用户人机接口测试用例的自动生成方法，属于软件的检验检测技术领域。其解决了现有书写测试用例方法存在的费时费力费钱问题。本发明提出了“条件-行动-预期结果”概念，包括以下步骤：规定计算的路径起点为系统启动；终点为系统退出；收集待测软件行为规格规定形成集合；选择集合中一个“条件-行动-预期结果”；找出从起点到此的路径；找出从此到终点的路径；运算结果连接起来，就得到一个覆盖此“条件-行动-预期结果”的测试用例；剔除已产生的和已经用过的，直到得出一个最小的并且准确覆盖所有的测试用例集合。本发明具有维护和更新成本低、人员开支少、规避风险能力强等优点，可广泛运用于软件的检验检测场合。

Description

软件图形用户人机接口测试用例的自动生成方法

技术领域

本发明涉及软件图形用户人机接口测试用例的自动生成方法，属于软件的检验检测技术领域。

背景技术

软件测试是软件开发必不可少的环节，而软件测试过程的主要技术内容就是书写软件测试用例，然后按照测试用例来操作被测程序，评估软件质量并发现软件缺陷。

目前的软件测试工业领域的创新多集中在软件测试用例的自动化方法，既把测试用例转化成程序，然后让软件代替人工来执行测试用例。而测试用例本身，尤其是图形用户接口(GUI)的测试用例准备还是人工书写。比如：某用户登录测试用例：第一步：启动程序，程序用户登录对话框出现；第二步：在用户名编辑框内输入有效用户名；第三步：在密码框内输入此用户名的正确密码；第四步：点击登录按钮；第五步：查看预期结果。用户应当顺利登陆网站。很多人几个月的努力来准备这些用例在现在软件领域是很正常的。可以想象，准备成百上千这样的测试用例会多么费时费力费钱。

另外在学术领域，有很多研究集中在软件测试用例方面，但他们的研究都使用数理逻辑和数学来书写软件规格规定，然后由此通过逻辑来论证程序。这根本上就是用一种计算机语言写软件规格规定，然后用它来论证用JAVA、C书写的程序的正确性。由于规格规定语言本身和程序语言本身一样复杂，甚至更复杂难懂，现实中，这些研究成果很难被应用到实际软件开发中。软件统一建模语言(UML)，算是最实用的软件抽象模型语言，在描述软件行为中被广泛应用。但UML是针对软件开发设计的，它对软件测试用例帮助不大。这就是为什么UML在测试领域中，尤其是人机接口(GUI)测试很少被用到。这些都导致了现在书写软件测试用例的方法落后。

从测试角度看软件开发，有两个问题：第一，因为时间和任务的挤压，软件需求以及设计文档很难及时更新，没有足够的动力和资源，测试人员和开发人员，尤其是人员流动大时，会造成知识流失，应对此问题的培训费用就会增加。第二，测试用例，尤其是在数量达到成百上千以后，当待测软件设计改变时，很难维护。而且由于没有结构，测试用例质量很难把握。

发明内容

本发明的目的在于克服现有书写软件测试用例的方法存在的上述缺陷，提出了一种软件图形用户人机接口测试用例的自动生成方法，通过软件测试用例的自动化生成，可以提高生产力、加速软件开发速度并降低软件测试成本。

本发明是采用以下的技术方案实现的：一种软件图形用户人机接口测试用例的自动生成方法，包括如下步骤：

第一步：规定计算的路径起点为系统启动；

第二步：终点为系统退出；

第三步：收集待测软件行为规格规定所有“条件-行动-预期结果”形成集合；

第四步：选择集合中一个“条件-行动-预期结果”；

第五步：找出从起点到此“条件-行动-预期结果”的路径；

第六步：找出从此“条件-行动-预期结果”到终点的路径；

第七步：把第四步和第五步的运算结果连接起来，就得到一个覆盖此“条件-行动-预期结果”的测试用例；

第八步：在集合里，剔除已产生的测试用例和已经用过的“条件-行动-预期结果”；

第九步：在缩小的集合里，选择一个“条件-行动-预期结果”，重复第五步和第六步，直到得出一个最小的并且准确覆盖所有“条件-行动-预期结果”的测试用例集合。

进一步地，第三步中，待测软件行为规格规定的步骤包括条件、行动和预期结果。

进一步地，第三步中，“条件-行动-预期结果”实际是软件测试用例步骤构成基本元素。

进一步地，实际测试用例的每一步骤都是待测软件行为规格规定中“条件-行动-预期结果”的一个选择排序。

进一步地，第五步和第六步中的路径采用单源路径算法。

进一步地，第五步和第六步中的路径中的每一条路径就是一个在输入值等价类基础上建立的测试用例。

本发明的有益效果是：

(1)本发明只要维护一份软件行为规格规定文档，便于及时维护和更新软件；

(2)本发明软件行为规格规定的书写维护需要的时间和人力远小于大量测试人员书写维护测试用例的需要的时间人力，为企业降低人员成本；

(3)本发明使软件行为规格规定的产生容易，在早期设计时找出缺陷并将其解决，规避风险能力强；

(4)本发明产生的测试用例质量高，省去了因待测软件设计改变而带来的测试用例维护成本。

附图说明

图1是本发明的原理框图。

图2是本发明的“条件-行动-预期结果”状态变化图。

具体实施方式

下面结合附图对本发明作进一步说明。

实施例一：

如图1所示，本发明所述的软件图形用户人机接口测试用例的自动生成方法，包括如下步骤：

第一步：规定计算的路径起点为系统启动；

第二步：终点为系统退出；

第三步：收集待测软件行为规格规定所有“条件-行动-预期结果”形成集合；

第四步：选择集合中一个“条件-行动-预期结果”；

第五步：找出从起点到此“条件-行动-预期结果”的路径；

第六步：找出从此“条件-行动-预期结果”到终点的路径；

第七步：把第四步和第五步的运算结果连接起来，就得到一个覆盖此“条件-行动-预期结果”的测试用例；

第八步：在集合里，剔除已产生的测试用例和已经用过的“条件-行动-预期结果”；

第九步：在缩小的集合里，选择一个“条件-行动-预期结果”，重复第五步和第六步，直到得出一个最小的并且准确覆盖所有“条件-行动-预期结果”的测试用例集合。

本发明的原理在于软件行为规格和测试用例二合一。

实施例二：

下面以图形用户接口(GUI)测试用例的自动生成为例对本发明的原理进行解释。

现有技术人员困扰的问题的实质是：要么集中在纯理论探讨，复杂无比；要么就在微软Word或类似工具里一条条地书写测试用例步骤，而忘记了考察两者的中间地带。

其实可以在应用日常语言描述测试步骤的同时，在软件行为规格规定中加入面向对象式结构。这结构具有普适性，而可以利用这个结构，借助软件的运算能力，实现测试用例的自动生成。

用户图形人机接口(GUI)都是由一系列控件组成，包括编辑框、视窗、按钮等等。在编程中，需要按照面向对象利用很多概念：对象、类、封装、继承、多态等等，而且要用语言写出，并能让能执行，所以，复杂程度高。

但让测试人员执行的测试用例不同，它们只要描述清步骤，让测试员看懂就行。所以大大简化，主要只用三个概念：

对象--用来代表待测软件，图形人机接口控件，包括系统内部模块、环境等等。

行动--用来描述图形人机接口引起软件变化的鼠标点击、键盘输入、事件，以及在日常语言层面的行动描述，如登录、文件存储等等。

变量--用来描述控件属性，如编辑框数据内容形式，视窗是否打开等等。在编程中，变量可以是一个整数，一个对象，各种数据类型，很复杂。但在描述待测软件行为，产生测试用例中，只用字符串，就像写文章，让字符串的语义来代表变量内容。

在软件开发初期，把需要考虑的软件行为规格规定。第一步，找出所有要考虑的对象；第二步，对每一个对象，确定需要考虑的变量；第三步，对每个变量，定义值域等价类(有现成方法，所有软件测试教材里都有)；第四步，对每一个对象，确定需要考虑的行动；第五步，对每个行动，定义行动的条件，预期结果；第六步，对每一个行动条件，规定在此预期结果下，下一步所允许的行动以及条件(一般会有多个)。

下一步行动条件虽然可以有很多但通常很简单，不是所有控件都可以，就是只有少数行或不行。如果用手标示，会很麻烦。但这由软件来实现就很简单。比如，选择下一个视窗所有行动，然后去掉几个不允许的行动条件即可，或反过来。

至此，就完成了待测软件行为规格规定(BehaviorSpecification)。

行动的细节，在下面表一中展示：

表一

软件测试用例步骤构成基本元素实际是“条件-行动-预期结果”。而在软件行为规格规定中又定义了下一步行动及条件作为各个“条件-行动-预期结果”链接。实际测试用例的每一步骤都是待测软件行为规格规定中“条件-行动-预期结果”的一个选择排序。这样，就把待测软件以“条件-行动-预期结果”为基础的状态变化图做了出来，如图2所示。

实施例三：

如图2所示，本发明的“条件-行动-预期结果”状态变化图，实际和百度地图一样，可以把每一个“条件-行动-预期结果”当作是一个城市名，而下一步行动的连接就像地图里连接城市的道路，有单行线，双行线，环路。就可以利用图论中各种路径算法(比如Dijkstra路径算法)，像百度地图一样算出路径。而每一条路径就是一个在输入值等价类基础上建立的测试用例。

比如，

第一步，规定计算的路径起点为系统启动；

第二步，终点为系统退出；

第三步，指定一个“条件-行动-预期结果”；

第四步，找出从起点到此“条件-行动-预期结果”的路径；

第五步，找出从此“条件-行动-预期结果”到终点的路径；

第六步，把第四步和第五步的运算结果连接起来，就得到一个覆盖此“条件-行动-预期结果”的测试用例；如此，可以计算出所有“条件-行动-预期结果”所需要的测试用例-个数等于“条件-行动-预期结果”个数。

这也是本发明一种较为简单的实施方式。

实施例四：

从测试角度看软件开发，有两个问题：第一，因为时间和任务的挤压，软件需求以及设计文档很难及时更新，没有足够的动力和资源，测试人员和开发人员，尤其是人员流动大时，会造成知识流失，应对此问题的培训费用就会增加。第二，测试用例，尤其是在数量达到成百上千以后，当待测软件设计改变时，很难维护。而且由于没有结构，测试用例质量很难把握。

本发明将软件行为规格规定和测试用例形成一体(测试用例是由软件行为规格规定计算产生)。优点是：只要维护一份文档，软件行为规格规定，即可。这样，就有了及时更新软件行为规格规定的动力。软件行为规格规定的书写维护需要的时间人力远小于大量测试人员书写维护测试用例的需要的时间人力。多数软件测试用例执行所需要的技能会比软件测试用例设计低很多，因为多数软件本来就是为外行人用的。所以，公司可以只聘请少数技能高的测试人员做测试设计。临时雇佣低技能人员执行测试用例，为企业降低人员成本。

另外，软件行为规格规定其实是软件设计阶段必不可少的产品(利用UI设计、软件功能规格规定等等就可以产生)。根据此发明做出的软件，软件行为规格规定的产生会容易很多，而明确的分析行为，会在设计时帮助找出软件行为缺陷，将问题在早期解决掉，规避风险。等到测试临近时，只要几分钟，就可以产生出高质量的测试用例，省去了待测软件设计改变带来的测试用例维护成本。

实施例五：

通过多年的实践，找到了一个简单实用的软件行为规格规定(BehaviorSpecification)的逻辑结构。通过这个结构，把软件行为规格规定形成一个容易维护的图，把软件测试用例产生，转化成一个简单的图论问题，寻找各种遍历图节点的路径问题。利用图论算法，就可以迅速产生具有明确覆盖率的测试用例。

在复杂不实用的纯学术理论(SoftwareFormalDocumentation)和当前没有任何结构的测试用例方法之间，找到了使用日常语言但又有可运算结构的产生软件行为规格规定和测试用例的方法。

当然，上述内容仅为本发明的较佳实施例，不能被认为用于限定对本发明的实施例范围。本发明也并不仅限于上述举例，本技术领域的普通技术人员在本发明的实质范围内所做出的均等变化与改进等，均应归属于本发明的专利涵盖范围内。

Claims (6)

1.一种软件图形用户人机接口测试用例的自动生成方法，其特征在于：包括如下步骤：

第一步：规定计算的路径起点为系统启动；

第二步：终点为系统退出；

第三步：收集待测软件行为规格规定所有“条件-行动-预期结果”形成集合；

第四步：选择集合中一个“条件-行动-预期结果”；

第五步：找出从起点到此“条件-行动-预期结果”的路径；

第六步：找出从此“条件-行动-预期结果”到终点的路径；

第七步：把第四步和第五步的运算结果连接起来，就得到一个覆盖此“条件-行动-预期结果”的测试用例；

第八步：在集合里，剔除已产生的测试用例和已经用过的“条件-行动-预期结果”；

第九步：在缩小的集合里，选择一个“条件-行动-预期结果”，重复第五步和第六步，直到得出一个最小的并且准确覆盖所有“条件-行动-预期结果”的测试用例集合。

2.根据权利要求1所述的软件图形用户人机接口测试用例的自动生成方法，其特征在于：第三步中，待测软件行为规格规定的步骤包括条件、行动和预期结果。

3.根据权利要求1或2所述的软件图形用户人机接口测试用例的自动生成方法，其特征在于：第三步中，“条件-行动-预期结果”实际是软件测试用例步骤构成基本元素。

4.根据权利要求1所述的软件图形用户人机接口测试用例的自动生成方法，其特征在于：实际测试用例的每一步骤都是待测软件行为规格规定中“条件-行动-预期结果”的一个选择排序。

5.根据权利要求1所述的软件图形用户人机接口测试用例的自动生成方法，其特征在于：第五步和第六步中的路径采用单源路径算法。

6.根据权利要求1或5所述的软件图形用户人机接口测试用例的自动生成方法，其特征在于：第五步和第六步中的路径中的每一条路径就是一个在输入值等价类基础上建立的测试用例。