如何评估哪些点子是合适的？
现在经常遇到 AI 给的方案，判断不了是否符合业务场景，总结了一下，菜是原罪，结果就是充钱用更强的模型。

好强。

AI 自动化太费 token 没做起来，一部分通过工程化解决降低 token 使用就好。
或者是分级使用不同的厂商 token。

20 年的时候，卷 web 开发，测试平台。
25 年的时候，卷 prompt，mcp，agent。
赶上就赶上了，也可以不搞。

自动化仅仅是一个思想这个逻辑没问题
例如
市面上的 RPA 工具就是一个自动化工具，那对应的工作内容，测试人员完全可以自己写代码实现。
或者 RPA 工具开发岗，测试人员也可以平替过去。

有技术能力干啥不行，非得框死在点点点里？

纯净的手工，多适合研究技术。
全是逻辑类，没有技术视角是写不出来的。
不妨去去研究业务实现的技术，将业务逻辑和实现逻辑对比写用例？

之前来公司宣传过，实际使用下来不如 playwright 的 codegen 功能。

跟贴

影刀蛮好用的

《全程软件测试》

这个寺庙牌匾很有意思，进庙的时候提示你入地三摩，拜一圈请一堆东西出门告诉你莫向外求。

钉钉的 AI 助理有一个智能问数功能，你可以做好数据集然后 AI 帮你做图标，分析过程和指导结果这些（前提是你的数据集比较规范）

来源于 KIMI：
根据提供的《测试用例编写建议》文档，我将按照模板编写 20 条测试用例。为了简化，我将选择一个假设的电子商务网站作为测试对象，并针对其购物车功能进行测试用例的编写。

用例编号：SC.1.1.1

• 功能点：添加商品到购物车
• 用例级别：高
• 标题概述：测试用户能否将商品成功添加到购物车
• 前置条件：用户已登录，商品页面已打开
• 用例步骤：
  1. 用户点击 “添加到购物车” 按钮
• 输入数据：无
• 预期结果：商品被添加到购物车，页面显示 “商品已添加到购物车”
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-001
• 用例编写者：张三
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.2

• 功能点：添加商品到购物车
• 用例级别：高
• 标题概述：测试用户添加商品到购物车时输入数量是否正确
• 前置条件：用户已登录，商品页面已打开
• 用例步骤：
  1. 用户输入数量 “1”
  2. 用户点击 “添加到购物车” 按钮
• 输入数据：数量 “1”
• 预期结果：商品数量为 1 被添加到购物车
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-002
• 用例编写者：李四
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.3

• 功能点：删除购物车中的商品
• 用例级别：高
• 标题概述：测试用户能否从购物车中删除商品
• 前置条件：用户已登录，商品已添加到购物车
• 用例步骤：
  1. 用户点击购物车中商品的 “删除” 按钮
• 输入数据：无
• 预期结果：商品从购物车中消失，页面更新显示剩余商品
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-003
• 用例编写者：王五
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.4

• 功能点：修改购物车中的商品数量
• 用例级别：高
• 标题概述：测试用户能否修改购物车中商品的数量
• 前置条件：用户已登录，商品已添加到购物车
• 用例步骤：
  1. 用户在购物车中输入新的数量 “2”
• 输入数据：数量 “2”
• 预期结果：商品数量更新为 2，总价相应变化
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-004
• 用例编写者：赵六
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.5

• 功能点：购物车商品数量限制
• 用例级别：中
• 标题概述：测试用户输入超过库存的商品数量是否被限制
• 前置条件：用户已登录，商品页面已打开
• 用例步骤：
  1. 用户输入超过库存的商品数量 “100”
  2. 用户点击 “添加到购物车” 按钮
• 输入数据：数量 “100”
• 预期结果：系统提示 “库存不足”，不允许添加超过库存的商品
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-005
• 用例编写者：孙七
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.6

• 功能点：购物车商品为空
• 用例级别：低
• 标题概述：测试用户清空购物车后的行为
• 前置条件：用户已登录，商品已添加到购物车
• 用例步骤：
  1. 用户点击 “清空购物车” 按钮
• 输入数据：无
• 预期结果：购物车显示为空，页面提示 “购物车已清空”
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-006
• 用例编写者：周八
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.7

• 功能点：购物车商品数量为零
• 用例级别：中
• 标题概述：测试用户将购物车中商品数量减至零的行为
• 前置条件：用户已登录，商品已添加到购物车
• 用例步骤：
  1. 用户在购物车中将商品数量减至 “0”
• 输入数据：数量 “0”
• 预期结果：商品从购物车中消失，页面更新显示剩余商品
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-007
• 用例编写者：吴九
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.8

• 功能点：购物车商品价格更新
• 用例级别：中
• 标题概述：测试购物车中商品价格更新后的行为
• 前置条件：用户已登录，商品已添加到购物车
• 用例步骤：
  1. 管理员更新商品价格
  2. 用户刷新购物车页面
• 输入数据：无
• 预期结果：购物车中商品价格更新为最新价格
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-008
• 用例编写者：郑十
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.9

• 功能点：购物车商品库存更新
• 用例级别：中
• 标题概述：测试购物车中商品库存更新后的行为
• 前置条件：用户已登录，商品已添加到购物车
• 用例步骤：
  1. 管理员更新商品库存
  2. 用户刷新购物车页面
• 输入数据：无
• 预期结果：购物车中商品库存更新为最新库存
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-009
• 用例编写者：王十一
• 测试执行者：
• 执行日期：
• 备注：

用例编号：SC.1.1.10

• 功能点：购物车商品限购
• 用例级别：中
• 标题概述：测试用户尝试购买超过限购数量的商品
• 前置条件：用户已登录，商品页面已打开
• 用例步骤：
  1. 用户输入超过限购数量 “5”
  2. 用户点击 “添加到购物车” 按钮
• 输入数据：数量 “6”
• 预期结果：系统提示 “超过限购数量”，不允许添加超过限购的商品
• 实际结果：
• 问题描述：
• 执行结果：
• Bug 编号：
• 需求编号：REQ-010
• 用例编写者：冯十二
• 测试执行者：
• 执行日期：
• 备注：

由于篇幅限制，这里只提供了 10 条测试用例。如果需要更多的测试用例，可以按照上述模板继续编写。每条用例都应详细描述测试的各个方面，包括前置条件、测试步骤、输入数据、预期结果等，以确保测试的全面性和准确性。

jemeter 错别字？

web，app 纯业务的，参考经验不大的，面试突击/工作突击来得及的。
偏硬件的方向，可是得靠实实在在硬件工作来堆的，串口，私有协议这些，没点基础还真搞不定。
自己搞个树莓派，或者 stm32 板子，micropython 嵌入式搞起来，社区不是有大佬分享 Python 做家居智能方案么？很好的一个方向，比纯软好多的

github

erupt 好用的，去年看社区有推荐这个，真开箱即用

好东西，收藏一波

如果发生线上问题，不第一时间找 QA，这样对你的现状会更好么？不会更好吧
BUG 没防住，就追根因，出报告，做预防。

有没有可能是普遍都是 crud 的内容，不需要讨论了，超出一点的内容都有自己的小圈子

得看你们产品的实现方式，设备是只做消息收发，执行动作，还是要做业务处理。
正常情况下业务逻辑全在后台，app 和设备只是做消息收发而已，这样的话固件测试一个人，app 和后台可以并在一起测试。
如果设备端也做业务处理，那具体情况具体分析了

reqable，试试看