软件测试面试题（四）

1、在项目中如何保证软件质量?

• 项目质量不仅仅是某个人或某个团队来保障的，而是整个团队一起努力的结果，因此，在公司级别需要 有一个规范的项目流程。

1. 产品，保证迭代过程中的产品逻辑，对于可能的兼容，升级做出预判并给出方案
2. 架构设计，满足产品表达的同时，保证设计的延续性
3. 开发，产品细节的保证，技术方案选择要严谨，考虑兼容，性能，开发完成后要充分自测，严格遵循 开发规范操作
4. 测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多的使用技术手段保证测试质量
5. 运维，制定严谨的上线流程和权限管控，做好生产环境监控报警，出现事故后有应急预案

2、APP测试和web测试有什么区别

(1) 从系统架构来看的话:web端一般都是b/s架构，基于浏览器的，app是c/s架构，是有客户端的。

(2) 兼容性方面:Web是基于浏览器的，所以更倾向于不同浏览器(Chrome、firefox)的兼容;App测试则必须依赖于手机更关注系统版本、分辨率、屏幕尺寸等兼容性问题。

(3) 除了功能测试，APP端还需要额外关注一些专顶的测试，比如弱网测试、中断测试、安装/卸载测 试、流量/电量的测试，移动端性能测试等

3、怎么定位bug是APP端还是服务端的问题

（1）抓包分析，对接口进行抓包分析，如果请求里的参数出现错误，一般都是客户端bug;如果请求正常 而响应是错误的，那就是服务端的bug

（2）日志分析，还可以通过查看客户端/服务端的日志，分析有没有异常的日志信息，从而确定具体原因

4、讲一下你们的测试流程

1> 需求评审和分析

2> 制定测试计划

3> 根据需求文档编写测试用例

4>  测试用例评审

5> 提测后执行冒烟测试

6> 执行第一轮测试，找bug

7> 执行回归测试，验证bug

8> 执行第二轮测试

9> 部署项目到预生产环境

10> 预生产环境测试

11> 发测试报告

12> 项目上线

13> 线上验证(主流程、主功能点的验证)

5、当开发人员说不是 BUG 时，你如何应付

• 开发人员说不是bug，有2种情况:

1. 需求没有确定，所以这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不要改。
2. 这种情况不可能发生，所以不需要修改，这个时候可以先尽可能的说出是BUG的依据是什么?如果 被用户发现或出了问题，会有什么不良结果?如果还是不行，那可以给这个问题提出来,跟开发经理和测试经理进行确认。如果最终bug被确定不改那么就要在测试报告里面记录一下，以便以后查阅

6、遇到概率性bug怎么办?

首先需要明确的是，该类bug也是需要提bug的，描述清楚当时操作环境、操作步骡、数据、并提供必要 日志，可备注上可能产生原因。然后耐心一点，运用排除法、错误推测找规律必要时找开发人员一起 定位分析讨论。如果最终仍未解决，那么需要在测试报告中体现，并分析可能造成的影响，大家一起权衡该bug是否可遗留。

7、如何提交一份高质量的缺陷跟踪单

首先要明确，缺陷跟踪单不仅仅是给自己看的，所以高质量的缺陷单，最主要的一条判断标准是，别人一看就懂，标题简洁明了步骤条理清晰。还需考虑缺陷的完备性，比如缺陷等级、所功能模块、版 本、复现步骤、预期结果、实际结果、产生原因、日志截图等。

8、Bug优先级和严重程度如何划分

1. 严重（S）：需要立即解决的问题，比如：死机、进程无响应、崩溃
2. 高（A）：软件的主要功能错误，或者引起数据丢失的缺陷
3. 中（B）：影响软件功能和性能的一般缺陷
4. 低（C）：对软件的质量影响非常轻微的缺陷，多为建议性或者U1层级的问题

9、做好测试用例设计工作的关键是什么(高频题目)

1. 熟悉业务需求和用户使用场景
2. 了解本次需求对其他系统的影响
3. 了解开发技术实现和数据库设计
4. 从不同的维度编写测试用例，功能、性能、安全、兼容等

10、给你一个项目，如何开展测试(低频题目)

1. 查找需求说明、项目设计等相关文档，分析需求。
2. 制定测试计划，确定测试范围和测试策略。
3. 设计测试用例，包括功能、兼容、性能、安全等方面
4. 开展测试执行
5. 回归测试以及发送测试报告

11、bug的生命周期(高频题目)

1. New：新发现的bug，指定给对应的开发
2. Open：开发确认bug，并且认为需要进行修改
3. Fixed：开发人员进行修改后标识成已修复状态，等待测试人员的回归测试验证
4. Rejected：如果开发认为不是Bug，则拒绝修改Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改，并需要给出理由
5. Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug
6. Reopen：如果经验证Bug仍然存在，则需要重新打开Bug开发人员重新修改
7. Later：延期修改(下一个版本修复)

12、测试报告里都包含哪些内容(中频题目)

• 测试范围，测试时间、参与人员、测试策略、BUG数量、上线风险、遗留问题、测试是否通过

13、如何提高用例的覆盖率，减少漏测(高频题目)

1、要根据需求文档来编写用例，确保每条需求都被对应的用例覆盖

2、要充分理解业务，挖掘隐形需求，并编写对应的用例

3、除了正常的业务场景，多考虑一些异常的场景和数据

4、要从多个维度对软件进行测试，功能、性能、安全等各方面来考虑

5、多站在用户的角度去思考问题，模拟用户的使用场景

14.如何确定是不是一个bug(高频题目)

1、看需求文档，是否有明确的要求
2、看下这个问题是否违反了正常人的行为习惯，或者行业的通用规范

3、可以找产品经理或者开发人员沟通确定是否为bug

4、对于无法打成一致的问题，可以组织相关人员开会，共同来决定是否为bug

15、没有需求文档，如何开展测试(高频题目)

• 没有需求文档不代表没有需求。
• 可以找相关人员进行沟通，获取需求，比如产品经理、开发人员可以参考同行业竞品，总结梳理需求可以根据用户的使用习惯和一些行业的规范，来总结一些功能需求

 16、你是怎么看待你和开发之间的关系的？

——首先我们要知道我们项目中的所有的人，都是为了把这个项目做的更好，都是合作的关系。

分为2点：

1. 我认为我们测试是把控软件质量的，也代表了用户，需要把控好软件的Bug以及易用性
2. 其次，我们也会是研发的补充，需要在还没上线之前，把测试用例尽可能的覆盖全，去发现尽可能多的bug,在上线之前，可以把这些bug解决了

17、针对项目中的风险，你会如何处理？

• 面试官考察的是我们在实际项目中，应对即将要上线的版本，出现了S 或是 A级的bug，我们应如何去做

——个人看法：针对这样的问题，首先需和和对应的开发进行沟通，看看有没相应的简单、粗暴的解决办法，若是有，则修复后上线，若是没有找到产品、项目、架构、研发负责人等相关负责人进行沟通，协调出问题的应对方案。

——参考答案：

上线前发现⼀个bug，⾸先要看bug 的严重程度，如果不严重的情况，就让开发
加班进⾏修改，修改完成上线，如果严重，⾸先要看开发是否能够修改完成，如
果不能的情况下，要向项⽬经理申请是否可以延期上线，⼀般情况下，我们经过
⼏轮测试是不会出现这种问题的。

18、当测试时间不够⽤的时候你怎么处理？

⾸先向测试经理申请让同事⽀援，加班测试，如果没⼈的情况下，向项⽬经理申请是否可以增加测试时间，如果实在不⾏的情况下，我们⾸先要确保核⼼业务和主要功能要测⼀遍，确保程序能够运⾏，在开发过程中督促开发⼈员进⾏⾃测和
单元测试，然后我们会编写测试⼤纲，根据功能的优先级进⾏测试，我们会细化每天的测试任务，产出每天的测试报告发给相关⼈员并评估出⻛险等等。

19、系统发布上线的标准

1. 系统满⾜⽤户所有功能和性能的需求
2. 所有缺陷都关闭且修复完成
3. 完成⽤户的验收测试
4. 执⾏完所有测试⽤例

 

---