测试常见面试题之客观题--上岸100%（纯干货分享--手把手教你面试）【2】

***** 项目相关的面试题 *****

1.简单介绍下你最近做过的项目吧？【高频】

        根据自己的项目整理--核心：

1. 项目背景，业务，需求，核心业务的流程；
2. 项目架构，B/S 还是 C/S，数据库用的什么? 中间件用的什么？后台什么语言开发的？是否有做 App 端？是否有 H5 页面？是否开发了小程序等等；
3. 项目前端有哪些功能模块，后台有哪些功能模块；
4. 你参与了哪些功能模块的测试，设计测试用例用了哪些方法，运用了哪些测试工具，除了功能，性能，兼容，易用，其他方面是否也做了测试。
5. 如果时间允许，可以简单说下对这个项目的复盘，让面试官觉得你有思考。

2.讲一下你所负责的模块，说下具体怎么测的？【高频】

根据自己的项目整理完成--核心：

1. 拿一个你负责过的模块，核心业务模块讲解；
2. 业务流程是怎样的，需求怎么样，有什么规则没，规则简单介绍；
3. 你是如何分析的，讲明分析思路，测试点，主要怎么考虑测试的，主要核心测试重点在哪里，用了什么测试方法等等。

3.你们几个测试是怎么分工的？

        我们测试组 3 人，1 个测试组长，2 个测试。一般都是根据需求的复杂程度大小来，尽量是自己熟悉哪个版块的就继续做那个版块。

        例如：我这边主要是负责前端大部分的功能模块，还有接口测试跟 UI自动化测试，另一个同事主要是功能测试这边，组长这边也负责一些功能测试，包括一些性能跟安全测试。其实测试工作也划分的没有那么细，后期我们也会做交叉测试，相互测试功能，性能跟安全测试我也会参与一下。

4.你们项目的迭代周期是多久？BUG数量能有多少？【高频】

3种答案可参考：

• 介绍开发模型+大/小迭代周期介绍【比较符合小型公司的现状】：我们公司项目属于敏捷开发，一般迭代时间不会太久，小版本一周一迭代，大版本两周一迭代。BUG 的话每个版本都不太一样，小版本的话大概也就会有5-10，大版本20-40 不等。
• 普通只有一种迭代周期【中型项目】：我们公司是这样的，迭代还是蛮快的，一般是两个星期一个迭代，迭代测试两轮。Bug 的话不一定哦，关键还得看开发，开发的版本质量好的话，BUG 就会少些，整个版本比较好的情况下大概也就20个左右 BUG。当然如果遇到开发是个新手，那么找到 60-70 个也是很常见的，比如之前的那个金融项目，足足发现了 72 个 BUG，这样的情况下追踪 BUG 的工作量都比较的大，如果是版本选代的话，那么基本就不会出现多少 BUG 了。
• 长迭代（大版本）适合大公司【以维护为主，成熟的大项目】：因为我们项目的用户活动和三方合作平台比较多，一般半个月或者 1 个月肯定会有一个迭代版本，假如用户或者合作方突然有很紧急的需求，那一般老大他们会向上发邮件和 OA 呈批给(产品经理，项目经理)，如果通过了就会马上加急处理这个需求，测试完成直接上线。现在都是维护为主，但新需求也不断有，一般一个版本上百个 bug 是有的。

5.你们整个项目写了多少用例？你负责的模块大概写了多少条？【高频】

[切记己根据自己的项目及负责的模块来]

        答：这个得根据项目的复杂程度，我们最近做的这个也还好，整个项目写了大概一千多条，我负责的模块就写了一千多条(你要思考，你负责了哪些模块，大概评估下，不要乱喊)。

总结注意点：没有标准答案，先说你的前置条件，再说数据，只要你前置条件和数据匹配即可。

6.UAT测试的时候，你们一般会怎么做？

注意点：面试官就是想测试下你知不知道，UAT测试就是用户验收测试，纯纯就是想装一下~

        答：我们测试这边提供测试用例，UAT环境搭建好后，通知用户来执行测试。如果发现问题，需要协助，谁负责这个需求，就找对应的人；发现 bug，提交到UAT版本里面；修复完了，

客户需要回归验证的，我们公司只是辅助用户去执行测试。

7.具体讲讲你印象深刻的BUG

根据自己的项目来准备--核心：

1. 有哪些经典或者说影响比较深刻的 Bug，最好是与业务相关的 Bug，不要举例说前端的 Bug；
2. 具体怎么分析，讲明你的分析过程。如何定位的……

• 业务漏洞：但业务漏洞一般会让面试官觉得漏测，除非有那种不会引火上身的业务点，或者不是你测的模块，你可以说下，后面加一句，我也要引以为戒等等这种。

1. 支付功能:
   1. 商品选择支付的时候，实际已扣款成功，但是用户后台显示该商品没有付款，导致不能使用该商品提供的服务。
   2. 商品所显示的价格是 x 元，但是实际支付的时候显示和扣款的价格是 y 元(x≠y)。
2. 找密码流程：按照常规操作，会直接跳跃了某个必须的流程(流程缺失)，但是通过 url 修改参数又可以访问到该流程，存在安全和逻辑漏洞。

• 安全漏洞：

1. 登录账户：退出 or 注销之后，浏览器返回键回退之后又可以回到已登录的页面继续操作，识 别用户身份的信息并没有失效，用登录后才能访问的 url 直接访问也可以登录，安全漏洞。
2. 搜索功能：前端页面的搜索输入框中输入特殊敏感符号(如 script> alert(document.cookie)</script)，直接搜索后有可能把当前登录账户的cookie 信息直接以弹框的形式暴露出来。
3. 新增功能：一开始没有限制字符的类型和数量，当输入特殊符号、超长的字符，提交后直接抛出包含有 INSERT INTO 的完整 SQL 语句。
4. 前端搜索：以敏感字符直接搜索后，客户端和服务端都没有任何字符过滤 or 转义处理，直接把数据库和网站服务器的名称、版本暴露。

• 数据调用/加载异常：

1. 翻页功能：有时候会出现前面几页翻页和数据显示都是正常的，往后再翻页就会出现翻页不了 or 加载的数据异常。
2. 前端页面有几级菜单的情况下，程序都已经调用过，第一级是正常展示的，但是第二级、三级有可能被折叠而没有显示在浏览器显示。

就类似的吧，准备也应该有点带难度的，别一点难度都没有，这会显得你的项目没有难度，而且你没有思考。

***** 测试思维相关的面试题 *****

1.打电话这个功能你要怎么去测试？

我们会从以下几方面去思考测试：

• 界面：界面的话，我们会测试实际设计的电话机样式界面是否跟原型图一致；【如果是web网页端的页面需要考虑到网页设计与原型图是否一致，考虑系统不同缩放比，浏览器不同显示比例，是否页面自适应，显示器屏幕分辨率等；】
• 功能：给不同人员打电话；不同号码打电话；不同运营商；测试每个按钮是否正常使用；拨打号码，是输入还是其他方式；是否可以复制；多次拨打同一电话，双卡选择不同电话卡；
• 兼容性：不同手机型号，厂商，不同电话机的系统版本，电话机的屏幕大小，是否有分辨率，内存大小；
• 易用性：操作应越简单越好；
• 安全：是否会泄露通话，是否会被窃听；
• 性能：一天或是几天一直在通话是否会有中断的情况，一直操作一个按键会出现什么问题；
• 异常：扣下一个按键是否还能打电话，等等类似的，可以考虑破坏测试。

2.给你一个杯子，你会怎么测？

• 功能测试： 重点 -- 水杯的基本功能

1. 水杯是否可以正常装水；
2. 水杯是否可以正常喝水；
3. 水杯是否有盖子，盖子是否可以正常盖住；
4. 水杯是否有保温功能，保温功能是否正常保温；
5. 水杯是否会漏水，盖住盖子拧紧后是否会漏水。

• 界面测试： 重点 -- 水杯外观、颜色、设计等方面

1. 水杯外观是否完整；
2. 水杯外观是否让人看着舒适；
3. 水杯颜色搭配及使用是否让人感到舒适；
4. 水杯外观，大小是否适中；
5. 杯子是否有图案，图案是否易磨损。

• 易用性测试： 重点关注水杯使用是否方便

1. 水杯喝水时否方便；
2. 水杯拿起放下是否方便，这里会延伸到水杯形状的测试；
3. 水杯装水是否方便；
4. 水杯携带是否方便；
5. 水杯装有低温或者高温水时，是否会烫手。

• 性能测试：重点关注最大值，边界值等

1. 水杯装满水时，是否会露出来；
2. 水杯最多使用的次数；
3. 水杯的保温性是否达到要求；
4. 水杯的耐寒性是否达到要求；
5. 水杯的耐热性是否达到要求；
6. 水杯掉落时，是否可以正常使用；
7. 水杯长时间放置时，是否会发生泄露。

• 兼容性测试： 主要关注水杯是否可以装其他液体

1. 承装其他溶液，果汁，汽油，酒精等化学试剂

• 可移植性测试： 主要关注水杯放置环境等

1. 将水杯放在常温环境中，使用是否正常；
2. 将水杯放在零下的环境中，使用是否正常；
3. 将水杯放在高于正常温度的环境中，使用是否正常。

• 安全性测试： 主要关注水杯外观和各种异常条件下是否释放有毒物质等

1. 当水杯装满热水时，水杯是否会烫手；
2. 当水杯装上水后，是否会产生有毒物质；
3. 把水杯放在零下环境时，是否会产生有毒物质；
4. 把水杯放在高温环境时，是否会产生有毒物质。

3.图片上传功能的测试点【高频】

1. 检查图片上传路径；
2. 检查图片上传和修改功能；
3. 检查各种格式图片文件的上传（例如 JPEG、PNG、BMP 等）；
4. 检查文件名中含有空格或其他可用特殊字符的图片的上传；
5. 检查重复名称图片上传；
6. 图片尺寸大于最大允许范围值，上传时应该显示适当的错误消息；
7. 检查上传的图片文件类型外的其它文件时(例如 txt、doc、pdf、exe 等等)，应该显示适当的错误消息；
8. 检查如果上传的图片满足指定的高度和宽度(如果有定义的话)则可以成功上传，否则不能上传；
9. 上传大尺寸图片时应显示上传进度条；
10. 检查上传过程中的取消按钮是否有效；
11. 检查文件选择对话框中的文件列表是否只显示支持文件类型；
12. 检查上传多个图像的功能；
13. 上传后检查图像质量，图像质量不应该改变；
14. 检查用户是否能够使用/查看上传的图像。

4.搜索框的测试【高频】

遵循原则--适应于所有输入框，搜索框：等价类（分有效等价类--正确的业务流程，无效等价类--字符的类型，长度，是否为空，是否已存在等等）边界值（5个点，上点，内点，离点），接口上传参（多参，少参，错误参等）

1. 搜索按钮功能是否能够实现，验证搜索框的功能是否与需求一致；
2. 点搜索后，原先的搜索条件是否清空；
3. 直看比较长的名称是否能查到输入过长查询数据，看其有没判断，报错系统是否会截取允许的长度来检索结果；
4. 是否有忽略空格的功能，需要有忽略前置空格和后置空格的功能，但不能把中间空格忽略；
5. 不输入任何内容点击搜索看查询的结果；
6. 查看搜索框内的默认内容是否与设置的一致，焦点放置搜索框中，搜索框默认内容是否自动被清空；
7. 输入系统中存在的与之匹配的条件看其的查询后数据的完整性显示记录条数正确、文字折行显示正确页面布局美观列标题项、列显示内容、排序方式符合需求定义；
8. 组合中文和各种特殊符号输入查看能否正确搜索到合的内容；
9. 输入系统中不存在的与之匹配的条件，是否搜索出信息或者给予提示信息；
10. 使用复制粘贴，测试搜索框是否能执行；
11. 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方；
12. 反复输入相同的数据(5 次以上)看是否报错；
13. 敏感词汇，提示用户为敏感词汇；
14. 对于搜索功能
    1. 搜索功能：有的页面本身有回显搜索关键词的功能，搜索输入框填写的 keywords 字符较长(如：100 字符)，直接搜索后这些长字符显示在页面中，使得页面原来的样式变形，甚至有的功能按钮被挤到页面之外而不能使用；
    2. 新增功能：对于新增字段的长度没有任何限制，超长字符新增可以保存成功，回到列表页也没有对显示的字符长度进行控制，所有字符长度都展示在列表中。
15. 不同搜所的条件之间来回选择，查看是否出现页面错误；
16. 测试多个搜所条件时，要注意搜所条件的组合测试，可能不同组合的测试会报错；
17. 点击搜索框，看能否在搜索栏下方显示提供设置好的最近热门搜索词，点击任一可以直达搜索结果页；
18. 点击搜索框时，到有搜所历史时，能显示历史搜所内容，历史搜所内容应从上到下按时间排序，点击清空历史清空所有搜索记录；
19. 直看搜索框最大输入字符数。