软件测试实训系统若只做用例录入与执行记录，学生学到的是一套填表动作，换个项目仍然不会判断哪个缺陷该先修、哪些用例值得长期留着。缺陷分级的口径、回归用例的维护方式、缺陷库与教学案例的对应关系，才决定这套训练有没有迁移价值。

缺陷严重度与优先级的判定口径

严重度看缺陷本身的影响，优先级看修复的紧迫程度，两者不能合并成一栏。行业里常见的分法是严重度 S1 至 S4，S1 为系统崩溃或数据丢失，S2 为主要功能不可用，S3 为次要功能异常，S4 为界面与文案问题；优先级 P0 至 P3 按业务影响与修复成本排列。

把两栏分开后，学生才会遇到真实矛盾：一个只在极少数机型上出现的闪退是 S1 却可能是 P2，一个错别字是 S4 却可能因为出现在付款页面而升到 P1。系统里设计三组这样的冲突题，让学生各自排序再对比，争论过程本身就是训练。缺陷描述的模板可以固定为五段：环境、前置条件、复现步骤、预期结果、实际结果，缺一段就退回重写。

回归用例集的维护与复用

回归集不能靠不断追加。按模块维护，每个模块保留冒烟用例 5 至 10 条、核心路径用例 15 至 25 条，版本迭代时只增删有变更的部分。系统记录每条用例的最近执行结果与失效次数，连续三个版本都通过的可以降级为抽检，长期失败的要么修用例、要么提缺陷。

复用率是能算出来的指标：本版本复用的历史用例数除以本版本总执行用例数。教学班的合理区间在 40% 至 70%，过低说明用例没有沉淀，过高则可能漏掉新需求。让学生每迭代周期报一次复用率，比强调“要复用”更有推动力。

缺陷库与教学案例的映射

缺陷库按失效现象归类，参照 GB/T 25000.51 对质量特性的划分，把缺陷对应到功能性、性能效率、易用性、可靠性、信息安全等维度。归类之后，学生能看到自己提的缺陷集中在哪一类，长期只提界面问题的，说明没往深处测。

教学案例从缺陷库反推。挑一个真实项目里连续出现的三类缺陷，配一段代码与一份需求说明，让学生在设计用例时就把这三类漏洞覆盖进去。缺陷密度可以做横向对比，按每千行代码的缺陷数统计，不同模块的数字差异往往比总评更能说明问题。缺陷库里的重复缺陷要合并，合并时保留两条的复现路径，日后分析同类问题时信息更完整。

过程数据的评分设计

评分不只看最终找出几个缺陷。设四项权重：用例设计方法的运用（等价类、边界值、判定表是否用对）、缺陷描述的复现完整性（环境、步骤、预期与实际）、回归执行的覆盖率、缺陷定级的一致性。四项各占一定比例，避免学生靠数量刷分。