时光飞逝，转瞬之间，已在计算机软件这个行业，在开发和
测试岗位
工作了10年。而这其中的酸楚，苦涩和甜美，恐怕只有亲身经历过才能深有体会。
在当今信息社会，飞速发展的时代大背景下，小小的我，无疑是幸运的。感谢奋战过的每一个岗位，感谢每一位领导，感谢每一位同事。是他们提供了平台和机会，是他们的殷切期望和悉心培养，是他们的包容，鼓励和支持，让我不断成长。
无以为报，那就写下一些文字，算是勉励自己，记录那青春岁月，和对
软件测试以及
自动化测试的感悟。
对于自动化测试框架，其实并没有多数人想象中的那么高深玄乎，框架的概念只是一系列的被事先定义好的标准和规范。在自动化测试中我们经常提到的对测试需求的解析、脚本设计、测试执行、测试报告、维护管理等等，通过框架将它们串联并封装起来，从而使框架的终端用户能够更方便地使用。然而，一个好的自动化测试框架，不仅仅要能让用户方便使用，还需要考虑很多其他因素，下面就来分享一下一些个人的经验。
选择一种类型的框架
目前比较常见的自动化测试框架主要有3种：数据驱动框架、关键字驱动框架和混合型框架。
1. 数据驱动框架(Data Driven Framework)
数据驱动最适合测试的业务逻辑固定不变的应用程序，只有测试数据会变化。通常测试数据会被配置在外部文件或
数据库中。
2. 关键字驱动框架(Keyword Driven Framework)
关键字驱动顾名思义，它提供了一系列通用的关键字，用户通过调用这些关键字并输入一些参数可以实现单个操作，比如，打开浏览器、打开某个网页、点击某个链接等等，然后通过组织这些关键字形成一个完整的测试流程。
3. 混合型框架(Hybrid Framework)
混合型框架就是把数据驱动和关键字驱动整合起来，同时具备了两者的优点。与关键字框架不同的是，这种框架通常会提供一些针对于特定应用程序的关键字，比如 登录、登出等。然后在完整测试流程的基础上，再应用一层数据驱动，这样就能使测试逻辑和测试数据更加灵活和可配置。
不必重新造轮
在设计框架的时候应该尽可能的沿用自动化测试工具已提供的功能。比如，一个基于
selenium的框架，selenium本身就已经提供了打开浏览器和网页，点击按钮等功能，就不必花时间再去开发这样一些关键字，以减少开发成本。
可重用性
一个好的框架必须具有高度的可重用性。我们可以把一些单独的操作组合成一些最常用的测试流程，比如，把“输入用户名”、“输入密码”、“点击登录”三个操作组合成一个关键字“登录”。
配置管理
如同开发团队一样，自动化脚本也需要有配置管理，这样才能更有效地对脚本的提交、修改、版本控制、基线化等操作进行管理，所以在设计框架的时候需要考虑结合配置管理工具，如CVS、VSS、SVN等。
可配置性
1. 外部可配置性
脚本的配置项应该放在外部文件中，像URL，路径，版本信息等，从而能使脚本在不同的环境下运行。另外配置文件的路径也不能写死，应采用相对路径，以保证框架能在不同的机器上顺利运行。
2. 内部可配置性
当框架部署到不同的机器上时，会有不同的环境，要有能够自动根据不同的系统环境完成必要配置的能力。举个例子，比如一个selenium框架被部署到装有不同浏览器的机器上，框架应当能根据当前系统上装了哪些浏览器而分别运行它们。
对象库维护
在自动化测试中遇到的大多数问题基本上都是由于对象的属性变化导致的脚本失败，所以，对象库的维护能力对于一个框架来说十分重要。我们可以把对象库作为一个共享资源，由专人进行维护。对象库可以是一个外部的XML、Excel、数据库等。
执行模式
需要考虑到以下几种用例执行需求：
1. 执行一个单独的用例
3. 重新执行失败的用例
4. 根据其他的用例或用例集的运行结果执行相应的用例或用例集
除了这些以外可能还有其他的方法，主要是根据项目的需求来的，所以只需要满足特定的项目测试需求就可以了，不必全部都实现。
状态监控
在脚本执行的时候，框架应当能够实时监控脚本的运行情况，如果碰到运行故障的时候应当能进行基本的容错恢复处理，这样的话不至于使脚本处在一个被block的状态，从而浪费大量时间。
测试报告
不同的应用程序往往会有不同的测试报告的要求，有时需要把许多用例集的运行结果结合起来（总的运行报告）看，多少个成功，多少个失败，通过率多少；有时又要看单独一个用例的执行情况，哪一步失败，失败原因是什么。
另一方面，多样化的测试报告表现形式也是需要考虑的。Excel、word、
web、pdf、...等形式可以根据实际项目需要来选择，但不论做成何种形式都至少要保证测试报告的易读、易访问。
易调试性
一般情况下，调试(debugging)在开发测试脚本的过程中会占据大量时间，所以是否易于调试也是一个很重要的因素，直接影响到开发和维护框架的成本，不容忽视。
测试日志
一个好的框架应当能在测试执行过程中生产足够详细的日志信息（文字、截图等），这对于调试的帮助很大，同时也能我们快速定位到问题所在，节省时间。
易用性
易学易用对于自动化测试框架来说也很重要，因为毕竟是要面向最终用户的，如果框架很难上手，会失去用户群体，那框架也就没有存在的意义了。所以在保证易用性的基础上，最好有一个详细的框架说明文档，对于新手来说帮助会比较大。
灵活性
灵活性是指框架应当能保证在目前的基础上做二次开发的能力，这个其实跟
软件开发的标准是一样的，预留足够的可扩展性以便未来的版本升级。
性能
框架设计不宜过于复杂，太复杂的框架会增加脚本的加载、运行时间，从而导致运行脚本的效率低下。所以在设计框架的时候，也要考虑到性能这一因素。
引用外部工具
有一些外部工具本身就提供了自动化接口的，我们不妨可以把它融入到框架中，可以省去不少工作量。比如，经典的QTP+QC框架。
编码规范
好的编码规范能使脚本易读、易维护、易管理。下面列出了一些点：
1. 变量、常量、函数、文件、脚本的命名规范
2. 函数、函数库的注释规范
3. 对象命名规范
而所谓自动化测试的概念是通过模拟人工操作，完成对被测试系统的输入，并且对输出进行检验的过程，是由软件代替人工操作并对被测试系统的 GUI 发出指令，模拟操作，完成自动测试过程。
其实业界并没有对于自动化测试给出统一而全面的概念，以上的定义更多是从GUI（GraphicalUser Interface 图形用户界面，又称图形用户接口）层面自动化这一角度给出的。随着对自动化测试探索的不断深入，分层自动化测试，接口自动化测试，
移动设备的自动化测试，也越来越受到重视。
针对不同的行业，不同的业务系统，甚至不同公司的软件**度以及测试人员
技术能力等综合考量，设计出最适合公司现阶段并考虑后期技术层面扩展和维护，和人力成本等方面考虑的测试解决方案才是适合的，有效的。
言归正传，简述一下我所设计的针对公司现阶段的自动化测试框架的理由和想法
设计思路如下：
1.采用关键字驱动的设计思路来设计适合我们自己系统的自动化框架。
2.采用 Excel 文件来作为承载自动化的测试用例（Test Cases）的载体。
而针对测试用例的设计思路，也倾向于将手工测试用例和自动化测试
用例设计成共用的形式。
具体说明：
1.关键字驱动设计的好处是，可以将业务逻辑和测试数据从代码中剥离出来。
使得程序代码部分的功能更为纯粹，即仅仅是一个读取测试用例 Excel 文件中测试数据，
并将对应数值，填入业务系统页面，或执行测试用例 Excel 文件中某一动作，在业务系统中正确地表示出来。
这样设计，大幅度减小了程序代码的维护量级，也使得程序框架和代码部分功能更为纯粹。
2.采用 Excel 文件来承载自动化的测试用例，是由于 Excel 文件在编辑时很灵活，方便，易于操作。
编辑测试用例文件，和步骤的顺序，就像组合积木一样，将不同动作组件按照一定的业务逻辑串起来。
降低了自动化测试程序使用及维护的难度和门槛，使得更多的人可以参与进来。
从而总体降低了自动化测试程序使用、维护和人力资源的成本。
Q&A 为什么没有考虑使用
QTP，Watir，TestNG？
1.相对于QTP，SilkTest，TestComplete等这里收费软件，毫无疑问Selenium有着巨大的成本优势。并且对于Web自动化的测试，Selenium从技术层面已经完全可以满足要求。个别金融行业的公司或者IT部门依然愿意使用收费软件，恐怕跟金融行业的一些旧有习惯和改造成本已经公司政策等有关。这里不作讨论。
2.在选型过程中，比较了开源技术解决方案，最终采用Selenium而没有使用Watir是因为：第一，待测系统是由Java实现的，在自动化测试的实现解决方案是应与待测系统的技术体系保持一致，以便后期的维护和可以获得的支持。第二，Selenium技术拥有强大的技术类型公司所支持的维护更新，和较大用户使用群。
3使用自己写的小框架AWF（Action Words Framework 设计思路是关键字驱动的想法），而没有采用业界较为流行的TestNG框架理由是：第一，TestNG使用xml文件作为测试用例的调度，编辑起来并不方便，甚至有些晦涩。并且TestNG框架中，所有的测试用例（Test Case）全都需要程序员编码完成。毫无疑问，这对于测试人员的技术能力，和人力资源成本都提出了更高的要求。当然TestNG固然会有许多天然的好处和优势，比如对于以测试用例为颗粒度的测试结果验证，还有测试报告自动生成的便捷和美观等，而自己写的小框架必然也会有它在这方面的不足，但这些是可以通过完善框架代码来弥补的，并且我始终认为这恰恰的我们在实际的工作中对于具体设计实现问题的取舍。甚至可以这样说，选择怎样的技术体系不重要，选用什么样的计算机语言来实现也不重要，根据具体问题的需求来，重要的是思想。
自动化测试框架永远没有最好的，只有最适合的！
