前端提测前的自检清单

前言

本文从自己日常开发的经验中总结了一些提测前的自检case，帮助大家减少低质bug数量，提升测试效率。

样式类Case

1. 处理溢出元素

前端开发页面都要依据UI图进行样式的还原以及宽屏适配，一般在这里不会出现太大的问题，所以这里只说一个最容易忽略也是非常有必要检查的一点：
溢出元素样式

让我们想象一下如下情景:
自测的时候没有测试文本/图片/循环元素过多时的情况，结果QA同学进行测试时输入了很多字符导致页面出现诸如以下但不限于此的情况：

• 文本超过元素的容量，超出部分被截断看不到了/显示了多行但无法滚动（元素width写了固定值/overflow没处理好）
• 文本超出的内容显示了，但是换行错位了/显示了滚动条结果影响了同行的其他元素……
• 对某元素进行循环，换行后样式错乱 or 用flex进行布局没有换行元素过多后宽度被挤压……

类似的情况我相信大家都经历过，明明这些在自测阶段都可以避免的但还是免不了懒得做测试or测试不全面提测后被测试测出来。

建议：对于任何有可能溢出容器的元素，在开发时就尽可能的使用更多的文本/图片/循环元素去测试样式是否能够保持正常，这样自测过后再恢复正常的内容页面样式也不会出问题。

2. 表格内容排版

处理表格时一般根据内容的长度进行处理。需要考虑以下几点：

1. 内容是否只显示一行文本。只显示一行时要对列设置内容超出列宽度时的显示策略，如鼠标移入显示完整内容提示。
2. 内容不显示只在一行显示时，考虑是否有列的内容需要多分配宽度，比如某一列要显示文章概述，可以为该列设置最小宽度，宽屏时可以自动为这一列设置剩余宽度。
3. 像是时间戳、手机号、日期等内容较为固定的数据，为它们设置一个固定的宽度。
4. 表格列数过多时要考虑处理方式，如在一行内全部展示/固定首尾列滑动展示中间内容/点击展开全部内容

建议： 对于表格来说首先要确保数据能够展示完全，提测时保证每一列数据总有一种方法能够看到全部内容。至于处理方法可以和设计、产品、测试同学一起沟通

功能类Case

1. 搜索/查询

对于搜索查询功能来说，主要自测点有以下几点：

• 查询条件的合法性校验，不合法时给予正确的提示
• 单独测试查询条件
• 组合测试查询条件
• 清空查询条件后进行查询

而比较常见的一种情况是，页面包含查询区域（关键字输入框、时间选择框、条件选择、查询按钮）和结果展示区域，结果使用表格展示，底部是分页（可选择pageSize和page）。而这时就需要额外考虑几点：

• 输入查询条件后点击查询，再选择分页，是否正确显示分页后的查询结果；
• 在非首页的页数时，更换查询条件，是否正确查询且跳回首页
• 更换查询条件，不点击查询，直接跳入其他页，是否正常显示结果

可能大家对于最后一点会有疑惑，但这确实是真实发生过的Case。某次需求开发时，项目用的vue，我在查询条件的表单中用v-model绑定了查询条件的值，点击查询按钮时直接用了绑定的值进行查询，并且分页时传入的值也是一样的，结果就是即使查询条件更改了但没有点击查询按钮却依旧使用了更新后的值……

所以真的要注意这一点，对于查询条件一定要用另外的数据进行存储，和当前绑定的条件进行区分开来

2. 删除

删除操作一般都比较简单，需要注意的点就是在执行删除操作后页面的数据是否刷新/跳转。

3 .表单

之所以没写增加和修改的Case，是因为想放到表单里一起说。

表单的情况就比较复杂。考虑如下几个方面：

1) 绑定数据的类型

首先考虑表单中绑定的每条数据的类型，例如String或Number。尤其是接口需要的数据为Number时，就要特别注意下表单中的数据是不是String，是否需要类型转换。

2）合法性校验

表单的合法性校验应该是最让人烦躁麻烦的了。但是为了不被提Bug，多多自测还是值得的2333。

对于一般的输入框，考虑如下：

• 是否必填
• 对于空格的处理（前空格/后空格/中间存在空格/不允许空格）
• 超长字符处理
• 输入字母、中文、标点或其他符号是否合法

而对于特别的输入框一般都有特定的校验规则，例如数字框、密码框、邮件框、电话号码框等等，这些情况就要校验自己写的正则对不对啦。

3) 创建、查看与编辑

这三个之所以放在一起，是因为创建、查看、编辑这三种功能很可能是共用同一个表单组件的。

我目前遇到的情况大致分两种：

1. 三种功能分为三个页面进行（但实际上使用的都是同一个组件）
2. 三种功能使用同一个弹窗显示（引用同一个组件）。

无论是页面还是弹窗，使用同一个组件的话如何正确判断状态就比较重要了。查看一般来说没啥问题，单纯展示就好。问题出现最多的还是创建和编辑。

一般bug多出现在编辑页面，因为操作最多，一般流程都是：

获取详情数据 -> 初始化表单数据 ->修改数据 => 提交更新后的数据。

根据后端接口的设计，一般保存数据后都会有一个数据的unique id，在编辑保存时需要用到，而创建时不需要这个数据。因此需要留心一下每个环节可能出错的地方：

• 编辑时是否正确获取了数据（也要保证创建时不要做多余的获取操作）
• 是否将接口数据正确转换为表单中的数据（数据处理时容易出现bug）
• 编辑保存时是否传入unique id (创建的时候别传）

除此之外，如果使用弹窗来进行增改查操作的话，还需要注意：

• 保存成功后要关闭弹窗
• 保存按钮绑定一下disabled状态，保存中禁用按钮，并无论成功失败都应将按钮重新置为可用。
• 在三种状态中切换时，表单数据是否重置。例：编辑过后再创建，表单应都置为空（还显示上次编辑的数据就要被提bug了）

4)上传文件

上传文件也是一个比较容易出bug的功能。主要自测点如下：

• 文件类型是否正确
• 文件大小限制
• 文件数量限制
• 上传一个空的文件/文件夹，测试是否能够正常上传
• 上传失败后再进行上传操作，测试能够继续正常上传

交互类Case

最后剩下一些交互类的自测点。这一类属于遇到了可能会被测试提bug，不过bug等级一般都比较低。但是那也是bug啊，我们的目标是尽可能地消灭低质bug，所以对于这些细节还是要注意一下的。

1. loading态

常见于查询、保存等交互操作，接口返回数据需要一定的时间，而我们
又不想让用户多次重复操作，就需要给页面/按钮加一个loading态，同时禁止点击提交按钮。

2. 删除操作

对于任何删除操作，都应该给予用户一个提示，在用户二次确认过后再执行删除操作，除非交互设计明确了这个地方不需要提示。要记住删除永远是个风险操作。

3. 空数据

当页面上显示的某条数据为空时，需要考虑一下兼容策略，常用的方法有：

• 使用占位符，例如“ 性别： — ” ， “ 描述： 暂无”
• 直接不显示该项

只要不在空数据是显示空白，问题就不大。写个占位符保底还是不错的方法。

最后

我们的目标是消灭低质bug，提测必过！奥利给！