Spring Boot测试管理系统毕设：核心模块、技术选型与答辩攻略

很多同学后台问我，毕设题目看着挺常规，一到开题就没了底。比如“基于Spring Boot的软件测试管理系统的设计与实现”这种题目，乍一看就是个管理后台加增删改查，但真要动手，难点往往不在写代码，而在你怎么把“测试管理”这个词解释得让答辩老师信服。这篇就围绕这个题目展开，重点讲清楚测试管理系统应该具备哪些模块、哪些是真正加分的核心逻辑、Spring Boot技术栈怎么选型、程序跑起来之后有哪些隐藏问题和远程调试怎么配合，最后把源码结构、论文配图、演示环境这些交付细节一并理清。无论你是打算从零手写，还是在现成框架上做二次开发，这份梳理都能帮你少走弯路。

1. 这类题目的核心价值：软件测试管理到底在管理什么

1.1 别把“测试管理”做成缺陷登记表

我看到过不少同类毕设，做出来就是一个缺陷表CRUD，然后挂到Spring Boot后台就算完事。这种方案在系统演示时非常虚，因为答辩老师只要追问一句“你管理了哪些测试资产”，项目就立不住了。

软件测试管理系统的核心管理对象应该至少有四类：测试需求（需求用例关联）、测试用例、测试执行记录、缺陷生命周期。理想状态下还要覆盖测试计划、测试报告和项目成员分配。如果只做一张bug登记表，那你实现的是“缺陷跟踪系统”的极小一截，而不是“测试管理系统”。

这里有一个很实用的设计原则：不要追求功能数量多，要追求业务链路完整。比如你选“用例管理+执行记录+缺陷管理”三条核心链路，就已经能把测试工作流讲清楚了。系统里一个测试人员可以创建用例，把用例放入测试计划，执行用例产生通过/失败的结果，失败的用例自动关联一条缺陷，开发人员负责处理缺陷，测试人员验证关闭缺陷。这条闭环逻辑一旦做出来，项目的业务深度立即和普通增删改查拉开差距。

1.2 为什么这个题目适合Spring Boot技术栈落地

Spring Boot在当前Java生态里几乎已经成为企业级应用的默认起点。毕设选它，至少有三个好处：一是社区案例多，遇到问题更容易搜到解决办法；二是Spring Security、MyBatis-Plus、JPA等配套组件成熟，权限、持久层、参数校验都有现成方案；三是前后端分离的主流组合——Spring Boot后端加Vue，在文档撰写和演示效果上都容易获得高分。

还有一个现实因素：本地开发、部署演示时，Spring Boot的起步依赖能极大降低环境配置成本。一个内嵌Tomcat的jar包就能把整个系统跑起来，对Windows或Mac本机演示都很友好。相比SSH工程那种动不动就要手动配Tomcat的旧方案，Spring Boot确实更适合作为毕设项目的基础框架。

2. 技术栈和版本选择，先把地基的三个关键决策定下来

2.1 Spring Boot版本和JDK的搭配，不能只看最新版

这一点需要单独强调一下，因为很多同学上来就选Spring Boot 3.x加JDK 17，结果发现自己电脑上之前装的项目全是JDK 8，重新配置一堆环境变量，浪费了大量时间。而且有些学校机房或老师提供的嵌入式设备环境偏老，对JDK 17的支持并不好。

结合网上搜索“springboot版本太高”这类热词，就能看出很多人在版本问题上吃过亏。我的建议是：如果你的项目本身是中规中矩的增删改查加权限系统，Spring Boot 2.7.x + JDK 8是风险最低的组合。Spring Boot 2.7.x属于2.x系列的最后稳定版本，既兼容大量老教程，又比2.5、2.6多了很多修复补丁。JDK 8在企业里仍是存量主力，对机器性能没有额外要求，启动和打包速度也比较快。

提示：不是不能用Spring Boot 3.x，而是用到3.x时要注意两个坑。第一，javax.servlet包要改成jakarta.servlet，很多老代码里的import直接编译不过；第二，Spring Security 6的配置写法变化较大，如果你参考的是基于Spring Security 5的教程，改代码时要花不少时间。没有充分把握时，建议优先选2.7.x。

2.2 持久层选MyBatis-Plus还是Spring Data JPA

这个选择题几乎每个做Spring Boot毕设的人都要面对。结合项目需求，我的判断标准很简单：

• 如果论文里需要展示“复杂SQL统计”或“自定义多表分页查询”，选MyBatis-Plus更顺手。尤其像测试报告里的通过率统计、缺陷状态流转记录，这类查询用注解SQL或XML SQL写起来更直观。
• 如果你希望代码量少、实体类字段和表字段自动映射，选Spring Data JPA开发效率更高。它对小规模表结构的CRUD非常友好，一个Repository接口直接自带保存、删除、分页方法。

软件测试管理系统包含的定义表通常接近十张，业务主要是单表维护加少量统计查询。这两种方案都可以，但考虑到毕设论文中“SQL语句展示”是一个重要的加分点，MyBatis-Plus往往更能体现数据库设计能力。它在内置通用Mapper的基础上还保留了自定义SQL的能力，写起来灵活，出错了也容易排查。

2.3 前端方案的现实选择

大多数毕设作品会选择Vue做前后端分离。常见的组合是Vue 2 + Element UI，或者Vue 3 + Element Plus。想稳妥，建议确认你下载到的资料或者参考课程用的是哪一套，不要混搭。Vue 2现在虽然已经停止官方维护，但毕设场景里它还占有很大存量，如果你拿到的源码模板是Vue 2版的，直接升级Vue 3通常会因为组件API差异而报一堆错。

如果不想在前端浪费过多时间，可以优先考虑服务端渲染思路：Spring Boot + Thymeleaf + Bootstrap。这个方案能让你把注意力完全放在Java代码上，不用处理跨域、代理和前端打包问题。不过从视觉评分看，前后端分离的作品通常更“像样”，而且远程答辩时浏览器访问独立端口也更直观。最终看你的时间预算，时间充裕就Vue，时间紧张就Thymeleaf。

3. 系统模块与数据库表设计：从一张用例表延伸出完整业务链

3.1 角色与核心流程的界定

软件测试管理系统的最简角色模型可以定为三种：测试人员、开发人员、管理员。复杂一点还可以加入测试经理或项目经理，但毕设场景下三种角色足够覆盖业务，再多角色只是增加权限判断的复杂度。

用户故事可以这么梳理：

• 测试人员维护测试用例，按项目或模块创建用例，执行测试并记录结果，发现失败结果后提交缺陷。
• 开发人员查看分配给自己的缺陷，修改后更新缺陷状态并提交修复说明。
• 管理员负责用户管理、项目管理、数据字典维护，查看整体统计报告。

系统中的核心业务是“用例—执行—缺陷”三张表的关系。用例表记录“测什么、怎么测、预期结果”，执行记录表记录“哪一次测试跑到了这条用例、实际结果如何”，缺陷表记录“失败之后提交的bug及后续状态”。明确了这个流程，数据库表的设计会很自然，而不是把字段堆在一起。

3.2 核心表结构的拆解

我在做这个系统时，字段设计是这样规划的：

业务关系可以这样描述：一个项目下有多条测试用例；一个测试计划通过关联表关联多条用例；测试人员执行计划引出的用例并写入执行记录；执行记录结果如果是失败，可以联动创建缺陷。后面的统计报表，比如缺陷数量按状态分布、用例执行通过率、模块缺陷Top榜，都是对这些表做聚合查询。

数据库设计这里有一个实操建议：给核心业务表设置逻辑删除字段deleted，而不是物理删除。答辩时被问到“一条用例误删怎么恢复”，你就可以直接展开设计思路。这种细节虽然代码量不大，但很能在论文和答辩环节加分。

3.3 后端接口的REST设计与分页规范

接口路径尽量遵循资源化的命名方式。例如：

• GET /api/projects 查询项目列表
• POST /api/projects 新建项目
• PUT /api/projects/{id} 修改项目
• DELETE /api/projects/{id} 逻辑删除项目
• GET /api/cases?projectId=1&pageNum=1&pageSize=10 分页查询用例
• POST /api/cases 新建用例
• PUT /api/cases/{id}/execute 执行用例并提交结果
• POST /api/defects 提交缺陷
• PUT /api/defects/{id}/status 变更缺陷状态

统一返回结构可以设计为Result对象，包含code、message、data三个字段。这样前端Axios拦截器里只需要判断code是否为200，不用为每个接口单独写异常分支。分页参数统一用pageNum和pageSize，返回用包含total、records的对象，前端就能直接渲染表格和分页器。

4. 关键代码实现：JWT权限、用例执行与缺陷统计的落地细节

4.1 最简洁的JWT权限拦截写法

用户模块最常见的做法是Spring Security加JWT。但这个组合对初学者来说有一定门槛，因为Security的过滤器链配置稍微写错一点，接口就是401或403，而且排查问题半天摸不着头脑。

我当时基于毕设场景做了一个取舍：引入Spring Security作为认证框架，但在5.7版本后采用SecurityFilterChain的Bean配置方式，代码结构比较清晰。实际校验逻辑在OncePerRequestFilter里：

java复制@Component
public class JwtAuthenticationTokenFilter extends OncePerRequestFilter {

    @Resource
    private UserDetailsService userDetailsService;

    @Resource
    private JwtUtil jwtUtil;

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain) throws ServletException, IOException {
        String token = request.getHeader("token");
        if (token != null && !token.isEmpty()) {
            String username = jwtUtil.getUsernameFromToken(token);
            if (username != null && SecurityContextHolder.getContext().getAuthentication() == null) {
                UserDetails userDetails = userDetailsService.loadUserByUsername(username);
                if (jwtUtil.validateToken(token, userDetails)) {
                    UsernamePasswordAuthenticationToken authenticationToken =
                            new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
                    authenticationToken.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
                    SecurityContextHolder.getContext().setAuthentication(authenticationToken);
                }
            }
        }
        filterChain.doFilter(request, response);
    }
}

这个写法的核心逻辑是“每次请求都从Header里取token，解析出用户信息后放进SecurityContext”。后续controller里用@PreAuthorize("hasRole('TESTER')")就能控制具体接口的权限，不用到处手写权限判断。需要注意的一点是，角色名称如果是ROLE_TESTER，在注解里写hasRole('TESTER')，Spring会自动拼接前缀。

如果你的系统想做得更轻量，也可以不用Spring Security，而是写自定义拦截器实现同样的JWT校验。从演示效果看，功能没有差别，但使用Spring Security在论文的技术栈介绍里会更有分量。综合考虑答辩和开发效率，个人更推荐保留Security方案。

4.2 测试用例管理不只是增删改查

用例表字段较多，但最简单也最容易出错的地方是查询。前端列表往往需要同时按项目、模块、用例类型、优先级、用例名称模糊检索，多条件动态SQL怎么拼，是一个很好的加分点。

如果你用的MyBatis-Plus，可以用构造器：

java复制LambdaQueryWrapper<TestCase> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(StringUtils.isNotBlank(projectId), TestCase::getProjectId, projectId)
       .like(StringUtils.isNotBlank(keyword), TestCase::getTitle, keyword)
       .eq(caseType != null, TestCase::getCaseType, caseType)
       .orderByDesc(TestCase::getCreateTime);

如果你更想展示手写SQL能力，可以在Mapper中写这样的动态条件：

xml复制<select id="selectCasePage" resultType="com.example.vo.TestCaseVo">
    SELECT tc.*, p.project_name
    FROM test_case tc
    LEFT JOIN test_project p ON tc.project_id = p.id
    <where>
        tc.deleted = 0
        <if test="projectId != null">
            AND tc.project_id = #{projectId}
        </if>
        <if test="moduleName != null and moduleName != ''">
            AND tc.module_name LIKE CONCAT('%', #{moduleName}, '%')
        </if>
        <if test="priority != null">
            AND tc.priority = #{priority}
        </if>
    </where>
</select>

两条路都能走通，区别是你想在论文里展示哪方面的能力。左连接带出项目名称的做法虽然简单，却能让列表页显示更友好，很实用。

再比如用例编号的自动生成。我采用了一个很常见的策略：case_no字段由日期加数字组成，例如TC202411120001。后台通过查询当天已有数量来计算下一个序号。这个需求的实现逻辑不复杂，但能把“业务编号生成”这个真实场景带入项目，答辩时值得作为亮点讲。

4.3 测试报告统计的SQL与聚合实现

统计报表是很多同学最后才做甚至直接放弃的模块，但它在论文里的重要性非常高。一组图表能把系统的价值直接视觉化，也让系统看起来像一个“管理平台”，而不是一个“录入页面”。

主要统计指标可以做成三个接口：

一是缺陷状态分布：

sql复制SELECT d.status,
       COUNT(*) AS cnt
FROM defect d
WHERE d.project_id = #{projectId}
GROUP BY d.status

状态可以分为待处理、处理中、待验证、已关闭、已拒绝。前端用饼图展示即可。

二是用例执行通过率：

sql复制SELECT r.result_status,
       COUNT(*) AS cnt
FROM execute_record r
WHERE r.plan_id = #{planId}
GROUP BY r.result_status

result_status可以预设为PASS、FAIL、BLOCKED三种，统计出来之后算通过率，或者直接由后端算成百分比。

三是模块缺陷数量排行：

sql复制SELECT tc.module_name,
       COUNT(d.id) AS defect_count
FROM test_case tc
LEFT JOIN defect d ON d.case_id = tc.id
WHERE tc.project_id = #{projectId}
GROUP BY tc.module_name
ORDER BY defect_count DESC
LIMIT 10

这里要特别注意空值问题，LEFT JOIN时关联不到缺陷的模块，COUNT(d.id)不会统计NULL，所以不会误计0值记录。

注意：如果统计类SQL是控制层直接调用的，最好在Service层做一层封装并定义清晰的方法名。答辩时老师如果看代码，见Service层的getDefectStatusStatistics()、getExecutionPassRate()这样的方法，会觉得你的分层意识是清楚的。

5. 联调、远程调试与演示部署：最容易翻车也最容易被忽略的一环

5.1 Java远程调试的本质与启动参数

“远程调试”是这套交付经常被强调的卖点。技术本质上其实不神秘：Java虚拟机提供了JPDA（Java Platform Debugger Architecture），只要在JVM启动时加上一组参数，IDE就能通过网络端口连接上运行中的程序。

最常见的一组远程调试参数是：

bash复制java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 test-manage-system.jar

拆开解释：

• transport=dt_socket表示用Socket方式通信。
• server=y表示当前JVM作为调试服务器，等待调试器连接。
• suspend=n表示启动时不暂停，等前端连上来才停止；如果设为y，JVM会一直阻塞，直到调试器连上后再启动主程序，这通常只在排查启动阶段问题时用。
• address=:5005是监听端口。注意Java 9之前不用加:，直接address=5005；Java 9以后如果只写5005，通常也能用，但部分版本只监听本地回环地址，所以明确写成*:5005更通用。

我在实际操作中使用IDEA的Remote JVM Debug配置，Host填服务器IP，Port填5005，然后用Debug模式启动。打断点、看变量、实时表达式都能在本地生效。

要特别提醒的是：生产环境或答辩演示环境不要开着调试端口。远程调试会显著降低接口响应速度，而且5005端口如果暴露在公网，存在被攻击者利用的风险。更安全的做法是只在局域网测试环境开启，或者在不需要调试时去掉-agentlib参数重启服务。

5.2 跨域、端口冲突、数据库连接这些常规难题

前后端分离项目中，最容易翻车的不是业务代码，而是联调阶段的环境问题。这里整理我实际踩过的几个坑：

第一，跨域问题。 前端跑在8080端口，后端跑在8081端口，直接访问就会产生跨域。我在Spring Boot中写了一个全局配置类，实现WebMvcConfigurer，重写addCorsMappings方法，允许前端来源的地址访问：

java复制@Override
public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/**")
            .allowedOriginPatterns("*")
            .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
            .allowedHeaders("*")
            .allowCredentials(true);
}

如果项目用了Spring Security，还要额外注意Security自身的CORS过滤配置。有时后端放了跨域配置仍报跨域，就是因为Security过滤器先拦截了OPTIONS预检请求。

第二，端口占用。 Spring Boot默认端口8080非常容易被其他进程占用，尤其在做过Web开发的本机上。解决办法有两个方向：要么使用-Dserver.port=9090参数覆盖默认端口，要么把server.port配置统一写在application.yml里。看logs里“Port 8080 was already in use”时，不要瞎猜，直接换端口启动最省事。

第三，数据库版本与连接串。 MySQL 8.x版本的Driver不同，连接参数写法有差异。使用MySQL 8以上版本时，driverClassName常写成com.mysql.cj.jdbc.Driver，并附上serverTimezone=Asia/Shanghai参数。如果漏掉时区配置，查询时可能报SQLException，并且实际数据与本地时间差8个小时。

5.3 演示环境的稳定性清单

答辩演示通常发生在笔记本电脑或现场网络环境里，稳定性直接影响演示流畅度。我建议在正式展示前照着这个清单过一遍：

• 后端使用打包后的jar文件启动，而不是还在IDEA里Debug模式启动。
• MySQL服务设为开机自启，演示前清理掉无用的连接会话。
• Redis如果被引入到权限模块或缓存逻辑，必须确保Redis服务已经启动，否则登录接口直接失败。
• 如果演示时可能切换网络，Vue打包后的静态文件最好直接放到后端Spring Boot的static目录下，或者用Nginx部署在同一台机器上，避免出现静态资源地址变化的问题。
• 演示数据一定要提前准备好，至少包含两个项目、每个项目一个测试计划、计划里挂多条用例、执行记录覆盖通过和失败两种状态、若干不同阶段缺陷。这样演示时可以顺着“用例—执行—缺陷—报告”这条线直接跑通，临时造数据容易卡壳。

6. 源码结构与配套文档，决定项目分值的隐藏部分

6.1 后端代码分层与工程组织

很多同学在赶工时习惯把所有代码堆在一个包里，ServiceImpl和Controller长达几千行。表面上功能是跑通了，但论文里的架构图根本没法和代码对应上。比较好的工程结构是模块分包明确，让每个包名直接对应一个职责层：

code复制com.example.tms
├── common          // 统一结果、异常处理、常量、工具类
├── config          // 配置类：MyBatis-Plus、Security、CORS
├── controller      // 接口层
├── service         // 业务层接口
│   └── impl        // 业务层实现
├── mapper          // 数据访问层接口
├── entity          // 实体对象
├── dto             // 入参对象
├── vo              // 返回视图对象
└── security        // 认证过滤器与用户详情实现

配置文件里，至少要有application.yml和application-dev.yml两个场景。application-dev.yml配置本地开发环境数据库、日志级别；打包部署时用application-prod.yml指定不同的数据库地址和运行端口。通过Spring Boot的spring.profiles.active配置动态切换，属于非常标准的实践。

6.2 论文写作里不能少的设计图与测试数据

毕设文档质量高低，一半取决于图和表。论文中需要这些关键图片：

• 系统总体用例图
• 角色权限架构图
• 软件测试管理系统业务流程图（重点画用例执行到缺陷提交的闭环）
• 后端模块架构图
• 数据库ER图
• 核心表结构列表
• 关键接口时序图（比如用户登录认证流程）

尤其数据库ER图，建议用工具从建表语句直接生成，不要手动画。手绘ER图很容易漏字段，导致表格和代码不符。而软件测试管理系统的“测试报告统计”部分，如果能在文档里给出统计维度说明、SQL语句截图和前端图表截图，这份论文的完整度就会提升不少。

6.3 源码里必须留下的注释和README

既然交付物里包含源码，源码的可读性就应该当作衡量指标之一。你的项目不一定需要注释特别多，但每个Service方法必须有一段直白的注释说明“这个方法是干什么的、在哪里被调用”。Controller层的主要接口建议用Swagger注解或简单中文注释标明参数含义。

README文件是评判一个项目专业度的重要入口。至少需要包含：项目介绍、技术栈清单、环境要求、数据库初始化方式、启动步骤、默认账号、接口文档访问地址。如果还能附加演示视频链接或者部署说明，项目完整度会很高。

6.4 模块演示顺序和讲解话术建议

答辩时讲解项目的顺序也应该提前规划。不要从登录页开始一句一句念，更不要打开数据库逐表介绍，那样既耗时又没有重点。按照“背景—架构—业务闭环—亮点”的思路走是最稳的：

先介绍这道题目下系统解决的核心问题，说明有哪几类用户；再展示系统部署架构，前端加后端加数据库；然后按照“创建测试项目—维护测试用例—建立测试计划—执行用例并记录结果—提交缺陷—生成测试报告”的顺序走一遍演示；最后再重点讲一个你实现得最好的细节，比如缺陷状态机流转或执行记录与缺陷的联动接口。

缺陷状态流转是一个值得展开的点。我当时的实现是：缺陷有“提交、已指派、修复中、待验证、已关闭、重新打开”几种状态，每次变更都记录一条操作历史。演示时可以从测试人员角度提交缺陷，切换到开发人员账号修复缺陷，再切到测试人员账号验证并关闭缺陷。这个多角色切换演示直观展示了系统的权限划分，也说明了对缺陷全生命周期的覆盖。

最后补充几句实话

软件测试管理系统这种事看上去是“管理系统三件套”，但真正拉开档次的地方在于业务链路完整性、统计逻辑和代码规范。如果时间实在紧张，优先保核心闭环，后做边际功能。项目管理模块、附件上传、Excel导入导出这些功能都属于锦上添花，有余力再加。核心的测试用例、执行结果、缺陷状态、统计报表四条线做扎实，系统的交付价值就已经完整。根据我个人的开发经验，用Spring Boot做这个题目最稳住的方法，是一开始就把数据模型理顺，角色权限想清楚，然后再动手写业务逻辑。代码可以迭代，但数据库设计一旦跑偏，返工成本极高。希望这份梳理能让你避开我踩过的那些坑，省下更多时间打磨文档和演示效果。