对UI自动化的思考

今日，刚自动化入门，写了点自动化的脚本，引发了我对UI自动化的思考。

1.为什么搞自动化

现在都智能社会了，程序都自动运行，测试为什么不能自动化呢？答案是，现在的测试还不能实现完全的自动化，就算是脚本过了，测试人员也不敢断定程序就是没问题的。所以所有的自动化都是测试的辅助，都无法完全代替手工测试。

2.现有的自动化测试

由于刚入行，知道的测试形式可能比较少。

包括有UI自动化，接口自动化，单元测试自动化，代码扫描。

根据敏捷大师Mike Cohn提出的测试金字塔（越往上投入越多输出越少）。

我们不难看出UI自动化投入多但回报很少，那么我们为什么还要进行UI自动化呢？

3.为什么搞UI自动化

为什么ui自动化出力不讨好但我们还要做呢？确实，相比于接口的自动化，UI自动化缺少灵活性，前端代码又复杂，交互又灵活，说是一劳永逸的写好一个自动化脚本那纯属扯淡，就算是封装的再好，也需要人去维护。随着自动化脚本迭代的增加，维护的成本也在增加。

UI自动化也不能拿去做新系统的测试，不能在测试初期投入使用，项目上线时间紧，跟高效率的人工比，自动化就显得鸡肋。

说了这么多缺点，下面来说说他的有点。

1.最真实的模拟用户操作，对接口的测试不涉及前端层面，接口没问题并不能说明系统没问题，甚至不能说明主流程是通的，但UI没问题至少能说明验证的点是能走通的。

2.现在的项目都是不断往上迭代，对于需求稳定的项目，每一次迭代不可避免的就是回归测试，回归测试的意义大嘛？当然大。每一次新的需求的加入，会影响到那些点开发都不能完全确定。所以上线前验证之前功能是必要的。所以UI自动化的优点就显现出来了。

3.前端表现为组件化，页面设计就具有规范化，脚本就具有可封装性，大大节省维护成本。

4.自我的提升，做UI自动化，前期投入肯定大，也很难出成绩，但只要做下去，做成一套，那就能用了。

4.思考

做事情一定要有输出，不能安于现状，作者现在也很迷茫，接到的测试还是点点点，找不到有效的提升点，业务总在不停的变，自己的积累不明显。一个新项目过来，从需求评审，PRD，交互与设计搞，如果新老测试人员都同时参与，他们的业务的理解程度感觉不会有太多的差异。

所以我们测试人员的出路在哪里呢？希望有人能为我解惑。