软件测试基础术语解释：新手词典_千锋教育

01 核心基石：测试入门必须打破的三个认知

你以为测试就是找bug？错。测试的目的是确认系统是否满足需求，而bug只是副产品。新手最容易混淆三组词，搞错了，面试直接挂。

缺陷（Defect） vs 错误（Error） vs 失败（Failure）

• ►错误：人写代码时脑子里的坑。比如程序员把“>”写成“<”。
• ►缺陷：代码里已经存在的坑。错误一旦被写入代码，就变成缺陷。
• ►失败：用户踩到坑了。缺陷被执行后导致系统行为异常，就叫失败。

数据说话：IBM研究显示，60%的缺陷在需求阶段就埋下了。需求写错一个字，测试测到死也救不回来。

验证（Verification） vs 确认（Validation）

• ►验证：我们做对了吗？（检查文档、代码是否符合规范）
• ►确认：我们做了对的吗？（检查最终产品是否满足用户真实需求）

一句口诀帮你记住：验证是“纸上检查”，确认是“真人验收”。

测试用例（Test Case） vs 测试场景（Test Scenario）

• ►测试用例：一条精确的指令集，包含输入、步骤、预期结果。
• ►测试场景：一个用户故事，比如“用户登录后修改密码”。一个场景可以拆成10个测试用例。

术语不是敌人，是屠龙刀。握不住，就只能被龙砍。

---

02 测试层级：从单元到验收，你的测试地图

软件测试不是一锤子买卖，而是分层射击。每个层级的目标、对象、负责人完全不同。搞混层级，等于拿着冲锋枪打蚊子。

单元测试（Unit Testing）

对象：单个函数、方法、类。

负责人：开发人员。

目标：验证最小代码单元逻辑正确。

工具：JUnit（Java）、pytest（Python）。

数据：Google统计，单元测试可捕获30%的缺陷，且修复成本最低。

集成测试（Integration Testing）

对象：模块之间的接口、数据交互。

负责人：测试人员+开发人员。

策略：大爆炸（一次全连）、自顶向下、自底向上、三明治。

血泪案例：某支付系统集成测试没做全，上线后接口超时导致资金重复扣除，损失200万。

系统测试（System Testing）

对象：完整系统。

负责人：测试团队。

类型：功能测试、性能测试、安全测试、兼容性测试。

重点：模拟真实环境，比如高并发、弱网、不同浏览器。

验收测试（Acceptance Testing）

对象：用户业务场景。

负责人：客户或业务代表。

形式：Alpha测试（内部模拟）、Beta测试（真实用户）、UAT（用户验收）。

一句话：开发说“做完了”，测试说“没问题”，用户说“你昨天不是这么说的”。

测试每高一层，发现的缺陷修复成本翻10倍。

---

03 测试设计：等价类、边界值——新手防坑两板斧

写测试用例最怕什么？怕漏。1000万条输入的登录框，你怎么测完全部？等价类划分和边界值分析就是给你省时间的数学工具。

等价类划分（Equivalence Partitioning）

原理：把输入数据分组，每组取一个代表值测。

案例：年龄输入框（0-200岁）。

• ►有效等价类：1-200（测1次）
• ►无效等价类：<0，>200，非数字，空值（测4次）

结论：原来需要测100次，现在只要5次。

边界值分析（Boundary Value Analysis）

原理：80%的bug发生在边界上。测边界值，不要测中间值。

案例：密码长度6-20位。

• ►边界点：5、6、7、19、20、21
• ►再配合等价类：5（无效下限）、6（有效最小）、7（有效内）、19（有效内）、20（有效最大）、21（无效上限）
• ►只测这6个值，覆盖99%的边界错误。

错误推测法（Error Guessing）

靠经验猜哪个环节容易出bug。比如：

• ►输入特殊字符（SQL注入）
• ►提交按钮连点两次
• ►浏览器后退键后数据状态

新手不需要猜，直接背这10条常见场景。

选对方法，一天测完别人一周的活。

---

04 缺陷生命：从发现到关闭，每一步都是钱

一个bug不是“提就完事了”，它有自己的生命周期。不懂这个周期，你会在开发和产品之间被左右打脸。

六步标准流程

1. 发现：测试执行时看到预期结果不符。

2. 提交：填写缺陷报告（标题、重现步骤、环境、截图、严重等级）。

3. 分配：测试经理派给开发组长。

4. 修复：开发改代码，并自测通过。

5. 验证：测试在最新版本上复测，确认修复。

6. 关闭：通过则关，不通过则打回。

严重程度（Severity） vs 优先级（Priority）

• ►严重程度：缺陷对系统的影响程度。比如界面错位是低，支付扣款错误是致命。
• ►优先级：修复时间要求。老板催得急就是高。

常见误区：新手往往把“界面错位”提交高优先级，而真正的致命bug被压箱底。

状态流转图（简化版）

NEW → ASSIGNED → RESOLVED → VERIFIED → CLOSED

如果开发说“无法重现”，测试必须提供更清晰的日志、视频、抓包数据。否则缺陷就会在“REJECTED”里烂掉。

一个高质量缺陷报告，能帮你省下3小时扯皮时间。

---

05 自动化与持续集成：不是必须，但你迟早要面对

新手常被“自动化测试”吓退。实际上，90%的测试工作还是手工完成的。但有些老问题只有自动机能解决：回归测试、性能测试、重复性验证。

自动化测试（Automation Testing）

适用场景：

• ►回归测试（每次上线都要跑一遍的用例）
• ►大数据量测试（比如导入10万条记录）
• ►并发测试（模拟1000人同时访问）

工具三巨头：Selenium（Web）、Appium（移动）、Postman（API）。

致命陷阱：新人喜欢把全部用例自动化，结果维护成本比手工还高。原则是“20%的用例产生80%的价值”。

持续集成（CI） / 持续交付（CD）

定义：每次代码提交后，自动拉取、编译、运行单元测试、打包、部署到测试环境。

工具：Jenkins、GitLab CI、GitHub Actions。

数据：2019年DevOps报告显示，采用CI/CD的团队部署频率比传统团队高200倍，故障恢复快24倍。

测试金字塔（Test Pyramid）

底层：单元测试（最多，最快）

中间：集成测试（中等数量，速度中等）

顶层：端到端测试（最少，最慢）

新手误区：所有精力都放在手工做端到端测试，忽略了单元测试和自动集成。结果上线前发现大量底层bug，但时间不够了。

手工测的是逻辑，自动化测的是时间。

---

术语是地图，不是终点。地图画错了，走得越远越危险。

今天的你，至少应该能分清bug和failure，知道用例怎么写，缺陷怎么提。

明天，用这些术语去面试、去写报告、去和开发吵架。

记住：懂术语的人，先拿到offer。

声明：本站部分稿件版权来源于网络，如有侵犯版权，请及时联系我们。