入行测试大约两个月了，目前一直是纯手工测试，手工写用例、手工测试，每天重复性的做着一些工作，觉得甚是没劲，且超级没有安全感，自己的可替代性太强了，随便一个人都可以做我现在的工作。为了让自己变得更有价值，所以决心开始学习自动化测试。目前主要看一些网上的公开课视频，觉得吴老的公开课做的挺不错的，可以学习一下，因为PPT不分享，所以就将视频整理成文字版跟大家一起分享下。
《自动化理论基础（上）》，一个半小时的视频，word整理了6页左右。
一、需要的基本知识
- HTML
- CSS
- Javascript
- 熟悉Java、python、.Net、ruby其中的一种
- MySQL的基本SQL知识
- Junit的基本使用方法
二、需要用到的工具包和工具
- 浏览器:
- IE
- FireFox
- Chrome
- Safari
- Selenium browser drivers:
- Chrome Driver
- Internet Explorer Driver
三、需要用到的工具包和工具
- 开发工具：Eclipse（Java）
BDD（Behavior DrivenDevelopment，行为驱动开发）框架工具：Cucumber-JVM
TDD(Test Driven Development,测试驱动开发)：TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。（小步快跑的模式，只考虑自己本身的需求，其它需求不考虑；强调快速反馈，每天有早会，完成当天的开发和测试）
敏捷测试：
敏捷开发效率很高，也很累！
- 构建和集成工具：
-Maven（构建）
-ANT（构建）
-Jenkins（持续集成）
持续集成：团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。
- 其它工具(了解)：
-AutoIt：操作windows上的一些控件和元素（如上传文件时的文件框）
-Sikuli：基于图像做自动化测试
- 视频捕获工具：
-Monte MediaLibrary
四、测试的分层和收益（三层模型）
自动化分为三层：单元测试、接口和组件测试及UI测试。单元测试收益最高，接口和组件测试其次，UI测试最低。
图 1 自动化测试三层模型
单元测试收益最高的原因：基于最小的代码模块进行测试的话很容易定位问题，但是目前大多数公司的情况都是没有进行单元测试的，因为项目周期及存活等问题，目前大部分是由开发人员来做。
HP的一位姐们说曾与澳大利亚的开发人员聊到某一产品，开发人员说对这个产品不是太熟悉，只不过才开发了十年而已。中国有几个产品是开发十年的？十年的时间可能公司名都换好几个了。
接口和组件测试：做了一层封装，把各种代码组合封装为一个功能，他的定位和分析会变得较为困难。
UI测试：成本高，收益小。但是也很重要，是完全根据用户的体验和需求来进行的。
五、业内成功公司的标杆公司：
- Google测试和开发的人数比是10：1
- Facebook的测试和开发比是0
Facebook的开发工程师一个人支持100W用户。为何没有测试?1.Facebook开发工程师是绝对的大牛，Facebook需要面试大量的开发工程师才会招聘一个，而且面试流程非常复杂、严谨；2.做大量的单元测试来保证庞大规模代码的产品质量
纯手工测试人员如何提高自己？
像开发人员一样去学习开发。
有人就是因为不想写代码才去做测试，其实这种想法是不合适的，高级测试经理级别的测试人员一般是不仅有开发的技术，而且还有很多测试的要求。
六、目前流行的研发流程-敏捷开发
- 小版本发布，小步快跑
- 持续集成，每天构建版本
- 自动化测试主要版本逻辑，随时发现改动造成的新问题和影响
- 结对编程：两个人共同写一段代码，可以是一个人写一个人看，也可以各写一部分，然后合在一起。
- 重构：功能不变，代码重写
- 鼓励沟通，减少文档的重要性
- 测试驱动开发
七、Web自动化测试的基本原理
自动化：把手动测试替换为程序执行
图 2 Web自动化测试基本原理
八、自动化测试的类型
单元测试-执行速度最快1-10ms
接口测试-执行速度较快20ms-2s
UI测试-执行速度最慢 打开浏览器即需要3s，加上其它的时间就更长了
九、什么需要自动化
- 不是所有的功能都需要自动化--如：模拟断网的情况
- Gui测试自动化的秘密-执行自动化测试只会发现很少的Bug
自动化测试是为了发现更多的Bug吗？不是的，自动化测试是为了验证原有的功能可以正常执行。
- 执行自动化回归测试来验证系统状态，不是用来找出很多Bug的
- 执行自动化测试可以让我们抽出时间做更多的手工测试并发现缺陷
- 编写自动化测试过程会帮助发现大部分的bug,发现后要及时记录
十、使用自动化的一些典型场景
- 验证原有功能是否依旧可以使用，适合进行大量回归测试的场景
- 使用自动化测试技术注入测试数据
- 敏捷开发的TDD模式，行为驱动开发模式
- 机械并频繁的测试。每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长
- 做业务运行状态监控
十一、自动化实践的一些建议
- 从上到下的支持和协作
- 先找小的项目进行试点
- 测试人员需要有较强的编程能力和设计能力
- 开发需要不断提高软件的可测试性
- 多鼓励单元测试、接口测试
- UI测试使用并行测试方式提高执行速度
UI自动化的一些建议
- 需要根据自己的测试业务类型，量身定做适合自己的测试框架
- 让不懂开发的测试人员也能使用测试框架来进行自动化测试
- 使用分层的结构来设计框架
- 使用截屏技术提高一些测试效率
- 不断积累自动化测试技术，对开发提可测试性的要求
十二、自动化测试实施失败的因素
1.期望值过高。就像管理人员要求完全测试一样，期望100%的测试自动化，也同样是一个不现实的需求。
图 3 功能覆盖率与成本关系
2.对收益和成本认识不清。抛开工具的购买成本和培训成本，自动化测试的成本应该还包括两部分（实现成本中还隐含了测试准备成本）：
成本=实现成本+运行维护成本
3.自动化测试的收益是由测试脚本的重复运行次数，或自动测试脚本的利用率决定的。
十三、什么时候开始实施自动化
开发阶段？-->稳定阶段？-->部署阶段？
图 4 不要在不适宜的时机进行自动化测试
建议：可预见的需求不影响自动化测试用例的设计
十四、如何实施自动化测试？
单纯的讲，自动化测试的具体实现，应该是包含下面七个过程。
1.获取信息和测试需求分析：总体把握系统架构和设计，分析出系统的测试需求。
2.设计：设计测试用例，并且挑选出需要自动化实现的测试用例。
3.实现：编写、调试和实现测试脚本。
4.执行：执行脚本的过程，需要不断分析执行过程中的异常。
5.测试结果分析：分析哪些是Bug,哪些是测试框架本身的问题。
6.维护：自动化测试脚本的维护是一个难以解决但又必须要解决的问题。
7.总结：在自动化测试过程中总结自动化实践的投入产出比。
十五、软件自动化测试的成本投入
1.脚本的维护成本：
-自动化的脚本维护使得我们的自动化测试在成本上变得较为昂贵
-每一个系统的开发都是时刻随着需求的变更而改变，然而在大多数的情况下，就是很微小的一点系统修改都会导致我们去大量的修改自动化的测试脚本。
2.要维护的因素：测试用例、测试脚本、测试数据、测试结果、自动化的成本分析
3.维护难点：各因素的不确定性、脚本的版本要和软件build号相对应
4.测试服务器
5.人工成本
6.培训相关费用
7.时间成本
十六、自动化测试的术语-数据驱动
基于数据驱动的自动化测试框架是指测试驱动引擎从数据源获取测试数据，然后将数据以参数的形式传递给测试脚本，最后通过执行测试脚本，验证测试结果，并将测试结果输出。
一般数据源与测试结果存储在Excel文件、Csv文件等。
数据驱动的主要优点是：
--测试脚本与测试数据的分离
--当应用功能变更时，只需要修改该功能部分的脚本
--执行测试用例的人员不需要了解测试脚本的实现，只关注测试数据表与测试报告表。而且测试脚本的执行是离散的，即非线性的，测试人员可以有选择的执行测试用例。
十七、自动化测试的术语-关键字驱动
关键字驱动（keyword_driven）的自动化测试：
--关键字驱动测试是数据驱动测试的一种改进类型，它将测试逻辑按照关键字进行分解，形成数据文件，关键字对应封装的业务逻辑。
--主要关键字包括三类：被操作对象（Item）、操作（Operations）和值（value）,用面向对象形式可将其表现为Item.Operation(value)
--关键字驱动的主要思想是：脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离。
十八、自动化测试框架的一些目标
- 高复用性
- 高可维护性
- 稳定性
- 快速编写脚本
- 自动执行
- 正确输出结果
- 能够不断提升自动化测试比例