聊一聊UI自动化测试

前言

最近在搞我们司机端的UI自动化测试，用appium + java来写的。写了大概有一个多月吧，中间还穿插的版本迭代，使用的是object+page模式来写的，page基本都写完了，测试用例写了几个，基本都调通了。中间遇到过一些技术困难(ps:这些问题我将会在别的文章中详细介绍解决过程)，实现过程也改过来改过去，中间有一些感悟吧，记录一下

做UI自动化的前提条件

做UI自动化之前，要先确定自己的产品能不能做UI自动化

1. 非产品初期，主流程基本稳定下来了，在迭代中，主流程更改不大，不然产品每期都改主流程，投入产出比太低，需要消耗大量的人力去修改测试代码，还没有直接手工测试来得快
2. 前置条件基本稳定，首先要环境稳定，动不动就断网了，服务器宕掉了，服务器连不上了，接口调不通了等等，就很烦。还有需要测试金字塔的下面两层支持，单元测试和接口测试，单元测试一般是由RD来做（我们的RD，大部分是不写单元测试的，有的懒得写ps:文档都懒得写，别说单元测试了，甚至有的还不会写），接口测试一般是由QA来做的，在UI自动化测试之前，至少保证大部分接口是没问题的
3. 一定水平的开发人员，在版本迭代中，发布的前夕，需要几个QA把版本中的改动对应的代码改好，所以需求改动不能太多

做UI自动化的意义

要明确做UI自动化测试的意义

1. 永远无法脱离手工测试，首先要明白的一个道理就是，永远不要以为，我做了UI自动化测试，就可以脱离手工测试了。
2. 是真的模拟了用户的行为，测试金字塔中，无论是单元测试，还是接口测试，和用户都还有一段距离，无论做的多好，只要没有到用户这一步，就不敢说没问题。而UI自动化是包含了全程的，是真的模拟了用户的行为。之前做过一个聊天，push的测试，是从长连接里面取出内容处理验证，只差了在手机上显示这一步，加上UI测试这一步，才能完全覆盖
3. 节约人力成本，每次版本迭代，在发版之前，都要进行主流程的回归测试，即使没改的也要进行（原因：RD水平限制和责任心问题，不一定改别的地方，就把这个地方改出问题了），其实都是一些简单的重复劳动，开展UI自动化测试，可以减少劳动。而且机器比人更韧性，不容易出错，任劳任怨。我一直觉得，能用机器做的事情，就不要用人来做。
4. 守门员，在版本迭代中，在发版之前，我们一直强调的是，主功能没问题就行。UI自动化测试担任的就是质量守门员的角色，保证我的产品能用，版本主功能没问题。

个人观念

说做UI自动化没用的，你真的做过吗，或者说你根本没做好，给自己找个理由，说没用，就不做了。踏踏实实做一做，感受感受，收获总是有的。另外提一嘴，适用于自己的：初学写测试代码的时候，时间充裕的情况下， 别就知道copy别人的代码，多想想别人为什么这么写，多看看底层代码，项目结构，多自己写一写，想下一旦哪天没人给你copy怎么办。刚来公司的时候，每一行代码，都是手动写的，虽然浪费时间，但是感觉还是有收获的。