- APP的一个页面，你怎么区分是原生Native页面，还是H5？
- 观察页面交互体验
流畅度：原生>H5
手势支持：原生>H5，更多复杂手势，如侧滑返回等
启动速度：原生快，H5慢 - 查看URL
H5页面：URL可能会短暂显示，或者尝试点击页面链接，跳转到浏览器打开 - 断网测试（开启飞行模式）
原生页面一般正常使用，除非数据请求失败
H5页面显示白屏或无网络连接 - 开发者工具检测
IOS设备 使用safari开发者工具：查看到连接的设备，能够查看到html结构，说明是H5
Android设备 使用Chrome开发者工具：连接电脑，打开Chrome，输入chrome://inspect，能查看页面的 DOM 结构，则是 H5；如果看不到，则是原生页面。 - 长按页面元素
H5：长按后选中文字或图片并弹出菜单
原生：无反应或与H5反应不同 - 代码方式检测
1）js注入检测
在 APP 内的 WebView 页面，可能可以通过 window 对象检查是否有 Web 相关的 APIconsole.log(window.navigator.userAgent);如果 userAgent 里包含 WebView、Safari、Chrome 等，通常是 H5 页面。
2）安卓抓包（Charles / Fiddler）
抓取请求数据，如果页面资源（如 CSS、JS）是通过 HTTP 请求加载的，可能是 H5 页面。如果资源加载没有外部 HTTP 请求，可能是原生页面。
- 测试活动中，如果发现需要文档不完善或者不准确，怎么处理？
测试需求分析 发现需求文档不完善或者不准确，应该立即和相关人员进行协调交流。 - 一个前后端都能修改的bug，应该由谁修改？
1）首先，应该是前后端都要进行修改的，因为如果只是前端进行了修复，部分用户就会绕过前端的限制，直接调起后台接口对系统进行破坏。
2）如果只是通过后端接口限制修复了bug，前端不进行修改。那么，用户就会在前端页面输入错误，虽然是通过后端拦截住了错误的请求。
但是，一次错误的请求也经历了从前端发起请求，走后端接口，后端判断之后，返回给前端页面错误信息。这样是限制错误了，但是如果前端当时限制了这种错误的请求发送给对应服务器，间接的减少了发送到服务器的请求数，其实也是提高了服务器的性能。
3）并且，一般在没有特殊的要求情况，我们一般设计软件的时候，都会尽量把计算之类的功能做在前端，这样其实减少了服务器的计算所消耗的性能，把这部分性能压力分摊到每一个客户机上。
4）当然，有些功能是服务器必须要承担的，而不应该放在前端去实现。比如鉴权，加密等功能。
