前端自测的必要性和感想记录

前端自测适用于，前端开发前期《需求评审阶段》《UI评审阶段》《接口评审阶段》，中期《自测阶段》。末期《测试阶段》

身为前端狗在提交测试时，产品往往容易出现一些完全可以避免的bug。写此文意在提高个人提测质量和软件整体质量

目前前端角色处于软件开发过程中比较重要的节点，无论是产品经理，交互设计师还是UI设计师多需要前端交互来完善，前端是距离用户最近的开发，这也也意味着前端的责任：

• 需要对产品需求提出符合用户体验的修改
• 测试阶段的主要bug都将在前端被发现（包括交互缺陷、后端数据问题）

如果你反复测试你的线上项目的话，你会发现，依然有一些用户体验不佳 ，偶然情况下非常糟糕的bug，因为，前端最熟悉展现给用户使用的交互处理逻辑，即使后端传递的数据不规范，用户上传的数据不规范（数据展示为undefined）等，也是需要前端这个中间商规范化。

而提交测试前的阶段利用一定的时间进行自查往往可以将那长长的 bug单大大缩短，排除知名隐患。

如何高效+条例+高覆盖的 测试自己的项目
从基本功能到严格的页面加载和兼容依次展开

以下的测试参考并不涉及代码层次严格规范的单元测试之类的，规范的《前端单元测试》是建立在本文自测基础之上的，自测的目标是减少不必要的bug，提高提测质量。

用户视角

正常的使用和点击操作，按照一个普通用户的角度去点击，忘掉那些交互细节。有没有觉得哪里不太舒服，记得赶紧向产品提出，不然可能又是后期的紧急需求变更。

需求阶段和设计阶段，很多交互和界面基本都是产品凭空想象，即使UI搞很逼真但依然动不起来，

组合测试：防止不同模块的功能相互冲突

功能测试

单元功能，是我根据开发中某个单小功能分解出来的，比如

似乎所有需要输入的地方大概都有以下注意点，但几乎没有产品在需求稿中如此细致，往往测试阶段再考虑。或者出了问题再考虑。

你需要做的是

• 限制最短和最长字数，超出或未达到给出相应提示
• 限制特殊字符评论，是否支持某些表情包（输入法自带）
• 点击评论设置防抖（防止用户短时间多次点击评论，导致至少发出至少两条请求）
• 是否只支持而特定格式纯数字？纯字母
• 是否需要添加风控词过滤接口

所谓功能测试百度百科解释

根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求

视觉视角

视觉检查主要基于以下两点：

• UI设计师可能给你埋下的坑

  • 需求稿中的的字段，视觉稿无体现，和需求稿不一致（到底以谁为准）
    • 某UI稿中一个数据表有11列数据，你按照接近100%还原度完成。提测阶段,测试提出按照需求稿少一列数据。建立新bug，你添加这类时可能左边数据被挤掉了，或者表格数据显示不全，即使UI设计有很大责任，产品评审也有责任，但实现还是前端来做啊，所以还是前端锅最重（:D）
  • 上下相同的区域布局，背景色存在肉眼很难看出的差别，到底是视觉问题还是，故意的？
  • 部分视觉设计未考虑极限情况，比如给某副标题预留5个字位置，然而线上老版本该字段有一些5+的情况，

• 自己可能埋下的坑

  • 不同块之间的外边距和内边距，可能由于边框等存在微小差异
  • 多次调整导致色值出现差错
  • 开发中需求微微加了一行数据，或者加了一块内容，导致整体布局重新做

你需要做的是

• 页面所有的色值检查，不同区域与块之间的检查
• 查看所有字体，是否符合视觉要求，
  • 确定付费字体的使用分布和并确定是否公司有版权

极限检查

极限检查主要指极限值出现时的样式检查。例如：名称，预留位置为50px,假如有些用户名超出50px,此时需要超出行不显示或者显示省略号，设置title，保证隐藏部分用户鼠标放置可见。

特别极限问题，比如两个紧邻数组，假如同时都是最大值情况会不会出现显示混乱。

如以下实例1

过长字段也把右侧的按钮挤没了。。。

 

image.png

如下实例2

个人猜测，以下携程页面极有可能，在测试阶段测了此处30个人都加速的情况， 但后来需求改动，有变动布局，导致前端和测试都忽略了再次测试30人都加速的极限状态，因为测试要找三十个账号点击啊，。（笔者之前也遇到过这种bug，就是以上原因，还好是上线前两天，自己疯狂测出来），

image.png

空图片问题

无法保证接口返回图片地址存在错误，可以设置默认图或者，默认背景色
例子：广告位,假如页面顶部，或者页面中，嵌入广告，需要注意广告接口失效的情况。

后端视角（数据）

后端最容易出问题的首先就是和前端交接时使用的 ：接口文档

格式
后端往往在接口未开发完就开始写文档，开发中发现部分数据格式需要更改、文档字段写错等等问题

接口数据对照

开发中极易容易出现数据接错的情况，比如大量number类型的数据，且大小类似，后端测试不特意关注这一块的话，很容易出现，上生产，数据接错问题。

单项数据异常为空的情况

有些数据的为空时，页面极易容易出现以下问题

• 页面数据项显示 undefind、NaN。
• 控制台报Cannot read property 'length' of null之类的错误
• 数据为空，布局错位

当数据为空时，后端可能会返回什么？
可能是

data:{
    list:{}
}

或者是

data:{
    list:{
    title:'',
    body:''
    }
}

或者是

data:null

可能你搜索数据是返回第一个，请求所有时返回第二种，筛选时返回第三种。。。

实例bug：百度云盘的null

image.png

知乎内打开淘宝链接出现undefined

image.png

接口code值对不同情况的定义

返回值，一个部门最好统一返回code和errorcode，以及必须规范化msg。
线上常见bug就是，后端异常时，页面提示一些乱码的文案。原因在于，测试阶段未考虑，后端以为前端做了处理，前端以为后端做了处理，所以前端对于哪些地方显示接口传回的msg时必须和后端确认和自己测试验证。

你需要做的是

• 接口数据变量对照，确认哪些变量没用到，和后端及时沟通。
• 接口code或接口异常处理和容错处理
• 确认某一项数据为空或异常的情况

在接口异常时，保证提示给用户“网络异常，稍后重试”，“活动火爆，请稍后重试”之类的提示语，杜绝让用户看到出现一些程序开发专业数据，例如“当前token值失效，请重新登录”“请求参数有误”之类的专业名词

兼容性考虑

浏览器

根据需求对不同手机系统或浏览器的兼容版本，进行分别检查，

窗口、显示器

动态调整窗口大小，检测是否错位，为页面数据添加极限值，检测适应性

性能和优化问题

如果你顺利通过以上自测，距离正式提交测试还有时间的话，那是时候优化了。

对繁琐的布局结构进行优化

• 随着开发的深入，最初设计的dom布局结构可能过于错乱，在项目接近尾声时可以对其进行重构
• 对容易出错的地方进行重构
• 对无用代码删减

需要总结的地方还有很多，有时间再更，

箴言：解决bug的最佳途径就是“疯狂测试”

Test Obsessed 沉迷测试

引

浅谈前端单元测试
《代码整洁之道》