若本文对你有帮助，请点赞、关注我哟！大四上学期课设之一，仅供参考。
第一章 系统分析
1.1 需求分析
1.1.1 功能性需求分析
（1）个人信息：教师和学生查看自己的个人信息。
（2） 修改密码：教师和学生修改自己账号的登录密码。
（3） 我的课程：教师端添加课程并可指定班级来参加课程。
（4）题库：教师端添加试题并选择试题组卷。
（5）发布考试：教师端发布相应考试以对学生进行测试。
（6）成绩列表：考试结束后，教师端添加学生成绩，并显示学生成绩。
（7）学生列表：教师端显示所授学生名单。
（8）课程：学生端可选择相应课程。
（9）考试：当教师端发布考试后，学生可以通过此功能来参加考试。
（10） 成绩：当考试结果发布后，学生端可以通过这里来查看成绩。
1.1.2 性能需求分析
经过功能需求分析以及实际情况分析，我们可以发现，本成绩管理系统应满足以下性能需求：
（1）规范、完善的基础信息设置。
（2）对所有学生成绩信息进行集中管理。
（3）对操作人员设置不同的操作权限，为管理员提供修改权限功能。
（4）提供快速成绩检索功能。
（5）实现成绩录入、查询、删除的功能。
（6）系统运行稳定、安全可靠。
（7）网站设计页面要求美观大方、个性化，功能全面，操作简单。
（8）整体结构和操作流程合理顺畅，实现人性化设计。
1.1.3 系统采用的数据库及框架技术分析
本系统采用MySQL数据库进行连接，它具有性能卓越、服务稳定的优点。而且它的体积小，支持多种开发语言，安装方便，易于维护。它使用的核心线程是完全多线程，支持多处理器，这可以提升运行的效率。不仅如此，它通过一个高度优化的类库实现SQL函数库并像他们能达到的一样快速，通常在查询初始化后不该有任何内存分配。没有内存漏洞。
本系统框架使用Spring Boot和Spring Data JPA。对于Spring Boot，它支持快速开发，因此也特别适合用来构建微服务系统，它还给我们封装了各种经常使用的套件，可以使我们的开发更加方便。它拥有非常简洁的安全策略集成，可以在一定程度上提高系统的安全性。对于Spring Data JPA，我们可以将它拆分成两个部分来看。Spring Data简化了基于Spring框架应用的数据库访问，包括对关系型、非关系型、Map-Reduce、云数据服务等。它具备ORM框架的对象关系映射的功能，提供统一的Repository接口实现CRUD、分页、排序等相关操作，也提供了统一的模板类。JPA是一种规范，它简化了现有持久化的开发，并且充分吸收了Hibernate、TopLink、JDO等框架。Spring Data JPA是全自动框架，不需要自己写SQL,当然也可以自己写SQL实现。
1.2 系统数据流图
图1 顶层数据流图
图2 系统数据流图
第二章 系统总体结构设计
2.1 体系结构
图3体系结构图
2.2 系统的功能结构
2.3 概念结构设计
图5 E-R图
2.4数据库设计
2.4.1数据库逻辑结构设计
图6 E-R图
2.4.2数据库的完整性约束
图7 表detailscore
图8 表exam
图9 表result
图10 表joinlesson
图11 表lesson
图12 表login
2.4.3数据库的安全性
两个MySQL数据库通过日志同步方式实现双主节点热备份，通过haproxy实现数据库集群负载均衡。当某一个MySQL节点宕机时，保证服务正常运行，从而实现数据库的高可用和大流量并发。
第三章 详细设计
3.1 设计概述
本系统功能丰富，界面精美。在教师端，有个人信息、修改密码、我的课程、题库、发布考试、成绩列表、学生列表功能；在学生端有个人信息、修改密码、课程、考试、成绩功能。系统拥有非常高效的执行效率，对于学校的成绩管理有着极大的帮助。系统可根据学校的需求完成相应工作。本系统具有高度的可靠性，能够为学校节约大量成绩管理的精力。
3.2系统规范要求
需求验证很重要，如果在构造设计开始之前，通过验证基于需求的测试计划和原型测试来 验证需求的正确性及其质量，就能大大减少项目后期的返工现象。
在需求验证过程中，要对需求文档中定义的需求执行多种类型的检查。
有效性检查----对于每项需求都必须证明它是正确有效的，确实能解决用户面对的问题。 一致性检查。在需求文档中，需求不应该冲突，即对同一个系统功能不应出现不同的描述或相互矛盾的约束。
完备性检查----需求文档应该包括所有系统用户想要的功能和约束。 现实性检查，检查需求以保证能利用现有技术实现。 可检验性检查，描述的需求能够实际测试。
可跟踪性检查，需求的出处被清晰地记录，每一系统功能都能被跟踪到要求它的需求集合，每一项需求都能追溯到特定用户的要求。
可调节性检查，需求变更能够不对其他系统带来大规模的影响。 可读性检查，需求说明能否被系统购买者和最终用户读懂。
3.3 系统功能设计
在教师端，有个人信息、修改密码、我的课程、题库、发布考试、成绩列表、学生列表功能；在学生端有个人信息、修改密码、课程、考试、成绩功能。教师端与学生端的考试、成绩等功能一一对应。
第四章 系统实现
4.1 界面设计原则
（1）简易性
界面的简洁是要让用户便于使用、便于了解、并能减少用户发生错误选择的可能性。
（2） 用户语言
界面中要使用能反应用户本身的语言，而不是游戏设计者的语言。
（3）记忆负担最小化
人脑不是电脑，在设计界面时必须要考虑人类大脑处理信息的限度。人类的短期记忆极不稳定、有限，24小时内存在25％的遗忘率。所以对用户来说，浏览信息要比记忆更容易。
（4）一致性
一致性是每一个优秀界面都具备的特点。界面的结构必须清晰且一致，风格必须与游戏内容相一致。
（5）清楚
在视觉效果上便于理解和使用。
（6）用户的熟悉程度
用户可通过已掌握的知识来使用界面，但不应超出一般常识。
（7）从用户的观点考虑
想用户所想，做用户所做。用户总是按照他们自己的方法理解和使用。
通过比较两个不同世界(真实与虚拟)的事物，完成更好的设计。如：书籍对比竹简。
（8）排列
一个有序的界面能让用户轻松的使用。
（9） 安全性
用户能自由的作出选择，且所有选择都是可逆的。在用户作出危险的选择时有信息介入系统的提示。
（10） 灵活性
简单来说就是要让用户方便的使用，但不同于上述。即互动多重性，不局限于单一的工具(包括鼠标、键盘或手柄)。
（11）人性化
高效率和用户满意度是人性化的体现。应具备专家级和初级玩家系统，即用户可依据自己的习惯定制界面，并能保存设置。
4.2 功能设计实现
（1）程序部分源代码
图13 目录结构
图14 登陆拦截器
图15 ExamController
图16 ScoreController
图17Reposity
图18 StuReposity
图19 实体类
（2）运行截图
图20 登陆页
图21 课程页
图22 成绩列表
图23 学生课程
图24 学生页成绩列表
第五章 系统软件测试
5.1 测试目的
软件测试的目的是尽可能早的找出软件产品中潜藏的缺陷，并确保其得以修复，也就是让用户对产品有更好的体验，保证软件的高质量。软件测试的另外一个目的就是降低软件的开发成本，除了降低开发成本，还可以降低因软件缺陷带来的商业风险。如果软件的缺陷过多，也会降低合作企业的信任度，从而造成商业上的一些损失和风险，进行测试则会降低商业风险。测试是在用户使用软件之前提早介入，进行软件质量的保障。只有经过了软件测试这一环节，才能把软件交付到用户手中。公司的人员才对软件的信心更高，不至于把软件交付出去之后，时常担心用户的投诉或产品有致命的风险。
5.2 测试方法
（1）黑盒测试（Black Box）
测试内容：黑盒测试是把测试对象看做一个黑盒子，利用黑盒测试法进行动态测试时，需要测试软件产品已经实现的功能是否符合功能设计要求，不需测试软件产品的内部结构和处理过程。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
（2）白盒测试（White Box）
测试内容：设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。
白盒测试通常被认为是单元测试与集成测试，期中有六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖。
5.3 测试用例
