1.web测试和app测试的区别？
1.1web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端。
1.2系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
1.3性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory。FPS，内存泄露，内存溢出等。
1.4兼容方面，web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox），目前web测试也要考虑在手机浏览器的兼容性。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。一般app的兼容测试三种方法，云测试，请团队测试，真机测试真机的选择。首先要选择主流的机型，其次要选择不同的分辨率，尺寸，然后就是不同的操作系统。
1.5相比较web测试，app更是多了一些专项测试：
1.5.1健壮性测试：
一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。
而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过，这里不再讲了。
1.5.2安装、卸载、更新：
web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。这里讲起来的话太多了，如果有疑问的同学可以评论或者给我留言。
1.5.3界面操作：
现在app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试。
1.6自动化来讲，web大多用的selenium、webdriver，而app则是appium。
1.7性能使用的工具web则是LR，app使用Jmeter要多一点。
1.8 安全测试，app 安装包是否可反编译代码、安装包是否签名、权限设置，用户名等是否进行了隐藏等。web则要关注，sql注入，xxl攻击等。
1.9 边界测试，app测试比如sd不足，飞行模式等。web则不需要考虑这些
1.10权限测试，app需要获取用户的很多权限，但是web获取了用户极少数的权限就可以等等。
2.http协议中的post和get区别
HTTP是一个客户端和服务器端请求和应答的标准（TCP ）。客户端是终端用户 ，服务器端是网站 。
通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口 为 80）的HTTP请求。
（我们称这个客户端）调用户代理（user agent）。应答的服务器上存储着（一些）资源，
客户端与服务器之间的交互用到了两种类型的消息：请求（Request） 和响应（Response）
GET 向特定的资源发出请求。
POST向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。
POST请求可能会导致新的资源的建立和/或已有资源的修改。
GET是从服务器上获取数据，POST是向服务器传送数据
GET 安全性较低，POST安全性较高。
get（默认值）是通过URL传递表单值，post传递的表单值是隐藏到http报文体中，url中看不到。
GET提交的数据大小有限制2kb
3.你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。
将问题提交到缺陷管理库，类似禅道，进行备案，
根据需求文档，产品说明，设计文档等，确认实际结果是否与计划有不一致的地方，
如果没有文档，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据一般用户的使用习惯，来确认
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。
4.如何跟踪线上用户反馈bug？
1.首先收到 bug，确认是否是bug，复现bug
2.确认是bug要对bug进行记录，
3.通知产品，告知开发，商量解决方案
4.协助运维去查看日志
5.解决bug，测试环境验证，集成验证
6.告知用户，体验解决
7.和产品运营等确认是否需要给用户赔偿
8.记录bug处理过程，分析原因，组织相关人员进行回顾
9.思考测试过程中不足，总结经验教训。
