自动化终极思想：以目标为导向，不断抽象沉淀，消除冗余，做到测试数据与测试代码分离
1、自动化测试对人员的要求
1、对测试人员的技能要求较高，需要自己写测试代码或看得懂别人的测试代码；
2、需要根据版本迭代进行更新测试用例，有一定的维护成本；
3、自动化能发现的缺陷数（bug）远远少于手工测试，产出低；
4、自动化测试的产出价值在于长期的回归测试，短期内发挥的作用不明显；
2、为何要自动化（借助自动化能解决什么问题？）
1、测试资源紧张，手工测试可能覆盖不全，容易错过一些边界异常校验；
2、释放测试人力，提高回归测试的效率，缩短回归测试时间；
3、实现手工测试无法完成的测试任务；
4、加深业务/流程认知，有助于发现系统中隐藏的问题；
3、设计自动化用例的原则
基本原则：
1、自动化测试用例的范围必须是相对核心的业务流程，即覆盖主体功能的核心测试点和重复执行率较高的模块；
2、在测试脚本和被测代码都保持不变的情况下，测试用例的结果应该是稳定的，这一点非常重要；
3、除非是必要的情况，否则任何用例都应当避免做持久化的操作，以保证环境始终是干净的；
4、Once Written, Run Anytime as Desired ；（测试用例的健壮性）
5、不是所有的接口测试用例都可以使用自动化测试来实现，自动化测试替代不了手工测试，两者的有效结合是保证项目质量的关键。
6、回归测试场景中，测试用例的选择一般以正向为主，逆向为辅，不过分追求100%覆盖；
PS:自动化用例设计原则
1、保持case的独立性
2、保持case的可迁移行
3、提高case的执行效率
4、接口测试优先级原则
1、外部接口优先级高
2、内部接口优先级低
5、自动化用例编写规范：测试代码层
1、命名规范：Keyword命名，第一个单词应以小写字母开头，后面的单词则用大写字母开头，驼峰命名法；
如：queryUserInfo、queryOperatorInfo、queryOperatorDetails等
2、参数命名：参数的命名规范和方法的命名规范相同，请在尽量保证参数名称为一个单词的情况下使参数的命名尽可能明确。
如：queryUserInfo，明确这是一个查询用户信息的接口
3、全局变量命名：如果一个变量名称全局都在使用，可以考虑用大写的字母“G”(或是Global)来定义。
如：G_Env_Url、Global_Env_Url （ip地址+端口）
4、testCase规范：测试用例尽量使用TAG标签内容来标记，验证回归时优先验证正常接口的调用
PS：以上所写纯属个人总结
