• 前言

    转眼就7月了，一直想提笔写写技术博客但是都没架起势来。今天突然来了点兴致，想记录下自己最近做前端自动化测试时候的一些思考。（没有代码-_-||）

为什么需要UI测试

  • 当随着产品的不断迭代，功能越来越多，覆盖范围越来越大的时候，我们开发的代码，项目依赖也会变得更加复杂。对于后端而言，测试的东西大概是api，业务边界等和代码关系很密切的东西；但是前端UI的测试，要考虑的范围就非常宽广了。有简单的白屏检测，也有从打开应用开始走完一整套业务逻辑，也有页面渲染、加载速度、fps等用户感知上的测试······。总之，有可能被用户看到问题的地方，都可能成为被测试的对象。

UI测试能带来什么

  • 及时发现系统存在的问题：对于企业开发而言，一些仓库的代码几乎每天都会有发布，不论是在测试环境还是线上环境，想要在每次发布之后验证前端能否跑通逻辑就需要投入大量的人力进行测试，而自动化测试脚本能带来高效率的解决方案，仅需要编写一次测试脚本，就能验证发布结果。
  • 回归测试发现破坏性变更：在项目共建的时候，难免遇到多个项目组一起发布的情况。实际生产中，每个项目组都只会负责自己内容的测试，当别人变更了一些公有方法、函数的时候，可能会给自己的一些组件带来破坏性的变更，导致自己即使没有发布，应用依然崩溃的情况。自动化的测试就能在执行定时任务的时候发现这样的问题，通过监控测试结果来做到尽快发现并解决。

执行起来的痛点

  • 虽然以上讲得可能会让人觉得很有道理，感觉UI自动化测试必不可少，但实际上并不是所有项目都适合（值得）去做这样的测试。
  • 当UI发生变更时，需要修改测试用例代码：这就是自动化测试最大的痛点。试想一下，如果我们的项目UI频繁地变化，经常发布都要做一些UI上的调整（这样的调整是具有不定性的，比如删除/增加新的交互组件）那么，我们花费在重新编写测试用例上的时间，或许都能赶上我们开发的时间了（虽然开发和测试通常不是同一个人，但是这样真的不会被测试的同学锤死么？）
  • 为了写测试而写测试：要知道，即使puppeteer运行在无头的环境下，有些较长的测试用例跑完也需要几十秒。而做测试最容易犯的错误就是在一些无意义的地方编写用例，跑出来无法测出问题，但是一上线就发现bug。不仅浪费时间，也没能达到目的。

如何编写测试用例

  • 首先，一个完整的用例可以分为很多个测试步骤，每一步成功都是下一步的前提条件（注意，这里的成功指断言成功，而不是业务上的成功），因此，我们可以把一整个用例拆分为多个独立的步骤。
  • 每一个步骤具备4个要素：
    • 上下文：当前的环境，包括浏览器环境，操作系统，网络环境，当前url，是否已经登录等等。
    • 输入：任何模拟人的行为都被认为是输入，点击，输入，滚动，鼠标移入移除等。
    • 输出：指输入之后，系统反馈的结果。
    • 断言：匹配输出与期望是否一致，如果一致则断言成功，认为当前步骤成功；失败则认为当前步骤失败，抛出异常。

最后的一点思考

  • 关键业务逻辑一定要保证用例覆盖的完整性，需要尽可能模拟不同环境下的情况。
  • 其实写测试就是写爬虫，只不过爬虫的目的是为了拿到数据，而测试用例的目的是为了拿到断言结果。
  • 一定要了解清楚业务逻辑之后再设计如何测试，设计好之后也需要进行评估，不清楚业务的测试不是一个好测试（笑）
  • 一些参考资料

What is broken can be reforged.