Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

前端的「自动化测试」就是在做梦

  对接口的测试根本就是黑盒的,输入什么输出什么,只要正确即可。这种测试框架很容易写,所以有很多完善的接口测试框架可以用。可是前端的测试呢?Web 项目的 UI 和交互测试虽然也有一些测试框架,但是感觉都是没卵用的。要么就是侵入了代码,要么就是难以维护。
  前端项目的测试确实是个难题。现有的测试框架都是大同小异,打开一个浏览器让程序跑一遍,然后模拟各种操作,最后查看某些 DOM 元素的某些属性是不是预期的结果。但是这些行为的前提都是「打开一个浏览器」,即便这些浏览器是后台打开的但是这种「按键精灵」级的测试根本就不靠谱。而且前端还有很多纯 CSS 的 Bug,这种基于浏览器和 DOM 的测试,即使 CSS 文件完全加载不出来也可能可以跑通。所以我觉得前端项目的自动化测试是个难题。现有的这些测试框架和开发过程中在浏览器控制台写一堆代码来跑测试没啥区别。
  我觉得对 UI 和交互的所谓「自动化测试」都智能是「半自动」的。那些黑盒的接口测试完全可以通过脚本在无人的情况下跑通全部测试,这才叫「自动化测试」。如果需要人盯着屏幕,看执行的结果是否正确,看 UI 是否有被正确渲染,这些都应该是「半自动」的。而且前端的 UI 变化远比接口频繁得多,测试脚本的维护成本也比接口测试的维护成本高得多,所以我觉得对前端的「自动化测试」根本就是在做梦,除非有足够的人工智能,否则我们能做的最多只有「半自动」的测试而已。
  我们确实可以写一些前端的半自动测试框架来提高人肉测试的效率,我觉得这才是「前端测试」目前比较靠谱的方向。比如测试过程中一些测试人员会反复地填一些表单,这些重复的事情可以开发一些用于自动填表单的脚本来搞定。
  避免前端代码出 Bug 的办法应该是做好监控。首先测试人员应该人肉测试通过,然后灰度上线。程序中对所有交互路径添加埋点,使用 A/B test 的概念,如果发现上线后的程序某些埋点的触发异常就立即回滚或 hotfix。但是这样的体系只能建立在前端监控完善的环境中,对项目还是有很多要求的。而且灰度上线、盯着监控,这样的操作人力成本很高,很多时候只有大版本上线才能有这样的待遇。普通的 bug fix 之类的发布也许还是只有人肉测试。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^