团队作业3--需求改进&系统设计

这个作业属于哪个课程	班级链接
这个作业要求在哪里	作业要求
这个作业的目标	需求改进、系统设计、测试计划、alpha阶段计划等

《文章管理系统》需求规格说明书改进版

1. 系统概述
   1.1 产品背景
   随着信息爆炸式增长，个人及小型团队（如学生、博主、小型团队）需要一种高效、智能的工具来管理日益增多的文章与知识笔记。现有工具或过于简单（缺乏深度组织能力），或过于复杂（如一些大型内容管理系统）。本项目旨在开发一个极简、智能、互联的文章管理系统，帮助用户轻松管理、检索和连接自己的知识资产。

1.2 系统描述
本系统是一个轻量级的文章管理系统，聚焦于文章写作、分类管理、内容检索与知识关联等必要功能，致力于为用户提供流畅而高效的内容管理体验。用户可以进行文章的创建、编辑、分类、检索和管理。系统的核心亮点在于通过全局全文搜索和文章手动关联功能，解决用户“找不到”和“知识孤立”的痛点，实现从“文章仓库”到“个人知识中枢”的升级。

1.3 预期的用户量
基于目标用户（在校学生、内容创作者）的广泛性及项目的实用性，在项目发布并初步推广后，预期初期用户量为500人。此数值考虑了在校园或特定兴趣社群内传播的可行性。

2. 面向用户分析

用户角色	核心特征与需求	使用场景
在校学生	需要管理课程笔记、论文、读书报告。需求是：分类清晰、易于查找、支持多种格式。	撰写毕业论文时，快速找回一年前读过的相关文献笔记。
内容创作者	频繁产出和修改文章。需求是：稳定的写作体验、文章内部相互引流、SEO友好。	发布一篇新技术文章时，能方便地链接到之前写的基础概念文章，引导读者阅读。
小型团队	有体系化整理知识的习惯，并需要与团队成员共享知识内容。需求是：强大的检索能力、灵活的内容组织方式。	团队在进行项目复盘时，通过输入关键词，快速聚合所有成员写过的相关文档，形成完整的项目故事线。

3. 功能性需求
   3.1 用户管理模块
   用户管理相关需求：
   01： 系统应允许用户通过用户名和密码进行注册。
   02： 系统应允许已注册用户登录。
   03： 系统应允许登录用户修改个人基本信息。

3.2 文章管理模块
文章管理相关需求：
01： 系统应允许用户创建、编辑、删除和查看文章。
02： 系统应允许用户为文章设置一个或多个分类。
03： 系统应允许用户管理（增、删、改、查）文章分类。

3.3 核心升级功能
搜索功能相关需求：
01全局全文搜索：
系统应提供一个全局搜索框。用户输入关键词后，系统应能同时在文章的标题和正文内容中进行检索，搜索结果页面应列出所有匹配的文章。
02文章手动关联：
在文章编辑页面，系统应提供一个界面，允许用户通过搜索文章标题来关联已存在的其他文章。在文章详情页底部，系统应自动显示所有被手动关联的文章列表。

4. 技术需求
   01性能需求：
   页面平均加载时间应小于2秒。

全文搜索操作的响应时间应在1秒内完成。
02可用性需求：
界面设计简洁直观，符合主流Web应用操作习惯。
首次使用的用户无需培训即可完成文章发布和搜索等核心操作。
03安全需求：
用户只能操作自己创建的文章和数据，严格的前后端权限校验。
04可靠性需求：
系统应保证每周7x24小时稳定运行，核心功能（如文章保存、搜索）的可用性不低于99.9%。

5. 用户场景故事（User Story）
   场景：学生撰写毕业论文
   小明是一名大四学生，正在撰写毕业论文。他打开文章管理系统，在搜索框中输入“机器学习基础”，系统立即列出几篇他之前整理的笔记。他在编辑论文时，通过“关联文章”功能，快速链接到这些笔记。系统还自动推荐了另外一些关于“深度学习应用”的文章，帮助他拓展了思路。最终，小明高效完成了论文的文献综述部分，并构建起一个完整的知识脉络。

6. 功能优先级分析（四象限法）

象限	功能	说明
重要且紧急	用户登录注册、文章增删改查、全局搜索	核心功能，必须优先完成
重要不紧急	文章手动关联、文章自动推荐（“猜你喜欢”功能）	提升用户体验，可后续迭代
紧急不重要	数据看板（文章数量、字数统计）、文章批量操作（批量删除、批量移动分类）	辅助功能，对核心价值影响小，可延后开发
不紧急不重要	主题切换、文章评论功能	非核心，可作为扩展功能

7. 任务分解（WBS）与进度计划
   第一阶段：基础功能
   用户管理（注册、登录、个人信息）
   文章基础操作（增删改查、分类）
   基础界面设计与响应式布局
   第二阶段：核心功能
   全局全文搜索
   文章手动关联功能
   第三阶段：优化与测试
   性能优化与压力测试
   用户验收测试与反馈收集
   部署上线与文档撰写

8. 原型与用户反馈
   我们向目标用户（学生、博主）展示了原型，并收集了以下反馈：
   痛点：文章之间缺乏联系，查找困难。
   场景：写作时需频繁切换工具查找资料。
   改进：增加了“全局搜索”功能，任意输入文章中的一部分内容都能查找到相关文章；增加了“自动推荐”与“手动关联”双模式，提升知识连接效率。

9. 系统价值阐述
   真实性：
   本系统解决的问题源于真实场景。任何需要写作和记录的人都会面临“资料太多，找不到”的困境。其功能设计（如全文搜索）是对标小红书、知乎等成熟内容产品的核心体验，具有强烈的现实基础。

可用性：
系统在已有完备的增删改查基础上，新增功能均以提升易用性为核心。全局搜索让查找变得极其简单；手动关联的操作流程与“添加标签”类似，可以降低用户查找关联文章成本。

价值所在：
系统不仅是一个管理工具，更是一个生产力工具。它通过技术手段节省了用户大量查找和整理信息的时间，并通过构建文章间的联系，帮助用户激发新思路，形成个人知识体系，具有显著的学习和工作效率提升价值。

系统设计

1. 系统架构设计

本系统采用经典且职责分明的三层架构，即表现层、业务逻辑层、数据访问层，以实现高内聚、低耦合，便于团队成员并行开发与后期维护。

各层职责说明：
表现层：
职责：负责用户交互和界面渲染。
技术实现：使用现代前端技术（如Vue.js/React+HTML+CSS）构建响应式单页面应用，通过AJAX/Fetch API与后端进行异步数据通信。
优势：前后端分离，前端可以独立开发部署，用户体验更流畅。
业务逻辑层：
职责：作为系统的核心，处理所有业务规则、逻辑计算和请求分发。
技术实现：使用Django框架。接收表现层的请求，通过Django View处理，调用相应的服务模块（如用户认证、文章CRUD、搜索服务），并返回处理结果。
模块划分：
用户管理模块：处理注册、登录、会话管理。
文章管理模块：处理文章的创建、编辑、删除、查询和分类管理。
搜索与关联模块：处理全局全文搜索和文章关联逻辑。
数据访问层：
职责：负责与数据库交互，完成数据的持久化存储和读取。
技术实现：使用Django内置的ORM，通过模型与MySQL数据库进行交互。ORM将Python对象转化为SQL语句，简化了数据库操作，并增强了安全性和可移植性。
架构价值：此设计使前端、后端、测试人员可以基于定义好的接口并行工作。例如，前端开发界面时，后端可以同时开发API；测试人员可以根据接口文档提前编写测试用例。

数据库设计

数据库设计遵循第三范式，以减少数据冗余，保证数据一致性和完整性。

实体关系图
下图展示了核心实体（用户、文章、分类）及其之间的关系。

核心数据表结构

1. 用户表
   描述：存储系统用户的基本信息。
   字段：user_id（主键）, username, email, password_hash, created_at等。
2. 文章表
   描述：存储文章的核心内容。
   字段：article_id（主键）, title, content, author_id（外键）, created_at, updated_at, status等。
   关系：通过author_id与用户表关联，一篇文章属于一个用户，一个用户可以拥有多篇文章。
3. 分类表
   描述：存储用户自定义的文章分类。
   字段：category_id（主键）, name, user_id（外键）。
   关系：通过user_id与用户表关联，一个分类属于一个用户。与文章表为多对多关系。
4. 文章-分类关联表
   描述：实现文章和分类之间的多对多关系。
   字段：article_id（外键）, category_id（外键）。
5. 文章关联表
   描述：实现文章之间的手动关联关系。
   字段：source_article_id（外键）, target_article_id（外键）。
   说明：这是一个自引用关系，用于记录一篇文章主动关联了另一篇文章。

Alpha任务分配计划

1. 选取Product Backlog功能项
   总时间与能力：综合考虑优先级、依赖关系和团队资源,考虑到主要开发工作由前端和后端两人承担，第一周目标应聚焦为基础功能的开发与实现。测试同学将参与整个流程，产品经理和组长负责支持与协调。
   优先级：优先选择“重要且紧急”的功能，确保出一个可演示的、完整的核心功能闭环。
   依赖关系：用户认证为基础依赖，文章管理为核心价值。
   从Product Backlog中选取的功能项（聚焦最小可行产品MVP）：

• 用户登录与注册 (基础依赖)
• 文章的核心增删改查(核心价值)
• 基础布局与导航 (用户体验基础)
• 项目管理与支持（流程保障）

2. Sprint Backlog任务分解与认领

任务ID	所属功能	任务内容	负责人	预估工时
T-1	用户登录与注册	初始化项目结构，配置开发环境、基础路由	后端	4h
T-2	用户登录与注册	设计用户表、文章表结构，ORM映射	后端	3h
T-3	用户登录与注册	实现用户注册/登录接口（密码加密）	后端	6h
T-4	用户登录与注册	前端登录/注册页面开发+表单验证	前端	4h
T-5	基础布局与导航	搭建响应式前端布局框架	前端	5h
T-6	基础布局与导航	实现顶部导航栏和路由跳转	前端	4h
T-7	文章核心功能	设计文章CRUD后端API接口	后端	8h
T-8	文章核心功能	开发文章列表页前端（分页、搜索）	前端	7h
T-9	文章核心功能	开发文章编辑/详情页前端	前端	6h
T-10	测试验证	设计用户登录注册测试用例	测试	2h
T-11	测试验证	设计文章CRUD功能测试用例	测试	3h
T-12	测试验证	接口测试与BUG记录	测试	5h
T-13	测试验证	系统功能回归测试+报告 测试	测试	4h
T-14	项目管理	完善原型与需求细节，支持团队	产品经理	全程
T-15	项目管理	召开组会、跟踪进度、协调资源	组长	全程

3. Alpha冲刺甘特图
   假设Alpha冲刺周期为2周，第1周偏重基础模块开发，第2周偏重功能联调与测试。
   

测试计划

一、测试阶段划分与目标

本测试计划围绕测前准备 → 测中执行 → 测后验证的全流程展开，旨在系统性地覆盖TanhT项目的功能、性能、兼容性及潜在风险点，确保项目上线质量达到预期标准。

二、测前准备工作 (2025-11-25 至 2025-11-28)

2.1 数据与环境准备

任务项	具体内容	负责人	完成标准
测试账号构造	依据需求规格说明书，构造不同用户角色账号（管理员、编辑、普通用户），覆盖全部权限场景。	测试组	账号清单完备，各角色权限验证通过。
测试数据准备	基于核心业务场景生成文章数据（含长文、短文、图文混排、敏感内容等），模拟真实用户行为。	测试组+研发	测试数据对业务场景的覆盖度≥90%，数据一致性校验通过。
测试环境搭建	搭建BOE（预发布）、PPE（生产模拟）环境，确保其配置（如数据库版本、缓存策略）与线上生产环境一致。	运维组	环境配置清单已同步测试组，各环境连通性验证通过。

2.2 测试用例设计

• •

  功能分类：根据需求规格说明书，TanhT项目为新增功能项目，需执行AI测试粒度评估。

• •

  用例设计原则：

  • •

    核心流程（文章发布→审核→展示）：采用标准测试，覆盖正向、逆向、边界场景。

  • •

    辅助功能（标签管理、草稿箱、历史版本）：采用轻量测试，验证核心路径。

  • •

    风险点（敏感词过滤、并发发布）：采用专项测试，进行独立用例设计。

• •

  输出物：包含用例编号、步骤、预期结果的测试用例文档，通过AI评估后进行团队评审。

三、测中执行流程 (2025-11-29 至 2025-12-08)

3.1 测试阶段与重点

阶段	执行环境	测试重点	免测/执行规则
BOE测试	预发布环境	核心流程验证（文章发布/审核/删除）、权限校验（编辑/管理员操作限制）。	非高风险功能可申请免测，仅覆盖主流程及核心权限。
PPE测试	生产模拟环境	验证BOE未覆盖的分支场景（如跨端同步、异常网络处理）、性能与兼容性。	BOE已测用例抽测30%，BOE未覆盖的用例需全量执行。

3.2 过程留痕要求

• •

  Case执行记录：使用飞书文档标记执行状态（例如：✅ 已执行 / ❌ 失败），并同步更新至测试管理工具（如Meego）。

• •

  Bug记录规范：所有缺陷需通过运营平台-方舟缺陷流程提交至Meego，必须标注清晰优先级（P0/P1/P2），提交后@对应研发负责人确认。

• •

  风险同步机制：每日18:00在项目需求群同步测试进度。示例：“PPE测试进度70%，待解决问题：编辑界面图片上传超时（P1），风险：可能延期0.5天”。

四、测后验证与收尾 (2025-12-09 至 2025-12-10)

4.1 线上回归验证

• •

  时间节点：与研发团队确认上线完成时间（建议12:00前），QA于上线后2小时内启动回归验证。

• •

  验证范围：聚焦核心流程（文章发布→审核→用户端展示）及高频用户操作（刷新、收藏、分享）。

• •

  工具要求：必须使用线上正式包进行验证，严禁测试包连接生产环境（直播间等特殊场景除外）。

4.2 报告输出

• •

  测试总结报告：需包含用例执行率（要求≥95%）、缺陷统计（P0≤1个，P1≤3个）、风险关闭情况等核心指标。

• •

  遗留问题清单：清晰记录未关闭的缺陷，并必须标注其影响范围及已采取的临时解决方案。

五、测试计划总览（思维导图）

TanhT项目测试计划
├── 测前准备 (2025-11-25 至 2025-11-28)
│  ├── 数据与环境准备 (测试账号、数据、环境搭建)
│  └── 测试用例设计 (核心流程、辅助功能、风险点)
├── 测中执行 (2025-11-29 至 2025-12-08)
│  ├── BOE测试 (核心流程与权限验证)
│  ├── PPE测试 (分支场景与兼容性验证)
│  └── 过程留痕 (用例记录、Bug管理、风险同步)
└── 测后验证 (2025-12-09 至 2025-12-10)
  ├── 线上回归 (核心流程与高频操作)
  └── 报告输出 (测试总结、遗留问题清单)

六、全量系统测试用例

1. 用户登录模块

1.1 正常登录场景

用例：输入正确的用户名和密码 → 登录成功，跳转到首页，token被正确存储

用例：登录后，检查首页或用户信息区域，正确显示当前登录的用户名或昵称

1.2 异常登录场景

用例：用户名为空 → 提示"请输入用户名"

用例：密码为空 → 提示"请输入密码"

用例：用户名错误 → 提示"用户名或密码错误"

用例：密码错误 → 提示"用户名或密码错误"

用例：用户名和密码均为空 → 提示"请输入用户名和密码"

用例：输入SQL注入等特殊字符（如' OR '1'='1）→ 提示"用户名或密码错误"或有效拦截

用例：输入包含HTML标签的字符串（如<script>alert('xss')</script>）→ 输入被正常转义或过滤，登录失败并有相应提示

用例：连续输入错误密码5次（可配置）→ 账号被临时锁定，并提示"尝试次数过多，请10分钟后再试"

用例：输入超长用户名/密码（如1000个字符）→ 前端有长度限制，或请求被拒绝并返回合理提示

1.3 安全性 & 状态场景

用例：登录成功后刷新页面，登录状态保持（不退出，token未失效）

用例：直接访问首页URL，未登录时自动跳转到登录页

用例：登录成功后，直接在新标签页打开首页URL → 应保持登录状态，无需重复登录

用例：登录后，等待Token过期（如超过24小时）再操作 → 请求被拦截，自动跳转至登录页

用例：检查登录请求，密码在网络中传输是否为加密形式（非明文）

2. 文章管理模块

2.1 文章列表 (List)

用例：页面正常加载，显示文章列表（无数据时显示"暂无文章"）

用例：列表包含正确信息（标题、分类、发布时间、状态：已发布/草稿）

用例：列表支持分页（上一页/下一页/跳转页码），页码切换后数据正确加载

用例：按文章状态（全部/已发布/草稿）筛选，列表仅显示对应状态文章

用例：列表支持按文章标题关键字搜索 → 仅显示包含关键字的文章

用例：列表支持按分类进行筛选 → 仅显示选中分类下的文章

用例：列表支持按时间范围（开始日期-结束日期）筛选 → 仅显示在该时间范围内发布的文章

用例：列表默认按发布时间降序排列（最新发布的在最前面）

用例：点击文章标题 → 跳转至该文章的详情页或编辑页

用例：在列表页，检查不同状态的文章是否有明显的视觉标识（如草稿状态标灰）

2.2 发布文章 (Create)

2.2.1 正常发布场景

用例：填写所有必填字段（标题、内容、分类）→ 发布成功，列表新增文章且状态为"已发布"

用例：发布文章时，可选填封面图片、摘要等信息 → 发布后这些信息正确显示在列表和详情中

用例：发布文章时，设置文章为"定时发布" → 文章在设定时间点前状态为"待发布"，到达时间后自动变为"已发布"

2.2.2 字段验证场景

用例：标题为空 → 提示"标题不能为空"

用例：标题超过50字符（假设限制）→ 提示"标题不能超过50个字符"

用例：标题输入仅包含空格 → 提交时提示"标题不能为空"或自动 trim 处理

用例：内容为空（编辑器无输入）→ 提示"内容不能为空"

用例：内容仅包含空格或换行符 → 提交时提示"内容不能为空"

用例：未选择分类（下拉框未选）→ 提示"请选择分类"

用例：摘要字段超过最大长度限制 → 提示"摘要不能超过XXX字符"

2.2.3 编辑器功能场景

用例：图片上传（支持jpg/png，单张≤2MB）→ 上传成功后预览显示

用例：图片上传（选择大于2MB的图片）→ 失败提示"图片大小不能超过2MB"

用例：图片上传（选择非jpg/png格式文件）→ 失败提示"请上传JPG或PNG格式的图片"

用例：编辑器支持文本加粗、斜体、下划线等基础格式 → 格式设置生效，且发布后显示正确

用例：编辑器支持有序列表和无序列表 → 列表功能正常

用例：编辑器支持撤销（Ctrl+Z）和重做（Ctrl+Y）操作 → 操作响应正确

2.2.4 其他功能场景

用例：保存为草稿（未填写必填字段）→ 文章状态为"草稿"，不在已发布列表显示

用例：保存为草稿（填写所有必填字段）→ 文章状态为"草稿"，保存成功

用例：从草稿箱打开草稿继续编辑，修改后点击"发布" → 文章状态变为"已发布"

用例：发布文章后，文章发布时间应设置为发布操作的时间点

2.3 编辑文章 (Update)

用例：点击编辑按钮，页面回显原文章标题、内容、分类等数据

用例：修改标题/内容后保存 → 列表中对应文章数据更新为最新内容

用例：编辑时标题/内容/分类验证同"发布文章"（空值、超长等提示一致）

用例：编辑文章时，修改文章状态（如从"草稿"改为"已发布"）→ 保存后状态生效，文章出现在相应列表

用例：编辑文章后，文章的"最后修改时间"应更新为本次保存的时间

2.4 删除文章 (Delete)

用例：点击删除按钮，弹出确认对话框（标题："确认删除"，内容："删除后不可恢复"）

用例：对话框点击"取消"→ 文章未被删除，列表保持不变

用例：对话框点击"确定"→ 文章从列表中消失，数据库同步删除记录

用例：批量选择多篇文章进行删除 → 弹出确认框，确认后选中的文章均被删除

用例：尝试删除不存在的文章ID → 系统返回友好的错误提示，如"文章不存在"

2.5 文章详情/预览

用例：在列表页或编辑页点击"预览" → 在新页面或弹层中显示文章最终发布后的样式

用例：预览页面内容与编辑内容一致，格式正确显示

3. 用户与权限管理模块

3.1 用户退出

用例：点击退出按钮，弹出确认提示（"确认退出当前账号？"）

用例：确认退出 → 跳转至登录页，本地token清除（通过开发者工具检查Storage）

用例：退出后访问管理页面（如文章列表）→ 自动跳转至登录页

用例：退出后，点击浏览器后退按钮 → 不应再显示之前的敏感页面内容，或再次被重定向到登录页

3.2 权限校验（如果系统有不同角色）

用例：普通编辑登录 → 只能看到自己创建的文章，无法看到或操作他人的文章

用例：管理员登录 → 可以看到并管理所有用户的文章

用例：编辑尝试通过URL直接访问管理他人文章的页面 → 系统拦截并提示"无权限访问"

用例：检查菜单和按钮 → 不同角色登录后，只能看到自己有权限操作的菜单和功能按钮

4. 系统与UI兼容性测试

4.1 界面与交互

用例：各页面在Chrome/Firefox/Edge最新版本下布局无错位、元素显示完整

用例：按钮/输入框/表格样式符合设计稿（颜色、字体、间距）

用例：按钮状态（正常/悬停/禁用）样式正确（如禁用时颜色变灰、不可点击）

用例：所有操作（提交、保存、删除）均有明确的加载中状态提示（如按钮显示loading或全局loading）

用例：操作成功后有成功提示（如"发布成功"），短暂显示后自动消失

用例：操作失败后有错误提示，提示信息清晰易懂

4.2 响应式布局

用例：响应式布局（如1920px/1366px/平板/移动端）下，元素自适应显示（无溢出/隐藏）

用例：在移动设备上，导航菜单能正常收缩为汉堡菜单，并可点击展开

用例：在小屏幕下，数据表格可以横向滚动，不影响查看

4.3 浏览器兼容性

用例：在主流浏览器（Chrome, Firefox, Edge, Safari）上，核心功能（登录、发布、编辑、删除）均正常工作

用例：检查浏览器控制台，在所有操作过程中无JavaScript报错

5. 性能与数据安全

5.1 性能场景

用例：文章列表在大量数据（如1000条）下，分页加载和切换速度在可接受范围内（如<3秒）

用例：首次打开页面或刷新后，静态资源（JS、CSS）加载正常，无404错误

5.2 数据安全

用例：检查API接口返回的数据，不应包含敏感信息（如用户密码明文）

用例：通过工具抓包，检查敏感操作（如登录、删除）的请求是否合理，防止CSRF攻击

七、推荐测试用例

1. 用户登录模块

用例ID	用例标题	前置条件	测试步骤	预期结果	优先级
AUTH-001	成功登录	1. 拥有有效账号 2. 处于登录页面	1. 输入正确的用户名 2. 输入正确的密码 3. 点击“登录”按钮	1. 跳转至系统首页（如文章列表页） 2. 浏览器本地存储中生成有效的token 3. 页面显示用户昵称或登录状态	P0
AUTH-002	登录失败-用户名为空	处于登录页面	1. 用户名字段留空 2. 输入密码 3. 点击“登录”按钮	页面提示“请输入用户名”，且不发起登录请求	P1
AUTH-003	登录失败-密码错误	处于登录页面	1. 输入正确的用户名 2. 输入错误的密码 3. 点击“登录”按钮	页面提示“用户名或密码错误”	P0
AUTH-004	登录失败-SQL注入攻击	处于登录页面	1. 在用户名字段输入 ' OR '1'='1 2. 输入任意密码 3. 点击“登录”按钮	提示“用户名或密码错误”，系统日志无SQL报错，有效拦截	P0
AUTH-005	登录状态持久化	已成功登录	1. 刷新浏览器页面 2. 关闭浏览器后重新打开并访问项目地址	1. 刷新后仍保持登录状态，停留在首页 2. 重新打开浏览器后，若token未过期，应自动登录并跳转首页	P1
AUTH-006	未登录访问拦截	用户已退出或未登录	1. 在浏览器中直接输入后台首页地址（如/home）	页面自动跳转至登录页面	P0

---

2. 文章管理模块

用例ID	用例标题	前置条件	测试步骤	预期结果	优先级
ARTICLE-001	成功发布文章	1. 用户已登录 2. 有“发布文章”的权限	1. 进入文章发布页 2. 填写合规的标题、内容，选择分类 3. 点击“发布”按钮	1. 提示“发布成功” 2. 跳转至文章列表页 3. 新发布的文章显示在列表首位，状态为“已发布”	P0
ARTICLE-002	发布文章-标题超长校验	1. 用户已登录 2. 处于文章编辑页	1. 输入超过50个字符的标题 2. 尝试点击“发布”	1. 界面实时提示“标题不能超过50个字符” 2. “发布”按钮变为禁用状态或点击后提示错误	P1
ARTICLE-003	成功保存草稿	1. 用户已登录	1. 在编辑页仅填写标题，内容为空 2. 点击“保存草稿”按钮	1. 提示“保存成功” 2. 文章在“已发布”列表不可见，在“草稿”列表可见	P1
ARTICLE-004	图片上传成功	1. 用户已登录 2. 处于文章编辑页	1. 点击图片上传按钮 2. 选择一张小于2MB的JPG图片	1. 图片成功上传至服务器 2. 在编辑器中显示预览图	P1
ARTICLE-005	图片上传失败-格式不符	1. 用户已登录 2. 处于文章编辑页	1. 点击图片上传按钮 2. 选择一张BMP格式的图片	页面提示“仅支持JPG、PNG格式的图片”	P2
ARTICLE-006	编辑并更新现有文章	1. 用户已登录 2. 文章列表中存在自己发布的文章	1. 点击目标文章的“编辑”按钮 2. 修改文章标题和内容 3. 点击“保存”按钮	1. 页面正确回显原文章所有信息 2. 保存成功后，列表中原文章标题和更新时间更新为最新内容	P0
ARTICLE-007	删除文章-确认取消	1. 用户已登录 2. 文章列表中存在文章	1. 点击目标文章的“删除”按钮 2. 在弹出的确认对话框中点击“取消”	对话框关闭，文章未被删除，列表无变化	P1
ARTICLE-008	删除文章-确认删除	1. 用户已登录 2. 文章列表中存在文章	1. 点击目标文章的“删除”按钮 2. 在弹出的确认对话框中点击“确定”	1. 提示“删除成功” 2. 该文章从列表中消失	P0

---

3. 用户退出模块

用例ID	用例标题	前置条件	测试步骤	预期结果	优先级
LOGOUT-001	安全退出系统	用户已登录	1. 点击页面右上角的“退出”或用户昵称下拉菜单中的“退出” 2. 在确认提示框中点击“确定”	1. 跳转至登录页面 2. 浏览器本地存储中的token被清除 3. 再次访问首页会被拦截并跳转登录页	P0

---

八、P0/P00级别用户故事测试用例

P0/P00级别用例对应的是系统的核心功能，一旦失效会导致系统不可用或核心价值无法实现。

用户故事一：作为内容编辑，我希望能够安全地登录管理系统，以便开始管理工作。

• •

  用户故事测试焦点：身份认证与访问安全。

• •

  关联测试用例：

  • •

    AUTH-001（成功登录）

  • •

    AUTH-003（登录失败-密码错误）

  • •

    AUTH-004（登录失败-SQL注入攻击）

  • •

    AUTH-006（未登录访问拦截）

  • •

    LOGOUT-001（安全退出系统）

用户故事二：作为作者，我希望能够创建并发布一篇新文章，以便让读者看到。

• •

  用户故事测试焦点：核心业务链路的完整性。

• •

  关联测试用例：

  • •

    ARTICLE-001（成功发布文章）-- 这是最核心的P00用例

  • •

    ARTICLE-002（发布文章-标题超长校验）- 确保数据完整性

  • •

    ARTICLE-006（编辑并更新现有文章）- 核心CRUD操作

  • •

    ARTICLE-008（删除文章-确认删除）- 核心CRUD操作

Postmen接口测试

• 文章分类
• 文章管理
• 用户接口
• 其他接口
  接口展示如下图：