测试用例思维导图怎么写？用文件上传拆出正常、边界与异常场景

写测试用例思维导图，先把需求拆成可以判断的条件，再为每个条件写清预期结果。只列“正常上传、异常上传、兼容性”三个分支，看起来完整，执行时仍会漏掉大小边界、权限变化和结果不确定的重试。导图适合检查覆盖面；具体用例还需要前置条件、操作和检查点。

下面以课程平台的“提交作业附件”为例，用在线思维导图整理测试范围，再挑出关键分支写成可执行用例。整个过程围绕同一份规则展开，你可以把文件类型、大小限制和权限条件换成自己的项目约定。

先写上传规则，别让测试人员替需求做决定

假设这个作业功能约定：已登录且有课程权限的学员，可以在截止时间前提交一个 PDF 或 PNG 附件；文件必须可正常解析，大小大于 0 且不超过 10 MiB；再次提交时替换当前附件，但必须先确认。上传失败不能删除原来的有效附件。

这里的 10 MiB 是案例的容量约定，等于 10,485,760 字节。若需求只写“10M”，应先确认按十进制 MB 还是二进制 MiB 判断，不能测试人员用一种单位、前端显示另一种单位。截止时间也要明确时区及服务端如何判定，不依靠用户电脑的时钟。

先把会改变测试结果的约定写清楚

规则编号	本案例的约定	测试前需要确认
R01 文件	可解析的 PDF、PNG；0＜字节数≤10,485,760	后缀与实际内容不一致怎样处理？提示是否说明原因？
R02 权限	登录、拥有课程权限、未过提交截止时间	开始上传时符合条件，提交完成时权限已失效，按什么规则处理？
R03 替换	每份作业保留一个当前附件；替换前确认	用户取消确认、上传中断时，旧附件是否仍可访问？
R04 结果	成功后能看到当前附件信息并打开文件	响应超时但服务端可能已保存时，如何查询和避免重复提交？

最后一列若没有结论，就在导图中标为“规则待确认”，并写上需要谁回答。不要擅自把“自动重试三次”“断点续传”或“保留全部历史版本”补成产品能力。先暴露需求缺口，比写一条无法判断对错的用例更有用。

按文件、权限、过程和结果拆分导图

中心主题写“作业附件提交”，下面分别展开四个问题。它们覆盖输入、动作和可观察结果，评审时也容易找到遗漏。

• 文件是否可接受：类型、实际内容、大小、空文件、文件名。文件名相同不代表内容相同；类型校验也不能只看后缀。
• 此刻是否允许提交：登录、课程权限、截止时间，以及上传过程中这些条件发生变化的情况。
• 提交过程中发生什么：正常完成、主动取消、网络中断、重复点击、替换确认。每种情况都要接到明确的结束状态。
• 最终保存了什么：附件数量、名称、内容、提交状态、原附件去留，以及刷新页面后的显示是否一致。

每个叶子节点尽量写成“条件 → 预期”。例如“10 MiB 的有效 PNG → 大小检查通过”，比“测试大文件”更明确；“替换上传失败 → 原附件仍保留”，比“异常处理正常”更容易核验。若一个节点同时写了三种条件，拆开后再决定哪些需要组合测试。

在 Boardmix 中创建中心主题后，依次添加这四个分支，再把具体测试点放到子主题中。较长的解释留在旁边的文本或注释里，导图上保留条件、预期和规则编号。这样收起某个分支时，仍能看到测试范围，而不会被一大段用例步骤挤满。

大小边界要测在限制附近，且文件本身必须有效

需求规定“不超过 10 MiB”，临界值本身应通过大小检查，超过一个字节应被拒绝。可以准备 10,485,759、10,485,760 和 10,485,761 字节的有效文件，观察限制两侧的行为。另准备一个普通的小文件验证正常路径，以及 0 字节文件验证空文件处理。

不要随便向文件里填充字节后，只看文件名还叫 PDF 就拿去测大小。若文件结构已经损坏，被拒绝可能是解析失败，不能证明大小规则正确。测试材料需要同时记录文件名、实际类型、精确字节数和可打开状态，让一次用例尽量只改变正在考察的条件。

ISTQB 黑盒测试技术说明将等价类、边界值、决策表和状态转换区分开来。导图可以组织这些检查点，但不是把分支画全就证明覆盖充分。容量限制适合看边界；“权限有效且未截止才可提交”则需要检查条件组合。

如果页面显示的大小经过四舍五入，10,485,761 字节也可能显示成“10.0 MiB”。判定时应回到精确字节数，并核对提示是否足以让学员理解为什么不能提交，而不是仅凭界面上两个相同的显示值判断缺陷。

把关键节点展开成能交给同事执行的用例

导图里的一条“超限文件被拒绝”，还不够直接执行。需要说明使用谁的账号、是否已有附件、选择什么文件、观察哪个位置。下面三条用例分别覆盖边界、原附件保护和不确定结果，它们不能合并为一句“上传失败时有提示”。

用例需要同时写操作和可观察结果

用例	前置条件与操作	预期检查点
TC01 上限值	有权限且未截止；无旧附件；提交有效、恰为10,485,760字节的PNG	通过大小检查；提交成功后只有一个当前附件；刷新后可打开且内容一致
TC02 替换失败	已有可打开的附件A；确认替换为B；在B提交完成前使网络中断	不能显示B已成功；按已确认的失败规则处理；A不能因失败而丢失，恢复后能查询当前附件状态
TC03 响应未到达	提交已到服务端，但客户端未收到结果；恢复网络后再次操作	按项目约定确认首次结果；不能无提示地产生多个当前附件；界面状态与最终保存记录一致

TC02 与 TC03 的差别在于“服务端是否已经完成保存”。只断开浏览器网络，再看一个失败提示，无法覆盖这两种情况。研发与测试需要约定可控制的测试环境和观察方式；没有条件模拟时，标记未执行及原因，不把它涂成通过。

同样，看到成功提示也不代表附件内容正确。至少检查一次打开后的内容，尤其是两个不同文件使用同一个名称时。正式用例记录应保存版本、测试数据、执行结果和缺陷链接；思维导图保留对应编号，用来追踪覆盖与讨论，不替代执行台账。

评审时用反例找缺口，不按节点数量判断质量

把四个主分支暂时收起，请产品、研发和测试分别回答：什么条件才允许提交？什么时候原附件会改变？失败后学员还能做什么？如果答案不同，先修规则和节点，再增加用例。

• “所有异常都归到上传失败”：拆出文件不合格、权限不允许、过程未完成、结果未知。它们的提示和恢复动作不相同。
• “同名文件一定是重复提交”：用相同名称、不同内容的两个文件走读，确认项目究竟按什么判断替换或重复。
• “进度100%就是提交成功”：传输完成、服务端校验完成、业务提交成功可能是不同状态，检查最终记录和界面反馈是否对应。
• “每个叶子节点都通过了”：看的是已有测试点的结果，不能据此断言没有遗漏。再从权限、时间变化和恢复路径横向检查一次。

若发现多个条件相互影响，可以把这一小块转成决策表；若问题来自状态变化，再补一张状态流转图。不要强迫一张思维导图承担所有关系表达。涉及需求边界时，可用需求评审清单补齐未明确的规则，再回到导图更新受影响分支。

需求改变时，只更新受影响的分支和用例

例如容量从10 MiB调整为20 MiB，先更新R01，再找到引用R01的大小测试点、测试文件与用例；文件类型、权限和替换规则并不会因此自动改变。保留原用例的历史结果，新版本重新执行受影响用例，不把上个版本的“通过”直接带过来。

交付时让同事任选一条叶子节点，能够找到对应规则、测试材料、执行用例和当前结果。这条链路成立，导图才真正帮助团队管理测试；只有颜色整齐、节点很多，却说不清某条结论怎样得到，仍是一份待完善的检查清单。