自测标准：
1. 完成rp中涉及到的用例测试 （需要产品提供，如果没有的话需要产品提供）
2. 如果有prd，通过prd用例测试 （需要产品提供）
3. 如果有测试用例，通过测试用例 （需要测试提供，送测前需要提供）
4. 其他测试：边界测试，数据为空，接口返回未登录错误处理（如果该页面确实可以不登录访问）（需要更多的checklist，由开发共同整理）
5. 其他检查项：对于引入的图片资源需要检查是否太大，有无压缩等。
6. 对于依赖后台数据的，尽量自己造些数据来测（这样也可以更好的理解业务）。
注：如果rp和ui视觉稿不一致，需要产品和ui共同确认。
*其他测试说明：
1. 代码能正确处理接口没有返回数据的场景，比如字段不存在或者值为null或者空数组
2. 对于非必须登录就可以查看的页面（比如个人中心），可以忽略接口返回的未登录的错误。只有必须登录才可用的页面才需要跳转到登录页面。(后面支持页面级关闭所有接口未登录错误跳转逻辑）
3. 边界条件测试，包括代码及ui两方面。代码包括数组为空，变量为null等。ui包括：文字过长（换行或省略，限制输入字符的max-length），元素很多（一行显示不下等，需要换行或者约定可显示最大值），这些测试可以保证我们在’极端‘用例下也可以正常运行。
4. 对于临时新增的需求，变更，要求测试补全用例
修改Bug后的自测：
1. 需要了解bug的影响面，改完bug后需要对相关流程走一遍，确保没有引入新的问题。另外如果bug的修改涉及到较多的方面，需要在bug里备注说明。
2. 改完bug后需要自己在dev或test环境验证一下(可能需要测试帮忙发布下代码）
3. 改完bug后尽量通知给相关测试，让他们尽快验证，以免拖到最后发现还有问题没有时间去改。（如果没有发布代码记得给他们说一下）
4. 重新打回的bug需要确定原因，相互确认。
送测标准：
1. 通过“自测”（并通过测试写的测试用例）
2. 需要另外1个开发进行交叉测试（参考‘自测标准'，时间<30分钟）
3. 进行代码codereview（代码规范，主要逻辑，复杂业务有无注释等， 复杂业务找了解这块的开发，时间<30分钟）
4. 无影响正常操作及阻断流程的bug
5. 对于公用样式，js，组件的改动需要评估对全局的影响，并需要光辉或永禄进行codereview。
6. 对于新开发的页面或功能，送测时需要通知ui，ui会检查开发的页面是否符合设计，体验是否统一
7. 送测前做基本的兼容性测试
*code-review checklist，记录问题及解决方案。
兼容测试-h5测试环境：
1. chrome移动设备调试模式（iphone5大小，iphone6，iphone6 plus，iphone 7，iphone7 plus）
2. 微信下测试-重点测试（android，ios）--重点测试
3. 手机自带浏览器（ios，android默认）
4. 如果h5页面内嵌在app，需要测试在ios及android app中的兼容性
兼容测试-pc测试环境（可以自适应，支持宽1000+分辨率正常显示）：
1. chrome浏览器（较新版本）
2. firefox（较新版本）
3. Safari （较新版本）
3. ie8+ （公用虚拟机）
备注：考虑360安全浏览器优先使用webkit内核，加meta标签：
上线标准：
1. 通过测试，并且修复了主要的bug
2. 检查关键页面（首页，详情页等）加载速度，借助pagespeed等工具检查是否有需要优化的地方。
3. 开发，测试都需要对上线的内容进行再次验证（包括修改及涉及影响的页面性能检查）
*页面性能检查项：
1. js，css，图片是否已经压缩（对接口返回的图片也需做检查），是否有必要进行再次合并的文件。
2. 是否引用了不必要的js等
3. icon类图标是否都已添加到’雪碧图‘，图片是否使用了延迟加载（在使用轮播的时候有问题，可以不用使用)
4. 服务器是否已经启用gzip压缩，是否配置了缓存时间
5. 有些js是否可以延后执行（比如高德地图，微信等第三方库）
异步加载js例子：