看了社区里面很多大佬的自动化测试帖子，感觉收益匪浅，花了点时间整理一些自己的想法发出来，如有不对的地方请大家见谅。

有的小的团队从手工测试期望往自动化测试的方向发展，但是在选择的时候可能会比较迷茫，在这里我说下自己的一些想法。
我觉得选择一个适合团队的自动化测试发展方向大体归纳成一下几点:
1：开发语言的选择
2：学习周期和成本
3：协作开发用例的能力
4：后期维护成本（团队人员的变动可能也是会常有的事情，不过 1 和 2 也会直接决定维护成本）

首先申明下，我个人没有语言崇拜，是先会的 Java 后学的 Python。
①就个人理解，在开发语言上大家比较常用的是 Java 和 Python，但是我个人的感觉是测试人员中会 Python 比会 Java 的多，能学进去 Python 的比学进去 Java 的多。身边很多学 Java 后期都选择了放弃，个人觉得可能学 Python 得到成就感的周期要短些，很快就能从学习获取成就感能够让人信心倍增。当然如果你的团队里面有一半以上的人都会 Java，那你偏偏让团队选择 Python，我觉得老铁有些过分了。这里我就是个人一直使用 Java，但是团队中有一半的人了解和学过 Python，所以我最终将开发语言选择了 Python。
②由于我也是半路出家，但是个人感觉 Python 的学习周期和成本确实比 Java 要低，周围的同事也是这么和我说。
③作为一个脚本语言，协作上优势肯定是有的。但是有一点我觉得我要吐槽下，我用的 PyCharm 不能实时的编译，所以总是运行的时候发现错误，这一点作为一个写出来 Python 有 Java 味的选手来说不太适应。
④翻阅的不少测试工程师简历大部分会 Python 或者了解 Python 的比 Java 的要多些。

---------------------------------------------------------------------割-----------------------------------------------------------------

上面虾扯淡那么多，请见谅。
如果一个团队其他人都没有自动化测试经验的话，那么需要有经验的人来引导团队的开发。很多新手知道很多 Python 常用的语言等等，但是呢没法将这些碎片化的技能整理起来，来实现一个自动化测试的项目。
首先整理的是一部分常用的工具类：
①基于接口测试来说，可能常遇到的是 restful、soap 等一些协议接口，这些都是借助于 http 协议实现的。这里借助于 requests 整理了一些常用的 get、post 请，将一些常用的请求超时设置等等封装在内部。外部只需要调用工具类的发送方法即可。这里新手很容易忽略请求超时、协议中头里面消息如何设置等等，用例写好了发现自己的用例要跑很久很久。然后是一些常用的配置文件读取、日志的收集和输出、邮件的发送和测试报告的生产等等。

②其次将一些业务相关的基本接口进行封装，这样在写测试用例可以重复的调用不需要每个人都去关心。

③然后将一些基本的组合接口调用并且频繁使用的，比如商城类的测试订单的取消、删除、修改等都依赖于创建一个订单，创建订单本身可能就是很多接口组合获取到信息以后才能创建成功的，所以将创建订单再次抽象出来，当一个公用的方法。这里有一点，就是如果创建运单等需要选择商品类型、渠道类型这类建议都是通过对应接口获取，然后随机的选择而不是固定在方法中写死，这样的 case 就比较没有说服力。

④最后要写一个 case 的样例，原则是简单、容易看懂，让其他的人能够看明白符合新手的面向过程的编程逻辑。
整体结构大致如下：

将写好的 python 自动化脚本，借助于 CI 的工具（如：Jenkins），将后台的自动化构建、部署集成后，每次构建部署完成触发冒烟的自动化测试脚本运行，并及时邮件通知结果，这样的话就能够及时的高效的发现问题。
目前我们报告如下（借助于其他的报告修改调整的）：

当自动化测试的测试做到了一点的程度，自然会有个问题随之而来，就是自动化的用例完不完善怎么去判断？
随之理所当然的会引入一些代码覆盖率的工具，来借助于用例覆盖了哪些代码，哪些没有覆盖到来辅佐分析用例的完善性。
这里选择用 jacoco 的 on-the-fly + ant 来实现黑盒测试的代码覆盖率检查。（当然适用于白盒测试，这里附件不好上传，我就传几张图片）

最终效果如下：