（1）问题分析
考官主要想了解你对 Linux 的操作是否熟练，从而判断你 Linux 基础的操作水平是否
过关。
（2）核心问题讲解
切记不要说你会 ls、cd、pwd、exit 等简单的指令，要讲相对常复杂点的
如何查看 CPU 信息？
cat /proc/meminfo
cat/proc/cpuinfo
如何查看一个文件的末尾 50 行？
查看/etc/profile 的前 10 行内容，应该是：
# head -n 10 /etc/profile
查看/etc/profile 的最后 50 行内容，应该是：
# tail -n 50 /etc/profile
如何过滤文件内容中包含”ERROR“的行？
grep "ERROR" file_name
cat file_name | grep "ERROR"
查看某端口号？
netstat -anp | grep port_number
查看某进程号？
ps -ef | grep ps_name
ps -ef | grep ps_number
创建和删除一个多级目录？
mkdir -p ./a/b
rm -rf ./a
在当前用户家目录中查找 haha.txt 文件？
find ~/ -name haha.txt
如何查询出 tomcat 的进程并杀掉这个进程，写出 Linux 命令？
ps -ef | grep tomcat
kill -9 tomcat_port
动态查看日志文件？
tail -f log_file
查看当前机器 listen 的所有端口？
netstat -tlnp
把一个文件夹打包压缩成.tar.gz 的命令，以及解压拆包.tar.gz 的命令？
tar zcvf xxx.tar.gz file tar zxvf xxx.tar.gz
（3）问题扩展
Linux 中如何利用 shell 脚本条件执行命令？
首先建一个 shell 脚本 start.sh
然后把该脚本放在某个目录下，例如本人放在了/export/songhongwei/soft/sh
编辑~/.profile 文件把 sh 目录添加到环境变量即可
在 shell 或 Linux 终端中可以在任何目录下直接访问该命令
（4）结合项目中使用
在有些数据库 RDS 的测试中，有大量的表单需要生成，有数据库动态需要监控，我们
就可以写 shell 自动操作数据库的脚本来实现。
题目标签：Linux 命令
试题编号：MS006696
（1）问题分析
考官主要想看你对 Linux 操作细节的把控
（2）核心问题讲解
1）先切换到：cd usr/local/tomcat5/logs
2）tail -f catalina.out
3）这样运行时就可以实时查看运行日志了
（3）问题扩展
Linux 下查看 tomcat 日志的其他方法：
使用 docker
docker logs -f -t --since="2018-06-20" --tail=10 tomcat8080
--since : 此参数指定了输出日志开始日期，即只输出指定日期之后的日志。
-f : 查看实时日志
-t : 查看日志产生的日期
-tail=10 : 查看最后的 10 条日志。
edu_web_1 : 容器名称
主要弊端是日志非实时。
（4）结合项目中使用
用 tomcat 部署项目
（1）问题分析
考官主要想了解你是否有实际工作经验，对 Linux 的日常使用把控如何
（2）核心问题讲解
测试环境搭建和项目部署，会使用常见的 linux 命令，还经常连接 linux 服务器进行
一些基本操作，也会处理一系异常情况。如下：
kill 终止系统进程
格式：kill [参数] [进程号/pid]
参数：-9 无条件强制终止进程
（3）问题扩展
如何一次终止同一名字的多个进程
ps -aux|grep csh
假设得到：
root 1345 1345 ……… /bin/csh
root 2434 2434 ……… /bin/csh
root 3678 3678 ……… grep csh
2.执行 kill 命令:
kill 1345 2434
而如果我们使用 fuser 命令就可以执行：
fuser -k /bin/csh
（4）结合项目中使用
有些时候进程占用端口，需要杀死进程释放端口，需要用到此命令
知识点标签：数据库
试题编号：
（1）问题分析：
考察的是多表查询,表与表之间的关系, 考察分组,聚合函数
（2）核心答案讲解：
对于员工表(employees)的 部门编号字段(department_id) 与 部门表(departments)
的 主键字段(id) 有关联
1）对员工表和部门表联合查询
select *
from employees, departments
where employees.department_id = departments.id;
2）对查询后的数据,进行按照 部门名称 分组
select departments.name
from employees, departments
where employees.department_id = departments.id
group by departments.name;
3）再去求出每个部门的平均薪资
select departments.name, avg(employees.salary)
from employees, departments
where employees.department_id = departments.id
group by departments.name;
使用内连接的方式查询每个部门的平均薪资:
select departments.name, avg(employees.salary)
from employees
inner join departments
on employees.department_id = departments.id
group by departments.name;
（3）问题扩展：
（4）结合项目中使用：
知识点标签：mysql 基础
试题编号：
（1）问题分析：
1）考试面试者是否掌握了 sql 语句的建表语法
2）考试面试者是否掌握了 sql 语句建表的常见错误
3）考试面试者是否掌握了 mysql 中建表时常用数据类型
4）考试面试者是否掌握了主键设置
（2）核心答案讲解：
1）建表语法
create table 表名(
字段名 类型 约束,
字段名 类型 约束
)
2）建表 5 个常见错误
A）标点符号必须是英文状态下的
B）靠近最后一个括号的语句不能加标点符号
C）不能创建和现有表同名的表
D）类型在约束前面
E）不相关的语句一定要注释掉
3）mysql 中常用数据类型和约束
* 整数 int （没有负数就是无符号）
* 小数 decimal(5,2)
* 字符串 varchar(10)
* 日期时间 datetime
4）建表语句中主键的设置
id int unsigned primary key auto_increment
5）答案
create table stu_info(
no int unsigned primary key auto_increment,
name varchar(10),
age int unsigned,
score decimal(4,1),
grade int unsigned
)
（3）问题扩展：
（4）结合项目中使用：
知识点标签：mysql 基础
试题编号：
（1）问题分析：
1）考察你对取值命令limit的应用
2）考察你对order by命令的使用
3）考察你对 SQL 语句中的命令顺序的掌握程度
（2）核心答案讲解：
1）limit`命令的应用
limit 用法 1:限定查询记录（从第一条到指定的数量）
select * from 表名 limit 5
limit 用法 2: 获取指定区间的数据（从第一条到指定的数量）
select * from 表名 limit 0,5
2） order by命令的使用
select * from 表名 order by 列 1 asc|desc,列 2 asc|desc,..
-- asc 从小到大排列，即升序（升序是默认的，也就意味着可写可不写）
-- desc 从大到小排序，即降序
3）SQL 语句中的命令顺序
select *
from 表名
where 条件 1
group by 依据列
having 条件 2
order by 依据列
limit 0,1
4）答案：
select * from students order by score desc limit 5
（3）问题扩展：
（4）结合项目中使用：
知识点标签：mysql 基础
（1）问题分析：
1）考察面试者是否掌握了 sql 语句两表连接查询方法
2）考察面试者是否掌握了范围查询使用方法
3）考察面试者是否掌握了求统计数据的聚合函数的使用方法
（2）核心答案讲解：
1）两表连接查询方法
解题思路:
select * from
将题目中的所求字段所在的表做为数据源(放在 from 后面的表，就叫数据源）
找两表中意义相同的字段，进行相等，进行连接
如果有条件，将过滤条件放在 where 后面
将题目的所求字段放在 select 后面，替换*
2） 范围查询使用方法
范围查询
in 表示在一个非连续的范围内（使用频率非常高）
between ... and ...表示在一个连续的范围内 意味着只能接连接类型字段 注意点:小值
放在前面,大值放在后面
3）聚合函数的使用方法
A）常见聚合函数有哪些?
求个数：count(*)
求总和：sum
求最大值：max
求最小值：min
求平均值：avg
B）聚合函数如何使用?
所有的聚合方式使用都是 函数名(字段) 对这一个字段进行聚合
4）答案：
select sum(l_days) from e_info as e inner join leave_info as l on e.e_id=l.e_id
where l_date between "2019-10-1" and "2019-10-31"
（3）问题扩展：
（4）结合项目中使用：
知识点标签：mysql 基础
（1）问题分析：
1）考试你在之前工作中是否会数据库的条件查询操作
2）考试你是否能熟练掌握了 SQL 条件查询语句解题思路
（2）核心答案讲解：
1）在纸上画出该表的形状，就是一个非常简单的三个字段的表
2）关注查询成绩小于 60 分的所有学生名单
A）只显示成绩小于 60 分的学生名单，这是条件查询
B）使用条件查询三步法就能轻松做出题目
3）答案
select name from students where score <60
（3）问题扩展：
（4）结合项目中使用：
题目标签：**数据库**
（1）问题分析
面试官想考查你对数据库的基本操作的熟练度，看你是否真的有工作经验
（2）核心问题讲解
1）增：
insert into (列名，列名，列名，...) values(值，值，值，....)
insert into 表名 values(值，值，值，值，....)
2）删：
delete from 表名——删除全部数据
delete from 表名 where 条件——这里的条件是跟 select 的条件是一样的。
3）改：
update 表名 set 列名=值,列名=值..... where 条件
4）查：
简单查询
select * from 表名
select 列名，列名，...from 表名——投影
等值与不等值查询
select * from 表名 where 列名=值——等值查询
不等值查询
select * from 表名 where 列名 <> 值
select * from 表名 where 列名 > 值 >=
select * from 表名 where 列名 < 值 <=
多条件查询 逻辑与（and），逻辑或（or）
select * from 表名 where 条件 1 and 条件 2 ...
select * from 表名 where 条件 1 or 条件 2 ...
如果在 where 筛选条件中，既出现 and 又出现 or，则先运算 and。除非使用小括号
改变优先级。
范围查询
select * from Car where Price >=30 and Price<=50
select * from Car where Price between 30 and 50
select * from Car where Oil=7.4 or Oil=8.5 or Oil=9.4
select * from Car where Oil in(7.4,8.5,9.4)
模糊查询，一般不用=，而是用 like
%：任意多个任意字符
_：一个任意字符
select * from Car where Name like '宝马%'
宝马%：以宝马开头的
%宝马：以宝马结尾的
%宝马%：只要含有宝马这两个字就可以。
__宝马%：代表第三个字符以宝马开头的。
去重：
select distinct 列名 from car ——如果列中有重复值，则只查 1 个出来。
知识点标签：测试理论
（1）问题分析：
在软件开发过程中，缺陷拥有自身的生命周期。缺陷在走完其生命周期最终会关
闭。。缺陷在其生命周期中会处于许多不同的状态。
（2）核心答案讲解：
缺陷各个不同的状态如下：
1）缺陷的状态
A）new:“新建状态”。
测试人员新建缺陷，称之为“new”状态。
B）open: 意为“打开状态”。
开发人员接收到缺陷后确认该缺陷，并且会打开，称之为“open”状态。
C）fixed:意为“修复状态”。
开发人员打开缺陷后进行修复的状态称之为“fixed”状态。
D）closed:意为“关闭状态”。
测试人员发现该缺陷已被开发人员修改，并且修改正确，会关闭该缺陷，称之为
"closed"。
E）rejected：意为“拒绝状态”。
开发人员接收到测试人员新建的 bug 后,不认同该 bug,可以拒绝修改，称之为
“rejected”
F）postpone:意为“拖延状态”。
开发人员接收到测试人员的 bug 后，如遇到临时有事的情况，可以延后修复，称
之为“postpone”
2）简单的软件缺陷生命周期：
A）发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员;
B）打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证;
C）修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。
但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的
各种情况都 还是非常多的。
3）复杂的软件缺陷生命周期：
A）新建一个软件缺陷，这个软件缺陷是(open)状态，进行 bug 审查，不是代
码问题，就是设计需要修改;
B）新建一个软件缺陷，这个软件缺陷是(open)状态，进行 bug 审查，以后修
改的，就可以延期;
C）新建一个软件缺陷，这个软件缺陷是(open)状态，进行 bug 审查，实际没
有这个 bug， 可以将其关闭;
D）新建一个软件缺陷，这个软件缺陷是(open)状态，看是否清楚可重现，如果
不能重现， 就是缺少信息，需要返回到(open)状态;如果能够重现，就进行修正，修
正后关闭，进行回归测试。
（3）问题扩展：
缺陷在其生命周期中会处于许多不同的状态
new 新建状态 --> open 打开状态 ---> fixed 状态--->closed 状态
（4）结合项目中使用：
知识点标签：测试网页
（1）问题分析：
熟练掌握手工测试的测试方法
（2）核心答案讲解：
1）功能测试 Function test
A）输入正确的用户名和密码,点击登录按钮,验证是否能够正确的登录
B）输入错误的用户名和密码,验证登录会失败,并且提示相关的错误的的信息
C）登录成功,是否能够跳转到正确的页面
D）输入的用户名和密码要符合 需求说明书里面的长度
E）登录失败后,是否能记录密码的功能
F）输入用户名和密码如果前后有空格,如果处理的
G）密码是否为以 星号显示
2）界面测试 UI Test
A）布局是否合理 2 个输入框和按钮是否对齐
B）两个输入框和按钮是否符合 长度,和高度的要求
C）图片,颜色,字体,超链接 是否能够正确的显示
3）性能测试 Performance Test
A）打开登录页面的 需要几秒
B）输入正确的用户名和密码,跳转成功到新的页面,不能超过 5 秒
C）能够支持多少个用户同时登录
4）安全性测试 Security Test
A）登录成功后生成的 cookie,是否是 httponly (是否容易被脚本盗取)
B）登录的密码是否通过加密的方式,发送给 web 服务器
C）用户名和密码的验证,应该使用服务器端验证,不能单单用客户端的 javascript 验证
D）用户名和密码输入框,应该屏蔽 sql 注入攻击
E）错误的登录次数的限制(防止暴力破解)
5）可用性测试 Usability Test
A）是否可以全用键盘操作,是否有快捷键
B）输入用户名和密码 ,按回车,是否可以登录
6）兼容性测试 Compatibility Test
A）主流的浏览器下是否能够正确的显示已有的功能 Ie6,7,8,9,Firefox,chrome safari
等
B）在不同的平台下是否能够正常的工作,window mac linux
C）不同的分辨率
（3）问题扩展：
（4）结合项目中使用：
知识点标签：测试上传
（1）问题分析：
是否熟悉手工测试各种测试方法
（2）核心答案讲解：
1）功能测试
A）选中符合要求的文件，上传 上传成功
B）上传成功的文件名称显示 显示正常（根据需求)
C）上传成功的文件 ，是否能够下载
D）删除上传成功文件，可以删除
E）替换上传成功文件，可以替换
F）上传文件是否支持中文名称，根据需求而定
G）文件路径是否可以手动输入，根据需求而定
H）手动输入正确的文件路径，上传 上传成功
I）手动输入错误的文件路径，上传，提示不能上传
2）文件大小测试：
A）符合格式，总大小等于限制的大小的文件，上传成功
B）符合格式，总大小稍大于限制大小的文件，在上传初提示附件过大
C）小于 0 KB 的 txt 文档，不能上传
3）文件名称测试 ：
A）文件名称过长，Win 2000 标准：255 个字符(指在英文的符号下) 如果在中文
不超过 127 个汉字，提示过长
B）文件名称达到最大长度（中文，英文或混在一起）上传后名称显示，页面排版显
示是否正常
C）文件名包含特殊字符，根据需求而定
D）文件名全都是中文，根据需求而定
E）文件名全都是英文，根据需求而定
F）文件名为中，英文，混合，根据需求而定
4） 文件格式测试
A）上传正确格式，上传成功
B）上传不允许的格式，提示不能上传
C）上传 rar ,zip 等打包文件（多文件压缩）根据需求而定
5）安全性测试：
A）上传文件木马文件，提示不能上传
B）上传可执行文件(exe 文件) 根据需求而定
C）上传时候服务器空间已满，有提示
6）性能测试：
A）上传时候网速很慢 （限速）当超过一定时间 提示
B）上传过程断网，有提示上传是否成功
C）上传过程服务器停止工作，有提示上传是否成功
D）上传过程服务器的资源利用率 在正常范围
7）界面测试
A）页面美观性，易用性（键盘和鼠标的操作，tab 跳转的顺序是否正确)
B）按钮上文字是否正确 正确
C）正确/错误的提示文字是否正确 正确
D）说明性文字是否正确 正确
8）其他测试
A）有多个上传框时，上传相同的名称的文件，根据需求而定
B）上传一个正在打开的文件 是否可以上传
C）文件路径是手动输入的是否现在长度， 限制一定长度
（3）问题扩展：
（4）结合项目中使用：
知识点标签：测试报告
（1）问题分析：
面试官 22 主要是为了考察候选者对缺陷报告文档的理解和掌握程度。
（2）核心答案讲解：
1）缺陷报告：是一份用来记录测试执行过程中所发现的缺陷 BUG 的文档；
2）缺陷报告的组成：
A）ID 编号
B）标题
C）模块
D）严重程度
E）优先级
F）复现步骤
G）实际结果
H）预期结果
I）缺陷类型
J）缺陷状态
（3）问题扩展：
缺陷是用来记录并跟踪管理缺陷的一个文档；
缺陷跟踪管理——工具（JIRA，禅道等）
（4）结合项目中使用：
知识点标签：测试用例
（1）问题分析：
面试官主要是为了考察候选者对测试用例设计方法以及测试设计依据的理解和掌
握程度。
（2）核心答案讲解：
等价类：具有典型的输入，有效等价类与无效等价类，将测试从穷举测试中解放；
边界值：>,<,>=,<=等，根据统计数据表明，程序往往容易在边界上出现错误；
判定表：存在对个输入条件或多个输出结果，条件如条件之间存在组合关系，条件与输出之
间存在依赖或制约关系。
因果图：用图形的方式表示条件与条件，以及条件与结果之间的依赖于制约。
场景法（流程图）：针对用户的真实使用场景进行测试。
正交法：使用最小的测试用例集获得最大的测试覆盖率。
错误推测法：借助于经验，经验可以来自于产品使用经验或者同类型产品的测试经验。
状态迁移图：状态变化
测试设计的依据主要有：需求文档、原型、UI 设计图、概要设计文档、详细设计文档、数据
库表设计文档、接口设计文档等
（3）问题扩展：
软件测试按照测试阶段分：单元测试、集成测试、系统测试、验收测试
单元测试：等价类、边界值、判定表、因果图、正交法、错误推测法；
集成测试、系统测试、验收测试：场景法（流程图）、状态迁移图、错误推测法。
（4）结合项目中使用：
知识点标签：测试流程
（1）问题分析：
面试官主要是为了考察候选者对软件测试流程的理解和掌握程度。
（2）核心答案讲解：
1）需求分析与评审
2）编写测试计划与测试方案
A）测试计划
范围与目标
角色与职责
资源与进度
风险与应对
输入输出标准
B）测试方案
工具
环境
方法或策略
3）设计测试用例与评审
等价类
边界值
判定表
因果图
正交法
流程图（场景法）
错误推测法
状态迁移图
4）执行用例与缺陷跟踪
5）编写测试报告
测试概要
缺陷统计分析
测试结论
（3）问题扩展：
同行评审
项目评审
（4）结合项目中使用：
题目标签：**测试用例设计**
（1）问题分析：
考官主要考察你测试理论掌握情况，尽可能多说你知道的测试用例编写方法。
（2）核心答案讲解：
等价类划分、边界值分析方法、因果图方法、正交实验设计方法、功能图分析方法、
错误推测法、需求文档转化法、随机测试、对象属性分析法。
（3）问题扩展：
针对常见的等价类、边界值、因果法等方法举例子。
（4）结合项目中使用：
待定-自由发挥
题目标签：白盒测试方法
（1）问题分析
主要考验对白盒测试理论的了解程度，同时也侧面了解你对编程语言的了解
（2）核心问题讲解
白盒测试定义：把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻
辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通俗的讲：就
是看着开发编写的代码进行测试，找出代码中的错误。根据开发的代码逻辑与条件等来编
写测试用例，让每行代码都得到有效的执行，以此来看代码对功能完整性的支持。
（3）问题扩展
对常见的 Java、PHP、Python 等常见后台语言的了解
（4）结合项目中使用
待定-自由发挥
题目标签：测试概念及模型
（1）问题分析
考察你对项目结构，和网络硬件结构的了解
（2）核心问题讲解
C/S（Client/Server）:客户端/服务端，C/S 架构是一种典型的两层架构，其客户端
包含一个或多个在用户的电脑上运行的程序，而服务器端有两种，一种是数据库服务器
端，客户端通过数据库连接访问服务器端的数据；另一种是 Socket 服务器端，服务器端
的程序通过 Socket 与客户端的程序通信。客户端需要实现绝大多数的业务逻辑和界面展
示。这种架构中，作为客户端的部分需要承受很大的压力，因为显示逻辑和事务处理都包
含在其中，通过与数据库的交互（通常是 SQL 或存储过程的实现）来达到持久化数据，以
此满足实际项目的需要。
B/S（Browser/Server）:浏览器/服务器，浏览器也就是指的是 web 浏览器如微软的
Internet Explorer、Mozilla 的 Firefox、Opera 和 Safari 等，随着 Internet 技术的兴
起，对 C/S 架构的改进，为了区别于传统的 C/S 模式，特意称为 B/S 模式。在这种模式
下，极少的逻辑是在前端（Browser）实现，主要事务逻辑在服务器端（Server）实现，
和 DB 端构形成三层结构。这样就极大程度上减轻了客户端。
简单来说就是 B/S 只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维
护，但是个性化能力低，响应速度较慢， C/S 响应速度快，安全性强，一般应用于局域网
中，因为要针对不同的操作系统，需要针对性的开发，并且维护成本高。
（3）问题扩展
B/S 的优点：
分布性强，客户端零维护。只要有网络、浏览器，可以随时随地进行查询、浏览等业
务处理。
业务扩展简单方便，通过增加网页即可增加服务器功能。
维护简单方便，只需要改变网页，即可实现所有用户的同步更新。
开发简单，共享性强。
B/S 的缺点：
个性化特点明显降低，无法实现具有个性化的功能要求。不过随着 html5 的普及，这
个缺点越来越弱化了。
客户端服务器端的交互是请求-响应模式，通常动态刷新页面，响应速度明显降低
（Ajax 可以一定程度上解决这个问题）。无法实现分页显示，给数据库访问造成较大的压
力。
C/S 的优点：
能充分发挥客户端 PC 的处理能力，很多工作可以在客户端处理后再提交给服务器，
所以 CS 客户端响应速度快。
操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。
安全性能可以很容易保证，C/S 一般面向相对固定的用户群，程序更加注重流程，它
可以对权限进行多层次校验，提供了更安全的存取模式，对信息安全的控制能力很强。一
般高度机密的信息系统采用 C/S 结构适宜。
C/S 的缺点：
需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群
体，不能够实现快速部署安装和配置。
兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改
写程序。
开发、维护成本较高，需要具有一定专业水准的技术人员才能完成，发生一次升级，
则所有客户端的程序都需要改变。
用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户，所以
适用面窄，通常用于局域网中。
（4）结合项目中使用
待定---自由发挥
题目标签：兼容性测试
（1）问题分析
考察对兼容性测试的了解和在工作中的应用。
（2）核心问题讲解
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是
通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式
的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情
况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会
在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
（3）问题扩展
APP 兼容性测试
（4）结合项目中使用
一个 Web 系统是否成熟够强大，功能的兼容性的强弱是不容小觑的；我们的 Web 项
目面向的都是大众用户群体，而用户所使用的浏览器都是五花八门，某个功能在 A 浏览器
上显示正常操作 Ok，但是在 B 浏览器上显示就乱糟糟的，严重的可能导致功能都异常，
这样一来用户群体对项目系统的好感就大大的打了折扣，所以浏览器的兼容性测试我们得
加大关注力度。
兼容性测试从哪些方面入手？
1）了解当前哪些浏览器是主流，挑选前面 3-5 个左右的浏览器进行兼容性测试（一
般选 3 个左右就差不多了，项目时间允许的话可以做得更多）
2）同浏览器的不同版本也要进行兼容性测试（一般测试最新版本）
3）界面上元素功能是否正常、排版布局是否合理美观，这是兼容性最最最重要的测
试范围
那么在不同浏览器中或者是同一浏览器不同版本里需要对那些界面功能进行兼容性测
试？
一眼可见的是网页元素位置是否混乱与错位业务与功能结合的异步交互
功能按钮（增删改查、导入导出、超链接、清空）等等
各种控件的检查：日期和时间控件、搜索控件
有些特殊的图标功能比如：盘古系统上的画图功能是否正常（不覆盖区域图标、覆盖
区域绘图、站点位置迁移图标、挪动地图坐标等等
兼容工具：test 云测平台、三方付费工具
题目标签：测试概念及模型
（1）问题分析
对测试对象不同阶段的认知及不同阶段的测试重点。
（2）核心问题讲解
单元测试：是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，
软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模
块，包括子程序的正确性验证等。
集成测试：也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要
求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，
但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很
可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
系统测试：是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确
实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他
软件的兼容性。
（3）问题扩展
软件测试一般分为 4 个阶段：单元测试、集成测试、系统测试、验收测试。
验收测试：也称交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系
统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。
验收测试包括 alpha 测试和 beta 测试，alpha 测试是由开发者进行的软件测试，
beta 测试是由用户在脱离开发环境下进行的软件测试。
（4）结合项目中使用
待定---自由发挥
题目标签：测试概念及模型
（1）问题分析
考察对软件测试理论熟悉程度。
（2）核心问题讲解
一套完整的测试应该由五个阶段组成：
1）测试计划
首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试
需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进
行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试
内容，合理安排测试人员、测试时间及测试资源等。
2）测试设计
将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测
试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。
3）测试开发
建立可重复使用的自动测试过程。
4）测试执行
执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行
一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本
着科学负责的态度，一步一个脚印地进行测试。
5）测试评估
结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度
及工作效率进行综合评价。
（3）问题扩展
无
（4）结合项目中使用
无
题目标签：灰度测试
（1）问题分析
对拓展知识技术的了解。
（2）核心问题讲解
灰度发布定义：
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test 就是一种灰度
发布方式，让一部分用户继续用 A，一部分用户开始用 B，如果用户对 B 没有什么反对意
见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳
定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
（3）问题扩展
灰度发布作用
1）及早获得用户的意见反馈，完善产品功能，提升产品质量
2）让用户参与产品测试，加强与用户互动
3）降低产品升级所影响的用户范围
4）规避一定的发布风险
5）避免停服发布给用户带来不便
6）具有容灾能力
（4）结合项目中使用
以 TPShop 商城上线为例
产品需求收集和确定 –> 技术方案出具和分工协调 –> 开发编码 –> 内部服务器环
境的测试 –> 联调（又名预发环境） –> TPShop 内部环境发布，内部员工喷喷喷 –>
小流量（具体有多少取决于业务影响面）公网测试 –> 收集数据写反馈 –> 全量上线。
题目标签：测试概念及模型
问题分析
对测试理论的了解和实际项目中的实际情况。
核心问题讲解
1）基于“测试阶段”的原则：
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以
分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标
准后，再进行后面一个阶段的测试。
2）基于“测试用例”的原则：
测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后
面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用
例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达
到 100%，非功能性测试用例达到 95%以上，允许正常结束测试。但是使用该原则作为测
试结束点时，把握好测试用例的质量，非常关键。
3）基于“缺陷收敛趋势”的原则：
软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升
趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现
缺陷为止。
4）基于“缺陷修复率”的原则：
软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错
误、次要错误、一般错误、较小错误和测试建议 6 种。那我们在确定测试结束点时，严重
错误和主要错误的缺陷修复率必须达到 100%，不允许存在功能性的错误；次要错误和一
般错误的缺陷修复率必须达到 85%以上，允许存在少量功能缺陷，后面版本解决；对于较
小错误的缺陷修复率最好达到 60%~70%以上。对于测试建议的问题，可以暂时不用修
改。
5）基于“验收测试”的原则：
很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到
或接近测试部门指定的标准后，就递交用户做验收测试。
6）基于“覆盖率”的原则：
对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全
部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖
率达到 100%，基本上测试就可以结束。
7）基于“项目计划”的原则：
大多数情况下，每个项目从开始就要编写开发和测试的 Schedule，相应的在测试计
划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组
成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结
束点。如果项目的某个环节延迟了，测试时间就相应缩短。
8）基于“缺陷度量”的原则：
这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常
用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度
量。
9）基于“质量成本”的原则：
一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一
项占主要地位，就要看是什么软件了。比如说是：人命关天的航天航空软件，那还是质量
重要些，就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发
布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有 bug，也必须得先推出
产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷
可能导致的损失做一个均衡”。
10）基于“测试行业经验”的原则：
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员
对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试
计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的
项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的
经验，对确认测试执行和结束点也会起到关键性的作用。
问题扩展
第一类标准：测试超过了预定时间，则停止测试。
第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。
第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础。
第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某 一
预订 数目的故障。
第五类标准：根据单位时间内查出故障的数量决定是否停止测试。
结合项目中使用
无
题目标签：提交缺陷
(1）问题分析
考察面试人员沟通
（2）核心问题讲解
1）首先，将问题提交到缺陷管理库里面进行备案。
2）然后，要获取判断的依据和标准：
A）根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一
致的地方，提供缺陷是否确认的直接依据；
B）如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的
地方，来确认是否是缺陷；
C）根据用户的一般使用习惯，来确认是否是缺陷；
D）与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
3）合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人
情绪。
4）等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠
道，向上级反映，并有上级做出决定。
（3）问题扩展
无
（4）结合项目中使用
无
16、在没有产品说明书和需求文档的情况下能够进行黑盒测试的设计吗？
题目标签：无任何文档测试
（1）问题分析
无
（2）核心问题讲解
能，可以通过其他工作内容去替代产品说明书和需求文档
根据客户的功能点整理测试需求追溯表
根据开发人员的 Software Specification List 整理功能测试点
开展项目跨部门讨论会，主要整理对功能点的理解和认识
测试人员整理用例需求疑问提交项目组或者产品
项目内部的用例品胜
邮件客户代表确认部分争议问题
项目的 Demo 和部分已经开发的系统
参考同行业和竞争对手的类似产品
交叉模块之间的测试
咨询客户或相关者
（3）问题扩展
无
（4）结合项目中使用
无
题目标签：缺陷归属
（1）问题分析
（2）核心问题讲解
前端是用户看得见摸得着的东西，主要体现在页面的视觉效果以及交互设计上。比如
说一个网站的页面风格、页面跳转等，最简单的例子就是一个注册界面：前端设计界面风
格，约束输入的字符类型、长度以及合法性校验等，不涉及到与数据库之间的信息交流。
后台，则侧重于更深层面的东西，关于逻辑，关于数据，关于平台的稳定性与性能。
后台主要负责实现具体的功能，举个例子，还是那个注册界面，前端写好了界面，规定了
你能输入哪些数据，不能输入哪些数据，而后台则会把你输入的信息与数据库进行比对，
如果是新用户，则顺势在数据库中插入一条信息。
当然，关于数据的校验，不同项目情况不同，有些是由前端进行校验，有些是后台，
有些是前后台都需要校验。
知道了前后台的区别，就大致能够进行 bug 的判断了。
case1：文本框输入不合法的内容，点击提交按钮，如果不合法的内容提交成功， 那
应该是前后台没有做校验， 前后台都有这个 bug
case2：文本框输入合法的内容，点击提交按钮，查看数据库中的数据和输入的内容
不一致， 这个时候需要看前台传的数据是否正确，使用 fiddler 抓包，查看请求头里面的
数据是否和输入一致，如果一致就是后台的问题，如果不一致，就是前台的 bug
case3：界面展示不友好，重复提交这些都是前台的 bug
（3）问题扩展
无
(4）结合项目中使用
无
设置过程?
题目标签：抓包工具
（1）问题分析
考察对 Fiddler 的了解及抓包过程
（2）核心问题讲解
Fiddler 是一个 http 协议调试代理工具
打开 Fiddler，进入 Tools-Options-HTTPS，配置允许抓取 HTTPS 连接和解析
HTTPS 流量然后选择要解释的来源，设置是否忽略服务证书错误（这些操作做完之后，在
浏览器方位 IP:8888，安装证书就可以在浏览器抓取 HTTPS 协议了）
进入 Tools-Options-Connections，保证打开启抓取 HTTPS 连接，然后默认端口按
需求是或否需要修改，然后点选允许远程计算机连接选项
（3）问题扩展
Fiddler 的手机抓包过程
1）启动 Fiddler，打开菜单栏中的 Tools > Fiddler Options，打开“Fiddler
Options”对话框：
2）在 Fiddler Options”对话框切换到“Connections”选项卡，然后勾选“Allow
romote computers to connect”后面的复选框，然后点击“OK”按钮
3）在本机命令行输入：ipconfig，找到本机的 ip 地址。
4）打开 android 设备的“设置”->“WLAN”，找到你要连接的网络，在上面长
按，然后选择“修改网络”，弹出网络设置对话框，然后勾选“显示高级选项”
5）在“代理”后面的输入框选择“手动”，在“代理服务器主机名”后面的输入框
输入电脑的 ip 地址，在“代理服务器端口”后面的输入框输入 8888，然后点击“保存”
按钮。
6）然后启动 android 设备中的浏览器，访问百度的首页，在 fiddler 中可以看到完成
的请求和响应数据。
（4）结合项目中使用
无
题目标签： 缺陷产生分析
（1）问题分析
无
（2）核心问题讲解
网络设置的问题。
DNS 服务器的问题 。
IE 浏览器本身的问题。
网络防火墙的问题。
网络协议和网卡驱动的问题。
HOSTS 文件的问题。
系统文件的问题。
杀毒软件的实时监控问题。
感染了病毒所致 。
题目标签：APP 测试点
试题编号：MS006694
（1）问题分析
无
（2）核心问题讲解
功能测试：
1）业务逻辑正确性测试：依据：产品文档->测试用例编写
兼容性测试：
2）系统版本：Android:官方版本，定制版本;IOS：官方提供版本
3）分辨率：720 * 1280 1080* 1920
4）网络情况:2g 3g 4g 5g Wi-Fi
异常测试：
1）热启动应用:应用在后台长时间待机;应用在后台待机过程中，手机重启
2）网络切换和中断恢复:网络切换;中断恢复：
3）电话信息中断恢复
升级，安装，卸载测试：
1）升级测试：临近版本升级(1.0->1.1);跨版本(1.0->....->2.2)
2）安装测试：首次安装;覆盖安装(同版本，不同版本覆盖);卸载后安装
3）卸载测试：首次卸载;卸载安装后在卸载
健壮性测试：
1）手机资源消耗：cpu，内存
2）流量消耗：图片，数据，视频
3）电量测试
4）崩溃恢复
题目标签：测试概念及模型
（1）问题分析
考官考察项目中进行测试的好处
（2）核心问题讲解
软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望做的
事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事情（Do it
right）。第二是提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准
备的信息。第三软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程。
如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷
的。因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。
（3）问题扩展
软件测试的分类及测试用例的编写
（4）结合项目中使用
项目中要进行测试目的
题目标签：测试概念及模型
（1）问题分析
考官主要想考察下你对于软件测试分类的了解，及是否有真正参与过项目测试
（2）核心问题讲解
黑盒测试：又称数据驱动测试，把测试对象当成一个黑盒子，测试人员完全不考虑程
序内部结构和内部特征，注重于测试软件的功能需求，只关心软件的输入数据和输出数
据。
白盒测试：把测试对象当成一个透明盒子，测试人员去研究里面的源代码和程序结
构。
回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或者导致
其他代码产生错误。
（3）问题扩展
黑盒、白盒测试的测试方法、分类及其优缺点，给你一个具体需求你怎么去测试，说
出测试要点；
（4）结合项目中使用
简历项目的模块功能测试要点
题目标签：测试概念及模型
（1）问题分析
考官主要想要考察你在工作中用的哪种测试模块及测试在什么时候开介入项目
（2）核心问题讲解
软件测试主要内容是对软件正确性、完整性、安全性和质量确认及验证。为了验证这
些，软件测试与开发同步进行的，他们之间的关系同步进行一一对应，当开发进行需求分
析、概要设计、详细设计、编码实现、模块集成、系统构建与实施、交付运行时，测试人
员对应工作是需求测试、概要设计测试、详细设计测试、单元测试、集成测试、系统测
试、验收测试。
测试的活动与软件开发整体同步进行，测试对象不仅仅是程序，还包括需求和设计，
有利于尽早地全面的发现问题可降低开发和成本
（3）问题扩展
公司的测试流程
（4）结合项目中使用
简历项目的测试过程
题目标签：缺陷管理
（1）问题分析
考官主要对项目中使用 bug 工具及 bug 的跟踪
（2）核心问题讲解
bug 管理工具是为了更好的管理 BUG，流程化，方便开发以及测试人员处理这些
BUG，以及整个 BUG 的流程。常用的 BUG 管理工具，如：禅道、AML、BugZilla 等。
测试人员提交新的 Bug 入库，错误状态为 New。高级测试人员验证错误，如果确认
是错误，分配给相应的开发人员，设置状态为 Open。如果不是错误，则拒绝，设置为
Declined(拒绝)状态。开发人员查询状态为 Open 的 Bug，如果不是错误，则置状态为
Declined；如果是 Bug 则修复并置状态为 Fixed。不能解决的 Bug，要留下文字说明及
保持 Bug 为 Open 状态。对于不能解决和延期解决的 Bug，不能由开发人员自己决定，
一般要通过某种会议（评审会）通过才能认可。测试人员查询状态为 Fixed 的 Bug，然后
验证 Bug 是否已解决，如解决置 Bug 的状态为 Closed，如没有解决置状态为 Reopen
（3）问题扩展
缺陷描述或者测试报告应该包括哪些内容等
（4）结合项目中使用
项目中 BUG 的跟踪
题目标签：Android 与 IOS 区别
（1）问题分析
考察 APP 测试
（2）核心问题讲解
1、两者运行机制不同：IOS 采用的是沙盒运行机制，安卓采用的是虚拟机运行机制。
2、两者后台制度不同：IOS 中任何第三方程序都不能在后台运行；安卓中任何程序都
能在后台运行，直到没有内存才会关闭。
3、IOS 中用于 UI 指令权限最高，安卓中数据处理指令权限最高。
（3）问题扩展
Android 是一种基于 Linux 的自由及开放源代码的操作系统，主要使用于移动设备，
如智能手机和平板电脑，由 Google 公司和开放手机联盟领导及开发。尚未有统一中文名
称，中国大陆地区较多人使用“安卓”或“安致”，因为代码开源所以安卓的碎片化严
重。
IOS 是一个有苹果公司开发的一个封闭的移动端系统，不对外开放系统代码，所以
IOS 的生态圈相对更安全。
（4）结合项目中使用
项目中 APP 使用安卓跟苹果机测试
题目标签：测试计划
（1）问题分析
考察在公司中是否写过测试计划及测试是策略，从而看出是否有真实工作项目经验
（2）核心问题讲解
测试计划：描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信
息系统应用软件组装测试和确认测试。
测试计划内容：
（1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的
对象、范围、方法、进度和预期结果。
（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内
容。
（3）开发有效的测试模型，能正确地验证正在开发的软件系统。
（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。
（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。
（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风
险所带来的损失。
（3）问题扩展
了解测试策略及书写测试报告
（4）结合项目中使用
各项目中测试计划的书写
题目标签：测试用例设计
（1）问题分析
考官考察是否有真实工作经验，对项目的熟练度，从而判断工作经验
（2）核心问题讲解
具体写了哪些测试用例得根据自己项目负责的的模块去写测试用例，从显性需求、覆
盖需求、隐性需求、相关业务等其他角度补充完善根据经验等方面去写测试用例，如购物
车测试用例要点编写：
1）显性需求
购物车
2）隐性需求
1 购物车无商品时显示马上去购物
2 点击去结算跳转至支付界面
3 加入购物车后在购物车列表中增加一条商品
4 点击删除商品时购物车列表减少一条商品
5 购物车可以进行编辑商品数量
6 数量限制(考虑库存)
7 购物车合计功能
合计=单价*数量
8 添加相同商品时，数量+1
9 添加相同商品但是不同型号 商品分开展示
10 购物车有商品时显示商品详细信息
11 点击去结算后取消 应该跳转至购物车页
12 登录状态下点击去结算，跳转至结算页
13 游客状态下点击去结算，提示登录
14 游客状态下添加购物车，登录后购物车商品是否还存在
15 从外界点击[加入购物车]可以添加到购物车
16 点击购物车商品图片跳转至该商品的详情页
17 点击去结算时断网情况下提示网络异常
18 点击去结算时在弱网情况下结算成功
（3）问题扩展
对于项目的其他模块测试用例的测试要点分析及编写测试用例
（4）结合项目中使用
项目的其他模块测试用例编写，如会员列表模块、订单、支付等模块