校园二手交易系统开发报告

在大学校园环境中，学生群体存在着大量的二手物品交易需求。一方面，学生在入学时会购置各类学习、生活物品，如教材、宿舍用品等，随着毕业或学业阶段的推进，这些物品往往还有使用价值，但对本人而言不再必需；另一方面，低年级或有相应需求的学生，希望能以更经济的方式获取这些二手物品。然而，以往校园内的二手交易多以线下零散形式进行，主要依赖于校园摆摊，非商品交易平台发布闲置等方式。这种模式存在诸多弊端：信息传播范围有限，往往只能在局部区域内流转，导致很多有需求的学生无法及时获取物品信息；交易效率低下，从信息发布到达成交易，需要耗费大量的时间和精力进行沟通协调；信息透明度不足，交易双方缺乏有效的信息核实和保障机制，容易产生交易纠纷，且交易记录难以留存和追溯，不利于校园二手交易的规范化管理。为解决校园二手交易现存的这些问题，满足学生对高效、便捷、规范的二手交易平台的需求，提升校园二手资源的利用效率，我展开了对校园二手交易市场系统的开发工作，旨在打造一个专门服务于校园学生的线上二手交易平台。

1. 系统的简要描述

（1）用户管理子系统：“用户”指的是此软件系统的用户，该子系统主要负责处理与系统用户相关的功能，包括以下功能：用户注册、用户登录、用户实名认证、用户信息管理。

（2）商品管理子系统：该子系统主要负责与商品管理相关的功能，包括以下功能：创建商品、修改商品、浏览商品、搜索商品、收藏商品、将商品加入购物车、查看商品卖家详细信息。

（3）交易管理子系统：该子系统主要负责与交易管理相关的功能，包括以下功能：联系卖家、申请交易、查询交易、交易评价。

（4）后台管理子系统：该子系统主要面向系统管理员，用于对整个平台进行管理与维护。具体功能有：用户管理、商品管理、交易管理。

需求分析
1. 用户分析

校园二手交易市场软件的核心用户为在校学生群体，包含以下细分类型：

卖方用户：有闲置物品待出售的学生，典型场景为毕业季清理闲置、日常置换物品等。
买方用户：有低价购买实用物品需求的学生，典型场景为新生采购必需品、临时使用物品（如考研资料、演出服装）、追求性价比消费等。
潜在用户：暂未产生交易需求，但可能因季节变化（如换季衣物）、学业阶段变化（如升学换教材）、活动需求（如社团活动道具）转化为买卖方的学生。

下面表格呈现了用户特征分析：

表2-1用户特征分析

特征类别	维度	具体内容
核心属性特征	身份属性	年龄集中在18-25岁，受教育程度较高，对互联网工具接受度高，熟悉社交软件和电商平台基本操作
	消费特征	消费能力有限，偏好“高性价比”“实用性”物品，对价格敏感，重视物品真实状态（如新旧程度、功能完整性）
	时间特征	时间碎片化，交易时间集中在课余、周末及毕业季
	空间特征	活动范围局限于校园及周边，对“同校当面交易”需求强烈，对跨校邮寄交易接受度较低（信任成本高、运费不划算）
行为习惯特征	信息获取	习惯通过校园社群（班级群、社团群）、朋友圈、线下跳蚤市场获取二手信息，但信息分散、效率低
	交易偏好	倾向于选择同校师生交易（信任度高），重视交易便捷性（线下面交地点推荐、短时间内完成交易）
	决策因素	物品价格、卖家信用、物品实拍图、交易保障（如支持当面验货）
	痛点	卖家发布信息流程繁琐、买家咨询分散难管理、闲置物品长期卖不出去。买家难以快速找到所需物品、担心卖家身份虚假，担心买到劣质/虚假物品、与卖家沟通效率低

1. 需求分析
  1. 需求获取

一、需求来源

重用已有系统的软件需求：参考成熟平台的基础需求，再适配校园场景，确保需求合理且可落地，参考已有系统比如“闲鱼”，梳理它们的核心功能之后，复用参考平台的基础需求，去掉一些复杂功能，同时补充校园专属需求特点。
从软件系统的用户和客户出导出软件需求：校园二手交易市场的典型用户是学生，结合大学生的校园需求，如卖闲置教材、实时线上沟通等需求，并参考自己或同学买卖二手物品的痛点，将这些痛点转化为需求。
分解其它系统的需求产生新需求：将“非校园二手系统”的需求拆解，结合校园场景改造，产生新的针对性需求，拆分它们的功能模块如淘宝的“购物车”“商品评价”，QQ的“点对点聊天”，拆解后改造为校园二手需求。
软件开发者构思和创作软件需求：基于二手交易的通用流程（发布商品→浏览商品→沟通→下单→评价），构思每个环节的必需需求，增加校园专属需求，结合校园场景构思差异化需求，体现系统的针对性。

二、获取方法

调查问卷

设计涵盖校园学生二手交易习惯、需求、对线上平台期望等内容的问卷，通过线上校园平台、线下班级等渠道在校园内广泛发放。通过对回收问卷的统计分析，了解学生在二手交易中的痛点、对系统功能的具体需求。

观察法

观察校园内现有的二手交易场景，如公告栏二手物品张贴区、校园二手交易群的交流情况等。记录交易信息的发布形式、师生沟通交易的过程、交易成功与失败的案例及原因等，从中总结出线下交易的不足，进而推导线上系统需要具备的功能，如更高效的信息展示、更便捷的沟通方式等。

现场观摩

观察校园线下二手交易场景，如定期的跳蚤市场，记录业务过程，比如卖家摆展、买家咨询、议价、成交、物品交付的整个过程，以及交易完成后双方的反馈。

软件原型

为解决需求描述抽象化导致的理解偏差问题，本次开发引入墨刀原型设计工具进行可视化需求验证。具体过程如下：

根据前期用户访谈和问卷调查结果，使用墨刀工具快速搭建系统核心页面（如首页、用户中心等），并通过工具内置的交互逻辑功能实现页面跳转、按钮点击等基础操作模拟，形成可操作的交互式原型。将墨刀原型向用户进行演示，引导用户完成典型操作流程（如浏览商品、发布闲置、查看个人记录等），实时记录用户对页面布局、功能逻辑、操作便捷性的反馈意见，基于反馈，通过墨刀工具快速修改原型（如调整按钮位置、优化分类导航结构等），形成新的原型版本并再次验证，直至用户对需求呈现达成共识。最终通过可视化的原型将抽象需求转化为直观的交互体验，有效减少了需求理解偏差，也通过快速迭代提升了需求确认的效率。

部分原型界面展示：

图2-1商品首页原型图2-2用户中心

1. 1. 需求描述
功能需求

校园二手交易系统的用户可执行以下核心功能：

1.基础账户操作：支持用户注册账号，完成登录操作（若忘记密码可通过“找回密码”功能辅助）；用户需完成实名认证（该过程会要求后台审核），并可进行个人信息维护。

2.商品交互功能：用户可查询商品、查看商品列表及详情（在查看商品详情时，可扩展实现联系卖家、查看卖家信息、加入购物车、购买商品、发表评论等操作）；同时支持用户发布商品。

系统管理员负责平台的后台管理，功能涵盖：

1.商品信息管理：可对商品信息进行全生命周期管理，包括查看商品信息、修改商品信息、删除商品及新建商品。

2.用户信息管理：涵盖用户资料信息管理、用户买卖消息管理、用户登录信息管理、用户浏览记录管理、用户收藏管理及实名认证审核等，实现对平台用户的全面管控。

3.订单信息管理：支持对订单的全方位操作，包含查看订单信息、修改订单信息、删除订单及新建订单。

详细的功能需求、质量需求以及需求优先级分析在专题报告大模型辅助的需求分析部分

用例图可以描述系统的功能范围与系统参与者（用户、管理员）与系统功能（用例）的交互关系，下图是系统功能的用例图描述：

图2-3用例图描述

1. 1. 需求建模

一、功能建模

在校园二手交易系统开发的需求结构化分析阶段，功能建模采用数据流图作为核心工具。通过分层数据流图的构建，从系统顶层环境图开始，明确外部实体与系统的边界及交互关系，清晰呈现“用户注册登录”“商品发布与管理”“订单交易”“评价沟通”“后台审核”等核心业务流程的数据流走向。

顶层DFD聚焦系统与外部实体的整体交互，界定系统功能范围。

中层DFD对顶层流程进行分解，细化关键子过程，明确各子过程间的数据传递。

底层DFD进一步拆解复杂子过程，补充数据存储细节与具体数据流。

通过数据流图的分层建模，直观表达系统功能与数据的关联，为后续系统设计提供清晰的功能逻辑依据，确保需求分析的完整性与一致性。

图2-4校园二手交易系统0层数据流图

图2-5校园二手交易系统1层数据流图

图2-6校园二手交易系统2层数据流图

二、数据建模

在校园二手交易系统的数据建模阶段，采用实体-关系图（ER图）对系统核心数据实体及关联关系进行可视化表达，ER图中，核心实体包括“用户”“商品”“订单”“买卖消息”等。

各实体通过属性描述其核心特征：如“用户”实体包含用户名、密码、姓名、性别、联系电话、学号等属性，“商品”实体涵盖商品ID、名称、类别、价格、发布时间、状态（在售/已售）等属性；“订单”实体则记录订单编号、交易商品、交易双方、下单时间、交易金额、订单状态等关键信息；“沟通记录”实体记录会话ID、沟通双方、消息内容、发送时间等信息。

实体间的关联关系通过关系菱形标识：如“用户”与“商品”存在“发布”（一对多）和“收藏”（多对多）等关系；“用户”与“订单”存在“创建”（一对多）关系；“商品”与“订单”存在“包含”（一对一）关系，具体可见ER图。

通过ER图的数据建模，进行数据分析，直观呈现了系统数据的核心构成与关联规则，为后续数据库表结构设计（如实体到表的映射、关系到外键的转化）提供了直接依据，确保数据存储逻辑与业务需求的一致性。

图2-7校园二手交易系统ER图

三、行为建模

状态转换图是一种描述系统对内部或外部事件响应的行为模型。它描述系统状态和事件，事件引发系统状态的转换，而不是描述系统中数据的流动。在校园二手交易系统的行为建模阶段，采用状态转换图对用户、商品、订单三类核心业务对象的生命周期行为进行可视化建模，以清晰呈现其状态流转逻辑与触发条件。

用户状态转换图：围绕“未注册→待注册→已注册未认证→实名审核中→已认证”的链路展开，体现用户从首次进入系统到完成校园身份认证的全流程。

图2-8用户状态转换图

商品状态转换图：聚焦商品从发布到交易结束的状态变化，包含“用户提交商品信息→审核中→在售/审核失败（回退）”的初始流程，精准体现商品发布、审核、交易、更新的行为逻辑。

图2-9商品状态转换图

订单状态转换图：覆盖线下交易场景中订单的全生命周期，形成完整的订单行为闭环。

图2-10订单状态转换图

四、数据字典

数据字典以一种系统化的方式定义在分析模型中出现的数据对象及控制信息的特性，给出它们的准确定义，包括数据流、数据存储、数据项、数据加工以及数据源点、数据汇点等，是分析模型的核心。下面给出部分核心内容：

1.数据存储

名称：商品信息

描述：二手商品的详细数据

定义：

商品信息=商品ID+商品名称+类别+描述+价格+数量+图片+卖家ID+状态

商品ID=10{数字}20（英文=[0-9]）

商品名称=1{汉字}50

描述=文本型（商品成色、规格等说明）

价格=数值型（≥0，单位：元）

数量=数值型（>0）

图片=png/jpg

卖家ID=字符型（关联用户信息表）

状态=[“已上架”|“已售出”]

2.数据流

名称：用户信息（以用户注册为例）

描述：用户注册的核心数据

定义：

用户注册信息=用户名+密码+学号+联系方式

用户名=1{汉字或字母}20

密码=6{字母或数字}16（字母=[“A”-“Z”，“a”-“z”]，数字=[“0”-“9”]）

真实姓名=1{汉字}20

学号=1{数字}15（学生学号）

联系方式=11{数字}11（手机号）

3.数据处理

表2-2核心数据处理

名称	简述	输入数据流	加工逻辑	输出数据流	处理频率
生成订单	买家提交订单的处理流程	商品信息、用户ID	校验商品库存→整合用户信息→生成唯一订单ID→更新订单状态为“待支付”	订单信息	用户不定时
商品发布	卖家提交商品的流程	商品信息（名称、类别、描述等）、卖家ID	校验商品信息完整性→生成商品ID→标记状态为“已上架“	上架商品信息	卖家不定时

软件设计
1. 系统体系结构设计
  1. 体系结构风格选择

在校园二手交易系统的体系结构风格选择中，我选取了MVC架构，这既符合 MVC架构本身的设计理念，又能精准适配系统的业务特点，同时与我选取的基于python的django框架适配：

（一）MVC是一种经典的软件架构模式，其核心优势在于通过高内聚、低耦合的设计思想，实现代码模块化与业务逻辑的清晰分离：

1.分层清晰，职责单一

Model(模型）：负责数据逻辑与存储交互，封装数据结构、业务规则（如商品状态校验、订单状态流转逻辑）及数据库操作（通过DjangoORM与MySQL交互）。

View（视图）：专注于数据展示与用户界面，处理前端页面渲染（如商品列表页、订单详情页），不涉及业务逻辑。

Controller(控制器）：作为中间层，接收用户请求（如“发布商品”“提交订单”），调用模型处理数据，再将结果传递给视图展示，协调Model与View的交互。

2.可维护性与可扩展性强

分层设计使代码模块化，修改某一层（如调整UI样式仅需调整View，优化数据校验仅需修改Model）不会影响其他层，便于系统迭代（如后续新增“商品推荐”功能，只需扩展Model的算法逻辑，无需改动View和Controller的核心流程）。

3.适配校园二手交易系统的业务特点

系统的核心功能（用户管理、商品发布、订单交易、评价互动等）与MVC架构的分层逻辑高度契合，具体体现为：

数据密集型业务适配Model层：系统涉及大量数据（用户信息、商品属性、订单状态等），且存在复杂的数据关联（如“订单-商品-用户”的多对多关系）。Model层通过DjangoORM映射MySQL数据表，封装数据校验（如商品价格必须为正数）、状态转换规则（如订单从“待付款”到“已付款”的条件），确保数据一致性。

多样化交互场景适配View层：系统需面向不同用户提供差异化界面（如管理员的“商品管理页”、卖家的“商品管理页”），且界面可能随需求迭代（如新增“商品推荐”UI）。View层层通过Django模板引擎或前端框架渲染页面，仅负责“数据展示”，当界面需求变化时，只需修改模板文件，无需调整后端业务逻辑。

流程化操作适配Controller层：系统核心流程（如“下单→支付→发货→确认收货”）需严格的步骤控制，且涉及用户请求的分发与处理。Controller层（在Django中由视图函数/类视图承担）接收用户请求（如POST请求“创建订单”），调用Model层的订单生成逻辑，再根据处理结果跳转至对应View（订单详情页/错误提示页）。

所以，MVC架构的“分层解耦”特性，与校园二手交易系统“数据复杂、界面多样、流程严谨”的业务特点形成精准匹配。同时，Django框架本身与MVC架构理念完全兼容，进一步降低了技术栈适配成本，使架构设计与开发实现形成闭环。因此，选择MVC架构是该系统在技术合理性与业务适配性上的最优解。

1. 1. 体系结构设计

HIPO图可以描述软件总的模块层次结构（H图），又可以描述每个模块的输入输出数据、处理功能及模块调用的详细情况（IPO图）。

图3-1校园二手交易系统层次图

图3-2核心模块IPO图

1. 软件结构设计
  1. 接口设计

一、用户界面设计

（1）设计遵循原则

1.用户熟悉：界面布局采用常见的电商类APP或网站结构，如首页顶部搜索栏、用户中心、分类导航，中部商品展示，可以让学生快速入手。

2.一致性：整体色调选用符合理工大学的色彩（如蓝色和黄色结合、浅蓝色背景），按钮样式、字体大小、图标风格保持统一。比如“发布商品”“加入购物车”等按钮，在不同页面都使用相同的形状、颜色和交互反馈。

3.意外最小化：在用户进行商品删除、订单取消等破坏性操作时，弹出确认对话框，询问是否确定操作，避免误操作。

4.可恢复性：当用户操作出错（如填写发布商品信息时表单错误），给出明确的错误提示，并保留已填写的正确信息，方便用户修改。

（2）交互方式选择：

图形化界面：整体界面采用图形化设计，用图标表示不同功能（如购物车图标、消息图标等），通过窗口、按钮、对话框进行信息提示和交互，提升视觉体验。

（3）信息表示方式：

1.直接操纵与浏览：商品详情页面支持用户点击“我要购买”“加入收藏”等按钮直接操纵，进行交易或收藏操作；而商品列表页面主要供用户浏览，减少多余交互元素，专注信息展示。

2.文本与数字：商品描述等语义、状态类信息用文本展示，如“九成新，无损坏，使用一年”；商品价格、数量等量化信息用数字展示，如“¥50”“库存3件”。

3.信息变更提示：当有买家留言或卖家回复时，会在界面展示红色气泡提示用户有消息未进行处理，当用户发送的消息被对方读了之后，会更新消息下面的未读为已读，同时提示时间，确保消息实时性。

4.精确信息与数据关系：对于商品价格、库存数目等精确信息，直接显示数字；对于浏览次数等数据仅仅展示类似100+的大致信息，降低认知负担。同时对于某商品卖家所收到的买家评价以好评率的数字和星级评分直观展示。

（4）设计过程：

1.初步设计：针对校园二手交易需求，先依据师生发布、浏览、交易二手商品的需求初步设计交互界面，确定首页（商品展示）、商品详情页（查看商品信息）、发布页（发布商品）、个人中心页（订单、收藏、设置等），明确各界面的输入（如搜索关键词、发布商品信息）、输出（如商品列表、交易结果提示）及界面元素（输入框、按钮、图片展示区等）。

2.建立界面间的跳转：设计界面间的跳转逻辑，如从首页点击商品进入详情页，从详情页可跳转到发布者个人主页或直接发起交易，从分类页选择分类后跳转到对应商品列表页等，保证跳转流畅自然。

3.精化设计：对初步设计的界面进行精化，调整布局、色彩、字体等以提升美观度和易用性，例如优化商品图片展示比例使其更清晰，调整按钮位置使其更符合操作习惯。

4.评审设计：最后邀请同学朋友评价设计好的界面，收集反馈意见并迭代修改，确保界面符合校园用户的使用需求和习惯。

二、外部接口设计

数据库接口（与mysql的交互接口）

数据库接口作为系统核心数据存储的交互接口，用于实现系统与MySQL数据库的连接、数据读写等操作，是系统内部模块与数据库之间的“桥梁”。

核心功能：

建立数据库连接：通过数据库驱动（Python的PyMySQL）与MySQL建立连接，确保系统能访问数据库。

数据增删改查：用户注册时将账号、加密密码、邮箱等信息插入数据库；商品发布时存储商品名称、价格、图片路径等数据；用户查询商品时从数据库读取对应记录；订单状态变更时更新数据库中的订单信息等。

事务处理：在涉及多步数据操作的场景（如商品卖出时同时更新订单记录和商品信息），通过事务接口保证操作的原子性，避免数据不一致。

邮箱服务接口（用于密码重置功能）

实现通过邮箱发送“密码重置链接”的功能，依赖第三方邮箱服务提供商的接口（网易邮箱）。

核心功能：

发送密码重置邮件：当用户点击“忘记密码”并输入注册邮箱后，系统调用邮箱接口，按固定格式生成邮件内容，发送到用户邮箱。

邮箱发送状态反馈：接口返回邮件是否发送成功（如成功、失败原因：邮箱不存在/格式错误等），系统根据反馈提示用户（如“重置邮件已发送，请注意查收”或“邮箱不存在，请核对后重试”）。

三、内部接口设计

内部接口时用来说明本系统之内的各个系统元素之间的接口的安排，通过设计合理的内部接口，可以使模块间仅通过接口交互，修改一个模块的内部逻辑，只要接口不变，其他模块无需修改，降低耦合，同时标准化的接口可被多个模块复用，并且简化测试。下面给出核心模块用户下单、商品发布和用户登录模块的内部接口设计与交互逻辑：

表3-1用户下单模块接口设计

接口名称	视图函数名	请求方法	输入参数	核心功能	交互说明
创建订单	create_order	POST	goods_id/quantity/shipping_address/contact_phone、notes	生成唯一订单号，计算总价，创建OrderInfo	返回JSON结果（含订单号）；校验商品状态（未删除、未卖出），否则返回失败信息
购物车操作	cart	GET/POST	POST：商品ID	GET：查询当前用户购物车商品；POST：添加商品到购物车（校验状态，避免重复）	购物车数据包含商品总价、数量；若已添加则提示“已在购物车”
订单状态更新	update_order_status	POST	order_id/new_status	按规则更新订单状态（如“待付款→已付款”），同步商品状态	仅买家可操作自己的订单，返回JSON结果（成功/失败信息）
订单记录查询	purchase_record	GET	-	查询买家的订单，支持分页	返回订单记录页面，按状态分类展示订单列表
卖家订单查询	my_sold_orders	GET	-	查询当前用户作为卖家的订单	返回卖出订单记录页面，按创建时间倒序展示
提交评价	write_review	POST	order_id/rating（评分）/content（评价内容）	创建Review，关联订单并更新状态为“已完成”	仅“待评价”订单可提交，成功后跳转订单记录页

表3-2商品发布模块接口设计

接口名称	视图函数名	请求方法	输入参数	核心功能	交互说明
发布页面展示	release_goods	GET	-	验证登录状态，渲染商品发布表单	未实名则跳转登录页；已实名返回发布商品页面
商品发布提交	release	POST	基础信息：title、type、price等；图片：picture（主图）、desc_images（附加描述图）	校验数据合法性，创建GoodsInfo及图片关联	发布成功重定向首页；失败返回发布页并提示错误
商品修改（回显）	edit_goods	GET	id（商品ID）	验证权限（仅发布者可修改），回显商品数据到修改表单	未登录跳转登录页；越权访问返回错误提示
商品修改（提交）	edit_goods	POST	同发布接口参数+ id	校验修改后的数据，更新商品信息（支持更新图片）	修改成功跳转发布记录页；失败返回修改表单并提示错误
商品删除	delete_goods	POST	id（商品ID）	逻辑删除商品（isDelete=True），仅发布者可操作	返回JSON结果（成功/失败信息），前端刷新商品列表
发布记录查询	release_records	GET	-	查询当前用户发布的未删除商品，支持分页	返回发布记录页面，展示商品列表及分页控件

表3-3用户登录模块接口设计

接口名称	视图函数名	请求方法	输入参数	核心功能	交互说明
登录页面展示	login_page	GET	-	渲染登录表单，回显Cookie中的用户名	前端访问时返回login.html，携带Cookie中的username
登录验证	login_handle	POST	number（学号）、password（密码）	校验用户身份，记录登录日志，设置Session	验证成功后调用Django内置login()，设置相关信息到Session，重定向首页；失败则返回错误提示
登出	logout	GET	-	清除登录状态（内置）和自定义Session	清除Session中的相关信息,重定向首页或登录页
密码重置	reset_password_handle	POST	Number/email/verify_code（验证码）/password等	验证验证码，更新用户密码	重置成功后清除验证码Session，跳转登录页；失败则返回错误信息

1. 1. 数据设计

将需求分析阶段得到的ER图转换为如下所示的关系模式集合：

图3-3用户关系

图3-4消息关系

图3-5商品关系

图3-6订单关系

在上述关系模型设计过程中，遵循以下原则：

每个实体在ER图中通常会转化为一个关系（即数据库中的表）。实体的每个属性转化为该关系的列。如用户实体转化为user_userinfo表。
在1:1关系中，任意一个实体的主键可以作为外键添加到另一个实体的表中。
在1:N关系中，N方表包含指向1方表的外键。如一个用户可能发布多个商品，则用户ID作为goods_goodsinfo的外键。
在N:N关系中，直接用关系表示。如用户与商品收藏关系是N:N，那就直接建立一张商品收藏表。

设计说明：

删除逻辑：商品和订单采用is_delete字段（而非物理删除），便于数据恢复和历史记录查询，符合DjangoORM的常用实践。
时间字段：用datetime类型并设置自动更新，无需代码手动维护更新时间。
外键约束：所有关联字段设置外键并级联删除，确保数据一致性（如用户删除后，其发布的商品也删除）。
索引优化：针对高频查询场景（如“用户查自己的订单”“筛选未卖出的商品”）创建联合索引，避免全表扫描，提升MySQL查询效率。
1. 1. 过程设计

程序流程图是一种比较直观形象的描述过程的控制流程的图形工具，下面借助这一工具体现核心模块的过程设计：

图3-7商品下单流程图图3-8发布商品流程图

图3-9用户登录流程图

系统实现
1. 编程语言及开发环境介绍
  1. python+Django+mysql

在校园二手交易系统的开发中，我采用的是Python语言，搭配Django框架和MySql数据库构建开发环境，我在选择时主要参考了以下因素：

(1)编程语言与框架选择

应用领域适配性

校园二手交易系统涉及用户管理、商品发布、订单交易、数据查询等复杂业务逻辑。Python作为面向对象语言，具备出色的灵活性与可读性；Django框架则提供了“一站式”的Web开发解决方案，内置用户认证、ORM、后台管理系统等模块，能高效支撑系统的核心功能，大幅降低开发复杂度。

开发效率与工具生态

Python拥有丰富的第三方库生态，Django的脚手架工具可快速生成项目结构，结合其自带的Admin后台，能够在短时间内完成系统原型搭建与功能迭代。对于校园二手交易这类需要持续优化的应用，这种高效性尤为关键。

开发与学习成本

Python语法简洁直观，Django的文档与社区支持完善，即使是开发经验较浅也能快速上手。选择开发人员熟悉的技术栈，可节省学习与培训资源，加快开发进度，同时若为团队开发，也可降低后续维护的沟通成本。

(2)数据库选择

数据处理与数据库应用适配性

校园二手交易系统涉及大量数据存储与关系型操作，MySQL作为成熟的关系型数据库，支持复杂的SQL查询、事务处理，能高效管理用户信息表、商品信息表、订单表等核心数据存储，确保数据的一致性与完整性。

平台支持与可移植性

MySQL具备良好的跨平台兼容性，可在Windows、Linux、macOS等主流操作系统上稳定运行，适配校园内不同开发环境的部署需求，同时支持与Python、Django框架的无缝集成，保障技术栈的协同性。

综上，Python+Django+MySQL的技术组合，在应用领域适配、开发效率、团队能力匹配、数据处理等方面均展现出显著优势，能充分满足校园二手交易系统的业务需求与长期迭代要求。

1. 1. 编程风格与规范

（一）代码格式与可读性：

1.遵循PEP8规范：缩进使用4个空格，每行代码长度不超过79个字符，函数/类之间空两行，语句后不添加多余空格。

2.注释清晰：模块顶部添加文档字符串说明功能；复杂逻辑（如订单状态流转、权限校验）添加单行注释解释设计思路；避免“自解释代码”过度注释。

3.代码块拆分：单个函数长度不超过50行，复杂业务逻辑（如支付流程）拆分为多个子函数，通过函数名体现功能。

（二）命名规范：

1.变量/函数：采用小写字母+下划线，如user_id、get_goods_list()，避免拼音或缩写。

2.类名：采用首字母大写的驼峰式，如 GoodsModel，且类名需体现实体或功能（避免 MyClass 等无意义命名）。

3.常量：采用全大写+下划线。

4.数据库相关：表名使用小写+下划线（如 goods_info、user_auth），字段名与模型类属性保持一致（如模型 GoodInfo的 price 属性对应表字段 price）。

1. 1. 开发环境介绍

（一）开发语言与框架

Python：版本3.10（Django4.2的稳定支持版本，兼顾新特性与兼容性），通过pyenv或conda管理多版本环境隔离。

Django框架：版本4.2.7（长期支持版，含ORM优化、异步视图等特性，保障项目稳定性）。

（二）数据库系统

MySQL：版本8.0（支持JSON字段、窗口函数等高级特性，优化二手商品信息的存储与查询），通过PyMySQL驱动与DjangoORM交互。

NavicatPremium16：可视化管理数据库表结构、执行SQL查询、备份数据。

（三）开发工具与IDE

PycharmProfessional2023.2:支持Django项目的智能提示、调试、数据库可视化，内置PEP8代码检查与格式化功能。

Git（版本2.40.1）+GitHub，通过分支管理（main主分支、dev开发分支、功能分支如feature/goods-publish）保障代码迭代的安全性。

1. 代码重用实践
  1. 开源代码复用

本系统充分利用Python、Django及Web开发领域的开源生态，通过引入经过验证的开源库、框架和组件，避免重复开发基础功能，聚焦校园二手交易的核心业务逻辑。具体实践如下：

（一）核心框架与基础库复用

1.DiangoWeb框架：

作为系统的核心开发框架，复用其MVT架构、ORM数据库交互、用户认证、权限管理等核心功能：

直接使用django.contrib.auth模块实现用户注册、登录、会话管理，无需从零开发身份认证逻辑。

通过DjangoORM封装MySQL交互，用Goods.objects.filter()等API替代原生SQL，减少数据库操作的冗余代码。

复用DjangoAdmin后台系统，快速搭建商品审核、用户管理的后台界面，仅需通过模型类注册（admin.site.register(Goods)）即可实现基础CRUD功能，后续仅针对校园场景定制审核流程。

2.Pillow:

复用该开源图片处理库实现商品图片的上传、压缩和格式转换：

调用Image.open()和Image.save()处理用户上传的图片，自动压缩超过10MB的图片至500KB以内（通过thumbnail()方法）；

转换非JPG/PNG格式的图片为统一的WebP格式，减少前端加载时间。

3.开源代码的二次开发与定制

基于Bootstrap的前端组件定制：

复用Bootstrap的栅格系统和组件库，针对校园场景调整样式，复用Bootstrap的modal、dropdown等基础组件，通过CSS覆盖和JS扩展适配管理系统需求。

1. 1. 自定义代码复用

1.通用权限校验

封装RealNameRequiredMixin和StudentRoleMixin，在商品发布、订单管理等视图中复用，保证在购买商品、发布商品前已完成实名认证。

2.模块组件复用：

将导航栏、商品卡片、分页控件等抽离为独立模板片段，通过{%include%}在首页、列表页、详情页中复用，统一页面风格。

1. 软件测试
  1. 测试计划

软件测试将分为以下四个阶段：

单元测试

测试对象：单个模块的核心函数/类（如用户登录验证函数、商品发布数据校验方法、订单价格计算逻辑等）。
测试内容：

模块接口正确性：输入合法/非法参数验证接口响应。

内部逻辑完整性：覆盖条件分支、循环执行等独立路径。

数据处理准确性：如价格计算、订单状态更新等核心业务逻辑。

错误处理有效性：异常输入（如空值、超出范围参数）的捕获与反馈。

规范检查：借助静态代码分析工具SonarQube，检查代码规范、潜在缺陷（如逻辑错误、性能隐患），适配Python代码质量检测。

测试策略：以白盒测试为主，开发人员主导，确保被测单元隔离（不依赖其他未测试模块或外部资源）。
测试工具：借助Python官方内置框架unittest，无需额外安装，支持用例组织、自动化执行，适配Django项目的模块测试（如视图函数、模型方法测试）。

集成测试

测试对象：模块间交互逻辑（如登录模块与商品发布模块、商品模块与订单模块的协作）。
测试内容：

模块接口兼容性：数据传递格式、参数类型匹配度（如用户ID从登录模块传递到商品模块的一致性）。

交互逻辑正确性：如商品发布后状态同步到订单模块、下单后商品状态更新（未卖出→已卖出）。

数据一致性：跨模块操作时MySQL数据同步（如创建订单时商品数量、订单总价的关联更新）。

测试策略：采用渐增式集成策略（自底向上结合），先确保各单元测试通过，再逐步集成模块，兼顾黑盒与白盒测试技术，同步执行回归测试防止功能回退。
测试工具：采用Django内置测试类DjangoTestCase，支持模拟HTTP请求、数据库事务回滚，便于测试模块间接口交互（如模拟商品发布请求后验证订单模块数据响应）。

系统测试

功能测试：进行核心功能验证、边界场景测试与异常场景测试。借助Web自动化测试工具Selenium工具，模拟用户操作（如登录、商品搜索、下单），验证前端页面功能与交互逻辑。
性能测试：进行负载测试、压力测试与数据库性能测试。借助开源性能测试工具JMeter,模拟高并发用户，测试系统在负载/压力场景下的响应时间、吞吐量，适配HTTP接口与MySQL数据库性能测试。
兼容性测试：验证系统在Chrome、Firefox、Safari、Edge等主流浏览器中正常渲染与操作。借助SauceLabs跨浏览器、跨设备测试平台，验证系统在多环境下的一致性。
易用性测试：操作流程直观（如商品发布步骤、下单流程）、提示信息清晰（如登录失败、参数错误提示）。核心操作（如搜索商品、提交订单）步骤简洁，符合校园用户使用习惯。通过用户访谈方式获取测试结果。
安全性测试：验证普通用户无法修改他人商品/订单、未实名用户无法发布商品/下单，敏感数据加密存储、防止SQL注入，验证数据安全。同时防止直接通过URL访问需登录的页面（如用户中心、订单记录）的未授权访问。使用开源Web安全测试工具OWASPZAP，检测SQL注入、跨站脚本（XSS）等安全漏洞，适配Django项目的接口安全测试。

验收测试

测试对象：完整的系统功能与用户实际使用场景匹配度。
测试内容：采用α测试，在开发环境由内部用户执行，验证核心交易流程（注册→发布商品→下单→评价）完整性。
测试策略：用户主导，以黑盒测试为主，结合需求文档验证系统是否符合校园二手交易实际需求。
1. 1. 测试用例设计

一、白盒测试

根据软件设计阶段得到的用户登录的程序流程图进行如下分析：

(一）关键节点判定：

1：是否有账号（登录流程分支）

2：账号密码是否正确（登录流程分支）

3：是否要找回密码（登录异常分支）

4：验证码是否正确（注册流程分支）

5：该学号用户是否已存在（注册流程分支）

6：验证码是否正确（密码找回流程分支）

（二）环路复杂度计算：

环路复杂度=判定节点数+1=7

故需设计7条基本路径覆盖所有独立执行逻辑

（三）确定线性无关路径的基本集

路径1：登陆成功

用户登录→判定1（是）→输入用户名密码→判定2（是）→登录成功

路径2：登录-密码错误-不找回密码

用户登录→判定1（是）→输入用户名密码→判定2（否）→判定3（否）→回到“输入用户名密码”

路径3：登录-找回密码

用户登录→判定1（是）→输入用户名密码→判定2（否）→判定3（是）→密码找回→填写验证码→判定6（是）→重置新密码

路径4：登录-密码找回-验证码错误

用户登录→判定1（是）→输入用户名密码→判定2（否）→判定3（是）→密码找回→填写验证码→判定6（否）→回到“填写验证码”

路径5：新用户注册-成功

用户登录→判定1（否）→用户注册→输入信息→判定4（是）→判定5（否）→注册成功

路径6：新用户注册-验证码输入错误

用户登录→判定1（否）→用户注册→输入信息→判定4（否）→回到“输入信息”

路径7：新用户注册-但输入的学号已存在

用户登录→判定1（否）→用户注册→输入信息→判定4（是）→判定5（是）→回到“输入信息”

表4-1白盒测试用例1

TC-W-001	正常登录	用户名：已注册学号“2023001111”；密码：正确密码“Admin123”	数据库中存在“2023001111”用户，密码加密后匹配	登录成功，跳转系统首页；request.user为已登录状态	路径1
TC-W-002	登录密码错误	用户名：已注册学号“2023001111”；密码：错误密码“WrongPwd”	数据库中存在“2023001111”用户，密码加密后不匹配	提示“账号密码错误”，停留在登录页；无登录状态	路径2
TC-W-003	密码找回（验证码正确）	用户名：已注册学号“2023001111”；验证码：正确验证码“123456”；新密码：“NewPwd123”	1.数据库中存在“2023001111”用户2.系统已发送有效验证码至用户邮箱	密码重置成功；提示“可使用新密码登录”；数据库密码更新为新密码加密值	路径3
TC-W-004	密码找回（验证码错误）	用户名：已注册学号“2023001111”；验证码：错误验证码“654321”	数据库中存在“2023001111”用户，但验证码无效	提示“验证码错误”，停留在验证码填写页；密码未更新	路径4
TC-W-005	新用户注册（成功）	学号：新学号“2023002222”；密码：“NewUser123”；邮箱：“2023002@school.com”；验证码：“456789”	1.数据库中无“2023002222”用户2.验证码有效	注册成功；自动跳转登录页；数据库新增“2023002”用户记录	路径5
TC-W-006	注册（验证码错误）	学号：新学号“2023002222”；密码：“NewUser123”；邮箱：“2023002222@school.com”；验证码：“987654”	验证码无效	提示“验证码错误”，停留在注册页；数据库无新增记录	路径6
TC-W-007	注册（学号已存在）	学号：已注册学号“2023001111”；密码：“NewUser123”；邮箱：“test@school.com”；验证码：“456789”	数据库中已存在“2023001111”用户；验证码有效	提示“该学号用户已存在”，停留在注册页；数据库无新增记录	路径7

根据软件设计阶段得到的用户商品发布的程序流程图进行如下分析：

（一）关键节点判定：

1：是否有登录

2：是否实名认证

3：数据是否符合规则

4：审核是否通过

（二）环路复杂度计算：

环路复杂度=判定节点数+1=5

故需设计5条基本路径覆盖所有独立执行逻辑

确定线性无关路径的基本集

表4-2白盒测试用例2

测试用例ID	输入场景	预设条件（系统/数据库状态）	预期输出/行为	覆盖路径	测试目的
TC-W-001	未登录用户发布商品	无登录态	跳转至用户登录页，提示“请登录后发布商品”	判定1（N）	登录校验逻辑
TC-W-002	已登录但未实名认证用户发布商品	已登录但无实名认证记录	提示“发布商品需先完成实名认证”	判定1（Y）→判定2（N）	实名认证校验逻辑
TC-W-003	已登录且实名认证但数据违规发布商品	已登录且实名认证，提交含违规数据（如商品数量为0）	据实际情况给出“数据不符合规则”的提示，跳转回表单修改页	判定1（Y）→判定2（Y）→判定3（N）	数据合规校验逻辑
TC-W-004	已登录且实名认证且数据合规但审核驳回发布商品	已登录且实名认证，数据合规，商品属于需审核品类且审核驳回（如驳回原因“请补充实拍图”）	提示“审核未通过”信息	判定1（Y）→判定2（Y）→判定3（Y）→判定4（N）	审核驳回逻辑
TC-W-005	已登录且实名认证且数据合规且审核通过发布商品	已登录且实名认证，数据合规，商品审核通过	生成并保存商品记录，商品上架成功	判定1（Y）→判定2（Y）→判定3（Y）→判定4（Y）	正常发布流程

二、黑盒测试

（一）使用等价类划分方法设计测试用例，测试系统的“用户注册功能”

1.划分逻辑与等价类

表4-3等价类划分

划分逻辑	有效等价类	无效等价类
用户账号格式	符合校园学号规则（10位数字）（1）	非10位（2）
		非纯数字字符（3）
密码格式	6-16位字母数字组合（4）	小于6位(5)
		大于16位（6）
		纯字母(7)
		纯数字(8)
手机号码格式	11位数字（9）	非11位（10）
		非纯数字（11）
验证码状态	正确（12）	错误（13）

2.测试用例设计

表4-4黑盒测试用例1

编号	输入	预期输出	覆盖等价类
TC-001	1023005478/wly123456/193398 67888/验证码正确	注册成功	（1）（4）（9）（12）
TC-002	102300547/wly123456/19339 867888/验证码正确	提示用户账号格式错误	（2）
TC-003	102300547w/wly123456 /19339867888/验证码正确	提示用户账号格式错误	（3）
TC-004	1023005478/abc11/19339867 888/验证码正确	提示密码长度不足	（5）
TC-005	1023005478/abc123456789 00000/19339867888/验证码正确	提示密码长度过长	（6）
TC-006	1023005478/123456/19339867888/验证码正确	提示密码格式有误	（8）
TC-007	1023005478/abcdefgh/19339 867888/验证码正确	提示密码格式有误	（7）
TC-008	1023005479/abcd123456/193 398678/验证码正确	提示手机号格式错误	（10）
TC-009	1023005479/abcd123456/193 398678w/验证码正确	提示手机号格式错误	（11）
TC-009	1023005478/abcdefgh/19339 867888/验证码错误	提示验证码错误	（13）

（二）使用等价类划分方法设计测试用例，测试系统的“商品发布功能”

1.划分逻辑与等价类

表4-5等价类划分

划分逻辑	有效等价类	无效等价类
商品名称	1-50字之间（1）	无标题（2）
		大于50字（3）
商品价格	0-10000（4）	小于0（5）
		大于10000（6）
商品数量	大于0（7）	小于0（8）
商品主图	格式为JPG/PNG且大小≤5MB（9）	格式非JPG/PNG（10）
		大小>5MB（11）
商品文字描述	0<字数<=500（12）	无描述（13）
		字数大于500（14）
商品详图	格式为JPG/PNG、每张大小<=5MB、数量不超过5张（15）	格式非JPG/PNG（16）
		每张图片大小>5MB（17）
		数量大于5张（18）
用户实名状态	用户已完成实名认证（19）	用户未完成实名认证（20）

表4-6黑盒测试用例2

编号	输入（用户实名认证状态/商品名称/价格/数量/主图/文字描述/详图）	预期输出	覆盖等价类
TC-001	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/5张3MBPNG	发布成功	1、4、7、9、12、15、19
TC-002	已完成//1999/1/1张3MBPNG/手机无拆修/1张3MBPNG	商品名称为空，请输入商品名称	2
TC-003	已完成/这是一个超过五十个字的商品名称用于测试长度是否符合要求/1999/1/1张3MBPNG/手机无拆修/1张3MBPNG	商品名称过长，请重新输入	3
TC-004	已完成/华为Mate50/-1/1/1张3MBPNG/手机无拆修/1张3MBPNG	价格不可以小于0，请重新输入	5
TC-005	已完成/华为Mate50/10001/1/1张3MBPNG/手机无拆修/1张3MBPNG	价格不可以大于10000，请重新输入	6
TC-006	已完成/华为Mate50/1999/0/1张3MBPNG/手机无拆修/1张3MBPNG	商品数量应大于0，请重新输入	8
TC-007	已完成/华为Mate50/1999/1/1张3MBGIF/手机无拆修/1张3MBPNG	主图格式非JPG/PNG，请重新上传	10
TC-008	已完成/华为Mate50/1999/1/1张6MBPNG/手机无拆修/1张3MBPNG	主图大小>5MB，请重新上传	11
TC-009	已完成/华为Mate50/1999/1/1张3MBPNG//1张3MBPNG	无文字描述，请补充文字描述	13
TC-010	已完成/华为Mate50/1999/1/1张3MBPNG/这是一段超过五百字的商品描述.../1张3MBPNG	文字描述应不超过500字	14
TC-011	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/1张3MBGIF	详图格式非JPG/PNG，请重新上传	16
TC-012	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/1张6MBPNG	详图单张大小>5MB，请重新上传	17
TC-013	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/6张3MBPNG	详图数量应不超过5张	18
TC-014	未完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/1张3MBPNG	提示“请先完成实名认证”	20

1. 1. 测试结论及建议

一、测试结论

本次测试严格遵循“以发现尽可能多的错误为核心目标”的原则，通过单元测试、集成测试、系统测试及验收测试四个阶段，全面覆盖用户登录、商品发布、订单交易等核心模块，充分验证了系统在功能完整性、数据一致性、环境兼容性等方面的表现，具体结论如下：

错误发现与分类统计

功能类错误：大约占错误的60%，为主要错误类型。包括商品发布时价格为负数未拦截、订单取消后商品状态未自动重置为“未卖出”、未实名认证用户可提交订单等逻辑漏洞；登录功能中存在学号含特殊字符时验证失效、密码重置验证码超时未提示等边界错误；商品搜索时关键词含空格导致查询结果为空等交互错误。

兼容性与性能类错误：占比20%。包括在Firefox浏览器中商品详情页图片无法预览的兼容性问题；访问时商品列表加载响应时间超5秒、数据库高频查询出现全表扫描导致性能下降等性能问题。

安全性错误：占比20%，包括可以通过URL直接进入商品发布页面可绕过实名验证，同时用户实名认证信息，密码信息未加密存储。

核心模块错误分布

用户登录模块：发现错误6项，主要集中在身份验证逻辑、密码重置流程及登录状态保持方面，错误率15.2%。

商品发布模块：发现错误11项，重点集中在数据校验、图片处理及商品状态流转方面，错误率27.1%（为错误最高发模块）。

订单交易模块：发现错误9项，主要涉及订单创建、状态更新及数据同步方面，错误率23.1%。

系统兼容性与基础安全：发现错误11项，覆盖多环境适配、基础权限控制方面，错误率29.7%。

测试覆盖与错误发现效果

本次测试通过白盒测试覆盖核心模块100%的独立执行路径，通过黑盒测试覆盖95%以上的功能场景，遵循“80-20原则”聚焦核心功能与高风险场景，错误发现效率较高，暴露了系统在核心业务流程中仍存在较多未被开发阶段发现的逻辑漏洞、数据异常及安全风险。

二、测试建议

基于测试过程中发现的错误类型与分布特点，为进一步修复现有问题、降低潜在风险，提出以下建议：

错误修复优先级建议

高优先级：针对核心功能逻辑错误（如订单状态流转异常、库存超卖）、影响功能完整性的交互错误（如商品搜索失效），需优先修复，确保核心流程完整；

中优先级：针对针对安全性错误（如未授权访问、注入漏洞），数据一致性错误（如价格计算偏差、状态同步延迟）、基础兼容性错误（如Firefox浏览器图片预览问题），需在下次迭代中完成修复，并补充对应测试用例。

低优先级：针对低频次边界错误、非核心场景的性能问题，可后续逐步优化。

后续测试优化建议

补充专项测试：针对本次测试未完全覆盖的边缘场景（如数据异常恢复、超大文件上传），开展专项测试，进一步发现潜在错误；

增加自动化回归测试：将核心功能测试用例（如登录、下单、商品发布）转化为自动化脚本，每次系统迭代后执行回归测试，防止修复旧错误时引入新错误；

建立错误跟踪机制：对本次发现的所有错误进行分类归档，记录错误原因、修复方案及回归结果，形成错误知识库，为后续同类功能开发与测试提供参考，提升错误预判与发现能力。

3.长期迭代性建议

建议后期对项目进行迭代完善和周期性测试，并邀请用户参与实测，建立“完善-错误发现-修复-验证-复盘”的闭环机制，持续聚焦过程中可能出现的新需求和隐藏错误，不断提升系统的稳定性、安全性与可用性。

专题报告

大模型辅助的需求分析
1. 自主独立完成初始需求分析（1.0版本）

基于校园二手交易场景的核心痛点与用户需求，结合软件工程中需求工程的基础理论，从功能需求、质量需求、开发约束三个维度完成初始需求定义，确保需求覆盖核心业务闭环，同时具备可落地性。

功能需求

用户管理模块：

身份认证：支持学生通过学号+密码注册，注册时需校验学号格式（10位数字）；登录时提供“记住密码”功能（Cookie有效期7天），忘记密码可通过绑定邮箱接收验证码重置，验证码有效期10分钟。

实名认证：用户需通过真实姓名，校园卡号码，上传学生证内部图片，校园卡图片完成实名认证，后台管理员进行审核校验，未实名认证用户仅可浏览商品，不可发布商品或下单。

个人中心：支持查看个人信息，展示购买记录（待付款，待收货，待评价）、收藏列表、浏览历史，消息中心，卖出记录，都支持查看详情和删除记录。

商品管理模块：

商品发布：支持填写商品标题（1-50字）、分类（闲置书籍/数码商品/服装/日用品等9类）、价格（0-10000元）、数量（>0）、交易地点（限校园内指定区域）、详细描述（0-500字），主图必填（格式JPG/PNG，大小≤5MB），描述图可选（最多5张，单张≤5MB）。

商品管理：卖家可编辑未售出商品的信息（除商品ID外均可修改）、下架商品（逻辑删除），也可下架商品。

商品浏览：提供关键词搜索（支持标题/描述模糊匹配），商品详情可查看详细信息，卖家详情，支持联系卖家，收藏商品，加入购物车，立即购买功能。

交易管理模块

购物车：支持添加商品（同一商品仅可添加1次）、修改商品数量（1-商品剩余库存）、删除商品，展示商品总价。

订单流程：下单时可填写备注（0-100字），生成订单后支持线下付款，线上付款外部接口调用暂不实现、取消订单（仅待付款状态可取消）、确认收货（买家确认后订单状态更新为“待评价”）。

沟通与评价：买卖双方可针对商品发起沟通（支持文字、图片消息，消息已读/未读状态同步），订单完成后买家可对卖家评分（1-5星）并填写评价内容（0-300字）。

后台管理模块

用户管理：查看所有用户信息（学号、用户名、实名认证状态），用户登录记录，浏览记录，审核实名认证申请（通过/驳回，驳回需填写原因，如“学生证信息模糊”）。

商品管理：查看所有商品信息，可以删除商品，查看商品发布统计。

订单管理：可查看所有订单详情（买家/卖家信息、商品信息、订单状态），查看双方沟通记录。

质量需求：

表1-1外部质量需求

性质	质量需求描述	度量方法
易用性	系统应简单直观，无经验的新生经过不超过10分钟的使用（或10分钟的简单引导），就能熟练完成商品浏览、发布、购买等核心操作；用户每日因系统操作失误导致的流程中断次数平均不超过1次。	统计新用户首次完成核心操作的平均时长、用户操作失误率（失误次数/总操作次数）。
可靠性	系统在日常使用（如上课、课余高峰时段），平均无故障运行时间不低于8小时；若出现故障，系统能在10分钟内自动重启恢复，且重启后用户发布的商品、订单等数据不会丢失或损坏。	计算系统故障平均间隔时间、故障后数据崩溃的概率（故障时数据丢失/损坏次数/总故障次数）
响应速度	用户触发操作（如点击商品列表、提交订单、上传商品图片）后，系统平均响应时间不超过2秒；商品图片（不超过5M）上传后，屏幕刷新显示预览图的时间不超过3秒。	统计用户操作的平均响应时间、商品图片上传后的屏幕刷新时间。
安全性	确保用户实名认证信息（如学号、身份证相关信息）被解密的可能性低于0.1%；降低非法用户（非本校师生）入侵系统的可能性，使非法入侵成功的概率低于0.5%。	评估加密算法被破解的概率、非法用户入侵成功的概率。
可用性	在校园大型活动后（如毕业季、开学季，用户量陡增），系统仍能保障商品交易业务的执行，如商品发布、订单生成等操作的成功率不低于95%；若系统崩溃，能保存用户的商品发布进度、订单信息等资料，便于后续恢复。	统计高负载下核心业务操作的成功率、系统崩溃时数据保存的完整性（崩溃时成功保存数据的操作数/总操作数）。

表1-2内部质量需求

性质	需求描述	度量方法
可扩展性	系统能适应校园二手交易业务的变化，如新增“校园活动票务交易”“闲置器材租赁”等功能时，可通过模块化扩展实现，新增功能模块与原有系统的耦合度低于30%（即修改新增模块时，对原有系统代码的改动量占比低于30%）	计算新增功能模块与原有系统的耦合度（修改新增模块时改动原有代码量/原有系统总代码量）
可维护性	系统代码应具有良好的可读性和可维护性，阅读并理解核心模块（如商品管理、订单管理模块）代码的平均时间不超过2小时；修复系统bug时，平均修复时间不超过4小时。	统计理解核心代码的平均时长、bug平均修复时间。
可移植性	系统可以在不同的浏览器上运行使用	在Chrome、Firefox、Safari、Edge等主流浏览器中进行操作。

开发约束

1.技术栈约束：前端采用HTML5+CSS3+JavaScript（搭配Bootstrap框架），后端采用Python3.9+Django4.2，数据库采用MySQL8.0，开发工具使用PyCharm2023.2，版本控制使用Git。

2.时间约束：开发周期共10周，需求分析（3周）→系统设计（2周）→编码实现（3周）→测试优化（2周），无延期缓冲时间。

3.资源约束：开发设备为个人笔记本，无额外预算采购付费工具。

1. 大模型辅助完成需求修订（2.0版本）
需求评审标准

需求完整性：覆盖业务闭环（如校园二手交易“发布-搜索-下单”）、非功能需求（性能/安全）及约束条件，无关键场景或边界情况遗漏。
需求一致性：需求内部逻辑自洽（如状态流转无矛盾）、与技术栈/业务目标兼容（不引入未掌握技术）、术语定义统一（如“已卖出”有明确判定标准）。
可验证性：需求表述无歧义、指标可量化，每个需求对应可执行的验证方法。
可实现性：技术上适配现有栈、资源时间可控。
利益相关方一致性：符合用户习惯（如学生碎片化操作需草稿保存）、开发能力（不依赖未掌握框架）、项目目标（课程任务聚焦核心功能）。
需求可追踪性：需求与开发模块、测试用例双向关联，建立追踪矩阵，便于后续管理。

大模型修订与优化

表1-3修改点展示

原需求问题点	修订优化内容	优化后价值
功能细节缺失（如密码加密算法未明确）；异常场景未覆盖（如库存不足、商品删除后订单处理）同时如库存，购买数量，交易地点，发布商品时商品类型的输入未指明输入方式	密码用PBKDF2加密，交易地点，发布商品时商品类型的输入采用预设下拉框方式，库存，购买数量输入采用自增自减按钮，库存不足时操作失败并提示用户，商品删除后相应购物车与收藏也进行删除	覆盖全流程及边界场景，避免功能漏洞，完善功能细节
逻辑冲突（如订单取消后商品状态未同步）	修复逻辑冲突（订单取消后商品状态重置为“在售”）	确保功能逻辑自洽，避免开发误解
质量需求中部分验证方法不明确（如“安全性高”无检测手段）	明确验证方法（JMeter测试、OWASPZAP扫描）	需求可通过测试/检查验证，保障开发成果可衡量
功能需求与质量需求存在冲突	通过具体的解决措施解决了冲突问题	确保需求一致性
没有体现需求优先级	按照软件需求的重要性和用户的实际需要来确定软件需求的优先级	通过需求优先级确定开发重心和流程

图1-1与大模型对话记录

1. 自主独立审定需求（3.0版本）
  1. 需求审定分析
需求完整性

核心业务闭环覆盖：2.0版本已覆盖“用户注册/登录→商品浏览->商品发布→订单→评价”全流程，包含用户、商品、交易、后台管理四大模块，无关键功能遗漏；

边界场景补充：补充“商品库存为0时下单拦截”“订单取消后商品状态重置为在售”“非登录用户访问订单页跳转登录”等异常场景处理，确保流程闭环；

约束条件明确：技术栈（Python+Django+MySQL）、时间（10周开发周期）、资源（个人设备+校园服务器）等约束清晰，无模糊表述。

需求一致性

逻辑自洽性：订单状态流转（待付款→待收货→待评价→已完成）、用户权限控制（未实名仅浏览、实名可发布/下单）等逻辑无冲突；

技术兼容性：所有需求基于Django单表/基础联表操作、MySQL常规查询实现，未引入微服务、WebSocket等未掌握技术；

冲突解决：对于存在的质量属性与功能属性的冲突，已提出具体的解决措施和实现技术。

需求可验证性

功能需求可验证：每个功能点均对应可执行的测试用例（如“用户注册”测试用例：输入合法学号/密码→数据库新增用户记录）；

质量需求可量化：性能（商品列表加载≤2秒）、安全性（密码PBKDF2加密）、易用性（新用户发布商品时长≤12分钟）等指标明确，且可通过JMeter、OWASPZAP、用户实测等方式验证；

验证方法落地：如“并发支持≥100用户”可通过JMeter模拟50并发测试响应时间，“SQL注入防护”可通过OWASPZAP扫描核心接口。

需求可实现性

技术可行性：基于Python3.9+Django4.2+MySQL8.0技术栈，所有功能（如商品发布、订单创建、后台管理）均可通过DjangoORM、视图函数、模板渲染实现，无技术瓶颈。

时间资源可行性：10周开发周期分配为“需求分析3周→系统设计2周→编码实现3周→测试优化2周”，与课程节奏及个人开发效率适配；

利益相关方一致性

用户视角：功能聚焦校园二手交易核心场景（发布、搜索、交易），操作流程简洁，符合学生“碎片化操作”习惯。

开发视角：需求不依赖未掌握框架，适配个人开发能力。

1. 1. 需求3.0版本
功能需求

（一）用户管理模块

1.身份认证

学号注册：支持学生通过学号+密码注册，密码长度≥6位且包含数字+字母组合，采用PBKDF2算法加密存储。

登录功能：提供“记住密码”功能，Cookie有效期7天（仅存储登录态标识）；忘记密码可通过绑定邮箱接收验证码重置，验证码有效期10分钟，重发间隔60秒。

2.实名认证

用户需上传“JPG/PNG格式，单张≤3MB”的学生证正反面图片，输入真实校园卡号与姓名，完成实名认证，未实名认证用户仅可浏览、收藏商品，不可发布商品、下单或发起沟通；实名认证通过后即时生效所有权限。

3.个人中心

支持查看、编辑个人信息（昵称、头像、联系电话，学号不可修改）。展示购买记录（待付款、待收货、待评价）、卖出记录，浏览记录，支持“查看详情+删除记录”。消息中心区分支持“已读提示/消息未读提示”。

（二）商品管理模块

商品发布：填写商品标题（1-50字）、选择商品类型（预设下拉框：闲置书籍/数码商品/服装/日用品等9类）、设置价格（0-10000元）、数量（＞0）、交易地点（预设下拉框：校园核心区域）、详细描述（0-500字，纯文本）。主图必填（JPG/PNG格式，大小≤5MB），描述图可选（最多5张，单张≤5MB）。
商品管理：卖家可编辑未售出商品的信息（商品ID不可修改），可下架商品（逻辑删除）。
商品浏览与检索：关键词搜索支持“模糊匹配”。商品详情页展示“主图+描述图、价格、库存、详细描述、卖家信息”，支持“联系卖家、收藏商品、加入购物车、立即购买”。

(三）交易管理模块

购物车：支持添加商品（同一商品仅可添加1次）、修改商品数量（1-商品剩余库存，采用自增自减按钮）、删除商品。购物车商品价格实时同步卖家修改后价格，库存不足时自动剔除并提示；结算时校验商品状态（在售、库存充足），否则自动剔除并提示。
订单流程：下单时可填写备注（0-100字，仅买家可见），订单状态流转：待付款→待收货→已完成（待付款状态下可取消订单，订单取消后商品状态重置为“在售”）。买家确认收货后订单状态更新为“待评价”。
沟通与评价：买卖双方可针对商品发起沟通，支持“文字、图片消息（≤3张，单张≤2MB）”，消息已读/未读状态实时同步。订单完成后买家可对卖家评分（1-5星）并填写评价内容（0-300字）。

（四）后台管理模块

用户管理：查看所有用户信息（学号、用户名、实名认证状态）、用户登录记录（IP地址、登录时间、设备信息）、浏览记录；审核实名认证申请（通过/驳回，驳回需填写原因）。
商品管理：查看所有商品信息，可物理删除违规商品；查看商品发布统计（按日/周/月、分类维度统计）。
订单管理：查看所有订单详情（买家/卖家信息、商品信息、订单状态、沟通记录）。

质量需求

表1-4外部质量需求

性质	质量需求描述	度量方法
易用性	新生完成“注册→发布商品”核心流程平均时长≤12分钟；用户每日操作失误次数≤1次	统计20名新生实测时长；后台日志统计操作失误率（失误次数/总操作次数）
可靠性	课余高峰时段（10:00-22:00）无故障运行≥8小时；故障恢复时间≤10分钟，数据无丢失	监控系统日志记录故障间隔；模拟故障后检查数据完整性
响应速度	商品列表加载≤2秒；商品图片（≤3MB）上传后刷新≤3秒；订单创建响应时间≤3秒	JMeter模拟50并发测试；统计用户实际操作响应时长
安全性	用户敏感信息（密码、实名认证材料）采用SM4/AES-256加密；非登录用户不可访问订单页；SQL注入防护通过OWASPZAP扫描	检查数据库存储格式；模拟未登录访问；OWASPZAP扫描核心接口
可用性	毕业季并发≥100时，商品发布/下单成功率≥90%；系统崩溃时订单草稿自动保存	模拟100并发测试核心功能；手动触发崩溃后检查草稿数据留存

表1-5内部质量需求

性质	质量需求描述	度量方法
可扩展性	新增功能模块（如票务交易）时，修改原有代码量占比≤30%；开发周期≤7天	统计新增功能代码修改量/原有代码总量；记录模块开发工时
可维护性	理解核心模块（商品、订单）代码平均时长≤2小时；bug平均修复时间≤4小时	统计代码理解时长；记录10个bug修复耗时
可移植性	系统可以在不同的浏览器上运行使用	在Chrome、Firefox、Safari、Edge等主流浏览器中进行操作。

表1-6功能/质量需求冲突点解决

功能点/质量属性	冲突场景分析	具体解决措施
高负载下商品交易保障	高负载时需保障业务，但资源分配过多导致低负载浪费，复杂流程优化增加系统复杂度	1.业务分级处理：将业务分为核心（下单、支付）和非核心（商品浏览记录统计），核心业务优先分配资源，非核心业务采用异步队列（如Celery）处理；2.缓存策略优化：对商品列表、热门商品等高频访问数据，使用Redis设置多级缓存（本地缓存+分布式缓存），缓存命中率≥90%，减少数据库压力。
用户实名认证与信息加密存储	高强度加密导致认证操作延迟长	1.算法选型：采用PBKDF2加密算法，结合硬件加速，将加密耗时降低至毫秒级；2.数据分级加密：仅对核心敏感信息（如登录密码）加密，非敏感信息（如昵称）明文存储，平衡安全与性能。
身份验证和访问控制	计算负载大导致处理时间长	1.异步验证：将非实时验证（如历史登录IP风险分析）放入异步任务队列，实时验证（如密码校验）同步处理，保证登录响应时间≤2s；2.缓存凭证：对已验证通过的用户，在Session令牌中缓存权限信息，有效期内无需重复验证，减少数据库查询。

在需求分析阶段，可以按照软件需求的重要性和用户的实际需要来确定软件需求的优先级，采用MSCW模型来确定各项功能的优先级：其中Musthave必须有，具有最高优先级，Shouldhave应该有，具有中等优先级，Couldhave可以有，具有低优先级。

表1-7需求优先级划分

迭代阶段	核心目标	主要任务	功能类别	预期成果
第一次迭代	核心功能实现	用户注册、用户登录、用户信息管理、商品信息管理、发布商品、浏览商品、交易信息管理、购买商品、订单处理。	Musthave	基础业务闭环，系统可用。
第二次迭代	功能增强，体验优化	用户实名认证、用户信息修改、用户密码重置、搜索商品、修改发布的商品信息、收藏商品、查看商品卖家详细信息、将商品加入购物车、联系卖家、交易评价。	Shouldhave	业务完整，优化体验
第三次迭代	增值功能	个性化商品推荐、移动端适配。	Couldhave	性能提升

开发约束

1.技术栈约束：前端采用HTML5+CSS3+JavaScript（搭配Bootstrap框架），后端采用Python3.9+Django4.2，数据库采用MySQL8.0，开发工具使用PyCharm2023.2，版本控制使用Git。

2.时间约束：开发周期共10周，需求分析（2周）→系统设计（2周）→编码实现（4周）→测试优化（2周），无延期缓冲时间。

3.资源约束：开发设备为个人笔记本，无额外预算采购付费工具。

个性化学习总结
1. 《人月神话》读书心得

初读《人月神话》，便被其跳出技术细节、聚焦软件工程本质的视角吸引。这本书以作者主导IBMSystem/360系统与OS/360软件包的实践经验为基础，用通俗语言剖析了大型软件项目开发的核心困境与解决思路，成为了计算机和IT领域的圣经，也打破了我对“软件开发=编写代码”的片面认知。

书中“焦油坑”的比喻让我印象深刻——当软件项目缺乏周全规划，规模扩大后便会陷入“越挣扎越深陷”的困境。这让我联想到校园二手交易系统开发的经历：前期因为忽视模块划分，后期修改代码时牵一发而动全身，印证了“前期设计决定项目成败”的真理。正如软件领域的一种说法叫：破窗效应。意思是说，当一座大楼的一扇窗户被打破时，过不了多久，其他的窗户也会被打破。软件开发的过程也是如此，当我们发现软件的一个bug或缺陷，在我们试图修复它时，新的问题就会出现，就如同掉进了无底洞。这就是为什么我们学了各种各样的技术，各式各样的编程语言，看似懂得很多，却无法做出一个成熟的产品。其实软件工程重要的不是具体的技术，而是工程化的思想和方法。而这需要进行通过大量的实践来积累。对于一个项目的开发，要关心的问题不仅仅是技术，项目的需求，项目开发的时间估算，经费预算，项目组成员之间沟通和交流的方式，都会影响到一个项目的最终结果。

而“人月不可互换”的观点更是颠覆了我的认知，书中提出了这样一个观点：如果一个200人的团队中有20个人是精英，那就开除剩余的180人，他们的工作有项目经理自己完成。也就是说，一个小规模的精英团队的生产效率要比一个大规模的平庸的团队高。人力增加的同时，沟通和交流的成本也在增加，而整个团队的工作能力是二者的差值。书中详细剖析了不同种类的工作的情况。如果一个工作的各个部分是可以分解的，并且各个部分没有关联，那么，参与的人员越多，项目的效率就越高，例如收割小麦；而对于各个部分由严格的时序逻辑的工作，人力的增加，并不会明显提高工作的效率；而对于各个部分具有错综复杂的联系的工作，人力的增加只会起到副作用。工作的效率反而会降低。书中揭示了这样一个道理：人力和时间有时候是不能互换的，即“人”和“月”不一定是互通的。这的确很有道理，给了我很大的启发和思考。

团队成员之间的沟通和决策是团队工作中的另一个问题，书中提出了一种外科医生团队的模式：由少数人主导决策，其他人提供专业支持，既避免了“民主决策”的低效，又防止了“独裁管理”的片面。这让我意识到，团队协作的关键是明确角色分工与沟通机制，而非单纯追求人数或民主。

《人月神话》中提出的另外一个概念就是：银弹。《人月神话》的作者就将我们要开发的软件比喻为“狼人”，因为软件和“狼人”是类似的，看似正常的软件只要有细微的问题，就会变得“面目全非”。书中提出这样的观点：可以应对所有软件问题的“银弹”是不存在的。为什么“没有银弹”，作者认为主要原因在于软件的特性：复杂性、一致性、可变性、和不可见性。笔者认为最根本的原因还是变化。可变性造成了软件工程的复杂性，非一致性，和不可见性。其实开发一个软件和建造一座大楼，在思想上是类似的。最大的差别在于，建筑工程的设计实在具体实施前就决定了的，而软件的开发在实现过程中需求的变更时很常见的。软件项目的开发过程必须要适应这种随机的变化。拥抱变化，才是软件工程的精髓所在。没有“银弹”，也就意味着没有一个软件是完美无缺的。正如软件测试领域的一句名言：我们只能通过测试证明软件存在bug，却永远无法通过测试证明软件没有bug。IT领域也是优胜劣汰的，一个软件要想生存下来，就必须不停地修改和维护。

读完这本书，我深刻认识到软件工程的精髓并非技术本身，而是工程化思想——从需求预判、团队管理到风险管控，这些能力不会随技术迭代而过时。未来面对项目时，我会先做好前期设计，合理控制团队规模，以“无银弹”的理性心态应对变化，真正将书中经验转化为解决实际问题的能力。

1. 软件工具的应用
  1. SonarQube

SonarQube是静态代码分析平台，可以检测Bug、代码异味、安全漏洞、重复代码等问题。支持多语言,可以集成进CI流程，也可以本地分析,支持质量门：定义门槛（比如最低覆盖率、不能有重大bug等），分析不达标可以阻止发布，下面将对这一工具的使用进行详细介绍：

环境验证与准备

图2-1JDK版本确认

SonarQube服务部署

图2-2下载地址

图2-3下载界面

启动服务

图2-4启动方式

图2-5启动界面

首次登录安全配置

访问http://localhost:9000→使用初始凭证 admin/admin登录,之后完成密码修改后自动跳转到仪表盘。

（三）服务优化配置

汉化操作

首先下载中文包，之后将汉化包放入：

IDEA深度集成

1.SonarQubeforIDE插件配置

图2-6插件下载

2.服务器配置

之后点击File->Settings->Tools->SonarQubeforIDE->点击+，进行服务器配置

图2-7配置页面

Token获取方式：

登录SonarQube->MyAccount->Security->输入Token名称->generate->复制密钥，注意Token仅显示一次，注意妥善保存。

图2-8Token获取页面

3.项目级绑定

右键项目->SonarQubeforIDE->ProjectSettings,选择服务器，输入项目密钥

图2-9项目级绑定页面

Maven项目扫描实战

在管理端创建工程后，在pycharm中配置

图2-10工程创建

图2-10pycharm配置页面

Zhi执行代码

图2-11分析结果

第三部分课程心得

通过《软件工程》这门课的学习与实践，我深刻体会到软件工程不仅是一门技术学科，更是一门融合管理、协作与创新的系统工程艺术，在学习过程中，我们主要学习和实践了完整的软件生命周期，我系统掌握了软件开发全生命周期的核心知识，从需求分析、设计、编码、测试到维护，形成了对软件工程的完整认知。课程中，结构化分析方法，面向对象的分析方法与软件开发方法的教学，让我学会用规范化工具拆解复杂问题，例如用数据流图梳理系统数据流向，用E-R图构建数据模型等等，这些工具的实操训练为后续项目实践打下坚实基础。

课程思政元素的融入让我对软件工程的理解不止于技术层面。职业规范方面，通过学习ACM/IEEE职业道德标准及滴滴数据安全案例，我认识到软件工程师需严守数据保密、知识产权保护等底线；科技向善理念则通过无障碍开发案例体现，如《Windows应用无障碍可访问性开发指南》的分享，让我明白技术应兼顾不同群体需求；“青鸟工程”等国产软件工程案例的讲解，更激发了我的爱国情怀与科技报国意识，理解到自主研发对国家软件产业发展的重要性。

课程讨论环节聚焦关键概念辨析与实践方法，如“软件与程序的区别”讨论，明确软件是程序、数据与文档的有机整体，而程序仅是指令集合，这一辨析帮助我建立了系统化的软件观；开源软件阅读的讨论中，我们交流了从GitHub选取合适项目、阅读文档与理解代码的方法，体会到开源社区协作与代码重用的优势；画图工具使用的讨论则分享了Visio、PowerDesigner等工具的实操技巧，解决了建模过程中的格式规范与逻辑梳理问题。

总体而言，这门课程不仅传授了软件工程的技术与方法，更培养了我的工程思维与职业素养，让我明白软件工程既是技术学科，更是需要兼顾规范、责任与社会价值的综合性学科。

附件

本次校园二手交易系统开发为单人完成，但全程严格遵循Git版本控制规范，将Git的核心价值落地于个人开发全流程，既保障了代码的可追溯性与安全性，也培养了工程化的开发思维，基于单人开发的特点，设计轻量化分支结构，避免分支冗余的同时保障开发稳定性：其中主分支（main)仅存放经过测试的稳定版本，作为系统发布的基线，全程仅在需求分析完成、核心功能开发完毕、系统测试通过三个节点合并代码，确保主分支代码无运行异常；开发分支（dev)作为日常开发的核心分支，所有功能模块的开发均基于此分支展开；功能临时分支（feature)针对“商品发布”“订单管理”“用户实名认证”等核心功能，分别创建独立临时分支（如feature/goods-publish、feature/order-manage），功能开发完成并自测通过后，合并至dev分支并删除临时分支，避免单次功能开发失误影响整体代码。

图1Git提交记录

核心代码展示：

GoodsInfo模型用于定义商品的基本信息，包括商品名称、图片、价格、数量、描述、卖家信息以及商品类型等。该模型通过ForeignKey关联到用户模型（UserInfo），确保每个商品都与一个卖家相关联。商品的删除操作是逻辑删除，通过isDelete字段进行标记。

GoodsInfoManager是一个自定义的管理器类，封装了多个商品查询方法，便于按商品类型筛选商品。例如，获取所有闲置书籍、数码商品、服装等类型的商品列表。这个管理器极大地方便了商品的分类管理和展示。

图2商品管理核心代码

图3用户登录验证实现

图4订单创建核心代码

图5数据库配置代码

图6邮箱外部接口配置


课程序号	125

《软件工程》

大作业

学生姓名	王路瑶
专业班级	计算机zy2301班
学号	1023005478

2025

2026

学年

第

一

学期

批阅记录

序号	项目		分数	得分
1	开发报告	需求分析	20
		软件设计（含详细设计）	20
		编码与测试	20
2	专题报告	大模型辅助的需求分析	20
2	专题报告	个性化学习总结	10
3	课程心得（含格式规范）		10
合计

1.1自主独立完成初始需求分析（1.0版本）

1.2大模型辅助完成需求修订（2.0版本）

第一部分软件开发报告

概述
1. 项目背景

1. 系统的简要描述

（3）交易管理子系统：该子系统主要负责与交易管理相关的功能，包括以下功能：联系卖家、申请交易、查询交易、交易评价。

（4）后台管理子系统：该子系统主要面向系统管理员，用于对整个平台进行管理与维护。具体功能有：用户管理、商品管理、交易管理。

需求分析
1. 用户分析

校园二手交易市场软件的核心用户为在校学生群体，包含以下细分类型：

卖方用户：有闲置物品待出售的学生，典型场景为毕业季清理闲置、日常置换物品等。
买方用户：有低价购买实用物品需求的学生，典型场景为新生采购必需品、临时使用物品（如考研资料、演出服装）、追求性价比消费等。
潜在用户：暂未产生交易需求，但可能因季节变化（如换季衣物）、学业阶段变化（如升学换教材）、活动需求（如社团活动道具）转化为买卖方的学生。

下面表格呈现了用户特征分析：

表2-1用户特征分析

特征类别	维度	具体内容
核心属性特征	身份属性	年龄集中在18-25岁，受教育程度较高，对互联网工具接受度高，熟悉社交软件和电商平台基本操作
	消费特征	消费能力有限，偏好“高性价比”“实用性”物品，对价格敏感，重视物品真实状态（如新旧程度、功能完整性）
	时间特征	时间碎片化，交易时间集中在课余、周末及毕业季
	空间特征	活动范围局限于校园及周边，对“同校当面交易”需求强烈，对跨校邮寄交易接受度较低（信任成本高、运费不划算）
行为习惯特征	信息获取	习惯通过校园社群（班级群、社团群）、朋友圈、线下跳蚤市场获取二手信息，但信息分散、效率低
	交易偏好	倾向于选择同校师生交易（信任度高），重视交易便捷性（线下面交地点推荐、短时间内完成交易）
	决策因素	物品价格、卖家信用、物品实拍图、交易保障（如支持当面验货）
	痛点	卖家发布信息流程繁琐、买家咨询分散难管理、闲置物品长期卖不出去。买家难以快速找到所需物品、担心卖家身份虚假，担心买到劣质/虚假物品、与卖家沟通效率低

1. 需求分析
  1. 需求获取

一、需求来源

重用已有系统的软件需求：参考成熟平台的基础需求，再适配校园场景，确保需求合理且可落地，参考已有系统比如“闲鱼”，梳理它们的核心功能之后，复用参考平台的基础需求，去掉一些复杂功能，同时补充校园专属需求特点。
从软件系统的用户和客户出导出软件需求：校园二手交易市场的典型用户是学生，结合大学生的校园需求，如卖闲置教材、实时线上沟通等需求，并参考自己或同学买卖二手物品的痛点，将这些痛点转化为需求。
分解其它系统的需求产生新需求：将“非校园二手系统”的需求拆解，结合校园场景改造，产生新的针对性需求，拆分它们的功能模块如淘宝的“购物车”“商品评价”，QQ的“点对点聊天”，拆解后改造为校园二手需求。
软件开发者构思和创作软件需求：基于二手交易的通用流程（发布商品→浏览商品→沟通→下单→评价），构思每个环节的必需需求，增加校园专属需求，结合校园场景构思差异化需求，体现系统的针对性。

二、获取方法

调查问卷

观察法

现场观摩

软件原型

为解决需求描述抽象化导致的理解偏差问题，本次开发引入墨刀原型设计工具进行可视化需求验证。具体过程如下：

部分原型界面展示：

图2-1商品首页原型图2-2用户中心

1. 1. 需求描述
功能需求

校园二手交易系统的用户可执行以下核心功能：

系统管理员负责平台的后台管理，功能涵盖：

1.商品信息管理：可对商品信息进行全生命周期管理，包括查看商品信息、修改商品信息、删除商品及新建商品。

3.订单信息管理：支持对订单的全方位操作，包含查看订单信息、修改订单信息、删除订单及新建订单。

详细的功能需求、质量需求以及需求优先级分析在专题报告大模型辅助的需求分析部分

用例图可以描述系统的功能范围与系统参与者（用户、管理员）与系统功能（用例）的交互关系，下图是系统功能的用例图描述：

图2-3用例图描述

1. 1. 需求建模

一、功能建模

顶层DFD聚焦系统与外部实体的整体交互，界定系统功能范围。

中层DFD对顶层流程进行分解，细化关键子过程，明确各子过程间的数据传递。

底层DFD进一步拆解复杂子过程，补充数据存储细节与具体数据流。

通过数据流图的分层建模，直观表达系统功能与数据的关联，为后续系统设计提供清晰的功能逻辑依据，确保需求分析的完整性与一致性。

图2-4校园二手交易系统0层数据流图

图2-5校园二手交易系统1层数据流图

图2-6校园二手交易系统2层数据流图

二、数据建模

图2-7校园二手交易系统ER图

三、行为建模

图2-8用户状态转换图

图2-9商品状态转换图

订单状态转换图：覆盖线下交易场景中订单的全生命周期，形成完整的订单行为闭环。

图2-10订单状态转换图

四、数据字典

1.数据存储

名称：商品信息

描述：二手商品的详细数据

定义：

商品信息=商品ID+商品名称+类别+描述+价格+数量+图片+卖家ID+状态

商品ID=10{数字}20（英文=[0-9]）

商品名称=1{汉字}50

描述=文本型（商品成色、规格等说明）

价格=数值型（≥0，单位：元）

数量=数值型（>0）

图片=png/jpg

卖家ID=字符型（关联用户信息表）

状态=[“已上架”|“已售出”]

2.数据流

名称：用户信息（以用户注册为例）

描述：用户注册的核心数据

定义：

用户注册信息=用户名+密码+学号+联系方式

用户名=1{汉字或字母}20

密码=6{字母或数字}16（字母=[“A”-“Z”，“a”-“z”]，数字=[“0”-“9”]）

真实姓名=1{汉字}20

学号=1{数字}15（学生学号）

联系方式=11{数字}11（手机号）

3.数据处理

表2-2核心数据处理

名称	简述	输入数据流	加工逻辑	输出数据流	处理频率
生成订单	买家提交订单的处理流程	商品信息、用户ID	校验商品库存→整合用户信息→生成唯一订单ID→更新订单状态为“待支付”	订单信息	用户不定时
商品发布	卖家提交商品的流程	商品信息（名称、类别、描述等）、卖家ID	校验商品信息完整性→生成商品ID→标记状态为“已上架“	上架商品信息	卖家不定时

软件设计
1. 系统体系结构设计
  1. 体系结构风格选择

（一）MVC是一种经典的软件架构模式，其核心优势在于通过高内聚、低耦合的设计思想，实现代码模块化与业务逻辑的清晰分离：

1.分层清晰，职责单一

Model(模型）：负责数据逻辑与存储交互，封装数据结构、业务规则（如商品状态校验、订单状态流转逻辑）及数据库操作（通过DjangoORM与MySQL交互）。

View（视图）：专注于数据展示与用户界面，处理前端页面渲染（如商品列表页、订单详情页），不涉及业务逻辑。

2.可维护性与可扩展性强

3.适配校园二手交易系统的业务特点

系统的核心功能（用户管理、商品发布、订单交易、评价互动等）与MVC架构的分层逻辑高度契合，具体体现为：

1. 1. 体系结构设计

HIPO图可以描述软件总的模块层次结构（H图），又可以描述每个模块的输入输出数据、处理功能及模块调用的详细情况（IPO图）。

图3-1校园二手交易系统层次图

图3-2核心模块IPO图

1. 软件结构设计
  1. 接口设计

一、用户界面设计

（1）设计遵循原则

1.用户熟悉：界面布局采用常见的电商类APP或网站结构，如首页顶部搜索栏、用户中心、分类导航，中部商品展示，可以让学生快速入手。

3.意外最小化：在用户进行商品删除、订单取消等破坏性操作时，弹出确认对话框，询问是否确定操作，避免误操作。

4.可恢复性：当用户操作出错（如填写发布商品信息时表单错误），给出明确的错误提示，并保留已填写的正确信息，方便用户修改。

（2）交互方式选择：

（3）信息表示方式：

（4）设计过程：

4.评审设计：最后邀请同学朋友评价设计好的界面，收集反馈意见并迭代修改，确保界面符合校园用户的使用需求和习惯。

二、外部接口设计

数据库接口（与mysql的交互接口）

数据库接口作为系统核心数据存储的交互接口，用于实现系统与MySQL数据库的连接、数据读写等操作，是系统内部模块与数据库之间的“桥梁”。

核心功能：

建立数据库连接：通过数据库驱动（Python的PyMySQL）与MySQL建立连接，确保系统能访问数据库。

事务处理：在涉及多步数据操作的场景（如商品卖出时同时更新订单记录和商品信息），通过事务接口保证操作的原子性，避免数据不一致。

邮箱服务接口（用于密码重置功能）

实现通过邮箱发送“密码重置链接”的功能，依赖第三方邮箱服务提供商的接口（网易邮箱）。

核心功能：

发送密码重置邮件：当用户点击“忘记密码”并输入注册邮箱后，系统调用邮箱接口，按固定格式生成邮件内容，发送到用户邮箱。

三、内部接口设计

表3-1用户下单模块接口设计

接口名称	视图函数名	请求方法	输入参数	核心功能	交互说明
创建订单	create_order	POST	goods_id/quantity/shipping_address/contact_phone、notes	生成唯一订单号，计算总价，创建OrderInfo	返回JSON结果（含订单号）；校验商品状态（未删除、未卖出），否则返回失败信息
购物车操作	cart	GET/POST	POST：商品ID	GET：查询当前用户购物车商品；POST：添加商品到购物车（校验状态，避免重复）	购物车数据包含商品总价、数量；若已添加则提示“已在购物车”
订单状态更新	update_order_status	POST	order_id/new_status	按规则更新订单状态（如“待付款→已付款”），同步商品状态	仅买家可操作自己的订单，返回JSON结果（成功/失败信息）
订单记录查询	purchase_record	GET	-	查询买家的订单，支持分页	返回订单记录页面，按状态分类展示订单列表
卖家订单查询	my_sold_orders	GET	-	查询当前用户作为卖家的订单	返回卖出订单记录页面，按创建时间倒序展示
提交评价	write_review	POST	order_id/rating（评分）/content（评价内容）	创建Review，关联订单并更新状态为“已完成”	仅“待评价”订单可提交，成功后跳转订单记录页

表3-2商品发布模块接口设计

接口名称	视图函数名	请求方法	输入参数	核心功能	交互说明
发布页面展示	release_goods	GET	-	验证登录状态，渲染商品发布表单	未实名则跳转登录页；已实名返回发布商品页面
商品发布提交	release	POST	基础信息：title、type、price等；图片：picture（主图）、desc_images（附加描述图）	校验数据合法性，创建GoodsInfo及图片关联	发布成功重定向首页；失败返回发布页并提示错误
商品修改（回显）	edit_goods	GET	id（商品ID）	验证权限（仅发布者可修改），回显商品数据到修改表单	未登录跳转登录页；越权访问返回错误提示
商品修改（提交）	edit_goods	POST	同发布接口参数+ id	校验修改后的数据，更新商品信息（支持更新图片）	修改成功跳转发布记录页；失败返回修改表单并提示错误
商品删除	delete_goods	POST	id（商品ID）	逻辑删除商品（isDelete=True），仅发布者可操作	返回JSON结果（成功/失败信息），前端刷新商品列表
发布记录查询	release_records	GET	-	查询当前用户发布的未删除商品，支持分页	返回发布记录页面，展示商品列表及分页控件

表3-3用户登录模块接口设计

接口名称	视图函数名	请求方法	输入参数	核心功能	交互说明
登录页面展示	login_page	GET	-	渲染登录表单，回显Cookie中的用户名	前端访问时返回login.html，携带Cookie中的username
登录验证	login_handle	POST	number（学号）、password（密码）	校验用户身份，记录登录日志，设置Session	验证成功后调用Django内置login()，设置相关信息到Session，重定向首页；失败则返回错误提示
登出	logout	GET	-	清除登录状态（内置）和自定义Session	清除Session中的相关信息,重定向首页或登录页
密码重置	reset_password_handle	POST	Number/email/verify_code（验证码）/password等	验证验证码，更新用户密码	重置成功后清除验证码Session，跳转登录页；失败则返回错误信息

1. 1. 数据设计

将需求分析阶段得到的ER图转换为如下所示的关系模式集合：

图3-3用户关系

图3-4消息关系

图3-5商品关系

图3-6订单关系

在上述关系模型设计过程中，遵循以下原则：

每个实体在ER图中通常会转化为一个关系（即数据库中的表）。实体的每个属性转化为该关系的列。如用户实体转化为user_userinfo表。
在1:1关系中，任意一个实体的主键可以作为外键添加到另一个实体的表中。
在1:N关系中，N方表包含指向1方表的外键。如一个用户可能发布多个商品，则用户ID作为goods_goodsinfo的外键。
在N:N关系中，直接用关系表示。如用户与商品收藏关系是N:N，那就直接建立一张商品收藏表。

设计说明：

删除逻辑：商品和订单采用is_delete字段（而非物理删除），便于数据恢复和历史记录查询，符合DjangoORM的常用实践。
时间字段：用datetime类型并设置自动更新，无需代码手动维护更新时间。
外键约束：所有关联字段设置外键并级联删除，确保数据一致性（如用户删除后，其发布的商品也删除）。
索引优化：针对高频查询场景（如“用户查自己的订单”“筛选未卖出的商品”）创建联合索引，避免全表扫描，提升MySQL查询效率。
1. 1. 过程设计

程序流程图是一种比较直观形象的描述过程的控制流程的图形工具，下面借助这一工具体现核心模块的过程设计：

图3-7商品下单流程图图3-8发布商品流程图

图3-9用户登录流程图

系统实现
1. 编程语言及开发环境介绍
  1. python+Django+mysql

在校园二手交易系统的开发中，我采用的是Python语言，搭配Django框架和MySql数据库构建开发环境，我在选择时主要参考了以下因素：

(1)编程语言与框架选择

应用领域适配性

开发效率与工具生态

开发与学习成本

(2)数据库选择

数据处理与数据库应用适配性

平台支持与可移植性

1. 1. 编程风格与规范

（一）代码格式与可读性：

1.遵循PEP8规范：缩进使用4个空格，每行代码长度不超过79个字符，函数/类之间空两行，语句后不添加多余空格。

2.注释清晰：模块顶部添加文档字符串说明功能；复杂逻辑（如订单状态流转、权限校验）添加单行注释解释设计思路；避免“自解释代码”过度注释。

3.代码块拆分：单个函数长度不超过50行，复杂业务逻辑（如支付流程）拆分为多个子函数，通过函数名体现功能。

（二）命名规范：

1.变量/函数：采用小写字母+下划线，如user_id、get_goods_list()，避免拼音或缩写。

2.类名：采用首字母大写的驼峰式，如 GoodsModel，且类名需体现实体或功能（避免 MyClass 等无意义命名）。

3.常量：采用全大写+下划线。

4.数据库相关：表名使用小写+下划线（如 goods_info、user_auth），字段名与模型类属性保持一致（如模型 GoodInfo的 price 属性对应表字段 price）。

1. 1. 开发环境介绍

（一）开发语言与框架

Python：版本3.10（Django4.2的稳定支持版本，兼顾新特性与兼容性），通过pyenv或conda管理多版本环境隔离。

Django框架：版本4.2.7（长期支持版，含ORM优化、异步视图等特性，保障项目稳定性）。

（二）数据库系统

MySQL：版本8.0（支持JSON字段、窗口函数等高级特性，优化二手商品信息的存储与查询），通过PyMySQL驱动与DjangoORM交互。

NavicatPremium16：可视化管理数据库表结构、执行SQL查询、备份数据。

（三）开发工具与IDE

PycharmProfessional2023.2:支持Django项目的智能提示、调试、数据库可视化，内置PEP8代码检查与格式化功能。

Git（版本2.40.1）+GitHub，通过分支管理（main主分支、dev开发分支、功能分支如feature/goods-publish）保障代码迭代的安全性。

1. 代码重用实践
  1. 开源代码复用

（一）核心框架与基础库复用

1.DiangoWeb框架：

作为系统的核心开发框架，复用其MVT架构、ORM数据库交互、用户认证、权限管理等核心功能：

直接使用django.contrib.auth模块实现用户注册、登录、会话管理，无需从零开发身份认证逻辑。

通过DjangoORM封装MySQL交互，用Goods.objects.filter()等API替代原生SQL，减少数据库操作的冗余代码。

2.Pillow:

复用该开源图片处理库实现商品图片的上传、压缩和格式转换：

调用Image.open()和Image.save()处理用户上传的图片，自动压缩超过10MB的图片至500KB以内（通过thumbnail()方法）；

转换非JPG/PNG格式的图片为统一的WebP格式，减少前端加载时间。

3.开源代码的二次开发与定制

基于Bootstrap的前端组件定制：

复用Bootstrap的栅格系统和组件库，针对校园场景调整样式，复用Bootstrap的modal、dropdown等基础组件，通过CSS覆盖和JS扩展适配管理系统需求。

1. 1. 自定义代码复用

1.通用权限校验

封装RealNameRequiredMixin和StudentRoleMixin，在商品发布、订单管理等视图中复用，保证在购买商品、发布商品前已完成实名认证。

2.模块组件复用：

将导航栏、商品卡片、分页控件等抽离为独立模板片段，通过{%include%}在首页、列表页、详情页中复用，统一页面风格。

1. 软件测试
  1. 测试计划

软件测试将分为以下四个阶段：

单元测试

测试对象：单个模块的核心函数/类（如用户登录验证函数、商品发布数据校验方法、订单价格计算逻辑等）。
测试内容：

模块接口正确性：输入合法/非法参数验证接口响应。

内部逻辑完整性：覆盖条件分支、循环执行等独立路径。

数据处理准确性：如价格计算、订单状态更新等核心业务逻辑。

错误处理有效性：异常输入（如空值、超出范围参数）的捕获与反馈。

规范检查：借助静态代码分析工具SonarQube，检查代码规范、潜在缺陷（如逻辑错误、性能隐患），适配Python代码质量检测。

测试策略：以白盒测试为主，开发人员主导，确保被测单元隔离（不依赖其他未测试模块或外部资源）。
测试工具：借助Python官方内置框架unittest，无需额外安装，支持用例组织、自动化执行，适配Django项目的模块测试（如视图函数、模型方法测试）。

集成测试

测试对象：模块间交互逻辑（如登录模块与商品发布模块、商品模块与订单模块的协作）。
测试内容：

模块接口兼容性：数据传递格式、参数类型匹配度（如用户ID从登录模块传递到商品模块的一致性）。

交互逻辑正确性：如商品发布后状态同步到订单模块、下单后商品状态更新（未卖出→已卖出）。

数据一致性：跨模块操作时MySQL数据同步（如创建订单时商品数量、订单总价的关联更新）。

测试策略：采用渐增式集成策略（自底向上结合），先确保各单元测试通过，再逐步集成模块，兼顾黑盒与白盒测试技术，同步执行回归测试防止功能回退。
测试工具：采用Django内置测试类DjangoTestCase，支持模拟HTTP请求、数据库事务回滚，便于测试模块间接口交互（如模拟商品发布请求后验证订单模块数据响应）。

系统测试

功能测试：进行核心功能验证、边界场景测试与异常场景测试。借助Web自动化测试工具Selenium工具，模拟用户操作（如登录、商品搜索、下单），验证前端页面功能与交互逻辑。
性能测试：进行负载测试、压力测试与数据库性能测试。借助开源性能测试工具JMeter,模拟高并发用户，测试系统在负载/压力场景下的响应时间、吞吐量，适配HTTP接口与MySQL数据库性能测试。
兼容性测试：验证系统在Chrome、Firefox、Safari、Edge等主流浏览器中正常渲染与操作。借助SauceLabs跨浏览器、跨设备测试平台，验证系统在多环境下的一致性。
易用性测试：操作流程直观（如商品发布步骤、下单流程）、提示信息清晰（如登录失败、参数错误提示）。核心操作（如搜索商品、提交订单）步骤简洁，符合校园用户使用习惯。通过用户访谈方式获取测试结果。
安全性测试：验证普通用户无法修改他人商品/订单、未实名用户无法发布商品/下单，敏感数据加密存储、防止SQL注入，验证数据安全。同时防止直接通过URL访问需登录的页面（如用户中心、订单记录）的未授权访问。使用开源Web安全测试工具OWASPZAP，检测SQL注入、跨站脚本（XSS）等安全漏洞，适配Django项目的接口安全测试。

验收测试

测试对象：完整的系统功能与用户实际使用场景匹配度。
测试内容：采用α测试，在开发环境由内部用户执行，验证核心交易流程（注册→发布商品→下单→评价）完整性。
测试策略：用户主导，以黑盒测试为主，结合需求文档验证系统是否符合校园二手交易实际需求。
1. 1. 测试用例设计

一、白盒测试

根据软件设计阶段得到的用户登录的程序流程图进行如下分析：

(一）关键节点判定：

1：是否有账号（登录流程分支）

2：账号密码是否正确（登录流程分支）

3：是否要找回密码（登录异常分支）

4：验证码是否正确（注册流程分支）

5：该学号用户是否已存在（注册流程分支）

6：验证码是否正确（密码找回流程分支）

（二）环路复杂度计算：

环路复杂度=判定节点数+1=7

故需设计7条基本路径覆盖所有独立执行逻辑

（三）确定线性无关路径的基本集

路径1：登陆成功

用户登录→判定1（是）→输入用户名密码→判定2（是）→登录成功

路径2：登录-密码错误-不找回密码

用户登录→判定1（是）→输入用户名密码→判定2（否）→判定3（否）→回到“输入用户名密码”

路径3：登录-找回密码

用户登录→判定1（是）→输入用户名密码→判定2（否）→判定3（是）→密码找回→填写验证码→判定6（是）→重置新密码

路径4：登录-密码找回-验证码错误

用户登录→判定1（是）→输入用户名密码→判定2（否）→判定3（是）→密码找回→填写验证码→判定6（否）→回到“填写验证码”

路径5：新用户注册-成功

用户登录→判定1（否）→用户注册→输入信息→判定4（是）→判定5（否）→注册成功

路径6：新用户注册-验证码输入错误

用户登录→判定1（否）→用户注册→输入信息→判定4（否）→回到“输入信息”

路径7：新用户注册-但输入的学号已存在

用户登录→判定1（否）→用户注册→输入信息→判定4（是）→判定5（是）→回到“输入信息”

表4-1白盒测试用例1

TC-W-001	正常登录	用户名：已注册学号“2023001111”；密码：正确密码“Admin123”	数据库中存在“2023001111”用户，密码加密后匹配	登录成功，跳转系统首页；request.user为已登录状态	路径1
TC-W-002	登录密码错误	用户名：已注册学号“2023001111”；密码：错误密码“WrongPwd”	数据库中存在“2023001111”用户，密码加密后不匹配	提示“账号密码错误”，停留在登录页；无登录状态	路径2
TC-W-003	密码找回（验证码正确）	用户名：已注册学号“2023001111”；验证码：正确验证码“123456”；新密码：“NewPwd123”	1.数据库中存在“2023001111”用户2.系统已发送有效验证码至用户邮箱	密码重置成功；提示“可使用新密码登录”；数据库密码更新为新密码加密值	路径3
TC-W-004	密码找回（验证码错误）	用户名：已注册学号“2023001111”；验证码：错误验证码“654321”	数据库中存在“2023001111”用户，但验证码无效	提示“验证码错误”，停留在验证码填写页；密码未更新	路径4
TC-W-005	新用户注册（成功）	学号：新学号“2023002222”；密码：“NewUser123”；邮箱：“2023002@school.com”；验证码：“456789”	1.数据库中无“2023002222”用户2.验证码有效	注册成功；自动跳转登录页；数据库新增“2023002”用户记录	路径5
TC-W-006	注册（验证码错误）	学号：新学号“2023002222”；密码：“NewUser123”；邮箱：“2023002222@school.com”；验证码：“987654”	验证码无效	提示“验证码错误”，停留在注册页；数据库无新增记录	路径6
TC-W-007	注册（学号已存在）	学号：已注册学号“2023001111”；密码：“NewUser123”；邮箱：“test@school.com”；验证码：“456789”	数据库中已存在“2023001111”用户；验证码有效	提示“该学号用户已存在”，停留在注册页；数据库无新增记录	路径7

根据软件设计阶段得到的用户商品发布的程序流程图进行如下分析：

（一）关键节点判定：

1：是否有登录

2：是否实名认证

3：数据是否符合规则

4：审核是否通过

（二）环路复杂度计算：

环路复杂度=判定节点数+1=5

故需设计5条基本路径覆盖所有独立执行逻辑

确定线性无关路径的基本集

表4-2白盒测试用例2

测试用例ID	输入场景	预设条件（系统/数据库状态）	预期输出/行为	覆盖路径	测试目的
TC-W-001	未登录用户发布商品	无登录态	跳转至用户登录页，提示“请登录后发布商品”	判定1（N）	登录校验逻辑
TC-W-002	已登录但未实名认证用户发布商品	已登录但无实名认证记录	提示“发布商品需先完成实名认证”	判定1（Y）→判定2（N）	实名认证校验逻辑
TC-W-003	已登录且实名认证但数据违规发布商品	已登录且实名认证，提交含违规数据（如商品数量为0）	据实际情况给出“数据不符合规则”的提示，跳转回表单修改页	判定1（Y）→判定2（Y）→判定3（N）	数据合规校验逻辑
TC-W-004	已登录且实名认证且数据合规但审核驳回发布商品	已登录且实名认证，数据合规，商品属于需审核品类且审核驳回（如驳回原因“请补充实拍图”）	提示“审核未通过”信息	判定1（Y）→判定2（Y）→判定3（Y）→判定4（N）	审核驳回逻辑
TC-W-005	已登录且实名认证且数据合规且审核通过发布商品	已登录且实名认证，数据合规，商品审核通过	生成并保存商品记录，商品上架成功	判定1（Y）→判定2（Y）→判定3（Y）→判定4（Y）	正常发布流程

二、黑盒测试

（一）使用等价类划分方法设计测试用例，测试系统的“用户注册功能”

1.划分逻辑与等价类

表4-3等价类划分

划分逻辑	有效等价类	无效等价类
用户账号格式	符合校园学号规则（10位数字）（1）	非10位（2）
		非纯数字字符（3）
密码格式	6-16位字母数字组合（4）	小于6位(5)
		大于16位（6）
		纯字母(7)
		纯数字(8)
手机号码格式	11位数字（9）	非11位（10）
		非纯数字（11）
验证码状态	正确（12）	错误（13）

2.测试用例设计

表4-4黑盒测试用例1

编号	输入	预期输出	覆盖等价类
TC-001	1023005478/wly123456/193398 67888/验证码正确	注册成功	（1）（4）（9）（12）
TC-002	102300547/wly123456/19339 867888/验证码正确	提示用户账号格式错误	（2）
TC-003	102300547w/wly123456 /19339867888/验证码正确	提示用户账号格式错误	（3）
TC-004	1023005478/abc11/19339867 888/验证码正确	提示密码长度不足	（5）
TC-005	1023005478/abc123456789 00000/19339867888/验证码正确	提示密码长度过长	（6）
TC-006	1023005478/123456/19339867888/验证码正确	提示密码格式有误	（8）
TC-007	1023005478/abcdefgh/19339 867888/验证码正确	提示密码格式有误	（7）
TC-008	1023005479/abcd123456/193 398678/验证码正确	提示手机号格式错误	（10）
TC-009	1023005479/abcd123456/193 398678w/验证码正确	提示手机号格式错误	（11）
TC-009	1023005478/abcdefgh/19339 867888/验证码错误	提示验证码错误	（13）

（二）使用等价类划分方法设计测试用例，测试系统的“商品发布功能”

1.划分逻辑与等价类

表4-5等价类划分

划分逻辑	有效等价类	无效等价类
商品名称	1-50字之间（1）	无标题（2）
		大于50字（3）
商品价格	0-10000（4）	小于0（5）
		大于10000（6）
商品数量	大于0（7）	小于0（8）
商品主图	格式为JPG/PNG且大小≤5MB（9）	格式非JPG/PNG（10）
		大小>5MB（11）
商品文字描述	0<字数<=500（12）	无描述（13）
		字数大于500（14）
商品详图	格式为JPG/PNG、每张大小<=5MB、数量不超过5张（15）	格式非JPG/PNG（16）
		每张图片大小>5MB（17）
		数量大于5张（18）
用户实名状态	用户已完成实名认证（19）	用户未完成实名认证（20）

表4-6黑盒测试用例2

编号	输入（用户实名认证状态/商品名称/价格/数量/主图/文字描述/详图）	预期输出	覆盖等价类
TC-001	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/5张3MBPNG	发布成功	1、4、7、9、12、15、19
TC-002	已完成//1999/1/1张3MBPNG/手机无拆修/1张3MBPNG	商品名称为空，请输入商品名称	2
TC-003	已完成/这是一个超过五十个字的商品名称用于测试长度是否符合要求/1999/1/1张3MBPNG/手机无拆修/1张3MBPNG	商品名称过长，请重新输入	3
TC-004	已完成/华为Mate50/-1/1/1张3MBPNG/手机无拆修/1张3MBPNG	价格不可以小于0，请重新输入	5
TC-005	已完成/华为Mate50/10001/1/1张3MBPNG/手机无拆修/1张3MBPNG	价格不可以大于10000，请重新输入	6
TC-006	已完成/华为Mate50/1999/0/1张3MBPNG/手机无拆修/1张3MBPNG	商品数量应大于0，请重新输入	8
TC-007	已完成/华为Mate50/1999/1/1张3MBGIF/手机无拆修/1张3MBPNG	主图格式非JPG/PNG，请重新上传	10
TC-008	已完成/华为Mate50/1999/1/1张6MBPNG/手机无拆修/1张3MBPNG	主图大小>5MB，请重新上传	11
TC-009	已完成/华为Mate50/1999/1/1张3MBPNG//1张3MBPNG	无文字描述，请补充文字描述	13
TC-010	已完成/华为Mate50/1999/1/1张3MBPNG/这是一段超过五百字的商品描述.../1张3MBPNG	文字描述应不超过500字	14
TC-011	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/1张3MBGIF	详图格式非JPG/PNG，请重新上传	16
TC-012	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/1张6MBPNG	详图单张大小>5MB，请重新上传	17
TC-013	已完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/6张3MBPNG	详图数量应不超过5张	18
TC-014	未完成/华为Mate50/1999/1/1张3MBPNG/手机无拆修/1张3MBPNG	提示“请先完成实名认证”	20

1. 1. 测试结论及建议

一、测试结论

错误发现与分类统计

安全性错误：占比20%，包括可以通过URL直接进入商品发布页面可绕过实名验证，同时用户实名认证信息，密码信息未加密存储。

核心模块错误分布

用户登录模块：发现错误6项，主要集中在身份验证逻辑、密码重置流程及登录状态保持方面，错误率15.2%。

商品发布模块：发现错误11项，重点集中在数据校验、图片处理及商品状态流转方面，错误率27.1%（为错误最高发模块）。

订单交易模块：发现错误9项，主要涉及订单创建、状态更新及数据同步方面，错误率23.1%。

系统兼容性与基础安全：发现错误11项，覆盖多环境适配、基础权限控制方面，错误率29.7%。

测试覆盖与错误发现效果

二、测试建议

基于测试过程中发现的错误类型与分布特点，为进一步修复现有问题、降低潜在风险，提出以下建议：

错误修复优先级建议

低优先级：针对低频次边界错误、非核心场景的性能问题，可后续逐步优化。

后续测试优化建议

补充专项测试：针对本次测试未完全覆盖的边缘场景（如数据异常恢复、超大文件上传），开展专项测试，进一步发现潜在错误；

3.长期迭代性建议

专题报告

大模型辅助的需求分析
1. 自主独立完成初始需求分析（1.0版本）

功能需求

用户管理模块：

商品管理模块：

商品管理：卖家可编辑未售出商品的信息（除商品ID外均可修改）、下架商品（逻辑删除），也可下架商品。

交易管理模块

购物车：支持添加商品（同一商品仅可添加1次）、修改商品数量（1-商品剩余库存）、删除商品，展示商品总价。

后台管理模块

商品管理：查看所有商品信息，可以删除商品，查看商品发布统计。

订单管理：可查看所有订单详情（买家/卖家信息、商品信息、订单状态），查看双方沟通记录。

质量需求：

表1-1外部质量需求

性质	质量需求描述	度量方法
易用性	系统应简单直观，无经验的新生经过不超过10分钟的使用（或10分钟的简单引导），就能熟练完成商品浏览、发布、购买等核心操作；用户每日因系统操作失误导致的流程中断次数平均不超过1次。	统计新用户首次完成核心操作的平均时长、用户操作失误率（失误次数/总操作次数）。
可靠性	系统在日常使用（如上课、课余高峰时段），平均无故障运行时间不低于8小时；若出现故障，系统能在10分钟内自动重启恢复，且重启后用户发布的商品、订单等数据不会丢失或损坏。	计算系统故障平均间隔时间、故障后数据崩溃的概率（故障时数据丢失/损坏次数/总故障次数）
响应速度	用户触发操作（如点击商品列表、提交订单、上传商品图片）后，系统平均响应时间不超过2秒；商品图片（不超过5M）上传后，屏幕刷新显示预览图的时间不超过3秒。	统计用户操作的平均响应时间、商品图片上传后的屏幕刷新时间。
安全性	确保用户实名认证信息（如学号、身份证相关信息）被解密的可能性低于0.1%；降低非法用户（非本校师生）入侵系统的可能性，使非法入侵成功的概率低于0.5%。	评估加密算法被破解的概率、非法用户入侵成功的概率。
可用性	在校园大型活动后（如毕业季、开学季，用户量陡增），系统仍能保障商品交易业务的执行，如商品发布、订单生成等操作的成功率不低于95%；若系统崩溃，能保存用户的商品发布进度、订单信息等资料，便于后续恢复。	统计高负载下核心业务操作的成功率、系统崩溃时数据保存的完整性（崩溃时成功保存数据的操作数/总操作数）。

表1-2内部质量需求

性质	需求描述	度量方法
可扩展性	系统能适应校园二手交易业务的变化，如新增“校园活动票务交易”“闲置器材租赁”等功能时，可通过模块化扩展实现，新增功能模块与原有系统的耦合度低于30%（即修改新增模块时，对原有系统代码的改动量占比低于30%）	计算新增功能模块与原有系统的耦合度（修改新增模块时改动原有代码量/原有系统总代码量）
可维护性	系统代码应具有良好的可读性和可维护性，阅读并理解核心模块（如商品管理、订单管理模块）代码的平均时间不超过2小时；修复系统bug时，平均修复时间不超过4小时。	统计理解核心代码的平均时长、bug平均修复时间。
可移植性	系统可以在不同的浏览器上运行使用	在Chrome、Firefox、Safari、Edge等主流浏览器中进行操作。

开发约束

1.技术栈约束：前端采用HTML5+CSS3+JavaScript（搭配Bootstrap框架），后端采用Python3.9+Django4.2，数据库采用MySQL8.0，开发工具使用PyCharm2023.2，版本控制使用Git。

2.时间约束：开发周期共10周，需求分析（3周）→系统设计（2周）→编码实现（3周）→测试优化（2周），无延期缓冲时间。

3.资源约束：开发设备为个人笔记本，无额外预算采购付费工具。

1. 大模型辅助完成需求修订（2.0版本）
需求评审标准

需求完整性：覆盖业务闭环（如校园二手交易“发布-搜索-下单”）、非功能需求（性能/安全）及约束条件，无关键场景或边界情况遗漏。
需求一致性：需求内部逻辑自洽（如状态流转无矛盾）、与技术栈/业务目标兼容（不引入未掌握技术）、术语定义统一（如“已卖出”有明确判定标准）。
可验证性：需求表述无歧义、指标可量化，每个需求对应可执行的验证方法。
可实现性：技术上适配现有栈、资源时间可控。
利益相关方一致性：符合用户习惯（如学生碎片化操作需草稿保存）、开发能力（不依赖未掌握框架）、项目目标（课程任务聚焦核心功能）。
需求可追踪性：需求与开发模块、测试用例双向关联，建立追踪矩阵，便于后续管理。

大模型修订与优化

表1-3修改点展示

原需求问题点	修订优化内容	优化后价值
功能细节缺失（如密码加密算法未明确）；异常场景未覆盖（如库存不足、商品删除后订单处理）同时如库存，购买数量，交易地点，发布商品时商品类型的输入未指明输入方式	密码用PBKDF2加密，交易地点，发布商品时商品类型的输入采用预设下拉框方式，库存，购买数量输入采用自增自减按钮，库存不足时操作失败并提示用户，商品删除后相应购物车与收藏也进行删除	覆盖全流程及边界场景，避免功能漏洞，完善功能细节
逻辑冲突（如订单取消后商品状态未同步）	修复逻辑冲突（订单取消后商品状态重置为“在售”）	确保功能逻辑自洽，避免开发误解
质量需求中部分验证方法不明确（如“安全性高”无检测手段）	明确验证方法（JMeter测试、OWASPZAP扫描）	需求可通过测试/检查验证，保障开发成果可衡量
功能需求与质量需求存在冲突	通过具体的解决措施解决了冲突问题	确保需求一致性
没有体现需求优先级	按照软件需求的重要性和用户的实际需要来确定软件需求的优先级	通过需求优先级确定开发重心和流程

图1-1与大模型对话记录

1. 自主独立审定需求（3.0版本）
  1. 需求审定分析
需求完整性

约束条件明确：技术栈（Python+Django+MySQL）、时间（10周开发周期）、资源（个人设备+校园服务器）等约束清晰，无模糊表述。

需求一致性

逻辑自洽性：订单状态流转（待付款→待收货→待评价→已完成）、用户权限控制（未实名仅浏览、实名可发布/下单）等逻辑无冲突；

技术兼容性：所有需求基于Django单表/基础联表操作、MySQL常规查询实现，未引入微服务、WebSocket等未掌握技术；

冲突解决：对于存在的质量属性与功能属性的冲突，已提出具体的解决措施和实现技术。

需求可验证性

功能需求可验证：每个功能点均对应可执行的测试用例（如“用户注册”测试用例：输入合法学号/密码→数据库新增用户记录）；

验证方法落地：如“并发支持≥100用户”可通过JMeter模拟50并发测试响应时间，“SQL注入防护”可通过OWASPZAP扫描核心接口。

需求可实现性

时间资源可行性：10周开发周期分配为“需求分析3周→系统设计2周→编码实现3周→测试优化2周”，与课程节奏及个人开发效率适配；

利益相关方一致性

用户视角：功能聚焦校园二手交易核心场景（发布、搜索、交易），操作流程简洁，符合学生“碎片化操作”习惯。

开发视角：需求不依赖未掌握框架，适配个人开发能力。

1. 1. 需求3.0版本
功能需求

（一）用户管理模块

1.身份认证

学号注册：支持学生通过学号+密码注册，密码长度≥6位且包含数字+字母组合，采用PBKDF2算法加密存储。

2.实名认证

3.个人中心

（二）商品管理模块

商品发布：填写商品标题（1-50字）、选择商品类型（预设下拉框：闲置书籍/数码商品/服装/日用品等9类）、设置价格（0-10000元）、数量（＞0）、交易地点（预设下拉框：校园核心区域）、详细描述（0-500字，纯文本）。主图必填（JPG/PNG格式，大小≤5MB），描述图可选（最多5张，单张≤5MB）。
商品管理：卖家可编辑未售出商品的信息（商品ID不可修改），可下架商品（逻辑删除）。
商品浏览与检索：关键词搜索支持“模糊匹配”。商品详情页展示“主图+描述图、价格、库存、详细描述、卖家信息”，支持“联系卖家、收藏商品、加入购物车、立即购买”。

(三）交易管理模块

购物车：支持添加商品（同一商品仅可添加1次）、修改商品数量（1-商品剩余库存，采用自增自减按钮）、删除商品。购物车商品价格实时同步卖家修改后价格，库存不足时自动剔除并提示；结算时校验商品状态（在售、库存充足），否则自动剔除并提示。
订单流程：下单时可填写备注（0-100字，仅买家可见），订单状态流转：待付款→待收货→已完成（待付款状态下可取消订单，订单取消后商品状态重置为“在售”）。买家确认收货后订单状态更新为“待评价”。
沟通与评价：买卖双方可针对商品发起沟通，支持“文字、图片消息（≤3张，单张≤2MB）”，消息已读/未读状态实时同步。订单完成后买家可对卖家评分（1-5星）并填写评价内容（0-300字）。

（四）后台管理模块

用户管理：查看所有用户信息（学号、用户名、实名认证状态）、用户登录记录（IP地址、登录时间、设备信息）、浏览记录；审核实名认证申请（通过/驳回，驳回需填写原因）。
商品管理：查看所有商品信息，可物理删除违规商品；查看商品发布统计（按日/周/月、分类维度统计）。
订单管理：查看所有订单详情（买家/卖家信息、商品信息、订单状态、沟通记录）。

质量需求

表1-4外部质量需求

性质	质量需求描述	度量方法
易用性	新生完成“注册→发布商品”核心流程平均时长≤12分钟；用户每日操作失误次数≤1次	统计20名新生实测时长；后台日志统计操作失误率（失误次数/总操作次数）
可靠性	课余高峰时段（10:00-22:00）无故障运行≥8小时；故障恢复时间≤10分钟，数据无丢失	监控系统日志记录故障间隔；模拟故障后检查数据完整性
响应速度	商品列表加载≤2秒；商品图片（≤3MB）上传后刷新≤3秒；订单创建响应时间≤3秒	JMeter模拟50并发测试；统计用户实际操作响应时长
安全性	用户敏感信息（密码、实名认证材料）采用SM4/AES-256加密；非登录用户不可访问订单页；SQL注入防护通过OWASPZAP扫描	检查数据库存储格式；模拟未登录访问；OWASPZAP扫描核心接口
可用性	毕业季并发≥100时，商品发布/下单成功率≥90%；系统崩溃时订单草稿自动保存	模拟100并发测试核心功能；手动触发崩溃后检查草稿数据留存

表1-5内部质量需求

性质	质量需求描述	度量方法
可扩展性	新增功能模块（如票务交易）时，修改原有代码量占比≤30%；开发周期≤7天	统计新增功能代码修改量/原有代码总量；记录模块开发工时
可维护性	理解核心模块（商品、订单）代码平均时长≤2小时；bug平均修复时间≤4小时	统计代码理解时长；记录10个bug修复耗时
可移植性	系统可以在不同的浏览器上运行使用	在Chrome、Firefox、Safari、Edge等主流浏览器中进行操作。

表1-6功能/质量需求冲突点解决

功能点/质量属性	冲突场景分析	具体解决措施
高负载下商品交易保障	高负载时需保障业务，但资源分配过多导致低负载浪费，复杂流程优化增加系统复杂度	1.业务分级处理：将业务分为核心（下单、支付）和非核心（商品浏览记录统计），核心业务优先分配资源，非核心业务采用异步队列（如Celery）处理；2.缓存策略优化：对商品列表、热门商品等高频访问数据，使用Redis设置多级缓存（本地缓存+分布式缓存），缓存命中率≥90%，减少数据库压力。
用户实名认证与信息加密存储	高强度加密导致认证操作延迟长	1.算法选型：采用PBKDF2加密算法，结合硬件加速，将加密耗时降低至毫秒级；2.数据分级加密：仅对核心敏感信息（如登录密码）加密，非敏感信息（如昵称）明文存储，平衡安全与性能。
身份验证和访问控制	计算负载大导致处理时间长	1.异步验证：将非实时验证（如历史登录IP风险分析）放入异步任务队列，实时验证（如密码校验）同步处理，保证登录响应时间≤2s；2.缓存凭证：对已验证通过的用户，在Session令牌中缓存权限信息，有效期内无需重复验证，减少数据库查询。

表1-7需求优先级划分

迭代阶段	核心目标	主要任务	功能类别	预期成果
第一次迭代	核心功能实现	用户注册、用户登录、用户信息管理、商品信息管理、发布商品、浏览商品、交易信息管理、购买商品、订单处理。	Musthave	基础业务闭环，系统可用。
第二次迭代	功能增强，体验优化	用户实名认证、用户信息修改、用户密码重置、搜索商品、修改发布的商品信息、收藏商品、查看商品卖家详细信息、将商品加入购物车、联系卖家、交易评价。	Shouldhave	业务完整，优化体验
第三次迭代	增值功能	个性化商品推荐、移动端适配。	Couldhave	性能提升