自动化测试实施策略
 

 采用5W2H分析法
 

 
 
 

  
 

   （1） 
  WHAT——是什么？目的是什么？做什么工作？
 
 
 

   （2） HOW ——怎么做？如何提高效率？如何实施？方法怎样？
 
 
 

   （3） 
  WHY——为什么？为什么要这么做？理由何在？原因是什么？造成这样的结果为什么？
 
 
 

   （4）
  WHEN——何时？什么时间完成？什么时机最适宜？
 
 
 

   （5） WHERE——何处？在哪里做？从哪里入手？
 
 
 

   （6） 
  WHO——谁？由谁来承担？谁来完成？谁负责？
 
 
 

   （7） 
  HOW MUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？
 
 
 
 我们在制定自动化测试实施策略时，首先应该考虑其中可能存在的风险。
 
 1．自动化测试时间不充足
 
 2．对自动化测试期望过高
 
 3．缺乏自动化测试实施的经验
 
 4．自动化测试工具更新过于频繁
 
 5．自动化测试工具对软件测试本身没有起到帮助作用
 
 6．  当我们有了针对自动化测试实施风险的准备后，就可以开始考虑：
 
 6.1  需要在什么阶段开始启动自动化测试？
 
 在何时启动自动化测试，每个公司的情况都不同。有的公司是在测试用例都手工执行过并且测试用例不再修改时，再开发相应的自动化测试脚本；而有的公司则是在开发测试用例的同时，就进行脚本的开发。如果团队中测试用例的设计者是一个有着丰富测试用例设计经验的工程师，他所开发的测试用例是高效的，未来改动较少，则可以考虑在开发测试用例的同时，同步开发自动化测试脚本。如果团队中测试用例的设计者是一个测试用例设计经验不丰富或是设计的测试用例质量不高效的人，其开发的测试用例需要在后期经常进行许多的改动，则还是考虑等到测试用例本身稳定后，再开始脚本开发。
 
 6.2  自动化测试的人力投入方式如何？
 
   大部分公司是由专人进行自动化测试脚本开发的，少部分大公司则是全民开发自动化测试脚本。这两种方式都各有利弊：专人进行脚本开发，优点是开发脚本的专业技能可以不断地得到强化，开发效率大大提高；缺点是由于对开发模块的测试用例了解并不深入，有可能开发出的自动化测试脚本只是“翻译”测试用例，发现bug的概率较小。而有的大公司，由于员工的整体素质较高，通常都具备一定的开发能力，则由每个模块的手工测试者自行开发自动化测试脚本。虽然，手工测试者脚本开发的熟练程度没有专门的脚本开发者熟练，但是由于手工测试者是最了解测试用例真谛的人，因此他开发出的测试脚本就不仅仅是“翻译”，而可能是对测试用例的“升华”，其测试脚本发现bug的概率会更大。
 
 如何执行测试脚本才更高效？
 
 （1）N个测试环境同步并行执行测试脚本，可以将自动化测试脚本执行的总时间成本降低为1/N。
 
 （2）由专门的自动化测试执行工程师来执行批量的自动化测试脚本。自动化测试脚本运行失败的前3大因素大致为：
 
 Ÿ测试环境问题
 
 Ÿ脚本错误
 
 Ÿ被测目标出现bug
 
   由于专门的自动化测试执行工程师对大量失败的脚本分析经验的积累，通常可以非常高效地定位脚本失败的原因，提高自动化测试脚本执行的效率。
 
 （3）独立的自动化测试环境供脚本执行团队使用。如前所述，测试环境问题是测试脚本失败的原因。而测试环境影响测试脚本执行的两大杀手：一个是测试环境被前一个失败脚本破坏而未还原；另一个则是测试环境被其他项目的同事给破坏了。对于第一种情况，我们可以在测试脚本的代码结构中加入足够的系统恢复代码来解决；对于第二种情况，则只有依赖于公司领导的政策支持，是否愿意腾出足够的测试环境给自动化测试执行小组专用。
 
 （4）在测试脚本中加入丰富的脚本失败的定位信息。自动化测试脚本一旦失败，我们就只有依靠脚本自身打印的信息进行定位了，定位问题的速度快慢除了依赖脚本执行人员自身的经验外，更依赖脚本中是否有着丰富的脚本打印信息。
 
 （5）使用自动化测试基线软件版本。当出现大批量测试脚本失败的情况时，可以在排除了测试环境问题后，直接把这些失败的测试脚本在基线软件版本中运行。如果在基线版本中运行全通过了，则证明脚本失败原因是产品新bug引起的，而不用逐个地去阅读这些失败测试脚本的源代码来分析脚本自身原因。

这部分主要介绍如何基于当前框架创建一个全新的自动化项目，我们约定项目路径在F盘下，项目名称为AutoProject。
 
1.1. 目录创建
 
在路径：“F:\自动化测试管理\框架使用说明\项目初始化模板”下双击“双击生成新项目.vbs”文件，输入【AutoProject自动化测试】点确定。
 
 
 
执行初始化后，可以在路径：“F:\自动化测试管理\自动化测试项目”查看到新增的项目。
 
1.2. 报告数据库配置
 
目前报告服务器的地址为10.35.60.1。账号：hyholine 密码：Aa123456。在数据表【list_project】中添加一条项目的信息。
 
 
注：如果在此处添加记录，则执行报告结果插入到数据库时会失败。
 
1.3. 新建测试用例脚本
 
在充分阅读需要和测试用例的基础上，安装TD中用例组织的结构，在目录【F:\自动化测试管理\自动化测试项目\AutoProject自动化测试\AutoProject】下创建测试集和测试用例。
 
 
1.4. 配置脚本环境
 
1.4.1. 加载公共函数文件
 
1) 在QTP工具打开菜单项Tools-Options，找到Folder项：在此处添加存在函数库或对象库的文件夹路径。目的是其他配置的文件路径可以使用相对路径，相对路径会在此处配置的绝对路径下搜索匹配的文件。
 
 
2) 在QTP工具打开菜单项File-Settings，找到Resources项：在此处添加公共函数文件，默认存放在目录【公共函数库】下，如（F:\自动化测试管理\自动化测试项目\AutoProject自动化测试\公共函数库）。注：全局函数文件GlobalFunction.vbs存放在目录【Global】下，如（F:\自动化测试管理\自动化测试项目\Global）。
 
 
1.4.2. 加载公共对象库文件
 
1) 在QTP工具打开菜单项Resources-Associate Repositories，在面板上添加公共对象库文件，并把相应的Action脚本从左侧列表添加到右侧列表中。默认存放在目录【共享对象库】下，如（F:\自动化测试管理\自动化测试项目\AutoProject自动化测试\共享对象库）。
 
 
1.5. 编写脚本
 
根据需求文档和测试用例的要求设计脚本。原则上，在编写脚本之前务必详细阅读需求，在了解需求的基础上，再分析测试用例的设计结构，充分考虑测试的设计结构是否满足脚本的可实现条件。正常情况下，在分析完需求和用例后，脚本的设计雏形在脑海中应该就完成了。
 
1.5.1. 分析需求和用例需要考虑如下5点：
 
1) 需求的描述和用例是否一致，是否有遗漏，矛盾，冲突等情况。
 
2) 脚本的设计是否可以使用用例设计的结构（一般是可以的），如果不行，就要自己设计用例的脚本实现模式。
 
3) 正常一个功能点会有多个用例来覆盖，因此需要考虑多个用例是否可以整合成为一个脚本来覆盖。
 
4) 脚本的结构要优先考虑通过数据驱动模式，当然，脚本设计的原则是以最少的成本完成最大的用例覆盖。这里的成本包括当前的设计、编写、调试脚本的时间，也包括后期需要维护的时间。基于这个原则，如果数据驱动模式不容易实现，则采用逐个对应来覆盖。
 
5) 在阅读需求和用例过程中，要充分考虑每一个步骤和检查点在脚本实现上是否可行。因为如果某些步骤无法实现，则应该及时做出判断，不行就放弃实现。如果待到脚本编写了一半，才发现关键的功能点无法实现，那么就等着自我反省吧。另外，为了防止上述的问题，对于比较复杂的用例，最好是自己手工执行一遍，磨刀不误砍柴工！
 
1.5.2. 编写脚本时需要考虑如下7点
 
1) 脚本设计要考虑结构的合理性，例如：重复的业务逻辑，采用循环语句来遍历覆盖；对于可复用的业务动作或检查点要封装成函数；
 
2) 函数封装的原则，先查找现有函数库，存在已实现的用已实现，没有就考虑是否有可以扩展的函数，如果也没有就自己新建一个函数。
 
3) 新建函数的原则，不要仅仅考虑目前需求，也要考虑可扩展性。多多考虑你设计的这个函数在将来可能会用到的地方，涉及其他功能的调用，在不同场景下的调用。
 
4) 执行测试用例强调思维的发散，即在按照用例设计执行的基础上，发挥自己的想象力，结合需求上功能点进行交叉测试。那么在设计脚本上，也是可以借鉴，在保证基础功能点检查覆盖外，也可以加入自己认为有必要检查点。另外，对于用例中非重要检查点，脚本实现困难时可以选择不覆盖，但是，需要在对于的用例上加以说明。
 
5) 检查自己编写的脚本排版是否美观。
 
6) 对于复杂的步骤需要加以注释说明。
 
7) 创建函数的命名是否符合规则，是否达到见其名知其义。
 
1.5.3. Vbs编写命名规则
 
1) 常数命名规则
 
全部字母大写，多个单词用下划线 (_) 分隔。
 
例如： USER_LIST_MAX 、NEW_LINE
 
2) 变量命名规则
 
驼峰命名法。
 
例如：UserName、Passwd
 
3) 形参命名规则
 
全部字母小写，多个单词用下划线 (_) 分隔。
 
例如：user_name, passwd
 
4) 函数命名默认规则
 
动作函数、使用首字母小写驼峰命名法
 
例如：getEmailName、setNewUserEditValue
 
检查函数、使用check开头的驼峰命名法
 
例如：checkMailListBySubject、checkWriteMailMessage
 
5) 对象命名规则
 
如果是qtp对象，使用以objqtp开头的驼峰命名法
 
例如：objqtp_LoginPage、objqtp_WriteMail
 
如果是dom对象，使用以objdom开头的驼峰命名法
 
例如: objdom_SettingPage、objdom_PopMenu
 
6) 业务大模块函数命名规则
 
参考使用mod开头的驼峰命名法(根据业务的不同，可以采用不同的标示)
 
例如：mod_SendCommonMailBase、 mod_EditSettingValue_PageStyle
 
1.6. 脚本调试
 
代码调试是每个开发人员的基本功，良好对调试习惯和排错方法可以大大提高开发的速度。在实际生产过程中，需要针对实际情况选择最有效的排错方式，因此，针对VBS的代码调试排错，个人提出如下总结：
 
1) 在调试时需要在Setting窗口将错误处理选择弹窗模式，另外如果有on error resume next的语句，可能包含错误语句，可以先注释掉。
 
2) 在QTP中，首先需要排除语法错误，可以通过保存脚本或执行语法检查（快捷键：Ctrl+F7）判断脚本VBS语法是否正确，在底部对Information窗口可以查看到相应对错误信息，双击错误信息，可以定位到错误的脚本位置。
 
3) 认真分析执行中报错对信息，新手往往看到报错很紧张，没有认真阅读错误提示信息就关闭窗口进行调试，这是错的。错误提示信息是分析错误对第一手资料，同时也判断出错误对位置。
 
4) 设置断点、单步调试、输出变量、查看变量、执行调试动作等，这些都是常规对调试方法，可以有选择的使用。在QTP中，调试的功能还是比较不错的，基本满足调试任务对需要，相关的功能可以认真阅读分析Debug菜单项和Debug Viewer视窗。
 
5) 调试过程中，有些函数或业务模块过于复杂，可以将通过拆分，将认为可能存在问题对代码行拷贝出来单独调试。这样处理方式更有针对性，排除外部的干扰，降低调试对复杂度。
 
1.7. 设计数据驱动
 
1.7.1. 概念说明：
 
数据驱动是自动化测试框架中的一个重要思想，其目的是要让测试业务逻辑和测试业务数据剥离开，进行分别管理，所带来的最大好处是结构更清晰，维护更便捷。目前框架的数据驱动支持Excel和Mysql数据库的驱动模式，默认是Excel模式，Mysql模式需要另行配置。
 
1.7.2. 逻辑说明：
 
Excel驱动模式，通过函数方法【addExcelData】或【addExcelData_Action】执行数据加载，函数根据测试集名称和测试用例名称在Excel数据表【测试驱动数据表.xlsm】中搜索，判断存在相应字段信息则会加载到QTP的数据池中。
 
Mysql驱动模式，不建议使用，主要原因是从维护上到数据库编辑没有Excel方便。
 
1.7.3. 使用方法：
 
在脚本可以通过QTP提供的方法访问数据池中的数据，也可以使用框架封装的方法来访问（框架提供如下数据池操作方法）
 
1) 判断datatable表中是否存在指定的表 
 
2) existDatasheet(Byval sheetname)
 
3) 判断datatable指定表中是否存在指定的列
 
4) existDataParameter(Byval sheetname, Byval parametername)
 
5) 往QTP数据表中加载Excel数据主体函数，适用于默认加载Action  
 
6) addExcelData()  
 
7) 往QTP数据表中加载指定的Excel数据                                                                
 
8) addSpecifyExcelData(setname,casename)  
 
9) 通过封装，获取数据表中的值                                                                         GetData(Row,ParamaterID,SheetID)  
 
10) 返回特定的数据表中的某一列有效行数                             getParemeterRowCount(Byval paremetername, Byval sheetname)
 
11) 通过封装，获取特点字段对应的数据表中的值                     GetSpecialData(Byval reField,Byval reValue,Byval geField,Byval SheetID)
 
1.7.4. Excel数据表约定：
 
用例脚本的测试集名称    对应于  Excel表中的表名【测试集名称】 
 
用例脚本的测试用例名称  对应于  Excel表中字段【★测试用例名称】
 
 
举例：假设，新建测试集的名称(测试用例的父文件夹名称)为“MyTestSet”,测试用例名称为“MyTestCase1”。那么你需要在测试驱动数据表【测试驱动数据表.xlsm】中新建一张sheet表，命名为MyTestSet。在表中添加数据表，表的格式如上图，独立一行命名测试用例名称，在名称前加上小星星图标，表示该值为用例名称，中间部分根据脚本需要添加相应的数据，在末尾独立一行填入结束标示符【◆◆◆◆】，表示当前的用例数据加载到此为止。
 
1.8. 设计公共函数库
 
1.8.1. 概念说明：
 
为什么要写函数？为什么要定义函数库？函数封装本质是体现分工协作的关系，写的人关心函数的内部实现过程，保证功能的实现正确和健壮性。而使用的人仅仅需要函数提供的接口和返回值。这好比你想有辆车，不需要了解内部构造，但是要懂得如何驾驶它。从计算机科学上，函数的封装也体现了开发语言的美，不想让自己成为搬码工的最好方法，就是学会创造、激发自己的灵感，让自己封装出的函数足够灵活强大。
 
1.8.2. 使用说明：
 
函数库分两类：
 
一类是用来支撑自动化测试框架和辅助脚本开发，命名为【GlobalFunction.vbs】；
 
一类是针对项目开发的功能函数集合，仅仅为当前的项目脚本开发服务，如：
 
动作函数集合（XXX_ActionFunction.vbs）
 
检查函数集合(XXX_CheckFunction.vbs)
 
对象函数集合(XXX_Object.vbs)
 
业务函数集合（XXX_Module.vbs）
 
配置函数文件（XXX_Config.vbs）
 
目前函数库文件的管理采用头部说明的方式，即在每份函数文件的头部编写函数的目录信息，方便搜索和查阅，在函数设计上需要检查如下10点：
 
1) 函数的编写风格是否美观，代码相应的缩进是否排布清晰。
 
2) 函数是否可以在现有函数的基础上扩展，如果可以尽量在现有函数的基础上扩展实现。
 
3) 函数命名是否符合规则，是否见其名知其义。
 
4) 函数中的内部变量是否有定义。
 
5) 函数中是否存在冗余的代码，即存在可以通过调用现有的功能函数来实现。
 
6) 函数是否充分考虑到功能的扩展和不同场景的使用。
 
7) 函数的功能是否正确，是否经过严格的调试和检查。
 
8) 函数定义为Function，是否有正确的返回值，对于不同的调用场景下是否有准确的数据返回。
 
9) 函数执行过程中，对于特殊情况是否有处理，例如，对象不存在或取值错误的情况下。即，函数的代码是否足够健壮。
 
10) 函数名是否会存在重名，如果存在重名会导致调用失败。 
 
1.9. 设计公共对象库
 
1.9.1. 概念说明
 
对象库顾名思义即用来管理测试对象。自动化测试最为核心的技术即对象的识别技术，不管哪个自动化测试工具，对象识别越厉害，吸引的使用群体就越多，市场占有率也就越大。所以说，对象识别既是自动化测试的基础，也是难点。QTP中对象库采用了树状文件式的管理方法，分为本地对象和公共对象。本地对象只提供给当前依附的脚本使用，不提供给外部的脚本使用，反之，公共对象，即一个独立的库文件，脚本需要就加载它使用，与之带来的好处，即全部的脚本对象管理仅需要维护一份对象库文件。
 
1.9.2. 论对象识别机制
 
QTP工具在管理对象库方面是成功的，对象管理的结构很清晰，也很简单，对于开发人员来讲易于管理和使用，例如：对象的关联方法、对象的定义、对象的识别处理机制。个人觉得这些都是QTP工具上的亮点。以前，网上论坛常有人在争论描述性识别对象方法和对象库识别对象方法的优劣之分，其实，在我看来，二者本无优劣之分，仅有在特定的情况下，那种方法更适用，更方便脚本的开发。此处，我总结下我的看法：
 
1) 描述性对象识别方法：使用简单、体现直观、易于理解、处理灵活，在小规模项目和简单的对象识别上可以考虑使用，但是前提是对象在后期不会变更，否则随之带来的是大量的维护任务。
 
2) 对象库识别方法，科学管理、识别机制更强大、适用于大型的自动化项目开发，多人协作模式，以及项目对象频繁变更的场景下。一般是推荐使用对象库来管理识别对象，更有利于整个项目的管理。
 
上述二者之关系，好比一个是摩托车（描述性方法），一个是轿车（对象库管理），都可以用来处理对象识别，因为他们都是用发动机引擎，不过发动机的引擎规格不同，决定了它们的性能不同。摩托车固然灵活轻巧，容易驾驶上手，但是安全性不足，上了高速容易出事故，抛头颅，洒热血！而轿车呢，成本高，得先考驾照吧，即掌握使用方法，然而，相比摩托车，其速度更快、安全性更高（安全气囊）、行程更远。
 
另外，引用上述比喻，轿车也非万能，跑高速路上很优秀，但是走山路呢？这里想说明一个问题，对于产品的web对象可识别度不高、开发人员无法给与支持配合的情况下，对象库的使用也容易出现不灵光的现象，毕竟QTP对象库提供的识别技术有限。解决办法？请挽起袖子自己造轮子吧！这也是定义对象库文件【XXX_Object.vbs】的目的之一，对于识别难的对象（包括识别不到和识别速度慢），可以采用DOM方法封装函数对象的方式处理。这个方法目前在多个项目中被使用，效果比较好，因为这样即利用了对象库的优点，也提高了对象识别的灵活度。
 
1.9.3. 公共对象库的管理方法
 
对于新手，往往对对象库管理比较不感冒，使用过程也常头疼，觉得写个脚本中间还隔着个对象库，不论编写或维护脚本都比较麻烦。但是随着学习的深入以及经验的积累，对于QTP对象库会更为准确的认识。
 
本人在这三年来积累的一些相关认识记录下来供大家参考：
 
1) 使用对象库，必须先掌握对象识别机制，否则一定管理不好对象库。例如测试对象中的Web控件类别、每一类对象常用到几种定位属性、对象识别的优先顺序和策略等。
 
2) 对象库的目录树需要合理规划，正常情况下可以按照页面的功能排布来划分，如果存在特殊的对象，如上传弹窗，页面弹窗等，也可以根据对象的类别独立出来管理。良好的对象库目录树分类有助于脚本的编写和对象库的维护。
 
3) 对象命名的方式也需要统一准确，避免和其他模块的对象名称相混淆。对于集合类的对象需要做出特征标示，标示该对象属于集合对象、可以通过定义属性来定义对象。其次，良好的命名风格，可以使对象在目录树中分门别类清晰排布，如果随意命名，对象显示会呈现散乱不易管理。
 
4) 对象添加到对象库后，需要对特征属性进行重新确认并编辑，因为QTP默认识别到的对象属性不一定是最优方案，需要根据项目的对象特点采用最为稳定的特征属性。另外，对于使用定位属性（Index、Location、CreateTime）这类的对象，一定要慎重！多考虑在不同场景下，对象的定位是否准确。
 
5) 对象库中的定位属性，并不是越多越好，也不是越少也好，而是应该从稳定和识别速度上来取舍。
 
6) 通过对象库工具添加对象不一定能定位到属性，此时，可以使用FireBug这类工具来查看对象代码，通过分析代码抓取有效的特征值。
 
7) 灵活运用对象定位属性值的正则匹配方法，对于某些特征值，虽然不固定，但是有一定的规律，此时可以使用正则表达式来匹配，往往会有惊喜！
 
1.10. 设计脚本批量执行
 
1.10.1. 概念说明：
 
脚本批量执行就是根据给定对配置，调用执行工具对多个脚本进行遍历执行，并将执行对结果保存到指定对位置以供分析。
 
1.10.2. 批量执行方法
 
我们对执行工具是QTP，自然是要调用QTP的对象接口，通过定义对象接口，加载执行信息，让QTP按照我们的指示执行脚本，目前，我们对执行平台为Excel，基本可以满足批量执行对要求。基本的原理是通过VBA函数调用驱动文件【Action驱动.vbs】，驱动文件再加载Excel中的脚本执行路径信息和配置信息，通过调用QTP对象实现执行批量。
 
添加执行脚本的方法如下图，中对应的列【二级路径】和【Action】添加路径和脚本名，然后中【执行】列选择打钩。这样就成功添加了一条执行记录。
 
 
下图为执行对配置信息，脚本执行时会使用此处对配置信息，因此中执行脚本前，务必要检查一下配置信息是否正确。
 
 
1.11. 查看测试报告
 
1.11.1. 概念说明
 
测试报告承载了整个自动化过程的心血，我们需要通过测试报告分析脚本缺陷、产品缺陷、用例覆盖率等。拥有良好的测试报告展示效果对于一个自动化框架而言尤为重要。测试报告的载体多样化、常见的如：文本、Excel、XML、HTML。
 
1.11.2. 报告包含信息和功能
 
1) 执行的过程信息：执行时间、执行信息。
 
2) 检查点判断信息：执行时间、执行判断结果、执行信息。
 
3) 排错辅助信息：截图、录像、驱动数据。
 
4) 报告的排序、过滤、搜索等功能。
 
1.11.3. 测试报告输出类型:
 
1) 日常调试日志输出：存放在项目路径【输出数据\用例测试报告日志】下。
 
2) 脚本执行过程日志输出：存放在项目路径【输出数据\用例测试报告日志\debug】下。
 
3) 批量执行Excel报告：存在在项目路径【输出数据】下的测试报告.xlsm。
 
4) 批量执行Web报告：存放在http://auto.35test.cn/readqtp下。
 

功能测试自动化要点
 
 
 
1 什么时候开始使用自动化测试？
 
开始之前，要考虑5点
 
 
 
1.1 功能测试自动化类似软件开发过程
 
录制，回放是不能满足自动化测试的需求的，所以要测试人员掌握开发知识，和编程技巧。
 
 
 
1.2 功能自动化测试是个长期的过程
 
首先我们不能再短时间内有很多的测试成果，找到测试的BUG，自动化测试只有在长期的多次运行后才能体现出他的价值和作用。
 
其次开发出来的东西也不意味着可以取代所有的测试工作，要考虑自动化测试脚本的设计和维护，被测试的应用修改之后，测试脚本也需要去维护，测试是个长期的过程。
 
 
 
1.3 确保自动化测试的资源，包括人员和技能
 
准备好电脑，服务器，手机，等等一切自动化测试需要的资源，有专职的人员负责设计框架和开发脚本，解决开发过程中遇到的问题，确保自动化计划顺利进行。
 
 
 
1.4 循序渐进的开展自动化测试
 
不要一开始就把自动化测试弄的很大，这很难实现，自动化测试应该从最小的开始，熟悉自动化测试和基本的技能，开始整合资源，实现一些基本用例，例如冒烟的用例，然后在逐步的扩展和补充。
 
 
 
1.5 确保功能测试过程的成熟度
 
开展自动化测试之前，考虑一下企业各方面的管理，例如考虑测试是否要独立执行，有无配置管理，进展控制能力如何？这些不成熟，不具备，开展自动化测试有点困难。
 
 
 
2 如何开展自动化测试？
 
 
 
2.1 选取合适的项目进行自动化测试
 
关键字：长期，稳定的项目
 
       自动化测试只有在长期的多次运行后才能体现出他的价值和作用，不断的进行自动化测试才能预防缺陷，减轻测试人员的工作量，如果一个项目是短期的，或者UI频繁的在变，这是不适合做自动化测试的。
 
      其次，不要在紧急的项目中开展，自动化需要脚本的开发以及维护，这其中又要花费很多时间，这个时候开展自动化测试，最后会起到相反的效果
 
 
 
2.2 选择合适的自动化开始时间
 
过早的开始自动化测试带来的维护成本太高了，早期的需求不确定，频繁的变动，这个时候不能进行
 
 
 
2.3 选择合适的自动化测试工程师，构建测试团队
 
编写脚本的人，要有一定的代码知识，需要了解各种测试脚本的编写和设计方法，知道什么时候选择什么样的测试脚本开发方式，如何有效维护等，需要具备一定的编程技巧，以及需要测试的基本知识，能够理解测试业务，只有理解了才能准确的转化为自动化测试用例。
 
 
 
自动化测试体系：
 
a. 测试自动化的类型和接口类型：接口自动化，单元测试自动化，回归自动化，性能自动化等。
 
b. 自动化测试的工具：POSTMAN，Jmeter，LR，QTP等等
 
c. 测试自动化测试框架设计
 
d. 自动化脚本思想，包括用例选择，自动化测试设计和开发，自动化测试的执行，分析和报告。
 
e. 自动功能化测试脚本质量优化。考虑到脚本维护性，移植性，灵活性，健壮性，稳定性，可靠性，效率等问题。
 
f. 编程思想。掌握对应编程语言的基础语法，比如Java，Python
 
g. 自动化对象。包括识别应用对象，对象映射，对象模型，动态对象行为等
 
h. 调试技巧。脚本报错了，会去调试
 
i. 错误处理。了解常用的错误处理手段，诊断错误，定义错误捕获机制，建立出错日志，创建错误处理函数
 
j 自动化测试报告。比如HTMLTestRunner  这种的，生成一个漂亮的报告，给领导展示以及自动好记录工作成果。
 
 
 
2.4 控制成本
 
考虑人员，测试设备以及测试工作成本问题。
 
抽取专职人员做自动化测试，不影响测试业务进行
准备额外的设备：机器，文件服务器，数据库等
引入自动化测试工具或者开发工具成本预算，测试工具培训等等
 
 
3. 自动化测试项目流程
 
遵循软件开发的基本规则，按照软件开发生命周期来弄：
 
a. 需求概述   
 
制定自动化测试需求分析说明书
 
b. 制定自动化测试计划
 
c. 制定自动化测试方案
 
d. 自动化测试用例设计或从功能测试用例中挑选适合的用例
 
e. 自动化脚本的开发
 
f. 自动化测试执行，生成报告
 
根据自动化测试计划中指导，按照时间的要求执行所有自动化测试内容，并生成自动化测试结果，分析自动化测试需求覆盖率，自动化测试效果，生成报告。
 
 
 
4. 自动化测试方案制定
 
 
选择自动化测试方案要考虑以下几点：
 
a 项目的影响：自动化测试是否能对项目进度，覆盖率，风险有积极的作用，或者让开发更敏捷
 
b 复杂度：自动化测试是否容易实现，包括数据和其他环境的影响
 
c 时间：需要多少时间
 
d 早期的需求和代码的稳定性：
 
e 维护工作量：代码是否能保持长期相对的稳定，功能特性是否会变化
 
f 覆盖率：是否覆盖到了关键的特性和功能
 
g 资源：测试组是否有足够的人力资源，硬件资源和数据资源
 
h 自动化测试的执行：拥有足够的时间去运行代码
 
 
 
5. 自动功化测试执行的策略？
 
自动化测试用例的执行策略是要看自动化测试的目的，通常有如下几种策略：
 
要确信你的自动化case是有价值的，可以代替你的手动测试
 
        自动化测试，尤其是功能性，也就是说代替手动case的。所以说我们必须确信我们的case是有价值的，可以代替我们去执行相应的手动case。至于什么是有价值的自动化case，我们相信应该是这样的：在一定的环境中执行过了自动化case，我们就相信，在这个环境中，我们没必要再进行同样的手动操作。
 
        至于如何写出有价值的case，当然也有其策略和方法，这里不再提及。
 
在测试环境中的执行才更有价值的
 
        上条说道，在一定的环境中去执行case，那这个一定的环境是什么样的环境呢？这里我的观点可能比较极端，我认为写case的环境，是我们的开发环境，并不是我们理想中的测试环境。
 
        那什么才是测试环境呢？答案就是，我们自己定义的，并且专门用于测试的环境。这个环境的所有情形都是Expected，或者是可枚举的。比如说装什么系统，装什么相关软件，如何跑我们的case，这都应该是定义好的。这样的环境才是测试环境。
 
        也许有人会对我这里定义的测试环境持反对意见，认为这样的环境并不是用户真实使用的环境，我们应该在更复杂的环境中去执行自动化测试，以期找到更多的bug。但是我认为自动化测试的目的就是做Regression Testing，以期有效的功能测试和版本控制。自动化测试并不能代替手动case，它应该是一个增量式的过程，我们不要期望让自动化发现更多的bug，而应该不断的添加，丰富各种自动化case，以及Bug Verification，以解放测试人员，让其更关注于测试本身。
 
能持续集成的运行了，才算我们的自动化测试跑起来了
 
      持续集成是业界非常好的经验总结，不光适用于我们测试，实际上她应该是适用于整个项目的。要想做到持续集成我们有很多的开源工具可以选择，这里的持续集成包括了：自动化执行。发现了BUG，自动的报BUG等，真正做到了全自动化。
 
我们要拥抱任何有意义的变化
 
这一点非常重要，这个是观念上的转变。我们要拥抱任何有意义的变化，这是观念上的转变。为了做出更好的产品，需求在变，代码也跟着变，我们的case在变，自动化case又有何理由不变呢？如果因为需求的变动导致我们自动化case挂了，我们应该高兴才是，因为我们的case成功的侦测到了这个变动，它是有价值的。换句话说，如果需求都变了，而我们的case还跑的好好的，那我可就要怀疑你的case到底有没有价值喽？！拥抱任何有意义的变动，不是说创建稳定性好的自动化case就没有意义了。
 
至于如何做自动化，Just Coding！
 
当DEV的开发水平会更高一些，但是对于我们QA，尤其是做开源领域比如Android的测试，做自动化的终极解决方案其实就是阅读产品代码，当我们读懂了开发代码，那写测试case就不是问题了。所以我最终的的建议就是：Just Coding， Just Do It！只有真正去做了，你才会发现问题，才会想到去解决问题，才会想到要总结一些方法，然后让我们的Case在测试环境中自由的跑起来！
 
自动化测试用例是用来监控的
 
在此目的下，我们就把自动化测试用例设置成定时执行的，如果每五分钟或是一个小时执行一次，在jenkins上创建一个定时任务即可。
 
必须回归的用例
 
有些儿测试用例，如BVT测试用例，我们在公司产品任何变动上线之前都需要回归执行。那我们就把测试用例设置成触发式执行，在jenkins上将我们的自动化测试任务绑定到开发的build任务上。当开发人员在仿真环境上部代码的时候，我们的自动化测试用例就会被触发执行。
 
不需要经常执行的测试用例
 
像全量测试用例，我们没有必要一直回归执行，必竟还是有时间消耗的，有些非主要业务线也不需要时时回归。这类测试用例我们就采用人工执行，在jenkins创建一个任务，需要执行的时候人工去构建即可
 
广撒网 
 
广撒网是指，加测试的时候A，B，C，D四个模块雨露均沾，没有什么特别的规则，你只要能报证覆盖率是增加的就行了。
 
集中某个业务流程 
 
这种策略优先关注于A,B,C,D中的某一个，完成其中某一个之后，再去实现别的模块。
 
集中某个业务的策略收益更早一些，对于广撒网这种策略，因为某个业务模块的金字塔没有完全实现，所以我们是不敢用它代替人工的，只能等所有的都完成了，我们才敢使用它代替人工测试。但是，集中某个业务是先完成某个业务流程，当这个业务流程完成了，我们就可以使用它代替人工测试，因为不是广撒网，所以我们收益的更早一些。
 
自动化测试中的测试数据管理策略
 
 
 
 
 
 

 
 
转自：http://www.cnblogs.com/fnng/p/3653793.html
 

 
 
 
 什么是自动化测？
 
  
 
 　　做测试好几年了，真正学习和实践自动化测试一年，自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。
 
 　　首先理清自动化测试的概念，广义上来讲，自动化包括一切通过工具（程序）的方式来代替或辅助手工测试的行为都可以看做自动化，包括性能测试工具（loadrunner、jmeter）,或自己所写的一段程序，用于生成1到100个测试数据。狭义上来讲，通工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。
 
 　　当然，我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。
 
  
 
  
 
 分层的自动化测试
 
  
 
 　　这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。
 
 
 
  
 
 　　相信测试同学对上面的金字塔并不陌生，这不就是对产品开发不同阶段所对应的测试么！我们需要规范的来做单元测试同样需要相应的单元测试框架，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，几乎所有的主流语言，都会有其对应的单元测试框架。
 
 　　集成、接口测试对于不少测试新手来说不太容易理解，单元测试关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；那么集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。例如，我定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否两个参数相加。当然，接口测试也可以是url的形式进行传递。例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口，需要通过soapUI 等工具对其进行测试。 
 
 　　UI层的自动化测试，这个大家应该再熟悉不过了，大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比较主流的是QTP，Robot Framework、watir、selenium 等。
 
 　　为什么要画成一个金字塔形，则不是长方形 或倒三角形呢？ 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。
 
 　　既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力，所以，我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。
 
 　　在自动化测试中最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，那么就需要对自动化脚本进行维护；如何控制失败，降低维护成本对自化的成败至关重要。反过来讲，一份永远都运行成功的自动化测试用例是没有价值。 
 
 　　至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试。
 
  
 
  
 
  
 
  
 
 我为什么要做自动化测试？
 
  
 
 　　根据51testing的《中国软件测试从业人员调查报告》，手工测试占到的89% ，相对开发来说，测试的门槛底，薪资普遍较底，所要求的知识面虽然有一定广度，但缺乏深度。这是测试的普遍现状。
 
 　　正因为手功测试人门槛不高，使大量的毕业生，甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强列的危机感。由于工作的技术含量不高，薪资的涨幅遇到瓶颈，另一方面受到新进入者的威胁，同样的工作公司花5K招来的人就可以做，那么就不会花8K 的招。
 
 　　好吧，这个问题不应该出现讨论技术的话题中，但他的确是大多测试人员不得不面对的一个问题。所以，从测试人员自身的发展来说，我其实非常需要通过自动化技术来增加自己有竞争力。当然，做到一定年限测试人员会选择转管理或其它岗位，这又是另一个话题了。
 
 　　从测试行业的发展来说，国内产品由于产品特点，世界级的产品不多，技术含量相对不高，质量要求相对要求不高，外包国外项目，测试人力成本低廉，所以需要大量的手工测试人员。
 
 　　所以，在不远的未来，我认为纯的工手测试人员的需求是递减，公司更需要更高技术能力的测试。质量需要测试，测试行为永远不会消失，但纯的手工测试人员是否消失是有可能的。
 
 　　好吧，你可以说测试多朝阳的行业，我纯属在危言耸听。不管未来如何，我们都需要提升自身的技能对吧！
 
  
 
  
 
  
 
 什么项目适合做自动化测试？
 
  
 
 　　假如你已经决定要学习自动化测试了，如何学习是要面临的下一个问题？这个问题以被测试产品为出发点进行分析，假如你所学的技术不能得到应用（验证），将会使你的学习过程寸步难行。
 
 　　首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。
 
  
 
 　　软件需求变动不频繁
 
 　　测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
 
 　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
 
  
 
 　　项目周期较长
 
 由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
 
  
 
 　　自动化测试脚本可重复使用
 
 　　自动化测试脚本的重复使用要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；所选择的测试工具是否适应这种差异；最后，测试人员是否有能力开发出适应这种差异的自动化测试框架。
 
  
 
  
 
  
 
 选择什么工具进行自动化测试
 
  
 
 　　假如你已经确认了XX 项目适合做自动化测试，那么接下来你要做的就是选测试工具了。
 
 　　首先要先确认你所测试的产品是桌面程序（C/S）还是web应用（B/S）。
 
 　　桌面程序的工具有：QTP、 AutoRunner
 
 　　web应用的工具有：QTP、AutoRunner、Robot Framework、watir、selenium
 
 　　由于B/S架构的诸多优势，早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如，被测试有产品是C/S架构的，那么推荐QTP ，QTP在UI自动化测试领域占到了一半的试用率。所以，足以说明QTP在自动化领域强大，易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然，要想学好QTP ，你必须要掌握VBS脚本语言。
 
 　　如果，被测产品是B/S 结构，那么推荐selenium ，为什么不是QTP 或其它工具？因为selenium 对B/S应用支持很好，更重要的一点，它支持多语言的开发，真正的试用selenium ，你所要掌握的不仅仅是一个工具而已，你还需要学习一门语言。我为什么要选择selenium？还要学一门语言，这无疑增加了我的学习成本。增加成本的同时，也增加的你的竞争力，而且，在这个过程中你不单单只是学会了一个自动化工具而已，你完全可以使用所学的语言去做更多的事情。
 
 　　好吧！假如你决定试用selenium 了之后，你又面临了一个新的问题，选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。
 
 　　从语言易学性来讲，首选ruby ，python
 
 　　从语言应用广度来讲，首选java、C#、php、
 
 　　从语言相关测试技术成度（及 资料）来讲：ruby ,python ,java
 
 　　或者你可以考虑整个技术团队主流用什么语言，然后选择相应的语言。
 
  
 
  
 
  
 
 selenium 用前须知
 
  
 
 　　OK！经过上的过程，我相信你一定做出的相应的选择，如果你选择的是selenium 工具，那么接着往下阅读。
 
 首选你在开始selenium之前，需要花一到两个月时间去学一门语言，这里是根据没有语言基础的同学而定的。我推荐ruby ,python ,java 任意一门语言来进行学习。
 
 　　当然，已经如果有很好的语言基础略过这个环节，或者你的丰富的java编程能力，那么学习python 可能只需要几天时间或更短。
 
 　　假如，你已经搞定了一门语言的基础，接下来你需要先了解selenium ，selenium 并不是单纯的一个工具，他是一组工具的集合，而且，他还有1.0与2.0之分，当然3.0也已经到来。
 
 　　selenium 也不是简单一个工具，而是由几个工具组成，每个工具都有其特点和应用场景。
 
 
 
  
 
 selenium IDE
 
 　　selenium IDE 是嵌入到Firefox浏览器中的一个插件，实现简单的浏览器操作的录制与回放功能。那么什么情况下用到它呢？
 
 　　快速的创建bug重现脚本，在测试人员的测试过程中，发现了bug之后可以通过IDE将重现的步骤录制下来，以帮助开发人员更容易的重现bug。
 
 　　IDE录制的脚本可以可以转换成多种语言，从而帮助我们快速的开发脚本，关于这个功能后而用到时再详细介绍。
 
  
 
 selenium Grid
 
 　　Selenium Grid是一种自动化的测试辅助工具，Grid通过利用现有的计算机基础设施，能加快Web-app的功能测试。利用Grid，可以很方便地同时在多台机器上和异构环境中并行运行多个测试事例。其特点为：
 
 · 并行执行
 
 · 通过一个主机统一控制用例在不同环境、不同浏览器下运行。
 
 · 灵活添加变动测试机
 
  
 
 selenium RC
 
 　　selenium RC 是selenium 家族的核心工具，selenium RC 支持多种不同的语言编写自动化测试脚本，通过selenium RC 的服务器作为代理服务器去访问应用从而达到测试的目的。
 
 　　selenium RC 使用分Client Libraries和selenium Server，Client Libraries库主要主要用于编写测试脚本，用来控制selenium Server的库。
 
 　　Selenium Server负责控制浏览器行为，总的来说，Selenium Server主要包括3个部分：Launcher、Http Proxy、Core。其中Selenium Core是被Selenium Server嵌入到浏览器页面中的。其实Selenium Core就是一堆JS函数的集合，就是通过这些JS函数，我们才可以实现用程序对浏览器进行操作。Launcher用于启动浏览器，把selnium Core加载到浏览器页面当中，并把浏览器的代理设置为Selenium Server 的Http Proxy。
 
  
 
 selenium 2.0
 
 　　搞清了selenium 1.0 的家族关系，selenium 2.0 是把WebDriver 加入到了这个家族中；简单用公式表示为：
 
 　　selenium 2.0 = selenium 1.0 + WebDriver 
 
 　　需要强调的是，在selenium 2.0 中主推的是WebDriver ，WebDriver 是selenium RC 的替代品，因为 selenium 为了向下兼容性，所以selenium RC 并没有彻底抛弃，如果你使用selenium开发一个新自动化测试项目，强列推荐使用WebDriver 。那么selenium RC 与webdriver 主要有什么区别呢？
 
 　　selenium RC 在浏览器中运行JavaScript应用，使用浏览器内置的JavaScript 翻译器来翻译和执行selenese命令（selenese 是selenium命令集合）。
 
 　　WebDriver通过原生浏览器支持或者浏览器扩展直接控制浏览器。WebDriver针对各个浏览器而开发，取代了嵌入到被测Web应用中的JavaScript。与浏览器的紧密集成支持创建更高级的测试，避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持，WebDriver还利用操作系统级的调用模拟用户输入。
 
 　　如果是新项目直接学习webdriver 就OK了，RC是过时技术。
 
  
 
  
 
 selenium学习路线
 
  
 
 　　配置你的测试环境，真对你所学习语言，来配置你相应的selenium 测试环境。selenium 好比定义的语义---“问好”，假如你使用的是中文，为了表术问好，你的写法是“你好”，假如你使用的是英语，你的写法是“hello”。 所以，同样有语义在不同的语言下会有不同的写法（语法）。
 
  　　接着你需要熟悉webdriver API ，API就是selenium 所定义一方法，用于定位，操作页面上的各种元素。
 
 　　先学习元素的定位，selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能强大语法稍微复杂，在这其间你可能还需要了解更多的前端知识。xml ,javascript 等。
 
 　　定位元素的目的是为了操作元素，接就要学习各种元素有操作，输入框，下拉框，按钮点击，文件上传、下载，分页，对话框，警告框...等等。
 
 　　经过一段时间的学习，你可以游刃有余的模拟手工测试来操作页面上的各种元素了。接着你需要做的就是把这些“用例”组织起来，统一来跑。
 
 　　那么你需要做的就是学习并使用单元测试框架，单元测试框架本身就解决了用例的组织与运行。
 
 　　当你写了一些“测试用例” 之后，你会发现用例中有大量重复的操作，能不能写到一个单独的文件中，需要的时候调用这些操作？当然可以，运用你的编程能力来实现这一点将非常简单。然后，你又发现每个用例中都有一些数据，这些数据也是一样的，但如果变化了修改起来非常麻烦，你也可以把他写到一个单独的文件中进行读取。
 
 　　接着你又遇到了新的疑问，我写的脚本（用例）都是流水式的，我怎么知道用例运行失败还是成功。那么就需要在脚本中加一些验证与断言。
 
 　　接着你又有了更多的想法，单元测试框架的log太简陋了，能不能生成一张漂亮的测试报告出来。我能不能定时的来跑这个脚本。能不能把每一次跑脚本的测试结果直接发到我的邮箱。能不能......
 
 　　为解决这些问题，你不得不学习更多的编程技术，然后你的“测试结构”会功能越来越强大，越来越灵活。产生了一定的通用性和移植性。一个有模有样的自动化测试框架诞生了。
 
  　　假如，有一天你不再做UI的自动化测试了，你会发现你去做单元测试 或接口测试基本没什么难度。开发个测试工具之类的也不在话下，感谢selenium 吧！顺便也感谢一下我吧！