软件测试速查
测试分层与金字塔模型、用例设计方法（等价类/边界值/判定表）、自动化与接口测试、性能测试、缺陷管理与度量：测试工程速查。
测试基础与分层67 条
测试原则、单元/集成/端到端分层
单元测试（Unit Test）热门
针对函数、类或模块等小单元的测试，运行快、定位准，是金字塔底层的主要投入方向；通常由开发者在编码期编写与维护。
测试金字塔（Test Pyramid）热门
Mike Cohn 提出的分层模型：底层大量快速的单元测试、中层适量集成与服务测试、顶层少量端到端测试，用数量与成本结构指导投入分配。
端到端测试（End-to-End）热门
从用户界面或系统入口出发，贯通前后端与依赖验证完整业务链路；信心高但执行慢、失败定位成本高，适合覆盖关键业务路径。
集成测试（Integration Test）
验证模块之间、服务与外部依赖之间的协作：接口契约、数据流、事务与错误传递；介于单元与端到端之间的关键层。
回归测试（Regression Test）
验证修改没有破坏既有功能的测试活动；范围从受影响模块到全量套件不等，通常按风险与变更范围选择子集执行。
测试七原则（ISTQB）
ISTQB 大纲归纳的七条通用测试原则：测试证明缺陷存在而非不存在、穷尽测试不可行、尽早测试、缺陷聚集、杀虫剂悖论、测试依赖上下文、无缺陷谬论。
测试用例的结构与粒度
用例应包含前置条件、步骤、测试数据与预期结果四要素；粒度以一次可独立执行并得出明确判定为准，过细维护重、过粗定位难。
验收测试（Acceptance Test）
以业务视角验证系统满足验收标准的测试，决定产品能否被接受；通常在测试环境由业务方或用户代表参与执行。
缺陷修复成本随阶段上升
需求、编码、测试、生产各环节发现缺陷的修复代价整体递增：越晚发现，返工、验证与修复的连带成本越高，这是测试左移的经济性依据。
测试奖杯（Testing Trophy）
Kent C. Dodds 针对前端应用提出的投入模型：静态检查打底、单元测试适量、集成测试占比大、少量 E2E，强调用接近真实使用方式的集成测试换取信心。
测试左移（Shift Left）
把测试活动前移到需求、设计与编码阶段：评审需求可测试性、测试与开发并行设计、提交即触发自动化检查，缩短缺陷发现周期。
测试覆盖率基础
覆盖率度量测试执行了多少被测对象：代码行、分支、条件、路径与需求覆盖等；它是必要性与盲区指标，不是质量结论。
冒烟测试（Smoke Test）
对构建产物做快速的基础验证：关键功能可用、服务能启动、核心接口返回正常；失败即拒绝进入后续测试阶段。
基于风险的测试（RBT）
按发生可能性与影响程度对功能与质量属性排序，把有限测试资源投向高风险区域；风险分析贯穿计划、设计与退出的全过程。
Given-When-Then 描述规范
用给定条件、操作、预期结果三段式表达测试场景：结构清晰、可被业务阅读，适合验收标准与 BDD 场景编写。
杀虫剂悖论（Pesticide Paradox）
同一组测试用例反复运行后，发现新缺陷的能力会下降；需要定期评审与更新用例、补入新场景，才能维持检出效果。
安全测试要点（测试视角）
从测试视角验证常见安全风险不被引入：认证与会话、权限边界、输入处理、敏感数据暴露与依赖漏洞；以 OWASP 指南作为检查框架。
金丝雀发布与验证
先向小比例流量发布新版本，对比关键指标（错误率、延迟、业务转化）无异常后再逐步扩大；异常即回滚或中止，是降低发布风险的常用手段。
探索式测试（Exploratory Testing）
测试设计、执行与学习同时进行的测试方式：不预设全部步骤，以探索与反馈驱动；常用会话（Session）组织，配合章程与时间盒。
测试替身（Test Doubles）
用替代对象替换真实依赖以便隔离测试：Dummy、Stub、Spy、Mock、Fake 五类各有用途；Martin Fowler 与 xUnit Patterns 均有系统论述。
冰淇淋甜筒反模式（Ice-Cream Cone）
与金字塔相对的用例分布：大量缓慢的端到端测试、少量单元与集成测试，结果反馈慢、失败定位难、维护成本高。
质量内建（Built-in Quality）
把质量活动嵌入研发流程的每个环节：需求可测试、提交即验证、评审常态化、缺陷预防先于检出，减少依赖末端测试拦截。
测试策略与分层选择
测试策略说明为达成质量目标，各测试级别、类型与自动化程度如何组合；输入是风险、架构与交付节奏，输出是可执行的测试方案。
测试右移与生产验证
在发布后持续验证：灰度观测、金丝雀分析、线上监控与合成拨测、用户反馈闭环；生产环境是真实流量下的验证场，但需控制影响面。
测试环境分层管理
按用途划分本地、开发、测试、预发与生产环境，明确数据来源、版本部署方式与访问控制；环境差异是测试结论失真的常见来源。
测试驱动开发（TDD）
先写失败测试、再写实现让其通过、最后重构：以红-绿-重构循环驱动设计与反馈；Kent Beck 将其总结为三定律。
行为驱动开发（BDD）
用业务语言描述系统行为并驱动开发：从示例出发澄清需求，以 Given-When-Then 表达场景，使需求、测试与实现共享同一套描述。
覆盖率目标陷阱
把覆盖率当作单一目标会诱发刷数字行为：无断言测试、只为覆盖而写代码路径、忽略高价值场景；覆盖率应作为盲区雷达而非考核指标。
功能测试
验证系统功能是否符合需求规格：输入、处理与输出的正确性，业务规则与权限行为；覆盖正常路径与异常路径。
穷尽测试不可行与风险采样
除极简输入外，无法测试所有输入组合、路径与前置条件；测试本质上是基于风险的采样，需要选择能覆盖主要风险的子集。
验证与确认（V&V）
验证（Verification）回答是否按规格构建，确认（Validation）回答是否满足真实使用需要；两者关注点不同，测试策略需要同时覆盖。
组件测试（Component Test）
针对单个可独立运行组件（服务、模块、前端组件）的测试，可配合真实浏览器或容器隔离运行，比 E2E 更聚焦、比单元更接近集成。
移动端测试要点
移动应用测试需覆盖设备碎片化、系统权限、网络切换、生命周期与电量等维度；真机与模拟器结合使用，重点机型与低端机都要覆盖。
测试计划要素
描述测试范围、策略、资源、进度与风险的活动安排；ISO/IEC/IEEE 29119-3 给出文档框架，实际项目按规模裁剪为轻量清单。
静态测试与评审
不执行代码而检查工作产品：需求、设计、代码与配置的评审，配合静态分析工具；能在编码前后低成本发现缺陷。
单元测试 AAA 结构
Arrange（准备）、Act（执行）、Assert（断言）三段式组织测试代码，使意图清晰、便于维护；由 Bill Wake 提出并被广泛采用。
黑盒、白盒与灰盒测试
黑盒按外部行为设计用例（不看实现）；白盒基于代码结构设计覆盖（如分支覆盖）；灰盒结合接口与部分内部知识，常见于接口与集成测试。
非功能测试总览
覆盖性能、可靠性、安全性、兼容性、可维护性等质量属性（参考 ISO/IEC 25010 质量模型）；与功能测试互补，风险常集中在非功能维度。
测试判定基准（Test Oracle）
判断一次执行结果是否正确所依据的基准：需求规格、参考实现、历史输出、可校验的性质等；没有判定基准时只能记录输出，无法判定对错。
Alpha 与 Beta 测试
在开发方场所（Alpha）或真实用户环境（Beta）进行的预发布验证：前者受控、可观测；后者真实、噪声多，用于收集使用反馈与兼容性问题。
测试数据管理
为测试准备可控、可重复、合法合规的数据：覆盖边界与异常样本，并通过合成、脱敏、子集化等手段获得接近真实的数据分布。
单元测试 FIRST 原则
Fast（快）、Independent（独立）、Repeatable（可重复）、Self-validating（自校验）、Timely（及时）：衡量单元测试质量的五条通用标准。
测试独立性
由不同人员或角色执行测试可减少作者偏见带来的盲区；独立性从同人自查到独立组织逐级增强，但完全独立也带来沟通与归属成本。
数据库测试要点
验证数据模型、约束、事务与迁移脚本的正确性：包括 CRUD 逻辑、唯一约束、级联行为、迁移回滚与数据一致性。
特性开关测试
特性开关（Feature Flag）让未完成或实验性功能可控上线；测试需要覆盖开关开/关组合、灰度规则、过期开关清理与默认值行为。
可测试性（Testability）
系统支持被测试的难易程度：可观测性、可控制性、接口清晰度与状态可重置能力；可测试性差会让自动化与定位成本成倍上升。
代码覆盖率类型：语句、分支、条件与 MC/DC
不同覆盖准则的严格程度不同：语句覆盖最弱、判定与条件组合覆盖更强、MC/DC 兼顾强度与用例数量，常用于安全关键领域。
测试与质量保证（Testing 与 QA）
测试是面向产品的活动（执行与评估，找出问题）；质量保证是面向过程的活动（改进流程，防止问题产生）。两者互补，不能互相替代。
兼容性测试
验证系统在不同浏览器、操作系统、分辨率、设备与依赖版本组合下行为一致；重点在用户实际组合而非全量矩阵。
需求到用例的追溯（Traceability）
把需求、用例、缺陷与自动化脚本建立双向关联，用于评估覆盖完整性、影响分析与审计取证；工具中常用需求 ID 贯穿全流程。
验收测试驱动开发（ATDD）
在开发前由业务、开发、测试共同定义验收标准与验收测试，再开展实现；是协作式的需求澄清方式，与 TDD、BDD 常配合使用。
敏捷测试四象限
Brian Marick 提出、Crispin 与 Gregory 在《Agile Testing》中推广的分类：按「面向业务/技术」与「支持团队/评价产品」划分四类测试活动。
缺陷预防
通过根因分析改进流程与规范，减少同类缺陷再次发生：预防成本通常低于检出与修复成本，是质量内建的核心目标。
健全性测试（Sanity Test）
在冒烟通过后对变更相关的核心功能做窄而深的验证，判断本次修改是否值得继续深入测试；范围比冒烟窄，比回归聚焦。
测试命名与可读性
命名应表达被测行为与预期：条件 + 行为 + 结果；失败的测试名要能直接传达问题，减少翻看代码的时间。
基于属性的测试（Property-Based Testing）
描述对任意输入都成立的性质（如编码解码后等价），由框架生成大量随机输入并自动缩减反例；由 QuickCheck（Haskell）开创。
各生命周期阶段的测试活动
从瀑布到敏捷：不同模型下测试活动的组织方式不同，但尽早测试、持续反馈的原则一致；测试计划需匹配交付节奏。
评审类型（走查与技术评审等）
ISTQB 将评审分为非正式评审、走查、技术评审与正式审查：正式程度递增，适用范围与投入不同。
无障碍测试（Accessibility）
验证界面可被辅助技术（屏幕阅读器、键盘操作）使用：对比度、语义标签、焦点顺序、键盘可达性；以 WCAG 准则为检查依据。
变异测试（Mutation Testing）
通过自动修改源码（变更运算符、边界、返回值等）生成变异体，检查测试能否捕获这些人为错误，用来评估测试套件的检出能力。
本地化与国际化测试
验证多语言与多地区场景：翻译完整性、文本扩展与截断、日期/数字/货币格式、时区与排序规则、双向文字支持。
三剑客协作（Three Amigos）
由业务、开发、测试三方围绕用户故事澄清需求：业务讲价值与规则、开发讲实现与风险、测试讲边界与反例，在编码前对齐理解。
模糊测试（Fuzzing）
向程序输入大量随机或变异数据，监测崩溃、断言失败与超时：适合解析器、协议实现与安全敏感组件；覆盖驱动的模糊测试效率更高。
可用性测试（Usability Testing）
通过观察真实用户完成任务的过程评估易用性：任务完成率、耗时、错误与满意度；发现的问题常无法通过功能测试暴露。
测试依据（Test Basis）
设计测试所依据的信息来源：需求、设计、接口契约、风险分析、用户手册与法规；依据缺失会导致用例无判定标准。
测试规模分类（Small / Medium / Large）
Google 测试分类按资源占用区分：small 无网络无 IO、medium 可本机 IO、large 允许跨机器依赖；规模决定运行频率与隔离要求。
测试条件与用例的关系
测试条件（Test Condition）定义测什么，测试用例（Test Case）定义如何测；先梳理条件再落地用例，可减少重复与遗漏。
用例设计方法62 条
等价类、边界值、判定表与场景法
等价类划分（Equivalence Partitioning）热门
把输入域划分为若干等价类，每类中任取一个代表值即可代表该类行为；有效类与无效类都要划分，是黑盒用例设计的基础方法。
边界值分析（Boundary Value Analysis）
缺陷常出现在区间端点与临界点：取端点及其相邻值设计用例；边界值分析与等价类划分是互补的组合。
状态迁移测试（State Transition Testing）
系统行为由当前状态与事件决定时，用状态机描述合法迁移，再设计用例覆盖合法路径与非法迁移；适合订单、支付、工单等有状态流程。
判定表（Decision Table）
当业务结果由多个条件组合决定时，用判定表穷举条件桩与动作桩：每列一条规则，避免遗漏组合分支。
场景法（Scenario Testing）
以用户完成业务目标的完整路径为线索组织用例：主场景与扩展场景结合，贴近真实使用方式，适合验收与端到端测试设计。
接口参数边界（分页与范围）
接口参数需要覆盖缺省值、边界值（下界与上界）、越界值、类型错误与未知字段；分页接口重点测 page/size 的 0、1、上限与超大值。
无效等价类的设计要点
无效等价类验证系统在非法输入下的防御行为：报错、兜底与数据一致性；设计时每条无效类宜单独成用例，避免错误被掩盖。
成对组合测试（Pairwise Testing）
基于多数缺陷由两个参数交互触发的经验规律，生成覆盖所有参数两两组合的用例集，大幅压缩全组合规模。
数值类型边界（溢出与精度）
数值边界除业务范围外还涉及数据类型极限：int32/int64 溢出、浮点精度、负数与零、大数相加的进位。
负向测试（Negative Testing）
用非法、异常、越界输入验证系统的拒绝与容错行为；与正向测试成对设计，是鲁棒性的主要证据来源。
权限矩阵用例设计
用「角色 x 资源 x 操作」矩阵梳理权限用例：覆盖允许与拒绝、越权访问（水平/垂直）、匿名访问与权限变更后的会话。
用例参数化
把用例中的输入、环境与账号抽成参数：同一逻辑覆盖多组数据与环境，减少重复用例并集中管理测试数据。
日期与时间边界
日期时间边界密集：月末月初、年末年初、闰年 2 月 29 日、时区切换与跨天统计口径。
浮点与金额精度处理
浮点数不能精确表示多数十进制小数（0.1 + 0.2 现象）；金额与计费场景用最小货币单位或十进制类型，并用舍入用例验证规则。
字符串边界（长度与字符集）
字符串边界包括空串、单字符、长度上限与超长、多字节与组合字符（emoji、变音符号）；长度校验要注意字符数与字节数口径。
幂等性用例设计
对可重试操作（支付、创建订单）验证重复执行结果一致：同一幂等键多次请求只产生一次业务效果，并返回一致响应。
把验收标准写成 Given-When-Then
验收标准写成三段式可测试描述：明确前置条件、操作与可观察结果；编写过程能暴露需求歧义与缺失规则。
二值边界与三值边界
二值边界取端点与其相邻的外部值；三值边界同时覆盖端点内部相邻值（如 0、1、98、99、100），严格程度更高。
集合与数量边界（0/1/多）
列表、数组、集合的经典边界是 0 个、1 个、多个与数量上限：分页、批量接口与去重逻辑的高频缺陷区。
并发场景用例设计
并发缺陷难以稳定复现：设计用例时明确并发实体（用户、线程、请求）、共享资源与交错点，用屏障或同起点施压提高触发概率。
Gherkin Scenario 编写
Gherkin 用 Feature、Scenario、Given-When-Then 描述行为：一个 Scenario 表达一条规则或典型示例，供业务与自动化共用。
数据驱动测试（Data-Driven）
把测试逻辑与数据分离：脚本固定，数据来自表格、CSV 或数据库；新增覆盖往往只需增加数据行。
特殊值分析
对空白、null、默认值、零值、极值与特殊字符等输入单独设计用例：它们常触发未处理分支与显示异常。
主事件流与备选流设计
把用例（Use Case）拆成主成功场景与若干备选/异常流，每条流转化为一条可执行场景；流之间的组合关系要显式标注。
基于检查表的测试（Checklist-Based）
用维护好的检查表覆盖易错维度（权限、边界、并发、兼容性、日志等），逐项确认；适合快速评审与漏测补齐。
异常路径用例设计（依赖失败）
对每个外部依赖设计失败路径：超时、拒绝、错误响应、半途中断；验证系统降级、重试与用户提示是否符合预期。
Scenario Outline 与 Examples
Scenario Outline 用占位符参数化场景，Examples 表格提供多组数据：适合同一规则下多组边界值与等价类数据。
回归用例的选择策略
按变更影响、缺陷历史与风险等级选择回归子集：分层执行（冒烟、核心、全量），兼顾反馈速度与覆盖信心。
用例优先级与执行排序
优先级综合业务影响、风险、使用频率与变更关联：高优先级先执行，保证时间被压缩时关键验证已完成。
状态迁移覆盖准则
常见准则：覆盖所有状态、所有合法迁移、连续迁移组合（0-switch、1-switch 等）；覆盖强度与用例数量随准则上升。
错误推测（Error Guessing）
基于经验与缺陷历史，推测易出错点并针对性设计用例：如空值处理、并发、日期边界与最近修改过的模块；与系统化方法互补。
竞态与重复提交用例
竞态条件常在「检查后使用」的时间窗内出现：如余额校验通过后被并行扣减；用例设计重点是放大时间窗并观察最终一致性。
用例评审要点
用例评审检查覆盖完整性与可执行性：与需求对照有无遗漏、断言是否可判定、数据与环境是否明确、是否与已有用例重复。
等价类表的整理方式
把输入条件、等价类、代表值与用例编号整理成表格，一行一类；表格评审能快速暴露遗漏的类与重复用例。
判定表化简（合并规则）
当某些条件的取值不影响结果时，可用无关项（-）合并规则，减少用例数量并保留语义完整性。
构建状态模型的步骤
从需求与接口梳理状态清单、事件与守卫条件，绘制状态迁移图或表，标注非法迁移与超时迁移，再据此生成用例。
组合爆炸与剪枝
参数与取值增加会让组合数指数增长：用等价类合并、约束剪枝（排除非法组合）与 pairwise 控制规模，并记录剪枝依据。
PICT 生成成对组合用例
微软 PICT 工具从参数模型文件生成组合用例：支持权重、约束（IF-THEN）与多轮输出，适合落地 pairwise 设计。
约束型输入与依赖参数
参数之间存在依赖与约束（如 A 必填 B、区间不可重叠）：设计用例时先形式化约束，再生成满足与违反约束的用例。
超时与重试用例
覆盖各层超时与重试组合：客户端超时、网关超时、服务端处理超时；重点是超时后的数据一致性与用户可见状态。
非法状态迁移用例
验证在错误状态下的操作被拒绝：如已取消订单再次支付、已发货订单取消；断言操作失败且状态、数据无变化。
用例粒度权衡
粒度取决于用途：面向手工执行可稍粗、面向自动化宜细；判断标准是一条用例只验证一个明确目标，失败时可快速定位。
测试数据脱敏与合规
使用生产数据做测试前需脱敏：遮蔽姓名、证件号、手机号、银行卡等字段；优先使用不可逆映射并保留关联一致性。
判定表与组合测试的取舍
判定表适合条件组合决定业务规则（结果明确）；成对组合（pairwise）适合参数多、交互以两两为主且缺陷多由参数交互产生的场景。
因果图（Cause-Effect Graphing）
用因果图梳理输入条件（因）与输出结果（果）的逻辑关系（与、或、非），再据此生成判定表与用例；适合逻辑复杂的规格分析。
路径测试与基本路径法
基于控制流图枚举独立路径：基本路径法（McCabe）先用圈复杂度确定路径数量下界，再选择线性无关路径集合。
条件组合覆盖（白盒）
判定/条件覆盖要求每个条件的真假取值都被覆盖；条件组合覆盖进一步要求每个判定中条件取值的组合都被覆盖，强度更高。
实例化需求（Specification by Example）
用具体示例澄清与固化需求：从业务目标提炼关键示例，协作评审后作为验收标准与自动化用例的共同来源。
用例库维护与淘汰
用例是长期资产也是负债：定期清理过时用例、合并重复用例、把稳定用例转化为自动化，保持套件可信与高效。
合成测试数据生成
用工具批量生成结构化测试数据（用户、订单、地址等），支持字段规则与本地化；合成数据不含真实个人信息，适合自动化流水线。
错误提示与失败信息校验
错误信息是用体验的一部分：校验错误码、提示文案、可操作建议与日志可定位性；同时避免泄露内部实现细节。
关键字驱动测试（Keyword-Driven）
把测试步骤抽象为关键字（打开、输入、点击、断言），用例由关键字序列组成，由框架解释执行；非技术角色也可参与用例编写。
正交表与实验设计
正交表用于安排多因素多水平的组合实验：任意两列的各水平组合出现次数均衡，可用较少次数评估因素影响。
随机测试与随机化设计
按分布随机抽取输入执行测试：能在缺少精确预期时暴露崩溃与异常；随机输入应可复现（固定种子）并与其他方法组合。
输入域与输出域分析
分析合法输入域与输出值域：识别域内点、边界与域外点；对存在多个输入域交互的场景（如双参数约束）使用域测试思想。
用例复用与模板化
通过公共前置步骤、数据构造器与场景模板复用用例资产：减少重复编写，同时避免过度抽象导致理解成本上升。
分类树方法（Classification Tree）
把测试对象的输入域按分类与类逐层分解成树状结构，从各分类选取组合生成用例；适合输入结构复杂、组合维度多的系统。
循环结构测试策略
针对循环的经典策略：跳过循环、执行一次、执行两次、典型次数、上限次数与越界次数；边界次数是高频缺陷点。
图覆盖：节点、边与路径
把程序或流程抽象为有向图，用节点覆盖、边覆盖与路径覆盖度量测试充分性；流程测试、状态测试与数据流测试都可统一到图覆盖框架。
Background 的使用边界
Background 为同一 Feature 内所有场景提供公共前置步骤：适合登录、基础数据准备等；过多前置会掩盖场景差异并拖慢执行。
基于模型的测试（MBT）
用形式化模型（状态机、决策模型、流程图）自动生成测试用例：模型变更后用例可再生成，适合规格清晰的系统。
数据表与 DocString 表达
Gherkin 支持用 Data Table 传递结构化数据、用 DocString 传递长文本；两者让步骤参数结构化，适合表单与报文类场景。
自动化测试66 条
框架选型、用例稳定性与 CI 集成
pytest 入门
pytest 用普通函数加 assert 写用例：文件名匹配 test_*.py、函数匹配 test_* 自动发现；断言内省、夹具与参数化内置，插件覆盖并行、重试、覆盖率等场景。
Playwright 入门
Playwright 以单一 API 驱动 Chromium、Firefox 与 WebKit，默认自动等待并内置报告、trace 与重试；npx playwright test 运行测试，支持 TypeScript、Python、Java、.NET 绑定。
pytest fixture 夹具
fixture 用 @pytest.fixture 声明可复用的前置资源（连接、临时数据、浏览器），通过参数注入用例；scope 控制生命周期，yield 之后执行清理。
Selenium WebDriver 基础
Selenium WebDriver 通过 W3C WebDriver 协议驱动真实浏览器：创建 driver、打开页面、定位元素、执行动作与断言；语言绑定覆盖 Java、Python、C#、JavaScript 等。
pytest 参数化
@pytest.mark.parametrize 把多组数据展开成独立用例，每组单独计数、单独失败定位；ids 参数为用例命名，多层叠加时按组合（笛卡尔积）展开。
JUnit 5 入门
JUnit 5 以 @Test 标记用例，@BeforeEach/@AfterEach 做方法级准备与清理，@BeforeAll/@AfterAll（静态方法）管理类级资源；默认每个测试方法拿到新的测试实例。
Mockito 打桩与验证
Mockito 用 when(...).thenReturn(...) 定义桩行为、verify(...) 校验调用次数与参数；@Mock 创建替身、@InjectMocks 注入被测对象，配合 MockitoExtension 自动初始化。
Playwright locator 与自动等待
locator 是惰性解析的定位句柄：get_by_role、get_by_label、get_by_text 等语义定位在动作前自动等待元素可交互；断言建议使用 web-first 断言（expect(locator).to_be_visible()）。
pytest 标记（markers）筛选执行
marker 给用例打标签（smoke、slow、integration 等），用 -m 表达式筛选执行；注册 marker 可避免拼写错误被掩盖，让 CI 按标签拆分任务。
conftest.py 共享配置
conftest.py 组织共享 fixture 与钩子：按目录层级自动加载、用例无需 import；子目录同名 fixture 覆盖上层，适合按项目结构分层组织资源。
避免固定 sleep
固定 sleep 是脆弱测试的常见来源：短了等待不足、长了拖慢套件；更好的做法是等待可观测条件（元素可交互、接口返回、状态收敛），并使用框架提供的等待机制。
偶发失败的常见根因
flaky（偶发失败）的根因大致分四类：等待与同步不足、测试间状态污染、外部依赖不稳定、并发与时序竞争；治理思路是先定位类别，再谈重试与隔离。
pytest 异常断言
pytest.raises 上下文断言异常类型，match 参数用正则匹配消息；也可通过 excinfo 取异常对象继续检查属性，覆盖异常分支的验证。
pytest 并行执行（xdist）
pytest-xdist 用 -n 把用例分发到多个 worker 进程并行执行，-n auto 按核数分配；--dist 提供 loadfile、loadscope 等分发策略，可让同文件用例落到同一进程。
JUnit 5 参数化测试
@ParameterizedTest 配合 @ValueSource、@CsvSource、@MethodSource 等数据源把同一逻辑跑多组输入；@CsvSource 适合表格化数据，@MethodSource 适合复杂对象。
Selenium 显式等待
Selenium 显式等待（WebDriverWait 加 expected_conditions）轮询直到条件成立或超时；相比固定 sleep 更精确，超时报错也带上等待条件与时长。
Playwright Trace 回放
Trace Viewer 记录执行快照、DOM、网络与控制台信息，可按时间轴回放；生成方式为配置 trace 选项或 CLI 参数，npx playwright show-trace trace.zip 查看。
pytest 断言内省
pytest 允许直接写 assert，失败时自动展开表达式内省：标量比较显示两侧值，容器比较显示差异项；无需记忆专门的断言方法名。
pytest monkeypatch 临时替换
monkeypatch 夹具在用例范围内临时替换属性、字典项与环境变量，用例结束后自动还原；适合隔离时间、网络地址与外部依赖。
JUnit 5 断言
JUnit 5 断言集中在 org.junit.jupiter.api.Assertions：assertEquals、assertTrue、assertThrows、assertAll 等；assertAll 会执行完所有断言再汇总报告，减少「修一个跑一次」的往返。
用例隔离
用例隔离指任意用例都能单独运行、以任意顺序运行并得到一致结果：不共享可变状态、不依赖执行顺序、不残留数据；这是并行与重试能够成立的前提。
定位器稳定性策略
定位器稳定性从高到低大致是：专用测试属性（data-testid）、用户可见语义（role、label、文本）、稳定 id/name、结构化的 CSS 路径；随构建变化的自动生成 class 不宜作为依据。
Playwright 网络拦截与桩数据
用 page.route 拦截并改写请求：返回桩数据、修改响应、模拟 500/超时或限流，用于前端边界验证；HAR 文件也可作为网络记录的固定回放源。
pytest tmp_path 临时目录
内置夹具 tmp_path 为每个用例提供独立的 pathlib 临时目录，结束后自动清理；适合下载、导出、配置文件等落盘类验证，不污染工作区。
pytest 配置文件
pytest 配置集中在 pytest.ini、pyproject.toml 的 [tool.pytest.ini_options] 或 tox.ini；常用项包括 testpaths、addopts、markers、filterwarnings 与日志设置。
pytest-mock 的 mocker 夹具
pytest-mock 提供 mocker 夹具封装 patch/spy，随用例自动清理；相比手写 unittest.mock 上下文样板更少，且能与 fixture 系统组合。
等待策略（显式/隐式/自动）
三类等待各有适用面：显式等待针对指定条件、隐式等待影响所有元素查找、自动等待由框架在动作前自行同步；混用会引入不可预测的等待叠加。
Page Object 模式
Page Object 把页面元素定位与操作封装成类，用例只调用业务动作（如 login(user, pwd)）；页面改版时定位集中修改，用例层保持稳定。
自动化可行性判断
决定一条用例是否值得自动化：看执行频率、稳定性、回报周期与维护成本，而不是「能写脚本就自动化」；每次构建都要回归的稳定场景通常是优先项。
测试中的密钥管理
测试用的账号、令牌与密钥应通过环境变量或密钥管理注入，不提交进仓库；本地用 .env（列入 .gitignore），CI 用平台密钥变量，测试代码只引用变量名。
失败现场的采集
失败现场信息决定排错效率：截图、页面快照、视频、网络请求记录、服务端日志与容器日志；CI 上按失败用例归档为构件，并在报告里给出直达链接。
Playwright 测试夹具
Playwright 自带夹具体系（page、context、browser、request），也支持自定义 fixture 与项目配置；测试之间默认隔离 context，相当于每个用例独立会话。
视觉回归测试
视觉回归通过截图对比发现样式级变化：首次运行生成基线，之后逐像素或按结构比对；Playwright 提供 toHaveScreenshot，工具生态中也有专门的视觉测试服务。
JUnit XML 报告格式
JUnit XML 是 CI 消费测试结果的通用格式：pytest 用 --junitxml 输出，Java 生态多为 surefire/failsafe 报告；CI 平台据此渲染失败列表与历史趋势。
测试框架的组成
测试框架通常由五部分组成：用例发现与组织、夹具与资源配置、断言与等待、执行调度（并发/重试/分片）、报告与 CI 集成接口；选型时逐项对照团队需求。
pytest 失败重跑
pytest-rerunfailures 提供 --reruns 失败自动重跑与 --reruns-delay 间隔控制，也可只对标记用例生效；重跑能缓解环境抖动，但不该静默忽略根因。
Testcontainers 真实依赖容器
Testcontainers 用一次性 Docker 容器提供真实依赖（数据库、消息队列、Redis），测试结束即销毁；可结合 JUnit 的 @Testcontainers/@Container 或语言侧 API 启停。
Playwright codegen 录制
codegen 录制用户操作并生成脚本骨架：playwright codegen <url> 打开浏览器输出操作代码，适合快速起草与提取定位器；生成结果仍需人工整理结构并补充断言。
storageState 复用登录态
storageState 把登录后的 cookie 与 localStorage 序列化保存，用例启动时加载即可跳过重复登录；生成方式为登录一次后保存，或在 codegen 中导出。
Cypress 基础
Cypress 在浏览器内运行测试：cy 命令链内置重试与自动等待（默认命令超时 4000ms），提供时间旅行调试与网络拦截；运行器与页面同环境，调试链路贴近前端开发。
浏览器矩阵
浏览器矩阵是在多个浏览器与版本组合上执行用例（Chromium、Firefox、WebKit 或企业内标准浏览器），用项目配置一次声明；并非所有用例都需要全矩阵执行。
Allure 测试报告
Allure 汇总测试结果生成可读报告：支持步骤、附件、参数化数据与失败分类；常见用法是从测试框架输出结果目录，生成 HTML 报告并在 CI 或静态站点发布。
变更影响测试选择
变更影响测试选择：依据本次改动涉及的文件与依赖关系挑选回归子集，缩短反馈时间；Google 的预测性测试选择用历史数据训练模型，实践上也可以先用文件映射的启发式实现。
JUnit 5 分组与标签
@Nested 把测试类组织成内部分组、@DisplayName 给出可读名称、@Tag 打标签供构建工具筛选；组合使用让报告层次接近业务结构。
JUnit 5 生命周期与超时
JUnit 5 生命周期回调分方法级（@BeforeEach/@AfterEach）与类级（@BeforeAll/@AfterAll）；@TestInstance(PER_CLASS) 让类级回调免写 static，@Timeout 给用例设置执行时长上限。
测试数据工厂
测试数据工厂（Object Mother/Builder）把「构造一份合法数据」的代码集中管理，用例只声明差异字段；数据需求变化时改一处而不是几十个用例。
Playwright 接口请求上下文
Playwright 的 request 夹具（APIRequestContext）可在同一套用例里直接调用后端接口：准备数据、验证副作用、串起 UI 与 API 的混合流程，无需额外 HTTP 客户端。
Playwright 失败重试
Playwright 在配置里设置 retries 次数：失败用例自动重跑并在报告中标记为 flaky；配合 trace: 'on-first-retry' 可以先拿到重试时的完整现场。
Playwright 并行与分片
Playwright 默认按文件并行执行（workers 数量可配）；CI 用 --shard=1/3 把套件切到多个作业并行，缩短反馈时间；分片之间数据与账号必须隔离。
CI 测试缓存
CI 里缓存依赖与工具链能缩短测试准备时间：缓存键用「操作系统加锁文件哈希」，区分只读缓存（PR）与回写缓存（主分支）；测试结果的用例级缓存需要评估正确性风险。
过度打桩的问题
过度打桩让用例与实现细节强耦合：调用顺序、内部方法名变化都导致失败，而真实回归价值有限；务实的边界是只隔离外部依赖（网络、时间、随机），业务逻辑用真实对象。
Appium 移动端自动化
Appium 基于 WebDriver 协议扩展出移动端自动化：用 capabilities 指定平台与设备（platformName、deviceName、app），Android 走 UiAutomator2、iOS 走 XCUITest 驱动。
MSW 请求拦截（Mock Service Worker）
MSW 在网络层拦截请求：浏览器端通过 Service Worker、Node 端通过拦截器，前端开发与测试共用同一套 handler 定义，不需要为测试单独维护一套 mock 层。
CI 测试产物的归档
测试产物（报告、日志、截图、trace、覆盖率文件）按作业上传为构件：命名带上运行号与用例标识便于检索；只保留失败用例的现场，兼顾存储成本与排错需求。
自动化投入回报（ROI）
自动化收益来自高频重复执行与快速反馈，成本包含搭建、编写、调试与长期维护；比较时把「单次节约时间 x 执行次数」与「持续维护投入」放在同一口径。
JUnit 5 扩展模型
JUnit 5 通过 @ExtendWith 注册扩展点（BeforeEachCallback、ParameterResolver、TestExecutionExceptionHandler 等），实现依赖注入、条件执行与自定义重试等能力。
顺序依赖的发现与治理
顺序依赖的典型信号：单独运行失败、整体执行通过；治理方法是查明共享状态来源（数据、单例、登录态、端口），改为自建自清，并在 CI 中用随机顺序持续暴露。
Selenium Grid 分布式执行
Selenium Grid 把测试分发到多个机器与浏览器节点并行执行，本地用 Docker 即可起一套 hub 加 node 的拓扑；适合浏览器矩阵与跨平台组合，环境维护成本需要预先评估。
偶发用例的隔离流程
隔离（quarantine）流程：确认 flaky 的用例先移出阻塞门槛（标记或迁入独立套件），记录责任人与期限；隔离数量与滞留时长都应纳入跟踪。
无头模式与有头调试
无头模式在 CI 上默认运行（Playwright 默认无头，Selenium 可用 --headless 参数），本地调试切有头模式观察；两种模式的字体、GPU 与时区差异需要在 CI 配置里对齐。
WireMock HTTP 桩服务
WireMock 以 HTTP 桩服务替身外部接口：用 JSON 映射声明「请求匹配加响应返回」，可模拟延迟、错误与各类状态码；Java 生态常用，也支持独立进程与容器方式运行。
Pact 契约测试
Pact 属于消费者驱动契约测试：消费方为每个交互生成契约文件，提供方用契约回放做验证；契约经 Broker 发布与比对，避免双方对接口的假设脱节。
Python unittest 基础
标准库 unittest 以 TestCase 类组织用例并提供断言方法族，python -m unittest discover 支持目录发现；pytest 能直接收集运行 unittest 用例，便于渐进迁移。
Mockito 严格桩检查
Mockito 的 strict stubs 默认检查两类问题：定义了从未被调用的桩（UnnecessaryStubbingException）与参数不匹配的调用；严格模式把无效打桩尽早暴露出来。
Playwright 时间控制（Clock）
Clock API 控制页面内时间：clock.install() 冻结初始时间，setFixedTime/fastForward 推进时间，用于验证倒计时、免打扰时段与缓存过期等时间相关逻辑。
视觉基线的管理
基线管理策略：基线变更随代码评审一起审阅，仅在确认属于预期改动后才更新（如 --update-snapshots）；不同操作系统与浏览器生成的基线分目录存放。
接口与性能测试66 条
API 测试、压测指标与瓶颈定位
HTTP 状态码速查
常用状态码：200/201/204 成功族、301/302/304 重定向与缓存、400/401/403/404/405/409/422/429 客户端错误、500/502/503/504 服务端错误；断言应区分具体状态码而不是「不等于 200 就失败」。
延迟分位指标
延迟看分位：P50 中位体验、P90/P95 常见服务目标、P99 反映长尾；平均值会掩盖长尾。报告中应同时给出分位数值与采样窗口口径。
接口测试清单
接口测试的常规覆盖面：正向与参数组合、鉴权与越权、错误码与错误体、边界与畸形输入、并发与幂等、限流、依赖异常（超时与降级）、数据一致性、契约与文档一致性、日志与可观测字段。
压测类型对照
压测类型对照：负载（预期峰值下验证）、压力（逐步加压寻找拐点）、尖峰（瞬时突增验证弹性）、浸泡（长时间运行查泄漏）、容量（新环境与基线对比）；先写清目标再选类型。
JMeter 基础组件
JMeter 以线程组（Thread Group）为核心：线程数、Ramp-up 与循环次数描述负载；采样器发请求、断言校验响应、配置元件参数化、监听器收集结果。正式压测建议只用命令行。
HTTP 方法语义与幂等性
方法的语义与幂等：GET/HEAD 安全且幂等，PUT/DELETE 幂等（重复执行结果一致），POST 非幂等；PATCH 语义依接口定义。自动重试策略必须围绕幂等性设计。
接口鉴权与授权测试
鉴权与授权测试矩阵：无凭证（401）、无效凭证（401）、有效但无权限（403）、对象级越权（换 ID 访问他人资源）、令牌过期、签名错误、最小权限核对。
curl 接口调试
curl 是接口调试的基本工具：-i 看响应头、-d/-H 构造请求、-w 输出耗时指标、-f 让服务端错误码变成命令失败、-sS 静默但保留错误信息；排查 401 与 429 时常用。
requests 与 pytest 接口测试
requests 加 pytest 是常用的接口测试组合：Session 复用连接、显式超时、断言状态码与响应体、json 解析；封装 client 统一 base_url、鉴权头与超时，用例只表达业务意图。
瓶颈定位方法
瓶颈定位自顶向下：先确认压测机不是瓶颈，再看被测服务的 CPU/内存/GC/线程池，然后检查依赖（数据库、缓存、下游），最后回到链路（网络、代理、DNS）。
接口异常与边界用例
接口异常用例：缺失必填、类型错误、超长与特殊字符、越界数值、未知字段、重复提交、并发修改、鉴权过期与伪造；异常输入应有确定的错误码与可解析的错误体。
平均延迟陷阱
请求延迟通常呈长尾分布：平均值达标不代表体验达标，少数慢请求会显著抬高 P99 却拉不动平均值。对外承诺与内部告警都应基于分位指标。
幂等键测试
幂等键（Idempotency-Key 或业务去重键）让重试安全：同一键的重复请求应返回首次结果或明确冲突，并发下仅生效一次；支付、订单与回调类接口的测试重点。
负载曲线设计
负载曲线设计：载入方式（阶梯、瞬时、波浪）、目标量级（峰值 RPS 或并发用户数）、持续时间、恢复阶段；曲线要能在报告中一眼读出「何时加压到多少」。
RPS 与并发口径
RPS（每秒请求数）与并发是两种口径：闭环（固定并发）下 RPS 随响应时间变化，开环（固定到达率）才能精确控制负载强度；选哪种取决于要回答的问题。
k6 基础
k6 用 JavaScript 描述负载：默认导出函数是一次迭代，options 定义虚拟用户与阶段，check 与 threshold 内建；单二进制运行，便于 CI 集成。
JSON Schema 响应校验
JSON Schema 校验响应结构：类型、必填字段、枚举、格式与嵌套约束；比逐字段断言覆盖更完整，字段新增不破坏，字段缺失或类型变化立即暴露。
JMeter 命令行执行
JMeter 命令行执行：jmeter -n -t plan.jmx -l result.jtl -e -o report/；-l 记录原始结果、-e 与 -o 生成 HTML 报告；CI 中应统一使用非 GUI 模式。
延迟 SLI 与 SLO
把性能目标写成 SLI/SLO：如 95 分位延迟、错误率与可用性，并绑定统计窗口考核；压测、监控与告警共用同一套指标口径，结论才能互相印证。
压测反模式清单
压测反模式清点：压小数据求好看数字、只看平均不看分位、压测机先到瓶颈、无思考时间、失败请求计入吞吐、脚本与真实行为差异大、结果不可复现。
压测报告结构
压测报告结构：目标与范围、环境与数据说明、负载曲线、关键分位与吞吐、错误分类、资源占用、瓶颈分析与结论边界；附脚本与数据版本，保证可复现。
Postman 与 Newman
Postman 组织请求集合与环境变量，Newman 让集合在 CI 中命令行执行：newman run 集合文件 -e 环境文件 --reporters；适合快速搭建接口回归集合与冒烟。
OAuth2 流程测试
OAuth2 授权码流程的测试要点：授权跳转与 state 校验、回调换 token、scope 最小化、令牌过期与刷新、撤销后失效；测试环境使用独立 client 与固定回调地址。
限流测试
限流测试：确认算法与维度（IP、用户、接口、令牌桶或固定窗口）、阈值、超限返回 429 与 Retry-After、恢复时间；并发压测可同时观察限流与熔断的联动。
k6 阈值（thresholds）
k6 把性能目标写成阈值：如 http_req_duration 的 p(95)<500、http_req_failed 的 rate<0.01；不达标时 k6 以非零码退出，可直接作为 CI 门禁。
数据库瓶颈识别
数据库瓶颈信号：慢查询、锁等待、连接池耗尽、主从延迟、缓存命中率下降；压测中结合慢日志、执行计划与连接池、锁等待指标，区分 SQL 问题与容量问题。
性能基线与回归
性能基线：在稳定环境定期跑固定脚本，把关键分位与吞吐记录为基线，新版本对比基线；趋势比单次绝对值更有价值，超阈值即预警。
接口延迟分解
把端到端延迟拆成 DNS 解析、TCP 连接、TLS 握手、等待首字节（TTFB）与内容传输几段；curl 的 -w 变量或浏览器 DevTools 都能给出分解，定位到阶段后改进方向才明确。
JWT 令牌测试
JWT 测试要点：签名算法校验（拒绝 none 与算法混淆）、exp/nbf 时间窗、aud/iss 校验、密钥轮换后的兼容、错误令牌返回 401；载荷可解码但不可被信任。
JMeter 定时器与断言
定时器控制节奏：固定定时器、高斯随机定时器、恒定吞吐量定时器（按目标吞吐控制发送）；断言（响应断言、持续时间断言、JSON 断言）把「只发请求」升级为「带验证的压力测试」。
Core Web Vitals 指标
Core Web Vitals 是面向用户体验的指标：LCP（加载）、INP（交互响应）、CLS（布局稳定）；常用良好阈值 2.5 秒、200 毫秒、0.1，监控以真实用户数据（CrUX）为准。
压测结果解读顺序
解读压测结果先核对三件事：错误率是否受控（否则延迟与吞吐无意义）、压测机资源是否先到瓶颈、负载是否达到目标量级；之后再分析分位分布与阶段对应关系。
压测脚本设计
压测脚本设计要点：参数化（账号、查询键）、关联（从响应提取动态值供后续请求使用）、事务边界（把业务动作合并为事务）、幂等与清理、脚本与真实行为的差异登记。
OpenAPI 契约校验
以 OpenAPI 文档为契约做双向校验：校验实现与文档一致（Dredd、Schemathesis 类工具），同时用文档生成用例；文档与实现漂移时应让测试直接失败而不是默默放过。
思考时间（think time）
思考时间模拟用户操作间隔：缺少它会制造不真实的请求密度；JMeter 用定时器、k6 用 sleep、Locust 用 wait_time 实现，取值应贴近真实用户的行为分布。
k6 指标与 check
区分 check 与 metric：check 记录通过率但不中止执行，阈值与指标用于判定；内建指标含 http_req_duration、http_req_failed、vus、iterations；自定义指标用 Trend/Counter/Gauge/Rate 表达业务量。
CPU 瓶颈识别
CPU 瓶颈识别：观察用户态与系统态占比、上下文切换、运行队列长度；用 top、pidstat 与 perf 采样（火焰图）确认热点在业务逻辑、框架还是序列化。
压测环境保真度
压测环境保真度：硬件规格、网络路径、数据规模、中间件版本与参数、依赖形态都要登记；结论只在该环境范围内成立，差异项写入报告与结论边界。
容量规划
容量规划：以业务峰值为目标，结合单实例容量、冗余与故障域推算实例数；包含安全余量与扩容时间评估，并定期用压测校准，而非一次拍板。
Lighthouse 页面评估
Lighthouse 对页面做实验室评估：性能、可访问性、工程实践与 SEO 四类分数；性能项含 FCP、LCP、TBT、CLS 等指标，可在 Chrome DevTools、CLI 或 CI 中运行。
接口测试数据管理
接口测试数据管理：用例自建数据（带随机后缀避免冲突）、用后清理或事务回滚、直连数据库核对副作用、不依赖他人固定数据；批量场景关注数据量与清理成本。
压测错误分类
压测错误分类与预算：区分系统错误（5xx）、超时、被限流（429）与业务拒绝；只有前三类计入可用性折损，报告分列并给阈值，避免混在一起看总数。
浸泡测试与泄漏检测
浸泡测试长时间运行以捕捉内存泄漏、连接泄漏与句柄增长：监控 RSS、堆、连接数与线程数随时间的斜率，周期性尖峰再结合 GC 与定时任务解释。
REST Assured 基础
REST Assured 是 Java 接口测试的常用 DSL：given/when/then 结构、链式配置参数与请求头、JsonPath 断言响应；与 JUnit 或 TestNG 集成后在 CI 中执行接口回归。
利特尔法则（Little's Law）
利特尔法则：L = λ x W，即系统中的平均请求数等于到达率乘以平均停留时间；用于在并发、RPS 与响应时间之间换算，估算压测所需并发与容量上界。
GC 与延迟尖峰
JVM 应用的 GC 常是延迟尖峰来源：关注停顿频率与时长、堆占用曲线、晋升与元空间；调优前先用 GC 日志确认停顿与业务延迟的时间对应关系。
下游依赖瓶颈
下游依赖瓶颈：第三方接口延迟、重试风暴、熔断与降级策略、连接建立开销；压测时把下游桩化并注入可控延迟，才能区分「自身慢」与「被拖慢」。
压测数据规模
数据规模决定压测意义：记录数、热点分布、索引与分区状态、缓存命中率；用等比例脱敏数据或数据生成器构造，避免小数据快、上线即慢。
性能门禁（CI）
性能门禁：在流水线里跑冒烟级压测（核心接口固定曲线），把分位与错误率阈值作为合并条件；全量压测留在发布前或按周期执行，避免流水线拥堵。
连接复用对压测的影响
连接复用（keep-alive、连接池）显著影响压测数据：不复用时每请求含握手开销，测的是连接建立能力；多数场景应复用连接，并核对客户端池上限与并发目标匹配。
接口挡板环境
挡板（stub/mock）环境替身难以控住的外部依赖：支付网关、短信、第三方接口；用规则配置响应、延迟与错误码，验证降级、超时与重试路径；上线前需与真实服务联调对齐。
加压与降压策略
加压策略决定结论解读方式：阶梯加压寻找拐点、瞬时加压验证弹性、平台期测稳定性；降压阶段同样重要——观察负载退去后系统能否回到健康水平。
WebSocket 接口测试
WebSocket 测试要点：握手（101 与 Upgrade 头）、消息收发与顺序、心跳与重连、断线补发、消息大小上限与背压、鉴权过期后的行为；客户端可用 websocat、浏览器控制台或框架内置客户端。
JMeter 分布式压测
JMeter 分布式压测：一台控制机协调多台负载机（jmeter-server）共同施压，用于突破单机瓶颈；前提是版本、脚本与数据文件统一，并核对各负载机时钟。
Locust 基础
Locust 用 Python 定义用户行为：HttpUser 与 @task 描述任务与权重、wait_time 控制思考时间、Web UI 实时观察；适合与 Python 技术栈共用代码与工具链。
wrk 快速压测
wrk 是轻量 HTTP 压测工具：-t 线程、-c 连接、-d 时长、--latency 输出延迟分布；适合对单接口快速摸底，配合 Lua 脚本可参数化与自定义上报。
GraphQL 接口测试
GraphQL 测试要点：单端点 POST、query/mutation/subscription 三类操作、变量与类型校验、字段级鉴权、错误对象结构、部分成功（data 与 errors 并存）、查询深度与复杂度限制。
压测工具选型
压测工具选型维度：协议支持（HTTP/2、gRPC、WebSocket）、脚本与数据能力、分布式负载、报告与阈值、CI 集成、团队技术栈；先用小场景验证再上规模。
协调遗漏（coordinated omission）
协调遗漏：压测工具在目标时间点未发出请求时，会把这段等待从统计中剔除，导致延迟被系统性低估；用固定并发闭环模型记录时尤其明显，应按到达率发送或校正计时。
gRPC 接口测试
gRPC 测试要点：用 .proto 生成客户端桩、校验状态码（INVALID_ARGUMENT、NOT_FOUND、DEADLINE_EXCEEDED 等）、metadata 鉴权、deadline 与取消、流式（server/client/bidi）行为。
尖峰测试实践
尖峰测试：短时间把负载拉到峰值，观察错误、排队、熔断与自动扩缩容行为，以及负载退去后的恢复时间；重点是弹性与保护机制的有效性，而不是稳态吞吐。
扩展性测试
扩展性测试验证加资源后的性能画像：水平扩实例、垂直扩规格、读扩展（副本与缓存）；记录资源翻倍时吞吐与延迟的变化，评估线性程度与新瓶颈出现的位置。
HAR 与请求瀑布分析
HAR（HTTP Archive）记录页面全部请求的时间线：按域名聚合、分析瀑布图中的阻塞关系与慢请求；浏览器 DevTools 可导出 HAR，也常用作缺陷报告的证据附件。
Karate 接口测试 DSL
Karate 用 Gherkin 风格语法编写接口测试：feature 文件直接描述请求与断言，内建 JSON 解析、并行执行与报告；不写 Java 代码即可开始，适合团队快速共建接口用例。
Gatling 基础
Gatling 基于 Scala DSL 描述场景：scenario 与注入剖面（rampUsers、constantUsersPerSec）、check 校验、内建 HTML 报告；适合需要细腻注入曲线的 JVM 团队。
ab（ApacheBench）快速压测
ab 以 -n 总请求数、-c 并发数快速压测：输出吞吐、平均延迟与分位分布，并给出失败统计；适合快速冒烟与版本间对比，不适合复杂会话与长时压测。
缺陷与测试管理62 条
缺陷生命周期、测试报告与度量
缺陷报告的要素
缺陷报告要素：标题（现象加模块）、环境与版本、前置条件、复现步骤、期望结果与实际结果、证据（日志、截图、请求响应）、影响范围与出现频率。
严重程度与优先级
严重程度（Severity）衡量缺陷对系统的影响，优先级（Priority）决定修复的先后；两者相互独立：崩溃但影响面小可能优先级低，文案错误出现在关键入口也可能优先级高。
缺陷生命周期
缺陷生命周期：新建（New）到分派（Assigned）、处理中（Open）、修复（Fixed）、待复测（Ready for Test）、验证（Verified）、关闭（Closed），验证不通过则重开（Reopened）。
error、defect 与 failure 的区别
ISTQB 术语区分：error（人的失误）、defect/fault（代码或文档中的缺陷）、failure（运行时的失效表现）；缺陷可以长期潜伏而不立即引发失效，测试通过不等于不存在缺陷。
测试退出准则
退出准则在测试计划阶段预先定义：执行与通过比例、遗留缺陷分级与数量、关键风险覆盖情况、回归完成度等。达到准则是进入发布评审的前提，避免用「测得差不多了」代替判断。
度量的古德哈特定律
当指标成为目标，它就不再是好的度量：考核用例数会催生小颗粒用例，考核缺陷数会诱发少报与拆小，考核覆盖率会出现只写不断言。对策：度量面向系统改进、组合使用、接受抽查校验。
测试工作量估算
测试估算常用比例法（按开发工作量比例折算）、外推法（基于历史数据）、德尔菲与三点估算。估算给出区间与假设，随需求变化滚动修正；把假设写下来比单点数字更重要。
测试总结报告
测试总结报告面向干系人：范围与版本、环境与限制、执行结果、缺陷与遗留、度量数据、风险评估与结论建议。数字服务于结论，报告要能支撑发布与否的决策。
DORA 四指标
DORA 研究用四项指标观察交付效能：部署频率、变更前置时间、变更失败率、故障恢复时间。测试与它们直接相关：前置时间包含测试等待，失败率反映拦截与验证质量；用于改进而非个人考核。
缺陷分级会议（triage）
缺陷分级会议：按影响、频率、修复成本与发布窗口决定处理顺序；输入是证据完整的报告，输出是结论（修复、延期、关闭）与责任人、期限。
缺陷关闭判定
关闭判定：在修复版本上按原步骤与最小复现验证通过、补齐边界与相邻路径验证、更新关联回归用例、回填修复提交与验证证据；验证人不宜是修复人本人。
测试度量陷阱
常见陷阱：把缺陷数直接用于个人考核、指标成为目标后被优化（Goodhart 效应）、只收集不解读、口径频繁更换。度量的目的应是支撑决策与改进，并且需要定性信息交叉验证。
测试进度监控
进度监控对照计划跟踪执行与通过趋势、缺陷发现与修复趋势、阻塞项与外部依赖；发现偏差时触发控制动作：调整范围、增加资源、升级风险或调整时间。关键是偏差早暴露、动作有记录。
质量成本
质量成本框架把质量投入分为预防成本、评估成本与失败成本（内部与外部）。用它与上线后失败成本做对比，是向管理层沟通测试价值的常用方式；数字用于量级判断，不适合当精确会计。
无责复盘
无责复盘聚焦系统与流程而非个人：梳理时间线、影响、根因与放大因素，提出可跟踪的行动项；目标是让信息充分流动、避免同类事故复发。SRE 实践把复盘文化视为可靠性的基础环节。
缺陷环境信息采集
缺陷环境采集：构建号与提交、部署形态、浏览器与系统、账号与角色、数据快照、依赖状态、网络条件；把采集清单做成脚本或模板，减少来回沟通。
缺陷重开
重开（reopen）治理：常见原因三类——修复未覆盖根因、复测环境差异、需求理解偏差；重开率是过程质量信号，应按原因分类跟踪，而不是按人统计追责。
缺陷密度
缺陷密度：缺陷数与规模单位（千行代码、故事点、功能点等）的比值，用于观察模块质量与测试充分性。规模口径必须统一，跨语言、跨团队对比前先确认可比性。
质量门禁
质量门禁：流水线中对关键检查的自动判定（测试通过率、覆盖率阈值、静态扫描、性能基线等）。门禁宜少而硬，每一条都有明确的失败处理与豁免审批通道，否则会被绕过或退化为形式。
三点估算
三点估算取乐观（O）、悲观（P）、常见（M）三个值：三角分布期望约 (O+M+P)/3，贝塔分布（PERT 常用）约 (O+4M+P)/6。用于把不确定性显式化，适合测试任务与迭代容量估算。
测试视角的 DoR 与 DoD
DoR（进入就绪）与 DoD（完成定义）是团队工作协议：需求进迭代前有可测的验收标准，任务完成前有测试证据与缺陷收敛；测试参与定义这两道门，能减少开发末期才发现需求不可测的返工。
ISO/IEC 25010 质量模型
ISO/IEC 25010 定义软件产品质量特性：功能性、性能效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性（2011 版八项，后修订版本有调整与增补）。用特性清单检查非功能测试覆盖，避免只测功能。
测试文档体系
测试文档按用途分层：方针与策略（组织级）、计划（项目/版本级）、用例与检查单（执行级）、记录与报告（证据级）。轻量团队可以合并文档，但决策依据与证据两类内容不建议省略。
敏捷仪式中的测试活动
把测试活动嵌入敏捷仪式：计划会评估可测性与测试任务、每日站会暴露阻塞、评审会演示验收、回顾会改进质量实践；测试不是迭代末尾的独立关卡，而是贯穿始终的活动。
质量文化
质量文化体现在日常行为：问题被早报告不被惩罚、复盘对事不对人、质量目标纳入团队而非只压测试、测试债务像技术债务一样被管理；Google 的测试实践强调质量人人有责，而非独立检查关卡。
最小复现
最小复现：逐步删除与现象无关的输入与操作，保留能稳定触发问题的最短步骤；缩减过程本身常能暴露根因，缩小后的步骤也便于固化为回归用例。
缺陷延期（defer）的标准
延期决策标准：影响可接受且有替代路径、修复风险高于缺陷影响、目标窗口不具备修复条件；延期必须登记影响范围、临时规避方案与复查时间。
5 Whys 根因分析
5 Whys：沿现象连续追问「为什么」，直到落在可行动的过程或系统原因；用于缺陷与事故的根因分析，结论应对应改进项，而不是归咎个人。
缺陷逃逸率
逃逸率：发布后发现的缺陷与同期缺陷总量之比，用于评估测试拦截效果与发布风险。口径需要固定：什么算逃逸（环境/配置类如何归类）、观察窗口多长、以哪个环境为基线。
MTTR 与恢复度量
MTTR（平均恢复时间）衡量从故障发生到服务恢复的耗时，用于评估应急与修复能力。起点（告警、确认、用户可见影响）与终点（服务恢复、修复上线）必须先定义，同一口径才能比较。
发布就绪评审
发布就绪评审（go/no-go）在发布前汇总质量证据：测试完成情况、遗留缺陷与风险、变更影响面、回滚预案、监控与值守安排。测试、开发、运维与业务共同参与，结论与例外项留档。
缺陷趋势报告
趋势报告关注曲线形状：新增与修复是否收敛、未关闭存量是否受控、重开率反映修复质量、按模块分布找热点。发布前仍持续高发现率，往往说明范围或质量尚未稳定。
测试管理工具选型
测试管理工具（TestRail、Zephyr、Xray 等）承载用例库、执行记录、覆盖与报告。选型先看团队工作方式与现有工具栈（是否围绕 Jira），再评估用例复用、导入导出与 API 能力，避免资产被锁定。
热修复流程与测试
热修复走精简但不省略的流程：从主线切修复分支、控制变更范围、针对性验证加相关回归、快速评审后发布并持续监控，最后合回主线。修复本身也要沉淀用例，防止同类问题再次回归。
UAT 组织与协调
UAT（用户验收测试）由业务方在准生产环境执行，测试团队提供环境、数据、脚本与缺陷通道支持。要点：明确的进入条件、业务场景覆盖、反馈节奏与缺陷分级约定，避免 UAT 沦为形式化签字。
测试与开发协作
高效协作模式：测试早期介入需求与设计评审、缺陷报告聚焦可复现与证据、开发提测前自测、环境问题共同定位；用「质量是团队的事」替代「测试把关」的对抗心态。
修复验证与回归范围
缺陷修复验证分两层：确认原问题复现路径已修复（用例加反向用例），再评估变更影响面确定回归范围（同模块、共享组件、关联接口）；回归范围由风险决定，不由改动行数决定。
生产缺陷回灌
生产缺陷是改进测试的直接输入：每个逃逸缺陷复盘类别与漏网环节，转化为新用例、检查单或自动化信号；定期统计回灌覆盖率，让用例库随真实世界演化，而不是冻结在设计阶段。
非缺陷与需求偏差
非缺陷处理：先与需求方核对预期（需求文档、原型、接口文档与线上行为），确认属于预期行为时转为需求变更或文档更新；结论与依据要留痕，避免重复讨论。
帕累托分析
帕累托分析：缺陷常集中在少数模块或类型，按分布排序后把改进资源投向头部；同时关注样本窗口与分类口径，避免被单次版本波动误导。
缺陷检测百分比（DDP）
DDP：测试阶段发现缺陷数除以测试阶段与发布后窗口内缺陷数之和，衡量测试拦截比例。发布后窗口（如 30 天）需要事先约定，窗口未结束时不计算结论。
Jira 中的测试管理
在 Jira 中管理测试：缺陷用问题类型与工作流承载；测试用例可用专用管理插件（Xray、Zephyr 等）挂到需求与版本；关键是字段与状态对齐团队工作协议，避免自定义字段无序膨胀。
测试复盘
测试复盘在版本或里程碑结束后进行：对比计划与实际、评估估算准确性、提炼有效与低效的测试活动、更新检查清单与用例库；产出改进项进入下一迭代待办并跟踪闭环。
测试签字确认
签字（sign-off）是对发布决策的确认，而不是责任的转移：签字前应有明确的权利义务边界、退出准则核对结果、遗留缺陷与风险清单、回滚预案；信息不完整时应拒绝或附加条件签字。
TMMi 测试成熟度简介
TMMi（测试成熟度模型集成）把测试过程改进分为五级：初始、已管理、已定义、已测量、优化。用于给组织的测试实践做基线评估与渐进改进，可与 CMMI 配合使用，评估本身不是目的。
测试外包
测试外包指把部分测试活动交给外部团队（人力外派或整包交付）。要点：明确交付物与验收标准、知识转移与访问权限、缺陷质量约定、知识产权与数据合规；甲方保留发布决策与关键风险测试能力。
测试沟通与汇报
测试沟通面向不同读者调整粒度：管理层要结论与风险（能否放行、什么在冒烟），开发要证据与复现，支持要规避方法；坏消息尽早说，带着数据与选项（推迟、限制范围、带风险发布）一起说。
回滚演练
回滚能力需要演练验证：数据迁移类变更能否安全回退（备份点、双写、兼容窗口）、旧版本对新数据的兼容性、回滚时长与操作步骤；演练结果写进发布预案，而不是事故时才首次尝试。
重复缺陷的处理
重复缺陷处理：登记前先检索（标题关键词、模块、日志片段），确认重复后关联并保留主单；对高频重复主题做专题排查，而不是逐条关闭了事。
鱼骨图（因果图）
鱼骨图把影响因素按类别展开：制造语境是人、机、料、法、环、测；软件语境常按需求、设计、编码、测试、环境、数据；先发散收集候选原因，再收敛验证。
缺陷排除效率（DRE）
DRE：交付前各环节（评审、测试）排除的缺陷占（交付前+交付后）全部缺陷的比例，用来评估整体质量活动而非单一测试环节；与 DDP 一样依赖固定窗口与缺陷归类口径。
已知问题清单
已知问题清单（Known Issues）面向支持与客户沟通：收录已确认、暂不修复或待排期的问题，说明影响、规避方法与计划；由测试与产品共同维护，随版本发布更新。
测试排期
测试排期把测试活动对齐发布计划：确定里程碑、环境窗口、数据准备、回归周期与人员投入；给依赖项（上游提测、第三方接口）留提前量，排期冲突时按风险优先级取舍，而不是压缩回归。
不修复与延后决策
不修复（won't fix）与延后（defer）是主动决策而非放弃：需要记录理由（成本高于收益、设计如此、后续版本处理）、影响评估与责任人，并同步给支持与产品；决策进缺陷库可检索，避免重复讨论。
度量基线与改进
度量改进先建立基线：用数个可比版本的历史数据确定当前水平（逃逸率、缺陷密度、构建时长等），再定改进目标与观察窗；没有基线的目标（如提升百分比）无法验证，也容易引发数据失真。
测试证据与审计
受监管或审计场景需要可追溯证据：谁、何时、对哪个版本、执行了什么、结果如何；执行记录、缺陷流转、审批痕迹要能串起来对应需求与发布。工具选择时优先考虑完整留痕与可导出。
缺陷大扫除（bug bash）
bug bash：集中时段组织跨角色探索测试，围绕新功能、边界与真实场景找缺陷；配套主题清单、环境准备、现场分级与跟进机制，成果进入缺陷流程。
缺陷龄期
缺陷龄期：缺陷从创建（或开始处理）到关闭（或当前）经历的时间。观察分布而不是只看平均：中位数看常态，长尾条目需要逐条检查卡点（等待澄清、等待环境、等待修复窗口）。
宽带德尔菲估算
宽带德尔菲：多位专家匿名独立估算，汇总后对离群值展开讨论，再轮估算直至收敛。匿名避免权威压迫，讨论让分歧暴露，适合跨团队对测试范围与工期达成共识。
分布式测试团队
分布式团队（时区、语言、文化差异）下，测试协作依赖异步沟通与显式约定：交接文档化、环境集中管理、术语表统一、决策留痕；重叠时段用于同步高风险话题而非日常流水同步。
测试预算与资源规划
测试预算覆盖人力、环境、工具与自动化维护；规划时区分一次性投入（环境搭建、框架建设）与持续成本（用例维护、执行集群、许可），用质量成本与风险视角排序削减目标，避免先砍回归与维护预算。
ODC 缺陷分类
ODC（正交缺陷分类）从多个正交维度给缺陷打标签：触发、类型、目标、影响、来源、龄期；结构化分类后可以回答缺陷从哪来、在哪里集中、如何预防。