简介：一套C#编写的在线考试系统源码，面向正在学习C# Web开发的学生、培训机构及需要快速搭建在线考试平台的高校教师，完整覆盖试卷生成、题目自拟、自动批改三大核心功能，并设置学生、教师、管理员三角色权限体系，可用于课程设计、毕业设计或教学管理系统改造。资源包共133个文件，约1.66MB，主体为47个cs逻辑代码文件与39个aspx页面文件，另含SQL Server数据库文件（mdf/ldf）、CSS样式表、图片素材等项目必备组件，可在Visual Studio 2010环境中直接打开编译，运行后即可体验从登录到考试、阅卷、管理的完整流程。系统基于SQL Server 2008存储试题、考生信息与成绩数据，支持教师自定义题目和按条件生成试卷，自动批改能即时反馈得分，管理端可维护学生和教师账号，帮助理解真实Web项目的分层结构与权限设计。已有1372人学习下载，得益于清晰的页面命名和源码注释，读者可以逐模块对照学习，快速掌握C#与数据库交互、Session权限控制、动态出题等关键开发技能。
1. 拿到 .rar 源码之后，先别急着双击运行
这份 C# 在线考试系统源码，我前后翻了三遍。第一遍花半小时扫目录结构，第二遍把数据库脚本跑起来，第三遍跟着学生端完整走了一遍答题流程。说实话，网上这类源码不少，但大多数停在“能跑但不敢改”的级别。这份不一样的地方在于，生成试卷、考试管理、学生端、教师端四条业务线分得很干净，确实可以拿来改造成培训机构考核、企业内部测评这类真实场景。
如果你正面临“领导丢来一个在线考试系统需求，预算为零，时间三天”的情况，这份源码是很好的起点。但源码到手不等于能直接上线，你得先搞清楚它属于哪种架构、数据库里有哪些表、组卷和交卷的链路是怎么走的。这篇文章我就从源码剖析、核心算法、状态管理、权限控制、典型踩坑五个方向，把它拆开讲清楚。
1.1 这套系统到底“在线”在哪里
很多人一听到“在线考试系统”，脑子里默认是浏览器打开的那种 B/S 系统。实际上在培训机构机房、企业内部考试这类环境里，C/S 形态的考试系统反而更常见：服务端部署一套 Web API 负责题库、组卷、成绩存储，教师端和学生端用 C# WinForms 客户端，管理员再用一个 Web 管理页面做全局配置。
这种混合架构的好处很实在：客户端环境固定，Canvas 答题、键盘监听、切屏检测都更容易做，而且考试过程中即使网络抖动，客户端本地已经缓存了试卷快照，不会因为断网就全军覆没。源码里服务端用 ASP.NET Core Web API，客户端是 WinForms，数据层走 SQL Server，这条链路你拿到手后第一步就要确认清楚，后面所有改造都围绕它展开。
1.2 读懂项目骨架比读懂每一行代码更重要
解压 .rar 之后，先别急着按 F5。按我的习惯，先画一张项目结构图。核心项目一般是这几个：
Exam.Entity：实体类，对应数据库里的表，比如 Question（题目）、ExamPaper（试卷）、ExamPaperQuestion（试卷-题目关联）、ExamRecord（考试记录）、User（用户）。Exam.DAL：数据访问层，负责 SQL 操作或 EF Core 的 DbContext。Exam.BLL：业务逻辑层，组卷算法、自动判分、状态流转都在这里。Exam.API：Web API 服务，提供登录鉴权、试卷下发、答案提交等接口。Exam.WinClient：教师端和学生端的 WinForms 程序。SQL目录：数据库初始化脚本，通常包含建表语句和基础测试数据。
我见过很多人一上来就打开某个界面文件狂改，结果改完发现数据出不来，因为表结构和业务层根本没匹配上。正确的打开方式是：先跑数据库脚本，再用 Navicat 或 SSMS 把表关系捋一遍，最后才看代码。
2. 自动组卷算法：随机抽题背后的那点数学与边界
生成试卷是整个系统的灵魂。很多源码里的“随机组卷”就是一句ORDER BY NEWID()或Random.Next()从题库里随机挑几道题，这种实现在题目数量少、规则简单的时候勉强能跑，一旦要求按题型、难度、章节、知识点按比例出题，就完全不够用了。
2.1 随机抽题的正确写法：洗牌而不是重复随机
假设要从 500 道单选题里抽出 20 道，如果每次都用Random.Next(0, list.Count)去取，会出现重复题目，你得额外维护一个已选集合。更优雅的做法是 Fisher-Yates 洗牌算法，先打乱列表，再取前 N 个：
static void Shuffle<T>(List<T> list, Random rng) { for (int i = list.Count - 1; i > 0; i--) { int j = rng.Next(i + 1); (list[i], list[j]) = (list[j], list[i]); } }洗牌之后取前 20 道，既保证不重复，又让每次生成的试卷顺序都不同。源码里如果有独立的PaperGenerator类，大概率用的就是这个思路。
2.2 按分数配比抽题的实现思路
实际组卷需求通常是这样：总分 100 分，单选题 20 题每题 2 分共 40 分，多选题 10 题每题 2 分共 20 分，判断题 10 题每题 2 分共 20 分，简答题 2 题每题 10 分共 20 分。同时每个题型里还要保证难度分布，比如容易 30%、中等 50%、困难 20%。
实现时不能一个题型一个题型孤立地抽，而是先按分组条件查询符合条件的题目 ID 列表，再对每个分组做洗牌，按配额取题。配额不够的情况必须提前检查，否则会出现试卷分数凑不满 100 分的情况。源码里我的建议是不管原来的逻辑怎样，你都要把“科目 + 题型 + 难度”这三个维度作为分组键，拼成Dictionary<string, List<int>>，再统一计算每组抽题数量。
2.3 试卷生成后的快照冻结
这里有一个很隐蔽的坑：如果试卷明细表里只存了QuestionId，没有存题干、选项、答案的内容副本，那么考试过程中一旦题库里的题目被老师修改，考生看到的试卷也会跟着变，甚至会出现“学生考完试对答案，发现答案选项变了”的事故。
正确做法是生成试卷时直接生成快照。也就是说ExamPaperQuestion表里除了QuestionId，还要冗余保存题干内容、选项内容、正确答案、分值、排序号。我见过的高质量源码在这一点上做得很好，生成试卷时把题目内容全部复制进试卷明细表，考试时读的完全是快照数据，跟题库彻底解耦。
2.4 题库不够时的自动补偿
组卷时还会遇到一种崩溃场景：指定难度和题型组合后，可用题目数量不够。这时候必须做容错。合理的策略是分级放宽条件：
- 先按“题型 + 难度 + 章节”精确匹配。
- 数量不足时，放宽到“题型 + 难度”。
- 仍然不足，放宽到“仅题型”。
- 如果连题型都不够，直接返回组卷失败，并在日志里记录是哪个科目、哪个题型缺题。
组卷失败比组出来的卷子缺斤少两更安全，至少你不会发一张只有 80 分的试卷出去。源码里如果没做这层补偿逻辑，建议你自己加上，否则上线后一定会被题库维护人员频繁找麻烦。
3. 考试过程管理：一个状态机解决所有意外
试卷生成之后，考试如何开始、中断、结束，这里面的状态管理比想象中复杂得多。很多 C# 源码在考试流程上写得很随意，学生点“开始考试”就把试卷显示出来，点“交卷”就写入成绩。中间一旦发生断网、客户端崩溃、超时自动交卷，数据就乱了。
3.1 从预考到交卷的六种状态
一份能用的考试系统源码，考试记录的状态至少要有这几种：
public enum ExamStatus { NotStarted = 0, // 已分配，未开始 InProgress = 1, // 进行中 Submitted = 2, // 已交卷 Timeout = 3, // 超时自动交卷 Aborted = 4, // 异常中断 Resumed = 5 // 中断后恢复 }关键不在枚举定义，而在状态流转的约束。比如只有InProgress状态才能提交答案；Timeout状态只能由服务端定时任务触发；Resumed状态必须是在上一次记录有未提交答案时才能进入。源码如果在服务端有独立的ExamSession接口处理这些流转，就说明设计者考虑到了异常情况，如果没有，你改造成本会很大。
3.2 倒计时用定时器，而不是随便开线程
交卷倒计时是考试客户端最常见的功能。很多人喜欢写while(true) { Thread.Sleep(1000); }来倒计时，然后交卷时用Thread.Abort()把线程杀掉。这是非常糟糕的做法，线程中止时如果正持有数据库连接或文件句柄，资源不会正常释放，UI 线程还容易出现假死。
正确姿势是使用系统级定时器。WinForms 里可以用System.Windows.Forms.Timer，但考试程序我更推荐System.Threading.Timer，因为它不依赖 UI 消息循环，即使客户端最小化或拖拽，倒计时也不会停：
_timer = new System.Threading.Timer(CheckDeadline, null, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(1)); private void CheckDeadline(object state) { if (DateTime.Now >= _examEndTime) { SubmitPaper(auto: true); _timer.Change(Timeout.Infinite, Timeout.Infinite); } }注意CheckDeadline是在线程池线程里执行的，如果里面要更新 UI 控件，必须Invoke回 UI 线程，否则会抛跨线程访问异常。
3.3 防作弊与断线续考的兜底设计
比较完整的源码会在客户端记录切屏次数，也就是窗体失去焦点或用户切换到其他应用时，记录一条日志，交卷时把日志一并提交。还有一个更高明的做法是选项乱序：同一个考生同一道题，每次看到的选择题选项顺序不同，这比单纯记录切屏更能防住“左邻右舍对答案”。
断线续考的兜底也要靠服务端。客户端启动时会请求一次/api/exam/resume，服务端根据ExamStatus判断这个考生是否有未完成的试卷，如果有就返回试卷快照和剩余时间。客户端本地也建议把已答答案实时缓存到本地文件，即使进程被杀，重开后还能把未提交的答案恢复回来。
4. 学生、教师、管理员三个角色的权限切分
标题里“学生、教师”这两个词说明这是一套多角色系统。很多考试系统源码在权限上做得非常“表面化”：教师登录后界面里不显示学生菜单，学生登录后不显示管理菜单，但 API 层完全没有校验，懂 HTTP 的人直接调接口就能越权。这是上线前的重大隐患。
4.1 权限校验必须发生在服务端，而不是界面
在 Web API 项目里，正确做法是用 JWT Token 加角色特性（Attribute）。每个受保护的接口都显式声明允许哪些角色访问：
[Authorize(Roles = "Teacher")] [HttpPost("api/paper/generate")] public IActionResult GeneratePaper(GenerateRequest request) { // 只有教师角色能调用 }学生提交答案的接口，必须从 Token 里解析出当前用户 ID，而不是相信前端传过来的studentId参数。我审计过不少开源考试系统，这里是最容易出问题的点：直接拿明文的学生 ID 查数据，换个 ID 就能替别人考试。
4.2 教师端核心：题库维护和试卷管理
教师端界面上，最高频的操作是录入题目、批量导入题目、配置组卷规则、监考和阅卷。批量导入题目这一块，很多源码用Microsoft.Office.Interop.Excel去读取 Excel 文件。实话说，在服务器上跑 Office COM 组件非常不稳定，权限不够会崩，并发多了会卡。我更推荐用 NPOI 或 ClosedXML 这类托管库，不需要目标机器安装 Office，性能和稳定性都好得多。
主观题阅卷一般是二级审核制：教师 A 初评，教师 B 复核，分数差异超过阈值时由管理员仲裁。源码里如果已经有ScoreRecord表，通常会带FirstScore、SecondScore、FinalScore三个字段，这在真实考核场景里非常实用。
4.3 学生端答题交互：答案草稿和键盘细节
学生端的答题体验直接影响考场秩序。比较完善的做法是左侧答题卡、右侧答题区域，已答题目标记成绿色，未答题标成灰色，点击题号直接跳转。答案要实时保存到本地Dictionary<int, string>，用户点击“上一题/下一题”时只改当前高亮，不触发网络请求，只有交卷时才统一提交。
这里有个我在多个项目里踩过的坑：在KeyUp事件里弹MessageBox。比如用户在填空题里按回车弹出提示“是否确认本题答案”，看起来没毛病，但 MessageBox 会让输入框失去焦点，关闭后焦点回来，KeyUp 事件又被触发一次，如果你的代码没有做防重入处理，就会出现回车键“穿透”的诡异现象。
正确做法是在 KeyUp 里设置e.SuppressKeyPress = true，然后把弹窗逻辑放到BeginInvoke里异步执行，避免事件重入。
5. 源码上线前最值得修的四个坑
不管源码写得再完整，真正部署到服务器和学生电脑上时，总有一些细节会跳出来打你脸。下面这几个是我在类似项目里反复遇到的问题，你拿到源码后建议提前排查。
5.1 数据库连接字符串和脚本初始化
解压包里通常有一个App.config或appsettings.json，里面写着数据库连接字符串。但很多源码默认指向localhost的 SQL Server，而且数据库脚本可能是按 SQL Server 2012 写的，如果你的环境是 LocalDB 或 SQL Express，跑脚本时会报语法不兼容。
我的建议是：不要直接双击.sql脚本，先打开文件看开头有没有CREATE DATABASE，里面用了哪些数据类型。如果发现datetime2、ROW_NUMBER()这类语法，说明脚本比较新，需要 SQL Server 2008 以上版本。还有一点，脚本里如果有内置账号密码，登录后第一件事就是改掉，否则系统上线等于裸奔。
5.2 P/Invoke 调用 C++ DLL 时的 AccessViolationException
有些考试系统为了做摄像头抓拍或人脸识别，会通过 P/Invoke 调用 OpenCV 等 C++ 库写好的原生 DLL。如果你在运行源码时遇到类似System.AccessViolationException: Attempted to read or write protected memory，先别怀疑人生，这通常不是数据问题，而是互操作问题。
常见的坑有三个。第一，32 位和 64 位不匹配：C# 程序是 x86 编译，但 DLL 是 x64 的，直接崩溃；第二，结构体内存对齐：C++ 的struct在 C# 里声明时没加[StructLayout(LayoutKind.Sequential)]，字段偏移对不上；第三，回调函数被 GC 回收：你把一个 C# 委托传给了原生 DLL，运行几次突然崩了，因为委托对象被垃圾回收了。
解决办法是：确认平台目标跟 DLL 一致；用DllImport时声明CharSet和CallingConvention；在类里保存一个委托字段，防止被回收：
private NativeCallback _callback; // 保持引用，防止 GC public void Init() { _callback = OnNativeEvent; NativeApi.SetCallback(_callback); }5.3 WinForms 客户端发布与安装包制作
源码能跑，不等于能装到五十台考试机上。教师端、学生端用的是 WinForms 的话，制作安装包时我推荐用自带发布功能做单文件发布。在 Visual Studio 里右键项目选择“发布”，目标框架选带运行时的 win-x64，发布模式选“单文件”，这样拷出一个 exe 就能运行，不需要目标机器装 .NET 运行时。
如果你需要真正的安装向导，可以用 Inno Setup 封装一层，写一个简单的脚本把 exe 和配置文件、OCR 模型文件一起打进安装包。注意如果是 x86 的客户端，Inno Setup 里也要选 32 位安装模式，否则装在 64 位系统上路径会重定向到 Program Files (x86)，配置文件可能和程序文件分离，导致找数据库配置时扑空。
5.4 成绩导出和文件处理
考试结束后，导出成绩是刚需。如果你的源码导出 Excel 用的是 Office COM，建议趁早换成 OpenXML 或 CSV。用 CSV 是最简单可靠的方案，但中文乱码问题要处理，记得在文件开头写入 BOM 头：
var bytes = Encoding.UTF8.GetPreamble() .Concat(Encoding.UTF8.GetBytes(csvContent)) .ToArray(); File.WriteAllBytes(path, bytes);如果要求导出真正的 xlsx 文件，用 ClosedXML 这种第三方库，两三行代码就能生成带格式的 Excel，还不需要服务器装 Office。这个替换能避免掉你在生产环境遇到的最诡异的一类问题：Excel COM 组件在 Windows Server 上权限配置不正确时，导出偶尔成功偶尔失败，而且没有规律。
最后再分享一点我个人的习惯：拿到任何考试系统源码，第一件事不是看界面，而是把“组卷 → 生成试卷快照 → 考生开始考试 → 中断/超时处理 → 提交判分”这条主链路完整读一遍。这条链路只要逻辑严谨，其他功能都是锦上添花；这条链路有漏洞，界面再漂亮也救不了。你按上面的思路把它拆透，等于在动手改代码之前，先拿到了一张完整的系统地图。
本文还有配套的精品资源，点击获取
