软件上线前所有提交的bug都要解决完吗？为什么？
不一定需要解决所有的bug，第一完全的测试是不可能的，也就说明没有bug的软件是不可能的，只要满足客户要求的就是好软件， 第二：版本上线是有时间截点的，在规定的时间内优先解决对客户影响大的bug。
bug遗留一般是下面几种情况： 1、bug没有好的解决方案，且影响可控的 2、优化类的bug 、转成需求来修改， 3、时间太紧张，对客户影响小遗漏到不紧张的版本修复。
测试用例评审的目的：
1、让产品、开发、测试三方对需求理解达成一致,减少开发过程中由于理解不一致产生的bug，提升效率
2、尽早发现需求设计中存在的问题，尽早修改，降低修复成本
如果测试A人员提单给开发B，A和B关系还不错，B说提单会影响他的绩效考核，这个时候怎么处理？
以我自己的经验
场景1： 面试的时候如何回答， 面试的时候尽量回答 发现bug就提单， 测试要有测试的原则性，不能因为影响谁而不提单，影响到产品的质量
场景2 ，实际工作中， 如果是测试还有几轮才结束， 且bug问题影响不大，可以让开发私下偷偷修改， 在下一个版本转测试后，一定要去验证开发偷偷修改的地方， 如果影响比较严重，还是要坚持提单，不让问题给遗漏了 ，好好和开发沟通，开发会理解你的， 可以运用一些技巧，这些你们自己去想。
* 做测试用例设计时，先进行等价类划分还是先进行边界值分析?*
先使用等价类划分。为什么说只有先分好了等价类，才能找边界值， 这个大家练习一个例子就明白了， 一个输入框，只允许输入字母、数字， 长度是6-10位。
在你测试的时候发现一个功能有点慢，但是功能是正常的，这个时候怎么处理？
分几种情况来讨论：
1、由于客户端的电脑配置引起的系统慢，如果客户也使用相同配置的电脑，这个慢需要提单解决
2、由于客户端网络慢导致的系统反应慢，这个不用解决
3、由于系统架构设计不合理导致的系统慢（数据库设计不合理、程序运行流程不合理、计算方法不合理等），提交bug单解决
在我们提交bug单前，需要和产品沟通下，这种慢是否需要更改，需要才提交bug。
软件测试完后,还有BUG,是测试人员的问题吗?
bug也要分情况：
1、需求里面有明确说明或者测试应该测试到的点，如果还有bug，那就是测试的责任
2、如果还有优化类的bug不能算测试的责任
3、如果还有不符合用户要求但是需求设计就错了的，不算测试的bug
为了测试不背锅， 所有关于bug沟通的记录都要有记录，方便以后不背黑锅
1、测试发现这个问题，但是不修改的， 这个也要有问题单记录
2、测试发现这个问题， 但是开发说没有这个场景的， 这个也要有沟通记录
3、测试发现这个问题，但是开发说不能复现，不修改的， 这个也要问题单记录
4、测试发现这个问题，但是说这个问题不重要，不修改的， 这个也要有沟通记录
一个系统上线之后经常会有线上问题，这个时候要求测试去复现网上问题，一般我们怎么样去入手分析呢？
（1）收集网上问题发生时的记录，一般包括如下几个方面
1、抓取出现问题的日志，还原操作过程
2、询问当时操作员执行了哪些操作，尽可能多的了解事发经过
3、了解当时的网络情况
（2）分析发生问题的原因？
通过查看日志，分析发生问题时做了哪些操作，每一步操作的数据是否都正确，如果找到问题发生的节点， 分析为什么会在这个节点出现这个问题
大部分有如下原因：
1、用户错误使用，但是没有对应错误限制
2、全局变量初始化错误，各种场景重复操作就会出现
3、数据量太大，但是没有限制
4、网络不好，重复请求（点击）
5、多人同时操作同一个数据，导致数据错乱
6、数据的同步异步请求传输
7、浏览器兼容性
8、接口数据返回异常
（3）我们可以通过哪些工具来帮助我们复现问题
1、Linux抓包工具 tcpdump
2、fiddler接口测试工具
3、clumsy制造网络延迟
4、设置Linux网络延迟