一、项目背景
先介绍下背景，脱离背景上来就直接应该怎么怎么做自动化都是耍流氓（当然能让领导给足够的资源做，那就无所谓）：
1、内部项目：主要是保证产品功能的准确性，安全、性能属于可以逐步优化的点。
2、技术陈旧：10几年的项目了，因此技术比较旧，前后端未分离（很多功能是后端直接返回html、xml，接口文档难整理）。
3、项目庞大：高度定制化满足各个事业部的需求，因此系统体量大，千表级别，需要验证的内容极多，同体量的内部系统，据了解测试人员近20个。
4、项目特征：复杂的大表单（如订单新增表单，字段数150+，涉及多层嵌套的明细，平均要10分钟构造一条）、长业务链（如订单->收款计划->账单-->收款，模块间重度依赖，长的业务链会涉及到7-8个大模块，每个模块间又有多个接口关联）
5、团队情况：开发：15，测试：5，这个比例按理来说还好，但是因为项目前7年没有测试，后面才逐渐补充，测试中有两个是新招的。
二、做自动化的目的
1、减少日常测试工作
从前面的背景介绍中可以看出，测试新功能，测试人手够；但是要补前七年的坑，则测试人手严重不足。因此首要考虑是做一定程度自动化，减少日常测试工作，以腾出人力去填坑，这里的自动化指的不是自动化测试，只是自动化，包括接口的实现但先不校验、数据库数据快速复用、系统日志自动获取等。
2、校验核心老功能
核心的老功能是每次测试首先要保证的点，而这块因为新功能的引入又很容易被动到，因此这块需要做下自动化测试。
3、减少开发内测、用户外测时间
前两点是在测试内部的优化点，而减少开发内测、用户外测的时间，则是要把测试团队的成果给其他团队使用（其他团队使用并认可你团队的成果，最能证明你的行之有效）。
4、在流程上做优化，提前发现BUG，使工程整体工期缩短。
三、自动化方案选择
1、做哪些自动化
1）接口自动化：校验后端+DB存储，主要通过接口请求，校验数据库存储与预期一致。因为很多接口涉及到多表存储，如订单新增接口，字段数150+，涉及到10+表，校验其数据的存储是否准确，是否有字段丢失，关联关系是否正确很重要。
2）数据库自动化：数据的查询、插入
3）服务器交互：获取系统日志、mysql日志，备份、导入数据库表、库
4）查询平台：因为系统是长业务链，因此主要是提供各个业务链节点的可用数据，给测试、开发、用户使用，以减少构造数据的时间。
5）UI自动化：因为人手严重不足，因此这块基本不考虑。
2、技术选择
1）抓包工具：fiddler
2）接口、数据库、服务器交互部分：Robotframework+相关库，考虑人手不足且团队人员没有相关基础，因此入门相对简单但是可拓展性强，各种库完善，报告良好，又可以与jenkins等很好结合的Robotframework，就成了非常好的选择。
3）没有现成库的：python封装成Robotframework可用方法
4）数据库表获取：shell脚本+Robotframework-SSH部分
5）查询平台：python+flask
四、自动化实现
内容较多，实现在后面分篇记录。
目前已经实现：
1）营销订单新增：日常测试频繁使用，每次减少10min构造时间，且可以快速复制已有的复杂数据，用于定位问题等；同时该模块核心case200+，每个版本回归可减少2000+min时间，且数据维护工作量极低，手工测试后记录即可。类似场景的大小模块实现多个。
2）工作流自动化测试：以最少的case遍历所有分支，每个case减少时间：数据构造+工作流审批耗时，约6-7min。
PS：另外实现自动审批（非自动化测试）：构造一条数据后，自动获取当前节点，自动审批至通过。
3）二级业务链节点自动化，如分摊配置，依赖订单的数据：单个case手工需要10min，另外需要加订单构造10min，核心case50+。日常测试频繁使用，每次减少20min构造时间，同营销合同新签，可以快速复制已有的数据，用于定位问题等；每个版本回归可减少1000+min时间。
4）解耦业务链，二级业务链节点自动化时，不需要再马上先做一级业务链节点新增。
5）提供查询平台，自动化生成的可用数据在平台展示，测试、开发测试时可以快速获取。
内容是边实践边记录，内容比较粗糙，欢迎感兴趣的大佬们指教沟通
也欢迎新手一起来灵感的触碰（思路比实现更重要，我们也是在一边思考方案一边实践，不少思路也是团队内没有基础的提供的，与其花好多money培训，不如自学在实际项目中实践）