1、编程语言里的数据类型要转换为 json，有一个叫 序列化 的过程。这个过程会把变成语言里的数据类型，按照一定规则转为 json 里的数据类型。python 里一般用自带的 json 库进行序列化（具体要看你们研发的代码）。

这个库的 python 转 json 的转换规则如下：https://docs.python.org/3/library/json.html

2、按照上面规则，turple 应该转为了 json 的 array，而你的接口规定的参数类型是 string，自然对不上

3、覆盖的时候，覆盖 json 支持的格式就好。甚至有些场景下，没太大必要做这个测试，因为各个语言的反序列化其实是有一定的兼容性的，比如 json 传了 string 类型的"3"，语言中对应的类型是 int，会尽量转为 int。这部分转换是各个库自动完成的，开发压根不用写代码，风险也低。所以在做参数覆盖的时候，相比单纯从技术层面去设计，更建议从业务层面去设计。业务层面的才是研发要写代码实现的，也是风险更高的。

如果不打算做任何和代码沾边的事情（如自动化、提效脚本编写等），也不想和开发交流时让对方觉得你懂行，确实没啥用。

自住非投资的，就别看房价涨跌了。涨了你又不会卖，跌了你也不会买，何必为此影响心情？

另外，自住的房子，属于负债，不属于资产，和自用的车没啥区别（不具备涨了后随时出售赚取收益的属性）。好好享受下房子带来的便利和安定感就好了。

直接用飞书文档之类的吧。把需求文档、技术方案文档等全部都在上面编辑和记录。可以按需搜索，历史更改记录也很清晰。而且支持画板，流程图、时序图啥的都可以直接在上面记录。

同时也建议维护一份核心功能回归的用例，让新人进来都跑一遍，借这个用例对整体系统功能有个了解，也方便后面快速参与整体版本回归。

试了下，确实可以复现，感谢反馈。

@Lihuazhang 有时间看下这个问题么？

只是提了 MR。官方对于这个 diff 处理最终采用的是基于实时数据更新的解决方案（类似飞书文档那种），所以最终没有合并进去。

这里的 input_text 是实例方法，必须是在实例化后的对象才能调用。例如：

handler = BaseHandler()
handler.input_text(element, text)

只有类方法或静态方法，才能用 BaseHandler.input_text() 这种写法。

详细建议看看 https://zhuanlan.zhihu.com/p/40162669

我看你截图，两个截图里展示的内容都不大一样，第二个多了个弹窗。

从我历史经验，有 2 种可能：
1、sleep 时间不够长。session.page_source 语句的执行是比较耗时的（一般几秒左右，复杂页面时间更长），相当于再 sleep 了几秒。你看下加长 sleep，去掉 print，是否可以解决？
2、webview 内部元素要通过调用 page_source 强制遍历一遍，才会出现在控件树中（猜测）。可以试试不加 page_source 和加 page_source ，看加的话是不是稳定成功，不加的话是不是稳定失败。

现在这情况，不建议继续跳，要不简历更差，后面更难。

先干着吧，过程中熟悉一下公司情况，看后面是否有发展起来的机会，没有的话再骑驴找马地找。

主要看能力，我这边业务有不少 35+ 的同事，目前招聘也没有强卡年限。

去年换到字节了

字节广州有兴趣么？我这也还在招。

今年我也满 10 年了，握个爪

不知道咋分的话，先别分是最佳选择。要不很容易过度设计，还不如不设计

可以把质量保障领域相关的，也汇总一份么？

这个话很戳心，但很真实。

我看了下后台账号信息，你的权限应该是 ok 的。

可以把你发帖时的一些错误提示贴上来吗？我们针对性排查下。

学习了。

建议可以的话，缓存下 element。每次都去 find 的话，会导致每次都要遍历控件树，无法使用缓存。

app 端控件树遍历不像 web 端，得递归整个控件树才能生成。如果界面复杂，这个递归会比较耗时。

最基本的就是人工测试，设计用例 + 点点点
设计用例提效部分可以 ai 辅助，人工复查
点点点今年 gpt 发布会演示这个功能，未来可以关注试试

这篇总结得挺全的，可以参考下：
https://testerhome.com/topics/37479

赞同 1 楼的，我觉得 AI 自行研发 + 测试人工验证的合作模型会是更可行，或者说离我们更近的。

其实我们为啥一直要想着被取代呢，学习下把大模型技术用起来，成为自己的助手，让自己人效更高也帮助自己更熟悉大模型技术，不是更好吗？

可以监听 minder 的事件来获取。

示例：

minder.on && minder.on('interactchange', function() {
          self.selectedNodeCount = minder.getSelectedNodes().length
          if (self.selectedNodeCount === 1) {
            self.selectedNodeText = minder.getSelectedNodes()[0].data.text
          } else {
            self.selectedNodeText = ''
          }
        });

至于具体有哪些事件，可以源码里搜索下，我也有点不大记得了。

这个我觉得你参考 8 楼的说明吧。

用例是否需要考虑，核心是看你们的项目对越权这块的容忍度。如果这个越权漏洞你能证明可以造成很大的问题（比如删掉某些实际这个用户没有权限删除的内容），我觉得可以把案例摆出来，大家一起决策是否需要修复，然后再进一步扩展到同类型问题，是否要处理。

大部分情况下，服务端也是要做限制的，要不纯前端限制，绕过成本很低，会导致一些越权的安全风险。

不过这个还是看实际业务情况。如果是内部业务，外部不可能入侵，不做的风险倒还好。