我特怕这种题，根本想不全

来源于 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 条测试用例。如果需要更多的测试用例，可以按照上述模板继续编写。每条用例都应详细描述测试的各个方面，包括前置条件、测试步骤、输入数据、预期结果等，以确保测试的全面性和准确性。

有没有可能这种题是考验你的思考方式呢？ 我觉得可以从质量体系的 8 个方面去思考，这样反而容易体现你的专业性！

质量体系的 8 个方面是不是：功能性，可靠性，可维护性...啥的，但是这个说的都是功能性吧？

购物车这道题虽然已经是经典老题，但是其实考察是你的业务理解能力，当然也可能是面试官随便抽的。

你说的答案是测试方向，开测时都会分别从功能、UI、性能、安全这几个方向去归纳用例，
功能用例会用等价类划分、边界值、错误推断、场景法等去丰富和尽量覆盖。

所以比较关键的点就在于功能用例里的场景覆盖，我们首先从用户角度上去对购物车功能进行理解：

• 购物用户角度

  • 暂存有意向的商品
  • 方便组合计算商品价格
  • 不同券/活动促销类商品的归类
  • 降价提醒
  • 不同商家的商品价格比较

• 用户涉及的流程： 登录身份信息验证、点击购物车入口、购物车商品内容展示、购物车商品库存显示、购物车商品增删改查

结合用户角度和流程你就可以提取出大量测试用例了
如：

1.身份验证：帐号校验、未登录状态的购物车操作、登录后的信息同步、部分商品加购物车是否做用户分类限制

1. 购物车入口: H5/小程序/app/web 不同渠道的入口位置和交互视觉设计验证

2. 购物车内容展示：不同店铺/不同促销类型/不同地区/特殊商品等的归纳展示、赠品展示、价格文案字段展示

3. 库存显示：刷新机制、不同库存状态显示等

4. 增删改查：增删改查功能、商品排序逻辑、商品状态变换、对应的交互显示等等等

   ---

• 平台或者商家角度
  • 利用购物车进行数据统计
  • 利用购物车进行营销
  • 利用购物车提高客单价

感觉好多写不完，你可以查查对应的购物车设计文档，可以提取超多用例

商品下架后，购物车内如何显示

商品库存不足，购物车内如何显示

商品不同状态和库存的批量支付，热点商品批量支付抢购，抢购的时候有些订单主动取消和被动取消

在 2019 年面试的时候，就遇到了这题，当时也是自然就觉得这个题目就是考察如何设计用例。但是我回去好好考虑了一下，觉得可能不是这样的，因为面试官其实想问的和你想的可能并不一样，为了更好的回答问题，你应该反问，有没有前提条件，例如：我可不可以按照淘宝购物车来回答，有没有需求文档，测试环境是不是已经搭建了，等前提条件确认完成了，再去回答会不会好点。如果不想问，那就按照最稳妥的方式回答，从整个测试工作是如何开展的进行回答，用例设计只是其中的一点吧，答题思路：确定测试目标与策略 ------ 编写测试计划 ------ 设计测试用例设计 ------ 测试环境搭建 ------测试执行 ------ 测试报告 ------- 测试过程改进。如果中途面试官打断了，他肯定会强调自己这个问题到底在问你什么，假设真的是在考察用例设计是否考虑全面，那就直接回答用例设计相关的就好了

你这答了跟没答一样。我要是面试你这么回答，我已经给你扣很多分了。我看了第一点我就懵了，什么叫 “1、校验：添加商品到购物车是否正常”？你要这么测，有几个因素，一是数量因素，一是物品因素。然后再根据现在主流的前后分离思想。首先数量，你添加 0 个商品到购物车，前端给不给输入 0，接口怎么提示；然后你添加负数，小数，正数，都这么试试。然后是物品因素，你添加一个正常物品，你添加一个被下架了不存在的物品。最后是购物车因素，这个和数量因素差不多，可能购物车最多给你 9999，所以你数量因素输入 9999，或者重复添加直到数量超过 9999。最后看下网络，弱网前端是否有转圈圈，弱网重复点击会如何。这个才叫做功能测试。你上面说的那些，答了跟没答一样，满分 10 分最多给 2 分。如果有个测试问我，怎么添加一个被下架了不存在的物品，我就想问，你工作几年了，刚毕业还能理解，要是有个三年了，那你注定走不远。

1.面对这种老套而常规的题目，建议回答的时候突出逆向思维和发散思维
2.面试官每天面对多个面试者，千篇一律的回答很难留下印象
3.回答一定要精炼，不要太长
4.比如，功能方面以冲突为主，加入购物车的商品，后台下架了，售罄了，更新了，单位变了，有优惠了赠品了等等
5.回答之前要问需求，随便问几个点，可以表现出测试对需求的关切度，以及能进一步定位测试方向；是一般电商购物车，还是大宗交易，还是别的
6.考虑性能，负载等放最后，突出规划能力，优先级安排能力
7.结合实际项目经验，问题是怎么测也包括怎么执行，遇到特殊情况的处理；多数人仅仅回答了怎么设计；容易忽略测试的推进，问题总结报告等

大佬，您说到的前后分离的思想，是不是接口用例和功能用例的设计？，如果不是，麻烦您能赐教下具体思维吗？我想学习下，-------我觉得问题还是出在题目信息太少，不敢确定是什么阶段对购物车进行测试的，回答问题前还是和面试官再三确认下比较好

最烦你这种给别人下定义的人

你快攻击我吧。我朴实无华说出了我面试别人的想法，你就开始急了。

你确实可以理解为，前后分离=接口 + 功能。因为很多人回答测试一个点，总是不关注前后端。比如添加商品到购物车，前端必然是有代码要校验，不让你输入-1，后端必然也要校验-1 是不可行的。所以你只在界面上输入-1 试了不行，就认为用例通过了，那绝对就是错误的。因为你漏测了后端校验的逻辑。我面试就是要听到具体的东西，而不是说校验什么正常不正常，这种确实说了=没说。至于楼上最烦我的那位同学，你要是 bat 大佬，那你牛逼，你要不是 bat，恐怕你连被我面试的资格都没。我面试别人，就是要听到，你告诉我你输了-1，前端不给输入，然后你又发了请求，确认了后端有校验。当然，鄙人不是做电商，这种购物车也就举个例子。这个论坛我又不常来，我科学上网都是看的其他论坛。楼上尽管烦我呗。

举个面试实际例子：问你测试购物车输入框，你告诉我校验负数，那在我这里必然不是满分；你要是告诉我，前端输入-1，自动会变为 1，最低就是 1，点个 - 号，也是不会变为 0，然后通过更改页面元素，或者通过接口方式，去测验-1 在后端也有校验。那你就是答到点了。

好了，不再多说了，下一次回答，也许也是几个月之后了。楼上的那位，应该看不到我了。

第一次看到有人回个问题上跳下窜的。。。。你这也回答得不怎样，你无法就是想说功能测试 + 接口测试嘛。。，还把帐号也注销了。。。

九楼的朋友很不错，不过虽然流批，满分 10 分，我只能给他 8.8，因为他自己已经有 1.2 了

哈哈，我突然发现，面试不过不一定是我的问题

那位已经注销账号的 “面试官” 说了一堆，无非就是两个方面：1、用例设计的粒度问题，就是我们在设计用例时候要能把握好这个粒度，这个粒度是能够可以执行或者评估的，不能够直接说检查某个功能是否正常，要细分到具体的正常元素；2、我们点工通常是针对界面去操作和设计用例，比如说一个输入框的校验，可能前端校验了，后端接口没有校验，这种情况如果我绕开前端直接通过接口调用可以规避这个限制，针对前后端校验的问题，如果条件允许情况下可以单独使用 postman 等工具调用后端接口，不过这个比较花费时间，我平时都是直接拉去项目代码找到这个调用的接口的 controller，看下代码中有没有这种校验逻辑，一般来讲这种校验逻辑放在最开头的地方实现，可以把利用 AI 工具 输入需求进行检查，这样甚至还可以发现这个接口的一些隐藏的 BUG
最后我还想补充一点： 前面说的 1 和 2 是针对功能界面 和接口，其实还有就是最好在测试的过程中，跑完一条流程，去看下这个功能涉及到表的数据存储记录是否正常，表设计是否合理。我就遇到过 BUG，就是表的主键 id int 类型长度设置的比较短，然后这个业务量又是巨量增长的，随着时间推移以后这个主键 id 一定会超过限制报错，后面提了 BUG 改数据类型
最后还想再补充一点，论坛是个交流的地方，大家都是相互学习，论坛里面有大佬也有小白，也许你的经历很丰富，你觉得人家回答的不好，你补充就行了，不想回答绕过就可以了，没有必要去诋毁，真的是没有必要。

是这样的，你看九楼那位 1.2，可能你就是在面试中稍微说了点不合他心意的话，他就直接 pass 你了

往往这种人更难相处，估计也是个小组长之类的，这种平时工作中就很难相处了

这类人本身就是造成职场环境不和谐的因素

一般会看你简历写的项目吧，如果是商城类的项目
购物车一般还需要考虑，
1、不同店铺（供应商）是否有集合，分类
a\ 可以展开来说：不同商铺 展示以及 相同店铺下商品 展示。。。。
2、折扣金额对购物车的展示
3、失效商品在购物车的展示
4、购物车的刷新逻辑

经典说别人急了，实际是听不得一点讨论的声音，大家确实就烦你这种狭隘的拿鸡毛当令箭的。

面试的时候你真的愿意听面试者跟你扒拉半天颗粒度吗?都挺忙的,既为难自己还为难别人

如果我是面试官的话，我更期望面试者从功能，性能，兼容性等几个方面去分析，每个方面列几个典型测试点，一上来就列一大堆功能测试点的，评价不会太高