简介这是一份高校软件测试技术的综合实验报告围绕《仓库管理系统》演示了从需求分析、可行性分析、系统设计到测试用例设计与执行记录的全过程适合软件工程、软件技术专业学生或初入测试岗位者用于课程设计、实验报告撰写和用例设计参考。资源为单个doc文档大小237KB正文包含登录模块、设备信息管理模块的功能结构、系统流程图、数据库设计及多类测试用例可帮助读者掌握黑盒测试、白盒测试等常见方法在实际项目中的落地方式。报告层次清楚目录结构完整便于按模块查阅。目前已有208人学习浏览对正在完成同类仓库管理系统课程作业或测试实验的用户具有较高参考价值既能对照检查报告结构也可借鉴其测试思路与用例表格组织方式。1. 软件测试技术综合实验选仓库管理系统不是选业务是选边界仓库管理系统在软件测试技术课程和综合实验里出现频率极高原因不是它业务复杂而是它的输入输出规则足够典型。库存数量不能为负、入库单号有固定格式、出库数量不能超过当前库存、不同角色对同一菜单的可见性不同——这些规则覆盖了等价类划分、边界值分析、场景法和错误推测法的主要应用场景。也就是说拿《仓库管理系统》做测试用例设计一个系统就能把测试用例设计方法的主干全部过一遍。这份实验报告的核心任务是在有限的实验周期内以仓库管理系统的需求文档为唯一依据完成测试需求分析、测试用例编写、用例优先级划分和测试执行记录。比写用例更重要的是证明你的用例设计有方法可依。全文从拆分需求开始落到可执行的用例表最后给出几个在实验报告里容易被忽略的细节。2. 从需求文档到测试点先把仓库管理系统拆到可测粒度2.1 把系统切成功能模块再切成可测的输入项拿到仓库管理系统的需求说明之后第一步永远是画功能地图而不是直接打开Excel写用例。仓库管理系统常见的功能域至少有这些登录和权限控制、基础资料管理供应商、客户、商品、入库管理采购入库、退货入库、出库管理销售出库、领料出库、库存管理库存查询、库存盘点、库存调拨、报表统计。以库存管理举例它不是一个测试点而是一组测试点。库存查询关心的是查询条件组合和结果显示是否正确库存盘点关心的是盘点单创建、盈亏数量计算、盘点差异审核这条完整链路库存调拨关心的是调出仓库的库存扣减和调入仓库的库存增加是否在同一个事务里。把每个功能子项再往下拆一层拆到输入项级别——比如“盘点数量输入框”“调拨数量输入框”才是测试用例能落笔的粒度。拆完之后做一件重要的事给每个功能点编号。编号规则可以随手定义比如 MOD-STK-QRY-001 表示库存管理模块下的库存查询功能点但是必须保证用例可以反向追踪到这个编号。这是测试用例可追溯性的基础也是综合实验报告评分时最先被看的部分。2.2 需求跟踪矩阵一张表证明测试点没有遗漏需求跟踪矩阵Requirement Traceability MatrixRTM是连接需求文档和测试用例的桥梁。它的作用不是给实验报告凑页数而是当你写了 200 条用例之后能清楚回答“需求文档里的第 3.2 条规则到底有没有用例覆盖”。表格至少要有这些列需求编号、需求描述、功能模块、对应测试用例编号、用例执行结果。下面是一个仓库管理系统的 RTM 片段。需求编号需求描述功能模块对应测试用例覆盖状态REQ-STK-001库存数量值域为 0 到 999999不允许负数库存管理TC-STK-001 至 TC-STK-008已覆盖REQ-IN-002入库单号规则为 RKYYYYMMDD4 位流水号入库管理TC-IN-021 至 TC-IN-026已覆盖REQ-OUT-003出库数量不得超过可用库存出库管理TC-OUT-015 至 TC-OUT-019已覆盖REQ-USR-004普通用户无权访问用户管理菜单系统管理TC-USR-011, TC-USR-012已覆盖RTM 的做法是在写完用例之后回填不是先建好表再编用例。实验报告里常见的错误是需求写了十条用例写了二十条但是看不出每条用例对应哪条需求。RTM 就是用来消除这个断层的。2.3 测试环境的搭建和数据准备这一步影响用例能不能跑起来用例设计得再好如果测试环境缺少基础数据执行阶段会发现大量用例根本无法执行。仓库管理系统的测试环境最少需要两个部分数据库里预置的商品、供应商、仓库基础数据以及不同权限的测试账号。数据库预置数据可以用 SQL 脚本完成下面是创建基础测试数据的一个示例。-- 插入基础商品数据用于入库、出库和盘点用例 INSERT INTO product (product_code, product_name, spec, unit, stock_quantity) VALUES (P001, A4打印纸, 70g/500张, 包, 500), (P002, 中性笔, 0.5mm/黑色, 支, 1200), (P003, 档案盒, 55mm, 个, 300); -- 插入两个角色不同的账号用于权限相关用例 INSERT INTO user (username, password, role) VALUES (admin, MD5(123456), ADMIN), (operator, MD5(123456), OPERATOR);参数说明product_code是商品编码需要与入库单里录入的商品编码完全匹配否则测试入库流程时会出现“商品不存在”的提示这不是被测系统的缺陷而是测试数据准备不完整。stock_quantity是库存初始值边界值用例会直接依赖这个数值所以需要在设计用例前确定初始库存量。测试数据准备的关键原则是一条用例一份数据至少不能互相依赖。比如测试跨仓库调拨的用例必须准备两个仓库否则用例执行到调拨这一步就断了。3. 三种核心测试用例设计方法在仓库管理系统中的落法3.1 等价类划分把无限输入压缩成有限代表值等价类划分的基本思想是把输入域的无限集合划分成若干子集每个子类里的数据对被测程序来说“表现相同”然后从每个子类取一个代表值进行测试。仓库管理系统里最适合用等价类划分的是各种数值输入和文本输入框。以“库存数量输入框”为例先明确需求规则库存数量必须是整数取值范围为 0 到 999999不能为负数不能为空。按这个规则划分等价类输入条件有效等价类无效等价类数据类型整数如 100小数如 10.5、字母如 abc、特殊字符如 取值范围0 到 999999 之间的整数负数、大于 999999空值无空字符串、全空格数据格式标准数字格式前导零如 00100、科学计数法如 1e3为什么要给“前导零”单独设一个无效等价类因为在仓库管理系统里经常出现用户从 Excel 复制数据的情况Excel 里的“0100”复制到系统输入框如果系统后端没有做类型强转有可能产生两种结果一种是被解析为 100另一种是直接报错。这两种结果本身不是问题问题在于未经验证的行为是潜在缺陷。所以实验报告中写等价类时把这个场景列为无效类然后用用例去确认系统的实际表现。等价类划分的实践经验是每一条需求规则至少要对应一个有效等价类输入和一个无效等价类输入。如果需求里没有任何规则限制某个输入框那么也需要设计一个用例确认“该输入框是否真的没有限制”这种用例往往能发现需求文档本身的疏漏。3.2 边界值分析仓库管理系统一半的缺陷都在边界上边界值分析是等价类划分的补充它关注的是等价类边界上的值包括边界值本身、边界值两侧的值。库存数量取值 0 到 999999那边界值就是 0、1、999999、1000000 这组数字加上负数边界 -1。除了数值边界仓库管理系统里还有两种容易忽略的边界。第一种是字符串长度的边界入库单号规则为“RKYYYYMMDD4 位流水号”总长度是 14 位需要测试 13 位、14 位、15 位三种情况。第二种是业务数据的边界比如出库数量等于当前库存、小于当前库存、大于当前库存这三个值的差异直接对应三种完全不同的业务流程。边界值用例的参数可以写成一个小的生成脚本避免手写录入时出错。下面这个 Python 脚本可以自动生成库存数量的边界值集合。def generate_boundary_values(lower, upper): values [lower, lower 1, upper - 1, upper, upper 1] # 去除超出业务允许范围的值保留负边界用于异常测试 valid [] invalid [] for v in values: if lower v upper: valid.append(v) else: invalid.append(v) # 额外加入 -1 和 0 的左侧邻值 invalid.append(lower - 1) return sorted(set(valid)), sorted(set(invalid)) valid, invalid generate_boundary_values(0, 999999) print(有效边界值:, valid) print(无效边界值:, invalid)执行后会得到有效边界值: [0, 1, 999998, 999999]和无效边界值: [-1, 1000000]这两组值直接对应库存数量的正向用例和异常用例。脚本逻辑说明lower 1和upper - 1是边界内侧值upper 1是上边界外侧值lower - 1追加进无效列表是因为负数在仓库管理系统里不仅涉及校验失败还涉及库存扣减逻辑是否会变成负数的问题需要单独确认。3.3 场景法把出库流程从登录到提交串成完整链路场景法适用于有明确业务流程的功能仓库管理系统的出库流程就是一个典型。场景法的核心是先画基本流和备选流再把每个流对应成一条或一组用例。基本流是最常见的正常流程备选流则覆盖各种分支和异常情况。出库流程的基本流如下登录系统、进入出库管理、选择出库类型、选择出库商品、输入出库数量、提交出库单、系统扣减库存、审核出库单、完成出库。备选流包括提交时库存不足、提交时商品不存在、审核被驳回、超管绕过审核直接出库、出库后库存变为负数。把这些流描述成表格场景编号场景描述涉及流程操作预期结果SC-OUT-01基本流正常出库登录 → 填单 → 提交 → 审核 → 完成库存扣减出库单状态为“已完成”SC-OUT-02备选流库存不足填单 → 输入大于库存的数量 → 提交系统提示“库存不足”出库单不提交SC-OUT-03备选流审核驳回提交出库单 → 审核员驳回出库单状态为“已驳回”库存不变SC-OUT-04备选流出库数量为 0填单时输入 0 → 提交系统阻止提交提示数量必须大于 0SC-OUT-05异常流提交过程中断网提交时断开网络连接出库单不生成库存不变场景法的价值在于它能把等价类和边界值串起来。比如“库存不足”这个场景里边界值用例覆盖的是“出库数量等于库存 1”场景法覆盖的是“用户从选择商品到提交出库单的完整操作路径”。粗粒度地说等价类是点场景法是线实验报告里两类用例缺一不可。3.4 三种方法如何落到一张用例表里实验报告里最常见的疑问是一条用例到底应该对应一种方法还是可以对应多种答案是一条用例的主设计方法只有一种但设计过程中可以组合。比如出库数量边界值用例主方法是边界值分析但前置条件里的“用户登录”是场景法的产物不能因此说这条用例不属于边界值用例。一个合理的用例集结构是先按模块分目录每个目录下按用例编号排列表格表头包含用例编号、测试点描述、前置条件、测试步骤、输入数据、预期结果、实际结果、优先级、设计方法。设计方法列只标注最主要的一种不要写“等价类边界值场景法”这种三合一的标注看起来全面实际评审时会被认定为主方法不清。如果实在想写组合就写“边界值为主场景法辅助”并单独留一行说明副方法具体参与了哪个步骤的设计。4. 测试用例优先级与编号规范实验报告里最容易拉分的地方4.1 用例优先级P0 到 P3 怎么划理由比等级本身更重要仓库管理系统的用例数量通常在 80 到 200 条之间如果实验要求在一个测试周期内完成回归执行优先级就是决定执行顺序的唯一依据。常见的四级划分方式是P0 为阻塞性用例不通过则无法进入下一轮测试P1 为核心业务流程用例覆盖主要功能P2 为次要功能用例P3 为界面友好性和易用性用例。以仓库管理系统为例P0 用例是登录、入库、出库、库存查询这四个核心流程的主路径用例每一条都是“不通过就不能交付”的级别。P1 是对这些流程的异常分支覆盖比如入库时商品不存在、出库时库存不足。P2 是基础资料管理和报表统计。P3 是界面文案、按钮位置、操作提示这类问题。划分优先级时有一个容易犯的错误把用户不常用但业务上关键的功能判为 P2。比如“库存盘点差异审核”是一个月才跑一次的功能但它的结果直接影响财务数据属于 P1 而不是 P2。判优先级的依据应该是业务影响度不是使用频率。4.2 用例编号规则用字符编码直接看清楚模块和场景用例编号是一种沟通语言格式不统一会给评审和执行带来额外障碍。拿仓库管理系统的用例表来看一个推荐格式是“TC-模块缩写-场景缩写-三位序号”。模块缩写对应功能模块场景缩写对应基本流或备选流的相关场景。举几个具体编号TC-LOGIN-BASIC-001登录模块基本流用例第一条TC-LOGIN-AUTH-002登录模块权限校验用例第二条TC-IN-BOUNDARY-005入库模块边界值用例第五条TC-STK-SCENE-003库存模块场景法用例第三条这个格式的优点是用例编号本身携带了模块信息和方法信息。实验报告打印出来后评审老师只看编号就能判断模块分布是否均匀、每个模块是否覆盖了多种测试方法。4.3 用代码批量生成和检查编号避免人工录入错误手工维护上百条用例的编号时很容易出现重复编号或跳号。写一个小脚本做唯一性检查比肉眼扫描高效得多。下面这段 Python 脚本可以读取 Excel 格式的用例表对用例编号做重复和缺失检查。import re from collections import Counter def check_case_ids(file_path): # 假设Excel中B列为用例编号实际使用时可替换为pandas读取 case_ids extract_case_ids(file_path) # 自定义读取函数 duplicates [k for k, v in Counter(case_ids).items() if v 1] pattern re.compile(r^TC-[A-Z]-[A-Z]-\d{3}$) invalid [cid for cid in case_ids if not pattern.match(cid)] return duplicates, invalid duplicates, invalid check_case_ids(testcases.xlsx) print(重复编号:, duplicates) print(格式非法编号:, invalid)代码里的pattern限定了编号格式必须是以 TC 开头、模块缩写为大写字母、场景缩写为大写字母、序号为三位数字这能在用例编写阶段就拦截掉大量格式错误。正则参数说明[A-Z]要求模块缩写和场景缩写至少一个字母\d{3}要求序号必须是三位数不足三位时需要补零这是为了避免TC-IN-BASIC-1和TC-IN-BASIC-10在排序时出现乱序。4.4 Excel 里的用例字段多一个字段评审时就少一个问题实验报告的用例表至少要有以下字段用例编号、所属模块、用例标题、优先级、前置条件、测试步骤、测试数据、预期结果、设计方法。其中最容易漏掉的是前置条件。比如“出库数量等于库存量”的用例前置条件必须写明当前库存量是 500否则执行者不知道出库数量填多少才能触发边界场景。前置条件的写法也有讲究不要写“系统正常运行”这种所有用例都适用的话要写具体的数据状态。正确的写法是“库存中存在商品 P001库存数量为 500当前用户具备出库操作权限。”这样执行者可以直接按照前置条件去准备测试环境不需要猜。预期结果的写法同样很重要。“系统提示库存不足”和“系统提示库存不足且出库单状态保持为草稿”是两种不同质量的预期结果。后者多了状态断言验证的不只是提示文案还包括数据没有被污染。5. 用登录模块做全套演练从用例设计到缺陷定位的闭环5.1 登录模块用例表把等价类、边界值、场景法全用上登录模块规模小但方法覆盖全面适合作为实验报告中的“完整示例”章节。它的输入项有三个用户名、密码、验证码结合“记住账号”这个选项能写出的用例超过二十条。下表是一个压缩版展示了三种设计方法在同一个模块里的落法。用例编号测试点优先级前置条件测试步骤测试数据预期结果设计方法TC-LOGIN-BASIC-001用户名密码正确登录成功P0数据库中已存在用户 admin输入用户名和密码点击登录admin / 123456跳转至系统首页显示当前用户名等价类TC-LOGIN-BASIC-002用户名正确密码错误P0无输入正确用户名和错误密码点击登录admin / 000000提示用户名或密码错误不跳转等价类TC-LOGIN-BOUNDARY-003密码长度边界值P1无分别输入 5 位、6 位、7 位密码12345 / 123456 / 12345676 位及以上密码通过格式校验5 位提示密码长度不足边界值TC-LOGIN-AUTH-004未输入验证码直接登录P1无仅输入用户名和密码点击登录admin / 123456 / 验证码为空提示请输入验证码不发送登录请求场景法TC-LOGIN-FAIL-005连续 5 次密码错误账号锁定P1无连续输入 5 次错误密码密码依次为 000001 至 000005第 6 次登录时提示账号已锁定边界值TC-LOGIN-NULL-006用户名为空点击登录P2无密码输入正确用户名为空点击登录空 / 123456提示用户名不能为空焦点定位至用户名输入框等价类这张表里值得注意的细节是 TC-LOGIN-BOUNDARY-003密码长度 6 位是系统的安全规则边界但需求文档通常不会写“最小密码长度”而是写“密码长度不得少于 6 位”。边界值用例取 5、6、7 三位是因为 5 能证明“少于边界会被拦截”6 能证明“等于边界可以通过”7 能证明“超过边界依然正常”。5.2 登录用例执行失败时的典型缺陷定位登录模块测试执行中遇到失败排除测试数据错误后常见原因集中在三个方面。第一种是前端校验和后端校验不一致前端允许 6 位密码通过但后端按 8 位校验导致用户在界面看到逻辑错误提示。定位方式是用抓包工具查看登录接口的实际请求参数比对前端拦截规则。第二种是验证码校验与登录接口的时序问题验证码在点击登录瞬间被刷新导致校验失败属于并发类缺陷。第三种是用户状态字段异常数据库中锁定标记受其他逻辑误改需要用 SQL 直接查询用户表确认状态位的值。-- 查询用户锁定状态排查登录失败是不是账号被误锁 SELECT username, lock_flag, fail_count FROM sys_user WHERE username admin;lock_flag字段为 1 表示锁定fail_count是连续失败计数。如果fail_count是 0 但lock_flag是 1说明锁定不是密码错误触发的需要进一步查审计日志确认是谁在什么时间改了状态字段。5.3 把边界值用例做成数据驱动模板回归测试直接复用实验报告最后可以附一个数据驱动模板把登录模块的边界值用例参数化后续回归测试不需要再手工修改用例表。参数化模板的最小结构是测试数据、期望结果、适用接口。下面是一个 JSON 结构的示例。[ { test_data: {username: admin, password: 12345, captcha: 1234}, expected: password_length_error, remark: 密码5位小于最小长度6 }, { test_data: {username: admin, password: 123456, captcha: 1234}, expected: login_success, remark: 密码6位等于最小长度 }, { test_data: {username: admin, password: 1234567, captcha: 1234}, expected: login_success, remark: 密码7位超过最小长度 } ]这套数据结构的优点在于无论是用自动化测试框架跑接口用例还是手工测试时按数据逐条执行测试数据和预期结果都是闭环的。remark字段写明了边界取值的依据回归测试时即使换一个人执行也能理解每一条数据的来源。综合实验报告里把这个 JSON 作为附件附在文档末尾评审时会明显看出测试设计的完整度高于“只在 Excel 里列了二十条数据”的做法。本文还有配套的精品资源点击获取
软件测试实验：用仓库管理系统掌握等价类与边界值用例设计
简介这是一份高校软件测试技术的综合实验报告围绕《仓库管理系统》演示了从需求分析、可行性分析、系统设计到测试用例设计与执行记录的全过程适合软件工程、软件技术专业学生或初入测试岗位者用于课程设计、实验报告撰写和用例设计参考。资源为单个doc文档大小237KB正文包含登录模块、设备信息管理模块的功能结构、系统流程图、数据库设计及多类测试用例可帮助读者掌握黑盒测试、白盒测试等常见方法在实际项目中的落地方式。报告层次清楚目录结构完整便于按模块查阅。目前已有208人学习浏览对正在完成同类仓库管理系统课程作业或测试实验的用户具有较高参考价值既能对照检查报告结构也可借鉴其测试思路与用例表格组织方式。1. 软件测试技术综合实验选仓库管理系统不是选业务是选边界仓库管理系统在软件测试技术课程和综合实验里出现频率极高原因不是它业务复杂而是它的输入输出规则足够典型。库存数量不能为负、入库单号有固定格式、出库数量不能超过当前库存、不同角色对同一菜单的可见性不同——这些规则覆盖了等价类划分、边界值分析、场景法和错误推测法的主要应用场景。也就是说拿《仓库管理系统》做测试用例设计一个系统就能把测试用例设计方法的主干全部过一遍。这份实验报告的核心任务是在有限的实验周期内以仓库管理系统的需求文档为唯一依据完成测试需求分析、测试用例编写、用例优先级划分和测试执行记录。比写用例更重要的是证明你的用例设计有方法可依。全文从拆分需求开始落到可执行的用例表最后给出几个在实验报告里容易被忽略的细节。2. 从需求文档到测试点先把仓库管理系统拆到可测粒度2.1 把系统切成功能模块再切成可测的输入项拿到仓库管理系统的需求说明之后第一步永远是画功能地图而不是直接打开Excel写用例。仓库管理系统常见的功能域至少有这些登录和权限控制、基础资料管理供应商、客户、商品、入库管理采购入库、退货入库、出库管理销售出库、领料出库、库存管理库存查询、库存盘点、库存调拨、报表统计。以库存管理举例它不是一个测试点而是一组测试点。库存查询关心的是查询条件组合和结果显示是否正确库存盘点关心的是盘点单创建、盈亏数量计算、盘点差异审核这条完整链路库存调拨关心的是调出仓库的库存扣减和调入仓库的库存增加是否在同一个事务里。把每个功能子项再往下拆一层拆到输入项级别——比如“盘点数量输入框”“调拨数量输入框”才是测试用例能落笔的粒度。拆完之后做一件重要的事给每个功能点编号。编号规则可以随手定义比如 MOD-STK-QRY-001 表示库存管理模块下的库存查询功能点但是必须保证用例可以反向追踪到这个编号。这是测试用例可追溯性的基础也是综合实验报告评分时最先被看的部分。2.2 需求跟踪矩阵一张表证明测试点没有遗漏需求跟踪矩阵Requirement Traceability MatrixRTM是连接需求文档和测试用例的桥梁。它的作用不是给实验报告凑页数而是当你写了 200 条用例之后能清楚回答“需求文档里的第 3.2 条规则到底有没有用例覆盖”。表格至少要有这些列需求编号、需求描述、功能模块、对应测试用例编号、用例执行结果。下面是一个仓库管理系统的 RTM 片段。需求编号需求描述功能模块对应测试用例覆盖状态REQ-STK-001库存数量值域为 0 到 999999不允许负数库存管理TC-STK-001 至 TC-STK-008已覆盖REQ-IN-002入库单号规则为 RKYYYYMMDD4 位流水号入库管理TC-IN-021 至 TC-IN-026已覆盖REQ-OUT-003出库数量不得超过可用库存出库管理TC-OUT-015 至 TC-OUT-019已覆盖REQ-USR-004普通用户无权访问用户管理菜单系统管理TC-USR-011, TC-USR-012已覆盖RTM 的做法是在写完用例之后回填不是先建好表再编用例。实验报告里常见的错误是需求写了十条用例写了二十条但是看不出每条用例对应哪条需求。RTM 就是用来消除这个断层的。2.3 测试环境的搭建和数据准备这一步影响用例能不能跑起来用例设计得再好如果测试环境缺少基础数据执行阶段会发现大量用例根本无法执行。仓库管理系统的测试环境最少需要两个部分数据库里预置的商品、供应商、仓库基础数据以及不同权限的测试账号。数据库预置数据可以用 SQL 脚本完成下面是创建基础测试数据的一个示例。-- 插入基础商品数据用于入库、出库和盘点用例 INSERT INTO product (product_code, product_name, spec, unit, stock_quantity) VALUES (P001, A4打印纸, 70g/500张, 包, 500), (P002, 中性笔, 0.5mm/黑色, 支, 1200), (P003, 档案盒, 55mm, 个, 300); -- 插入两个角色不同的账号用于权限相关用例 INSERT INTO user (username, password, role) VALUES (admin, MD5(123456), ADMIN), (operator, MD5(123456), OPERATOR);参数说明product_code是商品编码需要与入库单里录入的商品编码完全匹配否则测试入库流程时会出现“商品不存在”的提示这不是被测系统的缺陷而是测试数据准备不完整。stock_quantity是库存初始值边界值用例会直接依赖这个数值所以需要在设计用例前确定初始库存量。测试数据准备的关键原则是一条用例一份数据至少不能互相依赖。比如测试跨仓库调拨的用例必须准备两个仓库否则用例执行到调拨这一步就断了。3. 三种核心测试用例设计方法在仓库管理系统中的落法3.1 等价类划分把无限输入压缩成有限代表值等价类划分的基本思想是把输入域的无限集合划分成若干子集每个子类里的数据对被测程序来说“表现相同”然后从每个子类取一个代表值进行测试。仓库管理系统里最适合用等价类划分的是各种数值输入和文本输入框。以“库存数量输入框”为例先明确需求规则库存数量必须是整数取值范围为 0 到 999999不能为负数不能为空。按这个规则划分等价类输入条件有效等价类无效等价类数据类型整数如 100小数如 10.5、字母如 abc、特殊字符如 取值范围0 到 999999 之间的整数负数、大于 999999空值无空字符串、全空格数据格式标准数字格式前导零如 00100、科学计数法如 1e3为什么要给“前导零”单独设一个无效等价类因为在仓库管理系统里经常出现用户从 Excel 复制数据的情况Excel 里的“0100”复制到系统输入框如果系统后端没有做类型强转有可能产生两种结果一种是被解析为 100另一种是直接报错。这两种结果本身不是问题问题在于未经验证的行为是潜在缺陷。所以实验报告中写等价类时把这个场景列为无效类然后用用例去确认系统的实际表现。等价类划分的实践经验是每一条需求规则至少要对应一个有效等价类输入和一个无效等价类输入。如果需求里没有任何规则限制某个输入框那么也需要设计一个用例确认“该输入框是否真的没有限制”这种用例往往能发现需求文档本身的疏漏。3.2 边界值分析仓库管理系统一半的缺陷都在边界上边界值分析是等价类划分的补充它关注的是等价类边界上的值包括边界值本身、边界值两侧的值。库存数量取值 0 到 999999那边界值就是 0、1、999999、1000000 这组数字加上负数边界 -1。除了数值边界仓库管理系统里还有两种容易忽略的边界。第一种是字符串长度的边界入库单号规则为“RKYYYYMMDD4 位流水号”总长度是 14 位需要测试 13 位、14 位、15 位三种情况。第二种是业务数据的边界比如出库数量等于当前库存、小于当前库存、大于当前库存这三个值的差异直接对应三种完全不同的业务流程。边界值用例的参数可以写成一个小的生成脚本避免手写录入时出错。下面这个 Python 脚本可以自动生成库存数量的边界值集合。def generate_boundary_values(lower, upper): values [lower, lower 1, upper - 1, upper, upper 1] # 去除超出业务允许范围的值保留负边界用于异常测试 valid [] invalid [] for v in values: if lower v upper: valid.append(v) else: invalid.append(v) # 额外加入 -1 和 0 的左侧邻值 invalid.append(lower - 1) return sorted(set(valid)), sorted(set(invalid)) valid, invalid generate_boundary_values(0, 999999) print(有效边界值:, valid) print(无效边界值:, invalid)执行后会得到有效边界值: [0, 1, 999998, 999999]和无效边界值: [-1, 1000000]这两组值直接对应库存数量的正向用例和异常用例。脚本逻辑说明lower 1和upper - 1是边界内侧值upper 1是上边界外侧值lower - 1追加进无效列表是因为负数在仓库管理系统里不仅涉及校验失败还涉及库存扣减逻辑是否会变成负数的问题需要单独确认。3.3 场景法把出库流程从登录到提交串成完整链路场景法适用于有明确业务流程的功能仓库管理系统的出库流程就是一个典型。场景法的核心是先画基本流和备选流再把每个流对应成一条或一组用例。基本流是最常见的正常流程备选流则覆盖各种分支和异常情况。出库流程的基本流如下登录系统、进入出库管理、选择出库类型、选择出库商品、输入出库数量、提交出库单、系统扣减库存、审核出库单、完成出库。备选流包括提交时库存不足、提交时商品不存在、审核被驳回、超管绕过审核直接出库、出库后库存变为负数。把这些流描述成表格场景编号场景描述涉及流程操作预期结果SC-OUT-01基本流正常出库登录 → 填单 → 提交 → 审核 → 完成库存扣减出库单状态为“已完成”SC-OUT-02备选流库存不足填单 → 输入大于库存的数量 → 提交系统提示“库存不足”出库单不提交SC-OUT-03备选流审核驳回提交出库单 → 审核员驳回出库单状态为“已驳回”库存不变SC-OUT-04备选流出库数量为 0填单时输入 0 → 提交系统阻止提交提示数量必须大于 0SC-OUT-05异常流提交过程中断网提交时断开网络连接出库单不生成库存不变场景法的价值在于它能把等价类和边界值串起来。比如“库存不足”这个场景里边界值用例覆盖的是“出库数量等于库存 1”场景法覆盖的是“用户从选择商品到提交出库单的完整操作路径”。粗粒度地说等价类是点场景法是线实验报告里两类用例缺一不可。3.4 三种方法如何落到一张用例表里实验报告里最常见的疑问是一条用例到底应该对应一种方法还是可以对应多种答案是一条用例的主设计方法只有一种但设计过程中可以组合。比如出库数量边界值用例主方法是边界值分析但前置条件里的“用户登录”是场景法的产物不能因此说这条用例不属于边界值用例。一个合理的用例集结构是先按模块分目录每个目录下按用例编号排列表格表头包含用例编号、测试点描述、前置条件、测试步骤、输入数据、预期结果、实际结果、优先级、设计方法。设计方法列只标注最主要的一种不要写“等价类边界值场景法”这种三合一的标注看起来全面实际评审时会被认定为主方法不清。如果实在想写组合就写“边界值为主场景法辅助”并单独留一行说明副方法具体参与了哪个步骤的设计。4. 测试用例优先级与编号规范实验报告里最容易拉分的地方4.1 用例优先级P0 到 P3 怎么划理由比等级本身更重要仓库管理系统的用例数量通常在 80 到 200 条之间如果实验要求在一个测试周期内完成回归执行优先级就是决定执行顺序的唯一依据。常见的四级划分方式是P0 为阻塞性用例不通过则无法进入下一轮测试P1 为核心业务流程用例覆盖主要功能P2 为次要功能用例P3 为界面友好性和易用性用例。以仓库管理系统为例P0 用例是登录、入库、出库、库存查询这四个核心流程的主路径用例每一条都是“不通过就不能交付”的级别。P1 是对这些流程的异常分支覆盖比如入库时商品不存在、出库时库存不足。P2 是基础资料管理和报表统计。P3 是界面文案、按钮位置、操作提示这类问题。划分优先级时有一个容易犯的错误把用户不常用但业务上关键的功能判为 P2。比如“库存盘点差异审核”是一个月才跑一次的功能但它的结果直接影响财务数据属于 P1 而不是 P2。判优先级的依据应该是业务影响度不是使用频率。4.2 用例编号规则用字符编码直接看清楚模块和场景用例编号是一种沟通语言格式不统一会给评审和执行带来额外障碍。拿仓库管理系统的用例表来看一个推荐格式是“TC-模块缩写-场景缩写-三位序号”。模块缩写对应功能模块场景缩写对应基本流或备选流的相关场景。举几个具体编号TC-LOGIN-BASIC-001登录模块基本流用例第一条TC-LOGIN-AUTH-002登录模块权限校验用例第二条TC-IN-BOUNDARY-005入库模块边界值用例第五条TC-STK-SCENE-003库存模块场景法用例第三条这个格式的优点是用例编号本身携带了模块信息和方法信息。实验报告打印出来后评审老师只看编号就能判断模块分布是否均匀、每个模块是否覆盖了多种测试方法。4.3 用代码批量生成和检查编号避免人工录入错误手工维护上百条用例的编号时很容易出现重复编号或跳号。写一个小脚本做唯一性检查比肉眼扫描高效得多。下面这段 Python 脚本可以读取 Excel 格式的用例表对用例编号做重复和缺失检查。import re from collections import Counter def check_case_ids(file_path): # 假设Excel中B列为用例编号实际使用时可替换为pandas读取 case_ids extract_case_ids(file_path) # 自定义读取函数 duplicates [k for k, v in Counter(case_ids).items() if v 1] pattern re.compile(r^TC-[A-Z]-[A-Z]-\d{3}$) invalid [cid for cid in case_ids if not pattern.match(cid)] return duplicates, invalid duplicates, invalid check_case_ids(testcases.xlsx) print(重复编号:, duplicates) print(格式非法编号:, invalid)代码里的pattern限定了编号格式必须是以 TC 开头、模块缩写为大写字母、场景缩写为大写字母、序号为三位数字这能在用例编写阶段就拦截掉大量格式错误。正则参数说明[A-Z]要求模块缩写和场景缩写至少一个字母\d{3}要求序号必须是三位数不足三位时需要补零这是为了避免TC-IN-BASIC-1和TC-IN-BASIC-10在排序时出现乱序。4.4 Excel 里的用例字段多一个字段评审时就少一个问题实验报告的用例表至少要有以下字段用例编号、所属模块、用例标题、优先级、前置条件、测试步骤、测试数据、预期结果、设计方法。其中最容易漏掉的是前置条件。比如“出库数量等于库存量”的用例前置条件必须写明当前库存量是 500否则执行者不知道出库数量填多少才能触发边界场景。前置条件的写法也有讲究不要写“系统正常运行”这种所有用例都适用的话要写具体的数据状态。正确的写法是“库存中存在商品 P001库存数量为 500当前用户具备出库操作权限。”这样执行者可以直接按照前置条件去准备测试环境不需要猜。预期结果的写法同样很重要。“系统提示库存不足”和“系统提示库存不足且出库单状态保持为草稿”是两种不同质量的预期结果。后者多了状态断言验证的不只是提示文案还包括数据没有被污染。5. 用登录模块做全套演练从用例设计到缺陷定位的闭环5.1 登录模块用例表把等价类、边界值、场景法全用上登录模块规模小但方法覆盖全面适合作为实验报告中的“完整示例”章节。它的输入项有三个用户名、密码、验证码结合“记住账号”这个选项能写出的用例超过二十条。下表是一个压缩版展示了三种设计方法在同一个模块里的落法。用例编号测试点优先级前置条件测试步骤测试数据预期结果设计方法TC-LOGIN-BASIC-001用户名密码正确登录成功P0数据库中已存在用户 admin输入用户名和密码点击登录admin / 123456跳转至系统首页显示当前用户名等价类TC-LOGIN-BASIC-002用户名正确密码错误P0无输入正确用户名和错误密码点击登录admin / 000000提示用户名或密码错误不跳转等价类TC-LOGIN-BOUNDARY-003密码长度边界值P1无分别输入 5 位、6 位、7 位密码12345 / 123456 / 12345676 位及以上密码通过格式校验5 位提示密码长度不足边界值TC-LOGIN-AUTH-004未输入验证码直接登录P1无仅输入用户名和密码点击登录admin / 123456 / 验证码为空提示请输入验证码不发送登录请求场景法TC-LOGIN-FAIL-005连续 5 次密码错误账号锁定P1无连续输入 5 次错误密码密码依次为 000001 至 000005第 6 次登录时提示账号已锁定边界值TC-LOGIN-NULL-006用户名为空点击登录P2无密码输入正确用户名为空点击登录空 / 123456提示用户名不能为空焦点定位至用户名输入框等价类这张表里值得注意的细节是 TC-LOGIN-BOUNDARY-003密码长度 6 位是系统的安全规则边界但需求文档通常不会写“最小密码长度”而是写“密码长度不得少于 6 位”。边界值用例取 5、6、7 三位是因为 5 能证明“少于边界会被拦截”6 能证明“等于边界可以通过”7 能证明“超过边界依然正常”。5.2 登录用例执行失败时的典型缺陷定位登录模块测试执行中遇到失败排除测试数据错误后常见原因集中在三个方面。第一种是前端校验和后端校验不一致前端允许 6 位密码通过但后端按 8 位校验导致用户在界面看到逻辑错误提示。定位方式是用抓包工具查看登录接口的实际请求参数比对前端拦截规则。第二种是验证码校验与登录接口的时序问题验证码在点击登录瞬间被刷新导致校验失败属于并发类缺陷。第三种是用户状态字段异常数据库中锁定标记受其他逻辑误改需要用 SQL 直接查询用户表确认状态位的值。-- 查询用户锁定状态排查登录失败是不是账号被误锁 SELECT username, lock_flag, fail_count FROM sys_user WHERE username admin;lock_flag字段为 1 表示锁定fail_count是连续失败计数。如果fail_count是 0 但lock_flag是 1说明锁定不是密码错误触发的需要进一步查审计日志确认是谁在什么时间改了状态字段。5.3 把边界值用例做成数据驱动模板回归测试直接复用实验报告最后可以附一个数据驱动模板把登录模块的边界值用例参数化后续回归测试不需要再手工修改用例表。参数化模板的最小结构是测试数据、期望结果、适用接口。下面是一个 JSON 结构的示例。[ { test_data: {username: admin, password: 12345, captcha: 1234}, expected: password_length_error, remark: 密码5位小于最小长度6 }, { test_data: {username: admin, password: 123456, captcha: 1234}, expected: login_success, remark: 密码6位等于最小长度 }, { test_data: {username: admin, password: 1234567, captcha: 1234}, expected: login_success, remark: 密码7位超过最小长度 } ]这套数据结构的优点在于无论是用自动化测试框架跑接口用例还是手工测试时按数据逐条执行测试数据和预期结果都是闭环的。remark字段写明了边界取值的依据回归测试时即使换一个人执行也能理解每一条数据的来源。综合实验报告里把这个 JSON 作为附件附在文档末尾评审时会明显看出测试设计的完整度高于“只在 Excel 里列了二十条数据”的做法。本文还有配套的精品资源点击获取
