一种基于覆盖的GUI驳拟试用例生成方法.docVIP

一种基于覆盖的GUI测试用例生成方法 摘 要 在GUI技术正得到广泛应用的同时，其自身的特点使传统的基于代码的测试方法无法有效应用于GUI测试。GUI测试主要是通过执行事件序列、获取检测状态和对比验证内容来发现故障的，而现有的事件序列生成方法都没有直接对GUI的覆盖进行控制，这很有可能会遗漏重要的测试步骤；而现有的检测状态和验证内容生成方法不但效率低下，还有可能遗漏必要的检测点和关键的验证点。针对这些问题，作者提出了一种基于覆盖的GUI测试用例生成方法，它可以快速生成符合覆盖准则要求的事件序列，并自动生成全面的检测状态和验证内容。与其它GUI测试用例生成方法相比，该方法在故障检测效率及故障覆盖率等方面都具有明显优势。 关键词 GUI测试用例； 覆盖准则； 事件序列； 检测状态； 验证内容1 引言 由于界面友好、便于开发、维护和操作等特点，GUI技术正在软件开发过程中得到广泛的应用。GUI应用程序一般具备两个主要的特征——图形界面的设计与功能代码的开发相独立、用户交互事件驱动程序执行[1，2]，这可以使GUI程序在开发和维护过程中产生许多特殊的情况，如相同的代码对应不同的界面、不同版本的GUI具有相同的代码、功能代码所对应的消息或方法不能有效的体现用户交互等等，导致传统的基于代码的测试方法无法有效的应用于对GUI的测试。 与传统的测试用例概念不同，GUI的测试用例是指驱动程序运行的事件序列，如鼠标的点击和菜单的选择等动作。一种常见的测试用例生成方法是使用录制/回放工具录制生成包含运行事件序列的脚本，并在录制的过程中或完成后向脚本中添加检测点来验证相应事件的执行结果[3]。这种方法虽然可以直接有效地生成事件执行序列，但是测试相关数据和事件操作顺序都固化在测试脚本中，非常不利于对测试用例的维护。Archer Group和Keith Zambelich等对这种方法加以改进，设计了控制同步数据驱动和关键字驱动方法[4，5]，将测试数据从测试脚本中分离出来，形成独立的数据文件，以文件中的数据来驱动脚本运行。这样虽然在一定的程度上改进了测试用例维护的问题，但Archer Group的控制同步方法仅限于业务规则类型的测试，而Keith Zambelich的关键字驱动方法还需要对不同项目的测试脚本进行维护。 对于GUI测试用例的自动生成方法，Donat提出一种基于需求的测试用例生成技术[6]，自动的将格式化的需求说明转换成测试用例。Kasik提出一种以学习的方式来生成测试用例的技术[7]，在专家给出的GUI事件序列基础上，应用遗传算法技术来修改和增加这个序列[8]，从而得到达到同样的目标多种选择。Memon给出一种基于计划的方法，用目标驱动测试用例生成的技术[9]。这种方法首先给出测试用例的初始条件和目标条件，然后应用人工智能技术逐步向目标逼近。在利用有限状态机来生成测试用例的方法中[10]，软件的行为被描述成FSM模型，它包含GUI的有限个状态，每一个输入动作都会使FSM中状态发生改变。在创建了FSM后，测试用例的生成过程就可以自动进行了。 虽然以上的几种方法在一定程度上可以实现测试用例的生成，但由于它们都没有直接对GUI的覆盖程度进行控制，因此可能会遗漏由用户交互产生的重要事件序列；而由于现有检测状态和验证内容生成方法的不足，每个事件序列对应的检测点和验证点也可能会有所缺失。在目前国内外GUI测试领域里，尚没有对以上问题进行详细研究。因此本文结合Memon的事件序列覆盖准则[11]，提出一种基于覆盖的GUI测试用例生成方法。它可以生成符合覆盖准则要求的事件序列，并自动生成其全面的检测状态和验证内容，解决传统测试用例生成方法遗漏的重要测试步骤、必要检测点和关键验证点等问题。 本文的第二部分对GUI的组件、事件流图、调用关系图和测试用例进行定义；第三部分给出了GUI的单事件故障、事件交互故障和事件序列故障模型；第四部分从测试用例生成条件、子序列生成、预期状态生成和子序列连接等方面介绍了基于覆盖的GUI测试用例生成方法；第五部分通过实验来对比不同方法生成测试用例的事件序列覆盖率和故障覆盖率；最后是全文的总结和参考文献。2 GUI相关定义2.1 GUI的组件 模式化窗口是GUI的一个窗口，当它被打开后，会将用户可操作的范围限定在该窗口之内。与模式窗口相对应的是非模式窗口，它不会限制用户的输入焦点，而是扩展了用户操作范围。模式化窗口及其相关的非模式化窗口可以代表GUI的一个层次，将其定义为GUI组件，以如下三元组lt;MW，UWs，S0gt;表示： ● MW={e1，e2，e3，…，en}， ●UMs={UM1，UM2，…，UMm} ●UMi={ea，eb，ec，…，ex}，UMiIcirc; UMs ●”UMi，UMi = invoke(e)，eI