bug总是多不如看一看，前端写完代码进行的自测流程减少bug重复反工，提高开发效率。

提测标准：

1. 修改bug前要熟知之前的操作逻辑以及涉及其代码的周边逻辑，修改bug后的操作逻辑和测试确认，检测其它周边逻辑。

2. 至少需要另外1个开发进行交叉测试

3. 必要时进行代码Code Review（代码规范，主要逻辑，复杂业务有无注释等， 复杂业务找了解这块的开发，有没有封装可复用的组建。时间<30分钟）

4. 无影响正常操作及阻断流程的bug。

5. 对于公用样式、JS、组件的改动需要评估对全局的影响，并需要进行Code Review。

6. 对于新开发的页面或功能，送测时需要通知UI，UI会检查开发的页面是否符合设计，体验是否统一。

7. 检查是否有异步代码，查看network接口的调用执行顺序是否符合预期。

8. 单据是否有审批状态，如果单据为审批中操作按钮都应该禁用。

9. 页面是否有缓存，数据编辑后当前页面的数据是否发生变化。

10. 尽量少使用evel函数和innerHtml插入因为这些代码可以解析脚本。

11. 提交git的时候一定要看本地提交是否有多余的代码操作取代哦console.log 和 debug。

12. 长时间的调用接口有没有try catch进行处理。

13. 检查修改的功能函数在其他地方是否复用，如果复用它们之间的功能逻辑是否一致呢？。

合法性校验

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

• 是否必填，空格是否校验有没有进行trim处理。

• 对于空格的处理（前空格/后空格/中间存在空格/不允许空格）

• 超长字符处理

• 输入字母、中文、标点或其他符号是否合法

• 编号是否重复

• 判断账户金额时候足够支付的时候，尤其的自定义金额，一定要拿到原来的金额进行判断（走查询接口），不要拿输入的金额判断。

• 支付金额不能为0，支付金额不能为负数，支付金额注意js的小数点，一般保留两位，输入框是否可以输入文本（只能输入数字）。

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

上传文件

主要自测点如下：

• 文件类型是否正确

• 文件大小限制

• 文件数量限制

• 上传一个空的文件/文件夹，测试是否能够正常上传

• 上传失败后再进行上传操作，测试能够继续正常上传

• 文件里的内容进行校验是否为空是否必填是否重复。创建的时候后端有没有进行校验传入的数据，判重。

• 导入一万条数据接口会不会502，前端有没有将数据分批传送，后端有没有分批创建。

按钮点击loading态。

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

如果是弹窗里有按钮，比如说金额的改动，点击完成按钮直接禁用按钮防止多次点击，当再次打开弹窗之后再把按钮给解除禁用，然后检测是否有异步代码，考虑网络慢和网络异常的情况，接口返回成功情况，接口返回失败情况。

按钮的权限判断，比如说a能看到但是b没有权限不能看到。

form表单没有输入完成，按钮不能点击，按钮有没有进行防抖节流的处理，有无默认事件。

删除操作

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

边界条件

1. 代码能正确处理接口没有返回数据的场景，比如字段不存在或者值为null或者空数组

2. 接口返回未登录错误处理，确认该页面是否可以不登录访问；必须登录才可用的页面才需要跳转到登录页面

3. 对于非必须登录就可以查看的页面（比如个人中心），可以忽略接口不应该返回未登录的错误。

4. 文字过长（换行或省略，限制输入字符的max-length），元素很多（一行显示不下等，需要换行或者约定可显示最大值），这些测试可以保证我们在’极端‘用例下也可以正常运行。

修改bug后的自测

1. 需要了解bug的影响面，改完bug后需要对相关流程走一遍，确保没有引入新的问题。另外如果bug的修改涉及到较多的方面，需要在bug里备注说明

2. 改完bug后需要自己在dev或test环境验证一下(可能需要测试帮忙发布下代码）

3. 改完bug后尽量通知给相关测试，让他们尽快验证，以免拖到最后发现还有问题没有时间去改。（如果没有发布代码记得给他们说一下）

4. 重新打回的bug需要确定原因，相互确认