Add PPT presentation outline document

docs/17_PPT汇报大纲与页面设计.md

@@ -0,0 +1,547 @@
+# ServicePilot 软测大作业 PPT 汇报大纲与页面设计
+
+## 一、汇报定位
+
+### 1. 汇报主题
+
+《ServicePilot 智能客户工单与 SLA 履约管理平台综合测试实践汇报》
+
+### 2. 汇报目标
+
+本次 PPT 不做单纯的系统功能展示，而是围绕“商业项目规划 + 系统落地 + 综合测试实践”展开，重点体现：
+
+- 项目选题具备真实商业场景和完整业务闭环。
+- 系统实现满足指定技术栈要求：Angular、GSAP、React 组件、Node.js、TypeScript、Express、Parse。
+- 测试方案按课程要求拆分为单元测试、接口测试、自动化测试、性能测试四类。
+- 测试执行有真实脚本、日志、截图、CSV、HTML 报告和 Word 报告作为证据。
+- 最终结论能够说明系统质量达到本次大作业验收标准。
+
+### 3. 推荐汇报时长
+
+| 模块 | 建议时间 |
+|---|---:|
+| 项目背景与系统介绍 | 2 分钟 |
+| 技术架构与功能模块 | 2 分钟 |
+| 测试计划与测试范围 | 2 分钟 |
+| 四类测试执行与结果 | 5 分钟 |
+| 总结反思 | 1 分钟 |
+
+总时长建议控制在 10 到 12 分钟。
+
+## 二、整体视觉设计规范
+
+### 1. 设计风格
+
+建议采用“企业 SaaS 产品汇报 + 软件测试报告”的风格，整体应简洁、规范、数据清晰，避免做成花哨的宣传页。
+
+### 2. 配色建议
+
+| 用途 | 颜色建议 | 说明 |
+|---|---|---|
+| 主色 | 深蓝 `#1E3A8A` | 用于标题、页眉、重点线条 |
+| 辅助色 | 青蓝 `#0891B2` | 用于架构图、流程箭头、强调数据 |
+| 成功色 | 绿色 `#16A34A` | 用于 PASS、通过率、0 失败 |
+| 警示色 | 橙色 `#F59E0B` | 用于风险、不足、后续优化 |
+| 背景色 | 浅灰 `#F8FAFC` | 用于页面底色 |
+| 正文字色 | 深灰 `#1F2937` | 用于正文内容 |
+
+### 3. 字体建议
+
+| 层级 | 字号 | 字体 |
+|---|---:|---|
+| 封面标题 | 32-36 pt | 微软雅黑 / 思源黑体 |
+| 页面标题 | 24-28 pt | 微软雅黑加粗 |
+| 小标题 | 16-18 pt | 微软雅黑加粗 |
+| 正文 | 13-15 pt | 微软雅黑 |
+| 表格文字 | 11-13 pt | 微软雅黑 |
+
+### 4. 版式原则
+
+- 每页只讲一个核心观点。
+- 测试结果页优先使用表格、数字卡片、图表，不堆长段文字。
+- 每页底部可放统一页脚：`ServicePilot 综合测试实践汇报`。
+- 章节过渡页可以少用，除非答辩时间较长。
+- 截图要作为证据使用，配简短标题，不要占满整页导致结论缺失。
+
+## 三、PPT 总体结构
+
+| 页码 | 页面标题 | 汇报重点 |
+|---:|---|---|
+| 1 | 封面 | 项目名称、课程、姓名学号 |
+| 2 | 汇报目录 | 展示整体汇报逻辑 |
+| 3 | 项目背景与选题说明 | 为什么选这个商业项目 |
+| 4 | 系统业务目标 | 项目解决什么业务问题 |
+| 5 | 系统功能模块 | 展示系统模块完整性 |
+| 6 | 技术架构与技术栈落地 | 对照作业技术要求 |
+| 7 | 综合测试总体计划 | 四类测试整体规划 |
+| 8 | 单元测试设计与结果 | 核心业务规则验证 |
+| 9 | 接口测试设计与结果 | Express API 契约验证 |
+| 10 | 自动化测试设计与结果 | 前端页面流程验证 |
+| 11 | 性能测试设计 | Locust 压测场景与指标 |
+| 12 | 性能测试结果 | 后端/前端压测数据 |
+| 13 | 测试结论与质量评估 | 汇总验收结果和证据 |
+| 14 | 总结与反思 | 收获、不足、后续优化 |
+
+## 四、逐页内容与设计方案
+
+## 第 1 页：封面
+
+### 页面目标
+
+明确汇报主题，让老师第一眼知道这是“商业项目 + 综合测试实践”的大作业汇报。
+
+### 页面标题
+
+ServicePilot 智能客户工单与 SLA 履约管理平台  
+综合测试实践汇报
+
+### 页面内容
+
+- 课程名称：综合测试实践 04 商业项目规划
+- 项目名称：ServicePilot 智能客户工单与 SLA 履约管理平台
+- 学生信息：学号、姓名、班级
+- 汇报日期：2026 年 6 月
+
+### 页面设计
+
+- 背景使用浅灰或浅蓝渐变，不要过度复杂。
+- 中间放大标题，副标题居中。
+- 右下角放项目关键词：`Angular`、`Express`、`Parse`、`Jest`、`Playwright`、`Locust`。
+- 可加入一张系统工作台截图的低透明度背景，体现项目真实落地。
+
+### 讲述重点
+
+本次汇报围绕 ServicePilot 平台展开，重点说明项目实现情况和综合测试执行结果。
+
+## 第 2 页：汇报目录
+
+### 页面目标
+
+建立汇报结构，让后续内容有清晰顺序。
+
+### 页面内容
+
+1. 项目背景与系统概述
+2. 技术架构与功能模块
+3. 综合测试计划
+4. 四类测试执行结果
+5. 测试结论与总结反思
+
+### 页面设计
+
+- 使用左侧纵向编号导航，右侧放每个部分的关键词。
+- 每个目录项配一个简洁图标：项目、架构、计划、测试、总结。
+- 当前页不放大段文字。
+
+### 讲述重点
+
+说明汇报逻辑先介绍“测什么”，再介绍“怎么测”，最后说明“测得怎么样”。
+
+## 第 3 页：项目背景与选题说明
+
+### 页面目标
+
+说明为什么选择客户工单与 SLA 履约管理平台，体现商业项目属性。
+
+### 页面内容
+
+- 企业售后、客服、运维场景中，经常存在工单处理不透明、响应时间不可控、服务质量难追踪等问题。
+- ServicePilot 面向企业服务团队，提供工单提交、分派、处理、SLA 监控、知识库沉淀、附件管理和满意度评价。
+- 该选题业务链路完整、角色权限明确、数据结构复杂，适合进行综合测试设计。
+
+### 页面设计
+
+- 左侧放“业务痛点”三张小卡片：
+  - 工单处理不透明
+  - SLA 超时难预警
+  - 服务质量缺少量化反馈
+- 右侧放“系统目标”流程箭头：
+  - 提交工单 → 分派处理 → SLA 监控 → 解决关闭 → 满意度评价
+
+### 讲述重点
+
+强调本项目不是单页面练习，而是有完整商业业务闭环，因此适合做软测综合实践。
+
+## 第 4 页：系统业务目标
+
+### 页面目标
+
+展示系统要解决的核心业务问题和业务闭环。
+
+### 页面内容
+
+系统核心目标：
+
+- 支持客户提交和跟踪工单。
+- 支持客服、技术支持、管理员多角色协作。
+- 根据 SLA 规则监控响应和处理时限。
+- 通过知识库提升问题复用和处理效率。
+- 支持附件上传、满意度评价和数据看板分析。
+
+### 页面设计
+
+- 使用一张横向业务流程图：
+  - 客户提交工单
+  - 客服初审
+  - 技术支持处理
+  - SLA 告警
+  - 工单关闭
+  - 满意度评价
+  - 数据看板复盘
+- 每个节点下方写 1 个关键测试关注点，例如“状态流转”“权限隔离”“超时判断”。
+
+### 讲述重点
+
+说明测试设计不是孤立测试页面，而是围绕这条业务流程进行覆盖。
+
+## 第 5 页：系统功能模块
+
+### 页面目标
+
+说明项目实际实现了哪些页面和模块。
+
+### 页面内容
+
+| 模块 | 主要功能 |
+|---|---|
+| 登录模块 | 用户登录、角色进入系统 |
+| 工作台 | 指标总览、工单趋势、风险概览 |
+| 工单管理 | 工单查询、新增、编辑、状态流转 |
+| SLA 管理 | SLA 规则、预警、超时状态 |
+| 知识库 | 常见问题、处理方案沉淀 |
+| 附件管理 | 文件上传、预览、类型校验 |
+| 满意度评价 | 星级评价、反馈统计 |
+| 测试计划页面 | 系统测试计划展示 |
+
+### 页面设计
+
+- 使用 2 行 4 列模块卡片。
+- 每张卡片包含模块名称、一个图标、1 句功能说明。
+- 右侧或底部放 2 到 3 张系统页面截图缩略图，例如工作台、工单管理、SLA 页面。
+
+### 讲述重点
+
+说明系统页面覆盖了 PRD 中的核心模块，为后续单元、接口、自动化和性能测试提供对象。
+
+## 第 6 页：技术架构与技术栈落地
+
+### 页面目标
+
+对照老师要求，说明技术栈确实落地。
+
+### 页面内容
+
+| 层级 | 技术 | 落地说明 |
+|---|---|---|
+| 前端 | Angular + TypeScript | 页面路由、组件化开发、业务视图 |
+| 前端动画 | GSAP | 工作台、列表、页面过渡动效 |
+| 前端组件 | React 组件嵌入 | 图片预览、星级评价组件 |
+| 后端 | Node.js + TypeScript + Express | API 服务、健康检查、配置接口 |
+| 数据库 | Parse / Back4App | 数据表结构、权限隔离、Mock 数据 |
+| 测试工具 | Jest、Supertest、Playwright、Locust | 四类测试脚本和结果证据 |
+
+### 页面设计
+
+- 使用分层架构图：
+  - 用户浏览器
+  - Angular 前端
+  - React 嵌入组件 / GSAP 动画
+  - Express API
+  - Parse 数据服务
+  - 测试工具链
+- 每层用不同颜色区分。
+
+### 讲述重点
+
+突出这页是“技术栈验收页”，明确 Angular、GSAP、React、Node.js、TS、Express、Parse 都有对应落点。
+
+## 第 7 页：综合测试总体计划
+
+### 页面目标
+
+说明测试按课程要求拆分为四个测试部分，而不是按网站页面随意描述。
+
+### 页面内容
+
+| 测试类型 | 测试对象 | 工具 | 验收标准 |
+|---|---|---|---|
+| 单元测试 | 工单规则、权限、SLA、附件规则 | Jest | 核心规则 100% 通过 |
+| 接口测试 | Health、Parse 配置、404 契约 | Jest + Supertest | 状态码和响应结构正确 |
+| 自动化测试 | 7 个前端关键页面 | Playwright | 页面 200、截图生成、7/7 通过 |
+| 性能测试 | 后端接口、前端页面 | Locust | 错误率 < 1%、P95 < 1000ms |
+
+### 页面设计
+
+- 中间使用测试金字塔或四象限矩阵。
+- 每类测试使用统一结构：范围、工具、数量、标准。
+- 右下角放测试产物路径：
+  - `tests/unit_tests`
+  - `tests/api_tests`
+  - `tests/auto_tests`
+  - `tests/performance_tests`
+
+### 讲述重点
+
+强调测试计划是按作业要求的四类测试组织，后续结果也按这四类汇报。
+
+## 第 8 页：单元测试设计与结果
+
+### 页面目标
+
+说明单元测试覆盖核心业务规则，证明后端规则函数可靠。
+
+### 页面内容
+
+| 测试模块 | 测试点 | 用例数 | 结果 |
+|---|---|---:|---|
+| 工单状态 | 合法流转、非法流转、关闭状态不可重开 | 8 | 通过 |
+| 权限隔离 | 客户、客服、技术支持、管理员读取权限 | 7 | 通过 |
+| SLA 规则 | 截止时间、预警、超时判断 | 6 | 通过 |
+| 附件规则 | 类型限制、大小限制、空文件 | 5 | 通过 |
+| 合计 | 核心业务规则 | 26 | 100% 通过 |
+
+### 页面设计
+
+- 左侧放测试覆盖表。
+- 右侧放一个大数字卡片：
+  - `26/26 PASS`
+  - `通过率 100%`
+- 底部放脚本路径：
+  - `tests/unit_tests/run_unit_tests.ps1`
+  - `tests/unit_tests/reports/unit_test_log.txt`
+
+### 讲述重点
+
+说明单元测试重点不是测页面，而是测业务规则本身，包括状态流转、权限、SLA 和附件校验。
+
+## 第 9 页：接口测试设计与结果
+
+### 页面目标
+
+说明后端 Express API 的基础契约、安全字段和错误响应已验证。
+
+### 页面内容
+
+| 接口 | 测试内容 | 预期 | 结果 |
+|---|---|---|---|
+| `GET /api/health` | 服务健康检查 | 200 | 通过 |
+| `GET /api/config/parse` | 返回前端 Parse 配置 | 200 | 通过 |
+| `GET /api/config/parse` | 不暴露敏感字段 | 无 masterKey/restApiKey | 通过 |
+| `GET /api/unknown-resource` | 未知接口 | 404 | 通过 |
+| `POST /api/ghost` | 错误信息包含方法和路径 | 404 | 通过 |
+
+### 页面设计
+
+- 使用接口列表表格。
+- 右上角放结果卡片：
+  - `5/5 PASS`
+  - `2 个测试套件通过`
+- 可以放一小段日志截图或终端结果截图。
+
+### 讲述重点
+
+说明接口测试验证的是 API 契约，包括正常响应、错误响应和配置安全性。
+
+## 第 10 页：自动化测试设计与结果
+
+### 页面目标
+
+说明前端关键页面通过浏览器自动化访问，并生成截图证据。
+
+### 页面内容
+
+| 编号 | 页面 | 验证点 | 结果 |
+|---|---|---|---|
+| AUTO-001 | `/dashboard` | 工作台页面可访问 | PASS |
+| AUTO-002 | `/tickets` | 工单管理页面可访问 | PASS |
+| AUTO-003 | `/sla` | SLA 页面可访问 | PASS |
+| AUTO-004 | `/knowledge` | 知识库页面可访问 | PASS |
+| AUTO-005 | `/files` | 附件页面可访问 | PASS |
+| AUTO-006 | `/reviews` | 满意度页面可访问 | PASS |
+| AUTO-007 | `/test-plan` | 测试计划页面可访问 | PASS |
+
+### 页面设计
+
+- 左侧放 7 条自动化流程表。
+- 右侧放 2 张截图证据：
+  - 工作台截图
+  - 工单管理或 SLA 页面截图
+- 页面底部放证据目录：
+  - `tests/auto_tests/artifacts`
+  - `tests/auto_tests/reports/auto_test_summary.txt`
+
+### 讲述重点
+
+说明自动化测试不是人工打开页面，而是 Playwright 自动访问、校验 HTTP 状态、生成页面截图。
+
+## 第 11 页：性能测试设计
+
+### 页面目标
+
+说明 Locust 压测设计，包括测试对象、并发配置和指标标准。
+
+### 页面内容
+
+性能测试分为两组：
+
+1. 后端接口性能测试
+   - `GET /api/health`
+   - `GET /api/config/parse`
+   - `GET /api/unknown-resource`
+
+2. 前端页面性能测试
+   - `/dashboard`
+   - `/tickets`
+   - `/sla`
+   - `/knowledge`
+   - `/files`
+   - `/reviews`
+   - `/test-plan`
+
+压测配置：
+
+- 并发用户：30
+- 启动速率：5 用户/秒
+- 持续时间：3 分钟
+- 验收标准：错误率 < 1%，P95 < 1000ms，服务不崩溃
+
+### 页面设计
+
+- 左侧放 Locust 压测配置卡片。
+- 右侧放“后端接口”和“前端页面”两个压测场景框。
+- 使用箭头表示 Locust 对服务发起并发请求。
+
+### 讲述重点
+
+说明性能测试不是只写脚本，而是已安装 Locust 并真实执行，生成 HTML 和 CSV 报告。
+
+## 第 12 页：性能测试结果
+
+### 页面目标
+
+用数据证明性能测试通过。
+
+### 页面内容
+
+| 测试对象 | 请求总数 | 失败数 | 失败率 | 平均响应时间 | P95 | 吞吐量 | 结论 |
+|---|---:|---:|---:|---:|---:|---:|---|
+| 后端接口 | 2656 | 0 | 0% | 2.77 ms | 4 ms | 14.84 req/s | 通过 |
+| 前端页面 | 24311 | 0 | 0% | 4.29 ms | 9 ms | 135.88 req/s | 通过 |
+
+### 页面设计
+
+- 顶部放两个大数字卡片：
+  - 后端：`2656 请求 / 0 失败`
+  - 前端：`24311 请求 / 0 失败`
+- 中间放结果对比表。
+- 底部放小型柱状图：
+  - 平均响应时间：后端 2.77ms，前端 4.29ms
+  - P95：后端 4ms，前端 9ms
+- 右下角放报告路径：
+  - `backend-performance-report.html`
+  - `frontend-performance-report.html`
+
+### 讲述重点
+
+重点说失败率均为 0%，P95 远低于 1000ms，因此性能测试满足验收标准。
+
+## 第 13 页：测试结论与质量评估
+
+### 页面目标
+
+汇总四类测试结果，形成最终质量判断。
+
+### 页面内容
+
+| 测试类型 | 数量 | 通过情况 | 结论 |
+|---|---:|---|---|
+| 单元测试 | 26 条 | 26 通过 | 通过 |
+| 接口测试 | 5 条 | 5 通过 | 通过 |
+| 自动化测试 | 7 条 | 7 通过 | 通过 |
+| 性能测试 | 2 组 | 0 失败 | 通过 |
+
+质量结论：
+
+- 核心业务规则验证通过。
+- 后端接口契约验证通过。
+- 前端关键页面自动化验证通过。
+- 后端接口和前端页面性能测试通过。
+- 测试证据完整，包括日志、截图、CSV、HTML、Markdown、Word 报告。
+
+### 页面设计
+
+- 使用一张“测试结果总览表”。
+- 右侧放绿色通过徽章：`综合测试通过`。
+- 下方用图标列出证据类型：
+  - 脚本
+  - 日志
+  - 截图
+  - HTML 报告
+  - CSV 明细
+  - Word 报告
+
+### 讲述重点
+
+说明最终质量判断不是主观判断，而是基于四类测试结果和证据文件。
+
+## 第 14 页：总结与反思
+
+### 页面目标
+
+总结本次大作业收获、不足和后续改进方向。
+
+### 页面内容
+
+项目收获：
+
+- 完成了从商业选题、PRD、数据库设计、系统实现到测试报告的完整闭环。
+- 熟悉了 Angular 前端、Express 后端、Parse 数据服务的项目组织方式。
+- 建立了单元、接口、自动化、性能四类测试的分层测试意识。
+- 学会将测试结果沉淀为可交付证据。
+
+不足与改进：
+
+- 当前性能测试规模是课程实践规模，后续可扩大并发用户数和测试时长。
+- 可继续补充更多异常场景，例如登录失败、权限越权、附件上传异常。
+- 可引入 CI 流程，让测试在代码提交后自动运行。
+- 可进一步完善真实业务数据和多租户隔离测试。
+
+### 页面设计
+
+- 左侧放“收获”列表，右侧放“后续优化”列表。
+- 使用两列对比布局。
+- 底部放结束语：`谢谢老师，请批评指正`。
+
+### 讲述重点
+
+不要只说“完成了项目”，要强调完成了软件测试实践中的计划、执行、证据和质量评估闭环。
+
+## 五、可直接使用的汇报开场词
+
+各位老师好，我本次汇报的项目是 ServicePilot 智能客户工单与 SLA 履约管理平台。该项目面向企业客服、售后和运维服务场景，围绕工单提交、处理、SLA 履约、知识库沉淀和满意度评价形成完整业务闭环。本次汇报将从项目背景、系统实现、测试计划、四类测试执行结果和总结反思五个方面展开，重点汇报综合测试的设计过程和测试结果。
+
+## 六、可直接使用的结尾词
+
+综上，本项目完成了从商业项目规划、系统开发到综合测试执行的完整过程。测试部分按照课程要求拆分为单元测试、接口测试、自动化测试和性能测试四类，并保留了脚本、日志、截图、HTML 报告、CSV 明细和 Word 报告等证据。最终结果显示，四类测试均达到预期验收标准，ServicePilot 在课程实践规模下具备较好的功能正确性、接口稳定性、页面可访问性和性能表现。我的汇报到此结束，谢谢老师。
+
+## 七、答辩可能被问到的问题
+
+### 1. 为什么选择这个题目？
+
+因为客户工单和 SLA 管理属于典型企业服务场景，业务链路完整，涉及角色权限、状态流转、文件管理、评价反馈和数据统计，适合进行较完整的软件测试设计。
+
+### 2. 测试为什么分成这四类？
+
+这四类对应课程综合测试要求，也符合软件测试分层思路：单元测试验证业务规则，接口测试验证后端契约，自动化测试验证前端页面流程，性能测试验证并发访问下的响应和稳定性。
+
+### 3. 性能测试结果为什么前端请求数比后端多？
+
+前端性能脚本一次任务会顺序访问 7 个页面，因此在相同并发和持续时间下，总请求数高于后端接口压测。
+
+### 4. React 在 Angular 项目中如何体现？
+
+项目中使用 React 组件作为前端局部能力补充，例如图片预览和星级评价组件，并通过 Angular wrapper 挂载到 Angular 页面中，满足 Angular 主框架下嵌入 React 组件的技术要求。
+
+### 5. GSAP 动画如何体现？
+
+GSAP 用于工作台、页面列表、卡片进入和页面过渡等前端交互动效，使系统不是静态页面，而是具备更好的前端体验和动效实现。