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

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

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 并解决掉，加精让更多人看到。

找中厂，或者二线大厂？

看起来是前端问题，已记录 Issue ：https://github.com/testerhome/homeland/issues/130
浏览器的返回既不是完全刷新，也不是单纯 js 触发事件引起的变化，真是个神奇的状态。。。

你这个举例和入参出参说明，还是很不清晰呀。。。

举例应该是明确给出入参长什么样的时候，出参要长什么样。你的举例只是业务逻辑说明，不是真正的例子。建议去看看 leetcode 的例子吧。

另外，从你这个逻辑上，我理解的大概伪代码：

def get_common_data(datas):
    for data in datas:
        if (data.hasKey('level') and data['level']) == 2:
            # 二级分类多加一个获取 parentId 的函数，然后把 parentId set 回 data 里面
        add_data(data)

def add_data(data):
    # 这里写具体怎么 add data 的逻辑

你代码的主要问题是，一下子把太多细节展开了，而且命名也不大好，有些没有业务含义的工具类函数命名（如get_data_from_rex），所以容易看懵逼，也容易出现各种 KeyError、数组越界之类的问题。

建议可以仿照上面写的伪代码，抽离一部分细节，主要的函数只体现业务逻辑，具体细节放到别的函数里。

额，既然这是一个函数，你的需求描述是不是应该参照 leecode ，说明入参格式，出参要求，然后举个例子？

光看这段代码，不知道你入参出参的信息，代码里也没有注释说明正在做的业务逻辑是什么，没法给意见。只能说代码好长，可读性比较差。

不客气。

建议后面还是多留意下报错信息吧，我说的这些其实都是报错信息上就有的内容，只是翻译了一下。有些时候不一定遇到问题就直接百度的。

大家有想分享的议题，欢迎投递过来，让更多人看到呀~

我晚些抽空搞台 windows 试试吧，现在手上没有 windows 。。。

老大不是给答复你了么？所以纠结的点是？

提供一种思路，供参考：

1、“可以在平台上进行选择执行的项目和用例” ，核心需要的是项目列表和用例列表，以及控制本次执行的用例范围的能力。
项目列表——代码仓库搞一个组专门存自动化，项目列表直接就是这个组里面的仓库列表信息（可以直接用 gitlab 的 http 接口拿）？
用例列表——自动化框架里增加一个命令，可以执行后输出用例列表，并调用平台提供 http 接口进行上报。然后配合 gitlab push hook，每次 push 代码自动触发执行这个命令，把用例列表上报即可
控制本次执行的用例范围——pytest 命令行好像本身就有这方面能力，建议可以看看 pytest 的文档

具体执行还是用 Jenkins 其实就可以，可以通过 http 接口调用 jenkins 触发 job 执行。这样可以暂时先不花太多时间在这个你们不大熟悉的领域。

2、“可以看到各个项目的执行结果和方便做统计”，不知道你这里执行结果是什么粒度，姑且先认为是用例级别。那核心需要的是获取各项目每次执行结果数据的能力。统计属于数据到手后纯平台自己写各种 sql 做的事情了，为了能随心所欲地做统计，最好还是数据都存到平台数据库里。
获取各项目每次执行结果数据——类似上面用例列表思路，自动化框架里通过 listener 之类的监听器，每个用例执行完毕后，都调用平台的某个接口上报此次用例执行结果信息。

在平台里面维护整个自动化测试的状态并提供界面查看，从你描述里不是目前平台的核心能力，而且做起来对你来说应该也是技术难点。本着 “能复用现有设施尽量复用” 的原则，减少工作量，所以建议初期平台尽量轻量级，只做最重要的功能，对你们来说工作量也相对较少。后续有需要，再单独把 jenkins 做的事情搬到平台上也是可以的。

你用的 mac 还是 windows ?

报错信息是说没有找到 xcode ，而且看你配置有勾选了 usePrebuildWDA ，不知道是不是这个会导致 appium 自己去找 xcode 相关信息。

看了下，weditor 是 atx 提供的用来获取界面元素信息，便于编写 UI 自动化中元素定位相关语句的工具。

目前主流的自动化，从如何编写脚本角度，会提供两种方式
一种是录制生成代码，比如 solopi 、appium desktop 都可以通过用户操作直接自动生成对应自动化代码。直接用这个生成出来的代码来执行，成功率一般也还好。
另二种是直接编写代码，比如使用 Page Object 模式定义各个页面及页面元素，然后用例里去操作这些页面元素进行自动化。好处是维护成本相对较低（重复的东西都会抽离封装），并且后面会越写越快（可以复用已有的代码），缺点是从零开始写用例来算，相比第一种写起来耗时会多一些。

看你提到 相当花时间 ，个人理解你应该是在使用第二种方法。但觉得用起来比较耗时。建议你可以也试试第一种方法？

另外，建议刚开始先不要弄太多用例，把最重要的用例做出来就好了。自动化耗时的大头不是编写，而是后续不断调优让它更快更稳定。

第一个警告，是说你项目里的 Pipfile（定义 pipenv 环境用的）要求用 python 3.7 ，但你实际用的是 3.8 。这只是一个 warning ，有可能是因为你创建项目的 Pipfile 时使用的环境刚好是 3.7，所以自动记录了 3.7。实际应该不影响程序运行。

比较合适的解决方案是手动改下 Pipfile 里 python version 的限制，改为要求大于某个版本，而不是必须等于某个版本。不过这个只是一个警告，应该不至于影响你程序实际运行。

至于第二个，是直接报错，你的某个依赖包里要求 importlib-metadata 这个依赖包版本要 >=0.12， <3 ，而你的实际安装版本是 3.7.3 ，超出范围，所以报错。

解决方法，可以试试卸载掉已有的 importlib-metadata 再运行 pipenv install pytest requests ，让它自动获取正确版本的依赖。不过考虑到你用 pipenv ，安装依赖时使用的应该是纯净环境，还有可能是 2 个依赖包同时依赖了 importlib-metadata 且要求版本不一致。如果用上面的卸载重装无效，得查下是哪两个依赖同时依赖了这个包，然后看怎么调整这两个程序依赖的版本来解决这个问题

挺不错的实践，也是换种思路看自动化测试。加个精给更多同学看到

感觉有点复杂了。这种自定义语法除非很好记，否则会严重影响可读性且容易留坑。比如上面这个格式，没有考虑转义这个场景，如果用户刚好要定义的是 api?a=1&b=2&c=4 ，这里的 &b=2& 是不是有可能会被正则匹配到然后替换？

如果确实要引入函数语法，个人建议参考 Jmeter 或者 RobotFramework 的语法来，相对好记和容易识别。

个人理解，提升代码能力是手段，是否有想过你最终的目标是要做什么吗？

如果是把自动化测试做好，建议看看目前接口自动化还有什么不足，怎么优化。过程中各种疑难杂症的排查解决，应该能附带帮助你提高一些代码能力，特别是相对深入一些的能力。

如果是做工具平台开发，那就先想好要做什么平台，然后对应调研、选型、开干、落地。

单纯用 提升代码能力 作为目标，容易只是把这个语言的文档都看一遍，示例都敲一遍，但实际工作怎么用还是一头雾水，不产生价值。这样的代码能力去到面试，也容易被面试官问倒，甚至手写代码题直接卡住，记不住常用函数名字和用法。

PS：代码能力还有一个很重要的用处，阅读开发代码熟悉具体技术细节。也可以考虑从这个方面去实践。

查了下，MultiValueDictKeyError 异常是因为要获取的 key 不存在才出现的。但看你前端发送请求的内容，有明确设定 ts_api_body 的内容，不应该有这个报错。

是不是这个点击按钮事件还绑定了别的操作，触发了二次请求，但请求里没有带上 ts_api_body ？

报错的 appium 服务日志，上下 10 行可以一起贴上来不？

要看看 appium 为啥要调这个，才能知道是不是可以通过别的配置或者改源码的哪里去绕过。