直接用飞书文档之类的吧。把需求文档、技术方案文档等全部都在上面编辑和记录。可以按需搜索,历史更改记录也很清晰。而且支持画板,流程图、时序图啥的都可以直接在上面记录。
同时也建议维护一份核心功能回归的用例,让新人进来都跑一遍,借这个用例对整体系统功能有个了解,也方便后面快速参与整体版本回归。
试了下,确实可以复现,感谢反馈。
@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 楼的说明吧。
用例是否需要考虑,核心是看你们的项目对越权这块的容忍度。如果这个越权漏洞你能证明可以造成很大的问题(比如删掉某些实际这个用户没有权限删除的内容),我觉得可以把案例摆出来,大家一起决策是否需要修复,然后再进一步扩展到同类型问题,是否要处理。
大部分情况下,服务端也是要做限制的,要不纯前端限制,绕过成本很低,会导致一些越权的安全风险。
不过这个还是看实际业务情况。如果是内部业务,外部不可能入侵,不做的风险倒还好。
建议和研发确认下,这个多端背后的技术方案是啥,看确实是每个端代码都完全独立,还是用类似 Electron 的技术,一套逻辑代码,打包成多平台应用。
如果是完全独立,只能老老实实去测试,因为代码之间相互独立。
如果是有相互复用的,可以看哪些部分复用,复用部分只需要过一下 P0 功能确认没问题就行,不用过太细。重点关注兼容性方面有没有问题(如唤起相机这类调用平台 api 实现的,以及不同屏幕大小下的适配)
按我个人理解,https 请求的安全性,核心在证书。内容如果发生了篡改,在没有官方私钥的情况下,是必须改证书才重新加密请求内容。
如果客户端没有进行 https 证书强校验,仅按照系统默认配置来进行证书有效性验证,有可能会出现中间人让系统信任自己的自定义证书后,进行请求篡改的。
以前发帖多的人工作越来越忙,没那么多时间发帖了吧。