用下面的 adb 滑动方法试试
def adb_swipe_up(
start_x_percent=0.5,
start_y_percent=0.7,
end_x_percent=0.5,
end_y_percent=0.3,
duration=300,
max_attempts=3,
delay=1,
):
"""使用 ADB 命令执行上滑操作,支持自定义滑动参数和重试机制
该函数提供以下功能:
1. 支持通过百分比设置滑动起始和终点位置
2. 自动获取设备屏幕尺寸并计算实际坐标
3. 可配置滑动持续时间
4. 内置重试机制,处理滑动失败的情况
Args:
start_x_percent (float): 起始点 x 坐标在屏幕宽度上的百分比,默认 0.5(屏幕中间)
start_y_percent (float): 起始点 y 坐标在屏幕高度上的百分比,默认 0.7(屏幕偏下位置)
end_x_percent (float): 终点 x 坐标在屏幕宽度上的百分比,默认 0.5(屏幕中间)
end_y_percent (float): 终点 y 坐标在屏幕高度上的百分比,默认 0.3(屏幕偏上位置)
duration (int): 滑动持续时间(毫秒),默认 300ms
max_attempts (int): 最大重试次数,默认 3 次
delay (int): 重试间隔时间,默认 1 秒
Returns:
bool: 滑动操作是否成功。成功返回 True,失败返回 False
"""
for attempt in range(max_attempts):
try:
# 获取屏幕尺寸
output = subprocess.check_output(["adb", "shell", "wm", "size"])
size_str = output.decode("utf-8").strip()
width, height = map(int, size_str.split(": ")[1].split("x"))
# 计算实际滑动坐标
start_x = int(width * start_x_percent)
start_y = int(height * start_y_percent)
end_x = int(width * end_x_percent)
end_y = int(height * end_y_percent)
print(
f"开始执行滑动操作:从 ({start_x}, {start_y}) 滑动到 ({end_x}, {end_y})"
)
# 执行滑动操作
try:
subprocess.run(
[
"adb",
"shell",
"input",
"swipe",
str(start_x),
str(start_y),
str(end_x),
str(end_y),
str(duration),
],
check=True,
)
time.sleep(0.5) # 等待滑动动画完成
print("滑动操作执行成功")
return True
except subprocess.CalledProcessError as swipe_error:
print(f"滑动操作执行失败: {swipe_error}")
except Exception as e:
print(f"第 {attempt + 1} 次滑动尝试失败: {e}")
time.sleep(delay)
return False
确保每个页面都被点击需要额外控制,点击频率可以统计 activity,工具的话可以搜一下,有工具可以直接用,但是无法保证每个页面都被点到,因为有些页面是需要特定条件才能点进去的,需要二次开发才行
问答机器人可以整理一下之前用户的反馈和问的问题当做数据进行测试,这个应该也是有个产品文档和分类的吧,按照需求来就行,还是要针对业务来测,我们不知道你们业务其实没有好的建议
不找同行,我们这行圈子不大,除非别人介绍
cursor 或者 trae 直接给你生成几个,选一个适合自己的就行,像 apifox 这种不需要写代码的工具不可以吗?用 python 写需要考虑后期成本和团队技术能力是否达标
apifox 了解一下
迭代快如果 UI 变化频繁,实施 UI 自动化测试的维护成本很高,所以不建议开始,如果 UI 和功能开始稳定了再实施,不过可以提前学习和设计框架,到时候机会一到可以直接开始,省去调研和学习的时间,框架和语言建议选择 Appium 和 Python。接口自动化测试可以看看 apifox,上手快
苏州和南京不考虑吗?
我们一直用的 boardmix,挺好用,并不贵,开发一套加维护成本不如直接买会员了,写用例的话数据安全应该不是很高,如果不在意数据安全或者是可以接受的范围内,买现成的最快,而且比自检的要好很多,当画板内容很多时,性能问题是个瓶颈
一般 toast 不会太快,2-3s 还有是有的,足够截图了,然后 OCR 识别文字进行断言,我们是这么做的
大厂镀镀金,有自己擅长的领域,比如自动化测试或者接口自动化,要那种去了新地方可以快速部署使用的程度
测试环境小程序可以让开发写死账号给你们选择就行,如果非要走微信 openid 逻辑就没什么好办法了,你们小程序和微信是通过 openid 关联的吗?
https://www.cnblogs.com/Im-Victor/p/17754051.html
中文支持最好的 6 款 OCR,推荐用前两种就可以,亲测好用
metersphere 毕竟需要部署,直接在线用免费版的 apifox 吧,也算接口自动化测试,postman 和 jmeter 也可以,别看不起小工具,至少门槛低能满足你的紧急需要
线上数据数据不能随便脚本操作,你是要修改或者删数据还是查数据,找运维或者开发吧,线上数据操作要慎重
VirtualXposed 安装这个然后打开,然后再试试抓包
AI 的话最好在公司内部署一套大模型,用网上的再好用,也会泄露公司隐私和内部资料以及代码的,不安全
我们之前也用,不过公司说用这个会将 code 上传到公网,有隐私问题,所以不能继续用了,建议慎重使用,除非自己公司搭建私有的工具
要能用技术手段解决业务测试中的难点,提高人效,也就是能通过技术手段做到降本增效
你这个是需要人工审核吧,轮询吧,其他没有很好的办法,硬等待不好
推荐一个工具 uiautodev,强烈推荐
如果多端页面逻辑和 UI 一样,可以一套用例多端共享,只需要把初始化过程和定位元素参数化出来就可以,我们就是这样做的,我们用的 Appium,主要是因为我们是 3 年前开始搞的,那时候 Airetest 没有 Appium 合适,现在可以俩对比着调研,看看哪个更合适自己的项目
BUG 数多并不一定能提现候选人的能力,因为有可能是你多花了更多的时间,或者是开发能力差,又或者是需求复杂等原因,面试要体现个人能力,这种 BUG 数多不一定是个人能力强