不得不看的经典软件测试面试问题

怼烎@ 2023-03-04 10:27 15阅读 0赞

项目的测试流程

1.  拿到需求文档后，写测试用例
2.  审核测试用例
3.  等待开发包
4.  部署测试环境
5.  冒烟测试（网页架构图）
6.  页面初始化测试（查看数据库中的数据内容和页面展示的内容是否一致，并且是否按照某些顺序排列）

7 .具体执行测试用例（几乎所有的功能测试、流程法、场景法）

1.  发现缺陷就要再填写缺陷表
2.  非功能性测试（sql、js注入、页面效率、绕过js验证直接添加数据到数据库）
3.  书写最终的测试报告

测试用例设计方法

等价类、边界值、正交试验法、状态迁移法、因果图、场景测试法、异常分析法、因果图、错误猜测法、判定

表

测试用例的要素

Id 主题 测试名称 创建日期 设计者 描述 步骤名 步骤描述 预期结果 执行状态

测试的优先级

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

测试报告包含哪些内容

1.写测试背景

2.测试目标

3.测试范围

4.测试环境

5.测试数据

6.测试标准（重点）

7.测试进度

8.测试结果

9.测试结论

有的公司会采用非标准的测试报告

大致会包含 测试所用时间 测试环境 测试人员 测试发现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.  架构不同。

web端是b/s架构的，b/s架构是基于浏览器地址访问的

app端是c/s架构的，c/s架构是要有客户端作为载体的

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

web发版本，开发部署新的代码到对应服务器地址，就可统一实现web端的更新

app发版本，开发需要打包（apk包和ipa包），打包之后需要发布到对应的渠道

1.  兼容性

web，测试不同浏览器的兼容性（ie、chrome、firefox、360、QQ）

app，测试不同的分辨率、屏幕尺寸、手机品牌、系统版本

1.  性能方面

web，测试响应的时间

app，测试响应时间、流量、耗电量、CPU、GPU、memory

1.  安全性

web，sql注入。xss攻击等

app，https加密、签名、加固、密码加密等

6、app测试特点

适配性测试

网络测试

在线升级测试

中断测试

耗电量测试

弱网测试

安装卸载测试

流量测试

app测试的主要内容

1.  功能测试

业务逻辑正确性的测试

1.  兼容性测试

系统版本

分辨率

网络情况

1.  异常测试

热启动

网络切换

电话信息终端恢复

1.  升级、安装、卸载
2.  健壮性测试

手机资源消耗

流量消耗

电量测试

崩溃恢复

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

1.  将问题提交到缺陷管理库里面进行备案。
2.  获取判断的依据和标准

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

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

1.  合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
2.  等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

常用linux命令

1.  ifconfig 查看IP地址
2.  cat 用于显示指定文件的全部内容
3.  more 用分页的形式显示指定文件的内容
4.  mkdir 创建目录
5.  touch 创建新的文件
6.  grep 查找文件里符合条件的字符串
7.  find 查找指定的文件
8.  tail -f 用于自动刷新显示文件后N行数据内容
9.  kill -9 强制结束
10. netstat -anp | grep 端口号 查看端口
11. chmod -R 777 赋予777权限

什么情况下定位不到元素

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、jmeter、soupUI等。

–也可以用 接口自动化来实现，就是用代码实现，框架和UI自动化差不多，发送请求用断言来判断。

接口测试的重点

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

http状态码

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

表没有这个页面，415 格式错误

1.  5xx：5开头的代表服务器异常，500代表服务器内部异常，504代表服务器超时

cookies和session的区别

1.  cookies数据存放在客户的浏览器上，session数据放在服务器上
2.  cookies不是很安全，别人可以分析存放在本地的cookies并进行cookies欺骗考虑到安全应当使用

session

1.  session会在一定时间内保存在服务器上，当访问增多，会比较占用，你服务器的性能考虑到减轻服务器

性能方面，应当使用cookies

常用的adb命令

1.  adb start-server 启动adb服务
2.  adb kill-server 关闭adb服务
3.  adb devices 查看设备号
4.  adb push 电脑 手机
5.  adb pull 手机 电脑
6.  adb logcat | grep 包名（unix）
7.  adb logcat | findstr 包名 （win）
8.  adb shell 进入shell命令行
9.  adb install 安装app到手机上
10. adb uninstall 卸载app到手机上
11. adb logcat > 文件名 输出log到文件
12. adb shell top 测试app的资源消耗命令

产品的业务流程

解析

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

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

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

验收标准

(1) 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。

(2) 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准

(3) 所有测试项没有残余紧急、严重级别错误。

(4) 需求分析文档、设计文档和编码实现一致。

(5) 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件安装程

序。）