软件测试基础术语解释：新手词典_千锋教育
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。
