说下你最近做的项目，你主要负责什么？说说 xx 模块是怎么测试的？

考察点：

项目的测试思维

面试命中率：

95%以上

参考答案：

• 熟悉项目业务流程，用 2-3 句话简单的总结概括介绍一下项目业务（每个人根据自己简历里写的项目进行总结）

• 自己主要负责的模块：注意说核心业务功能模块，避免说注册登录这种技术含量略低的模块，体现自己有涉及到项目的核心功能；

  然后说明自己负责这个模块的测试内容 ，比如功能测试，接口测试，自动化测试，性能测试等。

• 继续追问你xx模块你是如何测试的？

  就按照以下3步：

  1）说明需求条件和约束；

  2）然后再说明自己测试点和提取测试点的用例设计方法  

  3）再说明具体的测试点，包含正常和异常的测试点 

数据库增删改查语法的使用都知道么？Group by 和 order by 区别？Drop 和 delete 的区别？怎么插入部分数据？

考察点：

数据库的知识

面试命中率：

80%+以上

参考答案：

• 增删改查基本都会用；包括单表查询 多表关联查询，左连接 右链接等

• Group by 是分组，一般需要进行一些数据统计的时候，比如一个群体里最大数据、总数、数量平均数等都会用到分组；

  Order by 是排序，就按照升序或者降序排列的；

  两个如果要一起使用的话，先分组后排序，先 groupby，后 order by。

• Drop 和 delete 都是删除数据库的数据的命令，但是 drop 会删除表、库的结构，delete 不会删除表的结构，只会删除里面的数据。测试的话用 delete 会更多一些。

• 插入部分数据：Insert into (字段）values1，values2

Linux 的命令会哪些？怎么在 Linux 创建文件夹？怎么查找文件和文件里的内容？怎么查看文件 100 行到 200 行？

考察点：

linux操作命令

面试命中率：

90%+以上

参考答案：

• （注意：Linux 命令结合业务操作去说，不要简单罗列：还有一些简单的命令不要说，比如 ls cd pwd 这种初级命令）

  我们工作中使用 Linux 基本都搭建测试环境，所以一些解压命令 tar，还有文本编辑命令 vi/ VIM，以及查看服务是否启动会通过查看进程 ps -ef 命令，查看端口状态 netstat -apn，还有赋权命令 chmod，查看文件 cat tail more less 等，以及分析问题的时候查看动态日志 tail -f 等；

• 创建文件夹命令是 Mkdir xxx ；

• 查找文件用 find 命令，find / -name 文件名；查找、文件里的内容用 grep 命令；

• 查看文件 100 行到 200 行命令：head -n 200 filename | tail -n 100

Jmeter 怎么做接口测试？怎么测试接口的关联？

考察点：

接口测试和jemete工具

面试命中率：

95%+以上

参考答案：

• 首先我们做接口测试的流程是：根据开发提供的接口文档，编写接口测试用例；然后根据用例使用 Jmeter 进行测试；

• Jmeter做接口测试：测试计划-->添加线程组-->添加http请求-->输入url+端口+请求方法+参数-->添加头部信息-->添加查看结果树查看响应消息
  
  然后对比接口测试用例的预期结果，同时也会同步检查数据库，确认接口测试结果的正确性（可以使用Navicat连接数据库，或者用 Jmeter添加jdbc请求获取数据库信息）。还有就是一些数据也会定义为用户变量调用；以及批量测试，会使用csv测试元件读取数据进行批量测试；

• 接口关联：我们用的是 Jmeter 的后置处理器，JSON 提取器和正则提取器，比如 cookies token 就可以提取出来赋值给一个变量，然后下个接口调用这个变量即可；

app 测试和 Web 测试的区别？

考察点：

APP测试和WEB测试

面试命中率：

80%+以上

参考答案：

• app 测试和 Web 测试的测试方法和功能测试都是差不多的；主要是区别有以下几点：

• APP 需要单独测试安装、卸载和升级，Web 是不需要的

• APP 还有些手机行为特定的测试点，比如网络类型测试（3G4G5Gwifi 热点）等各种网络类型/切换，还有弱网测试；以及中断测试，因为手机有很多行为会导致 APP 被打扰中断了；还有消息推送的测试，以及手机的权限测试等；

• 还有一些横批竖屏切换的测试，以及手势、触屏支持的测试等，这些都是是 APP 需要 而 Web 端不需要测试的；

• 兼容性：APP 要考虑手机型号 系统版本，屏幕大小等兼容性需求，而 Web 端需要考虑的是浏览器的兼容性测试。

fiddler 怎么对 app 进行抓包？Fiddler 怎么设置弱网？弱网测试的关注点？

考察点：

fiddler抓包工具

面试命中率：

90%+以上

参考答案：

• fiddler 抓手机的包：需要被 APP 端设置代理，指向 fiddler；并 fiddler 上配置好端口和允许远程机器连接；如果需要抓取 https 的报文，还需要安装证书，进行报文解密；

• fiddler 设置弱网环境：就是在 fiddler 上配置规则-增加丢包和延迟，然后把 fiddler 设置为手机的网络代理；让 APP 的浏览都走 fiddler 模拟出来的弱网环境；

• 弱网测试的关注点：

• a、数据不会重复提交

• b、提示友好

• c、不会发生 ANR 和 crash

bug 定位有哪些方法？/用什么方法定位区分出前后端 bug？

考察点：

bug定位/抓包工具

面试命中率：

95%+以上

参考答案：

• bug 定位的方法主要有抓包和分析日志，以及数据库数据定位；

• 区分前后端 bug 主要通过抓包分析：

• 如果这个 bug 是界面排版布局错误，像兼容性问题，则很明显是前端 bug；
  对于网络不稳定下导致的 js/css 未加载完全或请求超时，可以优化前端代码，例如压缩 js/css，增加超时时间；一般这种不需要提 bug；但正常网络下加载页面元素超时(抓包可以看到加载元素时间)，前端 bug

  而对于数据或逻辑处理上的问题，则可以通过抓包工具来进行接口分析，网站项目的话可以通过 F12，移动端 app 项目通过 fiddler

  a、检查前端没有发出请求，或者请求的参数有错误，就是前端的问题。

  b、前端发出了请求，参数没有问题，，后端没有响应或者后端返回数据有问题，就是后端的问题。

  c、后端返回了 也是正确的，但是前端没有正确显示的，一般就是前端渲染响应的数据出错，就是前端问题

• 并且可以通过同步查看报错日志、查看数据库数据判断哪一层面的问题

开发认为你的 bug 不是 bug 怎么办？出现偶现 bug 的如何处理？

考察点：

bug跟踪和管理流程

面试命中率：

95%+以上

参考答案：

1.开发说我的 bug 不是 bug，我要怎么办？

• a、告知开发 bug 的判断依据，同时明确开发说不是 bug 的理由。
  b、对开发的理由进行校验，校验依据

• 1.参照需求文档，

• 2.参考成熟产品的实现；

• 校验后，如果我认为仍然是 bug，就跟开发沟通，从需求和成熟产品罗列证据，说服开发修复这个 bug；
  c、如果沟通依然无法达到一致，就跟产品经理进行沟通确认。
  d、如果跟产品沟通确认后，如果是 bug 提交给开发进行处理，确保产品质量；如果产品说不是 bug，就更新 bug 备注并关闭这个 bug。

2.出现偶现 bug，你要怎么处理？

• a、先记录这个 bug，并且多次进行复现尝试，标记 bug 的复现率；如果复现率比较高，可以催促开发修复并提供日志和截图

• b、如果复现比较低，可以在复现的时候，叫开发过来测试环境进行定位和收集有用信息，辅助修复 bug

• c、跟踪多个版本如果依然无法复现，就可以在临近发布之前，备注这个 bug 并关闭。

tcp/ip 协议，三次握手和四次挥手的过程？ACK 是什么？

考察点：

网络协议和网络基础知识

面试命中率：

75%+以上

参考答案：

• TCP 三次握手过程和四次挥手的过程图解：

  

• ACK 是一个确认报文，确认上一个报文是否收到，以及收到的是否正确。

web 兼容性测试怎么做的？

考察点：

兼容性测试

面试命中率：

85%+以上

参考答案：

Web 兼容性测试 ：主要考虑的是浏览器的兼容性测试，选择浏览器做兼容性测试主要有三个原则：

• 用户指定的浏览器优先测试

• 根据浏览器的内核类型选择不同内核的浏览器进行测试

• 同类型内核的浏览器不较多的时候，根据用户使用量选择主流的浏览器进行测试

然后兼容性测试一般都是伴随着功能测试一起测试的，检查页面的显示和友好性。

讲一下最近做的一个项目？

考察点：

项目业务流程

面试命中率：

99%+以上

参考答案：

我最近做的一个项目是个电商网站，他是一个 xx 品类的，然后他主要涉及的功能模块有注册、登录、还有购物车，订单查询这几个模块。（项目的简单介绍）

我测试这个项目的时候，负责的是功能方面的一个测试用例编写，写完以后，我会我们测试内部会进行一个用例评审，评审完以后会进行对功能测试用例进行一个测试执行，如果发现问题会提交 bug 到 bug 管理平台；（功能测试流程）

然后也有做过接口测试，根据接口文档编写接口测试用例，选择 Jmeter 执行，如果执行过程中如果发现问题也会提交到 bug 管理平台；（ 接口测试流程）

再测试之前我们也是搭建的测试环境，最后测试结束后，评估一下 bug 和测试用例是否达到上线的标准，并编写一个测试报告；这就是是大概这样的一个工作流程。

那你能讲一下你这个项目中的购物车，你当时测试了哪些测试点呢 ？

考察点：

测试思维

面试命中率：

90%+以上

参考答案：

• 分为已经登录和未登录的场景；如果是未登录的话，添加购物车就提示登录页面让先登录；已经登录的话，可以正常操作；

• 进入购物车的入口--一般比如淘宝有商品页顶部去购物车，还有从首页的顶部去往购物车；都能跳转

• 购物车的商品-- 一件 多件，多个商家 多件商品；显示，并且点击可以跳转到商品详情页；

• 商品数量的增减和输入，从输入的数据类型、库存、限购规则进行考虑，找到有效等价类和无效等价类 ，以及下架、无货的商品显示；

• 选择 全选 和删除商品， 确认总价 结算里的数量和总价

• 点击结算 可以跳转到 订单页面，考虑跟订单交互模块的交互

• 考虑跟优惠券的交互

再考虑非功能测试：

• 界面：页面的美观，没有错别字 和 页面排版等

• 兼容性：Web 端的能兼容主流浏览器，APP 端能兼容手机和系统版本

• 性能：多次访问，长时间访问 考虑稳定性等

• 安全：敏感信息的传输，漏洞扫描等

你讲一下登录的话你都考虑哪些测试点呢？

考察点：

测试思维

面试命中率：

90%+以上

参考答案：

登录的话，明确一下需求，比如有几个输入项，假如说有 3 个输入项：用户名和密码，验证码；

功能方面，先考虑到正常登录；然后针对每一个输入项考虑一些异常的情况：比如说手机号码的位数（10,12 长度）、数据类型支持的什么格式（非数字-字母字符空格），当输入 0 的时候，然后输入负数，重复输入的时候，以及不输入（为空的时候）；

然后是密码同样的从这几个维度来考虑，使用等价类和边界值的方法来设计测试点，以及验证码；大概是这样的一个测试点的考虑。

如果是非功能方面测试的话，会测试一下它的兼容性（），还有一个界面（美观 排版 错别字），兼容测试的话是 Web 端的话，测试一下浏览器的兼容，还有一些像、、那个界面测试的话，像页面布局，文字大小是否完整、规范这些，只要是页面可以点到的地方都会做一下功能点的测试，大概就是这些。

你知道有哪些 http 的状态码吗？

考察点：

http协议的常用状态码

面试命中率：

90%+以上

参考答案：

• 1xx：这类状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。

• 100 继续。

• 101 切换协议。

• 200 -OK：表示从客户端发送给服务器的请求被正常处理并返回；

• 204 - No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；

• 206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的 GET 请求，响应报文中包含由 Content-Range 指定范围的实体内容。

• 301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的 URL，之后应使用更改的 URL；

• 302 Found：临时性重定向，表示请求的资源被分配了新的 URL，希望本次访问使用新的 URL；

• 303 See Other：表示请求的资源被分配了新的 URL，应使用 GET 方法定向获取请求的资源；

• 304 Not Modified：资源没有改变，已经被缓存了

• 400 Bad Request：表示请求报文中存在语法错误；

• 401 Unauthorized：未经许可，需要通过 HTTP 认证；

• 403 Forbidden：服务器拒绝该次访问（访问权限出现问题）

• 404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；

• 500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是 Web 应用存在的 bug 或某些临时的错误时；

• 503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

平时会用 SQL 吗？左连接会写吗？SQL 的增删改查

考察点：

数据库的基本使用

面试命中率：

90%+以上

参考答案：

• Insert into 插入一个表

• 删除的话是 delete from

• 查询语句一般是用 select from

• 修改使用 update set

• 左连接：left join ，规则：以左表为准，右边不存在得到字段用 Null 替代

在测试报告到产品上线之间测试会做什么事情？

考察点：

项目的测试流程

面试命中率：

90%+以上

参考答案：

我们测试做完测试工作后，就会评估产品的质量（用例 bug），然后下一个结论是否达到上线的标准。这个报告会发给相关的项目人员，比如开发、产品、项目经理等；

然后我们的产品部门会进行一轮验收测试（UAT），验收测试没有通过，就要打回到测试部门重新测试；如果通过了，就会进入上线流程：

开发会进行打包，做一个线上的包，然后由我们的项目经理和运维部署到生成环境上；

测试会在生成环境上进行基本功能的验证，确保线上版本的质量；有问题就及时回滚，没有问题，就上线成功。

产品发布到线上的过程测试会介入吗？发布之后在质量这块测试会做什么？

考察点：

项目的测试流程

面试命中率：

85%+以上

参考答案：

会的。

• 测试报告评估质量；

• 测试要随时等待开发的做好版本，部署到线上环境，然后测试要进行简单的验证的，防止线上版本出现严重问题；验证通过后，才能宣布上线成功；验证不通过，要进行版本紧急修复，然后再次上线。

• 发布之后，我们会进行线上问题的跟踪；如果有用户 bug，需要复现和跟进的，

• 并且如果是测试用例里没有的，需要丰富到测试用例库中；----持续完善测试用例

• 另外，也会统计和分析一些用户常用的使用场景，通过分析用户行为调整我们的测试策略和侧重点；方便更好的提高用户的体验。

在测试报告阶段做缺陷分析的目的是什么？

考察点：

测试报告和缺陷分析

面试命中率：

85%+以上

参考答案：

做缺陷分析的目的是有几个：

• 通过分析缺陷的状态，比如还有哪些是打开状态的，有哪些是不修复状态，延期状态的等，可以知道目前剩余 bug 的风险，以及有无达到上线的标准；

• 还可以分析 bug 严重级别占比：一般正常的分布应该是一般 bug 比较多，严重和致命的 bug 比较少，如果出现了异常的分布，就需要分析下原因是什么，做好优化和规避；--开发问题，代码审查，

• 按照模块来进行分析分析：一般功能复杂的模块 bug 也会比较多，如果同样出现异常的话，也可以分析得出开发或者测试这边的工作问题；

• 按照版本进行分析（bug 分布统计）：一般正常情况下，随着版本的增加，bug 数量应该是越来越少的，如果出现异常，就可能是中间流程上的问题，或者有新需求加进来了，或者是开发修复 bug 出现严重的回归问题等。

• 总的来说，就是通过缺陷分析，评估产品的质量测试流程（测试 i 开发 产品 ）做一些优化。

测试过程中怎么管控质量？怎么确定产品是否合格？

考察点：

测试质量保障

面试命中率：

80%+以上

参考答案：

• 通过把控测试用例测质量，按照一些用例设计方法来设计用例，并且加强评审和优化；

• 通过进行组内的交叉测试，可以避免一些固化思维带来的漏测；

• 可以通过使用自动化测试，来提高测试效率，从而可以提高测试质量。-- 回归测试 自动化

• 需求阶段加强评审

测试报告里涉及到：

• 测试用例是否执行完成。测试用例在产品上线前至少要完成 90%+ 的用例，剩下的用例应该要标明原因，以及优先级比较低的；

• 剩余 bug 的数量和验证程度要达到标准。剩余 bug 不应该还存在 blocker、critical 级别的 bug，如果有不能上线；剩余的 major 的 bug 应该不超过一定的比例（根据公司情况而定）。

• 上线前的最后一轮的回归测试有完成。最后一个版本也就是上线的版本一定要经过一轮完整的回归三个条件之后，即可达到上线的标准。

一条 Bug 记录中包含了哪些记录？如何提交高质量的软件缺陷(Bug)记录 ？

考察点：

测试缺陷记录

面试命中率：

85%+以上

参考答案：

bug 包含：标题，步骤（测试数据），测试结果，预期结果，bug 的严重级别和优先级，功能模块和指派，附件（日志）

提交高质量的 bug 注意几点：

• 标题清晰：写好哪个功能模块，以及操作和现象结果；--从标题中就可以知道什么问题。

• 步骤详细：写好每一步操作，有数据提供数据（登录账号/上传文件等），提供截图（证据，而且更加清晰！）

• 执行结果：把操作结果描述清楚，提供截图（动图，视频）；

• 预期结果：来自于测试用例，指导开发如何修复这个 bug 的，所以要合理清晰。

项目流程和测试方面有什么需要优化的吗？

考察点：

测试流程

面试命中率：

85%+以上

参考答案：

主要优化有以下几个方面：

• 设置严格的时间节点，并督促开发和测试执行；因为我们现在很多时候就是开发的时间被拉长，测试的时间被压缩的很少，这样很不利于测试质量的保证；--共性

• 加强测试用例的评审流程；现在评审有但是不是很严格吗，而且开发和产品部分也不会参与进来；但是其实很多开发和测试理解不一致的地方和信息不对等的情况，就可以通过用例评审来规避的；

• 加强开发的代码审核，以及单元测试监督；经常有一些胡回归测试的 bug 其实就是开发修复代码引起的；加强代码审核，以及开发自测，也可以规避这些问题。