2026计算机毕业论文系统测试怎么写：用例设计与对比实验

[摘要] 系统测试与实验设计是计算机毕业论文里最能体现工作量的两章。本文给出三种用例设计技术的写法、压测方案四要素、阶梯加压曲线分析口径、对比实验三原则与四层自查清单。

关键词：计算机毕业论文系统测试测试用例性能测试对比实验评价指标2026

计算机毕业论文系统测试怎么写：从测试用例设计到对比实验，让"工作量"看得见

论文写到"系统测试"这一章，很多同学会陷入一个尴尬的循环：明明系统做了三个月，功能也写了不少，这章却只能写出一句"经测试，系统各项功能运行正常"。

这一章明明是展示工作量最有力的地方——测试用例的数量、覆盖的场景、压测的数据，本身就是工作量的证明。但大部分人把它当成了"证明系统没坏"的环节，而不是"展示系统有多好"的环节。

一、测试章节要完成两个任务：计算机毕业论文系统测试要证明的两件事

表 1

任务	回答的问题	证据形式
功能正确性	系统的每个功能在各种情况下都按设计工作吗	测试用例表 + 通过率
性能与非功能	系统在真实负载下表现如何	压测数据 + 指标对比

评审看测试章节，重点看三件事：

有没有覆盖到边界和异常排在首位。 只测"输入正确数据、结果正确"的用例，任何人都写得出。评审想看的是"输入为空会怎样""输入超长会怎样""两个人同时操作会怎样"。

有没有量化数据排在第二位。 "系统运行稳定"是废话，"在 500 并发下平均响应时间 180ms，P99 为 340ms，错误率 0.02%"才是证据。

有没有对比排在第三位。 单独一个数字读者无从判断好坏，必须有参照系——跟谁比、差多少、为什么。

二、功能测试：三种设计技术怎么用

功能测试用例的设计不需要学软件测试理论全套，掌握三种技术就够应付本科论文，写出来也显得专业。

技术一：等价类划分

原理：把输入数据分成若干"等价类"，同一等价类里的数据应该得到相同的结果，测一个代表值就够了。

以"用户注册"为例：

表 2

等价类	有效/无效	代表值
用户名长度 < 6	无效	"abc"
用户名长度 ≥ 6	有效	"abcdef"
用户名为空	无效	""
用户名为纯数字	无效	"123456"
密码含大小写+数字+特殊字符	有效	"Abc@123"
密码仅小写	无效	"abcdef"

怎么写进论文：把上面这张表直接做成测试用例表的"输入数据/预期结果"两列，每一类取一个代表值作为一条用例。读者一看就明白你的测试是有设计依据的，不是随手点的。

技术二：边界值分析

原理：错误往往发生在边界上，而不是中间。测边界值比测中间值更容易发现缺陷。

计算机毕业论文里最典型的边界：

表 3

边界类型	例子	要测的值
数量下限	至少上传 1 个文件	0 个、1 个
数量上限	最多上传 10 个文件	9 个、10 个、11 个
长度边界	用户名 6–20 位	5 位、6 位、20 位、21 位
分页边界	每页 20 条	19 条、20 条、21 条
时间边界	订单 30 分钟未支付自动关闭	29 分钟、30 分钟、31 分钟

这是最容易拿分的地方。 很多评审看到"上传文件数量为 11 时系统提示超出上限"，会立刻判断这个学生做事细致。

技术三：判定表法（处理复杂逻辑）

原理：当一个功能涉及多个条件组合时，用判定表列出所有条件组合和对应结果，避免漏测。

以"优惠券是否可用"为例，涉及三个条件：用户等级、订单金额、优惠券类型：

表 4

组合	等级	金额	类型	是否可用
1	普通	< 满减	满减券	否
2	普通	≥ 满减	满减券	是
3	会员	< 满减	满减券	是
4	会员	≥ 满减	满减券	是
5	任意	任意	折扣券	否（与订单叠加限制）

一个功能组合出 5–8 条用例，论文里就有 5–8 行表格，工作量立刻显得扎实。

测试用例表怎么排

一张规范的测试用例表长这样：

表 5

用例编号	测试模块	等价类/边界	输入数据	预期结果	实际结果	是否通过
TC-01	用户注册	用户名过短	用户名"abc"，密码"Abc@123"	提示"用户名至少 6 位"	一致	通过
TC-02	用户注册	密码强度不足	用户名"zhangsan"，密码"abcdef"	提示"密码需含大小写字母、数字、特殊字符"	一致	通过

注意"实际结果"和"是否通过"两列——很多同学只写"预期结果"，但评审想看的是你真的跑了，并且结果符合预期。如果某条没通过，写"未通过，已修复"并说明修复过程，这反而是加分项（说明你有真实测试过程）。

用例数量建议：本科论文写 30–50 条，覆盖 8–12 个功能模块，每个模块 3–5 条。数量写"共设计 42 条测试用例"比写"若干"强得多。

三、性能测试：让数据有参照系

性能测试是拉开差距的地方。多数人只写"系统响应速度快"，而这在评审眼里等于没写。

压测方案怎么写

要写清楚四件事：

测试环境——硬件配置、操作系统、数据库版本、JDK 版本、网络环境。这决定数据有没有意义。配置太低而数据好看，评审会怀疑。

压测工具与方法——JMeter / Gatling / Locust，模拟多少虚拟用户，阶梯加压还是固定压力，请求什么接口。

测试场景——读多写少（浏览为主）、读写混合（下单流程）、峰值场景（秒杀式突发）。

指标口径——这一条最容易被忽略，也最显得专业：

表 6

指标	定义	说明
平均响应时间	所有请求响应时间的算术平均	容易被慢请求拉低，单独看会失真
P95 / P99	95% / 99% 的请求在该时间内返回	真实用户体验由 P99 决定
吞吐量	单位时间内完成的请求数	常写 QPS / TPS
并发用户数	模拟的同时在线用户	说明系统的承载能力
错误率	失败请求数 / 总请求数	超过 1% 通常算不可接受

为什么要同时报平均值和 P99？ 因为平均值会骗人。1000 个请求里 999 个 20ms、1 个 5 秒，平均值是 25ms，看着很好，但那 1 个卡了 5 秒的用户已经关页面了。P99 才反映真实体验，这也是你论文显得专业的关键点。

阶梯加压：把曲线画出来

性能测试最有说服力的呈现方式是阶梯加压曲线：逐步增加并发用户数，记录响应时间和吞吐量的变化。

典型曲线有三个阶段，写论文时要把这个分析写出来：

表 7

阶段	现象	含义
上升段	并发增加，响应时间基本不变，吞吐量线性上升	系统还有余力
拐点	响应时间开始明显上升，吞吐量增长放缓	系统容量到达临界点
饱和段	并发继续增加，吞吐量不再上升甚至下降，响应时间急剧上升	瓶颈出现，需要扩容或优化

找出拐点并给出它的数值，就是这一章的核心结论。 写法示例：

有数据、有拐点、有结论，这段话就是硬的。

找出并说明瓶颈

如果性能不理想，要定位瓶颈并给出分析——这是技术深度的直接体现。

常见瓶颈与定位手段：

表 8

现象	可能的瓶颈	定位方法
响应时间随并发线性上升	数据库连接池耗尽	看连接池等待时间、活跃连接数
某接口慢但 CPU 空闲	SQL 未走索引	打开慢查询日志，看执行计划
CPU 打满	业务逻辑在应用层做重计算	看火焰图，定位热点方法
内存持续上涨	存在内存泄漏	观察 GC 频率与老年代占用
写入变慢、读取正常	磁盘 IO 瓶颈	看磁盘 IO 等待占比

写法：

"发现问题 → 定位原因 → 优化 → 验证效果"这条完整链路，是性能测试章节拿高分的关键。 只报告"性能不好"没有意义，能定位并优化才有技术含量。

四、对比实验：证明你的改进有效

如果你在论文里声称"本文提出的方法优于现有方法"，那必须有对比实验来支撑。没有对比实验的"优于"是无效主张。

对比实验的三条设计原则

原则一：控制变量。 对比实验唯一有效的前提是"除了被测方法，其他条件完全一致"。

表 9

变量	怎么控制
数据集	所有方法用同一份预处理后的数据
数据划分	训练/验证/测试按同一比例随机划分一次，固定下来
特征处理	相同的归一化方式、相同的缺失值处理
评价指标	用同一套脚本计算，不手算
随机性	多次运行取均值和标准差，或固定随机种子

原则二：基线要合理。 至少选三类基线：

表 10

基线类型	举例	作用
简单基线	热门推荐、随机推荐、平均值	证明你的方法确实超过了"瞎猜"的水平
经典基线	原始协同过滤、传统协同优化算法	证明你的方法比主流方法好
最新基线	近两年提出的同类方法	证明你的方法跟得上研究前沿

没有简单基线是常见疏漏。只跟最新方法比，如果你的方法赢了，没人知道你赢了什么水平。

原则三：指标要多个。 单一指标容易被质疑"你只是挑了个对自己有利的指标"。

推荐组合：

表 11

场景	推荐指标
推荐/分类	Accuracy、Precision@K、Recall@K、F1、AUC
检索/排序	NDCG@K、MAP@K、HitRate
预测	RMSE、MAE、R²
分类不平衡	准确率不够，要加 Precision/Recall/F1
系统性能	平均响应时间、P95/P99、吞吐量、错误率

注意准确率的陷阱。 类别不平衡时（比如欺诈样本占 1%），全预测为"正常"的模型准确率也有 99%。这时候单报准确率会被评审直接质疑，必须报 AUC 或 F1。

消融实验：证明每个模块都有用

如果你的方法有多个改进点（改进 A + 改进 B + 改进 C），那就需要消融实验（ablation study）：每次去掉一个模块，看性能掉多少。

表 12

配置	模块 A	模块 B	模块 C	准确率	召回率
完整方法	启用	启用	启用	0.873	0.742
去掉 A	未启用	启用	启用	0.851	0.738
去掉 B	启用	未启用	启用	0.842	0.701
去掉 C	启用	启用	未启用	0.819	0.726

这张表能回答评审最爱问的问题："你这些改进，到底哪个最有用？" 答案一目了然：模块 C 贡献最大。

如果消融实验显示某个模块去掉后性能几乎不变，那说明这个模块没有价值——这是很有价值的自我审查结论，写进论文反而显得诚实且严谨。

实验结果怎么写

不要只放图表，要写分析：

这段话包含：结论、具体数字、对趋势的解释。第三句最值钱——它证明你不只是在描述图表，而是理解了背后的原因。

五、测试章节自查清单

功能测试

• 用例表有编号、模块、输入、预期、实际、结论六列
• 覆盖了等价类划分，论文里体现了分类依据
• 覆盖了边界值（数量、长度、分页、时间）
• 复杂逻辑用了判定表或多条件组合
• 用例总数明确写出（30–50 条量级）
• 至少覆盖 8 个功能模块
• 有未通过用例的说明（如有）

性能测试

• 写清了测试环境（硬件、OS、数据库、JDK 版本）
• 写清了压测工具、并发梯度、测试场景
• 指标口径明确（尤其 P99 的定义）
• 有阶梯加压曲线，并分析了拐点
• 给出了最优承载并发量或吞吐量结论
• 有瓶颈定位与分析（若有性能问题）

对比实验

• 基线包含简单基线、经典基线、最新基线
• 控制变量写清楚了
• 多个评价指标，不靠单一指标
• 准确率之外还有 AUC/F1 或 NDCG
• 有消融实验（若方法含多个改进点）
• 结果分析含"为什么"而不只是"是什么"

呈现

• 图表清晰可读，坐标轴有名称和单位
• 每张图在正文里都被引用和解读
• 表格没有截图（必须是可编辑的表格）

六、测试环境与论文的一致性

最后一个容易被忽略但很致命的问题：论文里写的测试环境，要和真实跑测试的环境一致。

常见的翻车场景：实验室机房是 16 核机器，你在论文里写"测试环境为 4 核 8G"，评审去查你的项目部署文档发现对不上；或者你在服务器集群上跑出了漂亮数据，论文里却写单机部署。这类"技术造假"盲审老师扫一眼就能发现。

正确做法：测试前固定环境，论文如实写。配置低一点没关系，真实的数据比漂亮但不可信的数据有价值得多。

测试用例表、判定表与压测方案模板可在五网精选模板库查取。

参考来源

1. Apache JMeter 官方文档，性能测试工具，https://jmeter.apache.org/。

2. Gatling 官方文档，开源性能测试工具，https://www.gatling.io/。

3. Postman 官方文档，API 接口测试与调试工具，https://www.postman.com/。

4. JUnit 官方文档，Java 单元测试框架，https://junit.org/。

5. GB/T 7713.1-2025《信息与文献 编写规则 第1部分：学位论文》，2025年8月1日发布，2026年2月1日实施，国家市场监督管理总局、国家标准化管理委员会，https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=36C05B5738C54D42B4B262525320B52F。

6. 五网精选模板库，https://www.5ol.com/moban.html。

本文由五网（www.5ol.com）用户/编辑整理，来源标注见参考来源章节。压测环境、并发梯度与指标口径以实际测试记录为准，工具用法与参数以各工具官方文档为准。