软件测试概念篇：需求、测试用例、缺陷与测试生命周期

正式开始讲软件测试之前，先泼一盆清醒的冷水：很多人以为测试就是"点点点"——照着软件随便点几下，看它崩不崩。这句话对了一半，错的那一半恰恰是最重要的。测试不是"乱点"，测试是"有目的地、可重复地、对照标准去验证"。如果你只是乱点，那叫"体验"，不叫"测试"；而我们要做的，是把这份"乱点"升级成一套科学、严谨、成体系的工作方法。

这篇文章是软件测试系列的概念篇。我们不急着教你怎么写脚本、怎么用工具，而是先把地基打好：需求到底是个什么东西，软件从无到有要经历怎样的生命周期，瀑布、敏捷这些开发模型各自长什么样，V 模型和 W 模型解决了什么问题，测试用例的要素是什么，缺陷（bug）到底怎么定义、怎么分级、怎么走完一生，以及测试和开发是怎么协作的。这些概念看起来零碎，但它们是理解后面所有测试技术的砖。这一砖不牢，后面盖多少层楼都要返工。

你应该有的知识准备

在往下读之前，建议你先带着下面几个基本印象进来。它们现在模糊一点没关系，后面全都会展开：

• "需求"不是一句"我想要个登录"：用户嘴上说的，和能落成文档、能指导开发和测试的，是两回事。这一篇我们要把它们掰开。
• 软件不是一蹴而就的：从想法到上线，中间要经过需求、计划、设计、编码、测试、维护一大堆阶段，这就是"生命周期"。
• 测试不是编码之后突然冒出来的：好的测试，在需求还在酝酿的时候就该到场了。这是 V 模型和 W 模型想告诉你的核心。
• 测试要有"预期"：你执行任何一步操作，脑子里必须先有一个"结果应该是什么样"的答案，否则你就是在盲目点击。这一步将来会演变成"测试用例"和"缺陷"两个概念的基石。

顺带交代一句：下面讲到的很多做法，在不同公司、不同团队里细节会有差异（比如缺陷等级叫法、用例字段），这是正常的。我讲的是业界最通用、最主流的版本，你理解了原理，换个壳也能举一反三。

什么是需求

需求（Requirement）听起来是个很朴素的词，但它在软件工程里有格外精确的分量。一句话定义：需求，是"软件应当做什么、满足什么条件"的正式描述，它是开发人员写代码、测试人员定标准的共同依据。如果你要问测试为什么能和开发"对得上话"，靠的就是同一份需求——开发照着做，测试照着验。

在多数软件公司里，需求一般会被拆成两部分：用户需求和软件需求。这两者肉眼看着像，其实是两件完全不同的事，很多测试新人踩的第一个坑就是把它们混为一谈。我们一节一节拆开说。

用户需求

用户需求（User Requirement），可以简单理解成"甲方提出的需求"。如果没有甲方（比如做自己公司的产品），那就是"终端用户使用产品时必须要完成的任务"。它最大的特点是简略，往往就是一句话。

用户的需求是五花八门的，而且常常只有一句话。比如："实现一个声控灯""实现一个软件的登录功能"。你能从这句话里知道灯要多灵敏吗？知道登录要用手机号还是邮箱还是第三方吗？知道密码错了要提示什么吗？统统不知道。但没关系，因为用户的身份决定了他说不出那么细的东西——他是"要结果的人"，不是"懂实现的人"。

软件需求

软件需求（Software Requirement），也叫功能需求，它会把"开发人员必须实现的软件功能"描述得非常详细。软件需求是测试人员进行测试工作的基本依据——你后面写的每一条期望、每一个预期结果，追根溯源都要回到这份软件需求上来。

为了让你一眼看清用户需求和软件需求的区别，我们来看一个流传很广、也极其传神的例子："女朋友饿了"。

• 用户需求：女朋友说"我饿了"。就这一句，很简略。这对应的是甲方/用户说的那句"我要个登录功能"。
• 软件需求：你需要和她反复沟通，把需求逐层问清楚，最终定出一套可执行的解决方案。比如你问她"想吃啥"，她说"随便"；你问"吃米饭炒菜？"，她说"不想吃"；你问"那你想吃啥？"，她说"随便"……在你一轮轮的追问下，最终你弄清楚：她不是要随便吃个东西敷衍，而是想吃"你亲手做的红烧肉"。到这一步，你才算是把"我饿了"这个用户需求，翻译成了目标明确的需求。

但这还没完。"想吃红烧肉"仍然不等于"软件需求"。接下来你怎么买肉、买哪种肉、怎么做、火候怎么控制——这些"具体可执行的步骤"才对应软件需求。也就是说：

• 用户需求是"要什么结果"，软件需求是"用什么方案、按什么步骤去达成这个结果"。

我们再对照一份软件需求规格说明书（SRS，Software Requirements Specification，就是描述软件需求的正式文档）里的常见写法，你会更直观地看到差异：

注意右边的"软件需求"，它把"怎么校验、成功提示什么、失败提示什么"全都写明白了。只有细化到这个程度，开发才知道自己该写什么代码，测试才知道自己该验什么结果。用户的原始需求，不能直接作为开发和测试的依据。

这里还要补一个关键环节：既然用户需求不能直接用来开发，那谁来把它变成软件需求？答案是产品经理。针对用户的原始需求，产品经理需要做需求分析——从技术可行性（这么做技术上能不能实现）、市场可行性（做出来有没有人买、有没有价值）、成本投入和收益占比（花多少钱、多久能回本）等多个维度进行分析判断，确认可行之后，才把用户需求转写成软件需求。所以你看，需求这层"翻译工作"本身就是一个专业岗位的活儿，不是拿过来就往上写的。

这里回答的其实是测试领域一个非常根本的问题：**测试的依据是什么？**答案是"软件需求"。如果一个功能连需求都没有明确，那它到底"对不对"，你就根本没法判断——因为你没有一把量尺。我们后面讲缺陷、讲用例三要素时，会一遍遍回头看这个点。

软件开发模型

认识了需求，我们接着往上游看：整个软件是怎么从无到有被造出来的。这就引出了"模型"这个概念。

什么是"模型"，为什么要谈模型

先说清楚"模型"在软件工程里指什么。别一听到"模型"就想到那种精致的塑料等比车模、飞机模型——在软件工程里，开发模型指的是"一套描述软件开发过程如何组织、各阶段如何衔接的框架和标准"。它本质上是人类从大量软件开发实践中总结出来的一种"做事的节奏"，说明软件开发不是乱来，而是有章法的。

为什么软件工程会需要模型这个东西？因为随着软件工程学科的发展，人们逐渐认识到：软件工作的范围，绝不只局限在"写程序"这一件事上，而是扩展到了整个软件生命周期——从软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换成新版本。除此之外，软件工程还包含很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐渐建立起了标准或规范。当所有环节都有标准可依、有模式可循时，开发这件事才从"手艺活"变成了"工程活"。

软件的生命周期

认识具体开发模型之前，得先认识软件的（开发）生命周期。

什么是"生命周期"（Life Cycle）？它指的是"从生命的开始到生命结束的一段时间"。以人为例，人类的生命周期是从生命孕育开始，中间经历幼年、童年、少年、青年、老年，直至死亡——这是所有人的共同轨迹。软件/产品的生命周期也不例外：需求的开始是软件生命的起点，中间会经历需求的计划、设计、程序开发、程序测试等阶段，直到软件不再进行维护，便到了生命的终点。

为了把这套抽象的阶段讲清楚，课件里用了一个特别形象的类比——亲手建一套房子。我们把"盖房子"和"做软件"的阶段一一对应起来：

于是我们就得到了软件（开发）的生命周期这条主线：

需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护

那每一个阶段具体都在做什么、产出什么？我再给你捋一张表，把"这个阶段干什么"和"这个阶段交什么文档"对应起来：

关于运行维护，还要多说一句——它本身又分成三个方向：

• 修复性维护：对项目中未发现的问题（上线后才暴露的）进行修复。房子漏了，补漏。
• 完善性维护：对功能进行完善/增强。房子住着觉得阳台小了，加宽一点。
• 预防性维护：居安思危，为了避免产品在线上出现其他不可预料的问题，预先做一些防护手段。比如提前加固、扩容、监控告警，别等房子塌了才想起加固。

到这里，"软件生命周期"这个生命周期概念就已经讲透了——它描述的是软件从"孕育需求"到"停止维护"的整个存续过程。你可能会觉得这是软件开发的事，跟测试有什么关系？关系很大：测试不是生命周期的某一个孤岛，而是贯穿其中、并直接决定"产品能不能交付"的关键一环。后面 V 模型、W 模型,就是专门围绕"测试在生命周期里站在哪、怎么站"来设计的。

常见的开发模型

认识完生命周期这条主线，我们来认识依附在它上面的几种经典开发模型。它们本质上是"同样六个阶段，用什么顺序、什么节奏来做"的不同流派。

瀑布模型

瀑布模型（Waterfall Model）在软件工程中占有重要地位，它是所有其他模型的基础框架。它的核心思想是：每一个阶段都只执行一次，阶段之间线性顺序推进——需求分析做完了才做计划，计划做完了才做设计，以此类推，像瀑布一样只能从上往下流，不能回头。

瀑布模型最大的缺陷在于：可以运行的产品很迟才能被看到。这会带来很大的项目风险，尤其是集成风险——因为如果在需求阶段引入的一个缺陷，要等到测试阶段甚至更后面的阶段才被发现，通常会导致前面阶段的工作大面积返工。业界有句流传很广的玩笑话叫"集成之日就是爆炸之日"（Big Bang），说的就是这种"所有模块最后一次性拼到一起，结果炸成一锅粥"的惨状。尽管瀑布模型存在很大缺陷——前期阶段未发现的错误会传递并扩散到后面阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目失败——但目前很多软件企业依然沿用瀑布模型的线性思想，只是在此基础上做了修改：比如细化了各个阶段，在某些重点关注的阶段之间掺入"迭代"的思想。

我们把瀑布模型的优缺点总结成一张表：

既然瀑布模型风险这么大，那它是不是完全不能用了呢？不是。**瀑布模型有个明确的适用场景：需求固定的小项目。**如果你的需求一开始就非常明确、基本不会变、规模也不大，那瀑布这种"一次走通"的方式反而是最省事的。

但现实是，企业里存在大量规模庞大、复杂度高、风险大的项目，这种情况下我们再死守瀑布就会很痛苦。于是就有了其他模型。

螺旋模型

螺旋模型（Spiral Model）：一般在软件开发初期阶段需求还不是特别明确时，会采用渐进式的开发模式，而螺旋模型就是渐进式开发模型的代表之一。

它尤其适合那些规模庞大、复杂度高、风险大的项目。这种迭代开发的模式，给软件测试带来了新的要求：**它不允许有一段独立完整的测试时间和阶段，测试必须跟随开发的迭代而迭代。**这句话请划重点——因为开发是一圈圈转着往前进的，测试就得每一圈都跟上。而在这里，回归测试的重要性就不言而喻了（什么是回归测试，我们后面专门有完整的章节讲，这里先记住：每一次新版本的迭代，都要确认旧功能没被改坏）。

螺旋模型的优缺点：

适用场景：规模庞大、复杂度高、风险大的项目。

增量模型与迭代模型

上面提到了"渐进式/迭代开发"，这里我们把两个很容易弄混的概念彻底掰清楚——增量开发和迭代开发。这两者往往被人搞混，但实际上是有区别的：

• 增量（Incremental）是"逐块建造"的概念：先把一块拼好，再拼下一块。
• 迭代（Iterative）是"反复求精"的概念：先把一个粗糙的整体轮廓搭出来，再一遍遍往细了修。

经典的例子是"画一幅人物画"：

• 增量模型是先画人物的头部，再画身体，再画手脚……按部位一块一块画完。
• 迭代模型是先画整体轮廓，再勾勒出基本雏形，再细化、着色……整体反复打磨。

先看增量开发。它能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次迭代都可能意味着需求更改、都可能构建出新的可执行软件版本，测试就需要频繁进行，测试人员也就需要与开发人员更加紧密地协作。

适用场景：大型项目、需求不明确。

敏捷模型

在早期，"迭代瀑布"（Iterative Waterfall）模型非常流行。但随着实践的深入，开发人员在用它的过程中遇到了各种问题。主要困难包括：在项目开发期间处理来自客户的变更请求，以及合并这些变更所需的高成本和时间。为了克服瀑布模型的这些缺点，1990 年代中期提出了敏捷软件开发模型（Agile Software Development）。

敏捷模型要干什么？一句话：帮助项目快速适应变更请求、促进项目的快速完成。敏捷性是靠"让过程适应项目、删掉对特定项目可能并非必需的活动、避免任何浪费时间和精力的事情"来实现的。

在敏捷模型里，需求被分解成许多可以增量开发的小部分，敏捷采用迭代开发。每个增量部分都是在一次迭代中开发的，每次迭代都旨在"小而易于管理"、并且只能在几周内完成。一次为客户计划、开发和部署一个迭代，没有制定长期计划。

敏捷模型里有一份非常重要的纲领性文件——《敏捷宣言》。它的内容是：

• 个体与交互 重于 过程和工具
• 可用的软件 重于 完备的文档
• 客户协作 重于 合同谈判
• 响应变化 重于 遵循计划

注意宣言主要用的是"对比"的手法，而它想表达的深意是：**在每一对对比中，后者并非全无价值，但我们更看重前者。**也就是说，不是说不要文档、不要计划，而是当二者冲突时，我们优先保证前者。由这份宣言可以总结出敏捷模型的四个特点：轻文档、轻流程、重目标、重产出。

敏捷开发有很多种具体做法，其中Scrum 是目前最流行的一种。Scrum 又称"迭代式增量软件开发模型"，它主要有三个角色和五个重要会议，我们逐一来看。

Scrum 的三个角色：

• Product Owner（产品经理）：负责整理 User Story（用户故事，注意这里说的"用户故事"不是写小说，而是敏捷中一种"以用户视角描述功能需求"的简短叙述），定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• Scrum Master（项目/敏捷教练）：负责召开各种会议、协调项目、为研发团队服务。它不是"项目经理"那样发号施令的角色，更像团队的服务者和流程守卫。
• 研发团队（Team）：由不同技能的成员组成，通过紧密协同完成每一次迭代的目标，交付产品。

Scrum 的迭代开发节奏：与瀑布不同，Scrum 将产品的开发分解为若干个小的 Sprint（迭代/冲刺），周期从 1 周到 4 周不等，但不会超过 4 周。参与的团队成员一般是 5 到 9 人。每期迭代要完成的 User Story 是固定的，每次迭代都会产生一定的交付。

Scrum 的五个会议：

1. 发布计划会议：Product Owner 负责讲解 User Story，对其进行估算和排序。它的产出就是制定出这一期迭代要完成的 Story 列表——叫 Sprint Backlog。（原始的产品待办清单叫 Product Backlog，由产品负责人整理 User Story 形成。）
2. 迭代计划会议：项目团队对每一个 Story 进行任务分解，分解的标准是"完成该 Story 所必需的所有任务"，每个任务都有明确的负责人，并完成工时的初步估算。
3. 每日例会（每日站会）：每天 Scrum Master 召集站立会议，团队成员依次回答三个问题——昨天做了什么、今天计划做什么、有什么问题。站着开，就是为了让会议短、聚焦。
4. 演示会议（评审会议）：迭代结束之后召开，相关人员都受邀参加，团队向所有人展示本次迭代取得的成果。大家的反馈被记录，由 Product Owner 整理，形成新的 Story，进入下一轮的待办。
5. 回顾会议：项目团队对本期迭代进行总结，发现不足、制定改进计划，下一次迭代继续改进，以达到持续改进的效果。

**敏捷中的测试又有什么不同？**这是测试人最关心的，归纳成两点：

• 轻文档 + 快速迭代：敏捷强调轻文档，所以测试人员不应再只用传统的 Excel 写测试用例，而是更多地使用思维导图、探索性测试（强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划）、自动化测试等方式来适应当前节奏。
• 讲求合作：在敏捷项目组中，测试人员应多主动跟开发人员了解需求、讨论设计、一起研究 bug 出现的原因——而不是等开发把东西丢过来，自己闷头点点点。

看到这里，你其实已经把"开发模型"这一片拼图拿全了：瀑布是打地基的祖师爷，螺旋管高风险大项目，增量/迭代是建造节奏，敏捷是它们的现代升级版。接下来我们要看的"测试模型"，是专门从测试的视角回答一个问题的——测试到底应该在生命周期的哪些位置上发力。

测试模型

程序里有需求、计划、设计……那测试有没有自己的一套"嵌入式模型"？有，而且有两个非常具有标志性——V 模型和W 模型。

V 模型

V 模型最早由 Paul Rook（保罗·鲁克）在 20 世纪 80 年代后期提出，目的是改进软件开发的效率和效果，属于瀑布模型的变种。它为什么叫"V"？因为你把"开发阶段的左侧分支"和"测试阶段的右侧分支"画出来，正好形成一个大大的 V 字。

它把测试明确区分成了不同类型，并把这些测试阶段和开发过程各阶段一一对应起来：

• 单元测试和集成测试，对应开发阶段的编码/设计，用来检测程序的执行是否满足软件设计的要求；
• 系统测试，对应需求分析，用来检测系统功能、性能的质量特性是否达到系统要求的指标；
• 验收测试，对应用户需求/合同，用来确定软件的实现是否满足用户需要或合同的要求。

V 模型的优点：

• 明确标注了测试过程中存在的不同类型的测试，并清楚地描述了这些测试阶段和开发过程各阶段的对应关系，有效提升了测试的质量和效率。
• 它点出了测试层级和"验证对象"的严格对应关系——你测的粒度越小、对应得越靠开发下游；越接近用户，对应得越靠开发上游。这一思想至今被广泛沿用（单元→集成→系统→验收的语法几乎成了行业默认词汇）。

V 模型的缺点：**仅仅把测试当作编码之后的一个阶段，没有在需求阶段就介入测试。**它的缺点同瀑布模型——测试依旧后置，早期需求引入的缺陷还是要等到编码完成后才开始测。这跟瀑布是同一个毛病。

W 模型（双 V 模型）

V 模型"未把测试前置"的问题，在 W 模型中得到了解决。W 模型增加了软件各开发阶段中应同步进行的验证（Verification）和确认（Validation）活动。它由两个 V 字型模型组成——左边的 V 代表"开发过程"，右边的 V 代表"测试过程"，图中明确表示了测试与开发的并行关系。

W 模型的核心特点一句话就能概括：**测试的对象不仅是程序，需求、设计等同样要测；测试与开发是同步进行的。**你可以在需求分析完成后，测试人员就参与到对需求的验证和确认活动中，尽早找出需求本身的缺陷——而不是等到代码写完了才发现"啊，原来这个需求根本说不通"。

W 模型的优点：

• 有利于尽早地、全面地发现问题。例如需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，尽早找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间、加快项目进度。

W 模型的缺点：

• 需求、设计、编码等活动被视为串行的；
• 测试和开发活动之间也保持着一种线性的前后关系——上一阶段完全结束，才可正式开始下一阶段工作；
• 重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W 模型并不能解除测试管理面临的困惑。

一句话收束两个模型：V 模型解决了"测试类型和开发阶段对应关系"的问题，W 模型进一步解决了"测试前置、尽早介入"的问题；但它们都是面向"传统串行流程"的模型，到了敏捷时代，又需要新的灵活应对。

测试用例

概念和模型都铺垫到位了，现在进入测试人每天都要亲手打交道的东西——测试用例。这是概念篇里分量最重的一块，也几乎是面试官最爱问的基础题。

**什么是测试用例？**测试用例（Test Case），简而言之就是"为了验证某个具体功能点而设计的一组操作步骤与预期结果的集合"。你可以把它理解成一份"给软件立下的考试卷"：先摆出考试环境（前置条件），再写清一道题怎么一步步做（操作步骤），最后写明"正确答对是多少分、正确答案长什么样"（预期结果）。

它为什么重要？因为你不可能靠"想到哪点到哪"来做完一个项目的测试——那样你不知道自己测过什么、没测过什么，也无法让别人接手。测试用例给了测试三样最宝贵的东西：可重复性（换个人照着步骤也能重新验一遍）、可追溯性（每条用例都对应一个需求点，需求覆盖清清楚楚）、可度量性（用例总共多少条、跑了多少条、过了多少条，全都能量化）。所以，用例不是测试的"应付文档"，而是测试作为工程的脊柱。

用例的三要素

提到测试用例，业界反复强调一个"三要素"的说法。不同的资料给出的三要素名字略有出入，这里我讲两条最常见的表述，并把它们合起来理解，你就再也不会绕晕了：

• 表述一：前置条件、操作步骤、预期结果。
• 表述二：测试数据、操作步骤、预期结果。

你发现没有，两条表述里共同出现的、雷打不动的两个是"操作步骤"和"预期结果"。它们的差异在第三项：到底是"前置条件"还是"测试数据"？其实它们都在说同一件事的不同侧面——一条能真正跑起来、能真正判定对错的用例，下面这三点缺一不可：

1. 前置条件（Precondition）：执行这条用例时，软件和外部环境必须处于什么状态。比如"用户已登录"、"数据库已初始化"、"当前网络正常"。前置条件错一位卡，这条用例可能根本执行不下去，或者跑出来结果不对。
2. 操作步骤（Step）：从哪一步开始、按什么顺序、如何操作。它必须具体到"可照着做"，不能出现"随便点一下"这种模糊指令。
3. 预期结果（Expected Result）：完成上述操作之后，软件应该呈现的、符合需求标准的结果。说说看，如果期望只是"应该正常"——这算不算预期结果？答案是不算。"正常"太抽象了，得写清"页面显示『登录成功』并跳转到首页""余额显示为 ¥100.00"这种可判定、可量化的描述，才叫预期结果。

那"测试数据"和"实际结果"去哪了？别慌，它们是这么回事：

• 测试数据（Test Data）：往往可以并入前置或步骤里——比如"输入邮箱 test@example.com、密码 Abc123"这部分数据，既是在准备前置条件，也是操作步骤的一部分。所以"测试数据"与"前置条件/步骤"并不矛盾，它是这些字段里具体填入的"料"。
• 实际结果（Actual Result）：它不是你写用例时就有的，而是执行这条用例后，软件真实呈现出来的结果。实际结果与预期结果，一对比，就产生了"过/不过"的判定。所以它属于"用例执行时补填"的字段，而不是编写用例时预设的内容。

我们把上面这些整合成一张"测试用例的完整字段表"，这正是你在企业里最常见的用例模板（不同项目字段名略有差异，但主体万变不离其宗）：

这张表，就是"用例"这个概念在现实中落地的完整形态。你现在应该能回答最初那个问题了——为什么"乱点"不叫测试？因为乱点没有前置、没有步骤、没有预期，更谈不上对比实际结果。有没有一份完备的用例，往往就是一个团队"在测"还是"在体验"的分水岭。

用例三要素的边界与坑

正因为"三要素"是判定用例有效性的标尺，测试新人特别容易在这几个坑里栽跟头：

• 坑一：只有步骤，没有预期。 这是最常见的一种"伪用例"——写了一大串操作步骤，最后预期结果写个"正常"或者干脆空着。这样的用例形同虚设，因为执行者不知道自己对不对、该比什么。记住：预期结果必须对得上需求、必须可判定。
• 坑二：只有预期，没有前置。 比如一条登录用例没有说明"用户得先注册"，执行的人拿着一个没注册的账号去登录，弹出的提示和预期的完全对不上，就会误判为"bug"。其实是你自己没把前置条件交代清楚。前置条件没写清，用例的可执行性直接打折。
• 坑三：把"实际结果"当成了"预期结果"来写。 写用例的人图省事，直接照着"现在软件长什么样"写上去了，而忘了预期结果应该参照需求而不是现状。这会导致一个可怕的结果：软件实现某天真的破了需求，用例依然"通过"——因为预期被写成了"和现状一致"。这是"缺陷与需求不符"问题的一大根源，后面专门讲。

用例设计的基本思维

聊完用例长什么样，我们再往前迈一步：这些用例是怎么设计出来的？这是测试的看家本领。概念篇里我们先建立两个最基础、也最普适的思维——等价类划分和边界值分析。很多人印象里，这是"学了边界值方法以后的事"，其实你在设计任意一条用例时，脑子里转的都是这两件事。

等价类划分（Equivalence Partitioning）：把所有可能的输入按"测试效果等价"划分成若干组，每一组里抽一个代表来测就够，不必把每个可能值都试一遍。这个思路的核心是"代表性"——既然同组的输入走的是同一段代码逻辑、出的是同一类结果，那测一个代表，就等于测了整组。

举个最经典的例子：需求规定"登录密码为 6~16 位，由字母和数字组成"。按等价类，你可以划分出这么几组：

• 有效等价类（软件应该接受的）：合法 6~16 位字母数字组合，比如 Ab1234。
• 无效等价类（软件应该拒绝的）：
  • 长度不合法：短于 6 位（如 ab1）、长于 16 位（如 17 位的串）；
  • 字符不合法：包含字母数字以外的字符（如 Ab@123）；
  • 只含字母不含数字（如 abcdef）、只含数字不含字母（如 123456）。
  • 空输入：直接不填密码提交。

你看，通过等价类，我们把"成千上万种可能的密码"压缩成了"一小撮有代表性的类"，每条用例覆盖一大片，这就是测试效率的哲学。边界值分析（Boundary Value Analysis）是等价类的黄金搭档。软件领域的错误，最喜欢潜伏在"边界"上——因为判断条件往往写成"大于等于某值""小于等于某值"，写错一个等号，边界就破个洞。边界值分析要求我们不仅测等价类的"代表值"，更要专门测每一类边界的"等于、略小于、略大于"这些关键点。沿用密码 6~16 位的例子：除了代表性的合法密码，你还得专门测 5 位、6 位、7 位、15 位、16 位、17 位——因为这些"卡在判定线上"的值，最容易测出开发把 >= 写成 > 这类低级又致命的错误。

概念篇我们先把这个思维讲透，具体的完整方法论（还有判定表、正交、场景法等）会放在后面的设计方法篇专门展开。你现在只需要种下一个习惯：**设计用例时，先想"这输入该分成哪几类、每类抽谁代表"，再想"每种分类的边界点在哪、得补测哪几个关键值"。**这个习惯，能让你在测试岗上先立于不败之地。

缺陷

选择题环节先来一道：下面哪个算是"缺陷"？

• A. 用户说"这个按钮颜色不好看"
• B. 用户按需求输入，结果系统弹出了错误的提示
• C. 需求上没写的功能，系统多了个隐藏按钮
• D. 以上都是

先不急着公布答案，我们把"缺陷"这个概念彻底讲透，你再回头选——这道题本身就是一道很好的思考题（答案放在文末，但更希望你读完自己判断）。

什么是缺陷

缺陷（Defect），日常嘴上的叫法是 Bug（臭虫，源自早期计算机工程师从继电器里拔出真实虫子的典故，后来泛指程序中的毛病）。在软件工程里，对"缺陷到底怎么定义"有一套更严谨的表述。先引入一条软件质量的经典链条，帮你把几个容易混的词归位：

• 错误（Error）：人犯的错，比如程序员把 > 写成了 >=。
• 缺陷（Defect，也叫 Fault）：这个错误混进了代码，成了留在程序/文档里的"问题源"。它是静止的，躺着代码里。
• 故障/失败（Failure）：缺陷在运行中被触发，表现出来的"现象"。比如用户一操作就报错。它是动态的，是我们亲眼看到的结果。

用一句话连起来：**人犯了个错误 → 代码里留下一个缺陷 → 运行这个功能时故障就暴露了。**所以，测试人员天天报的"bug"，严格说多是"现象层面的 Failure"，而我们要顺着它去定位、去描述"代码层面的 Defect"。不过在绝大多数公司的日常语境里，"缺陷""bug""故障"混着说也没人计较，关键是你要心里清楚它们的层级差别。

那么，"什么算一个缺陷"？这里正好呼应我们前面反复强调的"需求"——缺陷，本质上是"实际结果与预期结果不符"，而这个"预期结果"的源头就是需求。因此判定一条缺陷，最常用的标准就是缺陷与需求不符：软件该按需求做出来的行为没做出来、做错了，或者多做了需求之外的东西而影响了正确行为，都算缺陷。

顺带着，我们就可以解开前面那道选择题了：

• A 是"用户体验/审美"层面的反馈，若需求里没有任何关于配色的明确标准，它更像"需求之外的建议"，不能直接判作缺陷——除非有明确的设计标准说你违反了它；
• B 是典型的"实际与预期不符"，是标准的缺陷；
• C"多做了需求之外的功能"，如果这个隐藏功能影响了预期行为或造成了风险，也是缺陷（需求之外不应存在的行为，往往被归为缺陷或安全性问题）。

所以正解是 D（以上都有可能构成缺陷），但判定的关键永远是你有没有一把"需求"这把尺子。这也再次印证：不理解需求，就无从下结论"它是不是 bug"。

缺陷的等级

缺陷报出来了，是不是全都一个待遇？当然不是。缺陷要分轻重缓急，否则团队会被海量小 bug 淹没，真正的致命问题反而排不上队。这个轻重缓急，就是缺陷等级（Defect Severity）。

业界最主流的做法，是把缺陷按严重程度（Severity，对软件/M 用户影响的大小）分成四个等级。不同公司叫法略有差异，常见的一套如下（我同时给出英文和中文叫法，方便你对照英文系统的 Case）：

注意，缺陷等级有两个容易和它混淆的概念，必须分清：

• 严重程度（Severity）：上面这张表，描述的是"问题本身有多重"，是客观维度。
• 优先级（Priority）：描述的是"该多快修"，是排期维度，带主观和战略色彩。

严重 ≠ 优先级。举个真实的例子：一个错别字，严重程度很低（不影响功能），但如果它出现在给客户看的、合同金额相关的页面上，可能优先级就被提到很高；反过来，一个只在某个极端冷门环境下触发的崩溃，严重度很高，但优先级可能被排得很靠后（因为几乎没人会撞到）。所以你报缺陷时，应当分别评估"严重程度"和"优先级"，不能混着填。

缺陷的生命周期

和软件有生命周期一样，一个缺陷从被发现到彻底了结，也要走完一生。理解缺陷的生命周期（Defect Life Cycle），是测试协作的钥匙——你每天和开发的拉锯，本质上就是"把缺陷推到生命周期哪一站"的协调。

我们来看一条缺陷最经典的流转路径（结合一套典型的缺陷管理工具状态，比如 Jira 的 Workflow）：

新建 → 已确认 → 已分配 → 已修复 → 已复验 → 关闭
开          |          |         |         |
修          +-- 拒绝(Invalid/Not a Bug)    +-- 重新打开(Reopen)
                                        (复验不过就重新打开)

逐站解释：

1. 新建（New）：测试人员发现并提交缺陷，创建一条缺陷单，填清标题、步骤、预期、实际、等级、优先级、环境、附件等。此时状态为"新建"。
2. 待确认 / 已确认（Confirmed）：开发（或测试负责人）核对后，认定"这确实是缺陷"，转到"确认"，并通常会指派一个负责人来处理。这一站是一道"过滤网"，很多"提交了却发现不是 bug"的单子就在这被拦下。
3. 已分配（Assigned）：缺陷正式落实到某个开发头上，准备修复。
4. 已修复（Fixed / Resolved）：开发宣称修好了，缺陷进入"待验证"状态。
5. 复验 / 关闭（Closed）：测试人员拿到新版本，照原步骤重新执行，确认问题消失且没引入新问题，然后关闭缺陷。
6. 重新打开（Reopened）：复验后问题依旧，或修好 A 又弄坏了 B，测试把缺陷重新打开，回到修复流程再来一轮。

除了这条主线，还有几个分支状态要记住：

• 拒绝 / 无效（Invalid / Not a Bug）：开发审查后认为这根本不是缺陷（比如操作方式错误、环境不允许、不符合需求标准而被澄清）。如果测试不认同，可以提出再讨论，或按流程升级。
• 延期处理 / 挂起（Deferred）：确认为缺陷，但暂不修（比如本期资源不足、影响极小），挂起留到以后版本。
• 重复（Duplicate）：和已有缺陷是同一个问题，合并处理。

这里有个测试人必须守住的职业底线：**复验必须亲自动手照原步骤重新跑一遍，而不是"开发说修好了就信了"。**你信任开发的人品，但不能信任自己的记忆和开发的一句话——bug 是否真的没了，必须以你的实测结果为准。

还有一条实战经验：**一个好的缺陷报告，本身就是测试功力的体现。**至少应该包含：清晰能复现的标题、详细的前置/步骤、明确的"实际 vs 预期"、必要的截图/日志、环境信息（设备、浏览器、系统、版本）、严重程度与优先级。你把缺陷写得含糊（比如"登录不了"），开发定位半天定位不到，来回踢皮球，浪费的是整个团队的时间。

缺陷与需求不符：一个必须拎出来单独讲的坑

前面反复出现"缺陷 = 实际与需求不符"，但有一个特别隐蔽的坑，必须单独拎出来讲清楚——有一种"缺陷"，它的源头根本不在代码，而在需求本身。

我们把情况摊开看：

• 情况一：需求是对的，代码没实现好。 这是最常见的，修改代码即可，缺陷闭环清晰。
• 情况二：需求本身就是错的、模糊的、或前后矛盾的。 开发照着这个"坏需求"写，写出来的东西当然是有问题的，但问题不在代码，而在需求。如果测试只会"照着需求验需求"，那么当需求错了时，测试会得出一个荒诞的结论："和需求一致，通过！"——而产品在用户手里却是个残次品。

这正是测试要"前置到需求阶段"（W 模型的核心思想）的原因：**对需求的测试，同样是测试工作的一部分。**一个成熟的测试团队，在评审需求时就会积极提问——这个需求说得通吗？边界定义清了没有？异常情况覆盖了吗？有没有自相矛盾的地方？把需求阶段发现的问题堵住，成本远比上线后返工低得多。这也再次回答了一个疑问：测试的对象绝不只是"代码"，需求、设计文档同样需要被"测试"（在这个语境下，通常叫"评审/验证/确认"）。

给你的实操建议：当你执行用例发现"实际结果和需求一致，但这个东西明显不对劲"时，别急着给开发开 bug 单，先回头审视需求——你很可能发现的是需求缺陷。这既避免误伤开发，也体现你作为测试对"需求可测性"的理解深度。

回归测试

概念篇里，"回归"这个词已经出现过几次了（螺旋模型的迭代、敏捷的快速迭代里都提到"回归测试很重要"）。这里我们把回归测试（Regression Testing）彻底讲清楚，因为它直接关系到"缺陷修复会不会引入新问题"，是测试里最容易出乱子、也最考验纪律的环节之一。

什么是回归测试？在给软件做了修改之后（修了一个 bug、加了一个新功能、改了一段代码），为了确认这些改动没有把原本正常的功能弄坏、没有引入新的缺陷，而重新执行之前通过的测试用例，这个过程就叫回归测试。

为什么必须有这么一道工序？因为软件是牵一发而动全身的。你修了一个 bug，改的可能是某处公共逻辑——这块逻辑被十个功能共用。你把这里一改，bug 是没了，但另外五个功能全被改坏了。这种"按下葫芦浮起瓢"的事，在真实项目里每天都在发生。回归测试，就是专门用来兜住"我这次改动，是不是顺带捅了别的娄子"这一问的。

回归测试的关键点与坑：

• 回归用"旧用例"：回归测的是"以前测过、并且通过"的那批用例，跑它就是为了确认"以前是好的，现在还是好的"。所以一套好的、可持续维护的用例库，是回归测试的地基——用例没有归档沉淀，你就无从"回归"。
• 改得越多，回归面越大：一个模块改动，殃及的范围往往不止这个模块本身。所以回归范围要按"改动影响面"来评估，全量回归最稳妥但也最贵，日常常用"重点回归 + 影响面回归"的组合，自己掂量风险。
• 回归不是一次性的：每一次发布、每一次迭代合入，都可能需要回归。在敏捷/持续集成的节奏里，回归往往是自动化测试的一等公民——把高频、稳定的回归用例做成自动化，每次跑一遍，能省大量人力。

这里有个测试新手的名场面，提前给你打个预防针：开发修完 bug 说"好了"，你复验时不光要验证"这个 bug 好了"，更要顺手过一遍相关功能是否还正常——这就是最基本的回归意识。很多新人只盯着自己那条 bug 验，结果上线几天后，旁边的功能悄悄坏掉，追责时才发现复验时压根没回归相邻功能。

测试与开发的协作

到最后一块拼图——测试与开发怎么协作。前面的内容其实已经埋了很多协作的伏笔（需求评审、缺陷复验、回归确认），这里把它们收拢成一套清晰的心法。这段不涉及硬性概念，但它是决定你"能不能把测试做好"的软实力，概念篇必须给你立正这面镜子。

**第一，从"对立"走向"共同目标"。**一个常见认知误区是"测试=挑刺、找开发麻烦"。实际上，测试和开发的目标完全一致：交付一个可靠的、满足需求的产品。只是一个人负责"造对"，一个人负责"验对"。心里装着这个共识，沟通就不会变成互撕。

**第二，越早介入，越省成本。**前面 V/W 模型已经反复强调：测试前置。不要在开发"全部写完、甩到你面前"之后才开始看需求、写用例。敏捷里测试更要全程在场——多跟开发了解需求、讨论设计、一起研究 bug 出现的原因。你前置得越多，返工越少，团队越感谢你。

**第三，缺陷沟通靠"事实"而非"情绪"。**报 bug 时带上完整的复现步骤、实际 vs 预期、环境、日志，比你说十句"这功能有问题"都要管用。争议不可避免（尤其遇到"我觉得这不是 bug"），这时回到那把尺子——需求，逐条对照，以标准和事实说话。

**第四，闭环是大家的责任。**缺陷从"新建"到"关闭"，中间每一步都依赖测试说清楚、开发改到位、双方确认。复验不过就重新打开，坦率沟通；需求歧义就拉产品经理一起对齐。一个健康的缺陷流，是整个团队协作质量的体温计。

到这里，概念篇要讲的核心就全部串起来了。你回头看会发现，它们其实是一条线：需求是尺子 → 生命周期里测试各就各位（V/W/敏捷模型）→ 用例是丈量的度量工具 → 缺陷是测量发现的"不符" → 回归是防止"越修越坏"的保险 → 协作是把这一切串起来的胶水。

概念篇就先讲到这里。我们从"需求"这个测试的度量基准出发，看清了用户需求与软件需求的差别，以及产品经理做需求分析的那道翻译工序；随后走完了软件的生命周期，认识了瀑布、螺旋、增量/迭代、敏捷（Scrum）等开发模型，以及从测试视角设计出来的 V 模型和 W 模型——核心就是"测试前置、全面介入"；接着我们亲手拆解了测试用例的字段和三要素，掌握了两条最基础的用例设计思维（等价类、边界值）；然后给"缺陷"立了定义、分了级、介绍了它的一生，并单独把"缺陷与需求不符"这个隐蔽的坑刨了出来；最后讲了回归测试为什么是"越修越坏"的保险，以及测试与开发协作的心法。

如果你能合上页面，用自己的话把"需求、用例（前置/步骤/预期）、缺陷等级、生命周期、回归"这几个词各讲一分钟，那概念篇就算真正拿下了。接下来，我们进入测试设计方法的实战篇，把等价类、边界值那套思维展开成一整套完整的用例设计方法体系，再配上判定表、因果图、场景法这些利器。准备好继续往下挖了吗？

思考题（带参考答案）

思考题 1：用户需求 vs 软件需求 "我要一个搜索功能"这句话，是用户需求还是软件需求？请把这句话改写成至少包含三要素的软件需求。

答案："我要一个搜索功能"是用户需求，因为它只是用户的一句话，非常简略，没有细化到可开发、可测试的程度。 要把它改写成软件需求，需要产品经理做需求分析，细化到开发和测试都能看懂。一个衡量改写是否合格的标尺，就是"它能不能支撑起一条条测试用例"。可如下改写（不止一种正确答案）：

• 名称：搜索功能。
• 输入：在搜索框输入 1~50 个任意字符的关键词（支持中英文、数字、空格）。
• 触发：点击"搜索"按钮，或输入完成后按回车。
• 行为：在站内标题与正文范围内，对输入做包含匹配，返回与关键词有关的结果并按相关度降序排列。
• 结果：有结果时展示列表（显示标题、摘要、作者、日期）；无结果时展示友好空态提示"未找到与关键词相关的结果"；关键词为空时给出提示"请输入搜索关键词"。 这样，开发和测试就都有了明确依据——预期结果、边界情况（空、超长、无结果）全都可判定。判定要点：软件需求必须让"能不能写用例"这个问题变得一目了然。

思考题 2：三个角色与五个会议 请说出 Scrum 的三个角色和五个会议，并说明"发布计划会议"和"迭代计划会议"分别产出什么。

答案： 三个角色：Product Owner（产品经理）、Scrum Master（项目/敏捷教练）、研发团队（Team）。 五个会议：发布计划会议、迭代计划会议、每日例会（站会）、演示会议（评审会议）、回顾会议。 产出区别：发布计划会议由 Product Owner 负责讲解并排序 User Story，产出是"本期要完成的 Story 清单"即 Sprint Backlog（它是从整体待办 Product Backlog 中挑出来的）；迭代计划会议则由团队对每个 Story 做任务分解，产出是"该 Story 的所有任务分解 + 每个任务的负责人 + 工时初估计"。一句话区分：发布计划会议定"本期做什么"（Story 层面），迭代计划会议定"这些 Story 怎么拆任务、谁来做"（任务层面）。

思考题 3：用例三要素 下面这条测试用例缺了哪一项？说明它会导致什么问题。 "测试人：小张；步骤：打开首页，点击登录，输入 abc，点击提交。"

答案：缺了预期结果（严格说，前置条件、测试数据（什么才是合法的 abc，这里是数据但不完整）、预期结果都没有充分交代，但最致命的是缺预期结果）。没有预期结果，执行者无法判定"实际结果对不对"，这条用例形同虚设，别人接手不知道该拿什么当标准去比对，也就无法得出"通过/失败"的结论。一条能判定的用例，至少要同时具备：前置条件、操作步骤、预期结果（再带上测试数据）。缺少预期，就无法形成"实际 vs 预期"的判定，也就没法发现缺陷。

思考题 4：等价类与边界值（综合） 需求：注册页"手机号"字段要求为"11 位、以 1 开头的数字"。请给出至少 3 个有效等价类代表值、4 个无效等价类代表值，并写出你专门用于边界值分析的几个关键输入。

答案： 有效等价类代表值（软件应接受）：13812345678（11 位、以 1 开头）；也可以补 10012345678、19912345678 等覆盖"以 1 开头的多种情况"。核心是"11 位数字且首字符为 1"， 无效等价类代表值（软件应拒绝）：

1. 位数错误：123（过短）；
2. 首位错误：21812345678（11 位但不是 1 开头）；
3. 含非数字字符：1381234567a（含字母）；
4. 首位非 1 且含符号：a3812345678（首字符非数字）；

边界值分析关键输入（针对"11 位、以 1 开头"的判定边界）：

• 长度边界：10 位（如 1381234567）、11 位（如 13812345678）、12 位（如 138123456789）——分别对应略短、等于、略长。
• 前缀边界：首字符为 0、1、2（第一位是否为 1 的边界两侧）；

这些"卡在判定线"输入最容易暴露开发把 = 写成 >、< 或把首位判断漏掉之类的错误。 判定要点：等价类负责"分成哪几组"，边界值负责"在每组的临界点补测"，两者搭配才能既不漏关键值、又不至于穷举所有输入。

思考题 5：缺陷等级与优先级 一个银行 App 上，把"转账金额"输入框的提示文字写错了（比如提示"请输入 1 到 50000"，实际规则是 1 到 5000），它影响核心金额数字的输入吗？它的"严重程度"和"优先级"分别该怎么定？

答案：文字提示错误本身不影响金额数字的实际输入，输入框的功能（接收数字、校验范围）是正常的，所以它的严重程度不高，属于"一般/轻微"级别（不影响功能主流程，仅影响提示准确性）。 但它涉及金额与规则这种对用户很重要、也最容易引发用户误解和客诉的场景，从"该多快修"的优先级角度，往往会排得比普通错别字高。 判定要点：再次验证"严重程度（问题本身多重）"与"优先级（该多快修）"是两套维度。错字级别低，但出现在关键业务文案界面，优先级可上调。这也提醒你——不要只根据严重程度决定排期。

思考题 6：缺陷与需求不符的隐蔽坑 开发照着需求实现了某个功能，测试执行用例发现"实际结果和需求完全一致"，但产品经理和用户都认为"这个功能很难用、不合理"。请判断：这是不是缺陷？测试应如何处理？

答案：按"实际 vs 需求一致"的标准看，它不是"代码层面的缺陷"，因为代码忠实实现了需求。但它极可能暴露了需求本身的缺陷（需求不清晰、设计不合理、不符合用户真实使用习惯）。这恰恰是"缺陷与需求不符"这个坑的核心提醒——测试不能只照着需求验需求。正确做法：不要立刻只给开发开 bug 单，而是回头重新审视需求与设计，把这个问题作为"需求/设计缺陷或改进建议"反馈给产品经理（拉上开发一起评审），由需求方评估是否需要调整需求。这既体现你对"需求可测性、合理性"的敏感，也避免把锅甩到照做需求的开发头上。