测试常见面试题

项目的测试流程

1. 需求可行性分析，需求评审

   由产品发起，大型需求必备评审环节，测试需要提前理解需求，存在疑问点直接在会议上提出来

2. 业务流程分析，技术评审

   由开发发起，针对实现方式进行说明。

3. 测试计划制定

   制定模块测试计划，确认测试时间。该时间不包含开发修复bug时间

4. 测试用例设计

   测试根据测试方法进行测试用例设计

5. 测试用例评审

   测试核心环节，切记需要将每个模块功能点对应到具体人，颗粒度达到前端，后端; 关键注意点需当面说清楚

   需求理解中存在歧义，理解不清，现场要求产品确认统一意见

6. 测试用例更新

   存在需求变更时需要维护测试用例

   测试用例评审结束，更新会上变更点并广而告知

7. 等待开发包

8. 部署测试环境

9. 功能测试

   1. 页面初始化测试
   2. 执行测试用例
   3. 提交缺陷
   4. 缺陷跟踪处理
   5. 非功能性测试（sql、js注入、页面效率、绕过js验证直接添加数据到数据库）

10. 灰度测试（预生产环境）

11. 上线后的线上回归测试

12. 上线后的项目沉淀，项目总结，测试报告

测试用例设计方法

等价类、边界值、因果图、判定表、正交分解、场景分析、错误推测

测试用例的要素

用例编号 所属模块  用例标题 重要级别 前置条件 测试数据  操作步骤 预期结果

测试的优先级

1. 先测试变更的部分，然后测试没有变更的部分
2. 先测试程序的核心功能，然后测试一般功能
3. 先测试逻辑性的功能，然后测试业务性的功能
4. 先测试常规情况，然后测试异常情况
5. 先测试功能，然后测试性能

测试报告包含哪些内容

测试背景 -- 测试目标 -- 测试范围 -- 测试环境 -- 测试数据 -- 测试标准（重点） -- 测试进度 -- 测试结果 -- 测试结论

有些公司会采用非标准的测试报告, 大致会包含

测试所用时间 -- 测试环境 -- 测试人员 -- 测试发现bug数量 -- 已修复bug数量 -- 遗留bug -- 遗留bug原因 -- 测试结果等

BUG的生命周期

提交 -- 开发验证 -- 接受/拒绝 -- 开发解决 -- 测试人员验证 -- 关闭 -- 不通过 -- 重新打开

BUG的状态

1. NEW：所有提交到开发对接的问题状态为NEW，表示为未处理
2. OPEN：开发对接人初判为需流转问题，指定测试人员和开发人员，状态为OPEN。
3. REFUSE：开发对接人判断为不需要流转至下环节的问题，状态为REFUSE，并且填写原因
4. FIXED：开发人员完成修复，待测试，状态为FIXED
5. REOPEN：测试人员针对开发人员的修复结果测试不通过，状态为REOPEN
6. CLOSE：测试人员判断问题为需求或其他问题，需填写原因；

缺陷的要素

缺陷标题 -- 缺陷状态 -- 影响版本 -- 提交人 -- 负责人 -- 优先级 -- 严重程度 -- 缺陷描述 -- 时间 -- 截图

缺陷的级别

致命问题：核心功能不可用或系统崩溃

严重问题：业务主要流程无法使用，业务主要流程中的某个功能存在缺陷导致主要流程无法继续使用

一般问题：一般性问题，非主要流程上的功能缺陷

轻微问题：界面ui问题 提示不规范等

建议性问题：根据自己的经验提一些建议性的问题

WEB测试与APP测试的区别

1. 架构不同

   1. web端是b/s架构的，b/s架构是基于浏览器地址访问的
   2. app端是c/s架构的，c/s架构是要有客户端作为载体的

2. 版本发布的方式和流程不同

   1. web发版本，开发部署新的代码到对应服务器地址，就可统一实现web端的更新
   2. app发版本，开发需要打包（apk包和ipa包），打包之后需要发布到对应的渠道

3. 兼容性

   1. web，测试不同浏览器的兼容性（ie、chrome、firefox、360、QQ）
   2. app，测试不同的分辨率、屏幕尺寸、手机品牌、系统版本

4. 性能方面

   1. web，测试响应的时间
   2. app，测试响应时间、流量、耗电量、CPU、GPU、memory

5. 安全性

   1. web，sql注入。xss攻击等
   2. app，https加密、签名、加固、密码加密等

app测试特点

• 适配性测试
• 网络测试
• 在线升级测试
• 中断测试
• 耗电量测试
• 弱网测试
• 安装卸载测试
• 流量测试

app测试的主要内容

1. 功能测试

   • 业务逻辑正确性的测试

2. 兼容性测试

   • 系统版本
   • 分辨率
   • 网络情况

3. 异常测试

   • 热启动
   • 网络切换

4. 升级、安装、卸载

5. 健壮性测试

   • 手机资源消耗
   • 流量消耗
   • 电量测试
   • 崩溃恢复

如果一个bug，开发认为不是一个bug，怎么处理

1. 将问题提交到缺陷管理库里面进行备案。

2. 获取判断的依据和标准

   根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

   如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

3. 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。

4. 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

什么情况下定位不到元素

1. 代码写错
2. 元素未出现（需要元素等待）
3. 元素在iframe中
4. 多窗口
5. 出现弹窗（系统弹窗、JS弹窗）
6. 元素属性值是动态加载的
7. 元素无法确定唯一性
8. 只读属性（元素不可操作）

GET请求和POST请求的区别

1. GET使用URL或Cookies传参，POST将数据放在BODY中
2. GET的URL会有长度上的限制，POST的数据则可以非常大
3. POST比GET安全，因为在地址栏不可见
4. 一般GET用来获取数据，POST用来发送数据

为什么要做接口测试

1. 越底层发现BUG，修复成本越低
2. 前端发生变化时，后端接口可以不用变
3. 检查系统的安全性、稳定性，前端传参不可信

接口测试是怎么做的

• 由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、Apifox等
• 也可以用接口自动化来实现，就是用代码实现

接口测试的重点

1. 检查接口返回的数据是否与预期的结果一致
2. 检查接口的容错性，加入传递的类型错误时是否可以处理
3. 接口测试的边界值
4. 接口的性能
5. 接口的安全性

http状态码

• 1xx：请求正常，但是无响应，只有在实验状态下使用
• 2xx：2开头的表示发送成功
• 3xx：3开头的代表重定向，常见302
• 4xx：400代表客户端发送的语法有错误，401代表访问的页面没有授权，403 无权限访问该网页，404代表没有这个页面
• 5xx：5开头的代表服务器异常，500代表服务器内部异常，502代表服务挂了

cookie 和 session 的区别

1. cookie 数据存放在客户的浏览器上，session 数据放在服务器上
2. cookie 不是很安全，可以使用存放在本地的 cookie 并进行 cookie 欺骗, 考虑安全应当使用 session
3. session 会在一定时间内保存在服务器上，当访问增多，会比较占用服务器资源, 考虑性能，应当使用cookies

产品的业务流程

问你简历上写的某个项目整体的业务流程

比如电商项目中的注册功能，从开始注册到注册成功的整个过程

版本符合上线的标准是什么

1. 验收标准

1. 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求
2. 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
3. 所有测试项没有残余紧急、严重级别错误
4. 需求分析文档、设计文档和编码实现一致
5. 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件安装程序）

2. 缺陷修复率标准

1. 紧急、严重级别错误修复率应达到100%;
2. 普通级别错误修复率应达到95%以上;
3. 优化级别错误修复率应达到60%以上;

注：项目紧急时，普通级别错误修复率达60% 以上；优化级别错误修复率达20% 即可。

3. 服务器运行状态响应指标

1. cpu% 并发期间最大使用率应不超过70-80%，如有集合点并发可允许短暂接近或到达100& 但大部分不应超过95%;
2. memery 测试期间保证内存充足可用内存不少于20%;
3. disk 监控硬盘是否有读写不超过40%;
4. cpu load average 不应超过cpu 核心数*2 或者不超过cpu 核心数。

测试用例评审过程及相关参与人员

1. 评审的过程

A: 准备工作

1. 确定需要评审的原因
2. 确定进行评审的时机
3. 确定参与评审人员
4. 明确评审的内容
5. 确定评审结束标准
6. 提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及参与人员等
7. 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出
8. 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出

B：开始评审

1. 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录
2. 通用邮件与相关人员沟通
3. 通用IM工具直接与相关人员交流
4. 根据评审内容进行评审

2. 评审内容

1. 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2. 优先极安排是否合理。
3. 是否覆盖测试需求上的所有功能点。
4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5. 是否已经删除了冗余的用例。
6. 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8. 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

3. 参与评审人员（这里会分为多个级别进行评审）

1. 部门评审，测试部门全体成员参与的评审。
2. 公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3. 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见

参考资料

mp.weixin.qq.com/s/f2QIh_Ave…