自动化测试规范小结

自动化测试规范小结
2011年04月25日
　　自动化测试规范小结
　　发布时间: 2009-9-21 15:19    作者: 麦兜兜    来源: 新浪博客
　　字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖 
　　摘要
　　学习QTP自动化测试有些日子了,前段时间也介入项目组推进自动化测试,越来越强烈地感觉:自动化测试进程中，工具只是辅助角色，规范才是主导因素。正所谓 "兵无常势，水无常形。"没有大家共同认可的硬性标准，就很难规范自动化测试过程中的测试行为。因此，在自动化测试开始之前，我们应该来一起探讨，我们需要共同讨论、约定、而后遵守哪些规范。
　　1） 自动化测试的执行策略如何制定；
　　2） 自动化测试的脚本执行时机、执行人员、是否多机执行；
　　3） 脚本发现的缺陷如何提交、如何制定自动化测试的缺陷管理流程；
　　4） 自动化测试过程的资源如何管理、维护；
　　5） 需求发生变更时，测试资源同步变更。
　　这里主要对自动化测试过程的资源管理维护作和需求变更规范说明。测试过程的资源有：测试脚本、测试操作、库函数、场景恢复、测试数据、对象库等。
　　1、对象库管理规范
　　对象仓库的管理要满足以下几个原则：
　　1） 每个Browser下的Page或Windows不要太多，即使系统都在同一个IE窗口下（没有弹出新IE），也可以分几个Browser管理。把业务上关联较强的几个Page或Windows放在一个Browser下。
　　2） 制定统一的对像命名规范，对象按照所代表的业务属性命名，最好用中文。不要出现一些晦涩难懂的字符，比如abc。
　　要生成一份命名规范对照表，原始对象名---使用对象名。
　　3） 避免在一个tsr文件中堆放过多的对象，根据业务流程把对象分为几个tsr文件保存。这里没有统一标准，以每个tsr文件结构清晰为宜。
　　4） 避免每个测试脚本单独对应一个对象库，要求所有的脚本对应一个或几个对象库，并且对象库之间的对象唯一区分。
　　2、测试脚本规范
　　2.1 信息文档化
　　为了使测试脚本更容易维护，必须文档化所有测试脚本相关执行信息。这些信息在头文件中体现，头文件包含：
　　1） 脚本支持的业务范围、函数的功能；
　　2） 脚本中的变量、参数数量、数据的格式，例如日期格式；
　　3） 脚本的作者、创建和修改日期；
　　4） 所有依赖的测试脚本。
　　脚本头文件格式：
　　'------------------------------------------------- -----------------------------------------
　　'      Script:                   城市住宅电话_新装
　　'      Author:                  ****
　　'      Create Date:           2009-08-08
　　'      Modify Date:       2009-09-08
　　'      Version:           A-01
　　'      Description:
　　'      Remark:          该处说明本脚本需额外注意的事项.
　　'------------------------------------------------- -----------------------------------------
　　库函数头文件格式：
　　'------------------------------------------------- -----------------------------------------
　　'      Function:               连接数据库
　　'      Author:                  ****
　　'      Create Date:           2009-08-08
　　'      Param1 Name="*** " Type="String"；Param2 Name="*** " Type="String"
　　'      Return Name="*** "  Type="String"
　　'      Callby：         城市住宅电话_新装、城市住宅电话_变更……
　　'      Description:       连接数据库，根据传入SQL参数查询数据，最后返回数据
　　'      Remark:          该处说明本函数需额外注意的事项.
　　'------------------------------------------------- -----------------------------------------
　　2.2 操作和业务分离
　　QTP在组织测试逻辑时，提供了 Testcase和Action两种结构。这两种结构是包含和被包含的关系：一个Testcase可以包括多个Action。将可复用的业务实现分割为独立的Action。每个Action都有自己对应的object repository；Action可以设置为reused，进行复用；每个Action都有自己DataSheet；测试用例的相互调用，也是通过 Action来进行。而Testcase按照实际逻辑对众多Action进行组织，同时提供公共设置的管理，如设置使用到的函数库，错误现场恢复，测试使用的相关参数设置。
　　2.3 数据和脚本分离
　　测试数据是测试中非常重要的资源。测试脚本可能要移植到不同的测试机或测试环境中执行，也可能AUT（被测试的系统）版本需要升级，更重要的是我们需要模拟实际用户用不同的数据类型测试相同的业务，因此需要修改相应的测试数据。所以，将测试数据全部硬耦合到测试脚本中的做法不可取，需要合理处理好测试数据和测试脚本的分离问题。
　　将事先准备好的测试数据存储在EXCEL文档中，供测试脚本调用。定期对测试数据更新，以保证测试的有效性。
　　2.4 总结
　　通过头文件的说明，相关人员可以快捷地了解脚本或函数的相关信息，对后续脚本代码的执行、维护都能达到事半功倍的效果。实现操作和业务分离、数据和脚本分离，能有效地避免"牵一发而动全身"。
　　3、需求变更
　　在实际工作中，脚本绝不是一成不变的，而是随着需求和页面的变化而不断修改的。如果每次需求变化，都重新录制脚本，成本极高。所以最有效的方法是，先修改对象仓库，然后修改脚本，以适应新的系统。
　　这种方法的前提是，对象仓库的管理符合对象库管理规范。
　　4、其他
　　最后再对第一章概述中提到的其他问题作些补充说明。
　　自动化测试用例的选取：一般自动化测试的系统版本要比较稳定，否则要花费大量时间维护测试脚本。自动化测试的业务逻辑应该相对简单，一般情况下是对AUT的正面测试。在实际工作中，本着节省成本的原则，可以直接抽取手工测试用例中的正面测试用例作为自动化测试用例。
　　自动化测试工具和测试管理工具提供了缺陷邮件通知，或缺陷自动登记功能，但不建议启用。若自动化测试报告提示发现缺陷，应该先手工测试确认是否是程序BUG，然后再根据实情决定是否提交BUG。
　　-------------------------------------------------- ---------------------------------------- 如何学习自动化测试技术小谈
　　发布时间: 2009-9-15 15:05    作者: 未知    来源: 51Testing博客转载
　　字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖 
　　现在越来越多的人想步入自动化测试领域，大家要小心，虽然自动化测试很诱人但也很打击人。首先，想从事自动化测试，必须先了解What/Why/How，也就是常说的去了解什么是自动化测试、为什么要进行自动化测试、该如何进行自动化测试，这些基本的知识是必须的。
　　其次，需要根据项目的特点，选择合适的自动化测试工具。以QTP为例，对于初学者，大多数都是通过录制的方式来生成脚本，这个是基本是必须掌握的。然后呢？当然就是拔高了：
　　1）QTP是如何去识别对象的，对于新手经常会出现录制的脚本回放的时候报错的现象，这个时候就应该考虑为什么呢？
　　2）去掌握一些QTP对象的方法，如GetROPreperty、GetTOPreperty、ChildObjects等等
　　3）什么是环境变量？环境变量是如何建立和使用的，环境变量在参数传递中和action参数、test参数有什么不同
　　4）了解检查点的知识，并搞清楚在什么时候该如何使用检查点
　　5）掌握对象库的操作，了解对象库对于测试的意义
　　这几个问题都搞清楚的话，那基本就能够利用QTP生成正确的脚本了，当然以上只是部分必须掌握的内容，其实还是很多细节的设置，就需要在实际运用中去掌握了。
　　接下来，就可以进一步提升自己的QTP运用水平了，这个阶段就需要去学习vbs知识和如何运用描述性编程实现脚本了，同时在这个过程中还需要去学习以下知识：
　　1）VBscrīpt的基础知识
　　2）熟练掌握XML技术、excel、word等API对象，可以根据需要创建日志等
　　3）熟练掌握DOM和HTML知识，能够结合这些技术对Web页面进行解析
　　4）掌握数据库的基本操作语句，能够利用ADO对象进行数据操纵
　　5）熟练掌握正则表达式，很多时候处理对象问题相当方便
　　6）能够利用QTP的自动化对象模型创建出需要的运行模式
　　7）掌握WMI知识
　　接下来就需要考虑自动化测试框架问题了。如：
　　1）如何有效的管理并调度脚本
　　2）如何实现脚本运行的无人值守，测试过程中能够自动进行错误处理并进行日志记录
　　3）如何生成简介明确的测试报告
　　4）如何能够更加高效的维护测试脚本
　　5）实现框架代码和业务代码的分层、业务脚本和业务数据的分离
　　这些过程都是相当艰难的。当然各个公司项目的实际情况不同，导致设计出来的思想不同。我和大家一样在摸索中前进，在前进中跌倒，在失望中绝望，在绝望中失望。
　　总之，学习自动化测试需要在实际项目中进行，必须去实践才能，开始是会很头疼的，慢慢的就会熟悉并爱上她。让我们慢慢来吧。
　　-------------------------------------------------- ------------------------------------------
　　我的自动化测试学习之路
　　发布时间: 2009-10-14 15:08    作者: waylight    来源: 51Testing博客
　　字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖
　　做自动化测试大半年了，虽然是一份实习的工作，但是做的全职的活，学到了不少知识，我就慢慢说起，我的测试开始之路。
　　进公司之前，我一直学的JAVA，实习面试的时候也考的JAVA方面的知识，可是进去后却做起了测试，最开始有种受骗的感觉，觉得开发才是自
　　己想做的，测试太简单，没有技术含量，学不到东西……
　　苦于自己没有工作经验，待在学校自学没有效率，于是硬着头皮，开始了测试的学习。公司管理不严格，气氛比较活跃，工作和学习都很自由。
　　通过和同事交流和学习，很快我就对测试的基础知识有了一定的了解，对公司的业务和产品有了一定的认识，然后开始学习自动化测试。
　　自动化测试工具是公司自研的，我所做的工作就是写自动化脚本，进行单元测试和回归测试，分析测试BUG，和开发人员沟通出现的BUG，发测
　　试报告。看起来是个简单的活，可是做起来还是很花时间和精力的。总结起来有如下几点：
　　1、首先要熟悉业务方面的知识，产品方面不熟悉，写出的脚本错误百出。
　　2、其次是脚本的学习，我用的是TCL语言，语言比较简单，学起来很快，还有它的扩展iTCL,也是面向对象的语言（就像C++是C的扩展一样）。
　　3、接着是测试的执行，测试用例的分配，测试环境的选择，在有限的时间内测试用例的覆盖，都是需要思考的。
　　4、然后是测试结果的分析，是测试用例问题，还是自动化测试脚本错误，还是产品的缺陷，又或者测试环境或脚本语言的错误，这些都要仔细分
　　析，经验在这里就显得尤其重要了。
　　5、最后是发送测试报告，发报告虽然比较繁琐，却是很重要的，它是工作执行结果的反映，也体现了当前自动化测试的情况。
　　总的来说，自动化测试的工作是比较多的，与开发人员和测试人员的沟通也很重要，毕竟是处在他们之间，协作好才能提高工作效率。
　　最后来说一下测试的地位，测试在行业内的地位比开发低，是不可争议的事实，国内的公司大多如此，对测试工作的误解，更加剧了这个现状，
　　自动化测试的地位就更低了。我所在的公司测试人员很多，算是对测试比较重视的，可我们搞自动化测试的只有不足十人，自动化测试的作用还没有
　　完全发挥出来，虽然经过我们的努力，有了很大的发展，可是还是不够的。微软的测试，绝大部分是自动化测试，对比一下，自动化测试还是有很大
　　的发展空间的。
　　希望自动化测试发展的越来越好，测试的同胞们对工作越来越有信心，希望测试行业在国内发展壮大。
　　-------------------------------------------------- -------------------------
　　如何正确理解自动化测试技术
　　发布时间: 2009-10-13 15:44    作者: 朱少民    来源: CSDNBlog
　　字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖
　　谈到自动化测试，一般就会提到测试工具。许多人觉得使用了一、两个测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的
　　确，测试工具的使用是自动化测试的一部分工作，但"用测试工具进行测试"不等于"自动化测试"。那什么是"自动化测试"？ 半自动化测试过程
　　，算不算自动化测试？是否可以为"自动化测试"给出如下定义？
　　以自动化的方式完成测试？
　　测试过程的自动化？
　　将手工测试的过程变成了自动化测试的过程？
　　摆脱手工测试的各种途径和方法？  自动化为测试而存在的，所以自动化测试的真正含义可以理解为"一切可以由测试是相对手计算机系统自动完成的测试任务都已经由计算机系统
　　或软件工具、程序来承担并自动执行"。它包含了下列3层含义：
　　"一切"，不仅仅指测试执行的工作--对被测试的对象进行验证，还包括测试的其它工作，如缺陷管理、测试管理、环境安装、设置和维护等。
　　"可以"，意味着某些工作无法由系统自动完成，如脚本的开发、测试用例的设计，需要创造性，其工作需要手工处理。
　　即使由系统进行自动化测试，还少不了人的干预，包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。
　　严格意义上，"自动化测试（Automated Testing）"不等于"测试自动化（Test Automation）"。自动化测试，模拟手工测试步骤，通过执行程序
　　语言编制的测试脚本自动地测试软件，自动地实施软件的单元测试、功能测试、负载测试或性能测试等。自动化测试集中体现在实际测试执行（test 
　　execution）的过程，也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试，强调借助工具（不仅仅是工具，
　　有时包括策略和工件）来完成测试的执行，也就是用工具来帮助或辅助测试，这个执行过程可能是全自动的，也可能是半自动的。
　　测试自动化的要求高得多，侧重说明将测试用自动化设计和实现的过程，即所有的测试工作都能有计算机系统自动完成，包括：
　　测试环境的搭建和设置，如上载安装包到服务器；
　　脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本；
　　测试数据的自动产生，例如自动产生数据负载测试所需要的大量数据；
　　测试操作步骤的自动执行，包括测试执行过程的控制；
　　测试结果分析，实际输出和预期输出的自动对比分析；
　　测试流程的自动处理，即测试工作流的自动实现，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等流程的自动化处理。
　　测试报告自动生成功能等。
　　这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界，但是很难实现的。往往不能
　　完全通过全自动化过程来完成一个完整的测试任务，自动化到不需要人工参与的程度是不现实的。虽然不能完全实现那种理想境界，但是我们每时每
　　刻可以向这个方向去思考，优化每项工作，一切可以由计算机系统自动完成的测试任务都已经由计算机系统或工具来承担并自动执行。
　　在一般情况下，人们并不严格区分"自动化测试"和"测试自动化"，就是通过工具或程序来对软件进行测试，一般不需要大量的手工操作来完
　　成测试，而只要很少的人工干预。自动化测试，理应从工作效率和产品质量的目的出发，而不是为了自动化而自动化，在某些时刻，也可能得不偿失
　　，即投入过大，产出远远小于投入。脱离了目的，测试人员可能会变成自动化测试的奴隶。奢想做到百分之百地实现自动化测试，不仅不现实，所引
　　起的代价可能会非常大，而且可能引起负面性，造成质量水平的降低。
　　最后，我们还不得不承认，自动化测试和手工测试往往交织在一起，相互补充，工具执行过程往往需要人工分析，手工测试时也可以借助工具处
　　理某些数据、日志或显示某些信息。也就是说，不是试图用自动化测试来代替所有的手工测试，而应该在尊重手工测试的同时，尽量采用自动化测试
　　，根据各自的特点充分发挥各自的优势，使手工测试和自动化测试实现完美结合。（以上言论仅代表作者的个人观点，不代表51Testing观点）
　　-------------------------------
　　国内软件自动化测试现状分析及展望
　　发布时间: 2009-9-25 16:36    作者: 未知    来源: 51Testing博客转载
　　字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖
　　在软件测试日新月异发展的今天，自动化测试正在成为软件测试领域里的一个非常瞩目的趋势和潮流，很多软件公司正在或已经在企业测试团队
　　内部实施软件自动化测试流程和框架，同时也把自动化技能作为人才衡量和业绩考核的重要技能指标，这些都不是偶然的事情，因为：
　　1. 软件质量的重视和提高
　　软件产业虽然只有短短几十年的历程，但是其应用范围已经从最初的科研专用转变为渗透入我们社会中生产生活各个方面，起着非常重要的作用
　　，我们人类社会对软件的依赖正在越来越强，根据牛顿第的反作用力定律，那么软件问题对我们的影响也在越来越大。比如2007年发生的奥运订票网
　　站在开通首日不能登陆的问题，导致上百万人购票失败；中国工商银行黄金交易系统出现漏洞，两名大学生通过低买高卖获利三千多万元，这样的新
　　闻在报纸或网络上还能找到更多，要避免这样的事情发生，就要使这些问题能够在软件上线之前被发现和解决，换句话说，软件质量必须要提高，而
　　软件测试就是保证软件质量的一个重要并且非常有效的手段。因此现在软件公司越来越重视软件测试，体现在老板那里就是对软件测试"舍得花钱，
　　舍得投人"，测试执行起来就是"多测"，"测多"，"多测"就是时间上测试执行频率加快，以前一个版本测一轮，现在一次编译就要测一轮，"
　　测多"就是测试更加完整，覆盖更多的功能模块。这就为软件自动化测试提供了强有力的需求和生长空间。
　　2. 软件系统规模的扩大，复杂性的提高
　　我们记得在单机系统时代时，几千行代码就能写出一个商业软件，比如WPS，CCED这些一代软件枭雄。但随着网络时代的到来，分布式系统的发
　　展，软件系统 越来越重视交互和协作，多个模块服务的交叉调用，网间的交互安全等等，这大大提高了软件系统的复杂度和规模。Oracle曾经开发过
　　一个邮件客户端 Outlook的插件，这个插件是安装在outlook上，提供一些常用功能，比如收发mail，calendar创建等等。但oracle的测试部门仅 仅为这个
　　插件就设计了6000多个test case！这个数目是如此巨大，使得测试执行和产品周期产生了深刻的矛盾。这个矛盾体现在：当每个新版本发布时，如果做
　　一遍完整测试，一个人手工测试执行一遍6000多个test case就要半个月，而产品版本的发布周期也就一周左右，也就是说测试的速度远远跟不上产品的
　　发布速度。在这种情形下，如果没有自动化测试帮忙，手工测试只能望洋兴叹了！
　　以上两个软件的根本现状，决定了软件测试自动化的趋势不是人云亦云，昙花一现，而会蓬勃发展，强劲有力，成为势不可挡的潮流。很多软件
　　公司已经看到了这个 潮流，很早就开始做软件自动化测试的预研和实施，比如微软，oracle 等已经在企业内部测试团队整合了自动化测试流程，实施
　　了自动化测试框架，并且已经按时更新换代，进入稳定应用的周期。但在国内，由于软件自动化测试时间不长，测试人员技能水平等因素影响，软件
　　自动化测试的研究和实施大多还处于一个起步摸索的阶段，我们看到普遍的情形是"做的人不少，成功的不多"，这种现状一方面有技术的问题，另
　　外也有方向上的问题。因为在业界可供借鉴的成功实施经验或案例比较少，所以在起步阶段可能就会走弯路，这是摸索必然要付出的"学费 "。
　　那么怎样能够把握软件自动化测试方向和思路呢？下面笔者结合业界的现状分析，以及未来展望，对软件自动化测试的作出三个层次的划分：
　　第一阶段：测试的自动化
　　这是最原始的起步阶段，其目的就是将原先手工测试所作的工作转化为自动化代劳。显著的特征就是以工具为中心，比如QTP的应用，原先靠人
　　工来执行的测试案 例，比如点击，录入等，现在由QTP来完成，如果QTP不能支持我们的系统，我们就要寻找解决方案，或改用其他工具，总之大多
　　数的自动化工作重点是在每个 case上，也就是技术层面上的问题。但随着技术上的解决，自动化测试规模的进一步增大，我们很快就面临下面的问题
　　之一或全部：
　　1. 自动化测试脚本的类型和数量越来越多，怎样有效管理和复用这些脚本？比如有1000个脚本，有QTP的，有Winrunner的，还有perl的等等，每种
　　脚本又实现了多个case，那我们怎样统一管理和调度这些脚本，使之能够组成一个大的自动化测试目标？要知道单个的测试脚本和单个的测试案例一 样，对于公司的老板来说，他们是不关心这些细节的，只有它们组合起来成为一个壮丽的图本，才能体现出来它们的价值。也许老板们刚开始对自动
　　化的执行感到新奇和惊喜，但当他们意识到这些并不能为他带来什么价值时，他就会厌倦并放弃。
　　2. 自动化测试如何与手工测试整合？我们知道自动化测试是不能100％完全替代手工测试的，那么自动化测试必须要和手工测试整合在一起，才能
　　反映出其价值。这 意味着，自动化测试要全方位和手工测试执行，包括前期的案例管理，测试的执行，以及最后的报告呈现。
　　这些问题是助产士，它们促成软件自动化测试第二个阶段的到来。
　　第二阶段：自动化的测试
　　如果说第一阶段是在一个点上下功夫，那么第二阶段就是在一条线上作战了。"自动化的测试"的内涵更加丰富，它意在将软件测试里的所涉及
　　的各个环节作为一个统一的整体考虑，从测试案例的管理，测试案例的执行到测试报告的展现都有相应的策略及自动化实现，故称"自动化的测试"
　　。在这里，自动化测试框架横空出世，自动化测试框架是一系列策略思想，规范和代码的集合。它要解决第一个阶段的困局，就要回答下面这些问题：
　　1.怎样管理多个自动化测试案例？
　　2.怎样无人职守地运行测试脚本？
　　3.怎样呈现自动化测试报告？
　　AC（Automation Center）是"www.cesoo.com"提供的基于QTP的软件自动化测试框架，它的回答是：
　　1.回答：测试组件的创建和划分
　　2.回答：增强自动化测试的健壮性，提供re-run机制，抓图策略等等
　　3.回答：采用web服务接口和标准的xml技术，既可web页面展现，又可灵活地与手工测试报告整合
　　其中在Oracle等公司已经成功实施了AC，并取得了非常好的效果。
　　第三阶段：软件流程框架
　　这个阶段可以说是软件自动化测试炉火纯青的时候了，达到了"天人和一"，经过多年修炼，在这里软件自动化测试和软件开发再次做一个整合
　　，从自动化流程上， 能够达到真正的测试驱动开发，比如coding与unit testing做整合。目前已经达到这个阶段的有微软，IBM等。
　　目前国内软件公司软件自动化测试的实施情况大多处于第一阶段或从第一向第二过渡的阶段。所以我在下面着重谈谈软件自动化测试框架的设计
　　原则和一些风险的规避：
　　1.框架要集中精力解决自动化测试中的问题
　　看起来这是个很简单明了的原则，不是么？自动化测试框架本质是一个软件产品，它旨在满足自动化测试中的必然需求，而不是大包大揽软件工
　　程中所有的问题。我在某个测试网站曾看过一个测试框架的设计原型，真叫人叹为观止，从脚本代码的版本同步管理到bug的提交和存储，都通通塞入
　　框架解决方案之中，包罗万象，无所不能。我虽猜不中这框架的开始，但我能猜到这框架的结局，无非两种情形，要么技术资源不够而流产，要么实
　　施起来太过复杂，自动化成本大大高于产出，总之结局一个字：死。
　　一个经验丰富的自动化测试架构师应该既能够敏锐捕捉到当前自动化测试中的关键问题，又能巧妙利用现有企业资源为我所用，在上面的例子中
　　，可以把脚本版本管理工作交给企业中已有的源码管理系统，比如clearcase，Vss，把bug的存储交给bug管理系统，而框架集中精力解决自动化测试中的
　　无人值守运行，报告生成等问题，总之在框架设计的初期阶段，一个明确切实的实施目标是十分重要的。
　　以AC为例，紧紧以QTP自动化测试为中心，全力解决最实际最关键的问题：
　　1.自动化测试案例的管理
　　a）基于xml的测试组件的定义
　　b）基于xml的被测实例管理
　　2.无人值守的案例执行
　　a）案例关联关系校验，大大缩减自动化测试执行时间
　　b）Case级别Transaction的定义及实现，提供transaction的re-run和超时设定机制，从而减少因测试环境不稳定引起的失败
　　c）Recovery自定义机制，大大提高脚本的健壮性
　　3.基于xml的测试报告和测试日志
　　a）Xml标准，极强的扩展性，提供标准接口，用户可二次开发与手工测试报告进行合并，或直接写入数据库。
　　b）灵活的抓图机制，所有抓图最后生成一个网页，作为测试报告的一部分提交。
　　2. 框架设计中的扩展考虑
　　毫无疑问，自动化测试框架是一个软件，在设计时同样遵循软件设计原则：模块的高内聚和低耦合，这些都是基本原则，不再赘述。需要注意的
　　一点是由于框架作为企业环境的一部分，必然涉及与其他系统的多种接口，比如和case数据库连接实现自动化测试案例自动获取，和mail服务器连接实
　　现邮件实时通知，和 bug数据库连接实现bug的自动提交，因此，在接口设计上要尽量保证扩展性和兼容性。
　　AC采用的数据接口为xml，这有两个显然的好处：
　　1.xml是数据存储的标准规范，可与其他系统保持非常强的兼容性
　　2.xml的utf-8可支持多种字符，不用担心乱码的问题
　　3.框架实现中的数据驱动思想
　　数据驱动在这里有两层意思，第一，框架实现上完全数据驱动，不能存在hard-code的问题，比如被测server信息，测试案例等信息以 xml配置文件
　　的形式放在框架外面，要换个server或运行另外一套测试案例，只需更改xml文件即可；第二，框架要提供规范和策略，使得脚本同样必须遵守数据驱
　　动的原则。
　　AC提供excel数据全局加载机制，所有的数据都可以放在外部的excel里，AC会在case运行时加载数据，case则只需调用接口即可获得数据，数据驱动
　　实现十分方便。
　　自动化测试与手工测试流程的整合：
　　我们的企业不是试验的学校，也不是花拳绣腿的作秀场，在企业里做事往往从务实和实际效益出发，以结果为导向，因此，"自动化测试"在我
　　们看来，重点在"测试"，而"自动化"只是一种手段而已。我们更关心测试整体的效果，不是么？
　　下图是自动化测试与手工测试的整合流程，在此流程架构中，自动化测试以smoke test为中心，旨在保证产品版本的稳定性；手工测试以negative test
　　为中心，意在验证产品的功能和健壮性。两种测试互为补充，相得益彰，大大提高了测试整体的效益。
　　-------------------------------------------------- --------------------------------------------------- -----------------