多个接口比例，个人理解本质上是根据业务场景确定的。

已上线：可以基于线上数据获取，比如流量录制，或者通过日志来分析。而且要注意想办法多拿几次数据，确定要有哪几种场景。
未上线：找项目相关的开发、产品、运营一起评估下用户最常用的场景，分析场景里接口调用情况，然后把它作为一个大致的基准。

虽然有点卖广告，但还是推荐看看高楼老师极客时间的《性能测试实战 30 讲》，里面 13、14 讲就是特别讲这块的，个人觉得也是相对科学的方法。

直接给点测试任务她，让她体验下做测试有什么要求呗？

楼主加油，坚持就是胜利。

PS：没看懂这题目是在干嘛？array 和 dictionary 的基本使用？

这个感觉是中年焦虑？只是相比其他人还要焦虑还房贷啥的，楼主这方面经济压力应该暂时没有。

还没到这个年龄，但也有思考过这个方面的东西，说点个人的观点吧：

1、年龄相对较大，外面找工作找一线技术一般会比较难（当然你能力强有人脉另说哈）。不知道楼主对管理或者向更高岗位发展兴趣如何？可能身边看到这个年龄继续上升的基本都是往更高岗位上升居多。而且往高走也更容易成为业务的核心。

2、其他爱好这个，建议可以先尝试下业余去钻研，真的能静下心来继续钻研再考虑转为职业。很多时候爱好只是业余接触会觉得很有趣，但一旦变成职业 1 天 8 小时面对，很快就会觉得枯燥然后没有兴趣了。

3、个人不觉得有什么 “终身职业”，如果有，保持学习的学生算是职业么？技术发展这么迅速，新行业兴起和老行业没落其实十年就很大变化了。算 65 岁退休，职业生涯有 40 年左右，运气好可以不换赛道走到最后，运气不好可能还得换 1-2 次赛道，与其想着选定后做终生，还不如保持好自己的学习能力，真到了要换赛道的时候可以更快速察觉和切换。

好吧，我文字没写好，用一样的扫描工具，就是你正文说的【绿盟、启明星辰】再扫一次。

这个原则个人持保留意见，要看具体业务。不见得每个操作都会有对应的查询接口暴露，查数据库是最直接的手段。

至于多环境权限这个，不见得每个用例都要每个环境都跑吧，线上跑的用例我们一般都是筛选过，不会做增删改的才会放上去。

查询类用这个思路是没啥问题的，但人工维护成本会比较高，建议补充一些自动录制生成 yaml 的功能，否则成本略高。

用 appium desktop 定位，回显的是调 driver.find_elements_by_ios_uiautomation 方式

不知道你这里回显具体是什么，给个截图？

看你的 api 像是 python 语言的，找到官方 python client 自带的测试里有用 ios_class_chain 定位的，可以试试？怎么跑起来可以参照 https://github.com/appium/python-client

用 ios_class_chain 定位的示例
https://github.com/appium/python-client/blob/master/test/functional/ios/search_context/find_by_ios_class_chain_tests.py

截图日志里 connect ECONNREFUSED 127.0.0.1:8002 就是错误原因了吧。看起来这个端口应该是 XCTestWD 提供的。

确认下你单独启动 XCTestWD 能不能成功？

建议也参照官方安装文档，安装 macaca 和用 doctor 检查下安装是否正常

https://macacajs.github.io/app-inspector/guide/install.html#requirements

yml 里怎么定义返回的内容是 json 格式还是 pb 格式，可以给个示例吗？

正文里的复杂例子没看出哪个配置对应这个点。

用 easy mock 搜索，会搜到好几个。

之前公司里有用过这个： https://github.com/easy-mock/easy-mock ，多人协作很方便，也支持 mockjs 自定义 mock 逻辑。至于命令行的以前用的 moco ，也不错。现在搞前端，直接用了 mockjs 内置到前端里面，有需要起独立服务的话加个 express 或者 koa 之类的也可以。

pb 自动转 yml 的，想了解下，转成的 yml ，实际返回 mock 数据的时候还是用 pb 二进制格式返回的吗？给的示例里没看出怎么区分用 pb 格式还是 json 格式，有点疑问。

从用例角度，是否要判断里面数据对不对是要根据被测服务逻辑决定的。但从框架角度，这个功能有比没有好。

可以先看下用平台的项目一般接口返回要验证什么，然后再决定这个功能是不是一开始就需要具备，需要具备到什么程度？（最简单可以直接一个是否包含特定字符串，写到 excel 里最后一列就行了；复杂的可以做到允许自定义函数进行断言）

个人感觉，json 和 yaml 差不多。
yaml 好处是不用管括号匹配，但容易踩缩进符号不对导致匹配层级错误的坑，要用合适的编辑器。

如果是比较多人协作的话，可以考虑直接用数据库，也方便后续直接平台化。

并不会呀。

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

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

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

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

感觉这类问题，一般面试官比较喜欢的答案可能是你在原来平台由于平台限制没法得到更大的挑战或者提高技术深度，所以想来鹅厂接触千万日活级别的大型项目，迎接更大的挑战，得到更大的提升。这样可以体现你的进取心，体现你原来有一定的底子。

用 学习大厂先进的技术以及测试理论 这个说法，有可能会被面试官理解为你水平不高，需要团队花精力去教，培养成本高。社招大部分情况下希望找的是能立马干活的，水平至少达到团队平均水平以上的，而不是还要慢慢教的。所以 学习 这个词尽量慎用，容易让人感觉你水平不高。

个人理解，非 java 项目就没 jvm 什么事？

jvm 是 java 的虚拟机，所有 java 程序都是在 jvm 里运行的。非 java 程序就没有涉及 jvm 。

这个思路挺好的，特别是前期准备很重要。项目开始了不一定有太多时间再给你去做准备。

最近在看高楼老师的极客时间专栏学习，感觉完全刷新了我对服务端性能测试的理解。

PS：FGC 次数过多，也有可能是配置的内存不够，导致普通 gc 清理不出足够的内存。也可以结合看看服务配置的 jvm 启动参数，里面各种内存分配了多少，实际使用中占用率达到多高。

去看看里面的漏洞描述，然后根据描述里的利用方法尝试下，看是否还可以利用？

个人感觉，最好还是直接用类似的漏洞扫描工具再扫一遍，最简单快捷。

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

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

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

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

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

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

也分享一下我日常写代码的大概过程，可能会更偏向于怎么让代码可读性更高，或者说怎么更清晰展示自己的逻辑思路，供参考。

1、先明确这个程序要做什么，怎么做。画个时序图啥的记录下来。一般这个时候就大概知道要分几步，每一步做什么了。然后可以根据这个时序图，一个泳道一个类/函数来拆分。
2、根据时序图拆分比较大的函数，然后代码里写上函数名字和函数文档（类似 javadoc ，按照语言规范可以自动生成文档的，idea 会自动补全，写起来不用太特意去留意格式）
3、对每个函数，写出其中会涉及逻辑的部分，比如 for 循环、if else 这些。但要留意，只写展示思路脉络的一层，很多细节（比如接口请求的具体入参啥的）先拿个函数名或者注释占着。类似伪代码先展示思路。
4、把上一步那些占位的细节补充上，补充方法可以直接写实现（实现简单且没有多处使用），或者抽离一个私有函数（实现比较复杂，里面也有不少 for 或者 if ，或者会有多处用到）。

总体上有点像写文章，先写大纲，确认大纲没问题，再细化各个章节内容。这样写的时候，每次思考的上下文会是有限范围内的内容，不会从头理到尾导致捡了芝麻丢了西瓜，函数本身也比较短小，注释相对也全（第 1、2、3 步都有各种注释或者图示），比较容易读懂。
至于调通，只要思路没大问题，调通不会太花时间。

最近比较忙。。。

要不你试试根据 appium server 打印的日志，看看 appium 究竟在做什么，然后根据日志找到对应组件源码看看？可以分享下你看的结果以及疑惑点，我帮你补漏一下。

思路不错，在测试阶段就相对靠谱地找到慢查询 sql 并解决掉，加精让更多人看到。

找中厂，或者二线大厂？