本文还有配套的精品资源，点击获取

简介：面向高校软件测试课程设计和实训场景的Java Web评分工具，基于Spring+SpringMVC+MyBatis（SSM）搭建，运行在Apache Tomcat上。支持学生上传测试用例文件，系统按预设规则自动比对预期输出与实际执行结果，生成得分、错误定位及简要评语。后台提供MySQL数据库支持，压缩包内含完整可运行源码（src目录结构规范）、建库建表SQL脚本（dbscripts）、配置文件（configs）、项目说明文档（runwen.docx）以及两套答辩专用PPT模板（含系统演示页与技术要点页）。开发环境适配JDK 1.8、Maven 3.x和MySQL 5.7+，导入IDEA或Eclipse后修改数据库连接参数即可启动；配套文档覆盖需求分析、模块划分、核心判题逻辑（如输出格式校验、边界值匹配、异常捕获机制）及详细部署步骤，方便教师快速部署教学环境或学生开展二次开发。

1. 项目概述：为什么高校测试教学急需这样一套“开箱即用”的自动评分系统？

在带软件测试实训课的第三年，我彻底放弃了手动批改学生提交的JUnit测试用例和黑盒测试脚本。一个班42人，每人交3套测试用例（功能、边界、异常），光是逐行比对assertEquals(expected, actual)里的输出字符串，就要花掉我整整两天——更别说还要检查断言逻辑是否合理、测试覆盖是否遗漏关键路径、甚至有人把assertTrue(false)当成“反向测试”来交……这不是教学，这是体力劳动。直到我把这套Java测试教学用自动评分系统部署到实验室服务器上，情况才真正改变：学生上传.java或.txt格式的测试用例文件后，系统在3秒内返回结构化评分报告——得分、错误定位行号、预期/实际输出对比块、以及一句精准的评语，比如“第27行：未覆盖空字符串输入场景，建议补充@Test public void testEmptyInput()”。关键词测试用例评分、SSM教学系统、Java自动判题，这三个词不是技术堆砌，而是我们一线教师每天面对的真实痛点：要教测试思维，而不是当人肉diff工具；要关注学生设计逻辑的缺陷，而不是帮他们数漏写了几个assert；要让课堂时间花在“为什么这个边界值必须测”，而不是“你这行输出少了个换行符”。

这套系统不是为生产环境设计的高并发判题平台，它的核心使命非常明确：成为高校测试课程中可信赖的教学助手。它基于成熟稳定的SSM架构（Spring + SpringMVC + MyBatis），运行在Apache Tomcat上，这意味着它不依赖任何云服务或特殊中间件，一台装了JDK 1.8、MySQL 5.7+和Tomcat 8.5的普通台式机就能撑起整个教学班的实训压力。压缩包里没有“可能需要你自行下载”的模糊依赖，只有清晰标注的dbscripts建库脚本、configs里开箱即用的数据库连接配置、src目录下规范分层的代码（controller→service→dao→entity→vo）、以及两套直击答辩要害的PPT模板——一套侧重系统演示流程（教师给评委讲“学生怎么用”），一套深挖技术实现细节（学生向答辩组解释“我怎么做的”）。它不追求炫酷的前端动画，但每个评分结果都附带可点击展开的原始日志；它不提供AI生成评语，但每条评语都对应着后台预设的、经过反复验证的规则引擎判断逻辑。如果你正在为《软件测试技术》《测试自动化》或《软件质量保证》这类课程寻找一个能让学生立刻上手、让教师省下80%批改时间、让答辩汇报有扎实技术支撑的落地工具，那么这套系统就是为你写的。它不是玩具，也不是半成品，而是一个被真实课堂反复锤炼过的教学基础设施。

2. 整体架构与设计思路：为什么选择SSM而非Spring Boot？为什么判题逻辑必须“轻量可控”？

2.1 SSM架构的深层教学价值：拒绝黑盒，拥抱可拆解

很多人看到“SSM”第一反应是“过时”，尤其在Spring Boot大行其道的今天。但恰恰是这份“不过时”，让它成为教学系统的最优解。Spring Boot的自动配置像一层厚厚的奶油，掩盖了Bean生命周期、DispatcherServlet初始化、MyBatis SqlSessionFactory构建这些底层脉络。而我们的目标不是让学生快速跑起来一个Demo，而是让他们在调试一个失败的评分结果时，能顺着@RequestMapping → @Service → @Transactional → SqlSessionTemplate这条链路，亲手打断点、看参数、查SQL执行日志。SSM的显式配置，本身就是一份活的Spring原理教材。

以数据库操作为例：dbscripts/create_database.sql里创建的test_case表，字段包括id, student_id, code_content, expected_output, submit_time。在MyBatis的TestCaseMapper.xml中，你会看到清晰的<insert>和<select>标签，SQL语句原样呈现，连#{}和${}的区别都一目了然。学生修改expected_output字段长度时，能立刻在TestCaseEntity.java里看到对应的private String expectedOutput;和@Column(name = "expected_output")注解——这种“所见即所得”的映射关系，在Spring Boot的@Table和@Id注解下是隐式的，而在SSM里是强制显式的。再看SpringMVC的TestCaseController.java，@RequestMapping("/submit")方法接收MultipartFile file，调用testCaseService.judge(file)，这个judge()方法内部又如何将上传的Java源码编译、运行、捕获输出？所有这些步骤，都在TestCaseServiceImpl.java里用ProcessBuilder和Runtime.getRuntime().exec()一行行写出来，没有封装成JudgeEngine.execute()这样的魔法方法。这就是教学系统的灵魂：每一个环节都必须是透明的、可触摸的、可质疑的。当学生问“为什么我的测试类没被识别？”，你可以直接带他去看FileUploadUtil.java里对文件后缀名的校验逻辑；当他困惑“预期输出为什么匹配失败？”，你可以打开OutputComparator.java，指着trim().replaceAll("\\s+", " ")这一行说：“看，我们统一处理了空白字符，所以你的预期里多了一个Tab，就导致了不匹配。”

2.2 判题引擎的“轻量可控”哲学：不追求完美，只确保教学有效

自动评分最危险的陷阱，是陷入“技术完美主义”。曾有个学生提交了一个用System.out.println("Hello World!")的测试用例，系统却报错“无有效断言”。我第一反应是升级规则引擎，去解析AST抽象语法树，识别Assert.*调用。但很快意识到，这完全偏离了教学目标——我们想评估的是学生对测试设计的理解，而不是他们的Java字节码解析能力。最终方案极其朴素：正则匹配 + 关键字扫描 + 沙箱执行。

• 第一步：静态扫描（Static Scan）
  用Pattern.compile("public\\s+void\\s+test\\w+\\(\\)\\s*\\{")匹配测试方法签名，用Pattern.compile("(assertEquals|assertTrue|assertFalse|assertNull|assertNotNull)\\s*\\(")匹配断言调用。如果找不到任何断言，直接返回评语：“未检测到有效断言，请检查是否使用了JUnit断言方法”。这步耗时不到10ms，且结果绝对确定。

• 第二步：动态沙箱执行（Sandboxed Execution）
  将学生代码写入临时文件，用javac编译，再用java -cp . TestClass运行。关键在于ProcessBuilder的配置：pb.redirectErrorStream(true)合并标准输出和错误流；pb.command("java", "-cp", ".", className)指定classpath；最关键的是pb.inheritIO()——不继承父进程IO，而是用process.getInputStream()读取输出。这样，学生代码里任何System.out.println()都会被捕获，而不会污染Tomcat控制台。

• 第三步：智能比对（Intelligent Comparison）
  这里没有复杂的Diff算法。OutputComparator.java的核心逻辑只有三行：
  java String actualTrimmed = actualOutput.trim().replaceAll("\\r\\n|\\r|\\n", "\n"); String expectedTrimmed = expectedOutput.trim().replaceAll("\\r\\n|\\r|\\n", "\n"); return actualTrimmed.equals(expectedTrimmed);
  为什么只做换行符标准化？因为教学场景中，95%的“不匹配”源于Windows/Mac/Linux换行符差异，或是学生复制粘贴时带入的不可见空格。过度复杂的比对（如忽略所有空白、模糊匹配）反而会掩盖学生真实的逻辑错误。当评语显示“第15行输出不匹配：预期‘123\n’，实际‘123\r\n’”，学生立刻明白问题出在环境配置，而不是测试逻辑本身。

这套“轻量可控”的设计，让系统具备极强的可维护性和可教学性。教师可以轻松修改dbscripts里的scoring_rules表，新增一条规则：“缺少@Ignore注释的无效测试方法扣2分”；学生也能读懂TestCaseService.judge()方法，理解从文件上传到分数生成的完整数据流。它不试图替代教师，而是把教师从重复劳动中解放出来，把精力聚焦在真正的教学核心上：引导学生思考“这个测试到底在验证什么”。

3. 核心模块解析与实操要点：从数据库建模到判题日志的每一处细节

3.1 数据库设计：一张表如何承载教学全生命周期？

dbscripts/create_database.sql创建的test_judge_system数据库，核心只有三张表，但每一张都直指教学管理的本质需求：

• student 表：存储学生基本信息，字段为id(PK), student_id(学号，唯一索引), name, class_name(班级)，create_time。这里的关键设计是student_id作为业务主键而非自增ID，因为教学系统中“学号”才是唯一可信标识，避免了因重置数据库导致ID冲突的问题。class_name字段允许教师按班级筛选成绩，期末导出Excel时，SELECT * FROM student WHERE class_name = '软工2101'即可获取全班名单。

• test_case 表：这是系统的数据心脏，字段包括id(PK), student_id(FK), task_id(任务ID，关联教学任务), code_content(TEXT, 存储学生上传的Java源码或测试脚本), expected_output(TEXT, 预期输出), actual_output(TEXT, 实际运行输出), score(DECIMAL(5,2)), status(ENUM: ‘pending’,’success’,’failed’,’error’), submit_time, judge_time。注意code_content和expected_output都定义为TEXT类型，而非VARCHAR(255)——因为学生可能提交包含大量注释的复杂测试类，或输出上千行的日志。status字段的枚举值设计，让后台管理界面可以直观展示任务状态：灰色“pending”表示待判题，绿色“success”表示通过，红色“failed”表示断言失败，橙色“error”表示编译或运行异常（如ClassNotFoundException）。

• scoring_rules 表：这才是教学策略的数字化体现。字段为id, rule_code(规则编码，如ASSERT_MISSING), rule_desc(规则描述，“未检测到有效断言”), score_deduction(扣分值，如-5.00), enabled(是否启用，TINYINT)。教师无需改代码，只需在MySQL客户端执行UPDATE scoring_rules SET enabled = 1 WHERE rule_code = 'BOUNDARY_CHECK';，就能开启“边界值检查”规则。配套文档runwen.docx的“评分规则配置”章节，详细列出了所有内置规则及其触发条件，比如OUTPUT_MISMATCH规则会在actual_output与expected_output不同时触发，扣分值由教师在scoring_rules表中配置。

提示：首次部署时，务必执行dbscripts/init_scoring_rules.sql。该脚本预置了6条教学常用规则，包括断言缺失、输出不匹配、编译失败、运行超时（默认10秒）、空测试方法、以及“无@After注释的资源未释放”警告（针对数据库连接等场景）。这些规则不是硬编码在Java里，而是通过ScoringRuleService.listEnabledRules()动态加载，实现了业务逻辑与数据的彻底分离。

3.2 判题日志：为什么每一份评分报告都必须附带“可追溯的执行痕迹”？

学生最常问的问题是：“为什么我得了85分？哪5分扣掉了？” 如果系统只返回一个冷冰冰的分数，教学效果就大打折扣。因此，TestCaseService.judge()方法在完成所有判题步骤后，会生成一份结构化的JudgeLog对象，并持久化到数据库。这个日志不是简单的字符串拼接，而是包含五个维度的元数据：

1. compileLog：javac编译过程的完整输出。如果学生代码有语法错误，这里会精确显示TestDemo.java:12: error: cannot find symbol，并标出行号。教师可据此判断是学生粗心（少了个分号），还是概念混淆（误用了不存在的类）。

2. runtimeLog：java命令执行时的标准输出与错误流合并内容。当出现java.lang.AssertionError: expected:<100> but was:<99>时，这条日志就是最直接的证据，证明学生的计算逻辑有偏差。

3. outputDiff：预期输出与实际输出的逐行对比。系统不使用第三方Diff库，而是自己实现了一个极简的DiffUtil：
   java List<String> expectedLines = Arrays.asList(expected.split("\\r?\\n")); List<String> actualLines = Arrays.asList(actual.split("\\r?\\n")); // 逐行比较，记录第一个差异行号及内容 for (int i = 0; i < Math.min(expectedLines.size(), actualLines.size()); i++) { if (!expectedLines.get(i).equals(actualLines.get(i))) { return String.format("第%d行不匹配：预期'%s'，实际'%s'", i+1, expectedLines.get(i), actualLines.get(i)); } }
   这种“找到第一个差异就停止”的策略，既保证了速度，又提供了最相关的调试信息。

4. executionTime：从ProcessBuilder.start()到process.waitFor()的毫秒数。当executionTime > 10000（10秒）时，status被设为'error'，评语为“执行超时，请检查是否存在死循环或无限递归”。这教会学生编写测试时要考虑性能边界。

5. stackTrace：仅当发生未捕获异常时记录。例如学生代码中new FileInputStream("nonexistent.txt")抛出FileNotFoundException，完整的堆栈跟踪会被捕获并存入此字段，帮助教师判断学生是否掌握了异常处理的最佳实践。

注意：所有日志内容在存入数据库前，都经过StringEscapeUtils.escapeHtml4()处理，防止XSS攻击。前端展示时，用<pre><code>标签包裹，并启用white-space: pre-wrap CSS样式，确保换行符和缩进正确渲染。这是教学系统安全性的底线——学生不能通过提交恶意HTML代码来破坏教师的管理界面。

4. 完整实操流程：从零开始部署，到第一次成功评分的每一步

4.1 环境准备与项目导入：避开IDEA的三个经典坑

部署成功率90%取决于环境初始化。以下是我在实验室反复验证的、最稳妥的步骤（以Windows 10 + IDEA 2022.3为例）：

1. 安装基础环境
   - JDK 1.8.0_291（必须是1.8，Spring 4.x不兼容JDK 11+）
   > 验证：java -version 输出应为 java version "1.8.0_291"
   - MySQL 5.7.32（推荐使用官方ZIP版，免安装，解压即用）
   > 启动：进入mysql\bin目录，执行mysqld --console，看到ready for connections即成功
   - Apache Tomcat 8.5.90（解压后，将conf\server.xml中的port="8080"改为port="8081"，避免与本地其他服务冲突）

2. 导入项目到IDEA
   - 解压资源包，找到pom.xml所在目录（通常是根目录或3SkxPo7bXjYIiEWZR1pL-master-...子目录）
   - IDEA中选择 File → Open，选中pom.xml，关键一步：在弹出的“Import Project”窗口中，勾选 Import Maven projects automatically，并确保Project SDK指向JDK 1.8
   - 等待Maven自动下载依赖（约3-5分钟）。此时常见坑：

   • 坑1：Maven仓库路径含中文 → 报错Could not resolve dependencies。解决方案：在Settings → Build → Maven中，将Local repository路径改为纯英文，如D:\maven_repo
   • 坑2：IDEA未识别webapp目录 → 项目结构中看不到webapp文件夹。解决方案：右键webapp文件夹 → Mark Directory as → Resources Root
   • 坑3：Tomcat无法启动，报错java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener → 这是因为IDEA未将Maven依赖打包进war。解决方案：File → Project Structure → Artifacts，点击+ → Web Application: Archive → For 'xxx:war exploded'，然后在Available Elements中，将Maven: xxx:jar拖入WEB-INF/lib目录

3. 配置数据库连接
   - 打开configs/jdbc.properties，修改以下三行：
   properties jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/test_judge_system?useUnicode=true&characterEncoding=UTF-8&serverTimezone=GMT%2B8 jdbc.username=root jdbc.password=your_mysql_password
   > 注意：jdbc.url中的serverTimezone=GMT%2B8是解决MySQL时区错误的关键，否则启动时会报The server time zone value '...' is unrecognized
   - 在MySQL中执行dbscripts/create_database.sql创建数据库，再执行dbscripts/init_scoring_rules.sql初始化规则

4.2 启动与首次评分：见证系统如何“读懂”你的测试用例

1. 配置Tomcat运行配置
   - Run → Edit Configurations → + → Tomcat Server → Local
   - Deployment选项卡 → + → Artifact → xxx:war exploded
   - Application context填写/testjudge（这样访问地址就是http://localhost:8081/testjudge）
   - Startup/Connection选项卡 → Open browser勾选，URL填http://localhost:8081/testjudge/login

2. 启动并登录
   - 点击绿色三角形启动Tomcat。首次启动较慢（约1分钟），等待IDEA底部Build窗口显示Server startup in XXX ms
   - 浏览器打开http://localhost:8081/testjudge/login，使用默认账号：admin/admin（密码明文存储在configs/app.properties中，正式环境请务必修改）

3. 上传测试用例并观察全过程
   - 进入学生端 → 提交测试用例，上传一个最简单的Java文件：
   ```java
   import static org.junit.Assert.*;
   import org.junit.Test;

   public class SimpleTest {
   @Test
   public void testAdd() {
   int result = 2 + 3;
   assertEquals(5, result); // 正确断言
   }
   }
   `` - 点击提交，页面跳转至提交结果页。此时，系统后台发生了什么？ -TestCaseController.submit()接收文件，保存到webapp/upload/目录，并插入test_case表，status=’pending’-@Scheduled(fixedDelay = 5000)注解的JudgeScheduler.checkPendingTasks()方法每5秒扫描一次status=’pending’的记录 - 找到新记录后，调用TestCaseService.judge()： a. 读取code_content，写入临时文件SimpleTest.javab. 执行javac SimpleTest.java，compileLog为空，说明编译成功 c. 执行java -cp . org.junit.runner.JUnitCore SimpleTest，捕获输出OK (1 test)d. 因为是JUnit Core运行，actual_output为OK (1 test)，而expected_output为空（学生未填写），系统判定为“输出不匹配”，但根据规则，JUnit运行成功即视为通过，故score=100.00，status=’success’`
   - 前端刷新页面，显示绿色“提交成功！得分：100.00”，并提供“查看详细日志”按钮

实操心得：第一次评分失败？别急着改代码。先检查tomcat\logs\catalina.out，搜索ERROR关键字。90%的问题在这里暴露：ClassNotFoundException说明webapp/WEB-INF/lib缺少JUnit JAR；SQLException说明jdbc.properties配置错误；IOException说明webapp/upload/目录无写入权限。日志是你的第一诊断工具。

5. 常见问题与排查技巧实录：那些在深夜部署时踩过的坑

5.1 典型问题速查表

问题现象	可能原因	排查步骤	解决方案
Tomcat启动后，访问/testjudge/login显示404	1. webapp目录未被识别为Web资源 2. Artifact未正确配置 3. pom.xml中packaging不是war	1. 检查IDEA项目结构，确认webapp标记为Resources Root 2. 查看Project Structure → Artifacts，确认xxx:war exploded已添加且包含webapp和lib 3. 打开pom.xml，确认<packaging>war</packaging>	1. 右键webapp → Mark Directory as → Resources Root 2. 在Artifacts中，点击+ → Web Application: Archive，将webapp拖入Available Elements 3. 修改pom.xml，确保packaging为war
登录后，点击“提交测试用例”报500错误，日志显示java.lang.NoClassDefFoundError: org/junit/runner/JUnitCore	webapp/WEB-INF/lib目录缺少JUnit JAR包	1. 进入target/xxx/WEB-INF/lib目录（Maven构建输出目录） 2. 检查是否存在junit-4.12.jar或类似文件 3. 若不存在，检查pom.xml中<dependency>是否声明了JUnit	1. 在pom.xml中添加： xml<br><dependency><br> <groupId>junit</groupId><br> <artifactId>junit</artifactId><br> <version>4.12</version><br> <scope>test</scope><br></dependency><br> 2. 右键pom.xml → Maven → Reload project
学生上传Java文件后，评分始终为0分，日志显示No tests found	学生代码未遵循JUnit 4规范	1. 检查学生代码是否包含import org.junit.Test; 2. 检查测试方法是否为public void且无参数 3. 检查类名是否与文件名一致（如SimpleTest.java内必须是public class SimpleTest）	在runwen.docx的“学生提交规范”章节，明确要求： - 必须包含import org.junit.Test; - 测试方法必须以test开头，如public void testAdd(){} - 文件名必须与public class名完全一致（区分大小写）
MySQL连接失败，日志显示Access denied for user 'root'@'localhost'	MySQL root用户密码错误或权限不足	1. 使用mysql -u root -p命令行登录MySQL 2. 执行SELECT User, Host FROM mysql.user;确认用户存在 3. 执行SHOW GRANTS FOR 'root'@'localhost';确认有ALL PRIVILEGES	1. 若密码遗忘，用mysqld --skip-grant-tables启动MySQL跳过权限检查 2. 执行UPDATE mysql.user SET authentication_string=PASSWORD('newpass') WHERE User='root'; 3. 执行FLUSH PRIVILEGES;

5.2 独家避坑技巧：让部署一次成功

• 技巧1：用“最小可行版本”验证环境
  不要一上来就跑完整系统。先创建一个最简HelloWorldController.java：
  java @Controller public class HelloWorldController { @RequestMapping("/hello") @ResponseBody public String hello() { return "Hello from SSM!"; } }
  配置好Tomcat后，访问http://localhost:8081/testjudge/hello。如果返回Hello from SSM!，证明SSM三大框架、Tomcat、IDEA集成全部正常。这一步能帮你排除80%的环境配置问题。

• 技巧2：数据库脚本执行顺序不可颠倒
  dbscripts/目录下的脚本有严格依赖：
  1_create_database.sql → 2_create_tables.sql → 3_init_scoring_rules.sql
  如果跳过2_create_tables.sql直接执行3_init_scoring_rules.sql，会因表不存在而报错。建议在runwen.docx的“部署步骤”中，用加粗字体强调执行顺序，并附上命令行示例：
  bash mysql -u root -p < dbscripts/1_create_database.sql mysql -u root -p test_judge_system < dbscripts/2_create_tables.sql mysql -u root -p test_judge_system < dbscripts/3_init_scoring_rules.sql

• 技巧3：学生端上传限制的温柔绕过
  系统默认限制上传文件大小为2MB（在web.xml中配置<max-file-size>2097152</max-file-size>）。当学生提交包含大量测试数据的.txt文件时，可能触发FileSizeLimitExceededException。与其修改配置，不如在runwen.docx中给出教学建议：“鼓励学生将大型测试数据外置，通过FileReader读取src/main/resources/testdata/下的文件，而非硬编码在Java源码中”。这既解决了问题，又引导学生学习工程化实践。

• 技巧4：答辩PPT的隐藏价值挖掘
  两套PPT模板绝非装饰品。“答辩PPT模板1.ppt”中的“系统演示页”，预置了http://localhost:8081/testjudge的截图占位符，教师只需替换为实验室真实IP（如http://192.168.1.100:8081/testjudge），并录制一段30秒的学生提交操作视频嵌入幻灯片，答辩时点击播放，评委立刻看到系统流畅运行。“答辩PPT模板2.ppt”中的“技术要点页”，则深度拆解了TestCaseService.judge()方法的UML序列图（手绘风格），清晰标注了compile()、execute()、compare()三个核心步骤的输入输出。这比任何文字描述都更能体现学生的技术理解深度。

6. 教学扩展与二次开发指南：如何让这套系统真正长在你的课程里？

6.1 教师专属：五分钟定制你的评分策略

系统最强大的地方，在于它把“评分权”交还给了教师。你不需要是Java高手，也能根据课程重点，动态调整评分规则。操作路径如下：

1. 登录后台管理界面（http://localhost:8081/testjudge/admin，账号admin/admin）
2. 进入评分规则管理菜单，看到一张表格，列出所有scoring_rules表中的记录
3. 找到rule_code = 'OUTPUT_MISMATCH'这一行，点击编辑
4. 将score_deduction从默认的-10.00改为-5.00，并将rule_desc改为“输出内容不匹配（轻微差异，如换行符）”
5. 点击保存，规则立即生效

这个改动意味着：当学生因换行符差异导致不匹配时，只扣5分而非10分，把扣分重点留给更严重的逻辑错误。同理，你可以新增一条规则：rule_code = 'COVERAGE_LOW'，rule_desc = '测试覆盖率低于60%，请补充分支测试'，score_deduction = -15.00。虽然系统当前不自动计算覆盖率，但你可以要求学生提交JaCoCo报告，并在后台人工标记此规则——系统会忠实记录并体现在总分中。

6.2 学生进阶：从使用者到贡献者的技术跃迁

这套系统的设计，天然支持学生从“使用者”成长为“贡献者”。在课程后期，可以布置一个开放性课题：“为系统增加‘Python测试用例’支持”。这需要学生完成以下步骤，每一步都是扎实的工程实践：

• 第一步：理解现有架构
  分析TestCaseService.judge()方法，理解它是如何调用ProcessBuilder执行Java命令的。阅读FileUploadUtil.java，掌握文件上传与类型校验逻辑。

• 第二步：扩展文件类型支持
  修改TestCaseController.submit()，增加对.py文件的判断：
  java if (file.getOriginalFilename().endsWith(".py")) { judgeResult = pythonJudgeService.judge(file, testCase); } else if (file.getOriginalFilename().endsWith(".java")) { judgeResult = javaJudgeService.judge(file, testCase); }

• 第三步：实现Python判题引擎
  创建PythonJudgeService.java，核心逻辑是：
  a. 将上传的.py文件写入临时目录
  b. 执行python -m pytest temp_test.py -v --tb=short（需提前在服务器安装pytest）
  c. 捕获stdout，解析=== 1 failed, 2 passed in 0.12s ===这类输出，提取passed/failed数量
  d. 根据scoring_rules中PYTHON_TEST_PASSED规则，计算分数

• 第四步：更新前端与文档
  修改webapp/WEB-INF/views/student/submit.jsp，在文件选择框下方增加提示：“支持上传.java或.py格式的测试文件”；更新runwen.docx，在“学生提交规范”章节补充Python要求。

这个过程，学生不仅实践了Spring MVC的Controller扩展、MyBatis的多数据源（如果Python结果也存库）、RESTful API设计（未来可提供判题API），更重要的是，他们亲手参与了一个真实软件项目的迭代演进。当他们的PythonJudgeService被合并进主干，那份成就感，远胜于任何理论考试的满分。

我个人在实际教学中发现，当学生意识到自己写的代码，正在被同班同学真实使用，并影响他们的课程成绩时，那种责任感和投入度是指数级增长的。这套系统，最终的价值不在于它有多“智能”，而在于它如何成为一个支点，撬动学生从被动接受知识，转向主动构建知识。它不是一个终点，而是一个起点——一个让软件测试这门课，真正活起来的起点。

本文还有配套的精品资源，点击获取

简介：面向高校软件测试课程设计和实训场景的Java Web评分工具，基于Spring+SpringMVC+MyBatis（SSM）搭建，运行在Apache Tomcat上。支持学生上传测试用例文件，系统按预设规则自动比对预期输出与实际执行结果，生成得分、错误定位及简要评语。后台提供MySQL数据库支持，压缩包内含完整可运行源码（src目录结构规范）、建库建表SQL脚本（dbscripts）、配置文件（configs）、项目说明文档（runwen.docx）以及两套答辩专用PPT模板（含系统演示页与技术要点页）。开发环境适配JDK 1.8、Maven 3.x和MySQL 5.7+，导入IDEA或Eclipse后修改数据库连接参数即可启动；配套文档覆盖需求分析、模块划分、核心判题逻辑（如输出格式校验、边界值匹配、异常捕获机制）及详细部署步骤，方便教师快速部署教学环境或学生开展二次开发。

本文还有配套的精品资源，点击获取