因为最近在群里有一些同学，之前没做过自动化测试，但是限于领导要求，或者自己想提升了，开始研究自动化测试，最近记忆比较深的低级的几个问题是：
1、编写一个python的类将 __init__写成_init_苦于问题一直解决不了；
2、想新建一个包，经常将package建成folder；
3、appium脚本中启动的activity或者包名经常写不出来；
4、将包名命名为selenium导致无法引入对应相应库；
5、写个selenium脚本执行不成功抛出异常，跑来问，这个怎么又报错了？异常类型都提示NoSuchElementException；
这些确实很初级的问题，其实最核心的而是缺乏编程能力、缺乏问题分析能力、缺乏解决问题能力。
对于功能测试学习自动化测试我的建议如下：
一、提升编程能力：
编程能力是一切的基础，所以基础先打坚固，对于python或者java的学习，可以看我自动化专栏里边的文章，也可以看我的论坛，里边有比较清楚的分类。
二、熟悉分层自动化测试思想：
自动化是分为三个层面的（UI层自动化、接口自动化、单元测试），不是每个层面的自动化都是遥不可及的，以下标示一下这三个层面的难易程度（也叫这个为自动化金字塔）：
三个层面的自动化测试
基本上可以肯定的是，单元测试是成本最低的，也是最容易推广，见效最大的，但是很多公司不会投入这块，原因是因为现在大部分公司都是人才短缺，特别是成熟的研发人员。你说投入到项目实际开发工作的人员都嫌不够，怎么可能抽出相关人力去做单元测试。而以目前大部分公司的测试团队人员构成来说，能做单元测试的基本没有（有也被抽去做开发了），这也是大家一致认为单元测试属于开发职责的原因（除了他们自己没人能做了）。
单元测试如果做不了，那么接口（API或Service）自动化测试能做不？这个只要有一定的技术基础还是能做的，至少有一部分测试人员是能够做接口测试的（话说性能测试就属于一种接口自动化），如果能自主开发或直接引进一套像样的接口自动化工具或框架（工具上来说，市面上也不少），那么就可以开展这部分的工作，我相信大部分公司能做好的自动化测试，应该也是基于这一层的（所以我们建议有条件的话，自动化测试可以先在这一层面展开，当然前提是真有那么多接口或服务需要测试）。接口自动化测试框架应该具有以下功能，根据复杂度和各自需求而定：
1、校验
这个很好了解，如果没有校验，单纯的执行接口的话，那就谈不上测试了。所以支持对返回值校验是一个必须的功能。
2、数据隔离
数据隔离就是指具体的请求接口、参数、校验等数据做到与代码相隔离，便于维护，一旦需要调整接口用例、新增接口用例时可很快速的找到位置，隔离的另一个好处就是可复用，框架可以推广给其他团队，使用者可以使用相同的代码，只需要根据要求填写各自用例即可测试起来。
3、数据传递
做到数据隔离可维护后，数据传递是另外一个更重要的需求。
数据传递是指接口用例之间可以做到向下传参，例如我们通过创建订单接口创建一个订单，该接口会返回一个订单号，接下来我们要进行调用查询订单的接口，从返回的数据中与创建订单用例中的数据进行校验，此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。这样的例子比比皆是，所以支持数据传递是又一个必不可少的功能。
4、动态函数
实际用例场景中我们可能会有随机生成一个手机号、字符串加密等需求，在数据与代码隔离之后，此时我们就需要代码可以支持做到识别对应关键字时可以执行对应的函数进行填充。例如在数据中填写nowTime()时，具体执行时会被替换成当前时间，填写random(5)时，会被替换成一个五位的随机数等等。
5、可配置
有时，我们的需求是用例不单单只能在一个环境上执行，可能需要同一份接口用例可以在QA、预发、线上等多个环境都可以执行。所以框架需要做到可配置，便于切换，调用不同的配置文件可以在不同的环境执行。
6、日志
日志包含执行的具体执行接口、请求方式、请求参数、返回值、校验接口、请求时间、耗时等关键信息，日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题，二来是发现bug时方便向开发反馈提供数据，开发可以从触发时间以及参数等信息快速定位到问题所在。
7、可视化报告
用例执行后，就是到了向团队展示结果的时候了，一个可视化的报告可以便于团队成员了解到每次自动化接口用例执行的成功数、失败数等数据。
8、用例驱动
（1）用例的驱动模式，涉及到怎么存放测试数据，怎么描述用例，又如何复用；
（2）考虑到效率的话还要支持并发；
（3）当然测试报告不能光记录成功和失败，还有用例执行耗时、接口调用耗时、场景的通过率等各项数值的统计。
说完单元测试、接口测试的自动化，我们现在来说说UI层自动化测试，这也是一直很火并且也是自动化概念先入为主的一块，毕竟市面上有不少成熟的自动化工具，如QTP、Selenium等。这块自动化一定是会有测试团队参与的，就算自动化框架是由开发来完成，那么具体测试工作也是由Tester全程参与的。UI层自动化测试真的不容易推行，无论有多么完善的自动化框架，在这一块维护的成本也是非常高的，特别是懂开发的人不懂测试，懂测试的人不懂开发，这一矛盾现象所带来的内部消耗就不少，再加上项目需求和UI层都在频繁变动，而且Web UI技术越来越复杂和多元化（UI层自动化需要基于对象识别技术），这些都导致很多公司不愿意投入这一块。即使这样，做为一个有上进心的测试人员，我们也是需要多想想这一块，毕竟这是离我们测试最近的一块“技术沃土”了（之一）。
现在我们来重点来谈下Web UI自动化测试（目前的系统大都通过Web UI来展示），一般成熟一点的自动化工具方案大体是这样：
1. 开发语言：Python或Java；
2. 开源测试框架：Selenium WebDriver；
3. Web元素定位：Xpath + cssSelector + findElement或findElements方法。
具体实施细节来讲重点是针对Web UI自动化测试的特点，将各层包装，分而治之的思想，各自相互独立，职责定义清楚，下面简要说明下：
1、测试用例业务流操作实现及测试数据分离管理；
2、页面元素定位及页面元素的操作分离；
3、可视化的日志查询系统；
4、跨浏览器支持如：IE,Firefox,Chrome；
5、可视化的的测试报告，可以具体查询到日志/截图等；
6、实现了通过Excel的数据驱动管理；
7、邮件发送管理，可以自定义具体时间及接受者等。
以上是一般Web UI自动化测试的一些实践要求，当然也是相对简易的，复杂的就是实现平台化管理，每天测试工程师，只需要选择具体项目、所测的测试用例集，然后执行，输出测试报告，邮件自动发送到相关开发/测试，框架的开发维护上也能够持续集成。
那么对于每一层一般都有那些技术方案呢？
UI层：
1、python+selenium+unittest、python+appium+unittest；
2、java+selenium+testng、java+appium+testng；
接口层：
python+requests；java+httpclient或者restassured
底层：
玩静态代码扫描吧，java方向有findbugs、pmd、checkstyle、fireline、godeyes、infer
oc方向oclint、infer
web方向：csslint、jslint等
这些过程似乎不是那么快速高效，但是效果会很好，如想快速入门，报培训班是不错的选择，但还得靠自己多花时间，多学习，多总结。
