self.url 是个 None，path 是个 str，那自然无法用 + 操作符链接。

问题原因：self.url 为空，根本就没有初始化，代码 bug

该走就走，消耗自己的时间就是对自己不负责，考虑一下我们团队呗：https://testerhome.com/topics/31151

先回答楼主原先的疑问：

Python 不足以支持问题排查时，Java 要学习到什么程度，才能进行接口调式和问题排查，能够看的懂代码

如果只是常规的 web 前后端代码，如果要读懂并且能调试（先不说要自己实现编码吧），其实难度一般，Java 基本语法熟悉了，业务使用的框架（一般也就是 spring 全家桶吧）的一些基本用法，或者业务实现中你看到的用法都了解了，这个程度就够了。

其实不需要你对框架、对 Java 底层有多少了解，那些都是唬人的，就好比你要玩游戏玩得很厉害并不需要你去自己开发游戏一个道理。编程语言、框架都是工具，用法知道了，如果只是实现常规需求，其实大多数是熟练度的问题，深入编程语言虚拟机、框架原理什么的，只是追求更极致更优雅的编码实现。所以不要给自己设限，把它假想得很可怕。

来自一个 Java 大佬的嘲讽：我们之前有个测试，是会调式前后端代码的，直接告诉我们哪里写错了，这样就能很快解决问题

不少同学对这个开发都是负面态度，不评价这个开发的观点。既然开发不排斥你去调试他们的代码，那你就上呗（以前我对接的业务是公司的安全业务，很多代码权限都不给测试开的，我想看都没得看）。

web 后端代码本身阅读理解难度就低，逻辑清晰，多数就跟你在 web 前端操作获得的直接反馈很接近，调试也方便。这是一个学习机会，也是一个增加个人影响力的机会，可遇不可求。如果不是常规 web 后端，而是一些服务后端，也是一样，就自己多花些心思啃一啃就好了。

3 楼恒捷的观点表示认可，首先需要明确到底是什么原因导致 元素动态的变化，写出来的测试脚本不稳定 ，如果这个点没调研清楚，那上面的想法不能否认没有价值，只能说有点自嗨。

另外，NLP 将人工用例转化为代码用例这一 part 是最不靠谱的，要实现这一点的前提是用例格式是统一规范的（要推动全部人遵循规范，这个成本已经劝退了），否则我觉得 NLP 再牛逼都实现不了。

所以很多时候，大家的思路更多是从降低 编写 o 或维护用例的成本 出发来做这个事，比如做一个用例编写的 ide，支持通过 UI 点击拖拽的方式快速编写用例、或者有更好的用例工程代码封装来达到最大复用等

学习学习~

本帖持续有效嗷！！！

是的是的，这个业务讲解，一般我会讲这么些内容：

1. 团队定位，本团队负责范围，合作团队工作，双方的工作边界 —— 让新人明白为什么要做这些工作
2. 团队所有的方向，新人会接触的到子方向工作总览，以及直接接触的子工作 —— 让新人明白做的是什么工作

以上时间大概 55 开，都很重要，但是不要陷入太多细节，要把主链路呈现清楚，不分散新人的注意力

目前待过 4 名新人（社招校招均有），简单分享我的经验。

• 入职第一天的业务讲解：这个是最重要的手段，重点是如何在一个新人面前将整体业务的逻辑讲清楚，需要考量新人的背景知识是否适合，讲解粒度是否要调整，很考验导师的水平（如果讲完新人不懂，我觉得是讲解人的表达总结水平问题）
• 文档：文档以简明有重点为主，细节充足是好事，但是要能保证维护更新
• 定期 1v1：前两个月每周或者每双周要 1v1 一次，这个 1v1 学问非常大，并不是找个时间让你去给新人洗脑，而是要真实关心新人的状态。1v1 要让新人来主导，让 ta 提问题你来回答或者解决。可以从【工作遇到的挑战、工作的成就来源、团队沟通合作、工作内容感受】等不同维度引导。里面有非常多的技巧性，个人水平有限也在持续摸索
• 培训：大厂一般会有强制观看内部录制课程的机制，如果公司没有这样的机制那就只能看个人了，导师可以自行收集一些外网视频或分享会等资料，打包提供给新人，并建立简单的学习复核考察机制

上面这些点，作用最大的是首日业务讲解，细水长流靠的是定期 1v1 和适当的文档。

我接触的 UI 自动化还停留在传统的 PO 封装上，看完此文后不知道我下面的表述是否正确：

1. 组件层：这层基本上都是控件定位的封装，简单来说可能是各种 find、locate elements 等控件定位获取的操作？
2. 页面层：基于组件层对所有控件定位的封装，在这一层就是把相同页面的控件整合在一起呈现一个页面的类，看起来似乎很薄？
3. 业务逻辑层：这一层比较好理解，一个或多个页面上有业务一样的操作，比如账号登录是一个业务逻辑（当然也能说是一个用例，这里举例可能不够合适），在这一层给封装起来
4. 用例层：很好理解，如果按照这样的模式，写用例基本就是调函数了

同样没了解过，尝试猜测一下。
首先大型游戏肯定都是模块化开发的，各个组件（物理、光照、）最开始肯定都是单独的测试，可能是单测、接口测试、宿主 demo 测试，个人感觉跟 sdk 的测试方法可能比较接近。
当模块化的组件确保没有问题，开始组合成场景（不同的场景由同样的组件集合来组装，就是等价类的概念），场景中插入一些任务，这里的 “任务” 概念我理解就是业务逻辑，这个时候相当于是集成测试环节。一个 3A 游戏虽然复杂（剧情、玩法、各种要素、各种场景等），但从游戏迭代的角度来说还是应该高度自动化的（游戏 bugfix 补丁也可以去跑）。而集成测试，可能会有部分专业的人做探索测试，更多工作可能是给到外包团队低成本铺人去点点点。

如楼上所说方案，我们目前也是用方案三，自己买主机挂载手机，同时连在办公网（wifi）下，而不是放在 idc 机房。
idc 机房可能会跟办公网隔离，不同公司规章制度不一样。

长见识了…… 真不知道还会有这种坑

按照线上页面的 PV、UV 排个序，首先最高的页面下几个最高的场景肯定是要做的，然后 QA、RD、PM 内部商讨，剩余长尾页面哪些要额外补充 UI 自动化

举个例子，比如说你的增量调用链最后是 B->C->D，你通过覆盖率拿到你测试后的调用链是 A->B->C->D->E->F ，这样不就能理解你的的测试已经覆盖了你的增量链路么？ 也就是判断子集的操作

同楼上
问题一：直觉上就是发压机的配置跟不上，如果你是用 PC 机发压，这个可能就更大了。建议关注一下发压机的配置，以及发压机在发压时候的资源占用情况。

问题二：可以先盘点一下，部署在两台不同的机器上会有什么差异

• 环境：机器配置（是否有一台的配置特别拉胯）、环境变量、
• 网络：不在一个局域网，是否距离比较远如异地机器
• 其他……（甚至可能是你在单台部署和两台部署时，没有控制好变量出现的差异）

问题三：具体要看业务逻辑实现，对于 “校验客户密码” 这种接口，应该是每次都要查询数据库，合理的代码实现不应该使用缓存

1. 我理解去不了所谓的【无关调用】，你想在静态分析技术中处理动态运行存在的问题，看着有点玄幻。要不就是你本身已经具备先验知识，比如你事先知道要关注的调用链上游会包含什么因素，那你就只关注这条子调用链即可，其他的不管。
2. 要判断【这条调用链有覆盖】，换个说法就是判断【覆盖路径 是否包含 调用链】，也就是调用链是覆盖链路的子集。具体怎么搞，那就看你的数据格式是怎么样的。

继续在这种地方呆着不走，除非你有什么难言之隐，不然就是对自己的未来不负责

我理解是一样的道理，算法在 monkey 上的作用就是决策下一步要点击哪个空间获得的 “收益” 更大，还是有可能直接给点 “返回按钮”。
我表达的意思是，这个手段在使用细节上还是有很多测试策略需要考虑的

我们内部有实现了一套差不多的玩意，我们管这叫 scheme 定向测试，只是说，可能定向过去的是一个原生页面、前端页面、内部其他技术制造的页面等。

其实有弊端：

1. 并非所有页面都能这样跳转，需要页面自身支持这样跳转才行。
2. 跳转本身所携带的参数是你在收集那一刻就被写死的，它缺少了动态的变化，跳转过去遍历测试一样会存在覆盖的死角。

不过还是有很多场景可以应用这种测试方式的，比如提高测试覆盖率、线下问题复现压测、某些特殊场景的定向测试。

如果要结合遍历测试来做，还需要预防跳转过去后，monkey 给你点到回退到其他页面了。

我觉得吧，能把大学那些数学课先捡起来（尤其是工作多年之后），就已经不是一件特别轻松的事情。

如果真的很轻松，要不就是天赋过人，要不就是基础确实稳扎稳打，要不就是学了点套路当调参侠自嗨

offer 中也有薪资开的比较高,越是工作年限比较久,越要知道下一份工作能得到什么,尤其在当下互联网环境,很难找到完美得工作,但是可以找到适合的自己工作.

表示这一点非常赞同，一定要看准赛道跳进去，跳进去之前又要充分考察这个公司、团队、岗位是否适合自己发挥。到这种时候 base 上差个两三 k 已经不是什么需要关注的问题了，主要还是考虑未来继续发展的空间。

对的，其实压测本来就是有两种目的，视不同场景：

• 目的一：要上一个活动，这个活动从产品侧估计会有 N 人参与，所以某些接口必须要能支持这种程度的压力，这种就是在上线前就有明确的压力预期（一般是 8/2 原则来评估），压测的主要目标是 check 接口能否达到这个预期
• 目的二：要上一个新功能，这个功能大家都不知道会有多少人用，是个船新的东西。这时需要旁敲侧击，比如有无类似的接口可以拿数据来参考，或者有个保底的用户人数，这时候压测的主要目标是看这个接口能承受的极限压力，先让大家知道这个接口能扛得住多少多少，然后在来评估是否合适上线

压测我以前做过一个总结，可以看我的博客做个参考。

如果产品不明白，那还是得耐心解释给他们听，其实这也是你在研发和产品之间制造自己影响力的机会，让大家觉得你知道得很多决策经常正确，那是一件好事。

所谓的熟练掌握 python，一般只需要系统把 python 学一次就够了，要求就是一个普通的想法能用 python 这个工具正确实现表达出来即可。并不会强制你掌握那种 blingbling 的、很 pythonic 的、很奇技淫巧的实现方式。

其实不仅仅是 python，对所有的编程语言都是一样，它们都只是我们的编程工具，只是说你追究到库源码实现、编译器虚拟机实现层面上，在某些特定场景下能帮助你解决问题和优化代码。单纯从测试开发的岗位来说，除非个人爱好或者工作面试需求，不然也不是非得到那种深度。

当然，多看别人的代码，尤其是高效优美的代码（github 高 star 项目），对自己还是非常有帮助的。

mark，这个周末拉到家里的电脑认真阅读一下源码~ 看看能不能给找几个 bug hhhhhhh