INFO5990-Week11-Lecture-Summary
一、本周整体框架
Week 11 Lecture 的主题是 Quality Assurance and Software Testing（质量保证与软件测试），从"什么是质量"出发，讲到 QA 的标准与治理框架、持续改进模型、软件测试的生命周期与类型，以及 QA 在不同开发方法论中的角色。
本周讲义按以下议程（Agenda）展开：
- Foundations of Quality in IT（IT 质量基础）
- QA in IT Practice（QA 在 IT 中的实践：标准与治理框架）
- Software Testing Fundamentally（软件测试基础）
- Types of Testing（测试类型）
- QA in Software Development Methodologies（QA 在开发方法论中的应用）
核心逻辑链：
先理解质量的多维含义与劣质的代价 → 用 QA（预防）/ QC（检测）/ Testing（验证） 区分职责 → 用标准（ISO 9000/27001）与治理框架（ITIL/COBIT/CMMI）把质量制度化 → 用 Deming 循环（PDCA）+ CMMI 成熟度驱动持续改进 → 用 STLC 与各类测试在每个阶段保证质量 → 最后看 QA 如何融入 Waterfall / Agile / DevOps。
二、Foundations of Quality in IT（IT 质量基础）
2.1 什么是 IT 质量
IT 质量是指软件产品或 IT 服务满足利益相关者需求与期望的程度，同时具备可靠、安全与可维护性。软件质量的维度包括：
- 功能性（Functionality）： 系统是否做了它应做的事？
- 可靠性（Reliability）： 在预期条件下能否稳定运行？
- 可用性（Usability）： 是否易用、可访问？
- 效率（Efficiency）： 是否最优地使用资源（CPU、内存、带宽）？
- 可维护性（Maintainability）： 更新、修复、改进是否容易？
- 可移植性（Portability）： 能否轻松部署到不同环境？
- 安全性（Security）： 能否保护数据、抵御威胁？
2.2 质量为何重要 + 劣质的代价
- 业务视角： 提升客户满意度、减少返工成本、建立信任。
- 技术视角： 防止缺陷、系统崩溃与漏洞。
- 专业/伦理视角： IT 专业人员有责任交付安全可靠的系统。
劣质成本（Cost of Poor Quality）： 直接成本（缺陷修复、停机、数据丢失）+ 间接成本（声誉受损、客户流失、法律风险）。两个著名失败案例：
- Ariane 5 火箭失败（1996）： 惯性参考系统的软件错误致火箭发射后 37 秒偏离航线自毁，损失约 3.7 亿美元。
- Knight Capital 交易故障（2012）： 新交易软件部署不完整，旧代码被误激活，产生大量非预期交易，45 分钟内损失 4.4 亿美元，公司濒临破产。
2.3 QA、QC 与 Testing 的区别（高频考点）
| 概念 | 性质 | 焦点 |
|---|---|---|
| 质量保证（QA） | 主动（proactive）、面向过程 | 通过有效可靠的流程预防缺陷，确保软件满足标准与期望 |
| 质量控制（QC） | 被动（reactive）、面向产品 | 在产品产出后检测缺陷，确保交付物符合规范 |
| 测试（Testing） | QC 的子集 | 执行系统以发现缺陷并核验需求；含验证（verification，把产品做对）与确认（validation，做对的产品） |
记忆口诀：QA 防患于未然（流程）、QC 事后把关（产品）、Testing 是 QC 的具体手段。
三、QA in IT Practice（标准与治理框架）
IT 中的 QA 是一套系统化流程，确保 IT 系统、软件与服务持续满足需求、行业标准与用户期望，其范围不止软件，还涵盖基础设施（服务器、网络、云）、流程（SDLC、ITIL 实践）与信息安全（合规、审计）。
3.1 ISO 9000（质量管理）
ISO 9000 是 ISO 制定的国际标准族，目标是确保组织持续交付满足客户与监管要求的产品与服务。七大原则： 客户导向、领导力、全员参与、过程方法、持续改进、基于事实的决策、关系管理。在 IT 中它确保软件开发/测试/交付流程清晰、跨项目一致、赢得客户信任并持续改进。
3.2 ISO/IEC 27001（信息安全管理）
ISO/IEC 27001 是信息安全管理体系（ISMS）的国际标准，提供系统化方法管理敏感信息，使其保持机密、准确与可用。主要目标： 保护信息的 CIA、建立 ISMS（政策/流程/控制的结构化框架）、降低数据泄露/黑客/内部威胁/人为错误风险、满足法律法规与合同要求。关键组成： 风险评估、安全控制（114 项控制、归为 14 类）、持续改进、管理层参与。它帮助组织展示可信度、降低泄露概率与影响，并与 GDPR、HIPAA、澳大利亚 APRA 等合规要求对齐。
3.3 QA 与治理框架
治理框架定义确保 IT 活动与业务目标、法规与质量标准对齐的结构、流程与实践。QA 保证产品与流程达到标准，治理提供监督与问责确保 QA 被一致地应用——二者共同营造质量与问责文化。关键框架：
- ITIL： 聚焦 IT 服务管理（ITSM），通过事件/变更/问题管理保证一致的服务交付。
- COBIT： 聚焦 IT 治理与管理，强调控制、风险管理与流程成熟度。
- CMMI： 聚焦软件与系统工程的流程成熟度，提供分级的流程改进路线图。
3.4 Deming 循环（PDCA）与 CMMI 成熟度
Deming 循环（PDCA） 是持续改进模型：Plan（识别问题/机会）→ Do（小规模实施）→ Check（对照预期评估结果）→ Act（标准化成功做法）。
CMMI（能力成熟度模型集成） 提供组织流程演进的成熟度路线图，常与 ISO 9001 和 Deming 循环结合。二者关系：Deming 回答"如何持续改进"，CMMI 回答"组织处于哪一成熟度、下一步是什么"。五个等级：
- Level 1（初始）： 流程临时、混乱，无 PDCA。
- Level 2（已管理）： 项目级有基本的 Plan–Do，但 Check–Act 有限。
- Level 3（已定义）： 流程在组织层面标准化、文档化，Plan–Do 一致，有一定 Check–Act。
- Level 4（量化管理）： 强调 Check，流程被统计度量与控制，决策数据驱动。
- Level 5（优化）： 持续 Act，主动改进与创新。
3.5 质量审计（Quality Audits）
质量审计是系统化、独立的检查，判定活动与结果是否符合既定安排（标准、流程、要求）并被有效实施。目标： 核验合规、识别差距/低效/风险、推荐改进、建立组织信任。类型： 内部审计（第一方，组织自查）、外部审计（第二/三方，客户或认证/监管机构，如 ISO 9000 认证）、过程审计、产品审计、系统审计（评估整体质量管理体系 QMS）。
四、Software Testing Fundamentals（软件测试基础）
4.1 软件测试生命周期（STLC）
STLC 是在测试过程中开展的一系列特定活动，确保软件达到质量标准。它与 SDLC 平行，但专注于软件的验证与确认。关键特征：与 SDLC 并行、需求一就绪即开始测试（左移测试，shift-left）、迭代进行（每个 sprint/版本可重复）、在每个阶段而非仅在最后保证质量。
测试阶段：
| 阶段 | 说明 |
|---|---|
| 需求分析 | QA 分析功能与非功能需求，识别可测试需求并与利益相关者澄清歧义 |
| 测试计划 | 定义范围、目标、资源、进度与职责，评估风险并制定缓解策略 |
| 测试设计 | 设计含输入/预期输出/条件的测试用例，准备测试数据并同行评审 |
| 环境搭建 | 准备硬件、软件、网络与工具（常用 DevOps 流水线或容器化环境，如 Docker/Kubernetes） |
| 测试执行 | 手动或自动执行用例、记录结果，对失败提出缺陷/Bug 报告 |
| 缺陷报告与跟踪 | 在缺陷跟踪系统中记录、排序缺陷，与开发协作及时修复 |
| 测试周期收尾 | 评估退出标准（用例已执行、关键缺陷已关闭），分析覆盖率并产出测试总结报告（TSR） |
4.2 测试制品（Test Artifacts）
测试制品是 STLC 中产生的文档与交付物，提供测试活动的证据、支持可追溯性、帮助评估软件质量。好处：可追溯性（连接需求与测试，确保无遗漏）、问责（提供尽职与合规证据，如 ISO、CMMI）、沟通（让管理者/客户/审计员了解质量状态）。三类重要制品：
- 测试计划（Test Plan）： 高层文档，定义测试的范围、方法、目标、资源、进度与职责——回答"测什么、怎么测、何时测、谁测、用什么工具"。
- 测试用例（Test Case）： 验证某项功能的详细分步指令，含 ID、前置条件、测试步骤、预期结果、实际结果、状态（通过/失败）。
- 测试数据（Test Data）： 用例中使用的输入值，含有效数据、无效数据、边界数据（如密码长度恰为 8 或 20）与大批量数据（用于性能/负载测试）。
五、Types of Testing（测试类型）
5.1 功能测试 vs 非功能测试
| 方面 | 功能测试（Functional） | 非功能测试（Non-functional） |
|---|---|---|
| 目的 | 验证系统是否按需求/功能行事 | 评估系统在特定条件下表现如何（质量属性） |
| 焦点 | 系统做什么（功能、操作、交互） | 系统表现如何（性能、可用性、可靠性、安全） |
| 需求来源 | 功能需求（如"用户可用账号密码登录"） | 非功能需求（如"系统须支持 1000 并发用户"） |
| 测试数据 | 确定性的输入/输出场景 | 基于指标：响应时间、吞吐量、错误率 |
| 自动化可行性 | 高（单元与集成测试常自动化） | 部分（部分性能/安全可自动化，可用性常为手动） |
| 示例 | 单元、集成、系统、UAT 测试 | 性能、安全、可用性、兼容性测试 |
5.2 功能测试
- 单元测试（Unit）： 隔离测试最小单元（函数、方法、类），确保每个单元按预期工作，通常由开发者完成。
- 集成测试（Integration）： 测试模块/组件间的交互，验证组合后正确协作；方法有大爆炸（Big Bang，一次性整合）、自顶向下（Top-Down，用桩 stub）、自底向上（Bottom-Up，用驱动 driver）。
- 系统测试（System）： 测试完整集成的系统整体，验证是否满足规定需求，由独立 QA/测试团队执行。
- 用户验收测试（UAT）： 发布前由真实用户/客户测试，确保满足业务需求；含 Alpha 测试（内部团队以终端用户视角）与 Beta 测试（外部用户在真实环境）。
- 黑盒测试（Black Box）： 不看内部代码，关注输入与输出；技术如边界值分析、等价类划分。
- 白盒测试（White Box）： 测试内部逻辑、路径与代码结构，关注代码覆盖、循环、条件；由懂代码者执行。
5.3 非功能测试
- 负载测试（Load）： 检验系统在预期用户负载下的表现（响应时间、吞吐量、资源使用），如模拟 10,000 用户同时登录。
- 压力测试（Stress）： 将系统推到极限之外以测试崩溃点与故障后恢复，如施加 5 倍流量直至崩溃并观察恢复。
- 冒烟测试（Smoke）： 新构建/部署后对基本功能的快速检查（"构建验证"），确保稳定到可继续测试。
- A/B 测试： 比较两个版本（A 与 B）哪个对用户表现更好，用于提升可用性、转化或参与度（如红色按钮 vs 蓝色按钮）。
六、QA in Software Development Methodologies（QA 在开发方法论中的应用）
- Waterfall 中的 QA： 在生命周期的特定节点做验证与确认——需求阶段确保需求完整/一致/可测试，设计阶段核验架构与设计文档，实现阶段确保编码规范，测试阶段由专门 QA 团队执行功能与非功能测试，部署/维护阶段确保发布就绪。
- Agile 中的 QA： 贯穿整个生命周期而非末期单独阶段——参与故事细化与估算以确保验收标准清晰可测、按 sprint 而非整体提前规划测试、与开发紧密协作 TDD/BDD、持续测试即时修复缺陷、强调自动化、参与 sprint 评审与回顾。
- DevOps 中的 QA： 完全融入交付流水线，强调自动化、监控与持续反馈——QA 嵌入 CI/CD 以尽早发现缺陷、高度依赖测试自动化支持快速发布、尽早开始 QA、监控生产环境的错误/性能/用户体验、由开发/测试/运维/安全协作共担质量。
专业问题与未来趋势
QA 不只是流程与测试，还涉及专业与伦理责任：确保软件安全可靠、满足用户需求；遵守监管与法律标准；处理敏感数据时的保密与数据隐私。未来的 QA 正从阶段驱动的被动过程演变为持续、主动、自动化的质量管理，AI、云、IoT、DevOps 等正在重塑测试实践，未来 QA 人员需兼具技术、分析与协作能力。
QA 角色在不同环境中的差异
| 方面 | Waterfall | Agile | DevOps |
|---|---|---|---|
| QA 何时发生 | 生命周期末期 | sprint 内持续 | 内建于 CI/CD 流水线 |
| 你的角色 | QA 专员核验交付物、重文档 | 开发 + QA 紧密协作、共担 | 人人（开发/QA/运维/安全）共担质量 |
| 专业风险 | 缺陷发现晚→返工成本高 | 快速迭代中漏测→质量风险 | 过度依赖自动化→疏漏风险 |
| 伦理与标准 | 合规 ISO/CMMI、审计检查 | 对利益相关者透明、验收标准清晰 | 持续监控、隐私与安全合规 |
七、End of Lecture Questions（课后复习问题与参考答案）
描述 Deming 循环（PDCA）及其与 QA 的关系。 PDCA 即 Plan（计划/识别问题）→ Do（小规模实施）→ Check（评估结果）→ Act（标准化成功做法），是 QA 与流程管理的持续改进基础，让质量改进成为循环往复、数据驱动的过程。
什么是 CMMI，其成熟度等级如何与 QA 流程相关？ CMMI 是流程改进框架，分五级（初始→已管理→已定义→量化管理→优化）。等级越高，流程越标准化、可度量、可持续改进；QA 确保流程被一致执行，CMMI 衡量并提升这些流程的成熟度。
列举并简述 STLC 的各阶段。 需求分析 → 测试计划 → 测试设计 → 环境搭建 → 测试执行 → 缺陷报告与跟踪 → 测试周期收尾，强调左移与迭代、全程保证质量。
从焦点、责任、时机比较单元、集成、系统与 UAT 测试。 单元（最小代码单元、开发者、最早）→ 集成（模块间交互、开发/测试）→ 系统（完整系统、独立 QA）→ UAT（业务需求、真实用户/客户、发布前），范围由小到大、责任由开发转向用户。
解释 QA 在 Waterfall、Agile、DevOps 中的差异。 Waterfall 在末期集中验证、重文档；Agile 贯穿 sprint、协作共担、强调自动化与持续测试；DevOps 内建于 CI/CD、自动化 + 监控、全员共担。
ISO 9000 与 ISO 27001 如何影响 QA 实践？ ISO 9000 通过质量管理原则（客户导向、过程方法、持续改进等）使 QA 流程一致可审计；ISO 27001 通过 ISMS 保障信息的 CIA，使 QA 涵盖信息安全合规——二者共同把质量与安全制度化。
八、Case Study：在线银行平台
8.1 背景
某银行正在开发新的在线银行平台（登录、转账、缴费、查看交易记录）。开发期间发现若干问题：部分用户登录失败的严重 Bug；高峰时段交易处理变慢；安全扫描发现密码存储漏洞；QA 文档不完整，导致漏测用例。
8.2 案例讨论问题
- 说明需求与测试用例之间的可追溯性如何防止漏测用例。
- 哪种性能测试能识别高峰时段的变慢？在此情境中解释负载（load）、压力（stress）与浸泡（soak）测试的区别。
- 若银行带着已知的登录与安全问题发布系统，会有哪些专业或伦理问题？
- 结合 DevOps 实践，说明持续测试与监控如何防止类似问题流入生产。
参考思路： ①可追溯性把每条需求映射到对应测试用例，确保无需求遗漏、覆盖完整；②变慢应用负载测试复现高峰，负载=预期负载下表现、压力=超极限找崩溃点、浸泡=长时间持续负载查内存泄漏等；③带病上线违反"交付安全可靠系统"的伦理责任与合规要求（如密码明文存储违反数据保护法），损害客户信任与法律责任；④DevOps 通过 CI/CD 持续测试在早期拦截缺陷、自动化安全扫描、生产环境持续监控性能与异常，从而预防同类问题复发。
九、考试速查表（Quick Reference）
质量七维度
功能性、可靠性、可用性、效率、可维护性、可移植性、安全性。
QA / QC / Testing
QA = 主动·面向过程·预防缺陷；QC = 被动·面向产品·检测缺陷；Testing = QC 子集（验证 + 确认）。
标准
ISO 9000 = 质量管理（7 原则）；ISO 27001 = 信息安全 ISMS（CIA、114 控制 / 14 类）。
持续改进
Deming 循环 = Plan → Do → Check → Act；CMMI 五级 = 初始 → 已管理 → 已定义 → 量化管理 → 优化。
STLC
需求 → 计划 → 设计 → 环境 → 执行 → 缺陷跟踪 → 收尾（左移、迭代）。
测试类型
- 功能：单元 → 集成（大爆炸/自顶向下/自底向上）→ 系统 → UAT（Alpha/Beta）；黑盒 vs 白盒。
- 非功能：负载、压力、冒烟、A/B。
QA × 方法论
Waterfall（末期、重文档）/ Agile（贯穿 sprint、TDD/BDD、自动化）/ DevOps（CI/CD 内建、自动化 + 监控、全员共担）。