在校时成绩是敲门砖，工作后简历和面试变成了敲门砖，简历筛选后就是面试，面试有多重要，不用我说大家都明白。由于中途换过一家公司，想找个好点的公司，面试经历比较曲折，所以有些面试经历经历写下来博大家一笑。

之前看过我文章的都知道我是从实习生做起，那年参加过绿盟科技的实习生考试被刷下来，然后我发邮件过去说我免费给您干活吧，人家愣是没理我。

之后就去了某做银行系统的公司，大概那年太缺人手了，笔试貌似答得不好，但是居然通过了。以下就是我的一些面试经历，有的伤心、有的哭笑不得、有的回味无穷。

实习生面试

面：笑眯眯的走过来，温柔的说，简单做个自我介绍；

我：我毕业于某大学，就读计算机科学与技术专业，在校期间学习了c语言、操作系统、数据库、数据结构、linux等，在校一直荣获三好学生奖，喜欢读书，最近了解到贵公司招聘软件测试实习生就来了。

面：你怎么看待出差？

我：很乐意啊！

那时候谁知道出差是啥意思，脑补应该是去不同地方工作，交通全额报销，出差有补贴，公司给租房子，周末吃喝玩乐，这相当于免费旅游啊。

面试官微笑的看着我说：“你的情况我基本了解了，三天之内给你答复，回去等通知吧。”

然后下午就接到了通知，通知第二天带着自己的笔记本电脑去实习，我终于如释重负的舒了一口气，终于找到工作了。

某大行面试

我一直待项目组，不知道我的部门是随时外派。某天测试组长说：“你要去某大行面试了，以后就在帝都工作喽。”

10多人来到帝都后，这边负责人专门找人给我们做培训，参加了个机考，就是写测试案例，倒入测试管理系统，执行案例，提交缺陷等。

面试一直推后，我们一帮人在帝都吃喝玩乐，去了长城、鸟巢、天安门、王府井、故宫等。终于某天下午负责人打电话说下午面试，大家好好发挥，争取都能来帝都上班。

拿着简历来到面试地点，敲门后，面试官微笑着说：“坐。”我把简历递给面试官姐姐。

面：自我介绍一下，包括做过的项目？

我：毕业于某大学计算机科学与技术专业，大三暑期开始实习，熟悉软件测试流程，熟悉oracle、Linux等

主要做银行系统，熟悉存款、贷款、卡、支付等业务，主要负责案例编写、案例执行、部署版本、重现生产bug、测试接口。

面：测试人员发现一个bug，开发人员说不是，这时你怎么办？

我：我让测试组长找那个开发人员修复bug。

面：这个问题回答的不好，你应该拿着需求文档，对照着上面的功能描述和开发人员谈。

老师我打断一下，我说：“既然我找开发人员说了这是bug，前提我已经认真看过需求，就是个bug，也和开发说这个事了。

面：你的思维跳跃太快，得一步一步来。开发人员一直坚持说不是bug，这时该怎么办？

我：让测试组长找开发人员聊，开发还坚持不是bug，测试组长去找开发组长，开发组长也坚持说不是bug

测试组长找项目经理，项目经理也坚持认为不是bug，最后只能找客户了。

面：你的情况我了解了，回去等通知吧。

别人都面了15分钟左右，我感觉自己也就用了2分钟。

我离开时不小心把简历带走了，这尼玛自己给自己挖坑呢，带走简历，面试官怎么找我？

很幸运最后通过了面试，见识了大行的工作风采。

联想到了汇报工作的事：我们项目组有4个测试人员，每人负责1个模块，每次汇报工作，别人汇报10来分钟，感觉领导还是听不懂，认为她们的模块太难。到我这我2分钟汇报完，举例子：资金归集就是，打个比方先在银行签约服务，你老公可以每天、每周、每月、每季度向你卡里打钱，简洁明了，领导说：“这么简单？”，我一脸黑线，此时领导会感觉你这个活太简单，工作量相当不饱和。

面试题整理

项目的测试流程

拿到需求文档后，写测试用例

审核测试用例

等待开发包

部署测试环境

冒烟测试（网页架构图）

页面初始化测试（查看数据库中的数据内容和页面展示的内容是否一致，并且是否按照某些顺序排列）

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

发现缺陷就要再填写缺陷表

非功能性测试（sql、js注入、页面效率、绕过js验证直接添加数据到数据库）

书写最终的测试报告

测试用例设计方法

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

测试用例的要素

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

测试的优先级

先测试经过变更的部分，然后测试没有变更的部分

先测试程序的核心功能，然后测试一般功能

先测试逻辑性的功能，然后测试业务性的功能

先测试常规情况，然后测试异常情况

先测试功能，然后测试性能

测试报告包含哪些内容

1.写测试背景

2.测试目标

3.测试范围

4.测试环境

5.测试数据

6.测试标准（重点）

7.测试进度

8.测试结果

9.测试结论

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

大致会包含 测试所用时间 测试环境 测试人员 测试发现bug数量 已修复bug数量、遗留bug、遗留bug原因、测试结果等

BUG的生命周期

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

BUG的状态

NEW：所有提交到开发对接的问题状态为NEW，表示为未处理

OPEN：开发对接人初判为需流转问题，指定测试人员和开发人员，状态为OPEN。

REFUSE：开发对接人判断为不需要流转至下环节的问题，状态为REFUSE，并且填写原因

FIXED：开发人员完成修复，待测试，状态为FIXED

REOPEN：测试人员针对开发人员的修复结果测试部通过，状态为REOPEN

CLOSE：测试人员判断问题为需求或其他问题，需填写原因；

缺陷的要素

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

缺陷的级别

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

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

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

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

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

WEB测试与APP测试的区别

1. 架构不同。

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

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

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

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

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

3. 兼容性

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

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

4. 性能方面

web，测试响应的时间

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

5. 安全性

web，sql注入。xss攻击等

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

6、app测试特点

适配性测试

网络测试

在线升级测试

中断测试

耗电量测试

弱网测试

安装卸载测试

流量测试

app测试的主要内容

1. 功能测试

业务逻辑正确性的测试

2. 兼容性测试

系统版本

分辨率

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

常用linux命令

什么情况下定位不到元素

GET请求和POST请求的区别

网络情况

3. 异常测试

热启动

网络切换

电话信息终端恢复

4. 升级、安装、卸载

5. 健壮性测试

手机资源消耗

流量消耗

电量测试

崩溃恢复

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

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

获取判断的依据和标准

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

如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

根据用户的一般使用习惯，来确认是否是缺陷；

与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

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

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

常用linux命令

ifconfig 查看IP地址

cat 用于显示指定文件的全部内容

more 用分页的形式显示指定文件的内容

mkdir 创建目录

touch 创建新的文件

grep 查找文件里符合条件的字符串

find 查找指定的文件

tail -f 用于自动刷新显示文件后N行数据内容

kill -9 强制结束

netstat -anp | grep 端口号 查看端口

chmod -R 777 赋予777权限

什么情况下定位不到元素

代码写错

元素未出现（需要元素等待）

元素在iframe中

多窗口

出现弹窗（系统弹窗、JS弹窗）

元素属性值是动态加载的

元素无法确定唯一性

只读属性（元素不可操作）

GET请求和POST请求的区别

GET使用URL或Cookies传参，POST将数据放在BODY中

GET的URL会有长度上的限制，POST的数据则可以非常大

POST比GET安全，因为在地址栏不可见

一般GET用来获取数据，POST用来发送数据

为什么要做接口测试

越底层发现BUG，修复成本越低

前端发生变化时，后端接口可以不用变

检查系统的安全性、稳定性，前端传参不可信

接口测试是怎么做的

–由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI等。

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

接口测试的重点

检查接口返回的数据是否与预期的结果一致

检查接口的容错性，加入传递的类型错误时是否可以处理

接口测试的边界值

接口的性能

接口的安全性

http状态码

1xx：请求正常，但是无响应，只有在实验状态下使用

2xx：2开头的表示发送成功

3xx：3开头的代表重定向，常见302

4xx：400代表客户端发送的语法有错误，401代表访问的页面没有授权，403 无权限访问该网页，404代表没有这个页面，415 格式错误

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

cookies和session的区别

cookies数据存放在客户的浏览器上，session数据放在服务器上

cookies不是很安全，别人可以分析存放在本地的cookies并进行cookies欺骗考虑到安全应当使用session

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

常用的adb命令

adb start-server 启动adb服务

adb kill-server 关闭adb服务

adb devices 查看设备号

adb push 电脑 手机

adb pull 手机 电脑

adb logcat | grep 包名（unix）

adb logcat | findstr 报名 （win）

adb shell 进入shell命令行

adb install 安装app到手机上

adb uninstall 卸载app到手机上

adb logcat > 文件名 输出log到文件

adb shell top 测试app的资源消耗命令

产品的业务流程

解析

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

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

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

验收标准

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

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

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

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

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

序。）

缺陷修复率标准

(1) 紧急、严重级别错误修复率应达到100%;

(2) 普通级别错误修复率应达到95%以上;

(3) 优化级别错误修复率应达到60%以上;

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

服务器运行状态响应指标

(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、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见

共勉:【可能给予你助力的教程】

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。

测试资源免费领~~~