基于数据驱动的自动化测试的研究和实现
1．3 数据驱动的自动化测试框架结构以及实现
基于数据驱动的自动化测试不是简单的录制回放，而且通过编程的形式来实现每个测试用例，其中数据文件独立于测试用例，这样数据的更新对整个测试工程的维护会降低到最小。因此创建自动化测试框架需要有一定的编程基础。
本文自动化测试中采取的是三层框架结构，如图3所示。
其中最底层为UI Driver层，主要负责定义基本的通用元素库，如按钮、下拉框、文本框等在每个软件中都会出现的基本元素；对这些元素的基本操作以及通用操作(如等待某段时间的函数等)。这一层和测试的软件没有关系，因此通用性很强，既可以自己开发也可以用前人开发好的底层自动化Driver。
第二层为代理(Agent)层，这一层是建立在被测软件上，对被测软件的每一界面(UI)均建立相关的类和对象，方便最上层调用，这一层需根据软件的不断更新而更改。
最上层为测试用例层(Test Cases)，这一层建立在代理层上，代理层建立好之后，可以提供给测试用例层所需的界面元素，使测试用例可以通过对界面元素的操作完成自动化测试过程。这一层是测试用例的实现层，如果有了比较完善、结构合理的底层以及代理层，此层实现起来就会非常简单。
其中测试数据以及软件中元素的ID信息是存放在独立的XML文件中，测试用例层或者代理层需要用数据时，可以通过统一的接口读取。这样的方式不仅可以使整个测试工程结果清晰，最重要的是可以降低整个测试系统的维护费用，这样才能确保自动化测试的投入回报不断提升。
1．4 自动化测试的维护和扩充
自动化测试工程会由于软件的不断扩充而必须加以维护和扩充。其中维护是指由于新版本的升级导致的旧的测试用例无法通过，必须加以维护才能正常运行。而扩充则是指由于版本的不断升级，某些功能已经非常稳定，适合于自动化测试，需要新添加一些测试用例来覆盖这些功能。
扩充和维护是一个长期的过程，其中需特别注意的是每次自动运行测试用例，必须有个详细的结果日志来记录测试用例的通过情况，对于运行失败的用例，记录失败的原因，这样有利于测试人员通过结果来判断产品的bug。这里需要特别注意的是，有的测试用例表面上是通过了，但是实际上却执行失败了，并且结果日志上记录的是通过，如果出现这样的情况，而测试人员却毫无察觉，这就是失败的自动化，所以对于每次自动化测试的结果，最好能够建立起核查机制，以确保结果的可靠性。
2 总结
自动化测试是一个比较新的研究领域，也是近来很具争议性的研究话题，对于自动化测试引入之后的利弊，众说纷纭。当然自动化测试也在争议中显现出了强大的生命力，其测试效率高、重用性好等优点得到了广泛的认同。本文中所介绍的自动化测试框架结构在很多大型的软件系统中得到了应用，取得了良好的效果。
加入微信
获取电子行业最新资讯
搜索微信公众号：EEPW
或用微信扫描左侧二维码
