基于图形用户界面的软件的测试方法的研究

饶建农

摘要：当今的软件系统通常以图形用户界面（GUI）为特征，但是对于图形界面的测试大多数都是手工操作完成，因此存在成本高，浪费时间等缺点。在GUI软件自动化测试的基础上，通过程序代码，将输出结果和输入进行对比，分析自动化测试的结果，研究出一种不利用GUI完成以GUI为基础的软件的测试方法。实验结果证明，不利用GUI功能来测试GUI软件的尝试得到了部分成功。

关键词：图形用户界面;软件测试;测试方法;软件工程环境;程序逻辑

中图分类号：TP311        文献标识码：A

文章编号：1009-3044（2019）17-0078-04

开放科学（资源服务）标识码（OSID）：

Abstract： Today's software systems are usually characterized by a graphical user interface （GUI）， but for most of the graphical interface testing manual to complete， so there is a high cost and waste of time and other shortcomings. On the basis of the automated testing of GUI software， by the code， compare the output and input， analyze the results of automated testing and come up with a non-use GUI to complete the GUI-based software testing methods.The experimental results show，do not use the GUI functionality to test the GUI software attempt has been partially successful.

Key words： Graphical User Interface（GUI）;software testing;test methods;Software Engineering Environment（SEE）;program logic

1 引言

當今的软件系统通常以图形式用户界面（GUI）为特征。那些帮助程序员利用图形界面产生应用系统的工具，已经戏剧化地改进了程序员的效率，但是也增加了测试者的压力。这种软件必须在每一次使用之前得到彻底地测试。

当今的图形界面测试大多数都是手工操作完成，这种方法成本较高且浪费时间。因此，需要有完全自动化的测试程序。如果使用自动化测试程序，将极大地减少测试所需的时间和人力。

本文着重研究如何解决一个具有GUI功能的应用程序，可以在不使用GUI的环境下被测试和引导;研究自动复原测试如何执行，使测试结果在应用程序功能发生变化的情况下不受影响或产生最小的影响。

不利用GUI功能来测试GUI的尝试得到了部分成功。这种自动化测试依赖于被测试产品的结构。课题的测试目标在某种程度上被结构化，这可能使测试方法变得困难和费时。

2 相关理论

2.1 测试的概念

在Glen Myers的经典著作《The Art of Software Testing》中，给出了测试的定义：“程序测试是为了发现错误而执行程序的过程”。另外，Glen Myers还给出了与测试相关的三个重要观点，那就是：测试是为了证明程序有错，而不是证明程序无错误;一个好的测试用例是在于它能发现至今未发现的错误;一个成功的测试是发现了至今未发现的错误的测试。当然测试用例在软件开发之前不能执行，但是可以在需求规格的基础上进行设计。

测试的质量可以描述为下列几个属性：效力、模范性和成本考虑。

2.2 验证和确认

验证和确认能确保软件的规格和顾客的满足程度。验证可以确保系统实现所有的要求，确保每一个功能都准确地实现。也就是说，验证可以确保开发者按照规格开发正确的产品，同时审核执行质量。

验证和确认可以分成两种技术，即：静态技术和动态技术。

2.2.1 测试过程

大型软件系统的测试过程包含几个阶段，这些阶段分为：单元测试、集成测试、系统测试、确认测试和复原测试。复原测试是测试中的必要部分，但是当进行手工操作的时候，就变得非常地反复和沉闷。这种测试越来越重要，需要通过发展周期来完成，如图1所示。

所有这些流程都应该尽可能经常运行。图中的箭头表明了测试的正常顺序，当箭头返回到先前的框架中时，表明先前的测试可能被重复，也就是复原测试。

复原测试也可能导致编辑现有测试用例或者产生新的用例。

2.2.2 测试技术

测试设计方法分为两类：白盒测试和黑盒测试。

白盒测试：这种测试技术基于程序代码、程序描述或者技术设计的基础上，对系统内在结构的认知起着重要的作用。

黑盒测试：这种测试技术基于功能规格和质量要求的基础上。在黑盒技术中，系统被认为是可以实际应用的。

2.2.3 测试成本

如同任何事物一样，软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。一般称其为计算机软件的生存期。根据这一思想，把上述基本的过程活动进一步展开，可以得到软件生存期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护。

每一阶段的相关成本，可以归结为如表1和表2所述：

测试、发现和修改程序中的错误可以在软件生存期的任何阶段进行，占总开发成本的40%到80%。然而，发现和修改错误的成本随着开发的推进显著增加。在代码写完之前，更改需求文件比代码写完之后进行修改要花费得少，因为代码必须重写。程序员在发现错误后进行维护成本是比较低的，因为他们不需要向其他人解释，这就不会产生沟通费用。在运行程序之前修改错误所花费的成本，要比发出新磁盘，给一个技术员，一个客户后修改所花费的成本低得多。

2.3 软件工程环境

软件工程环境（SEE）是一组硬件和软件工具，它可以以一种集成的方式运行，为整个软件程序从最初的规划一直到测试和运行提供支持。

软件工程环境运行的平台被称为客户系统。一般情况下，用软件工程环境开发的軟件将会在相同的平台中运行，但是在许多情况下，它可能传送到一些目标系统，而这些目标系统有一个完全不同的结构和运行系统。

3 不利用图形界面，来实现以图形界面为基础的软件的测试的自动化

3.1 介绍

通过使用GUI对以GUI为基础的软件进行自动化测试时存在两个问题：软件改变时，都会需要大量地维护性工作;软件运行时，如果存在绘图区，绘图区尺寸就会改变，这使得绘图区的测试变得困难。

为了避免上面提到的问题，本节着重于寻找不使用GUI来实现GUI软件测试自动化的可能性，也就是依靠程序代码。本节也要定义测试目标必须完成的要求，发现形成测试自动化的可能技术。

为了完成测试，使用Telelogic公司开发的Telelogic Tau（由UML Suite， SDL Suite， TTCN Suite， SCADE 和Logiscpoe组成）作为测试工具。

3.2 Telelogic库的概况

Telelogic库分为几个目录和子库。库是Telelogic Tau的一个完整部分，库被分成四个不同的层次。库框架体现了结构和公共代码库，代码库以特定的方式允许维护和开发软件的某些方面。

为了了解库界面是如何互动的，需要一个例子。这个例子显示菜单选择时事件的过程。通过选择菜单，在应用系统库中的功能被激活。这一功能唤起框架子库中的菜单选择功能。

3.3 测试目标的选择

为了完成测试，测试目标应当有一个简单的结构与少数的菜单，因为这能使获得和追踪可能存在的漏洞变得更简单。

在Telelogic Tau的编辑器中，有两种软件能实现这一目的：MSCE（Message Sequence Chart Editor）和HMSCE（High-level Message Sequence Chart Editor）。

本文选择HMSCE作为测试目标。然后给出具体的描述，调查HMSCE中菜单、对话框和绘图区的功能。

3.3.1 菜单

在Windows环境下有两种菜单，分别是下拉式菜单和弹出式菜单。

下拉式菜单：这类菜单从应用程序窗口的菜单栏中激活，允许用户选择将要执行的命令。

弹出式菜单：也称为快捷菜单或上下式菜单，当点击鼠标右键时出现。鼠标单击的区域不同，弹出的菜单内容一般也不同。

3.3.2 对话框

对话框通常用来显示信息或者提示用户输入继续执行应用程序所需要的数据。分为模态对话框和非模态对话框。模态对话框要求在继续执行应用程序的其他操作之前，必须先被关闭，或对它的提示做出响应。非模态对话框允许在关闭对话框之前对应用程序的其他部分做出响应或操作，即当对话框正在显示时，可以继续操作当前应用程序的其他部分。

从测试的角度分类，对话框分为安装/选项对话框和消息对话框。这些对话框可能是模态式的或者非模态式的。

安装/选项对话框：这类对话框分成两类。第一类选择可能安装的状态和命令按钮的数目。第二类几乎同第一类相同，不同的是：按钮被安装后，不能改变现有按钮的数目。

消息对话框：消息对话框被提前安装，经常会弹出来提醒用户某些内容被改变或者运行错误。消息对话框通常仅有一个按钮，而用户不能有任何选择，只是确认消息的内容。

有些消息对话框也有几个按钮，但是它们仍然是固定对话框，主要提醒用户某些内容被改变，用户可以接受或者拒绝这种改变。

3.3.3 绘图区

当在绘图区处理目标时，了解某个功能被调用时对软件的影响是非常重要的。一个好的测试用例，其目的在于实现绘图区测试的自动化，使测试者把这些测试活动用于运行自动化测试的输入。

满足这种需求需要测试用例覆盖一些重要的活动，例如增加、删除、产生和复制目标等。

3.4 案例研究

3.4.1 介绍

本文研究的目的是：调查GUI软件的自动化测试如何提高测试质量;是什么原因使现有产品的自动化测试变得困难;如何在将来的产品测试中克服这些困难。

通过测试案例的运行，理解了自动化测试的过程，发现了造成困难的原因。

3.4.2 计划

当软件测试开始之前，了解软件存在问题和软件的功能是非常重要的。因此第一阶段就是去调查Telelogic库的结构和子库之间的界面，如表3所示。

调查的目的是找出一个可以抓取所有信号的界面，利用这个界面，GUI和逻辑程序可以互相交流。

这些信号用于菜单、对话框和绘图区的分别测试。

在Telelogic Tau的研究中，发现GUI和程序代码是两个相互交叠的单元，如图2所示。因此，所需要的界面并不存在。

由于界面的缺乏，使得统一操作和掌控所有部件是不可能的。因此，菜单，对话框和绘图区必须被分别测试。

3.4.3 执行

为抓取信号，有许多工具可以使用。把Telelogic库分成四个子库的目的就是为了编写宏和把宏放到包含程序代码的应用子库中去，这对于所有类型的编辑器都是相同的。优点是能够测试和掌控任意编辑器，但是这种方法也比较费时，因为不仅是程序代码可能写在Unix和Windows两个运行系统上，而且对于一个简单的调用活动，必须改变子库中的许多其他程序。

为了避免这种复杂性，框架子库看起来同应用子库相比是一个更好的转变。在此子库中，有一个功能被称为Win菜单选择。用这一功能，能调用编辑子库中所需编辑器的其他功能。从子库中调用编辑需要现有程序代码的大量改变。

在其他HMSC编辑中，子库包含所有种类的编辑器。因为菜单可被选为测试目标。在此编辑器中，有一种被称为菜单选择的功能执行菜单的选择。在宏的帮助下，包括菜单选择功能的HMSCPage等级被定义为Original HMSCPage等级，它继承了来自于先前等级的所有功能。

测试执行期间，多余的窗口将会被同时打开。因此，菜单和调试窗口两者将会以两种独特的界面显示。

3.4.4 结果

通过抓取/回放功能的输入输出文件之间的对比，清楚地显示了菜单项的自动化测试是可行的，但是它并不是对现有产品的测试技术。尽管本论题的观念是研究菜单，对话框和绘图区域的测试，但是由于时间和软件产品的缺乏，不容易实现对对话框和绘图区域进行测试。

4 结论

4.1 设计上的测试执行

菜单项的测试可以通过宏抓取回叫信号来完成。对话框和绘图区用同样方法也是可以的，但是由于现有软件产品的结构，这种方法比较困难而且费时。

从测试指向来看，有三种类型的对话框，也就是两种安装对话框和一种信息对话框。由于这些对话框缺少一个公共的界面，因此这三种对话框可能会被分别测试。这就意味着回叫信号不可能由一个简单的宏抓取，会有大量的变化，而这种变化反过来会影响几个文件。

进行绘图区的测试时，除对话框测试存在的问题外，还应该考虑其他的问题：绘图窗口的尺寸和抓取回叫信号的可用性。主要的问题是：每次软件运行时，或者打开窗口而其他窗口也打开的时候，窗口的尺寸都会改变。这可能导致抓取的回叫信号和当前位置有所不同。因此对自动化测试来说，抓取的回叫信号不能看作是重播功能的输入。

回叫信号的可用性意味着：在进行调试时，抓取到的回叫信号能实现自动化测试，能够直接地使用重播功能，或者为实现这一目的做好准备。

一个普遍的问题就是平台的依靠性。例如，对于一些对话框，其测试必须安装在Unix和Windons双重平台之上。

另一个问题就是原有的测试数据的持久性。如果一个菜单在下个软件中菜单项增加或者删除，原来抓取的数据就是没有用的了，因为新的菜单不同于先前软件的菜单。持久性问题可以通过保存所有菜单的功能来解决，也可以在最初运行手工测试来解决。

很明显的，这些测试工具需要很多时间，要由有经验的测试者来安装，要由有经验地对系统有良好知识的测试者来运行。

在Telelogic公司，在现有软件中不借助GUI的使用去测试GUI软件，那也是非常困难的，或者是不可能的。

4.2 建议和未来的研究

要想能够测试以GUI为基础的软件而不利用GUI的话，第一步应该是从程序逻辑中分离出GUI。这种分离应该给出所需的界面，也就是公共界面。由于现有软件的结构，在应用库中生成这种界面是可能的。这种方法可以使菜单和一些对话框的测试更容易。

公共界面使得能抓取所有的数据（这些数据可以用作重放功能的输入）。这种重放功能可以用手写代码实现，通过使用抓取数据激活应用程序。正確的结果可以通过比较重放功能的输入和输出而得到。通过公共界面抓取的信号输入到重放功能的绘图区域时，需要当前产品结构上有巨大的改变。

另一种想法是在程序逻辑上写更多的代码和生成GUI的尺寸尽可能小，这种方法的目的是尽量减少基于GUI软件的自动化测试的GUI的工作量。好处就是测试程序逻辑比GUI可能更容易一些。

参考文献：

[1] Paul C. Jorgensen.Software Testing A Craftsmans Approach[M].北京：机械工业出版社，2005.

[2] 王谦.基于评价软件测试的有效性问题研究[J].计算机光盘软件与应用，2012（4）.

[3] 于凌云.软件测试的实践研究[J].电脑知识与技术，2010（27）：7664-7666.

[4] 钟百成，张言上.关于软件测试技术的探讨[J].数字技术与应用，2012（2）：133-135.

【通联编辑：代影】