功能测试自动化要点
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中的某一个，完成其中某一个之后，再去实现别的模块。
集中某个业务的策略收益更早一些，对于广撒网这种策略，因为某个业务模块的金字塔没有完全实现，所以我们是不敢用它代替人工的，只能等所有的都完成了，我们才敢使用它代替人工测试。但是，集中某个业务是先完成某个业务流程，当这个业务流程完成了，我们就可以使用它代替人工测试，因为不是广撒网，所以我们收益的更早一些。