PCMM

Level 名称 关键词 核心机制
1 Initial 无流程，混乱 No process, chaos 靠个人，无法复制 individual & cannot be replicated
2 Managed 基础人事流程稳定 The basic personnel process is stable 招聘/绩效/激励机制初具雏形 The recruitment/performance/incentive mechanism has taken initial shape
3 Defined 全组织标准化 Standardization of the entire organization 能力模型、职业发展、知识库 Competency Model, Career Development, Knowledge Base
4 Predictable 数据驱动、可预测 Data-driven and predictable 度量模型、绩效预测 Measurement model, performance prediction
5 Optimizing 持续改进、快速学习 Continuous improvement and rapid learning 创新能力提升、组织学习文化 Innovation capacity enhancement, organizational learning culture

“Chaos → Control → Consistency → Calculation → Continuous Improvement”

🧠 类比法：把 P-CMM 想成「一家公司如何管理员工成长的五个阶段」

🎯 整体目标：

P-CMM 就像企业的人才成长“地图”。它帮助公司一步步从「人治混乱」进化到「高效、有文化、有学习能力」的团队组织。

🟩 Level 1: Initial 初始级

🔧 关键词：混乱、靠人撑

想象你刚进一家公司：
没有明确的岗位职责、没人帮你规划发展、干得好坏也没人评价，项目做得全靠“老王经验”，今天靠他，明天靠她。

  • 没有标准流程
  • 人员成长靠天分或运气
  • 公司甚至不知道哪些人厉害，也不知道怎么留住人

📌 类比：野路子创业公司，靠几个天才工程师硬撑。

🟨 Level 2: Managed 受控级

🧱 关键词：建立基本流程

公司意识到“不能只靠人顶”，开始制定一些基础规范：

  • 招聘流程统一起来了
  • 每个人有岗位职责描述
  • 有了绩效考核、入职培训

📌 类比：公司开始像样了，人力资源部上岗，入职会给你讲规章制度。

🟧 Level 3: Defined 已定义级

📘 关键词：组织标准化，能力模型

公司不满足于有流程，还想确保「每个岗位的人都符合要求」，于是：

  • 建立了能力模型：比如“高级前端工程师”需要哪些技术？
  • 所有人才发展路径开始组织统一管理
  • 有了晋升路径图，有明确的职业发展通道
  • 团队内部也开始有“知识分享”文化

📌 类比：你在大公司看到“技术等级标准表”、“培训课程地图”、技术导师制度。

🟦 Level 4: Predictable 可预测级

📊 关键词：数据说话，绩效可量化

现在公司说：不能只靠制度，我们要看“效果”！于是：

  • 收集每个人的绩效数据、离职率、培训结果等
  • 可以“预测”：如果我们给某团队提升技能，他们未来能承担更大项目
  • 绩效考核不再靠感觉，而是有量化指标

📌 类比：你公司 HR 发了一份“部门技能图谱”，说“前端组整体 CSS 能力平均 3.7 分”。

🟪 Level 5: Optimizing 优化级

🔁 关键词：持续改进，自驱成长

这时的公司已经非常成熟，它关注的是：

  • 持续优化员工能力：比如推动“轮岗”、“跨团队学习”
  • 鼓励员工自主学习、提出改进意见
  • 整个公司变成了“学习型组织”

📌 类比：你在团队开分享会、公司每年搞“学习黑客松”，员工主动参与改进流程。

级别 名称 关键词 类比
1 Initial 混乱，靠人撑 野路子创业团队
2 Managed 有基本流程 有 HR 的公司
3 Defined 标准化 + 能力模型 成熟大厂
4 Predictable 数据驱动 数据化绩效管理
5 Optimizing 自驱+持续优化 学习型组织

it helps an organization evolve from relying on heroic individuals to building a systematic, measurable, and continuously improving approach to workforce development.

✅ Agile（敏捷开发）复习全攻略

📘 一、Agile 定义（中英对照）

  • 英文：Agile is an iterative and incremental approach to software development that emphasizes flexibility, collaboration, and customer feedback.
  • 中文：敏捷是一种迭代式、增量式的软件开发方法，强调灵活应变、团队协作与客户反馈。

🧠 二、Agile Manifesto（敏捷宣言 4 对价值观）

原则英文（考试必记） 中文解释（助理解）
Individuals and interactions over processes and tools 重人不重工具
Working software over comprehensive documentation 可用软件胜过长篇文档
Customer collaboration over contract negotiation 客户合作重于合同
Responding to change over following a plan 快速应变胜过死守计划

🧩 三、Agile 与 Waterfall 对比（考试常考）

对比项 Agile 敏捷开发 Waterfall 瀑布式开发
流程结构 迭代循环 串行阶段
客户参与 高度参与 开发前签合同后很少沟通
计划变更 接受变更 抵抗变更
文档依赖 少文档，重沟通 文档齐全
交付方式 小步快跑，频繁交付 一次性交付

🔁 四、Agile 常见术语（必须认识）

术语 解释
Sprint 一次迭代开发周期（通常 1~4 周）
Scrum 一种流行的 Agile 框架
Product Backlog 所有功能的待办列表
User Story 以用户角度写的需求描述（如：“作为一个用户，我希望…”）
Sprint Review 迭代结束后的评审会议
Burndown Chart 展示工作量减少趋势的图
Daily Scrum 每日站会，3 问：昨天做了啥？今天做啥？遇到啥问题？

✅ 五、考试常见题型例子

Q1: Which of the following is NOT part of Agile methodology?
A. Continuous integration
B. Simple design
❌ C. Rigorous documentation
❌ D. Following a rigid plan
✅ → C 和 D 是 Waterfall 的特征！

Q2: What is a user story in Agile?
→ A short, informal description of a feature told from the user’s perspective.

🎯 小口诀（背诵总结）

“人优于工具、产品优于文档、客户胜合同、响应强计划”
Agile 四原则口诀助记

📘 1. ISO/IEC 25010：

  • Product Quality Model（软件产品质量模型）
  • Quality in Use Model（使用中的质量模型）

🧩 2. Product Quality 的 8 个特性（记关键词）：

特性编号 名称 中文含义 子特性（重点记）
1 Functional suitability 功能适合性 Functional correctness, completeness
2 Performance efficiency 性能效率 Time behavior, resource utilization
3 Compatibility 兼容性 Co-existence, interoperability
4 Usability 易用性 Learnability, user error protection
5 Reliability 可靠性 Maturity, fault tolerance, recoverability
6 Security 安全性 Confidentiality, integrity, non-repudiation
7 Maintainability 可维护性 Modularity, analysability, modifiability
8 Portability 可移植性 Adaptability, installability, replaceability

✅ 1. Functional Suitability 功能适合性

Definition 定义:
The degree to which the system provides functions that meet stated and implied needs.
系统在多大程度上提供符合明确和隐含需求的功能。

🔹 Sub-characteristics 子特性：

  • Functional completeness 功能完整性
    👉 Example: The e-commerce site supports search, filter, checkout, and payment functions as expected.
    👉 示例: 电商平台支持完整的搜索、筛选、结账和支付功能。
  • Functional correctness 功能正确性
    👉 Example: The total price calculation always includes the correct discount and tax.
    👉 示例: 系统始终正确地计算折扣和税费。
  • Functional appropriateness 功能适当性
    👉 Example: The one-click reorder function reduces steps for frequent buyers.
    👉 示例: “一键复购”功能简化了老客户的操作流程。

✅ 2. Performance Efficiency 性能效率

Definition 定义:
How the system uses resources and responds within acceptable time limits.
系统在可接受的时间和资源内完成任务的能力。

🔹 Sub-characteristics 子特性：

  • Time behavior 时间行为
    👉 Example: Product detail pages load in less than 2 seconds for 95% of users.
    👉 示例: 商品页面在 95% 的情况下加载时间低于 2 秒。
  • Resource utilization 资源利用率
    👉 Example: The server CPU remains below 75% during flash sales.
    👉 示例: 秒杀活动期间 CPU 占用率不超过 75%。
  • Capacity 容量处理能力
    👉 Example: The platform supports up to 10,000 simultaneous users without crashing.
    👉 示例: 平台支持最多 10,000 并发用户而不崩溃。

✅ 3. Compatibility 兼容性

Definition 定义:
The system’s ability to operate with other systems.
系统与其他系统共存或交互的能力。

🔹 Sub-characteristics 子特性：

  • Co-existence 共存性
    👉 Example: The desktop app coexists with antivirus software without conflict.
    👉 示例: 桌面程序与杀毒软件可以正常共存，不冲突。
  • Interoperability 互操作性
    👉 Example: Integrates smoothly with PayPal and Stripe through APIs.
    👉 示例: 系统可通过 API 与 PayPal、Stripe 支付系统顺利对接。

✅ 4. Usability 易用性

Definition 定义:
The ease with which users can learn and use the system.
用户学习和操作系统的难易程度。

🔹 Sub-characteristics 子特性：

  • Learnability 可学习性
    👉 Example: New users can complete checkout without training within 5 minutes.
    👉 示例: 新用户可在 5 分钟内无需培训完成结账流程。
  • Operability 可操作性
    👉 Example: Key actions like “Add to cart” are always within two clicks.
    👉 示例: 购物车按钮等关键操作不超过两次点击即可完成。
  • User error protection 用户错误预防
    👉 Example: Warns users before deleting saved addresses.
    👉 示例: 删除地址前弹出确认提示，避免误操作。
  • Accessibility 可访问性
    👉 Example: Fully navigable by screen readers for visually impaired users.
    👉 示例: 支持屏幕阅读器，方便视障用户操作系统。

✅ 5. Reliability 可靠性

Definition 定义:
The ability of the system to function under defined conditions.
系统在指定条件下持续工作的能力。

🔹 Sub-characteristics 子特性：

  • Maturity 成熟性
    👉 Example: The system has had no downtime in the past 6 months.
    👉 示例: 过去 6 个月无任何系统中断。
  • Fault tolerance 容错性
    👉 Example: If one payment server fails, another takes over seamlessly.
    👉 示例: 如果一个支付节点故障，系统能自动切换至备用节点。
  • Recoverability 可恢复性
    👉 Example: User sessions are restored within 10 seconds after a crash.
    👉 示例: 系统崩溃后在 10 秒内恢复用户会话。
  • Availability 可用性
    👉 Example: The website guarantees 99.9% uptime per month.
    👉 示例: 网站每月可用性保证达 99.9%。

✅ 6. Security 安全性

Definition 定义:
The system protects information and prevents unauthorized access.
系统保护信息安全，防止未经授权的访问。

🔹 Sub-characteristics 子特性：

  • Confidentiality 机密性
    👉 Example: User passwords are stored using SHA-256 encryption.
    👉 示例: 用户密码使用 SHA-256 加密存储。
  • Integrity 完整性
    👉 Example: Order records are digitally signed to prevent tampering.
    👉 示例: 订单记录加签防篡改。
  • Non-repudiation 不可否认性
    👉 Example: Admin actions are logged with timestamps and usernames.
    👉 示例: 所有管理员操作都有时间戳和用户名记录，防止事后抵赖。
  • Accountability 可追责性
    👉 Example: Audit trails identify who accessed which records and when.
    👉 示例: 审计日志可记录每次数据访问的用户和时间。
  • Authenticity 真实性
    👉 Example: Two-factor authentication is required for admin login.
    👉 示例: 管理员登录必须启用双因素认证。

✅ 7. Maintainability 可维护性

Definition 定义:
The ease with which the software can be modified.
软件修改、升级或修复的难易程度。

🔹 Sub-characteristics 子特性：

  • Modularity 模块化
    👉 Example: Product and payment modules can be updated separately.
    👉 示例: 产品模块和支付模块可独立升级不互相影响。
  • Reusability 可复用性
    👉 Example: The login component is reused across multiple systems.
    👉 示例: 登录模块可在多个系统间复用。
  • Analysability 可分析性
    👉 Example: System logs clearly show root causes of failures.
    👉 示例: 日志清晰可用，便于定位故障原因。
  • Modifiability 可修改性
    👉 Example: Tax rate changes can be made without editing other modules.
    👉 示例: 修改税率不影响其他功能模块。
  • Testability 可测试性
    👉 Example: Business logic is fully covered by unit and integration tests.
    👉 示例: 所有核心业务逻辑均可自动化测试。

✅ 8. Portability 可移植性

Definition 定义:
The ease with which the system can be transferred to another environment.
系统在不同平台或环境间迁移的难易程度。

🔹 Sub-characteristics 子特性：

  • Adaptability 适应性
    👉 Example: The app runs on Windows, macOS, and Linux without code changes.
    👉 示例: 应用可在 Win/Mac/Linux 系统中无需修改直接运行。
  • Installability 可安装性
    👉 Example: The system offers a one-click Docker deployment script.
    👉 示例: 提供一键部署脚本，安装简单快速。
  • Replaceability 可替换性
    👉 Example: Stripe can be replaced with PayPal via configuration only.
    👉 示例: 支付模块可通过配置切换为 PayPal，无需改动代码。

✳️ Quality in Use 的 5 个特性（中英文对照 + 示例）

# 特性名称 英文名称 简要解释 示例
1 有效性 Effectiveness 用户能否成功、准确完成目标任务 用户是否能顺利下单并收到确认
2 效率 Efficiency 用户完成任务所花的时间、资源是否合理 用户可在 2 分钟内完成购物流程
3 满意度 Satisfaction 用户对产品的整体满意程度 用户给出好评或愿意推荐
4 风险规避性 Freedom from Risk 产品使用中不会带来经济/健康/隐私等风险 系统防止支付泄露或误操作退款
5 情境覆盖性 Context Coverage 产品在不同使用场景下都能正常发挥功能 无论用户使用手机还是桌面，系统都能稳定运行

📘 每个子特性英文定义 + 示例（背诵用）

1. Effectiveness（有效性）

  • Definition:
    Accuracy and completeness with which users achieve goals.
  • Example:
    Users can successfully complete the checkout process and receive order confirmation every time.
  • 中文示例：用户每次都能成功完成结账并收到订单确认。

2. Efficiency（效率）

  • Definition:
    Resources expended in relation to the accuracy and completeness of goal achievement.
  • Example:
    Users can finish placing an order in less than 2 minutes using no more than 5 steps.
  • 中文示例：用户下单不超过 5 步，总时长不超过 2 分钟。

3. Satisfaction（满意度）

  • Definition:
    Degree to which user needs are fulfilled and they are pleased with the product.
  • Example:
    80% of users rate the system 4 stars or higher in satisfaction surveys.
  • 中文示例：80% 用户在满意度调查中打出 4 星以上评分。

4. Freedom from Risk（风险规避性）

  • Definition:
    Avoidance of economic, health, environmental or social risks to users.
  • Example:
    The system prevents double payment and protects user data through encryption.
  • 中文示例：系统防止重复扣款，并使用加密保护用户信息。

5. Context Coverage（情境覆盖性）

  • Definition:
    Degree to which the product works well across various contexts of use (devices, users, environments).
  • Example:
    The app works consistently on desktop, tablet, and mobile, with accessible features for all user groups.
  • 中文示例：应用在桌面、平板、手机等不同设备上功能一致，且适配残障用户。

✅ SRS：Software Requirements Specification（软件需求规格说明）

📌 考试中常考写作题（比如“改写模糊的 SRS”），也有结构题、判断题
🔍 特别爱出现在与 Verification（验证）相关的题目中

📘 一、定义（中英对照）

  • 英文定义：
    An SRS is a structured document that describes what the software system should do, how it should interact with users, and any constraints on its operation or design.
  • 中文定义：
    软件需求规格说明书是一份结构化文档，用于准确描述软件应该做什么、与用户如何交互、以及任何运行或设计上的约束。

📦 二、标准结构（IEEE 830 模型，考试常考）

序号 模块 英文名 说明（中英对照）
1️⃣ 引言 Introduction 描述目的、术语、参考资料
2️⃣ 总体描述 Overall Description 用户特征、功能概览、约束、假设等
3️⃣ 具体需求 Specific Requirements 对每个功能和非功能要求的具体描述
4️⃣ 外部接口 External Interfaces 用户界面、硬件、通信协议等接口需求
5️⃣ 非功能需求 Non-functional Requirements 性能、安全、可靠性、可维护性等
6️⃣ 其他附录 Appendices 图表、词汇表、支持材料等

✅ 三、常考内容分类：

🔹 1. Functional Requirements（功能性需求）

  • 描述软件必须执行的具体功能
  • 常用句式：The system shall allow…

✅ 示例：The system shall allow users to search products by name and category.
✅ 中文：系统应允许用户按名称和类别搜索商品。

🔹 2. Non-Functional Requirements（非功能性需求）

  • 关注性能、可靠性、安全、可用性等“质量属性”
  • 常常要你识别“模糊”的非功能需求并重写成具体、可测量语句

✅ 示例改写题：

❌ 原句：The system should be fast.
✅ 改写：The system shall respond to user actions within 2 seconds for 95% of requests.

🔹 3. Ambiguous → Clear 重写（考试热点）

题目经常给你一句模糊的 SRS，让你指出问题并改写：

题目：

SRS-01: The system shall allow each customer to access only their own personal data quickly and not any other data related to any other customer.

改写思路：

  • 明确“quickly”：给出时间指标
  • 拆分多个需求（可访问 + 不能访问他人数据）
  • 明确“personal data”是什么字段？

✅ 改写示例：

  1. Each user shall be able to retrieve their own account data (including name, email, and order history) within 3 seconds.
  2. The system shall prevent users from accessing the data of any other users.

🧠 四、关键词与写作句式总结

英文句式 中文含义 用于哪种需求
The system shall… 系统应… 所有 SRS 推荐写法
shall support… 应支持… 功能性
shall respond within… 应在…内响应 性能
shall be accessible to… 应对…可访问 可用性
shall restrict access to… 应限制访问… 安全性

🧪 五、常考练习题（可试做）

  1. Identify any ambiguity in this requirement:
    “The system should support large-scale traffic.”
    → ❓ 哪些词模糊？你能重写吗？
  2. List three non-functional requirements categories in SRS.
    → ✅ 性能效率、兼容性、可维护性

✅ Software Testing Types & Levels（软件测试类型与级别）

  • 判断题：某测试属于哪个阶段
  • 选择题：哪个是黑盒测试？哪个是系统测试？
  • 简答题：对比测试类型、说明各层级目的
  • 实战题：某代码/流程该用什么测试？

📘 一、四个常见测试层级（Test Levels）

层级 英文名称 中文名称 目标 举例
1️⃣ Unit Testing 单元测试 测试最小功能单元，如类、函数 testAddProduct()
2️⃣ Integration Testing 集成测试 测试模块之间的接口与交互 用户登录后跳转购物车模块
3️⃣ System Testing 系统测试 整体测试系统功能是否满足需求 测试整个平台从注册到支付是否顺畅
4️⃣ Acceptance Testing 验收测试 最终用户是否接受系统 用户代表测试是否能完成下单并收到确认

🧪 二、黑盒 vs 白盒 测试类型（Test Types）

类型 定义 是否依赖代码结构 举例
Black-box 不看代码，仅测试输入输出 ❌ 不依赖 UI 测试、功能测试
White-box 依据代码结构设计测试用例 ✅ 依赖结构 单元测试、语句覆盖
Grey-box 结合部分代码结构信息与行为测试 ⚠️ 部分依赖 集成接口测试

🧩 三、测试类型汇总（常考分类题）

分类 类型 中文名 示例
功能性测试 Functional Testing 功能测试 登录、购物车是否正常
非功能测试 Performance Testing 性能测试 并发下单是否卡顿
非功能测试 Security Testing 安全测试 XSS、SQL 注入检测
非功能测试 Usability Testing 可用性测试 用户是否易于操作
特殊测试 Regression Testing 回归测试 修改代码后检查旧功能是否崩了
特殊测试 Smoke Testing 冒烟测试 发布前快速检查关键流程能否跑通
特殊测试 Stress Testing 压力测试 系统能撑多少并发？
特殊测试 Load Testing 负载测试 模拟 1000 用户下单场景

✅ V&V：Verification and Validation（验证与确认）

  • 区分 Verification 和 Validation 的本质
  • 各自常用的方法和测试活动
  • 它们分别在软件生命周期中的位置

📘 一、核心定义（中英对照，必背）

概念 英文定义 中文定义
Verification Are we building the product right? 我们做的东西“对”吗？（符合规格说明）
Validation Are we building the right product? 我们做的是“对的东西”吗？（满足用户需求）

🔍 快速理解方法：

✅ Verification = 规范为王：我们按照规格说明（SRS、设计文档）来检查产品。
✅ Validation = 用户为王：我们关心用户是否满意、是否用得上。

🧪 二、对比表（考试答题万能模板）

对比项 Verification（验证） Validation（确认）
问题 我们是否按照规格做？ 我们做的是用户想要的吗？
依据 软件规格说明（SRS、设计文档） 用户需求、业务目标
发生阶段 开发过程的每一阶段 开发后期、交付前
常用活动 走查、审查、静态分析 用户测试、验收测试、Beta 测试
是否运行程序 ❌ 通常不运行（静态） ✅ 必须运行（动态）
参与者 开发人员、QA、审查组 用户、客户、验收团队
示例 代码审查、设计审查、模型对比 用户能否成功下单并满意使用

🧠 口诀助记法：

验证：对照规格查质量；确认：用户满意最重要。

📦 三、举例理解（考试常见改写题）

✅ Verification 例子：

  • 静态检查代码是否符合模块接口规范 → 不跑程序 ✔
  • 审查设计文档是否符合系统结构要求
  • 检查是否实现了所有 SRS 中列出的功能点

✅ Validation 例子：

  • 用户点击结账后是否真的能下单成功
  • 用户能否在手机上顺利浏览商品
  • 系统是否“真的解决了他们的业务问题”

📘 四、V&V 在生命周期中所处阶段

生命周期阶段 验证（Verification） 确认（Validation）
需求分析 审查需求文档是否规范 用户是否认同需求
设计 审查是否符合架构标准 原型演示是否满足用户预期
编码 单元测试是否覆盖函数逻辑 用户测试是否满意最终结果
测试 代码是否符合测试用例设计 用户是否能实际操作通过流程

总结一句话：

Verification 是“做对事情”，Validation 是“做正确的事情”。两者缺一不可。

✅ QP, QA, QC：软件质量的三个核心概念

这是课程中非常基础又常考的概念组合，常用于选择题、简答题，尤其是要你：

  • 区分 QP、QA、QC 的概念
  • 给出实例
  • 说明它们在软件开发中的位置和作用

📘 一、核心定义（中英对照）

缩写 全称 中文含义 定义（简洁背诵）
QP Quality Planning 质量规划 确定质量目标和标准，并制定实现这些目标的过程和计划
QA Quality Assurance 质量保证 建立流程并确保按流程开发，防止缺陷发生
QC Quality Control 质量控制 通过测试与检查发现并修复已经存在的缺陷

🧠 二、万能对比口诀：

✅ QP：计划做什么 →
✅ QA：确保正确做 →
✅ QC：检查有没有错

🧪 三、详细对比（考试答题模板）

项目 QP（质量规划） QA（质量保证） QC（质量控制）
目标 明确要达到什么样的质量 建立流程避免错误 发现并纠正错误
时间 项目前期 项目执行全过程 项目执行中 & 后期
方法 编写质量计划、设定目标 审查、标准化流程、培训 测试、评审、缺陷报告
是否检测缺陷 ❌ 不直接检测 ❌ 不直接检测 ✅ 直接检测并修复缺陷
示例 确定要支持哪些平台、多少用户 建立代码审查流程、SQA 小组 执行单元测试、系统测试

📘 四、每个的英文举例 + 中文解释（用于写作题）

✅ QP 示例：

The project manager sets a quality goal: system must support 10,000 users with 99.9% uptime.
➜ 项目经理制定质量目标：“系统需支持 1 万用户，月可用性达 99.9%。”

✅ QA 示例：

The team enforces coding standards and conducts regular peer reviews.
➜ 团队实施代码规范和定期代码走查，确保按流程开发。

✅ QC 示例：

Testers run regression tests and report 17 critical bugs before release.
➜ 测试人员回归测试发现 17 个严重缺陷并提交修复。

🎯 总结对照表（背诵必备）

缩写 中文名 动词关键词 是否防缺陷 是否查缺陷
QP 质量规划 计划 ✅ 是 ❌ 否
QA 质量保证 预防 ✅ 是 ❌ 否
QC 质量控制 检测 + 修正 ❌ 否 ✅ 是

📌 衍生考试题目有：

  • Which phase ensures prevention of defects? → ✅ QA
  • Which activity happens after development to find defects? → ✅ QC
  • Which phase defines the criteria and methods to achieve quality? → ✅ QP

✅ Software Test Plan（软件测试计划）

📘 一、定义（中英对照）

  • 英文：A Software Test Plan is a detailed document that outlines the test strategy, objectives, schedule, resources, scope, and activities required to verify the quality of a software product.
  • 中文：测试计划是一份详细说明测试目标、策略、范围、资源、进度和活动的文档，用于确保软件产品符合质量要求。

📦 二、标准结构（IEEE 829 & 实际模板混合）

以下是测试计划的常见部分（考试必背结构）：

序号 模块名称 英文名称 说明（中英对照）
1️⃣ 测试计划标识 Test Plan Identifier 文档编号或版本信息
2️⃣ 引言 Introduction 说明测试目标、背景、约束
3️⃣ 被测项目 Test Items 说明测试的系统或模块
4️⃣ 特性要测试 Features to be Tested 将被验证的功能清单
5️⃣ 特性不测试 Features Not to be Tested 明确本次不测的部分（范围外）
6️⃣ 测试策略 Test Strategy / Approach 描述采用的测试类型和方法（黑盒/白盒/自动化等）
7️⃣ 通过标准 Pass/Fail Criteria 测试是否通过的判断标准（如：100% 通过关键路径）
8️⃣ 退出准则 Exit Criteria 测试完成的条件，例如缺陷关闭率 ≥ 95%
9️⃣ 测试任务 Test Deliverables 要提交的测试成果，如测试用例、报告、缺陷日志
🔟 时间安排 Schedule 每个阶段的开始与结束时间
1️⃣1️⃣ 人员与角色 Roles and Responsibilities 每个测试相关人员的职责
1️⃣2️⃣ 风险分析 Risks and Contingencies 可能的问题及应对方案（如测试人员不足、延迟等）

✅ 三、考试常考示例题型：

Q1: List 5 components of a good test plan.

→ 答：Test Items, Features to be Tested, Test Strategy, Pass Criteria, Schedule

Q2: What is the difference between Exit Criteria and Pass Criteria?

→ Pass Criteria 是针对单个测试用例是否成功，
→ Exit Criteria 是针对整个测试流程是否可以结束。

Q3: Why is “Features Not to be Tested” important?

→ 避免误解和扩大测试范围，让团队知道哪些模块不在本次测试目标内。

✅ Static vs Dynamic Analysis（静态分析 vs 动态分析）

📘 一、核心定义（中英文对照）

类型 英文定义 中文定义
Static Analysis Analysis of the software without executing it. 不运行程序，通过检查代码、文档、模型来发现缺陷的过程。
Dynamic Analysis Analysis of the software by executing it. 运行程序时观察其行为、性能、输出的过程。

🧪 二、对比表（考试背诵模板）

比较项 Static Analysis（静态分析） Dynamic Analysis（动态分析）
是否执行程序 ❌ 不执行代码 ✅ 需要执行代码
发生阶段 编码前/编译前 编译后或部署后
检查目标 代码结构、语法、逻辑、标准 程序运行行为、性能、输出
方法示例 代码审查、Lint 工具、模型分析、型检查 单元测试、系统测试、性能测试
工具示例 ESLint, SonarQube, FindBugs JUnit, Selenium, JMeter
发现缺陷类型 潜在 bug、死代码、不规范命名、未使用变量 内存泄漏、崩溃、性能瓶颈、边界错误
是否自动化 ✅ 高度自动化 ✅ 多数也可自动化
优势 早发现问题，节省测试成本 真实模拟运行情况，更接近用户体验
局限 无法检测运行时错误 无法在早期发现逻辑错误或结构问题

🎯 三、例题训练（判断题 / 选择题常考）

❓ Which of the following is a static analysis activity?
✅ A: Code walkthrough
❌ B: Load testing
❌ C: Acceptance testing
✅ D: Linting source code

🧠 记忆口诀

“静态不跑代码，动态观察行为”
Static 看“形”，Dynamic 看“跑”

🧪 四、各自的典型工具（补充记忆）

类型 工具举例 说明
🧊 静态分析 SonarQube, ESLint, StyleCop, Checkstyle 检查语法、规范、未使用变量
🔥 动态分析 JUnit, PyTest, Selenium, JMeter, Valgrind 执行测试、检查内存、测试性能

📌 你还可以用这个思路套用答题句式：

Static analysis is important because it helps detect issues early in development without running the software. In contrast, dynamic analysis reveals issues that only occur during runtime, such as memory leaks or crashes.