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

之前来公司宣传过，实际使用下来不如 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，试试看

试用过影刀，定位很强大，能降低定位的成本。单从定位来说，playwright 也够用的。
但是测试的业务逻辑，用例维护成本等，该那么多还是那么多的，看自己取舍。

官网，或者是 github 项目里的讨论，尤其是项目里的讨论，有很多有意思的场景和用法

第三方文档系统，然后上面做套壳

自动化框架有人用？测试平台有人用？代码覆盖率有项目落地？