之前的博客，有介绍过关于UI和API自动化测试的一些内容，也聊了些自动化测试可能遇到的挑战以及常见的一些自动化测试框架。
我个人专职做自动化测试有一段时间了，期间看了很多资料，遇到了很多“坑”，也学习到了很多技能，可以说是收获满满。
这篇博客，聊聊我个人对自动化测试的一些延展思考（只列出思考点，具体分析后续更新）。。。
之前博客的传送门：
一、为什么要开展自动化
系统越来越复杂，线上问题越来越多，手动回归效率低
上线时间长，构建失败率高，代码提交频繁，质量不高
覆盖率，还是覆盖率
性能问题越发突出
安全问题冒头
二、功能测试的不足之处
手动测试的偶然性和不确定性
手动回归工作量大，覆盖率不足
发布上线的产品质量无法保障，一切靠评估
生产事故导致加班，被迫快速“迭代”来解决问题
测试粒度不够、业务场景覆盖不足
用例等文档的维护及时性、有效性不足甚至缺失
解决方案：从数据、流程、环境多个方面来解决问题
三、开展自动化需要面对的问题
1、集成的复杂度
多协议支持和相互调用
多个系统之间的集成
多个测试执行任务和机器部署以及调度管理
不同环境、平台的账号管理
2、沟通成本及复杂度
前端、后台、运维、架构、DBA之间的沟通成本
解决重复造轮子的问题
变动通知需要及时沟通（开发&测试、前端&后台、依赖API的变动、不同业务线）
3、安全性问题
敏感信息的配置脱敏
端口、服务的安全性
4、流程问题
流程是否标准化
是否有统一的case管理和维护流程
是否有统一的项目管理流程
是否有自动化测试规范和最佳实践
5、环境独立和隔离
版本一致性
开发分支、开发集成————-docker、镜像
测试分支、测试集成———— docker、镜像
环境隔离、权限管理：开发、测试、UAT、灰度、生产
配置、打包、提交、发布自动化，专人化
依赖高、实现难度大成本大的模块：提供mock对象
6、自动化实施管理
日志管理
脚本、日志定备防灾
自动化测试任务分发执行和测试报告
自动化的管理流程
7、数据构造
同步生产数据
备份还原数据
特征数据查找
数据构造平台
PS：脚本化、批量化、避免手工输入的不确定性
8、服务治理
进程管理
日志监控
版本跟踪
专人处理
四、如何解决上述的问题
1、团队
CI和CD环境的搭建，管理、流程执行
冒烟不通过打回
立即修复失败的构建
定时沟通，“吐槽大会”
2、开发
静态代码检查
确定合理适宜的开发规范
提高代码构建的频次
单元测试不通过不提交
定时code review
认真填写changelog
分支、集成合并必须回归
3、测试
丰富测试类型，比如对比测试、性能测试、安全测试等
提高测试响应速率
提高回归覆盖率
提高回归效率
提高稳定性
降低回归成本
五、建立评价模型
1、团队
根据问题严重程度设定响应和处理时间、速率
设定合理适宜的评价模型和机制，适时调整
2、开发
不同阶段的CI频率
code review频率、覆盖率
千行代码BUG率
寻找你的第83行代码
3、测试
不同阶段不同测试类型的占比、覆盖率、测试时间
优先级划分、构建稳定性
线上BUG率
六、自动化实施的原则
针对重点业务进行回归
针对稳定业务（环境、需求）较早投入脚本开发，减轻后期维护成本
自动化为了保证功能完成可用，而不是多发现缺陷
自动化无法减少人力成本，而是为了加快测试结果反馈速率，提升测试质量
录制回放只是鸡肋，可视化并不是一个很好的做法
尽可能让开发参与自动化，而非功能测试人员
七、总结
部署自动化
测试服务化
完善质量保障和评估体系
提高执行和监管机制
八、延伸
单点登录、权限管理
测试服务化
以上为我个人对自动化的一些理解和思考，如有更好的建议，请评论指出，不胜感激。。。