请问数据驱动的自动化测试框架结构是怎么构成的？

　　随着社会的不断发展和信息化的不断普及，各种软件越来越多，在日常生活中也起着越来越重要的作用，再加上客观系统的复杂性，无论经验多丰富的开发人员、无论采用哪种开发模型开发出来的软件，每个阶段的技术复审也不可能毫不遗漏地查出和纠正所有的错误，因此如何才能把新的软件做得更稳定、错误更少呢？测试！ 统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40％以上。
　　测试是软件能否通向市场的最后也是最重要的一关。传统的测试方法是手工测试，目前大部分都是采用此方法，其特点就是简单，但是它存在的问题非常多。手工测试可能引入人为的输入错误，尤其在数据量大的情况下；另外大量重复性的手工测试可能成本较高，如果考虑软件发生改动而需要重复手工测试的情况，这个成本还会更高；没有办法对组件进行隔离的测试，从而导致发现问题和解决问题的成本都太高。在很多项目中，测试人员的所有任务实际上都是手动处理的，而实际上有很大一部分重复性强的测试工作是可以独立出来自动实现的。
　　针对手工测试的缺点，自动化测试应运而生。相比手工测试，自动化测试的优势很多；规范测试流程，提高测试效率、测试覆盖率等。很多人对自动化测试存在误区，把其理解为找到一种自动化测试工具，把它应用到软件工程项目中，自动化测试工具只是被看作是一种录制和回放的工具。事实上自动化测试远不止这么简单，录制和回放仅是自动化测试中的最低级别。目前常把自动化测试分为5个级别，如图l所示。
　　
　　现在常用的是基于数据驱动的测试，它是以数据来控制自动化测试的流程和动作的测试，其中数据是独立于测试用例脚本的，通常以文本文件形式、Excel文件形式、XML文件等形式存在。
　　1 基于数据驱动自动化测试的实施
　　1．1 可行性分析
　　基于对自动化测试优点的分析，很多人对自动化测试存在另一个误区，认为对于所有的软件都适合引入自动化测试，且只要引入自动化测试，就会提高测试的效率，降低测试的成本。实际上并非如此，自动化测试也需要开发和搭建测试框架，创建测试用例，这也就意味着成本的投入。对于一个项目周期很紧的测试项目，按测试方案进行手工测试的效率可能要比自动化测试工具录制脚本再测试的效率好得多。那么自动化测试工具的价值在什么地方？
　　对于一个一次性开发、没有后续版本更新的软件而言，自动化测试是毫无意义的。但是现在很多软件都会不断推出新的版本，在推出新版本的过程中，每次除了测试新加或修改过的模块，相关联的旧模块同样需要测试，才能保证产品的质量，这样就需要做大量的重复工作，自动化测试此时就可以创建测试中的可重用模块，同时还可以覆盖大部分的功能测试，这样可以使测试人员从回归测试中解脱出来，专注于新模块的测试。所以可以说自动化测试的最大价值在于回归测试。
　　因此，对于一个软件或其中某些模块是否适合自动化测试必须要先进行可行性分析，以证明你所选的测试方法的正确性，通常可进行自动化测试的软件需要满足以下几点：
　　（1）手工测试复杂度高：
　　（2）所选测试用例，实现自动测试的难度低；
　　（3）软件用于自动化测试的模块界面变化相对不大；
　　（4）软件生命周期长，经常推出新的版本；
　　（5）软件开发已基本完成，主要用于测试升级版本；
　　（6）所选自动化测试框架必须对所测软件应用界面有有效的支持，且维护管理成本较低。
　　另外自动化测试前期需要投入时间和一定的成本投入，故不要一开始就期望有高的回报，其效应会在不断完善积累中显现。而且不要期待自动化测试可以发现每个版本中的大部分错误，因为自动化测试主要用于回归测试，而且产品中每个新版本的大部分bug会在新模块中出现，所以自动化测试在于长期效应，能保证每个版本产品质量的稳定。
　　1．2 需求分析
　　正如开发软件需要有需求分析一样，基于数据驱动的自动化测试本质上也是开发，所以在制定测试方案之前也需要收集测试需求，这样才能保证自动化测试的成功。
　　随着IT技术的发展，传统的开发人员兼任测试人员的模式已经不能满足需求，目前大多数较正规的软件公司均已采用独立的测试人员来对软件进行测试，所以形成了开发人员、开发管理者、测试人员、测试管理者的模式。如图2示。
　　
　　规范的测试过程需要上述人员的通力配合，因此在做自动化测试之前应该有一份规范的文档，用来描述测试内容、人员安排、测试流程、缺陷管理等。其中开发管理人员和测试管理人员分别作为开发团队和测试团队的接口，协调两个团队的工作，一般来说开发人员需要在每次对软件更新后提供详细的功能文档，开发人员还需要提供自动化测试所需要的数据等相关资源，测试人员根据功能文档创建适合做自动化的测试用例，并建立基于数据驱动的自动化测试工程。
　　1．3 数据驱动的自动化测试框架结构以及实现
　　基于数据驱动的自动化测试不是简单的录制回放，而且通过编程的形式来实现每个测试用例，其中数据文件独立于测试用例，这样数据的更新对整个测试工程的维护会降低到最小。因此创建自动化测试框架需要有一定的编程基础。
　　本文自动化测试中采取的是三层框架结构，如图3所示。
　　
　　其中最底层为UI Driver层，主要负责定义基本的通用元素库，如按钮、下拉框、文本框等在每个软件中都会出现的基本元素；对这些元素的基本操作以及通用操作（如等待某段时间的函数等）。这一层和测试的软件没有关系，因此通用性很强，既可以自己开发也可以用前人开发好的底层自动化Driver。
　　第二层为代理（Agent）层，这一层是建立在被测软件上，对被测软件的每一界面（UI）均建立相关的类和对象，方便最上层调用，这一层需根据软件的不断更新而更改。
　　最上层为测试用例层（Test Cases），这一层建立在代理层上，代理层建立好之后，可以提供给测试用例层所需的界面元素，使测试用例可以通过对界面元素的操作完成自动化测试过程。这一层是测试用例的实现层，如果有了比较完善、结构合理的底层以及代理层，此层实现起来就会非常简单。
　　其中测试数据以及软件中元素的ID信息是存放在独立的XML文件中，测试用例层或者代理层需要用数据时，可以通过统一的接口读取。这样的方式不仅可以使整个测试工程结果清晰，最重要的是可以降低整个测试系统的维护费用，这样才能确保自动化测试的投入回报不断提升。
　　1．4 自动化测试的维护和扩充
　　自动化测试工程会由于软件的不断扩充而必须加以维护和扩充。其中维护是指由于新版本的升级导致的旧的测试用例无法通过，必须加以维护才能正常运行。而扩充则是指由于版本的不断升级，某些功能已经非常稳定，适合于自动化测试，需要新添加一些测试用例来覆盖这些功能。
　　扩充和维护是一个长期的过程，其中需特别注意的是每次自动运行测试用例，必须有个详细的结果日志来记录测试用例的通过情况，对于运行失败的用例，记录失败的原因，这样有利于测试人员通过结果来判断产品的bug。这里需要特别注意的是，有的测试用例表面上是通过了，但是实际上却执行失败了，并且结果日志上记录的是通过，如果出现这样的情况，而测试人员却毫无察觉，这就是失败的自动化，所以对于每次自动化测试的结果，最好能够建立起核查机制，以确保结果的可靠性。
　　2 总结
　　自动化测试是一个比较新的研究领域，也是近来很具争议性的研究话题，对于自动化测试引入之后的利弊，众说纷纭。当然自动化测试也在争议中显现出了强大的生命力，其测试效率高、重用性好等优点得到了广泛的认同。本文中所介绍的自动化测试框架结构在很多大型的软件系统中得到了应用，取得了良好的效果。