ISTQB 软件测试术语速查¶

教程简介

本文用于统一软件测试基础术语。它不替代 ISTQB 官方大纲，但可以帮助新手在学习、写文档和面试时使用更专业、准确的表达。

前置要求¶

项目	要求	获取方式
软件测试理论基础	了解测试目的、测试分类、用例设计方法	软件测试理论基础教程

新手导读¶

很多新人会“会做但说不清”。例如把冒烟测试、回归测试、系统测试混在一起，把严重程度和优先级混在一起。术语速查的目标不是背定义，而是让你在沟通时减少误解。

建议学习方式：

先看中文解释，理解工作场景。
再记英文术语，方便读官方文档和面试表达。
最后看“常见误区”，避免说错。

一、测试基础概念¶

中文	英文	通俗解释	工作场景
软件测试	Software Testing	通过评估和验证降低软件质量风险	执行用例、评审需求、分析缺陷
缺陷	Defect / Bug	实际结果和期望结果不一致	登录失败、金额错误、越权访问
错误	Error	人在理解、设计或编码时犯的错	需求理解错、代码写错
失效	Failure	软件运行时表现出来的问题	页面报 500、按钮无响应
质量	Quality	产品满足需求和用户期望的程度	功能、性能、安全、易用性
风险	Risk	可能发生的问题及其影响	支付错误、数据泄露、库存超卖

常见误区：

缺陷不是只来自代码，也可能来自需求、设计、配置、数据和环境。
测试不能证明软件没有缺陷，只能降低未知风险。
没有发现 Bug 不等于质量好，可能是测试不充分。

二、测试级别¶

中文	英文	关注对象	常见负责人
单元测试	Unit Testing	函数、方法、类	开发
集成测试	Integration Testing	模块之间的数据交互	开发 + 测试
系统测试	System Testing	完整系统	测试
验收测试	Acceptance Testing	是否满足业务验收标准	产品、用户、测试

例子：

优惠金额计算函数是否正确 -> 单元测试
订单服务调用库存服务是否正确 -> 集成测试
用户从下单到支付是否正确 -> 系统测试
业务方确认活动规则是否满足上线要求 -> 验收测试

常见误区：

接口测试不等于集成测试，但接口测试经常承担集成验证的工作。
验收测试不只是点页面，也要确认业务目标是否达成。

三、测试类型¶

中文	英文	目的
功能测试	Functional Testing	验证功能是否符合需求
非功能测试	Non-functional Testing	验证性能、安全、兼容、易用等质量属性
回归测试	Regression Testing	验证修改没有破坏已有功能
冒烟测试	Smoke Testing	快速确认核心流程是否可测
探索式测试	Exploratory Testing	边学习、边设计、边执行测试
兼容性测试	Compatibility Testing	验证不同系统、浏览器、设备表现
性能测试	Performance Testing	验证响应时间、吞吐量、稳定性
安全测试	Security Testing	验证认证、授权、输入校验、数据保护
可用性测试	Usability Testing	验证用户是否容易理解和使用

对比：

类型	什么时候做	结果怎么判断
冒烟测试	新版本刚部署后	主流程是否可继续测试
回归测试	修复缺陷或改动功能后	老功能是否被影响
探索式测试	需求复杂或风险高时	是否发现脚本用例没覆盖的问题

四、测试设计技术¶

中文	英文	适合场景
等价类划分	Equivalence Partitioning	输入范围可分为有效和无效集合
边界值分析	Boundary Value Analysis	数值、长度、时间边界
判定表	Decision Table Testing	多条件组合影响结果
状态迁移测试	State Transition Testing	订单、流程、审批、支付状态
场景测试	Scenario Testing	用户完整业务流程
错误推测	Error Guessing	根据经验补充易错点

例子：

手机号必须 11 位：
等价类：空、10 位、11 位、12 位、包含字母
边界值：10 位、11 位、12 位

订单状态：
待支付 -> 已支付
待支付 -> 已取消
已支付 -> 退款中
已取消 -> 不允许支付

常见误区：

等价类和边界值不是只用于输入框，也适用于接口参数、文件大小、并发数、时间范围。
场景法不能替代异常测试，只覆盖主流程是不够的。

五、测试工作产品¶

中文	英文	用途
测试计划	Test Plan	明确范围、资源、排期、风险、准入准出
测试策略	Test Strategy	明确整体测试方法和测试类型组合
测试用例	Test Case	描述可执行的步骤和期望结果
测试数据	Test Data	支撑测试执行的数据
缺陷报告	Defect Report	记录问题、证据、影响和期望
测试报告	Test Report	汇总执行结果、缺陷、风险和上线建议

一条清晰链路：

需求 -> 测试计划 -> 测试用例 -> 测试执行 -> 缺陷报告 -> 回归验证 -> 测试报告

六、缺陷管理术语¶

中文	英文	说明
严重程度	Severity	缺陷对系统或用户的影响程度
优先级	Priority	缺陷应该多快被修复
阻塞	Blocker	导致测试无法继续或核心流程不可用
复现步骤	Steps to Reproduce	让别人能重现问题的操作过程
实际结果	Actual Result	系统现在发生了什么
期望结果	Expected Result	系统应该发生什么
回归验证	Retest / Regression Verification	修复后验证问题是否解决

严重程度和优先级区别：

场景	严重程度	优先级
支付金额错误	高	高
Logo 显示错位	低	可能低
活动页文案错别字，明天上线	低	可能高
后台低频统计报表字段错误	中	可能低

七、测试管理术语¶

中文	英文	说明
准入标准	Entry Criteria	什么条件满足后可以开始测试
准出标准	Exit Criteria	什么条件满足后可以结束测试
测试覆盖率	Test Coverage	测试覆盖需求、代码、接口或风险的程度
测试估算	Test Estimation	评估测试工作量和时间
测试监控	Test Monitoring	跟踪测试进度、缺陷、风险
测试控制	Test Control	根据监控结果调整计划和优先级
风险测试	Risk-based Testing	按风险大小分配测试资源

准入标准示例：

需求评审完成。
测试环境可访问。
开发自测通过。
冒烟用例通过。
测试数据准备完成。

准出标准示例：

P0/P1 用例全部通过。
P0/P1 缺陷全部关闭。
核心接口和主流程回归通过。
遗留风险已评估并被产品或项目负责人接受。

八、敏捷与 DevOps 术语¶

中文	英文	说明
用户故事	User Story	从用户角度描述需求
验收标准	Acceptance Criteria	判断故事是否完成的标准
持续集成	Continuous Integration	代码频繁合入并自动构建测试
持续交付	Continuous Delivery	代码始终处于可发布状态
持续部署	Continuous Deployment	通过流水线自动发布到生产
测试左移	Shift Left Testing	更早参与需求和设计评审
测试右移	Shift Right Testing	关注上线后的监控和反馈
质量门禁	Quality Gate	不满足质量条件时阻止合并或发布

例子：

测试左移：需求评审时发现“优惠券叠加规则”没写清楚。
测试右移：上线后观察错误日志、接口成功率、支付回调延迟。
质量门禁：P0 冒烟测试失败时不允许发布。

九、自动化测试术语¶

中文	英文	说明
测试脚本	Test Script	自动化执行的代码
测试套件	Test Suite	一组相关测试用例
测试夹具	Fixture	用例执行前后的准备和清理
数据驱动	Data-driven Testing	同一逻辑使用多组数据执行
关键字驱动	Keyword-driven Testing	用关键字描述测试操作
页面对象模型	Page Object Model	把页面元素和操作封装成对象
易碎测试	Flaky Test	结果不稳定、时好时坏的测试
测试报告	Test Report	展示执行结果、失败原因和附件

常见误区：

自动化不是把所有手工用例都转成脚本。
自动化不能无人维护。
UI 自动化越多，维护成本通常越高。
稳定的接口自动化通常比大量 UI 自动化更适合回归。

十、接口测试术语¶

中文	英文	说明
API	Application Programming Interface	系统之间交互的接口
请求方法	HTTP Method	GET、POST、PUT、PATCH、DELETE 等
请求头	Header	鉴权、内容类型、客户端信息等
请求体	Body	POST/PUT/PATCH 常见参数位置
状态码	Status Code	HTTP 层处理结果
业务码	Business Code	系统自定义业务结果
鉴权	Authentication	证明“你是谁”
授权	Authorization	判断“你能做什么”
幂等	Idempotency	同一请求多次执行结果一致或可控
契约测试	Contract Testing	验证服务之间接口约定是否兼容

容易混淆：

认证 Authentication：验证身份，例如登录。
授权 Authorization：验证权限，例如是否能查看别人的订单。

十一、面试表达模板¶

当面试官问“你怎么理解软件测试”时，可以这样回答：

软件测试不是简单找 Bug，而是通过需求分析、测试设计、测试执行、缺陷跟踪和风险评估，帮助团队判断产品是否满足需求、是否具备上线条件。

从测试级别看，有单元测试、集成测试、系统测试和验收测试；从测试类型看，有功能、接口、性能、安全、兼容、回归等。实际项目中我会根据业务风险和测试成本安排优先级，例如订单、支付、权限这类高风险模块会优先覆盖。

当面试官问“严重程度和优先级区别”时，可以这样回答：

严重程度表示缺陷影响有多大，优先级表示应该多快修。比如支付金额错误严重程度和优先级都高；页面文案错别字严重程度低，但如果当天要上线，优先级也可能高。

十二、参考资料¶

术语学习的最终目标不是背英文，而是让你的测试分析、缺陷报告、测试报告和面试回答更准确。