在TesterHome看到一篇文章《被同龄人抛弃？68道中高级测试工程师面试题助你一臂之力》。我大致看了下，里面的问题很有代表性，即使是我这样的老司机，没有经过充分准备也不能回答的令自己满意，故花点时间，写下这些面试题的答案，给大家参考，也欢迎大家讨论指正。

正文全部引用上述文章的问题，答案写在每一个问题下面。

这种题目，考的就是你的软性能力，比如表达能力，理解能力，协调能力，一个词概括就是套路。这类题目会在面试开始热身的时候，问一道两题，不会多，但是如果你能回答的有条不紊，清晰达意，那么就会给面试官留下非常好的印象，大致的题目如下：

我叫XXX，毕业于XXX，从事测试行业已经XX年，我擅长接口测试自动化，测试框架，巴拉巴拉，我共服务过X个公司分别有Y个成就，江湖人称666.总之，尽量用
简介的语言突出自己的优点，要保持humble，就像我介绍的这样，嗯：）

介绍下你负责的公司项目

我主导了XXX，协助了YYY，参与了ZZZ。这个回答你要记清楚，后续的面试肯定还有项目细节，甚至技术实现细节。同类的项目说一个足以，重点突出不同技术栈或者有管理，对外沟通的项目

实际情况作答，比如优点是长的好看，缺点是太好看之类的，总之，要谦虚，不要傲。

在同一个项目组内，你认为你怎么做会比另外一名测试更加优秀？

我个人认为这个题目很有迷惑性，如果你只追求比别人优秀，肯定很难跟别人合作，如果你没有别人优秀，那么我为什么要用你？
要我答的话，我重点会放在如何一点一滴积累技术实力，及用这些实力解决项目组存在的问题上，这实际上也是很多优秀测试人员的必备素质

你为什么离开上家公司？离职原因（这个会在最后问）

看老板不爽啊，PM太SB啦喜欢的同事跟开发跑啦等等， 一个都不要说！！！我要面试别人，关注的是离职背后的动机，这人是不是被开除的，这人是不是不好相处，这人是不是有明显性格缺陷，只要不沾这些必死项，其它实际作答吧。

个人觉得软性题，不必要过多关注，除自我介绍外，通常是通过面试后HR关的闲聊题，主要还是要关注下面的技术问题。

3.Release process开始，不同小组把各自代码放到统一测试环境，继续测试一次，这轮关注别组不会影响自己。
4.然后还有一轮甚至两轮 pre release，主要验证代码，环境，变量等问题。
5.最后release， 观察下，有问题回退版本，没问题继续走下个sprint

请描述下bug的几个要素？

白盒和黑盒的区别，你是怎么运用的？

简单来说一个关注内部实现逻辑，一个只从用户角度出发，不关注具体实现。具体定义及区别请参考我以往文章。
一般中高级测试都会偏灰盒一些，既关注内部实现逻辑又关注用户jounery，设计case的时候两边参考。
内部实现逻辑可以看代码，也可以请开发讲给你听，知道了怎么实现，能在设计用例时构造不同数据cover逻辑覆盖。同时也清楚了regression 的scope

这题是考察测试思维，一个应用/功能如何测试的问题，我的原则是确定需求，先定性后定量。
具体来说，定性， 哪些是显性需求？那些是隐性需求？功能在scope吗？性能？可靠性？安全性？兼容mobile平台吗？
定量就是， 功能要测， 那么有哪些功能，每个功能点是什么， 入口是什么，出口是什么，precondition是什么，数据哪里构造等等。
重复上述操作直到分析完成

如何设计测试用例？什么样子的测试用例是好用例？

个人觉得上题回答好了，这题不会问了。设计用例原则上好的用例各有千秋（不外乎边界值，等价类，流程图，正交法，判定表等）， 但坏的实践要避免，具体如下：
1.一个测试用例验证多个功能点（A,B,C三个功能一个用例，那么用例失败了，到底是A引起的？还是B引起的?增加后续开发定位问题的难度，浪费时间）
3.不可执行（比如一个配置项组合， 手工要执行的case写了2000个， 怎么执行完？）
4.precondition，steps描述不清楚，上手困难（你负责的story可能要由其它测试人员交叉执行）。
5.不必要的外部依赖（用例应直指功能核心，无关的入口/步骤/依赖 不必要一股脑放进来）

功能测试在 beta 版本对外的上线标准是什么？

貌似业界对beta的定义不太统一，有人说这个是A/B测试的一种， 但一般认为专业测试人员完成后，有部分用户参与的一轮测试即beta测试。一般测试环境为用户实际应用环境，目标在于要求用户使用发现不合理，不符合实际情况的问题，然后改进。
功能上线标准每个公司不一样，大致如下：
1.所有功能点(需求)都被用例覆盖到了
2.所有用例执行过至少一遍
3.所有发现的bug被修复并验证，做过regression了。
5.bug曲线区域平稳了

本人认为此类问题属于淘汰题，一个问题回答不上来或者深度不够，直接闲聊然后结束面试。

范围不变，赶工/增加人手，快速跟进/并行开始任务。范围能变，砍低优先级用例，缩小测试范围。

描述下你团队的测试分工

干活是不可能干活的，这辈子都不可能干活的， 做管理又不会做，就是颜值这种东西，才能维持得了团队这样子。

对于团队成员，你是如何打kpi的？

没钱没颜你速去，童颜巨 你快来这样子。

公众号以前分享过，不赘述，把握以下几点：
0.任何类型测试先定性，再定量， 范围， 分类一定，大差不差。
1.web通常不要安装，移动应用通常要安装。
2.移动设备存在特殊性，不同设备的屏幕/分辨率，系统，定制UI都不相同。
3.移动应用不应该影响移动设备现有功能，如电话/短信等。
4.移动端要重点关注，发热（电量消耗）， crash， 流量(4G/WIFI/2G)等

你是如何做应用的兼容性测试的？

1.硬件的适配：不同手机厂商、硬件性能，不同屏幕大小的适配
3.不同分辨率屏幕的适配
解决办法（云测，此处欠我广告费），除公司自备主流设备外，需参考：
1.各大厂商发布的季度/年度手机出货量，尽量覆盖出货量大的，热门的机型
2.应用做tracking，记录自己用户常用机型
3.购买各种云测服务，解决机型适配问题

请讲出客户端下 3 个常用的性能指标的名称与具体含义？

4.竞品相应项目质量比较

iOS应用和Android应用测试有什么侧重点？

主要是iOS系统和Android系统的本质造成的：
1.Android运行基于虚拟机，iOS则是沙盒机制
2.iOS是伪后台，任何第三方程序都不能在后台运行；而Android是真后台，安卓中任何程序都能在后台运行，直到内存不够才关闭
3.IOS中用于UI指令权限最高，安卓中数据处理指令权限最高。
测试实际应用上来，个人觉得没有本质区别，要注意以下问题：
1.安全性。因为Android2的本质，任何程序都就可以轻松访问其他程序文件，要关注下有没有偷偷访问不需要功能/偷流量/常时间运行占用内存消耗电量等问题。
2.Android开源，定制版本过多（比如小米系列MIUI）， 要关注定制引起的问题。

请讲诉移动应用的灰度是怎么做的？

灰度发布作为A/B Test的一种，一般指发布新功能到部分用户，收集反馈/改进，进而发布到全步用户的一种策略。
1.新服务发布到全部服务器，但通过配置项把不同特征用户的请求打到不同的后端服务上去。比如ip是中国的用户访点击某个按钮，调用的是后端。。。/vi这个API， 而国外ip调用。。/V2
2.新功能的后端服务只发布到部分服务器，只有访问到这个服务器的用户才能用新功能。
3.同一个用户访问的平台不同，请求的服务就不同，比如app的访问V1， web的访问V2，可以通过发布app版本来实现。
另外这个实现还有很多专业的AB测试平台可以实现， 例如（云测，此处欠我广告费）。
如果涉及到写DB操作， 一般都双写。即访问新服务时，写到新服务的DB数据也要写到老服务的DB。甚至全部切换至新服务后再并行运行一段时间，才彻底切换到新服务，停写老服务。

2.后端服务或动态链接库未找到
3.应用初始化时无法正确读取到用户数据。
日志抓取的话，iOS：
2.通过Xcode从你的设备上获得崩溃日志
3.自己在程序中添加崩溃捕捉代码，如果应用集成第三方SDK，如百度统计
1.通过集成第三方SDK，如百度统计、友盟统计等
2、发版时使用加固工具，他们也会收集错误日志，如360加固
3、在程序中添加程序异常崩溃的捕捉代码，保存到本地文件中

请简述移动应用在升级安装时候应该考虑的场景？

实际上跟CS架构的升级没什么两样：
1.APP有新版本时，打开APP是否有更新提示。
2.当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3.当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。
4.不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。
5.删除老的APP，重新下载APP，能不能正常工作。
6.不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。
7.检查在线跨版本升级能否成功，版本过老是否提示用户重装。
8.更新成功后，用户数据有没有丢失，各个配置项是否还原。

给你一个应用，请简述你会从哪些方面去测试？

一般答分类， 分类如下：安装/卸载测试， UI， 功能， 性能， 安全， 兼容， 易用， 可移植性。切忌东答一下，西答一下。

请描述下微信朋友圈发小视频的用例设计？

先假设一个需求，征得面试官同意，在这个既定需求下说你的用例，还是那个思想，定性，定量分类， 不展开了，测试用例设计算基本功吧，考察的无非是功能的全面性，边界/异常条件下的处理， 性能/安全。主要是有测试思维/结构化思维，设计的用例要系统，不能想起那个说那个。

如果让你来测试扫码支付，你会考虑哪些场景？

如何测试一个应用的登录场景？

同上，不赘述， 吐槽下，这题改成如何测试百度的登录会更好，BAT齐活了 ：） 实际上这3道题有一道就好了。

对中高级测试而言，实践题也是淘汰题，一项卡壳没有后续， 但如果在细节上有疏忽，可以网开一面，进入下个环节

请问你们公司是如何做接口测试的？

累死我了， 题要做吐了。接口测试实际跟一般测试不同就是测试用例的设计部分。
2.设计接口测试功能用例（主要从用户角度出发看接口能否实现业务需求，用例设计就是黑盒用例那一套）。
3.各种入参验证（正常情况，异常情况包括输入参数个数不对，类型不对，可选/必选， 还有考虑参数有互斥或关联的情况）。
4.接口返回值各种验证（符合接口文档需求）
5.了解接口实现逻辑，实现逻辑覆盖（语句/条件/分支/判定/。。。。。）
6.接口能并发执行吗?
6.采用工具或者自写代码来验证，HTTP接口一般SoapUI， Jmeter， Fiddler， Postman等都能验证，自己写更好。web service接口一般要写代码来调用。根据测试用例自动化。
7.发现问题跟功能测试一样，该报bug报bug，该跟踪状态跟踪状态

接口测试质量评估标准是什么？

接口测试说的接口可以是模块接口，也可以是集成接口，那么质量评估标准也就转换为单元测试里的接口测试标准，和集成测试里的集成测试标准。
实际上这题如果我来回答的话会关注：
1.接口功能是否正确，接口功能是否实现了业务需求。
2.接口参数正确性包括实参形参的个数/属性，是否匹配。
3.接口并发/串行执行时接口返回值的正确性。
4.有没有性能问题（并发执行），有无安全问题（用户能否直接访问该接口，需不需要验证）
面试答上面的应该够了， 其实这里面涉及到单元测试和集成测试评估点，我公众号以前分享后，在测试基础知识里， 总结的更全面，大家可移步查看。

请问你们公司是如何做性能测试的？请讲诉性能测试的相关指标？

老规矩，先确定需求，再定性，定量。
1.这次测试目的是什么，是压力测试/负载测试/疲劳强度测试/BenchMark测试？
2.测试的硬件环境是什么？软件是什么？
5.测试分析调优/测试报告要吗？
1.拿到测试需求，确定测试软硬件环境/测试指标， 使用测试工具(Loadrunner, jmeter)录制或者编写测试代码，逐步加压，直到测试目的达成。
2.分析测试结果，编写测试报告，突出性能指标包括成功，失败情况，并加以分析。
3.调优（一般都是开发的事）
服务器系统资源方面 CPU占用率，内存占用率 磁盘的读写指标
网络的占用情况 基础吞吐率
事务处理速度 如平均登录时间，操作平均响应时间等。

压力测试和负载测试的区别

一个（压力测试）把最后一根稻草仍你身上，一个（负载测试）就剩最后一根稻草没仍，或者仍给你指定数目稻草。

服务器中一般要监控哪些数据，如何监控的，怎么从监控数据中发现问题？

CPU， 内存， 网络， I/O， 数据库。等等。一般用工具监控，另外Windows上有性能监视器。
发现问题，一般要关注阈值，比如CPU利用率超过85%，说明server压力太大了，数据量一大DB某条SQL写入速度变慢了等等等等

假设系统A调用系统B，我把B的接口都mock了，进行性能测试，这样有什么好处和坏处？

好处是去掉的依赖，可以在B没有好之前测试A，并且B的任何改动/错误/失效不会影响我测试A
坏处是真实性能要比测出来的性能差， 性能指标不准确。因为Mock的服务再真也不能代替真实服务

有一天早上打车高峰，滴滴服务端挂了大概30分钟，工程师抢修之后，马上上线，之后又挂了，请问有哪些原因会造成这个情况？

还是考测试思维， 一定记得先确认需求，再定性，定量。一般都要反问， 服务器是哪个服务器？后端应用服务器？数据服务器？缓存系统服务器？中间件服务器？文件系统服务器？
然后面试官说个，不说就自己假定一个， 然后第一次挂第二次挂分开说，先问有没有错误码，日志有吗，有就看日志，没有就猜 是应用服务器挂了啊，是不是高峰期顶不住这么大并发访问啊？是数据库服务器啊，是不是频繁读写受不了啊，读写有分开吗？同步还是异步啊， 把喇叭里。
第二次挂，可能更多了，是不是代码弄错了，改坏了，或者把喇叭里。
总之套路就是性能测试中可能预见的问题及原因，这个你们google下吧，自己分类总结下。

见仁见智，一切能提高软件质量的方法都应该尝试。
兵无常形，符合自己项目实际情况是最好的。当然你要面试自动化测试，肯定是一切稳定了的功能最好全部自动化掉。:)

你们公司的自动化投入产出比怎样？效益怎样？

实话实说，UI自动化测试发现新bug的效益很低，主要用在回归测试上，减少测试工作量。接口测试可就不一样了，可以小步快跑，也可以集团作战。

自动化测试用例的覆盖率多少？

有个50%了不得了吧， 一般核心业务里的最高优先级用例100%覆盖，这些用例也是用来跑冒烟的。另外的看项目资源了。

完整运行一次自动化用例需要多久时间？

Google说它们分钟级或者秒级别， 为毛我们都是小时级别 ：（

金字塔结构， 最底层UnitTest，往上接口API/集成起来的service， 最上面UI自动化

你的测试数据是怎么准备的？

当然是提前准备的了：）
写在脚本里/外部文件（excel， XML）/数据库， 逼格逐级提升

测试脚本的维护成本是怎么样的？

2.终身追责，谁污染谁治理

啊啊啊，已经两个小时了，要抓狂了。

请问如何实现用例失败或者异常时候需要截图？

请问如何分布式执行webdriver用例？

iOS和Android上还有独特的定位方法：

真想跟面试官说，您能帮忙打开官网吗？Appium对iOS和Anroid的实现原理不尽相同，并且对同一个平台不同操作系统版本的实现原理也不相同。

我倾向大家往简单了说：
1.Appium是C/S架构的，更像是一个proxy，连接其被测移动平台和测试脚本。
网上有个很清晰的图，截图如下：

实际上我个人理解，这个题就是想了解，当你使用一个工具时，你是否关心过它的内部实现，也可以过渡到当你测试一个应用时，你是否关注它的实现。

当定位策略都失败的时候，你该怎么做？

80%是你元素定位的不对，那么多定位方法，一个不行换另外一个，直接不能定位，先定位父元素，再循环找子元素。一般来说XPATH都能定位到，无非是可阅读性不强。真的全部失效，请求开发帮你改个元素属性好了。
这题其实还是”测试sense”问题，扩大点变成了怎么解决工作中困难。反正别认怂， 最好甭废话，直接开干。

请问Monkey测试的优缺点？

如果使用monkey发现了一个毕现闪退，请问怎么使用monkey重现它？

如果有一个登录接口需要服务端返回参数，再带着这个参数去请求才能完成登录，用jmeter 怎么做？

1~9999数列中数字3出现的次数。用递推方法解出。

本来以为很简单，写了一下，2位数能算出来结果，3位数会报递归次数太多， 觉得蹊跷， 仔细一查，尼玛这题大有来历，我跪的心服口服。经过查找资料，解答如下：

个位数为3：3， 共1次。

共9个10，我们记为A

还有千位数是2开头的，到9开头的，加起来共有9个（B） 9×10*10=900个。

从一个数组中找出前4个最大的数，用最优解。

这个就是排序问题了吧，我想法先排好序，在取前4个，那么多排序，冒泡啊，选择啊，快排啊。。这里面快排最快，用大O算法O (n * log n )。

少于2个元素的数组不需要排序

针对小于基数的数组做快速排序，暂且叫low

针对大于基数的数组做快速排序, 暂且叫high

最终排序后的 low + 【基数】+ high，就是排好序的数组

其实python里内置了很多优秀的方法来解决其他语言很繁琐的问题，比如本题目可以直接：

（据说python里sorted实现也是快排，没有经过求证。）

哈哈，这样，面试官会不会鄙视我 ：）

我之前也分享过基本的算法，大家可以去我的公众号testertalk查看。

写一段程序，删除字符串a中包含的字符串b，举例 输入a = “asdw”,b = “sd” 返回 字符串 “aw”，并且测试这个程序。

写一个方法，把字符串转为数字，比如 str=”1234”，变成 int 1234。并且测试这个程序。

把一切看成对象，三大特性 继承，封装，多态

讲下Java多线程的使用

java多线程跟别的语言的多线程有区别吗？
多线程一般用来更好的利用CPU资源，解决诸如程序“在一部分上会阻塞”，“在另一部分上需要持续运行”的场合。多线程一般用来更好的利用CPU资源，解决诸如程序“在一部分上会阻塞”，“在另一部分上需要持续运行”的场合。
例如有个程序需要接受多个用户输入并向服务器发送数据，那么如果不用多线程，一旦程序在等待某个用户输入时，程序就会阻塞。这段时间其它用户也不能使用了

有三个线程T1，T2，T3，怎么确保它们按顺序执行？

在主线程中，每一个线程start（）后立即join（）

个人理解start（）会启动线程，然后调用run（），run（）方法一般要重写。
调用start（）后，线程会被放到等待队列，等待CPU调度，并不一定要马上开始执行，只是将这个线程置于可动行状态。然后通过JVM，线程Thread会调用run（）方法，执行本线程的线程体。先调用start后调用run，这么麻烦，为了不直接调用run？就是为了实现多线程的优点，没这个start不行。

1.start（）方法来启动线程，真正实现了多线程运行。这时无需等待run方法体代码执行完毕，可以直接继续执行下面的代码；通过调用Thread类的start()方法来启动一个线程， 这时此线程是处于就绪状态， 并没有运行。然后通过此Thread类调用方法run()来完成其运行操作的， 这里方法run()称为线程体，它包含了要执行的这个线程的内容， Run方法运行结束， 此线程终止。然后CPU再调度其它线程

2.run（）方法当作普通方法的方式调用。程序还是要顺序执行，要等待run方法体执行完毕后，才可继续执行下面的代码；程序中只有主线程——这一个线程， 其程序执行路径还是只有一条， 这样就没有达到写线程的目的。
记住：多线程就是分时利用CPU，宏观上让所有线程一起执行 ，也叫并发

请写一个线程安全的单例模型

网上搜下吧，java不太熟

比如有两张表A和B。A表B表都有ID列，select* from A left join B where A.ID=B.ID. 会把A表所有记录显示，B表里没有和A表ID对应的，会显示NULL。左连接是把符合条件的所有的A表的内容列出来，B表里如果没有内容匹配就用NULL代替。右连接是符合条件的 B表的内容全显示出来，A表里没有匹配就用NULL代替。

使用sql生产10万条数据

平常没接触过这么大数据量，分批次吧，每次插入1w条，应该没什么压力

如何查找一个文件大小超过5M的文件

find . -type f -size +800M常用的参数有:- type:类型。POSIX支持——b:块设备文档、d:目录、c:字符设备文档、P:管道文档、l:符号链接文档、f:普通文档- name:按文件名查找。支持*模糊匹配- size:文件大小。+表示大于，-表示小于。支持k,M,G单位

ps命令。它能显示当前运行中进程的相关信息，包括进程的PID。Linux和UNIX都支持ps命令，显示所有运行中进程的相关信息。ps命令能提供一份当前进程的快照。如果想状态可以自动刷新，可以使用top命令。ps aux | less #显示所有运行中的进程

1. 这68道题目，我花费了2个晚上总结整理，真的收获蛮大。

2. 从个人角度看，这些面试题很接地气，很多考题也跟实际工作密切相关，大大增加了筛掉水货的几率，我也曾用部分相似题来筛选别人。

3. 对于初级测试来说，测试理论，测试基础都应该掌握，移动端测试，服务器端测试，自动化测试，性能测试，也应该逐渐接触起来，不会答没关系，但要大致了解，面试官喜欢有追求的人。

4. 对于中高级测试来说，除了硬题及性能测试题，其它题目经过充分准备都不应该丢分，回答正确率要在85%以上，另外，回答的深度非常重要，决定了你是年龄资深还是技术资深。

5. 对于硬题，虽然大部分的测试，甚至测试开发，工作中用到算法的几率也不高，但你如果都答对了，还是能让人眼前一亮的。
   对于这部分试题，稍有难度的例如google面试题那个，你有个大致思路也行，对于非常基础的，二分啊，排序啊，还是建议多练练，起码应该做到手写正确。
   现在有能力做好普通测试工作的人太多了，算法也跟学历，长相一样，用人单位不得不拿这些筛选掉很多合适的人，有时候你比别人更优秀的能力，也许就来自于你昨天刷了一道面试题。
   怎么说呢，面试造火箭，进来拧螺丝，接受现实吧。

6. 我本人其实是反对面试突击的，本文目的也不希望大家背答案就面试（面试从来也没有标准答案，背了估计也面不上 ：0），而是希望大家通过做这些面试题，发现自己的不足，从而有针对性的提升自己。

7. 感谢大家的阅读，能读到这里的都是真粉丝， 欢迎大家提出更好的意见，谢谢。