测试基础 零基础测开学习 03——用例设计_边界值

EternalRights · 2025年10月29日 · 最后由 Duke 回复于 2025年11月03日 · 4382 次阅读

前言

包含数值范围的测试用例在设计的时候,掌握边界值分析法更能游刃有余


边界值分析法

边界范围节点

  • 上点:边界
  • 离点:距上点最近的
  • 内点:范围

边界值设计用例步骤

  • 明确需求
  • 确定无效和有效等价类
  • 确定边界范围
  • 提取数据编写测试用例

节点选择优化

  • 结论:7 个优化为 5 个
  • 上点:必选
  • 内点:必选(验证范围的连续性)
  • 离点:开内闭外(考虑区间闭合,开区间选择内离点,闭区间选择外离点)

实战环节——等价类

需求题目

优惠券系统测试设计

场景描述

某电商平台计划推出一项新功能,用户可领取一张 “满减优惠券”。优惠券的使用规则如下:

适用订单金额范围

        订单金额需在 100 元至 1000 元之间(含边界值),方可使用该优惠券。

单用户领取次数限制

        每个用户最多可领取 5 张该优惠券。

优惠券有效期

        自领取之日起的 7 天​ 内有效(例如:1 月 1 日领取,有效期至 1 月 7 日 23:59:59)。

你的任务是

请针对以上规则,使用边界值分析法设计测试用例,验证优惠券的领取和使用逻辑是否正确。


实战环节答案

有效等价类和无效等价类的划分

测试用例


实战环节升华

多个不同需求测试用例设计

    同一场景下,涉及多个不同需求。对于多个不同需求在设计测试用例的时候,我们没有必要非得合而为一,我们可以分门别类的进行设计,即视为不同模块的用例设计。

涉及数据范围的测试数据

    我们要想设计一份优秀的测试数据,可以先判断数值类型,如若业务场景下该数值范围允许出现小数,那么我们在设计测试数据的时候需要考虑小数的情况。


后记

我接触 Markdown 不多,但我会在接下来的学习记录中不断优化文章的效果展示,争取提高排版的观赏性。

共收到 14 条回复 时间 点赞

6,7 合到 1,2,3 中其中两个好点吧

我们公司要求把需求文档喂给 AI,让 AI 来生成测试用例。 试行了几次,AI 生成的准确度和完整性都很好,感觉以后测试用例设计 大部分 可以由 Ai 来完成了。 测试工程师又减少了思考的环节,慌张啊,以后又变成 “点点点” 工程师了。

但是如果 2,6 为一组,3,7 为一组,这种情况下测试通过了还好说,测试失败了就得单独摘出来进行测试。
不过合并与否都是两种思路,只是前者合并可形象理解为 “先甜后苦”,后者合并可形象理解为 “先苦后天”。

4楼 已删除
Duke 回复

其实你归根结底慌张的是岗位缩减与裁员,我对此有过思考,希望能帮助你:
这么说,如果 AI 能够让一批测试工程师下岗,那么最该担心的不是程序员,而是每一家互联网企业。
当 AI 能让一批测试工程师下岗的时候,这个时候 AI 的技术也已经达到了个体开发程序的时代,那么这个时代每个人都可以通过简单学习,来使用 AI 生成程序,进而每一家互联网企业都会面临个体(也可以是一些小型但大规模使用 AI 的公司)的竞争。
类比于新闻学与自媒体的关系,自媒体崛起,新闻业落魄。

Duke 回复

况且各行各业,所谓的高端领域也在被 AI 占领,拿个最简单的例子:律师,律师这个行业趋势就是 AI + 律师,未来甚至有可能出现法院虚拟 AI 律师的存在。
所以,我们作为测开行业的,打好基础功,走一步看一步得了,毕竟以后脑机接口实现全民高知化,应试教育瞬间素质教育这些都是未来的趋势。倒不如放弃毫无意义的焦虑,选择过好当下,把该打的基础打好,并适应新时代,接受新事物。

Duke 回复

有没有 prompt 可以分享一下,是不是要给 AI 喂 SPEC 文档?

EternalRights 回复

但是你上一篇里不都是合并的么?有效等价类都是合并的,无效等价类才是逐个覆盖😃

Duke 回复

我们连需求文档都没有,只有原型,估计 ai 也识别不出来原型的内容吧

Duke 回复

哪个 AI 啊,稍微复杂一点得需求,AI 就冒烟了

        上一篇的总需求有明显的递进式色彩,即选择会员类型,之后输入续费时长,最后使用优惠券;但是此篇的总需求可以细分为两个小需求,一个是优惠券使用(订单范围 + 领取优惠券 + 一定时间使用优惠券),一个是优惠券领取(领取优惠券),很明显此篇的需求可以进行拆分,而且不是递进式拆分。
        关于你的观点 “有效等价类都是合并的,无效等价类才是逐个覆盖😃”,此篇评论区我也会回答过类似的观点,套用一下

但是如果 2,6 为一组,3,7 为一组,这种情况下测试通过了还好说,测试失败了就得单独摘出来进行测试。
不过合并与否都是两种思路,只是前者合并可形象理解为 “先甜后苦”,后者合并可形象理解为 “先苦后天”。

EternalRights 回复

本来就是必填项,你不合并如果出错了也一样要拆开来看啊,不是说前面有效期 0 和别的项组合通过了,后面如果出错就能拍出有效期 0 吧,既然不能排除,为何不合并呢

Alex-gaiii 回复

我现在就是把需求文档,自己看一遍,然后把需求整理成一小段内容完整的部分,然后复制粘贴给 deepseek, 当然你也可以直接把 word pdf 直接上传。

竹卒 回复

“好公司啊”,为了避免 Ai 对测试工程师的威胁, 来 需求文档都不写了

xiaoHei 回复

就是扔给 deepseek 而已。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册