UI 自动化测试现在是各个公司测试方向降本增效的途径之一，基本每个公司都想开展 UI 自动化测试，其中 UI 自动化测试又分为 APP 端的和 Web 端的。网上有很多入门的教程和 Demo 可以帮助大家很容易的写出一个 UI 自动化测试脚本 Demo，而且网上也有不少已经成型或者不错的 UI 自动化测试框架。但是大家在开始对自己的产品布局 UI 自动化测试实施方案的时候，建议大家还是要先思考一下设计什么样的 UI 自动化用例是最适合自己产品的，根据本人多年来 UI 自动化测试的实践经验来看，前期的设计方案尤其重要，否则一旦 UI 自动化测试脚本写到一定规模的时候，再回头分析的时候，会发现一些需要花很大成本去填的坑。对于自动化测试而言，最大的挑战其实就是成本和收益之间的权衡，所以大家在动手布局自己公司产品 UI 自动化测试之前，最好需要想清楚如何设计出高效的 UI 自动化测试用例。
下面是本人这些年根据自身经历和踩过的坑，得出的一些经验，希望可以帮助到正准备走这一步的测试友友们，如有不足，欢迎随时补足和沟通。
测试用例不需要考虑太多操作场景，简单明了的到达目的地页面，然后开始断言即可，越简单明了的操作步骤越好，每增加多一步都会对 UI 自动化测试的稳定性增加风险。
一条测试用例脚本一定不要太多行，如果超出 20 行还没有实现测试脚本的目的，建议分成两个脚本，越多的行数后期维护成本越高，而且可读性越差。
脚本使用最简单的脚本编写，不要追求太多花里胡哨的写法，毕竟我们不是开发，写出的脚本要简单明了，备注清晰，所以参与编写的测试都能很容易的看懂。
对于重复的页面进入或者点击操作，要单独拿出来封装，这样大家都可以使用，而且后期 UI 有改动，也只需要维护一个方法即可，其他脚本不需要跟着改动，降低后期的优化成本。
常用的方法建议封装成独立的方法进行维护，这样可以供大家调用，而且写出的脚本也会清晰易读，简单明了。
如果多个测试脚本用例都需要相同的步骤，建议将相同的部分提取出来单独封装，这样可以提高代码的编写速度和降低后期的维护成本。
每条测试用例务必要做到可以独立运行，绝不可以依赖其他用例的结果，或者后面的用例有依赖自己的场景，如果有依赖就意味着前面的用例如果出现异常或者不稳定的时候，之后的测试用例将都会受到影响。
和上面一条类似，测试用例之间的数据产生和交换，不能阻碍或者影响其他用例的执行，否则一旦出现问题，将需要花费大量的时候进行排查，而且后期维护成本也会更高。
所有用例都要有前置操作也就是 setup() 的初始化过程，这个过程需要把用例所用到的准备事项都 ready，然后是具体用例的执行过程，最后是断言也就是验证部分，最后还应该有个 quit() 方法来处理测试用例需要回收的数据，比如用例 Pass 的时候可能需要删除用例产生的脏数据，或者需要还原一些设置或者状态。
这一点很重要，不要边写用例边设计，要提前设计好每一条用例的步骤和断言点，最好是先把步骤和验证点写成备注，这样下面写测试用例脚本的时候可以有所参考，而且便于后期维护的时候可以很容易的知道每条用例具体是测什么的。
UI 自动化测试用例一定要符合用户的操作习惯，否则意义不大，一般 UI 自动化测试都是代替手工进行回归测试，回归测试基本也都是满足用户基本功能的操作，所以 UI 自动化测试用例一定要尽可能的模拟用户的操作轨迹和行为。
UI 自动化测试用例一定是符合用户目的为前提的，不能自动化的操作是伪用户的行为，或者无益于用户的操作，比如不停的删除自己发布的评论，不停的恶意投诉正常用户。
可以多和数据组确认哪些场景是用户最常用的操作路径，这样写出的用例才最有效。
希望上面的分享能对大家有帮助，也欢迎各位有经验的友友们提出宝贵的建议，多谢！