一、自我介绍

　　（自我介绍不局限于下面模板，灵活表达）

　　面试官你好，我叫xxx，今年xx岁，家乡是xx省xx市。20xx年毕业后一直从事软件测试工作，到现在已经x年了。

　　目前为止，经历过x家公司。第一份工作是在xxx公司，工作了大概x年，岗位是测试工程师，主要负责公司的web和APP项目的功能测试；第二份工作是在xxx公司。。。

　　工作这几年，我积累了丰富的功能测试经验，可以独立负责项目的功能测试。另外还负责过服务端的接口测试，可以用测试工具实现基本的接口自动化。其他的像Linux和SQL工作中用的也比较多。代码方面会一些Python基础，现在正在持续学习中。

　　以上就是我的一些基本情况，谢谢！

　　二、 测试基础

　　测试计划包括：

　　测试目标、测试范围、测试环境的说明、测试类型的说明（功能，安全，性能，稳定性）、测试工具、模块的划分、测试负责人、测试执行轮次的时间安排、测试的风险等。

　　2. 中-在项目中如何保证软件质量

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

　　A. 产品，保证迭代过程中的产品逻辑，对于可能的兼容，升级做出预判，并给出方案

　　B. 架构设计，满足产品表达的同时，保证设计的延续性

　　C. 开发，产品细节的保证，技术方案选择要严谨，考虑兼容，性能，开发完成后要充分自测，严格遵循开发规范操作

　　D. 测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多的使用技术手段保证测试质量

　　E. 运维，制定严谨的上线流程和权限管控，做好生产环境监控报警，出现事故后有应急预案

　　3. 高-功能测试用例一般包含哪些内容？

　　核心内容：

　　用例编号、标题、前提条件、测试步骤、预期结果、用例优先级、所属模块、输入数据等

　　4. 中-黑盒（或功能）测试用例设计方法有哪些？

　　主要有等价类、边界值、流程分析、因果图、判定表、场景分析、错误推测等

　　5. 高-APP测试和web测试有什么区别

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

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

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

　　6. 高-发现一个bug，怎么定位是APP端还是服务端的问题

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

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

　　7. 高-讲一下你们的测试流程

　　1> 需求评审和分析

　　2> 制定测试计划

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

　　4> 测试用例评审

　　5> 提测后执行冒烟测试

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

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

　　8> 执行第二轮测试

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

　　10> 预生产环境测试

　　11> 发测试报告

　　12> 项目上线

　　13> 线上验证（主流程、主功能点的验证）

　　8. 高-当开发人员说不是 BUG 时，你如何应付？

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

　　一是需求没有确定，所以这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不要改。

　　二是这种情况不可能发生，所以不需要修改，这个时候可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？

　　如果还是不行，那可以给这个问题提出来,跟开发经理和测试经理进行确认。如果最终bug被确定不改，那么就要在测试报告里面记录一下，以便以后查阅。

　　9. 中-遇到概率性bug怎么办？

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

　　10. 低-如何提交一份高质量的缺陷跟踪单

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

　　11. 低-Bug优先级和严重程度如何划分

　　严重：需要立即解决的问题，比如死机、进程无响应、崩溃

　　高：软件的主要功能错误，或者引起数据丢失的缺陷

　　中：影响软件功能和性能的一般缺陷

　　低 ：对软件的质量影响非常轻微的缺陷，多为建议性或者UI层级的问题

　　12. 中-做好测试用例设计工作的关键是什么

　　1) 熟悉业务需求和用户使用场景

　　2) 了解本次需求对其他系统的影响

　　3)了解开发技术实现和数据库设计

　　4) 从不同的维度编写测试用例，功能、性能、安全、兼容等

　　13. 中-给你一个项目，如何开展测试

　　1.查找需求说明、项目设计等相关文档，分析需求。

　　2.制定测试计划，确定测试范围和测试策略。

　　3.设计测试用例，包括功能、兼容、性能、安全等方面

　　4.开展测试执行

　　5.回归测试以及发送测试报告

　　14. 高-bug的生命周期

　　New：新发现的bug，指定给对应的开发

　　Open：开发确认bug，并且认为需要进行修改

　　Fixed：开发人员进行修改后标识成已修复状态，等待测试人员的回归测试验证

　　Rejected：如果开发认为不是Bug，则拒绝修改

　　Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改，并需要给出理由

　　Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug

　　Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改

　　Later：延期修改（下一个版本修复）

　　15. 低-黑盒测试和白盒测试的区别

　　黑盒测试就是把系统当成一个黑盒子一样，不需要了解系统内部的细节，只关注输入和输出，通过手动

　　输入不同的数据，来验证输出是否符合预期；

　　白盒测试需要了解系统内部实现细节，通常是针对函数进行测试，需要写测试代码来调用对应的函数，

　　通过传入不同的参数，来测试函数返回值是否符合预期。

　　16. 中-测试报告里都包含哪些内容

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

　　17. 高-如何提高用例的覆盖率，减少漏测

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

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

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

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

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

　　6、组织用例评审

　　18. 高-当发现一个bug时，如何确定是不是一个bug

　　1、看需求文档，是否有明确的要求

　　2、看下这个问题是否违反了正常人的行为习惯，或者行业的通用规范

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

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

　　19. 高-没有需求文档，如何开展测试

　　没有需求文档不代表没有需求。

　　可以找相关人员进行沟通，获取需求，比如产品经理、开发人员

　　可以参考同行业竞品，总结梳理需求

　　可以根据用户的使用习惯和一些行业的规范，来总结一些功能需求