测试基础 测试分析之原创面试题分享

summer1248 · 2021年03月28日 · 最后由 summer1248 回复于 2021年04月03日 · 7662 次阅读

个人喜欢问的面试题,基本没有遇到几个回答比较好的,自己怒答一波。
写的不对的地方,请指教。

********Q1:如果 web 上有一个保存按钮,点了没有任何反应,可能会是哪种问题,你分别会用什么方法去定位?
注:这里的保存需要将数据保存到服务器。
A1.最最基础的,目前回答次数最多的答案。
1.网络问题,除了其他页面的功能也都不正常,说明是网络问题。
2.打开抓包工具,查看是否抓到保存接口对应的请求,如果没有看到请求,说明是前端问题。
3.如果看到了请求,再看下返回接口是否正常,如果报错,说明是后端问题。

展开,
********Q2.如果同个网络环境,其他人都可以,就你的电脑不行,怎么排查呢?
A2:看下是否有设置代理(抓包工具、是否修改 host 文件、vpn 等)。
如果代理也没问题,诊断下网络。

再展开提问,
********Q3.如果是第 2 种情况,没有发起请求,怎么进一步分析?
A3.主要考察前端问题定位能力
1.前端问题,先打开 devtool,看下 console 中是否有脚本报错,如果出现报错,看下报错堆栈;
2.如果没有任何报错,看下前端的代码,可以使用 devtool 打断点调试找下问题代码(具体怎么用,还可以再考察下,比如代码混淆情况下怎么去找)

继续展开
********Q4.如果抓包工具抓到了请求,接口返回报错了,一定是后端问题吗?
A4:主要 http 请求是否熟悉,包括状态码、请求包、返回包,包头、包体
1.不一定,如果 http 状态码是 200,response body 返回了业务的错误码或者说返回了业务数据但是数据内容不对,此时需要先看下请求参数是否有问题。如果有问题,需要前端修改;如果参数没有问题,基本上可判断是后端问题。
2.如果返回码非 200,需要进一步分析。
比如 404,可能是前端请求 url 不对,也可能是服务端忘记部署相应的服务。(可以考察下 host、path、请求参数的不同点)
403,通常是鉴权失败,比如可能是前端在请求参数没有带登录票据信息。这里不同的业务实现不一样,有的业务是放在请求参数的某个字段里,比如 accessToken,有的业务可能是放在请求包 header 中的 cookie 字段里。需要根据具体的业务,去检查这两个地方。当然,也可能是 token 过期失效了,这个就更复杂一点,需要根据业务具体的 token 刷新机制来分析。
500/503,通常是后端服务不可用,比如服务没找到,进程挂了,比如接口调用超时.
302,请求被重定向到其他接口了。这种情况下,302 之后会紧跟重定向的请求,需要 check 下重定向行为以及重定向之后的 url 是否正确。如果无误,进一步分析下重定向之后的请求是什么情况。方法同上。
还有少数情况,比如 413,是请求包长度超过了 http 协议的限制。

继续考察服务端
********Q5.如果是服务端问题,怎么进一步分析?
A5:主要考察是否熟悉服务端相关的一些知识
1.如果返回了业务错误码,或者是返回了不正确的业务数据,说明服务肯定是在的,代码逻辑有问题。
首先,可以先看下服务器的 log,通过调用链、业务错误码、请求或返回中的某个唯一的字段或出现频率较少的字段,来缩小日志范围,再结合出现问题的时间点,找到出现问题的那部分日志。(cat、tail、grep 等等)
如果日志当中看不出具体的问题,可以通过白盒分析的方式查看代码,找到对应的问题;也可以通过调试的方法,找到问题。(arthas 等)
2.如果数据不对,可以直接查下对应的数据存储是否有问题。(mysql select,redis redis-cli 等)
3.如果是 500/503 这类错误,需要检查下服务的进程是否在,服务接口是否在,服务注册是否成功等(ps/telnet 等),以及接口耗时是否过长导致超时等。
4.定位过程中,可以还需要调接口查下下游应用的返回。根据具体的服务不一样,调用方法也不一样,比如 dubbo,至少要会 invoke 调用。
5.如果返回的错误码一看就不是业务应用返回的,有可能是中间在某个代理层/接入层就挂掉了,还没走到业务的后端代码中。此时可以确认下是否有请求走到后端,如果没有,基本上就是从这个方向去排查。
6.有些问题比较复杂,如果从代码等方面没有思路。可以从代码提交的角度缩小范围。比如部署上一次 commit 的代码,重放请求,如果上一次 commit 没问题,基本可以确认是最新 commit 引入问题,排查范围就缩小很多。

当然,还可以继续加大深度,比如
Q6.如果是服务进程不在,重启后正常,运行一段时间后进程又挂了,怎么分析?如果是接口耗时过长,怎么分析
A6:需要从内存泄露、线程池链接、任务排队等等角度再进一步分析。每个拎出来又是一个专项,不展示讨论。

最后,打个招聘广告。有兴趣来有赞的,请联系我,招有想法的测试开发。
邮箱:459979154@qq.com

共收到 20 条回复 时间 点赞

挺不错的面试题,逐层深入,方便了解对 web 技术了解的深度。

点赞,这个面试题不错,一个常见的工作场景考察了很多方面

一直有个疑问,就是我们定位问题 真的有必要去 debug 找到代码层哪里逻辑出来问题 提供给开发吗?
以我自己来论,做的最多的是找到毕现路径,描述清楚,然后定位是前端还是后端问题提交给对应开发,这样基本就结束了,对一些涉及到异地办公的项目,会再加上报错的日志,和一些关键性信息(如:接口传参,数据库数据等)

我觉得这个因项目而异

说的好详细,但是对于我们 to b 的项目,貌似服务端那边并不会深入到代码层。而且日志文件啥的都是管理员可以直接平台上查看到的,也用不到 linux 的指令。 请问有什么好的方法,可以提高测试的技术或者解决问题的思路呢

豁然开朗

个人理解,不需要每个都这么深入,但知识上要有所了解,有些疑难杂症需要能了解到这些细节(比如各种非必现但出现了就很影响用户的问题)。因为这样能让我们从原理上了解整个问题的全貌,以及推断开发的解决方案除了修复这个问题是否还会影响别的功能,是否要补充进行功能回归。

往大点说,也有助于我们提高自己的测试效率。比如常见的接口测试要验证必填字段没填是否正确,除了真正构造用例执行请求外,如果了解开发代码怎么写,可以直接通过 review 代码快速确认,效率会更高。原理上保障不出问题,比通过检验来确认没有问题,段位是不是更高一些,效率也可以更高一些(直接就不用全面测试,只需要抽验即可,甚至免测)?

其实简单的说,就是不能什么都不会,开发说啥就是啥。还是需要有自己的一些判断和理解。

djc-Sherlock 回复

linux 命令的话,可以自己搞个云主机,部署个播客之类的项目试试。我自己就是这么练手的。

技术深度的话,也不是一蹴而就的。平时的各种 bug 除了验证外,也找开发了解下出现原因以及修复方式,从中了解下原理。线上问题也要熟悉到自己能给不了解技术的同学讲清楚出现原因以及现在的解决方式为何可以杜绝再次出现。

今年以来我也开始担任面试官了,你这种循序渐进,开放式的面试方式很棒,学习到了,感谢分享~

陈恒捷 回复

通过这个面试题是不是反应了客户端测试技术深度不如服务端,天花板低,测试内部会有一条鄙视链

点了没有任何反应。不是明显在暗示按钮没有绑定事件么

面试首要试题👍

红客联盟 回复

并不会呀。

假设上面这道题,确认是客户端问题,要细究客户端可能什么问题,个人能想到的:

1、按钮没有绑定事件,所以点击后其实没有触发任何逻辑
2、按钮绑定了事件,但事件执行出错抛异常,所以没有触发任何逻辑。为啥抛异常又可以说很多原因了,不同浏览器支持的 js api 差异、本身逻辑不够严谨等。
3、按钮绑定了事件,事件也执行了网络请求,但没有设定请求成功的回调函数,请求了个寂寞
4、按钮绑定了事件,事件也执行了网络请求,网络请求也有回调函数,但回调函数出错或者没有触发界面元素变化,所以看不出有变化
...

如果是 app ,那可能比 h5 又要复杂不少,中间可能会用到好几个组件。而且很多时候相比服务端,客户端问题用户感知更明显,app 类的修复成本也更高,所以反而质量要求会更高。只是现在客户端性能一般没有服务端好,所以大多架构上倾向于把复杂逻辑集中在服务端,而这个题关注点也在逻辑。客户端更常见的界面兼容展示类问题这个题里没涉及。

之前看过某个极客时间的专栏,里面的大佬有提到,长期发展来说,服务端会逐步倾向于稳定,主要提供相对通用的存储共享服务,比如 GraphQL 这种模式。而客户端会倾向于多样化,内置大部分业务逻辑。

这个看具体情况决定,毕竟大家平时工作都排的很慢,可能没几个测试能有时间每个问题都去分析。但是如果能自己尝试分析,这个过程对自己的能力提升会有很大帮助。我个人的经验,是有选择的挑一些比较有挖掘价值的去看。

陈恒捷 回复

对,了解被测对象,包含了业务和技术实现。其实有个很显而易见的好处,就是可以给测试用例做减法。看完代码会发现有些点根本不用测,不可能出问题。

bugVanisher 回复

我也在学习中,多指教

红客联盟 回复

不是的,其实前端有很多问题分析难度我觉得完全不亚于客户端。这里没有展开,主要是因为,第一我这几年的工作偏服务端多一些,我们这边招聘也是偏重服务端的;第二,前端的问题分析我觉得需要举实际例子来讲比较合适。
我个人第一份工作,对应的业务主要都是重前端/客户端的,其实也学会到了非常多。包括我这边文章核心的思路,也是那个时候 get 到的。
所以鄙视链这回事不存在的~

hellohell 回复

哈哈,这只是一种万千可能的一种。

陈恒捷 回复

对,讲的蛮好。甚至有些 app 通信协议都是私有的,不是传统 http/https,在网络建立链接这个过程,都很多说头的。
只是服务端很多测试手段/方法已被大家广泛了解和学习,而客户端/前端则不然。
比如大家常说的客户端兼容性,有几个人真正知道底层具体要兼容的是什么呢?

陈恒捷 分享一下今天遇到的面试题 中提及了此贴 04月22日 10:57
天艮 跳槽的那些事儿 中提及了此贴 01月04日 16:00
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册