1.测试基础面试

[TOC]

面试基础

基础面试题

1. 如何介绍最近做的项目？

• 项目是什么类型：
  • 项目有哪些模块
  • 自己负责哪些模块
    • 如何工作
    • 1. 参与需求讨论
    • 1. 提出需求意见
    • 1. 测试具体内容
    • 如何测试
    • 总结 * 1. 项目结果 * 1. 出现问题 * 1. 如何解决
• 比如某个视频学习网站项目，是以视频录播为主要业务的网站，分为管理员，教师，学生三大模块，同时支持web端，APP端使用（项目业务描述的要通俗易懂）。第二点项目环境，项目搭建在Linux服务器上，使用mysql数据库，前段使用JS编写，后端使用JAVA语言。第三点是流程，测试的网站或者APP当前版本是多少，项目组有多少开发和测试，然后说一下测试的流程。第四点自己担任的角色，负责哪些模块的什么测试。第五点重点是自己负责的模块要详细展开的说，例如负责支付模块的接口测试还是功能测试，还是有自动化跟性能去辅助的，期间用python编写自动化测试脚本，结合pytest框架跟po分层模式做自动化测试，会的技术都要描述出来，另外在测试开展过程中是否遇到难点，并且准备一个印象深刻的BUG，你是怎么定位跟解决的
• 我最近做的项目是一个CRM管理系统以及客户助手APP。CRM客单管理系统是一个帮助企业业务员工进行销售管理的系统，然后它主要设计的功能模块有产品管理，订单管理，客户管理，分销，部门管理，财务管理等几个模块。客户助手是为公司销售、业务人员定制的一个个人APP工具，能够更好的管理和维护客户关系，然后主要模块有客户管理，跟进信息，个人笔记，收支记录，客圈发布等模块。项目搭建在Linux服务器上，使用mysql数据库，前段使用JS编写，后端使用JAVA语言。我测试项目的时候负责的功能方面的一个测试用例编写，写完之后我会在我们测试内部进行一个用例评审，评审完之后会对功能测试用例进行一个测试执行，如果发现有问题，就会提交BUG到BUG管理平台，然后也有做过接口测试，根据接口文档编写接口测试用例，然后选择postman进行执行，如果执行过程中发现问题也会提交BUG到管理平台。最后在测试结束之后，评估一下bug和测试用例是否达到上线的标准，并编写一个测试报告。我们测试这边是3个人负责项目，除了做日常的用例维护之外，还需要根据需求变更和版本迭代进行回归测试。

2. 遇到浏览器白屏（web空白）如何定位问题?

• 后台问题
  • 后台返回数据为空
• 前台问题
  • JS代码问题，没有把数据渲染到页面上
• 如何排查问题
  • 先访问其它网址，如果正常，表示网络正常，浏览器正常
  • 打开抓包工具，查看响应结果。返回响应为空是后台问题。响应有内容，没有显示到当前页面，前台问题，可以查看前台JS控制台日志，查询到问题反馈给前端人员

3. 概率性bug（偶现BUG）该怎么处理？

• 截图
• 抓日志
• 视频录制
• 列举相关条件
  • 前置条件，测试环境等进行列举
• 尝试复现BUG，若是复现不出来，也需要提BUG单，注明是个偶现的BUG
• 首先需要明确的是，该类BUG也是需要提单的，描述清楚当时操作环境，操作步骤，数据，并提供必要日志，可备注上可能产生原因。然后耐心一点，运用排除法，错误推测找规律，必要时找开发人员，项目经理一起定位分析讨论，如果最终仍未解决，那么需要在测试报告中体现，并分析可能造成的影响，大家一起权衡该BUG是否可遗留

4. 软件测试环境部署怎么做？

• 一般是指项目的一个环境的部署，APP的话直接装载APP就行。所以一般是指web后台的一个项目部署。
• 基础环境骨架
  • linux搭建JDK+tomcat+apache+mysql
  • 把开发编译好的项目War包放到tomcat的webapps文件夹内
  • 然后把数据库的配置配置好，让项目和数据库关联上，再去初始化下开发给我们的sql脚本，把数据库的表结构给建好，最后重启Tomcat服务
  • 远程连接，测试环境连通

5. 怎么判断BUG是前端还是后端的问题？

• 先看下界面排版和展示，如图标或样式错误则是前端问题
• 抓包分析，检查前后端响应是否正确，对比接口文档
  • 入参正确，后端返回数据不对，则后端问题
  • 入参数据不对，前端问题
  • 入参正确，返回数据也正确，但是前端没有一个正确展示，则前端问题
  • 接口返回数据为空，查数据库，如果数据库存在数据，则后端问题

6. 测试报告都包含哪些内容？

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

7. 测试时间不够怎么办？

• 说白了，测试时间不够，最直接有效那就是加班，当然我们不可能只说加班
• 1.通知项目负责人和相关干系人（开发和产品），使其了解项目现状
• 2.重新审视需求，缩小测试范围，减少工作量
• 3.识别任务优先级和重要性，优先完成核心的、重要的任务，保证业务流程正确无误
• 4.降低关键模块的测试强度、质量要求
• 5.寻求其它测试人员帮助，不行加班处理，如果加班也来不及并且项目不急着上线，可以跟领导商量下是否可推迟上线
• 6.这个不用说或者看情况说，如果是测试人员不足引起的，为了不影响测试团队紧张和混乱，招人吧

8. 测试工作中用Fiddler做什么？

• 当测试出BUG的时候，可以通过Fiddler抓包，分析bug是客户端还是服务端的问题
• 做接口测试的时候，通过抓包获取接口的入参和返回值，包括接口之间的数据关联
• 当对客户端做弱网测试，可以修改Fiddler的网络模拟参数，模拟出不同的网络速度（fiddler使用rules-performance-simlate modem speeds功能启动弱网，然后通过rules-Customize Rules 对文件中m_SimulateModem的上下行延迟变更，或者右边FiddlerScript--Go to 选择OnBeforeRequest--找到 m_SimulateModem）
• 当需要对客户端测试一下特殊场景，可以使用fiddler设置响应断点，修改服务端响应的数据，测试客户端对应的逻辑处理，比如修改服务端返回状态为500

9. Fiddler抓APP请求的过程是怎样的？

• 首先保证手机和电脑是在同一个网络下，接下来在Fiddler上开启远程连接，并开启HTTPS，端口号默认是8888，也可以自己改。然后在手机的wifi里面去设置代理，填写电脑端的ip以及代理端口，再使用手机浏览器访问代理IP，下载证书并安装。设置好之后可以先抓一下，如果有问题就重启一下fiddler，就可以抓到App端的所有请求了

10. 你是如何保证测试质量的？

• 1.从需求分析上来讲，需求分析是测试质量的源头，需求要吃透，有哪些关联的模块，数据库有哪些关联的点，涉及到的显性、隐性的需求都需要搞明白，做完需求分析要进行评审，防止有遗漏的地方，评审会比较保险。多站在用户的角度去考虑，存疑的地方要多跟产品和开发进行沟通
• 2.用例方面，用例执行要仔细认真，预期结果要检查到位，进行交叉测试，可以多个人覆盖不同的测试考虑点，严格按照公司的测试规范去执行，且执行认真对待，而且一定要做冒烟测试
• 3.bug回归来讲，需求根据开发修改的建议，相关联的一个模块要回归一遍，bug本身也要回归一遍，还需要根据自己的一些测试经验，考虑一下开发没有考虑到的模块

11. 如果线上用户存在问题，该如何解决？

• 首先有用户发现的现成问题，可以通过分析日志来分析用户问题。如果不是现成的问题，可以通过用户当时的操作步骤和环境，去模拟用户的一个使用场景，在测试环境里去复现这个问题

12. 你是如何推进项目进度的？

• 开站会，同步开发与测试进度
• 分模块自动化测试，提高测试效率
• 持续集成，降低集成测试成本
• 多沟通，与上级，产品经理，项目经理进行沟通，提前评估意外的需求变更带来的风险

13. 项目中遇到了哪些问题？

• 内部问题：
  • 无自动化，测试效率低。推进自动化的测试能力
  • 有自动化，用例维护不及时。推进用例以原始数据的形式存储在数据库中
• 外部问题：
  • 无文档，与开发不属于同一团队的情况，大家都不愿意写。
  • 有文档，但文档更新不及时。提高自己对文档的重视

14. 你们项目的测试流程是怎样的？

• 需求沟通——>制定测试方案——>设计测试用例——>准备测试环境——>测试执行——>bug处理——>回归验证——>跟进上线
• 第一是测试需求分析阶段，这个阶段需要阅读理解需求，需要对业务进行学习，分析需求点，需要参与需求的评审会议。第二个是测试计划的阶段，主要任务是编写相关的测试计划，这块参考软件需求规格说明书，还有项目的总体计划，测试计划呢它包括测试的范围，进度的安排，人力和物力的分配，需要制定整体的测试策略，还要写风险评估和规避措施。第三是测试设计阶段，这个阶段要编写测试用例，需要参考需求文档和原型图，用例写完之后还要做测试用例的评审。第四阶段是测试执行，这个阶段我们要搭建测试环境，要执行冒烟测试，然后我们会进入正式的测试，缺陷的跟踪，最后是多轮的回归测试，直到测试完全结束。第五个阶段是测试评估阶段，这个阶段呢我们要些测试报告，需要确认是否可以正式的上线。第六也就是最后阶段，我们要做项目的总结复盘。
• 第一步就是根据需求进行分析，接下来根据分析出来的测试点，去编写测试计划和测试方案，测试计划主要就是我们的组织文件，测试方案主要是实施方案，这两项搞定之后，就根据它们下发到不同的人，继续编写测试用例，完了之后就开始执行测试用例，看执行完是否有BUG反馈，解决完BUG后，再循环下执行测试用例，没有的话就过，提交测试报告，看下整个项目的测试情况，这就是整个的流程

15. 如何制定测试计划?

• 测试计划包括测试目标、测试范围、测试环境的说明、测试类型的说明（功能，安全，性能，稳定性）、测试工具、模块的划分、测试负责人、测试执行轮次的时间安排、相关文档在文档管理库中的位置、测试的风险。其中模块划分需要根据测试人员对于业务的熟悉程度及个人能力进行分配，工作量的估算需要根据以往测试时的经验，结合本次需求的修改，可以大致估算出测试量

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

• 要素一般包括：用例编号，用例优先级，测试目的，所属模块，前提条件，测试环境，输入数据，测试步骤，预期结果，测试脚本等
• 核心要素：用例优先级，测试目的，预期结果

17. APP闪退是什么原因造成的？

• 可能是缓存的垃圾过多，长时间不清理垃圾，就会导致越来越卡
• 运行程序太多，导致内存不足
• 应用版本兼容性问题
• 网络的问题
• APP的SDK与系统不兼容
• 系统升级之后，它的新版本和老版本不兼容

18. 软件项目上线，发布流程是怎么样的？

• 项目发布流程一般的话就是我们测试完成之后会出一个报告，报告会确定我们这个项目是否通过，通过的话就通知开发运维那边可以发布项目了。一般情况下项目发布我们都选择的是晚上22点或者0点，这个时间用户使用量比较少，出现问题的话容易回滚，他们发布更新到线上的时候，测试这边需要去配合，在线上环境做一个基本的测试，看他更新后的版本有没有问题。如果出现问题，就需要开发那边紧急修复

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

• 1.抓包分析，通过对客户端进行抓包，分析服务端返回的数据是否符合预期，如果服务端数据是正确的，那就是客户端的问题
• 2.日志分析，可以通过查看客户端/服务端的日志，分析有没有异常的日志信息，从而确定具体原因

20. 产品需求经常变更信息不同步如何解决？

• 1.变更需求需重新评估排期，变更时要求信息同步，信息不同步，可能会引发资源安排的问题。有部分公司立项、需求评审没有通知测试，那么可以说明，当前没有可用的测试资源，测试任务需要往后排。如果需求变更过于频繁，可以把一个季度或半年的数据统计出来，公示并上报老板进行改进
• 2.多方监察制度，设置项目经理角色，发现需求变更提BUG并公示变更。
• 3.针对项目管理不规范的问题，需要明确项目流程，定义清楚三个关键节点。谁负责输入什么，输出什么，不同项目组允许有差异，每一个小团队适用不同的流程，引入成熟可用的项目管理工具，例如阿里云aone，云效平台，腾讯的tapd，小公司可以用禅道，规模化公司可以使用JIRA。

21. 如果漏测了BUG，项目上线后才发现怎么办？

• 软件的BUG是不可能杜绝的，哪怕是测试时间充裕的情况下，更何况研发部门给测试预留时间并不充足，所以当软件发布线上后，在所难免出现BUG。发现线上bug后，项目组应该快速响应并做处理，记录BUG产生的过程后，第一时间将bug修复。然后我们要总结反思，漏测的原因和后面规避的方案，以降低以后再次出现类似问题的概率
• 常见的漏测BUG的原因： * 1. 需求规格不明确，导致测试用例编写过于粗略 * 1. 需求规格变更，测试用例没有及时更新 * 1. 测试用例覆盖不全面，场景出现遗漏 * 1. 测试过程中未严格按照测试用例执行 * 1. 测试时间不充足，导致一些功能点在测试过程中被忽略 * 1. 测试环境或测试数据受限，导致缺陷漏测 * 1. 开发人员修复其它BUG时引入了新的bug

22. 当开发人员说不是BUG时，你如何应对？

• 开发人员说不是BUG，有2种情况:
  • 一是需求没有确定，所以这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不要改
  • 二是这种情况不可能发生，所以不需要修改，这个时候可以先尽可能的说出BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那可以将这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改，那么就要在测试报告里面记录一下，以便以后查阅

23. 你们公司的测试环境是怎么划分的？

• 开发环境：主要是开发自测用的环境
• 测试环境：主要是测试人员进行日常测试
• 预生产环境：是一个独立的测试环境，但是数据库用的是生产环境的库，主要用于上线前，使用生产环境数据进行测试验证
• 生产环境：对真实用户开放的运行环境

24. 什么是回归测试？如何做回归测试？

• 回归测试，既是在软件生命周期中，只要软件发生了改变，就可能给该软件产生问题；所以，每当软件发生变化时我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否破坏原有的正常功能
• 回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。如何做回归测试，有以下几点：
  • 1.在测试策略制定阶段，制定回归测试策略
  • 2.确定需要回归测试的版本
  • 3.回归测试版本发布，按照回归测试策略执行回归测试
  • 4.回归测试通过，关闭缺陷跟踪单（问题单）
  • 5.回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

25. 如何提交一份高质量的缺陷跟踪单？

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

26. Bug优先级和严重程度如何划分？

• Priority(优先级)的定义要依赖于Serverity（严重程度），在大多数情况下，serverity越严重，那这个bug的priority就越高。
• serverity（严重程度）：
  • Bloker（崩溃）：即系统无法执行、崩溃或者严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等
  • Critical（严重）：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定，系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等
  • Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等
  • Minor/Trivial(次要的/不严重的)：即易用性及建议性问题
• Priority（优先级）：
  • Immediate：即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求
  • Urgent：即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常- High：即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
  • Normal：即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
  • Low：即”低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决

27. 做好测试用例设计工作的关键是什么？

• 关键点就是熟悉需求，但是需求可以分为以下几个方面
• 1.熟悉本次业务需求
• 2.熟悉其他系统和本次需求的关联
• 3.熟悉开发设计文档，了解开发实现逻辑
• 4.熟悉数据库设计文档，了解数据存储
• 5.熟悉项目架构，发现隐藏需求

28. 给你一个网站，如何开展测试？

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

29. bug的生命周期？

• New（发现）：发现bug，未经评审决定是否指派给开发人员进行修改
• Open（提交指派）：确认bug，并且认为需要进行修改，指派给相应的开发人员
• Fixed（修改）：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
• Rejected（拒绝）：如果认为不是BUG，则拒绝修改
• Delay（推迟处理）：如果认为暂时不需要修改或暂时不能修改，则延后修改
• Closed（关闭）：修改状态的BUG经测试人员的回归测试验证通过，则关闭BUG
• Reopen（重新打开）：如果经验证BUG仍然存在，则需要重新打开BUG，开发人员重新修改

30. 如果让你单独负责项目，需要注意哪些事项？

• 评估项目的测试范围和测试周期，是否能单独完成
• 做好测试策略和计划安排，尽量保证每个环节按时完成
• 如果自己解决不了问题，及时向外抛出，暴露风险，寻求帮助
• 尽量采用一些技术手段，提升测试效率
• 对用例设置好优先级，按照优先级去执行
• 及时对BUG进行追踪，推动开发尽快解决BUG
• 把控好上线标准，测试报告中标明上线风险

31. B/S架构和C/S架构区别？

• B/S是浏览器/服务器架构，需要通用客户端（浏览器），主要压力在服务器
• C/s是客户端/服务器架构，需要专用客户端（如APP），客户端承担一部分工作和压力

32. 说一下令你印象深刻的BUG？

• 这个BUG并不是发生在我负责的系统上，而是发生在我们依赖的系统服务上，当时在测试商品分类页，分类页数据接口需要调用商品系统的接口，别的很多服务也依赖于商品系统的接口，在大促活动前，商品系统在夜间进行性能测试，突然发现我们的服务收到接口调用超时报警，一番排查后，才发现是调用商品系统的时候超时了，我们的服务没有做降级处理，直接给前段抛了个错误，还好是凌晨，给线上的用户影响较小，也敲响了警钟。后面我们直接做了降级处理，缓存了部分商品数据，等到商品系统大规模调用超时的时候，将调用商品接口直接关闭，走我们的缓存数据。这个bug提醒我，不要只关注测试自己的系统，要关注上下游的服务，每逢大促活动的时候，都要做性能测试，要对服务的性能有个预期
• 有个项目当时在测试跟进/更新、新增客户时，我选择客户类别后再操作删除对应的这个类别，然后查看已选择的类别没有自动清除，点击保存后，客户类别显示为null，通过抓包查看接口请求和响应，并跟开发沟通后，发现是我在前端操作后，后端的这个数据没有同步过来，响应中没有这个数据。这个bug提醒我，在测试时要尽可能多的发现异常场景。
• 我之前测试一个项目的分销功能时，我设置分销商的上级归属代理时，分别设置了市代和省代。在进行佣金结算时，我发现佣金结算金额不对。通过抓包分析，查看响应后我发现响应数据其只归属于省代，只取了一级代理的佣金比。联系了产品经理和开发后重新确认了代理结算范围和逻辑。这个问题让我懂得遇见问题后，不要先急着提BUG，要自己做一个初步定位，再提交开发，有异议的情况一定要寻找产品经理和开发一起进行解决，测试也要尽可能的对所测模块功能进行详细的测试分析才行。

33. 什么是持续集成，持续集成的目的是什么？

• 持续集成是指开发阶段，对项目进行持续性的自动化编译、测试，以达到控制代码质量的手段（频繁地一天多次将代码集成到主干）
• 持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量
• 持续集成一般的做法：通过git等拉取代码——>自动化构建——>自动化编译——>自动化测试——>自动化部署——>自动化发布

34. 用过Monkey嘛？用Monkey来做什么？

• Monkey是用来针对安卓APP进行稳定性测试的一个工具，之前用monkey测app的稳定性时，发现过一些crash的情况，当时通过查看monkey日志以及adb logcat日志，找到了一些空指针的异常报错，将报错发给了开发，后来开发判断是因为兼容性的问题，修复以后就没有问题了。

• 进入到adb工具包文件夹内打开doc命令窗口，使用adb命令：adb logcat -c清空旧日志信息， 这个xxxx是应用包名，windows下把 grep 改成 findstr 进行过滤日志信息

  adb logcat | grep xxxx

• monkey进行压力测试的命令：

  adb shell monkey -p \

  \

• 重现crash、anr过程：添加参数 -s seed（随机数种子），随机数相同事件相同

  adb shell monkey -s 6777 -p \

  \

35. 单元测试、集成测试、系统测试的重点是什么？

• 单元测试的重点是系统的模块，包括子程序的正确性验证等
• 集成测试的重点是模块间的衔接以及参数的传递等
• 系统测试的重点是整个系统的运行以及与其它软件的兼容性

36. 平时测试过程中，如何构造测试数据？

• 1.能用现有数据，就用现有数据
• 2.需要的数据量小的时候，可以通过页面操作来完成数据构造
• 3.如果需要的数据量大的时候，可以通过接口或者UI的自动化手段构造，或者使用存储过程，在数据库中直接创建数据

37. 使用判定表来描述下以下问题？

• 问题：某公司折扣政策：年交易额在 10万元以下的，无折扣；在10万元以上的并且近三个月无欠款的，折扣率10%；在10万元以上，虽然近三个月有欠款，但是与公司交易在10年以上的，折扣率8%；在10万元以上，近三个月有欠款，且交易在10年以下的，折扣率5%

•