1、因为html5不兼容IE78，所以在PC上使用并非十分光。pc上IE还是占主流
2、html5主要用在移动终端
3、html5短期内因为自身的缺陷，用户体验无法达到原生app的体验。如：html5调用本地文件能力比较弱，所有数据需要从服务器拉取||||无法像原生app一样推送消息|||相比之下比原生app响应要慢，体验要差||不过移动设备的兼容性，使他也有一定的市场。现在所在的产品部，HTML5主要嵌入在Native App里面和微信公众号里面，这也限定了我们的测试环境。
4、html5也是一种web，所以web测试的方法我们都需要测试一遍
测试流程：
需求测试介入：需求是否合理，设计是否有遗落，原生逻辑图是否正确，目标是否明智等。前期的设计尽量满足后续开发需要，减少后续开发时出现遗漏，减少人力物力，了解需求后可介入测试计划，方案等，提高效率
接口测试：
终端这块，主要数据来自接口，接口错，即终端逻辑错误，逻辑错误即影响用户。接口测试主要方法如下：
1、接口输出是否与期望一致
2、终端上报是否与api文档一致
3、每个上报节点的边界值，是否为空等测试
4、接口逻辑测试
5、接口响应时间测试
6、接口安全性测试：接口部分敏感信息是否加密传输等，敏感内容是否屏蔽等
7、接口容错性：是否接受特殊字符，是否区分大小写，中英文符合等，整形和浮点型数据是否区分等
功能性：
功能测试，主要验证页面UI功能是否正确
参考51testing：
用户界面测试
根据测试和评审修改过的UED，测试开发递交的测试包。风格、样式、颜色是否协调，不仅包括HTML5本身，因为HTML5会嵌入App里面，所以要考虑h5的风格、样式、颜色是否与app本身协同，不至于格格不入，包括用户习惯等也最好保持一致或相近，最好在设计初期就有颜色、按钮、图片、背景、边框等详细规划和统一。但是正是由于H5的可移植性，同一服务会嵌入到N家客户的产品中，难以与各家都完全统一，所以在设计中就应该考虑这些问题。
兼容性：主要兼容IOS和Android的不同版本
下面做了一些与App对接测试常见问题：
▲由于HTML5嵌入在App里面，输入框需要调用原生键盘。由于andriod不同
手机的差异化，会导致原生键盘功能不同。曾发现
三星的android某版本调用原生数字键盘没有小数点，后只要碰到三星机器就调用全键盘；
▲App底部导航栏是否带入到H5页面中，打开键盘是否会影响导航栏位置变动。一般在HTML5页面中应该删除App的导航栏；
▲App与HTML5对接部分需要加密传输；
▲App头部的点击后返回的是前一个页面还是退回app主界面，需要注意；
▲IOS、Android的部分机型由于键盘的打开和收起会出现提示或确认页面弹框上下不居中；
▲由于网络问题偶现的App的报错需要包装；
▲从App各个入口进入HTML5界面都是免登录，各入口登录、登出正常；
▲在各个机型中，屏幕较小和较大的机器会出现不能全部显示或者部分空白的情况。
▲长时间不操作HTML5或者App，需要重新登录，或者需要重新输入密码；
▲屏幕较小手机提交参数的确认页面，由于字数较多会出现换行的情况，需要做适配。
微信主要是入口不一致，申请对接公众号后，需要用微信自带的浏览器进行兼容性测试，其他很多都相似，此处不在赘述。
【网络测试】
由于H5系统很多是云服务，所有响应速度普遍较慢。我们测试的时候一般会用wifi，速度会相对可观点。我们应该观察在4G、3G、甚至2G的网下，看响应时间是否在忍受范围内。时间过长的话，需要提示优化代码做改善。
由于我们对应的产品部利用HTML5把一些通用功能做成了云服务，可以嵌入多家客户的App，根据渠道划分，所以安全性显得尤为重要。
随着对接客户的增加，对服务的性能方面的要求也会增加。对于云服务的模块需要做性能测试。
由于部门机器的有限，第一轮测试我一般是采用google模拟器测试，也方便快速熟悉交互，最重要的是可以简单调试报错信息，定位缺陷原因，便于开发调试。
第二轮大功能基本稳定后，我才会借各种机器，用手机的自带的浏览器测试手机的兼容问题。因为app一般同步开发，App团队给不了稳定的包给我们做对接测试。
第三轮或者等App能给出稳定的包的时候，才嵌入微信和App测试。