软件测试理论：定义、分类、质量模型、原则、流程（入门第一课）

学软件测试，理论是绕不开的第一步。很多小伙伴觉得理论"背了没用"，我一开始也这么想，直到自己动手写用例、提 bug 的时候才发现：不懂理论，你连"这个测试属于哪个环节""这个 bug 该算多严重"都说不清楚。

理论决定了你工作时"在哪个环节、测什么、怎么定位自己"。

目录

• 一、软件测试的定义与价值
  • 1.1 一句话定义 + 三个关键词拆解
  • 1.2 测试的对象：不只是程序
  • 1.3 测试的三大目的
  • 1.4 测试 ≠ 调试（附对比表）
  • 1.5 测试能证明什么、不能证明什么

• 二、开发模式与测试的关系
  • 2.1 软件生命周期（SDLC）
  • 2.2 V 模型：开发阶段与测试阶段的对应关系
  • 2.3 敏捷开发中，测试怎么介入
  • 2.4 测试左移与测试右移

• 三、测试分类
  • 3.1 按阶段：单元 / 集成（3 种集成策略）/ 系统（7 种系统测试）/ 验收（α / β）
  • 3.2 按是否看代码：黑盒 / 白盒（3 种覆盖标准）/ 灰盒
  • 3.3 按是否执行：静态 / 动态
  • 3.4 按执行方式：手工 / 自动化（什么适合自动化）
  • 3.5 其他高频概念：冒烟 / 回归 / 探索性 / 兼容性 / 安全

• 四、软件质量模型（ISO/IEC 25010，8 大特性）

• 五、测试原则

• 六、标准测试流程

• 七、什么时候可以停止测试？（测试退出标准）

• 八、练手建议与写在最后

一、软件测试的定义与价值

1.1 一句话定义 + 三个关键词拆解

经典定义（教材版，理解着记）：

软件测试是通过人工或自动化的方式，运行或检查系统的过程，目的是发现软件中的缺陷，评估软件质量，确保产品符合需求。

拆开看三个关键词：

• 发现缺陷：测试的直接产出就是 bug。没有发现 bug 的测试值得警惕——要么软件真的好，要么你根本没测到位，这两者要能区分开；

• 评估质量：测试不只是找 bug，还要在版本发布前回答一个问题——"这个版本能不能上"，这是测试报告的核心价值；

• 符合需求：判断对错的依据是需求文档。开发说"这是设计如此"不算数，你觉得"不好用"也不算 bug——一切以需求为准绳。

1.2 测试的对象：不只是程序

很多人以为测试就是"测代码写出来的软件"，其实测试贯穿所有工作产品：

• 需求文档：需求写得自相矛盾、没法验收，就是文档级缺陷（而且是成本最低就能发现的一种）；

• 设计文档：接口方案、数据库设计里埋的坑，评审时发现比上线后发现便宜一百倍；

• 源代码：代码走查、静态扫描都属于测试；

• 可执行程序：我们日常理解的"测软件"；

• 数据与配置：配置文件写错、环境变量不对，功能全对也跑不起来。

理解这一点，就明白为什么"需求评审"也是测试工作的一部分。

1.3 测试的三大目的

1. 发现缺陷：在用户之前找到问题，把事故拦在上线前；

1. 评估质量：给团队提供"能不能发版"的决策依据（通过率、bug 分布、遗留风险）；

1. 降低风险：验证软件在异常场景下（断网、并发、恶意输入、断电）不会造成损失。

记住一句话：测试的价值不是证明软件能跑，而是找到它什么时候跑不了。

1.4 测试 ≠ 调试（附对比表）

这是新手最容易混的一对概念，务必分清：

一句话总结：测试负责找到并证明问题，调试负责找到并解决问题。两者由不同角色完成、互相独立，才能互相制衡——自己写的代码自己测自己修，问题永远发现不了。

1.5 测试能证明什么、不能证明什么

测试只能证明缺陷存在，不能证明缺陷不存在。

用一个直觉算式理解：一个接受字符串的输入框，可能的输入是无限的——长度无限 × 字符组合无限 × 顺序无限。你测了 1000 条全部通过，也不能保证第 1001 条不出问题。

所以测试的思路不是"证明没问题"，而是用最小的成本，覆盖最容易出问题的地方——风险越高、概率越大的场景优先测。这就是后面用例设计方法（等价类、边界值）存在的全部意义。

二、开发模式与测试的关系

2.1 软件生命周期（SDLC）

需求分析 → 设计 → 编码 → 测试 → 上线 → 运维

每个阶段测试都能介入：需求阶段评审需求的可测性，设计阶段评审方案风险，编码阶段做单元测试，测试阶段执行系统测试，上线后做线上监控。

2.2 V 模型：开发阶段与测试阶段的对应关系

V 模型把"每个开发阶段都有对应的测试阶段"画得很清楚，是理解测试分类的最好框架：

需求分析 ──────────────────────── 验收测试 设计 ────────────────── 系统测试 概要设计 ───────── 集成测试 编码 ───── 单元测试

左边往下是开发过程，右边往上是测试过程，一一对应：

• 需求分析 ←→ 验收测试（验收标准在需求阶段就定好了）

• 系统设计 ←→ 系统测试

• 概要设计 ←→ 集成测试（接口怎么定义的，就怎么测集成）

• 编码 ←→ 单元测试

V 模型的启示：测试用例不是写代码时才准备的，需求定下来的时候，验收测试的框架就该有了。

2.3 敏捷开发中，测试怎么介入

瀑布模型：阶段串行，需求全部确定 → 开发 → 测试。测试在开发完成后集中进行，周期长，问题暴露晚，改起来伤筋动骨。

敏捷开发：以 2 周左右一个迭代（Sprint）滚动交付，测试的要求变成：

• 测试和开发同步：每个迭代里，开发在写这个故事，测试在写它的用例，开发完成立刻提测，不再有"集中测试期"；

• 自动化是刚需：迭代快、发版勤，回归测试靠手工根本跑不完，稳定功能的回归必须自动化；

• 测试参与全程：参加需求梳理（把验收条件聊清楚）、每日站会（同步 bug 和阻塞）、迭代评审（演示通过的场景）。

现在国内互联网公司基本都是敏捷模式，所以"会自动化 + 懂业务"的测试才值钱，纯手工点点的空间在被压缩。

2.4 测试左移与测试右移

• 测试左移：把测试活动往生命周期前面移——需求评审、设计评审、代码评审时就介入。依据是成本曲线：需求阶段修一个理解偏差的成本，是线上修一个 bug 成本的几十分之一。

• 测试右移：把测试活动往上线后延伸——线上监控、日志告警、灰度发布验证、用户反馈处理。毕竟测试环境永远 100% 还原不了线上真实的数据量和用户操作。

三、测试分类（5 组概念）

3.1 按阶段：单元 → 集成 → 系统 → 验收

记忆点：由内到外，越往后越接近真实用户。

集成测试的 3 种策略：

• 大爆炸集成：所有模块一起拼起来一次测——省事，但出了问题不知道是哪个模块的锅；

• 自顶向下：从主流程模块开始，逐层往下集成，下层没好的用"桩模块（Stub）"代替；

• 自底向上：从最底层模块开始往上拼，上层没好的用"驱动模块（Driver）"代替。

实际项目里常用混合策略：先自底向上把稳定的基础模块测牢，再往下拼。

系统测试的 7 种常见类型（系统测试不是"随便测"，是有清单的）：

功能测试、性能测试、兼容性测试、易用性测试、安全测试、安装/升级测试、文档测试（用户手册和实际功能对不对得上）。

验收测试的两种形态：

• α（Alpha）测试：在开发方场所、由内部人员模拟用户操作，开发者在场可以随时记录问题；

• β（Beta）测试：发给真实用户在实际环境使用，开发者不在场，靠用户反馈收集问题——很多 App 的"内测版/公测版"就是 β 测试。

3.2 按是否看代码：黑盒 / 白盒（3 种覆盖标准）/ 灰盒

• 黑盒测试：不看内部代码，只关心"输入 → 输出"是否符合预期。功能测试基本都是黑盒，等价类、边界值、场景法都是黑盒方法。
• 白盒测试：基于代码逻辑设计用例，多由开发做单元测试时使用。衡量"测得够不够"有 3 种覆盖标准，从弱到强：
  1. 语句覆盖：每行代码至少执行一次——最弱，一整行if (a && b)走 true 就算覆盖了，但 a、b 各自为 false 的分支没测到；
  2. 分支覆盖（判定覆盖）：每个判断的真/假分支都执行过；
  3. 条件覆盖：判断里的每个子条件取真取假都组合到。
• 灰盒测试：不看代码内部实现，但懂接口和数据结构。接口测试就是典型灰盒：你不用看代码，但要看接口文档、懂数据库。

3.3 按是否执行：静态 / 动态

• 静态测试：不运行程序——需求评审、代码走查（Code Review）、文档检查、静态代码扫描（如 SonarQube）；

• 动态测试：运行程序，输入数据看输出——日常说的"测"默认指动态。

很多人不知道"评审"也算测试，这正是 1.2 里"测试对象包括文档"的落地：缺陷越早、越静态地被发现，修复成本越低。

3.4 按执行方式：手工 / 自动化（什么适合自动化）

• 手工测试：人按用例操作。优点是灵活、能发现"意料之外"的问题；缺点是重复劳动多、回归成本高。

• 自动化测试：脚本代替人执行。优点是回归快、可反复执行、结果稳定；缺点是只能发现"意料之中"的问题（脚本只会检查你提前写好的断言），且脚本本身需要维护成本。

什么适合自动化：

1. 重复执行频率高——每次发版都要跑的回归用例；

2. 结果稳定可断言——输入固定、输出确定的场景（接口返回码、页面元素存在性）。

什么不适合自动化：

• 界面频繁改版的功能（脚本改不过来）；

• 需要主观判断的（"这个页面好看吗""文案通不通顺"）；

• 一次性功能（写脚本的时间比手工测还长）。

一个重要认知：自动化不是替代手工，是替代"重复的那部分手工"。

3.5 其他高频概念

• 冒烟测试（Smoke Testing）：版本刚提测，先快速跑一遍核心主流程，能跑通才接下做详细测试；跑不通直接"提测打回"，让开发先自测。名字来源：电路板通电先看会不会冒烟。它是质量门禁，也是测试和开发之间的缓冲带。

• 回归测试（Regression Testing）：修了 bug 或加了功能后，把相关模块甚至全量用例再测一遍，防止改动引入新问题。改动是回归风险的唯一来源——改的地方越多、越底层，回归范围越大。敏捷时代回归靠自动化，这就是自动化测试存在的核心理由。

• 探索性测试（Exploratory Testing）：不按预设用例，边设计边执行，靠经验和直觉挖掘问题。适合在用例全部执行完之后"补刀"，经常能捞到用例覆盖不到的怪 bug。

• 兼容性测试：不同浏览器、操作系统、分辨率、机型、网络环境（4G/5G/弱网）下功能是否正常。

• 安全测试：SQL 注入、XSS 跨站脚本、越权访问、明文传输、重复提交等。入门至少要会"弱密码、重复提交、水平越权（改个 id 就能看别人的数据）"这三个基础检查。

四、软件质量模型（ISO/IEC 25010，8 大特性）

"什么算高质量软件"不能凭感觉，ISO/IEC 25010 给了 8 个标准维度，测试设计时按维度找测试点：

使用技巧：不用 8 个维度平均用力，结合系统类型挑重点。测电商后台：功能性、可靠性、性能优先；测面向用户的 App：易用性、兼容性、性能优先；测金融系统：信息安全性、可靠性一票否决。

五、测试原则（7 条完整版，每条配例子和对策）

教材版本是 7 条，逐条过：

1. 测试证明缺陷存在，不能证明缺陷不存在→ 例子：登录测了 50 条用例全通过，也不能说"登录没有 bug"，只能说"已覆盖的场景没发现问题"。 → 对策：测试报告里写"用例通过率"和"遗留风险"，不写"无 bug"。

2. 穷举测试不可能→ 例子：一个接受字符串的输入框输入组合无限。 → 对策：学用例设计方法，按风险和优先级取舍覆盖范围（这就是第二篇的内容）。

3. 尽早测试（测试左移）→ 例子：需求评审发现"会员价和优惠券的叠加规则没写清楚"，当场问清只花 5 分钟；等到测试阶段发现，往返确认 + 改代码 + 回归可能要两天。 → 对策：需求评审必到，评审前先通读文档列疑问清单。

4. 缺陷聚集（二八定律）→ 例子：某个模块上一版本出了 10 个 bug，这一版本大概率还是它问题最多——bug 喜欢扎堆在逻辑复杂、历史包袱重的地方。 → 对策：把历史 bug 分布当作战地图，重点区域加密用例、优先探索性测试。

5. 杀虫剂悖论→ 例子：同一套回归用例跑了 5 个版本，能发现的 bug 越来越少——不是软件变好了，是用例"抗性"变强了。 → 对策：每个版本更新 10%~20% 的用例，定期补充探索性测试。

6. 测试活动依赖于测试上下文→ 例子：测电商看交易链路和并发，测医疗软件看重数据准确和合规，测工具类 App 看易用性。没有万能清单。 → 对策：测一个新系统前，先弄清它的业务风险在哪。

7. "没有缺陷"的谬误→ 例子：一个软件 0 bug 但根本没做用户想要的功能——完美地做了一件错事。 → 对策：测试要懂业务。确认"软件做的是正确的事"，和"正确地做事"同样重要。

六、标准工作测试流程（7 步，每步展开讲）

这是功能测试的完整工作流，逐步展开：

第 1 步：需求分析与评审做什么：通读需求文档，标记模糊、矛盾、无法验收的点，在评审会上提出。 产出物：需求疑问清单。 常见的坑：评审前不看文档，会上被动听——那评审就跟你没关系了。评审前通读 + 带着问题去，是测试建立话语权的第一步。

第 2 步：制定测试计划做什么：确定测试范围（测什么不测什么）、排期、人力分工、环境准备、风险预案。 产出物：测试计划文档。 常见的坑：排期不留 buffer。开发延期是常态，计划里要预留 20% 左右的弹性时间。

第 3 步：设计测试用例做什么：按用例设计方法（等价类、边界值、场景法等）把需求拆成一条条可执行的用例。 产出物：用例文档（Excel 或测试平台）。 常见的坑：只写正常流程。异常和边界才是 bug 高发区，正常：异常的用例比例大致在 2:8。

第 4 步：用例评审做什么：开发、产品、测试一起过用例——产品确认"预期结果对不对"，开发确认"有没有理解偏差"，测试互相补遗漏。 产出物：评审后修订的用例。 常见的坑：走过场。评审完一条不改的评审等于没开。

第 5 步：执行测试（提 bug）做什么：先冒烟测试，通过后按用例逐条执行，发现问题按模板提 bug。 产出物：bug 报告、用例执行记录。 常见的坑：冒烟不通过还硬测——主流程都跑不通，后面的用例全是无效执行，先打回。

第 6 步：回归测试做什么：bug 修复后，验证原 bug + 跑相关模块的关联用例；新功能合入后，跑核心流程回归。 产出物：回归结果记录。 常见的坑：只验证单点 bug，不跑关联模块——修登录却把注册改坏了，这种"改出新问题"（引入缺陷）是回归测试要防的头号风险。

第 7 步：输出测试报告做什么：汇总用例通过率、bug 数量与分布（按严重程度/模块）、遗留问题及风险评估，给出"建议上线 / 暂缓"的结论。 产出物：测试报告。 常见的坑：只列数字不给结论。报告的读者是项目管理者，他们要的是"能不能上"，不是 Excel 截图。

七、什么时候可以停止测试？（测试退出标准）

"测到什么时候算测完了"——不可能无限测下去，常用的退出标准（满足其一或组合使用）：

1. 覆盖率达标：计划用例 100% 执行，通过率达到约定值（如 95% 以上）；

1. 缺陷收敛：新发现的 bug 数量连续下降（一版比一版少），且无 S1/S2 级遗留；

1. 达到约定门槛：核心流程全部通过，严重 bug 清零，一般 bug 有处理方案（延期修复记录在案）。

反过来说，出现以下情况不该停止：主流程还有未通过的用例、S1 级 bug 还开着、关键模块的用例还没执行完。上线决策是整个项目组的，但测试报告里必须如实写清风险——这是测试岗位的底线。

八、练手建议与写在最后

理论篇的练手方式比较特殊——不是动手，是"输出"：

1. 把 3.1 的阶段分类、1.4 的测试 vs 调试，用自己的话讲给别人听（或者写一篇笔记）——讲不出来的就是没懂；

1. 找一个你熟悉的 App，对着第四节的 8 个质量特性，每个特性写出 1 个对应的测试点（比如对微信：功能性—消息能发出；可靠性—断网后消息重发机制）；

1. 看 2~3 个招聘网站的测试岗 JD（职位描述），把里面出现的理论名词（如"回归""冒烟""质量保障""测试左移"）都能对上号——JD 就是理论知识的实战对照表。

下一篇《手把手教你给登录页面写 20 条测试用例》把理论落到实操