合格与否以本校任务书和评价要求为准。从工程角度建议检查**能否完成一条业务、正确处理异常并留下可验证的结果。**菜单数量只能说明范围不能单独说明完成度。下面以 Web 业务类毕设为例给出一份工程自查清单。✅ 如果你想先了解项目案例可以参考蓝象1. 八项内容要能互相对应内容用“校园报修”检查什么用户学生提交报修维修人员接单处理权限学生只查看自己的工单维修人员只处理自己接单的工单核心业务从提交、接单、处理到报修人确认完成数据库保存报修人、接单人、状态与流转记录API 接口说明每个操作的输入、身份条件与返回结果异常处理缺少地点、越权操作、状态不符时有明确结果测试检查正常流程和失败场景记录预期与实际结果部署按说明在演示环境启动并能读写业务数据这是八个检查维度不是要求每个维度都做一个独立模块。2. 用一条业务串起页面、接口和数据这个教学方案的流程是学生提交后“待受理”维修人员接单后“处理中”标记处理完毕后“待确认”报修学生确认后“已完成”。每次操作都要回答谁能执行、当前状态是否允许、成功后保存什么。比如学生不能直接把“待受理”改成“已完成”维修人员也不能确认别人的报修结果。权限检查应在服务端执行并检查所操作的具体记录前端隐藏按钮不能代替授权判断。OWASP 授权指南3. 测试要有能核对的结果下面是建议用例未执行项目实测正常走完整条流程页面状态、数据库状态和流转记录一致另一名学生请求查看或确认该工单拒绝访问或修改缺少必填地点、跳过处理直接确认拒绝操作不产生错误业务数据再次确认已完成工单按本例规则拒绝不重复生成流转记录。每条保留“前置条件、操作、预期、实际结果、证据”。失败就记录并修复不能把预期直接填成“测试通过”。4. 交付时还要能复现、能解释建议随源码整理数据库结构和初始化方式、接口说明、运行版本、配置示例、启动步骤与测试记录配置示例中不放真实密钥。再在目标环境走一次核心流程确认重启后记录仍可查询。论文和答辩材料来自真实工作需求对应用户任务设计对应数据与流程实现对应代码测试对应实际记录格式按本校要求准备。先按八项清单补齐核心业务再扩展功能。后续围绕跑起来、看得懂、改得动、讲得清也可了解蓝象的项目实战方向。本文由 AI 辅助整理配图为 AI 编写脚本绘制的教学示意。