基于数据驱动的自动化测试的研究和实现

功能文档，开发人员还需要提供自动化测试所需要的数据等相关资源，测试人员根据功能文档创建适合做自动化的测试用例，并建立基于数据驱动的自动化测试工程。

1．3 数据驱动的自动化测试框架结构以及实现

　　基于数据驱动的自动化测试不是简单的录制回放，而且通过编程的形式来实现每个测试用例，其中数据文件独立于测试用例，这样数据的更新对整个测试工程的维护会降低到最小。因此创建自动化测试框架需要有一定的编程基础。

　　本文自动化测试中采取的是三层框架结构，如图3所示。

　　其中最底层为UI Driver层，主要负责定义基本的通用元素库，如按钮、下拉框、文本框等在每个软件中都会出现的基本元素；对这些元素的基本操作以及通用操作(如等待某段时间的函数等)。这一层和测试的软件没有关系，因此通用性很强，既可以自己开发也可以用前人开发好的底层自动化Driver。

　　第二层为代理(Agent)层，这一层是建立在被测软件上，对被测软件的每一界面(UI)均建立相关的类和对象，方便最上层调用，这一层需根据软件的不断更新而更改。

　　最上层为测试用例层(Test Cases)，这一层建立在代理层上，代理层建立好之后，可以提供给测试用例层所需的界面元素，使测试用例可以通过对界面元素的操作完成自动化测试过程。这一层是测试用例的实现层，如果有了比较完善、结构合理的底层以及代理层，此层实现起来就会非常简单。
其中测试数据以及软件中元素的ID信息是存放在独立的XML文件中，测试用例层或者代理层需要用数据时，可以通过统一的接口读取。这样的方式不仅可以使整个测试工程结果清晰，最重要的是可以降低整个测试系统的维护费用，这样才能确保自动化测试的投入回报不断提升。

　　1．4 自动化测试的维护和扩充

　　自动化测试工程会由于软件的不断扩充而必须加以维护和扩充。其中维护是指由于新版本的升级导致的旧的测试用例无法通过，必须加以维护才能正常运行。而扩充则是指由于版本的不断升级，某些功能已经非常稳定，适合于自动化测试，需要新添加一些测试用例来覆盖这些功能。

　　扩充和维护是一个长期的过程，其中需特别注意的是每次自动运行测试用例，必须有个详细的结果日志来记录测试用例的通过情况，对于运行失败的用例，记录失败的原因，这样有利于测试人员通过结果来判断产品的bug。这里需要特别注意的是，有的测试用例表面上是通过了，但是实际上却执行失败了，并且结果日志上记录的是通过，如果出现这样的情况，而测试人员却毫无察觉，这就是失败的自动化，所以对于每次自动化测试的结果，最好能够建立起核查机制，以确保结果的可靠性。

　　2 总结

　　自动化测试是一个比较新的研究领域，也是近来很具争议性的研究话题，对于自动化测试引入之后的利弊，众说纷纭。当然自动化测试也在争议中显现出了强大的生命力，其测试效率高、重用性好等优点得到了广泛的认同。