目录
五、发现一个bug ,怎么定位是客户端还是服务端的问题？（高）
一、功能测试用例一般包含哪些内容？（高）
核心内容：
用例编号、所属模块、用例标题、优先级、前提条件、输入数据、测试步骤、预期结果
二、黑盒测试用例设计方法有哪些？（中）
主要有等价类划分法、边界值分析法、流程分析、因果图、判定表、场景分析、错误推测法等
三、APP测试与Web测试有什么区别？（高）
- （1）系统架构：web端一般都是B/S架构，基于浏览器的，APP是C/S架构，是有客户端的；
- （2）兼容性方面：Web是基于浏览器的，所以更倾向于不同浏览器（Chrome、Firefox等）的兼容，而APP测试则必须依赖于手机，更关注系统版本、分辨率、屏幕尺寸等兼容性问题。
- （3）除了功能测试外、APP测试还需要额外关注一些专项的测试，如弱网测试、中断测试、安装/卸载测试、流量/电量测试、移动端性能测试等。
四、讲一下你们的测试流程。（高）
- 需求分析与评审
- 制定测试计划
- 根据需求文档编写测试用例
- 测试用例评审
- 提测后执行冒烟测试
- 执行第一轮测试，找bug
- 执行回归测试，验证bug
- 执行第二轮测试
- 部署项目到预生产环境
- 预生产环境测试
- 编写测试报告并发布
- 项目上线
- 线上验证（主要针对主功能点、主业务）
五、发现一个bug ,怎么定位是客户端还是服务端的问题？（高）
（1）抓包进行分析，对接口进行抓包分析，如果请求里的参数出现问题，则一般都是客户端的bug，如果请求参数正常而响应出现错误，那就是服务端的bug。
（2）日志分析，查看客户端/服务端的日志，分析有没有异常的日志信息，从而确定具体原因。
六、当开发人员说不是bug 时，你如何应付？
开发人员说不是bug，有2种情况：
一是需求没有确认，所以这个时候可以找产品经理进行确认，需不需要改动，商量确定好后再看要不要更改。
二是这种情况不可能发生，所以不需要修改，这个时候可以先尽可能的说出是bug的依据是什么？如果被用户发现或者出了问题，会有什么不良的结果。
如果还是不行，那可以把这个问题提出来，跟开发经理和测试经理进行确认，如果最终bug被确定不改，那么就要在测试报告里面记录一下，以便以后进行查阅。
七、做好测试用例设计工作的关键是什么？（中）
- 熟悉业务需求和用户使用场景；
- 了解本次需求对其他系统的影响；
- 了解开发技术实现和数据库的实现；
- 从不同维度编写测试用例，如功能、性能、安全、兼容等。
八、 bug的生命周期（高）
New：新发现的bug，指定给对应的开发；
Open：开发确认bug，并且认为需要进行修改；
Fixed：开发人员进行修改后标识为已修复状态，等待测试人员的回归测试验证；
Rejected：如果开发认为不是bug，则拒绝修改；
Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改，并需要给出理由；
Closed;修改状态的bug经测试人员的回归测试验证通过，则关闭bug；
Reopen：如果验证bug仍然存在，则需要重新打开bug，开发人员重新修改；
Later：延期修改（下一个版本修复）
九、 如何提高用例的覆盖率，减少漏测？（高）
- 要根据需求文档来编写测试用例，确保每条需求都被对应的用例覆盖；
- 要充分理解业务，挖掘隐形需求，并编写对应的用例；
- 除了正常的业务场景，多考虑一些异常的场景和数据；
- 要从多个维度对软件进行测试，功能、性能、安全、兼容等各方面来考虑；
- 多站在用户的角度思考问题，模拟用户的使用场景；
- 组织用例评审。
十、当发现一个bug时，如何确定是不是一个bug?(高)
- 看需求文档，是否有明确的需求
- 看下这个问题是否违反了正常人的行为习惯，或者行业的通用规范；
- 可以找产品经理或者开发人员沟通确定是否为bug；
- 对于无法达成一致的问题，可以组织相关人员开会，共同来决定是否为bug。
十一、没有需求文档时，如何开展测试？（高）
- 没有需求文档不代表没有需求；
- 可以找相关人员沟通，获取需求，比如产品经理，开发人员等；
- 可以参考同行业竞品，总结梳理需求；
- 可以根据用户的使用习惯和一些行业的规范，来总结一些功能需求。
十二、黑盒测试和白盒测试的区别（中）
- 黑盒测试就是把系统当成一个黑盒子一样，不需要了解系统内部的细节，只关注输入和输出，通过手动输入不同的数据，来验证输出是否符合预期；
- 白盒测试需要了解系统内部实现细节，通常是针对函数进行测试，需要写测试代码来调用对应的函数，通过传入不同的参数，来测试函数返回值是否符合预期。
下一节分析软件测试面试题移动端，欢迎支持！！！！
