《构建之法》笔记整理

发表于 分类于 本文字数： 8.4k 阅读时长 ≈ 31 分钟

这个学期上了 “实用需求工程”，不过说实话个人感觉真的很痛苦。课上只讲点理论知识，课程设计方面也仅仅让学生分小组写书面报告了事（让我们找市场上的一款软件，然后全靠想象写点需求，画几张 UML 即了事），完全没有涉及到一丁点实践，一行代码都不需要写。这种授课真的是痛苦又无聊，为了逃避痛苦，就买了本邹欣老师的《构建之法》上课时看。整本书的内容非常充实，需求工程的内容也在其中，但不仅限于此。个人觉得软件工程专业的学生都有必要阅读这本书，尤其是 “做中学” 的思想很值得学习，虽然自己在学习软件工程的过程中离 “做中学” 还差很多，尤其是代码写的还不够。以下是自己整理这本书的一些概括。

概论

  • 软件 ＝ 程序 + 软件工程
  • 软件企业 = 软件 + 商业模式

程序（算法、数据结构）是基本功，但软件工程决定了软件的质量，商业模式影响了一个软件企业的成败。

软件开发的五点难题

  • 复杂性
  • 不可见性
  • 易变性
  • 服从性
  • 非连续性

软件工程的知识领域和理论基础

  • 生命周期：软件需求、软件设计、软件构建、软件测试、软件维护
  • 专门领域：软件配置管理、软件工程管理、软件工程过程、软件工程模型和方法、软件质量
  • 理论基础：计算基础、数学基础、工程基础

Cocomi 模型

Person * Month = 2.4 * KLoC1.05 ，KLoC 表示一千行代码。例：如果估计的代码量是 10 万行（KLoC = 100），那么时间花费就是 2.4 * 1001.5 = 302 人月。

个人技术和流程

单元测试

  1. 单元测试应该在最基本的功能 / 参数上验证程序的正确性。
  2. 单元测试必须由最熟悉代码的人（程序的作者）来写。
  3. 单元测试过后，机器状态保持不变。
  4. 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
  5. 单元测试应该产生可重复、一致的结果。
  6. 独立性：单元测试的运行 / 通过 / 失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
  7. 单元测试应该覆盖所有代码路径。
  8. 单元测试应该集成到自动测试的框架中。
  9. 单元测试必须和产品代码一起保存和维护。

回归测试（Regression Test）

在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个 “退步”（Regression），从正常工作的状态退化到不正常工作的状态。

在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准线（Baseline），一个模块的所有单元测试就是这个模块最初的 Baseline 。

当出现一个 “退步”（Regression）时，工程师们应该在新版本上运行所有已通过的测试用例，以验证有没有 “退化” 情况发生，这个过程就是一个 “Regression Test”。

针对 Bug 修复，也需要进行回归测试，目的是：

  • 验证新的代码的确改正了缺陷
  • 同时要验证新的代码有没有破坏模块的现有功能，有没有 Regression

两个软件设计原则

单一职责原则（Single Responsibility Principle, SRP）

一个模块（类）应该只有一个导致它变化的原因，一个模块应该完全对某个功能负责。

封闭原则（Open-Close Principle, OCP）

软件实体应该是可以扩展的，同时是不可修改的。

  • 允许扩展（Open for extension）：当应用的需求发生改变时，我们可以对模块进行扩展，从而改变模块的功能。
  • 不允许修改（Closed for modification）：对模块行为进行扩展时，不必改变模块的本身。

软件工程师的成长

思维误区

  1. 分析麻痹（Analysis Paralysis）：想弄清楚所有细节、所有依赖关系后再动手，心理上过于悲观，不想修复问题，出了问题都赖在相关问题上。
  2. 不分主次，想解决所有依赖问题：过于积极，想马上动手修复所有主要和次要的依赖问题，然后就可以 “完美地” 达成最初设定的目标，而不是根据现有条件找到一个 “足够好” 的方案。
  3. 过早优化：一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量的时间对其进行优化，无视这个模块对全局的重要性，甚至还不知道这个 “全局” 是怎么样的 —— “过早的优化是一切罪恶的根源”。
  4. 过早扩大化 / 泛化（Permature Generalization）

两人合作

结对编程

优点

  1. 在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有互相激励的作用，工程师看到别人的思路和技能，得到实施的讲解，受到激励，从而努力提高自己的水平，提出更多创意。
  2. 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
  3. 在企业管理层次上，结对能更有效地交流，互相学习和传递经验，分享知识，能更好地应对人员流动。

团队和流程

软件团队的模式

  1. 一窝蜂模式（Chaos Team）
  2. 主治医师模式（Chief programmer Team，Surgical Team）
  3. 明星模式（Super-star Model）
  4. 社区模式（Community Model）
  5. 业余剧团模式（Amateur Theater Team）
  6. 秘密团队（Skunk Work Team）
  7. 特工团队（SWAT）
  8. 交响乐模式（Orchestra）
  9. 爵士乐模式（Jazz Band）
  10. 功能团队模式（Feature Team）
  11. 官僚模式（Bureaucratic Model）

开发流程

写了再改模式（Code-and-Fix）

  • “只用一次” 的程序
  • “看过了就扔” 的原型
  • 一些不实用的演示程序

瀑布模型（WaterFall Model）

温斯顿 · 罗伊斯（Winston Royce）在 1970 年的论文 “Managing the Development of Large Software System” 中第一次明确地描述了这个模型（虽然他没有用 Waterfall 这个词）。

Waterfall-Model

注意点
  • 在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题
  • 要让产品成功，最好把这个模型走两遍，先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本
  • 要让顾客正式地，深入地，持续地参与到项目中来
  • 文档的重要性
局限性
  • 各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来
  • 回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯
  • 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早直到产品的原型并试用
适用范围
  • 如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证
  • 产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证
  • 使用的技术非常成熟、团队成员都很熟悉这些技术
  • 负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流
变形
  • 生鱼片模型：解决了各个步骤之间分离的缺点，同时也带来了一些困扰——究竟什么时候上一阶段会结束呢？
  • 大瀑布带小瀑布

统一模型（Rational Unified Process，RUP）

重计划，重事先设计，重文档表达

规程（Discipline）/ 工作流（Workflow）
  • 业务建模：为了理解目前用户的业务流程，业务建模（Business Modeling）工作流用精确的语言（通常是 UML）把用户的活动描述出来。有时也翻译为 “商业建模”。这个工作流的结果通常是用例（Use Case）。
  • 需求：有了用例之后，开发人员和用户要分析并确认软件系统得提供什么样的功能来满足用户的需求，功能有什么约束条件，如何验证功能满足了用户需求
  • 分析和设计：分析和设计（Analysis & Design）工作流将需求转化成系统的设计
  • 实现：在实现（Implement）工作流中，工程师按照计划实现上一步产出的设计，将开发出的组件（Module），连同验证模块提交到系统中
  • 测试：验证现阶段交付的所有组件的正确性、组件之间交互的正确性、以及检验所有的需求已被正确地实现
  • 部署：部署（Deployment）目的是生成最终版本并将软件分发给最终用户
  • 配置和变更管理：配置和变更管理工作流（Configuration and Change Management）负责管理 RUP 各个阶段产生的各种工作结果
  • 项目管理：软件项目管理工作流（Project Management）负责平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功地在各个阶段交付达到要求的产品
  • 环境：环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。
RUP 四个阶段

RUP 把软件开发分成几个阶段，一个大阶段的结束称为一个里程碑（Milestone）。

  • 初始阶段：此阶段的目标是分析系统软件大概的构成，系统与外部系统的边界在哪里（我们的系统究竟和什么别的外部实体打交道），大致的成本和预算是多少，系统的风险主要来自哪里。成功度过初始阶段的项目会达到生命周期目标（Lifecycle Objective）里程碑。
  • 细化阶段：它的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可拓展性等非功能需求。同时为项目建立支持环境，包括创建开发案例、创建模板并准备工具。细化阶段时，项目到达了第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。
  • 构造阶段：在这一阶段，团队开发出所有的功能集，并有秩序地把功能集成为经历过各种测试验证过的产品。构造阶段结束时时第三个重要的里程碑：初始功能（Initial Operational）里程碑。此时的产品版本也常被称为 “Beta” 版。
  • 交付阶段：这时候，团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代，基于用户的反馈，团队利用这些迭代对系统进行修改、调整。除了对功能的调整，团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的重点是第四个里程碑：产品发布（Product Release）里程碑。

老板驱动的流程（Boss-Driven Process）

开发流程由行政领导主导，或者由公司的老板驱动。

渐进交付的流程（Evolutionary Delivery），MVP 和 MBP

当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的循环中：开发 -> 发布 -> 听取反馈 -> 根据反馈做改进。当满足 “时间到了” 或 “钱花光了” 或 “用户满意了（或者很不满意，不再给钱了）” 即算完成。

MVP： Minimum Viable Product，最小可行产品，又称为 Minimum Feature Set，最小功能集

具体做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。

MVP 的指导思想和渐进交付相似，但是它更强调更早获得用户反馈，为此可以在产品完成之前就发布，它也强调产品的核心价值（产品最区别竞争产品的地方），为了突出核心功能，别的辅助功能可以不考虑或用别的平台提供的服务来代替。

Maximal Beautiful Product（最强最美产品，MBP）

如果对用户的需求了然于心，或者产品团队比用户更了解用户的需求，即可把产品最全、最美的形态展现出来。

Team Software Process（TSP）原则

  1. 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
  2. 团队的各个成员对团队的目标、角色、产品都有统一的理解。
  3. 尽量使用成熟的技术和做法。
  4. 尽量多地手机数据（也包括对团队不利的数据），并用数据来帮助团队做出理性的决定。
  5. 制定切合实际的计划和承诺，团队计划要由负责具体执行的角色来制定（而不是从上级而来）。
  6. 增加团队的自我管理能力。
  7. 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。

敏捷流程

scrum-process

原则

  1. 尽早并持续地交付有脚趾的软件以满足顾客需求
  2. 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
  3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
  4. 业务人员和开发人员在项目开发过程中应该每天共同工作
  5. 以有进取心的认为项目核心，充分支持信任它们
  6. 无论团队内外，面对面的交流始终是最有效的沟通方式
  7. 可用的软件是衡量项目进展的主要目标
  8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
  9. 只有不断关注技术和设计，才能越来越敏捷
  10. 保持简明 —— 尽可能简化工作量的技艺 —— 极为重要
  11. 只有能自我管理的团队才能创造优秀的架构、需求和设计
  12. 时时总结如何提高团队效率，并付诸行动

步骤

第一步：找出完成产品需要做的事情 —— Product Backlog

Backlog 翻译成 “积压的工作”、“待解决的问题”、“产品订单” 都可以。

第二步：决定当前的冲刺（Sprint）需要解决的事情 —— Sprint Backlog

如果团队成员能主导任务的估计和分配，他们的能动性得到较大的发挥。

第三步：冲刺

在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师（Scrum Master）来完成。这一措施较好地平衡了 “交流” 和 “集中注意力” 的矛盾。

冲刺期间，团队通过每日例会（Scrum Meeting）来进行面对面的交流，团队成员大多数站着开会，所以又称每日立会。

Scrum Master 根据项目的情况，用燃尽图（Burn Down Chart）/ 看板图（Kanban）展现整个项目的进度。

冲刺阶段是时间驱动的（TIme-boxed），时间一到就结束。

第四步

得到一个软件的增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

敏捷的团队

敏捷对团队的要求很简单：自主管理（Self-Managing）、自我组织（Self-organizing）、多功能型（Cross-functional）。

经验教训

  1. 敏捷宣言表明的是一些优先级，不必当做圣旨或者教条来争论。
  2. Scrum Master 不是一个官，而是一个没有行政权力的沟通者。他 / 她同时还要在团队中做具体的工作。直接把原来的 “经理” 变成 Scrum Master，大多行不通。
  3. 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum 会把这些矛盾都摆到明处。这有好处，也有风险。
  4. 在复杂的项目里，要让一线团队成员做决定。
  5. 创业公司的团队其实经常是运行在某种快节奏的敏捷的模式中。
  6. 在 Scrum 计划阶段的估计不是一个 “合同”，领导们不要把它当成一个合同。估计总是不准的，坚持短期的 Sprint，这样即使不准的估计也不会有大的损害。
  7. 不要和管理层谈 “流程”，他们只关心 “结果”。
  8. 在大型团队，跨地区的团队，或者复杂项目中，Scrum 并没有非常完美的答案。

使用范围

敏捷（Agile） 计划驱动（Plan-driven） 形式化的开发方法（Formal Method）
产品可靠性要求 不高，容忍经常出错 必须有较高可靠性 有极高的可靠性和质量要求
需求变化 经常变化 不经常变化 固定的需求，需求可以建模
团队人员数量 不多 较多 不多
人员经验 有资深程序员带队 以中层技术人员为主 资深专家
公司文化 鼓励变化，行业充满变数 崇尚秩序，按时交付 精益求精
实际的例子 写一个微博网站 开发下一版本的办公软件；给商业用户开发软件 开发底层正则表达式解析模块；科学计算；复杂系统的核心组件
用错方式的后果 用敏捷的方法开发登月火箭控制程序，前 N 批宇航员都挂了 用敏捷方法，商业用户未必受得了两周一次更新的频率 敏捷方法的大部分招数都和这类用户无关，用户关心的是：把可靠性提高到99.999%，不要让微小的错误把系统搞崩溃

需求分析

如何准确且全面的找到需求

获取和引导需求（Elicitation）

软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出真是的需求。不同的项目需要不同的手段，这一步骤也被叫做 “需求捕捉”，形容真正的需求稍纵即逝。

很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。

需求不仅来自外界，还可以来自软件企业本身。企业所采用的商业模式会对软件提出需求。

需求还可以来自于技术团队本身，团队在考虑软件的代码、架构、所依赖平台的长期演化的时候，会提出技术性的需求，包括代码的迁移、架构的演化、平台的变化，或者引入新的技术、编程语言等。

分析和定义需求（Analysis & Specification）

对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化。

验证需求（Validation）

软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。

在软件产品的生命周期中管理需求（Management）

在软件的生命周期中，需求在发生变化，技术在发展，团队成员能力也在提高，需要不断对需求进行重新审核并做出相应的调整。

需求划分

  1. 对产品功能性的需求：要求产品必须实现某些功能。
  2. 对产品开发过程的需求：要求软件的开发流程必须满足某些约束条件。
  3. 非功能性需求：这也叫 “服务质量需求”（Quality of Service Requirement）。
  4. 综合需求：有些需求并不是单单一个软件模块就能满足。

软件产品的利益相关者

  1. 用户：或称最终用户（User，End-user），是直接使用软件系统的人。
  2. 顾客：或称客户（Customer，Client），购买这个软件或者根据合同或规定接受软件的人。这些人不一定是软件的直接用户，但是他们的利益和软件直接相关。
  3. 市场分析者：代表 “典型用户“ 的需求，他们或者是市场部门的成员，或者是独立的市场分析人士。
  4. 监管机构：在一些行业，软件必须符合许多行业和政策规定。
  5. 系统 / 应用集成商：在复杂软件的开发和应用过程中，系统 / 应用集成商负责给客户提供咨询、服务、集成等工作。
  6. 软件团队：具体完成某一特定软件或特定功能的团队。
  7. 软件工程师：软件的各种约束、特性会影响到他们工作的效率、开发难度和软件维护的难度。

用户调研

焦点小组（Focus Group）

找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等。这种形式也叫做推进会议（Facilitated Meeting）。

深入面谈（In-depth Interview）

通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等。这种方法费时费力，效果往往取决于主持面谈的团队成员的能力。这也可以称为软件可用性研究（Usability Study）。

卡片分类（Card Sorting）

通常，团队收集到的需求都是杂乱无章的，在收集这类反馈时可以利用 “卡片分类” 的办法，把各种需求做成便于规整的小卡片，然后反复进行下列活动：讨论 -> 明晰定义 -> 归类 -> 排序。

用户调查问卷（User Survey）

这种方法是向用户提供事先设计好的问题，让用户回答。

常见错误
  1. 问题定义不准确。
  2. 使用含糊不清的形容词、副词描述时间、数量、频率、价格等。
  3. 让用户花额外的努力来回答问题。
  4. 问题带有引导性的频率。
  5. 问题涉及用户隐私、用户所在公司的商业机密或细节等。
方式
  1. 全开放式问题
  2. 二项选择题
  3. 多项选择题
  4. 顺位选择题

用户日志研究（user Diary Study）

这一调研方式要求用户记录自己日常工作或生活中与所用软件相关的行为，供软件团队分析。

人类学调查（Ethnographic Study）

可以解释为和目标用户 “同吃同住同劳动”。

NABCD 模型（电梯演说）

我们的产品 <名称> 是为了解决 <目标用户> 的痛苦，他们需要 <Need> 但是现有的产品并没有很好地解决这些需求。我们有独特的办法 <Approach>，它能给用户带来好处 <Benefit>，远远超过竞争对手 <Competitor>。同时，我们有高效率的 <Delivery> 方法，能很快的让目标用户知道我们的产品，并进一步传播。

功能的定位和优先级

四个象限

  • 维持：以最低成本维持此功能
  • 抵消：快速到达 “足够好”、“和竞争对手差不多”
  • 优化：花大力气做到并保持行业最好
  • 差异化：产生同类产品比不了的功能或优势
  • 不做：砍掉一个功能也是一个办法，不一定要做所有的功能

kano模型

分而治之（Work Breakdown Structure）

WBS 通常从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。这样的分割可以持续下去，直到 WBS 的使用者（开发团队、接收方）达到共识。

从数据结构方面来看，WBS 分割的结果是一棵树，所有子节点都最终有一个根节点。每个节点描述的是要交付的产品或文档。

项目经理

PM 的 M 就是 Manager，但是 P 有这几种：Product Manager、Project Manager、Program Manager。

PM 做开发和测试之外的所有事情

  1. 和客户交谈，组织用户调查，发现用户需求
  2. 了解和比较竞争对手的产品
  3. 怎么让软件变得可用（Usable）、有用（Useful）
  4. 怎么改进团队的流程

能力

  1. 观察、理解和快速学习能力
  2. 分析管理能力
  3. 一定的专业能力

项目中的具体任务

  1. 带领团队形成团队的目标 / 远景，把抽象的目标转化为可执行的、具体的、优美的设计
  2. 管理软件的具体功能的生命周期（需求 / 设想 / 设计 / 实现 / 测试 / 修改 / 发布 / 升级 / 迁移 / 淘汰）
  3. 创建并维护软件的规格说明书，让它成为开发 / 测试人员及时准确的指导，而不是障碍
  4. 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级
  5. 分析并带领其他成员对缺陷 / 变更需求形成一致意见，并确保实施
  6. 带领其他成员确保项目保持功能 / 时间 / 资源的合理平衡，跟踪项目进展，确保团队发布令人满意的软件
  7. 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气

典型用户和场景

用例（Use Case）

用例是很常用的需求分析工具。

基本元素

  • 标题：描述这个用例要达到的目标
  • 角色（Actor）：和软件系统交互的角色。例如用户，其他实体，甚至时间
  • 主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的。
    • 步骤（Step）：描述每一步的交互
  • 扩展场景（Extension）：描述一些扩展的交互

使用用例的原则

  1. 通过讲简单的故事来传递信息
  2. 保持对全系统的理解
  3. 关注用户的价值
  4. 逐步构建整个系统，一次完成一个用例
  5. 增量开发，逐步构建整个系统
  6. 适应团队不断变化的需求

规格说明书

规格说明书（Specification）简称 Spec，分为两种：

  • 软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当做一个黑盒子）
  • 软件技术说明书（technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当做一个透明的箱子）

功能说明书

功能说明书从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等，不涉及软件的内部实现细节。

  1. 定义好相关的概念
  2. 规范好一些假设（Assumption）
  3. 避免一些误解，界定一些边界条件
  4. 描述主流的用户 / 软件交互步骤
  5. 一些好的功能还会有副作用
  6. 服务质量的说明

技术说明书

技术说明书又叫设计文档，它用于描述开发者如何去实现某一些功能，或相互联系的一组功能。设计文档应该说明工程师的设计师如何体现下列原则的。

  • 抽象（Abstraction）
  • 内聚 / 耦合 / 模块化（Cohesion，Coupling，Modularization）
  • 信息隐藏和封装（Information Hiding，Encapsulation）
  • 界面和实现的分离（Separation of Interface and Implementation）
  • 如何处理错误情况（Error Handling）
  • 程序模块对于运行环境、相关模块、输入输出参数有什么假设？这些假设和相关的人员验证过么？
  • 应对变化的灵活性（Adapt to Change）
  • 对大量数据的处理能力（Scalability）

功能驱动的设计（Feature Driven Design，FDD）

  1. 构造总体模型（Develop an Overall Model）
  2. 构造功能列表（Build a Feature List）
  3. 制定开发计划（Plan by Feature）
  4. 功能设计阶段（Design by Feature）
  5. 实现具体功能（Build by Feature）

FDD 适用于团队成员对于需求没有切身体会的情景，FDD 对单元测试之外的测试（如集成测试、压力测试、对用户界面和用户体验的测试）的讲述不足。

软件测试

  • Bug：软件的缺陷
  • Test Case：测试用例，测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结构等
  • Test Suite：测试用例集

按测试方法分类

测试设计有两类方法：黑箱（Black Box）和白箱（White Box）。

  • 黑箱：指的是在设计测试的过程中，把软件系统当作一个 “黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计（Behavioral Test Design），即从软件的行为，而不是从内部结构出发来设计测试。
  • 白箱：指的是在设计测试的过程中，设计者可以 “看到” 软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。

按测试的目的分类

功能测试

测试名称 测试内容
Unit Test 单元测试 —— 在最基本的功能 / 参数上验证程序的正确性
Functional Test 功能测试 —— 验证模块的功能
Integration Test 集成测试 —— 验证几个互相有依赖关系的模块的功能
Scenario Test 场景测试 —— 验证几个模块能否完成一个用户场景
System Test 系统测试 —— 对于整个系统功能的测试
Alpha / Beta Test 外部软件测试人员（Alpha / Beta 测试员）在实际用户环境中对软件进行全面的测试

非功能测试

一个软件除了基本功能之外，还有很多功能之外的特性，这些叫非功能需求（Non-functional Requirement），或者服务质量需求（Quality of Service Requirement）。

测试名称 测试内容
Stress / Load Test 压力测试 —— 测试软件在负载情况下是否正常工作
Performance Test 效能测试 —— 测试软件的效能
Accessibility Test 可访问性测试 —— 测试软件是否向残疾用户提供了足够的辅助功能
Localization / Globalization Test 本地化 / 全球化测试
Compatibility Test 兼任性测试
Configuration Test 配置测试 —— 测试软件在各种配置下能否正常工作
Usability Test 易用性测试 —— 测试软件是否好用
Security Test 软件安全性测试

按测试的时机和作用分类

测试名称 测试内容
Smoke Test 冒烟测试 —— 测试不通过，则不能进行下一步工作
Build Verification Test 验证构建是否通过基本测试
Acceptance Test 验收测试 —— 全面考核某方面的功能 / 特性
Regression Test “回归” 测试 —— 对一个新的版本，重新运行以往的测试用例，确认新版本相比已知版本有无 “退化”（Regression）
Ad hoc (Exploratory) Test 随机进行的、探索性的测试
Bug Bash Bug 大扫荡 —— 全体成员参加的找 “小强” 活动
Buddy Test 伙伴测试 —— 开发人员（伙伴）作为测试人员测试特定模块

质量保障

Capability of software product to statisfy stated and implied needs under specified conditions.

The degree to which a software product meets established requirements; however, quality depends upon the degree to which those established requirements accurately represent stakeholder needs, and expectations.

即软件要符合用户以及利益相关者的需求。

软件工程的质量

  • 软件开发过程的可见性（Visibility）
  • 软件开发过程的风险控制（Risk Management）
  • 软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
  • 软件开发成本的控制（Cost Control）
  • 内部质量指标的完成情况（Internal Benchmarks）

其他

  1. CMMI（Capacity Maturity Model Integrated，能力成熟度模型集成）
  2. 戴明环（Plan - Do - Check - Act / Adjust）

稳定和发布阶段

常见名词

  • Alpha：指集成了主要功能的第一个试用版本。
  • Beta：功能基本完备，稳定性较 Alpha 版本高。
  • ZBB（Zero Bug Build）：某天的版本要把在之前（例如 48 小时前）记录的 Bug 都解决掉。
  • RC（Release Candidate）：发布候选版本，直到 RTM 为止，版本间隔时间较短。
  • RTM（Release To Manufacturer）：最终发布版本。
  • RTW（Release To Web）