[发明专利]一种基于模型变更的自动维护测试脚本的方法

说明书

技术领域

本发明涉及一种通过自动获取应用的两个相邻版本的GUI变更来自动的维护测试脚本的方法。

背景技术

随着移动终端的快速普及，成千上万的移动应用也应运而生。这些应用给我们的生活带来便利的同时，也存在一定的风险：大部分的应用会获取我们的隐私，如手机号，身份证号等，甚至管理着我们的资产，如银行卡，信用卡等。一旦这些应用出现问题，很容易造成用户的经济损失和隐私数据的泄漏。而且伴随着应用市场的激烈竞争，同一种功能的应用会有几款甚至十几款，一旦我们发现一款应用出现问题，我们肯定会弃之去寻找其他符合我们要求的应用，因此，开发者为了使产品在应用市场竞争中脱颖而出，也越来越注重产品的质量。测试就是一种可以用来提高产品质量的有效的手段。

在移动应用的开发过程中，通常会进行定期的回归测试来保证当前程序功能的正确性。回归测试需要准备大量的测试用例，一般情况下都要求测试用例库尽可能多的覆盖需要测试的功能和情况。在版本迭代后会重新执行这些测试用例，以保证对错误的修复以及没有引入新的错误。而且对于新增的功能，要添加新的测试用例，以保证测试的完整性。测试用例的执行方式，常用的有手工测试和脚本测试。脚本测试就是通过脚本语言模拟手工的动作，在测试工具的支持下，自动的执行测试用例。由于回归测试用例数目庞大且移动设备的软硬件种类繁多，需要在大量的设备上进行测试，所以脚本驱动的回归测试是移动应用开发和测试人员最常用的。

测试脚本可以人工编写、录制和自动生成等。一般来说，自动化程度高的方法更受测试人员的青睐。如何自动生成覆盖程度高的测试用例库，一直是研究人员关注的热点问题。而在自动生产测试用例的技术中，基于模型的测试生成技术使用的比较广泛，而且该方法更容易屏蔽移动平台(Android、OS、WinPhone等)带来的差异。

现在有很多自动生成测试脚本的方法，应用的每一个版本发布之前，都会重新生成新的测试脚本对应用进行测试，但是，要生成足够多的脚本对应用进行完整的测试，代价非常高。由于移动应用的升级频繁，且周期非常短，而且旧脚本中人工编写的测试用例，有很高的经验和领域价值，所以在回归测试中，复用测试脚本是提高测试效率的很有效的方法。

移动应用一般具有丰富的GUI，而GUI是给用户最直接的体验感受的部分，应用的GUI出现问题，对于移动应用无疑是致命的。所以在移动应用的回归测试中，对GUI进行充分的测试，对于保证应用的质量是非常重要的。针对GUI的测试脚本是一系列的事件序列，而事件是对界面和控件非常敏感的，如果GUI发生变更，相关的测试脚本通常会失效，而且为了提高用户的体验，工程师经常会修改应用的GUI。因此我们若想要复用针对上一版本的测试脚本，就要获取应用的GUI的变更，然后根据变更对脚本进行维护，以便尽可能多的复用原测试脚本中的事件，以保证测试覆盖度。

针对上面的问题，我们提出了基于模型的自动维护测试脚本的方法。减少了回归测试过程中维护测试用例库所需的大量人力和时间。

发明内容

技术问题：本发明的目的是提供一种在版本变更中自动维护测试脚本的方法，以减少回归测试中人工维护测试脚本的成本。

技术方案：本发明的基于模型变更的自动维护测试脚本的方法，首先利用深度优先遍历的方法获取初始版本模型中的所有执行路径，然后将这些执行路径映射成可以执行的测试脚本，同时人工可根据经验和领域知识补充一些测试脚本，作为应用初始版本的测试脚本。对于后续版本，首先对比当前版本和上一版本的模型，通过相似度来确定控件的对应关系，得到控件和事件的增加、删除和修改；然后遍历上一版本的脚本的执行路径，对于涉及到变更的路径进行修复，并修改该路径对应的脚本。

步骤1：建模。使用建模工具抽取出移动应用的状态转移关系，目前学术界常用的建模工具有Gator，Android Ripper等。根据状态转移关系创建事件序列模型(Event Sequence Model，ESM)来描述应用的行为。ESM描述了应用的界面信息以及每一个界面上的控件信息。其中状态是界面，包括activity，dialog，menu等。每一个界面的名称是唯一确定的，如activity的名称即是在资源布局文件中注册的activity的名称，且不会有重名情况。在我们的方法中，如果界面的名称改变了，我们认为原来的界面被删除了，新增了一个新的界面，且原界面中的控件转移到了这个新增的界面中。

步骤2：根据图1，如果当前为应用的初始版本(没有上一版本或没有可维护的测试脚本)，自动生成测试脚本：