背景
自测是送测前研发同学自己的测试，不是送测后才进行的研发自测，请务必在送测前完成自测！
自测包括研发自己测试自己的开发内容和内部研发peer之间的交叉测试
自测的宗旨是帮助大家减少低质bug数量，提高测试同学的测试效率
提测标准：
-
通过自测
-
至少需要另外1个开发进行交叉测试
-
必要时进行代码Code Review（代码规范，主要逻辑，复杂业务有无注释等， 复杂业务找了解这块的开发，时间<30分钟）
-
无影响正常操作及阻断流程的bug
-
对于公用样式、JS、组件的改动需要评估对全局的影响，并需要进行Code Review
-
对于新开发的页面或功能，送测时需要通知UI，UI会检查开发的页面是否符合设计，体验是否统一
-
送测前做基本的兼容性测试
-
送测前做特殊环境的测试
-
送测前做核心逻辑的单元测试
提测前自测清单checklist
功能类
搜索/查询
对于搜索查询功能来说，主要自测点有以下几点：
-
查询条件的合法性校验，不合法时给予正确的验证信息提示
-
单独测试查询条件
-
组合测试查询条件
-
组合联动测试查询条件
-
清空查询条件后进行查询
而比较常见的一种情况是，页面包含查询区域（关键字输入框、时间选择框、条件选择、查询按钮）和结果展示区域，结果使用表格展示，底部是分页（可选择pageSize和page）。而这时就需要额外考虑几点：
-
输入查询条件后点击查询，再选择分页，是否正确显示分页后的查询结果；
-
在非首页的页数时，更换查询条件，是否正确查询且跳回首页
-
更换查询条件，不点击查询，直接跳入其他页，是否正常显示结果
表单
绑定数据的类型
首先考虑表单中绑定的每条数据的类型，例如String或Number。尤其是接口需要的数据为Number时，就要特别注意表单中的数据是不是String，是否需要类型转换。
合法性校验
对于一般的输入框，考虑如下：
-
是否必填
-
对于空格的处理（前空格/后空格/中间存在空格/不允许空格）
-
超长字符处理
-
输入字母、中文、标点或其他符号是否合法
而对于特别的输入框一般都有特定的校验规则，例如数字框、密码框、邮件框、电话号码框等等，这些情况就要校验自己写的正则对不对。
创建、查看与编辑
这三个之所以放在一起，是因为创建、查看、编辑这三种功能很可能是共用同一个表单组件的。
大致分两种场景：
-
三种功能分为三个页面进行（但实际上使用的都是同一个组件）
-
三种功能使用同一个弹窗显示（引用同一个组件）
无论是页面还是弹窗，使用同一个组件的话如何正确判断状态就比较重要了。查看一般来说没啥问题，单纯展示就好。问题出现最多的还是创建和编辑。
一般bug多出现在编辑页面，因为操作最多，一般流程都是：
获取详情数据 -> 初始化表单数据 ->修改数据 => 提交更新后的数据。
根据后端接口的设计，一般保存数据后都会有一个数据的unique id，在编辑保存时需要用到，而创建时不需要这个数据。因此需要留心一下每个环节可能出错的地方：
-
编辑时是否正确获取了数据（也要保证创建时不要做多余的获取操作）
-
是否将接口数据正确转换为表单中的数据（数据处理时容易出现bug）
-
编辑保存时是否传入
unique id(创建的时候别传）
除此之外，如果使用弹窗来进行增改查操作的话，还需要注意：
-
保存成功后要关闭弹窗
-
保存按钮绑定一下disabled状态，保存中禁用按钮，并无论成功失败都应将按钮重新置为可用。
-
在三种状态中切换时，表单数据是否重置。例：编辑过后再创建，表单应都置为空（还显示上次编辑的数据就要被提bug了）
上传文件
主要自测点如下：
-
文件类型是否正确
-
文件大小限制
-
文件数量限制
-
上传一个空的文件/文件夹，测试是否能够正常上传
-
上传失败后再进行上传操作，测试能够继续正常上传
样式类
UI还原
-
字体
-
字体大小
-
颜色
-
间距
-
宽度
-
高度
-
阴影
-
边框宽度及颜色
溢出元素样式
如果自测的时候没有测试文本/图片/循环元素过多时的情况，结果QA同学进行测试时输入了很多字符导致页面出现诸如以下但不限于此的情况：
-
文本超过元素的容量，超出部分被截断看不到了/显示了多行但无法滚动（元素width写了固定值/overflow没处理好）
-
文本超出的内容显示了，但是换行错位了/显示了滚动条结果影响了同行的其他元素……
-
对某元素进行循环，换行后样式错乱 or 用flex进行布局没有换行元素过多后宽度被挤压……
建议：对于任何有可能溢出容器的元素，在开发时就尽可能的使用更多的文本/图片/循环元素去测试样式是否能够保持正常，这样自测过后再恢复正常的内容页面样式也不会出问题。
表格内容排版
处理表格时一般根据内容的长度进行处理。需要考虑以下几点：
-
内容是否只显示一行文本。只显示一行时要对列设置内容超出列宽度时的显示策略，如鼠标移入显示完整内容提示。
-
内容不显示只在一行显示时，考虑是否有列的内容需要多分配宽度，比如某一列要显示文章概述，可以为该列设置最小宽度，宽屏时可以自动为这一列设置剩余宽度。
-
像是时间戳、手机号、日期等内容较为固定的数据，为它们设置一个固定的宽度。
-
表格列数过多时要考虑处理方式，如在一行内全部展示/固定首尾列滑动展示中间内容/点击展开全部内容
交互类
loading态
常见于查询、保存等交互操作，接口返回数据需要一定的时间，而我们 又不想让用户多次重复操作，就需要给页面/按钮加一个loading态，同时禁止点击提交按钮。
修改离开
对应修改操作，当用户修改了表单的自动，当要离开当前修改页面时需要提示用户还有数据没保存。
删除操作
对于任何删除操作，都应该给予用户一个提示，在用户二次确认过后再执行删除操作，除非交互设计明确了这个地方不需要提示。要记住删除永远是个风险操作。
空数据
当页面上显示的某条数据为空时，需要考虑一下兼容策略，常用的方法有：
- 具体的值使用占位符，例如 - 、N/A
- 列表类直接不显示，用no data empty占位
边界条件
-
代码能正确处理接口没有返回数据的场景，比如字段不存在或者值为null或者空数组
-
接口返回未登录错误处理，确认该页面是否可以不登录访问；必须登录才可用的页面才需要跳转到登录页面
-
对于非必须登录就可以查看的页面（比如个人中心），可以忽略接口不应该返回未登录的错误。
-
文字过长（换行或省略，限制输入字符的max-length），元素很多（一行显示不下等，需要换行或者约定可显示最大值），这些测试可以保证我们在’极端‘用例下也可以正常运行。
兼容性
不同操作系统
windows、ios、linux等
不同设备
mac电脑、windows笔记本、windows台式机、Android手机、iPhone手机等
如果h5页面内嵌在app，需要测试在ios及android app中的兼容性
不同分辨率
可以自适应，支持宽1000+分辨率正常显示
不同浏览器
chrome、Safari等
手机自带浏览器（ios，android默认）
chrome移动设备调试模式（iphone5大小，iphone6，iphone6 plus，iphone 7，iphone7 plus）
同一浏览器需要区分不同的版本，一版需要考虑最近的5个版本
特殊环境
-
内网访问
-
外网访问
-
外网访问（通过VPN访问时）
-
WIFI访问
-
流量访问
-
网络信号强、中、弱访问（浏览器模拟）
性能测试
-
js，css，图片是否已经压缩（对接口返回的图片也需做检查），是否有必要进行再次合并的文件
-
是否引用了不必要的js等
-
icon类图标是否使用SVG、是否按需加载，图片是否使用了延迟加载（在使用轮播的时候有问题，可以不用使用)
-
服务器是否已经启用gzip压缩，是否配置了缓存时间
-
有些js是否可以延后执行（比如google地图等第三方库）；异步加载js例子：
单元测试
使用Jest Vitest等测试框架对核心逻辑编写测试用例，并保证测试覆盖率
自动化用例
使用cypress框架编写前端自动化用例
编写标准：有案例，有正常的测试点和异常的测试点
修改bug后的自测
-
需要了解bug的影响面，改完bug后需要对相关流程走一遍，确保没有引入新的问题。另外如果bug的修改涉及到较多的方面，需要在bug里备注说明
-
改完bug后需要自己在dev或test环境验证一下(可能需要测试帮忙发布下代码）
-
改完bug后尽量通知给相关测试，让他们尽快验证，以免拖到最后发现还有问题没有时间去改。（如果没有发布代码记得给他们说一下）
-
重新打回的bug需要确定原因，相互确认
