一般是根据这个了解对开发技术了解的深度。要很细的说的话，这里涉及了浏览器（客户端）、网络（DNS、tcp/ip 协议、路由等）、服务端（nginx 网关、提供服务的应用、涉及的中间件等）、前端（先拿 html 源码，再获取 html 中声明依赖的其他资源文件，并渲染 dom 树、执行 js 逻辑）等多个位置的逻辑，如果能从前到后都说到点上不容易。

可以看看 https://testerhome.com/topics/29256 这个帖子里的，虽然不是这样的问题，但也是在考察对整个背后技术实现原理的熟悉度。

Xmind8 结构清晰，但是在用例数量多的时候就会非常卡顿。

一直用着 xmind 8 ，一般用例里面 500+ 节点是常事，表示还没遇到过非常卡顿影响使用的情况。楼主的 xmind 用例里是有多少个节点？

同广州的，29 岁如果是本科毕业大概 5 年经验，12k 算是比较低的薪酬要求了。不过你正文说你一二面就挂，应该都还没到提薪酬的阶段，所以应该和你提的薪酬水平没啥关系。

另外，能否分享下你参加的面试，挂的那一面面试官大概问了什么内容，你大概怎么回答，也分析下有没有哪些你自己回答的时候觉得不是太好的？你写的情况有点太笼统了，为什么挂的原因都还没找到，后续的建议无从谈起呀。

先确认下你的卡顿定义是？是用性能测试工具发现总是会存在 Jank（也叫丢帧，对应上面图里红色底色框这个情况，主观感受就是一快一慢，不跟手），还是别的情况？

理论上，接口属于异步 IO 操作，应该是不影响 UI 渲染本身流畅度的。可以找一些淘宝之类的列表页在弱网下看看，拉到底翻页时，如果接口响应慢只会导致在底部停在 loading 状态，并不会引起滑动时卡顿的。你可以体验下，看淘宝的商品列表页是否存在你说的 “卡顿”

额，不知道你列表问题具体是什么问题，接口慢是做什么用的接口慢，可以说具体点么？就这么一句很笼统的描述，没法回答你。

建议看下 Perfdog 官方对于自身提供的各种性能指标的说明，说的很详细了。

1.他们说的对吗？——从帧率的计算角度，这个有一定道理。不过不知道你这里说的 慢了 4 帧 是什么概念，所以不好说对不对。

2.帧率显示多少才是测试的正确结果？——不知道你这里慢了 4 帧是啥，所以也不好说

3.系统的帧率怎么去验证？——可以用 perfdog ，自带的开发者工具有个 GPU 呈现模式分析，也可以用下。参考这个文章：https://www.jianshu.com/p/ffba2bdd85f5 ，官方文档（需特殊手段哈）：https://developer.android.com/topic/performance/rendering/inspect-gpu-rendering?hl=zh-cn

4.测试视频播放的平均帧率是否可靠？——个人理解，一般视频播放的帧率取决于视频，而非应用。只要解码器性能足够，一般是比较平稳的。我们日常测试流畅度、卡顿啥的主要看列表滑动和动画，且更关注的是卡顿（Jank，具体定义参照 perfdog 文档），因为平均帧率代表的是平均数，而大家更为敏感的是卡顿（突然卡一下，帧率突升突降这种），卡顿指标才能体现出来。

对的，相当于在接口确认没问题后，自动把响应记录下来，作为下一次测试的断言。当然有些不需要校验的字段，要通过一些比较简便的标记标记出来。

我们用的 bitbar.com ，看了下地区筛选选项，有欧洲和美国。

感谢指出，这确实是一个 bug。会导致遍历起始点直接往 label 右下角移动，label 下方和左方剩余区域都被忽略。

不应该直接跳过，应该只是对这个区域做标记，遇到这片区域的点直接跳过 getColor 就好。

是在这个界面状态下获取不到元素么？这部分元素看起来没有被任何东西遮盖？

我更新了下这个分支代码，把加仓库的相关修改加上了。你看下和你姿势是不是一样？

我已经调整到可以直接 mvn test 就跑起单测了。

+1，直接看招聘信息最全面。

看起来都是比较通用型和开放性的题目，能分享下你当时大概的回答不？

看了下代码，2 个疑问点：
1、f(points, targ, has+1, i); ，这里的 f 函数是什么？看参数就是 getPointCombiArea 自己？
2、area 这个计算多边形面积的函数在哪里用到？搜了下这个函数定义后好像就没被调用过，所以关键的判定面积方面的算法还是没太看出来是怎么做。

判断图标的这个函数，我理解对于 POI 标签这个场景，会不会容易受到里面文字内容不同干扰导致识别错误？

问题一的解法，方便花点时间直接写下代码么，代码看起来更清晰，只是文字描述思路总有些不理解的地方。

直接划 1/4 是有点粗暴了，确实任意 1/4 好点。但没想好具体要怎么判定，直接连接 4 个 label 中心点，有可以出现凹多边形，面积不够 1/4 但如果忽略凹点可能就够 1/4，应该也算作有问题

可以直接写下伪代码分享一下完整算法？

感觉这个像是比较另类的算法题，包了个导航的壳，实际考察内容和导航算法啥的没半毛钱关系。题目里已经给了可用的变量和函数（function 翻译为模块感觉怪怪的，个人更喜欢用函数这个名字），并且限制只能用标准库，意思就是根据变量和函数的组合来解题。

大概写了下：

a.从性能角度考虑，地图中每四分之一的部分中不能显示超过三个 POI 标识

def is_more_than_3_label_in_each_quater_screen():
    """
    判断地图中每四分之一的部分中不能显示超过三个 POI 标识。如果超过返回 True ，否则返回 False
    """
    # 把图拆为4部分（每个大小540*245）
    areas = [
        {"startX": 0, "startY": 0, "endX": 540, "endY":245}, 
        {"startX": 541, "startY": 0, "endX": 1080, "endY":245}, 
        {"startX": 0, "startY": 246, "endX": 540, "endY":490}, 
        {"startX": 541, "startY": 246, "endX": 1080, "endY":290}
    ]
    for area in areas:
        # 每个部分分别先用 getText 看下有没有文本。没有文本说明没有标签，直接略过
        if getText(area["starX"], area["startY"], area["endX"], area["endY"]):
            # 有文字，进一步判定有没有标签。实际这个判断可以融合到上面 if 里面，只是为了便于阅读单独拎出来
            if _is_has_more_than_3_label(area):
               return True
    return False


def _is_has_more_than_3_label(area):
    """
    判断当前区域里面是否有3个 PIO label
    Args: 
        area: 一个记录区域起始结束位置的字典。示例：{"startX": 0, "startY": 0, "endX": 540, "endY":245}
    """
    label_count = 0
    label = {"width": 100, "height": 30}

    # 判定下有没有标签。标签特征是大小为100*30，且最外面2px是红色。可以通过获取像素颜色值判定下
    current_x = area["startX"]
    current_y = area["startY"]
    # 遍历每个像素点
    while current_x <= area["endX"]:
        while current_y <= area["endY"]:
            # 判定是不是红色，是的话说明有标签，因为只有标签会有红色
            if getColor(current_x, current_y) == "red":
                label_count += 1
                # 有标签，直接可以跳过这个标签大小区域了。
                # 如果刚好某个标签横跨2个区域，那它在当前区域的大小就不一定是这个固定值
                # （这里暂且把这种只有一部分在区域内的也算作这个区域内标签，实际可能还得搞个判定算法，达到几分之几才算在这个区域内）
                # ，不过也不可能会在跳过的位置中间藏了一个标签漏检测，所以不影响标签数量判定。
                # 但如果加上标签可能会重叠，那就会更复杂。实际项目个人实在不推荐这么玩哈，直接拿原始接口数据更好
                current_x += label["width"]
                current_y += label["height"]
            # 标签边框里的红色宽度是2，但考虑到有可能命中红色的时候并不是刚好就是边框，所以还是逐个像素遍历吧，也没多少次循环。
            y += 1
        x += 1

    return label_count > 3

到达信息框中显示的预期到达时间应该始终基于到达目的地之前的预期平均速度

写代码有点花时间了，写思路吧：
1、根据 variable 拿到平均车速、当前时间
2、用 getText 直接拿整个地图的 text ，用正则提取出到达信息里的 剩余距离、预计到达时间 (当然也有点风险，比如刚好就有个 PIO Label 也符合正则表达式内容可能就会误判了。最靠谱还是遍历整个图像找那个显示剩余距离剩余时间的框，再从框里提取文字)
3、预计到达时间 - 当前时间获得背后程序计算出来的剩余时长，然后用剩余距离/剩余车速再手动算一个剩余时长，比较一下。特别注意的是 24 小时制这个点，不确定标准库意思是能不能用 datetime 之类的，不允许的话要自己写个小函数来算两个时间差异的小时值

最后，多提一嘴，如果是实际项目，问题一还是找开发去开放一些接口，用于获取背后的数据吧。用图像识别纯黑盒测试，效率不高，投入不少（比如还得像上面这样自己像个算法），直接基于数据简单多了。
问题二的话，这个计算逻辑应该不太复杂，直接 review 代码可能效率更高。

是否可以分享下一些当时提出的问题和你的回答？这个问题好抽象，不同公司，甚至不同人都会有不同的关注点。

要说共性的话，个人感觉更多会关注你的一些主动性、学习潜力、协调能力之类的，就是软技能相关的吧。因为硬技能类前面面试能过说明都没太大问题了。

有用 xcode inspector 来查看 UI 结构不？有的话方便直接截个完整的结构图么？

appium 底层是用 XCUITest 获取控件树的，能拿到的空间 xcode inspector 应该也可以看到。如果 xcode inspector 看不到，说明实际这个控件就是不存在，而不是被别的东西盖住。

另外，如果实在拿不到空间，除了坐标，也可以考虑用图像识别来获取控件位置，相对来说适配性会好一些。

每个人都可以有自己的选择，如果觉得匿名区的一些问题不是自己想浏览的内容，可以屏蔽匿名区哈。

相比吐槽，个人更倾向于引导，吐槽容易引起对抗，引导容易引起改变。并不是每个人都故意做伸手党的，很可能只是他们成长环境让他们提问方面比较直接简单。如楼上不少人所说，很多人都是从小白走过来的，愿大家多一些善意，多一些包容吧。

这描述有点抽象。查了下图例提到的一些容器名字，应该是用了 JXPagingView 这个控件库。暂时没搜到这个控件和 appium 配合使用的相关文章。

建议拿下源码，本地用 xcode debug 看下实际 UI 层级结构有什么特别，是不是可以拿到你图中粉色部分的控件？可以参考 https://blog.csdn.net/PZ0605/article/details/50670285

是不是可以了解下，开发具体改了啥？为啥改完就找不到了？既然都做 UI 自动化了，就不要把被测 app 当黑盒了，去了解下开发改动逻辑吧。

无法找元素 A，是整个树结构变了，还是元素属性变了，还是元素直接从树结构里消失了？这张截图啥都看不出来。

麻烦提问的时候，把这些信息补充完整吧。完整了解问题信息是分析问题的前提，问题是啥都不知道，怎么解决无从谈起。

从你的描述看，服务端应该是根据 cookie 来判定账号的。

requests.session() 本身设计是用来在整个会话过程中保持一些配置继续复用，避免每次都要重复配置的，和你这个需要有多个配置，不同位置要用不同配置有点差异。

如果确实是通过 cookie 判定账号，你可以全局设定每个账号角色的 cookies 值，然后使用 requests.session() 前手动设定里面内置的 cookies 试试？

具体怎么设定 cookies 找到了这篇文章，可以参考下：https://www.jianshu.com/p/264955856e61

adb 命令就可以调起，但出于安全原因需要开发在 app 里设置这个 activity 是可被外部调起的，否则会提示无权限之类的。

还有一种叫 deeplink 的技术，可以直接跳转到想去的页面，更加通用，但需要开发配合，在 app 里面加代码来提供。