自测标准：

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例子：<script  src= " " sync></script>