1. 测试用例评审的流程是什么？
目的：主要是为了开展测试用例评审工作提供指引，规范测试用例管理工作。
流程：
测试用例是否按照公司定义的模板进行编写的；
测试用例的本身的描述是否清晰，是否存在二义性； 操作步骤应与描述是否相一致；
测试用例是否覆盖了所有的需求； 测试用例是否具有可执行性
测试用例应有正确的名称和编号, 测试用例应标注有执行的优先级。
2. 怎样分析性能测试结果？
1、查看聚合报告和服务器的资源使用图，检查响应时间，事务成功率，CPU，内存和IO使用率是否达 到要求，如果出错率达到了总请求数的3%，我们会检查是什么原因导致的，修改好后，重新测试；
2、如果出现了性能瓶颈，比如响应时间，或者CPU使用率不达标，我们会从服务器上导出日志，分析 是哪个地方导致响应时间过长，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给开 发修复，修复好了就进行回归测试。
3. 请说几个常见的状态码？
200：请求发送成功。
302：代表重定向。
400：客户端发送的请求语法错误。
401：请问的页面没有授权。
403：没有权限访问这个页面。
404：没有这个页面。
500：服务器内部异常。
4. 请描述下接口测试与UI测试是如何协同测试的？
1、有一部分是重叠的，Ui测试是通过前端写的界面，是来调用接口的，而接口测试是直接调用接口。
2、排除前端的处理逻辑与调用的正确性，在理论上接口测试是可以覆盖所有的Ui测试，但实际中，如接 口层覆盖所有的业务流，在Ui上只测试前端的逻辑，而最终的结果会忽视很多原有的功能点，导致了Ui 测试的不充分，那么会存在人多分工且时间充分的时候可以尝试接口去做业务流的全覆盖，否则不要轻 易的去尝试。
5. 你们项目最佳的并发用户数是多少？
我们当时做到1500个并发用户的时候，查询功能的响应时间超过了性能指标2秒多，原因是有几个表的 索引建得不合理导致的，我们当时做到1500并发用户后，就没再继续增加用户量了
6. 如何判断网络是否存在瓶颈？
在性能测试结束之后，我们会根据性能测试的结果，查看在整个性能测试过程中，网络的吞吐量是多 少，如果网络的吞吐量占到了服务器的70%以上，我们就认为网络存在瓶颈，通常会增加带宽或者压缩 传输数据。
7. 如何判断响应时间不达标
响应时间不达标的话，我们会根据性能测试结果先检查看下是否是服务器带宽存在问题，如果带宽存在 瓶颈，则会考虑增加带宽或者压缩传输数据，如果带宽没有问题的话，我们会从服务器上导出日志，开 发一起讨论分析是哪个地方导致响应时间过长，确定问题后，就提单给开发修复，修复好了就进行回归 测试
8. 如何判断CPU使用率不达标
CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致CPU使用率不达标，如果分析不 出来，就叫上开发一起讨论，确定问题后，就提单给开发修复，修复好了就进行回归测试。
9. App常见崩溃的原因？
1、设备碎片化：由于设备极具多样性，App在不同的设备上可能有不同表现形式。
2、宽带限制：宽带不佳的的网络对APP所需的快速响应时间不够。
3、网络的变化：不同网络间的切换可能会影响App的稳定性。
4、内存管理：可能内存过低，或非是授权的内存位置的使用可能会导致App失败。
10. 你在项目中最经典的BUG是什么？
1、兼容性问题，在ie浏览器，提交订单按钮可以点击，到了谷歌，火狐就不能了。
2、查询订单页面，根据条件筛选的结果不是想要的结果，还有某些字段的值没有显示出来，或者显示错 误。（因为开发从库表取值有误）
3、付款成功后，订单状态一直不翻转为交易成功。（因为代码没有正确获取库表中付款成功记录的状态码）