为什么要分这么多类

软件出问题的方式很多，所以测试方法也多。业界常用"测试金字塔"来理解：底层是量大、便宜、跑得快的单元测试；中间是接口与集成；顶层是少量、贵、慢的端到端测试。下面按类别把常见方法逐一讲清楚，每种方法都给一个具体例子，方便照着做。

单元与底层

最靠近代码本身的一层，性价比最高，应该最先做、最常做。

单元测试Unit Testing

底层最快

• 测什么
• 最小可测单元（一个函数或方法）在给定输入下产出正确输出。
• 怎么做
• 对每个函数写断言，覆盖正常输入、边界输入、异常输入；依赖项用 mock 隔离。
• 工具
• JUnitpytestJestGo test
• 例子
• 一个计算折扣的函数 calcDiscount(price, rate)，传 (100, 0.9) 断言返回 90；传 (100, 0) 断言返回 100；传负数断言抛异常。
• 注意
• 只验证"没崩"不算测过；为了凑覆盖率写无意义的断言没价值。

组件 / 模块测试Component Testing

中层

• 测什么
• 一个独立组件（如一个微服务、一个前端页面模块）在隔离环境下的行为，比单测大、比系统集成小。
• 怎么做
• 把组件跑起来（自带内部依赖，外部依赖 mock），验证其对外接口与内部逻辑。
• 例子
• 一个"用户资料"微服务，mock 掉数据库，验证它对外提供的查询、更新接口在正确/错误参数下的表现。

集成测试（含 API 集成）Integration Testing

中层集成

• 测什么
• 多个模块、服务、外部系统（数据库、消息队列、第三方 API）连起来后的协作是否正确。其中最常做的是 API 集成测试，重点抓运行时 500 错误——那种编译通过、单测通过，一联调就崩的情况。
• 怎么做
• 逐步接入真实依赖（数据库、MQ），验证数据流与控制流；或直接调用真实接口，断言状态码与数据结构。
• 工具
• Postmanpytest+requestsREST AssuredJMeter
• 例子
• 调用"创建订单"接口后立刻"查询订单"，断言返回 200 且金额一致。若库存服务未启动，这里就会暴露 500，而不是等用户下单才崩。
• 注意
• 把集成测试当单测用（mock 掉所有依赖）就失去了"集成"意义；测试库与生产库不一致会制造假绿。

系统测试System Testing

整体

• 测什么
• 把整个系统当黑盒跑，验证是否满足需求规格：功能、性能、安全、兼容整体达标。
• 怎么做
• 在准生产环境部署完整系统，按需求文档逐条验收式地测。
• 例子
• 需求写"首页加载不超过 2 秒"，就在准生产环境实测首页 P95 延迟是否达标。

验收测试Acceptance Testing（Alpha / Beta）

验收用户视角

• 测什么
• 用户觉得能不能用、对不对胃口。Alpha 是内部或友好用户测，Beta 是真实用户小范围测。
• 怎么做
• 按用户故事、验收标准走查，收集真实反馈。
• 例子
• 按验收标准"用户能用手机号注册并登录"，完整走一遍注册登录流程，确认无阻碍。
• 注意
• 只看功能不看体验，会漏掉真正影响使用的细节；Beta 没留回收反馈的渠道等于白测。

接口、数据与契约

Web 系统上线前最容易翻车的地方，集中在前后端对接和数据一致性上。

接口路径对账（契约测试）Contract Testing

契约前后端

• 测什么
• 前端调用的地址、参数名、字段结构，和后端实际提供的契约是否对得上。
• 怎么做
• 前后端基于同一份接口定义（OpenAPI/Swagger）生成校验，或把前端真实请求的地址集合与后端路由表比差异。
• 工具
• PactSwagger/OpenAPIApifox
• 例子
• 后端把返回字段 userId 改成 uid 却没通知前端，前端取 userId 全是 undefined——契约测试能在联调前报警。
• 注意
• 契约写完不更新、或只在文档里写不校验，等于没契约。

CRUD 闭环验证Data Consistency

数据一致性

• 测什么
• 增删改查整条链路：Create→Read→Update→Delete 之后，数据库里存的是不是"你以为的那个值"。
• 怎么做
• 写一条→读出来比对→改一下→再读比对→删掉→确认查不到；跨表时还要验证外键、级联、事务回滚。
• 例子
• 把用户昵称从"A"改成"B"，前端显示 B，但直接查库发现还是 A——说明更新接口没落库或落错字段。
• 注意
• 只断言 HTTP 200 不查库等于没验证；事务未提交或脏读会让你看到假数据。

数据库测试Database Testing

数据

• 测什么
• 约束、索引、触发器、存储过程、迁移脚本的正确性，以及数据迁移不丢不错。
• 怎么做
• 针对迁移脚本跑前后比对，对触发器/函数写专项用例。
• 例子
• 给表新增"年龄"字段并加 CHECK 约束（0~150），迁移后用非法值插入应被拒绝。
• 注意
• 只在 ORM 层测不测底层约束，会漏掉数据库层面的规则；迁移脚本没在等价数据量下验证有风险。

缓存一致性Cache Coherence

缓存一致性

• 测什么
• 写完数据库后，缓存是否跟着更新或失效，避免"改了看不见、刷新才出现"。
• 怎么做
• 写数据→立刻读（走命中缓存的路径）→断言读到的是新值；或写入后强制失效再读。
• 工具
• 接口脚本加直接查 Redis，redis-cli
• 例子
• 改了商品价格，缓存没清，用户看到的还是旧价——写后读验证能抓到。
• 注意
• 测试时缓存被关了（本地没开 Redis）上线才暴露；双写顺序不对会导致不一致。

UI 与端到端

更贴近"用户眼睛看到的世界"，成本高但能验证完整业务流。

浏览器自动化UI / E2E via Browser

UI端到端

• 测什么
• 真实浏览器里页面能不能点、能不能填、跳转对不对、渲染正不正常。
• 怎么做
• 脚本驱动无头浏览器，模拟点击、输入、等待元素出现，断言页面状态、文案或 URL。
• 工具
• SeleniumPlaywrightCypressPuppeteer
• 例子
• 登录后断言页面出现"欢迎，张三"且右上角头像可点；若前端路由写错会停在空白页。
• 注意
• 等元素要用显式等待，sleep 硬等既慢又不稳定；选择器太脆一改版就红。

端到端用户旅程E2E User Journey

端到端流程

• 测什么
• 把多步串成"用户真实走完的一段路"：注册→登录→下单→支付→查看订单，确保整条业务流不断点。
• 怎么做
• 用浏览器自动化或接口串联，按真实顺序走完，断言每个关键节点状态正确。
• 例子
• 下单成功但支付回调没写回订单状态，用户永远看到"待支付"——单步测试看不出，整条旅程才暴露。
• 注意
• E2E 最慢最脆，别用它覆盖所有细节（那是单测的活）；数据没清理会互相污染。

兼容性测试Compatibility Testing

兼容

• 测什么
• 不同浏览器、系统、设备、分辨率、网络下表现是否一致。
• 怎么做
• 真机或云真机矩阵，或按浏览器兼容列表逐一验证核心功能。
• 工具
• BrowserStackSauce Labs
• 例子
• 核心下单流程在 Chrome、Safari、Edge 以及一台低端安卓机上各走一遍，确认都能完成。
• 注意
• 只在 Chrome 测、忽略老旧浏览器和低端机，上线容易踩坑。

响应式 / 跨端测试Responsive / Cross-device

移动

• 测什么
• 页面在手机、平板、桌面不同宽度下布局是否错乱、元素是否可点。
• 怎么做
• DevTools 设备模拟加真机，断言关键元素可见可交互。
• 例子
• 在 375px 宽度下，提交按钮不被键盘遮挡、不被挤出屏幕外。

可用性测试Usability Testing

体验人因

• 测什么
• 真实用户能不能毫不费力地完成任务、找得到按钮、不迷路。
• 怎么做
• 请用户边做任务边出声思考，观察卡点在哪。
• 例子
• 让新用户在不看说明书的情况下完成"找回密码"，记录卡在第几步。
• 注意
• 找开发人员自己测会感觉不到难；样本太少容易以偏概全。

可访问性测试Accessibility (a11y)

无障碍

• 测什么
• 视障、听障、行动不便用户能否使用：对比度够不够、能否键盘操作、有无 alt 文本、读屏是否通顺。
• 怎么做
• 按 WCAG 标准扫描，再加读屏软件实测。
• 工具
• axeLighthouse a11yNVDA
• 例子
• 纯键盘 Tab 能否到达所有按钮和链接；图片是否有替代文本。
• 注意
• 纯靠自动化扫描只能抓约三成问题；忽略键盘可达性是常见遗漏。

权限与安全

越权、会话、注入、渗透，这一类出问题往往最直接、后果最重。

多角色交叉测试（越权）Role / Permission Testing

权限安全

• 测什么
• 不同角色（游客、普通用户、管理员）能不能访问不该访问的接口或页面。越权是最常见的安全事故之一。
• 怎么做
• 同一操作分别用不同身份调用；尝试改 URL 里的 id 访问他人数据（水平越权），尝试直接调管理员接口（垂直越权）。
• 例子
• 用户把请求里的 orderId=100 改成 999（别人的订单），接口若不校验归属就会泄露他人隐私。
• 注意
• 只在 UI 上把按钮藏起来、后端不校验等于没防；只测"能不能进页面"没测"接口本身能不能越权调"。

登录态穿透测试Session / Auth State

会话安全

• 测什么
• 登录态（token/session/cookie）在各种情况下是否"该失效的失效、该保留的保留"：过期、注销、多端互踢、token 被盗用。
• 怎么做
• 用过期 token 调接口应 401；注销后旧 token 应失效；验证多设备登录策略。
• 例子
• 用户点了退出，但抓到的旧 token 还能继续调接口——会话没真正注销，存在被盗用风险。
• 注意
• 只在"已登录"路径测，没测"退出/过期后"；token 长期不过期等于一把永久钥匙。

安全测试（注入 / XSS / CSRF）Security Testing

安全专项

• 测什么
• SQL 注入、NoSQL 注入、XSS 跨站脚本、CSRF 跨站请求伪造、敏感信息泄露。
• 怎么做
• 在输入点注入 ' OR 1=1--、<script> 等载荷，检查是否被转义或拦截。
• 工具
• OWASP ZAPBurp SuiteSonarQube
• 例子
• 在搜索框输入 ' OR '1'='1，若返回了全部数据说明存在 SQL 注入；输入 <script>alert(1)</script> 提交后若原样回显说明有 XSS。
• 注意
• 只防了 GET 没防 POST；前端转义了后端没转义；把安全寄托在"用户不会乱来"。

渗透测试Penetration Testing

安全攻击视角

• 测什么
• 模拟真实黑客，从外部尝试突破系统，找组合漏洞和没想到入口。
• 怎么做
• 授权下做信息收集→漏洞利用→提权→横向移动，产出渗透报告。
• 例子
• 对对外网开放的后台登录页做弱口令与已知漏洞扫描，评估能否进入内网。
• 注意
• 未经授权扫描他人系统属于违法；一次性渗透不代表以后安全。

模糊测试Fuzz Testing

安全异常

• 测什么
• 用大量随机、畸形输入轰炸程序，看会不会崩溃、内存泄漏、死循环，专门抓想不到的边界。
• 怎么做
• 对接口或解析器喂随机字节流，监控进程是否挂掉。
• 工具
• AFL++libFuzzergo-fuzz
• 例子
• 对图片上传接口喂入损坏的、超大的、非图片格式的二进制文件，确认服务不崩溃。

异常、容错与资源

用户不按套路出牌，或系统局部出故障时，能不能顶住。

异常输入测试Boundary / Negative Input

边界健壮性

• 测什么
• 空值、超长、负数、特殊字符、非法格式、超大文件等边界场景。
• 怎么做
• 等价类划分加边界值分析：刚好在边界、越过边界、空、超长各造一条，看返回友好提示还是 500 堆栈。
• 例子
• 年龄填 -1 或 99999、昵称填 10000 个 emoji、手机号填字母——系统应拦截并提示，而非写入脏数据。
• 注意
• 只在正常流程里测等于没测；前端拦了就以为后端也拦了（后端必须独立校验）。

错误处理测试Error Handling

容错健壮性

• 测什么
• 系统出错时表现是否体面：有没有吞异常、有没有把堆栈甩给用户、有没有兜底默认值。
• 怎么做
• 主动制造故障：断网、杀依赖服务、传坏数据、制造超时，看降级、重试、提示的表现。
• 例子
• 支付网关超时时，订单应进入"处理中"而非直接报错消失；用户看到"稍后查询"而非白屏。
• 注意
• catch 了异常却空处理（silent fail）会把问题藏起来；错误信息把 SQL、路径泄露给用户。

静态资源检查Static Asset Check

资源完整性

• 测什么
• 页面引用的 JS/CSS/图片/字体/图标是否真的存在、能加载、没被构建漏掉或路径写错。
• 怎么做
• 构建后扫描产物目录，比对 HTML 引用的资源是否都存在；或用爬虫抓取页面收集资源 URL 批量校验 200。
• 工具
• webpack-plugin
   完整性校验、Playwright 收集网络请求、自写校验脚本
• 例子
• 部署时 hash 文件名变了，旧 HTML 还引用 app.abc.js，新包里是 app.xyz.js——页面白屏，静态资源检查能提前抓到。
• 注意
• 只在本地 dev 测（dev 不哈希）上线才暴露；CDN 缓存导致旧资源 404。

性能

快慢、稳不稳、能撑多少，这一类回答"扛不扛得住"。

性能基线测量Performance Baseline

性能基线

• 测什么
• 关键接口、页面在正常运行压力下的响应时间、吞吐量，建立一条基线，以后变慢能立刻发现。
• 怎么做
• 单接口压测取 P50/P95/P99 延迟，记录基线数值，后续每次对比。
• 工具
• JMeterwrkk6Gatling
• 例子
• 首页接口基线 P95=300ms，某次发版后变成 1500ms——性能回归被基线卡住。
• 注意
• 只测并发 1 的响应时间没测高并发；环境不同（笔记本对服务器）基线不可比。

负载测试Load Testing

性能

• 测什么
• 在预期峰值并发下系统是否稳：响应时间、错误率、资源占用是否达标。
• 怎么做
• 逐步加压到预估峰值并持续一段时间。
• 工具
• JMeterk6Locust
• 例子
• 预估日常峰值 1000 QPS，加压到 1000 并持续 10 分钟，观察错误率与 CPU 是否平稳。
• 注意
• 压测机本身成了瓶颈；只盯响应时间不监控后端资源。

压力测试Stress Testing

性能极限

• 测什么
• 超过极限的流量下系统怎么死、怎么恢复，找崩溃点和降级能力。
• 怎么做
• 持续加压直到报错或宕机，再撤压看能否自愈。
• 例子
• 把并发从 1000 一路加到 5000，记录系统在哪一点开始报错，撤压后能否自动恢复。

并发测试Concurrency Testing

性能

• 测什么
• 多用户同时操作同一资源时有没有竞态条件：超卖、重复扣款、计数错误。
• 怎么做
• 并发发起同一请求（如同时抢同一张票），检查最终一致性。
• 例子
• 库存只剩 1 件，同时发 10 个下单请求，最终成交不应超过 1 单。
• 注意
• 单线程测永远正确；没加锁/事务会导致超卖。

耐久性 / 稳定性测试Endurance / Soak Testing

性能长时

• 测什么
• 长时间（几小时到几天）稳定运行下是否出现内存泄漏、连接池耗尽、性能衰减。
• 怎么做
• 中等负载跑很久，监控内存、连接、响应曲线。
• 例子
• 以 200 QPS 连续跑 24 小时，观察内存曲线是否持续上涨不回落。

容量测试Capacity Testing

性能

• 测什么
• 系统最大能撑多少（用户数、数据量），为扩容规划提供依据。
• 怎么做
• 不断增加负载或数据量，找到拐点。
• 例子
• 逐步增加数据量到千万级，观察查询延迟在哪一级开始陡增。

工程化与静态分析

不运行程序也能发现问题的手段，适合放进持续集成常驻。

静态代码分析Static Code Analysis

静态不运行

• 测什么
• 不运行代码，靠规则扫描：空指针风险、未关闭资源、代码坏味道、安全漏洞模式。
• 怎么做
• CI 里接入扫描器，PR 阶段就报警。
• 工具
• SonarQubeESLintSpotBugsgolangci-lint
• 例子
• 扫描发现某处打开文件后没有关闭，或使用了已知不安全的加密算法，提前在合并前拦下。
• 注意
• 规则太严满屏告警会被无视；只扫不修没意义。

代码覆盖率Code Coverage

度量

• 测什么
• 测试用例跑到了多少代码（行、分支、函数覆盖），是"测够没"的量化指标，不是质量本身。
• 怎么做
• 插桩跑测试，生成覆盖率报告，设阈值卡 CI。
• 工具
• JaCoCopytest-covIstanbul
• 例子
• 设分支覆盖率门禁为 70%，低于此值合并被拒绝。
• 注意
• 为覆盖率写"假测试"；高覆盖率不等于没 bug（没断言的逻辑分支跑到了也白搭）。

代码评审Code Review

人协作

• 测什么
• 靠人眼发现自动化抓不到的：设计不合理、边界没想全、命名歧义、安全隐患。
• 怎么做
• PR 双人评审，按功能、安全、性能、可维护性清单检查。
• 例子
• 评审中发现一段逻辑在月末结算时会除零，自动化测试恰好没覆盖到这个日期。
• 注意
• 流于形式"LGTM"完事；评审太晚（大改写完才看）成本高。

部署、配置与容灾

上线过程和出事后能不能恢复，这一类常被忽略却很要命。

配置测试Configuration Testing

配置

• 测什么
• 不同配置（开关、环境变量、特性开关）下行为是否正确，默认值是否安全。
• 怎么做
• 枚举关键配置组合，验证开关生效、不互相冲突。
• 例子
• 关闭"新支付通道"开关后，下单应走旧通道；开启后应走新通道且回退逻辑可用。
• 注意
• 测试环境开了某个 flag、生产没开，行为不一致。

安装 / 部署测试Installation / Deployment Testing

部署

• 测什么
• 安装包、部署脚本能不能顺利装上、升级、回滚；首次启动是否自检查。
• 怎么做
• 在干净环境跑安装、升级、回滚全流程。
• 例子
• 从 v1.0 升级到 v2.0 后再回滚到 v1.0，确认数据兼容、服务正常。
• 注意
• 只在"已经装过"的机器测；没测回滚（回滚失败最致命）。

备份与灾难恢复测试Backup / DR Testing

容灾保命

• 测什么
• 备份能不能真恢复、恢复要多久、丢了多少数据（RPO/RTO）。很多团队"以为有备份"实则恢复不了。
• 怎么做
• 定期演练：删库/切机房→按预案恢复→校验数据完整性。
• 例子
• 按计划演练一次数据库恢复，记录从故障到业务恢复耗时，核对丢失的数据量。
• 注意
• 从不演练，真出事才发现备份是坏的；恢复时间远超业务容忍。

国际化与发布运维

上线前的小检查，以及上线后持续保障的手段。

国际化与本地化测试i18n / l10n Testing

国际化

• 测什么
• 多语言、多时区、多币种、日期/数字格式是否正确；译文是否截断、RTL 语言是否错版。
• 怎么做
• 切换语言、地区，检查文案、布局、时区换算。
• 例子
• 切到阿拉伯语后界面应从右到左排列；切到英语后日期应显示 MM/DD 而非 DD/MM 造成歧义。
• 注意
• 硬编码中文；德语长单词撑破按钮；时区算错导致"明天变昨天"。

冒烟测试Smoke Testing

健康快

• 测什么
• 每次构建后先跑一批最关键路径，确认系统没炸、能开机。
• 怎么做
• 挑 5~10 个核心用例（登录、首页、核心接口），全绿再往下细测。
• 例子
• 部署后先自动跑"能登录、首页能开、核心接口返回 200"，通过才通知测试人员介入。
• 注意
• 冒烟用例太多失去"快"的意义；长期不更新会过时。

健全测试Sanity Testing

健康

• 测什么
• 针对某次局部修改做合理性快速验证，确认这一块没明显问题再深测。
• 怎么做
• 改了支付模块，就快速点一遍支付相关功能。
• 例子
• 修复了导出功能后，先快速验证导出能成功、文件能打开，再展开格式边界测试。
• 注意
• 和冒烟常被混用；区别是冒烟看"整体能不能开"，健全看"某块改完合不合理"。

回归测试Regression Testing

回归持续

• 测什么
• 改了代码后，原来好用的功能有没有被改坏。
• 怎么做
• 把历史用例沉淀成回归套件，每次发版自动跑。
• 例子
• 改了登录逻辑后，回归套件自动重跑"注册、找回密码、第三方登录"等历史用例。
• 注意
• 用例只增不减越跑越慢；不维护导致误报一堆后被无视。

探索性测试Exploratory Testing

人灵活

• 测什么
• 不按脚本，靠测试人员经验和直觉边学边测边改，专找脚本测不到的诡异路径。
• 怎么做
• 定时间盒（如 30 分钟），带着怀疑自由操作并记录发现。
• 例子
• 随意快速连续点击提交按钮，看会不会重复提交或界面卡死。
• 注意
• 完全不记录导致无法复现；被当成"随便点点"。

基于风险的测试Risk-based Testing

策略优先级

• 测什么
• 不平均用力，把精力放在"出事概率高 × 影响大"的地方。
• 怎么做
• 给功能打分（概率×影响），优先测高分项。
• 例子
• 支付、权限得分最高优先测；头像背景得分低，自动化带过即可。
• 注意
• 风险评分拍脑袋；忽略"小概率但毁灭性"的项（如数据丢失）。

混沌工程Chaos Engineering

韧性主动故障

• 测什么
• 在生产或准生产主动注入故障（杀节点、断网络、加延迟），验证系统是否真弹性自愈。
• 怎么做
• 定假设→注入故障→观察→收敛，从小范围、可恢复的开始。
• 工具
• Chaos MeshGremlinNetflix Chaos Monkey
• 例子
• 随机杀掉一个订单服务实例，观察流量是否自动转移到其他实例、用户无感知。
• 注意
• 没设止血开关就乱炸生产；把混沌当玩具不回顾结论。

金丝雀 / 蓝绿发布测试Canary / Blue-Green

发布渐进

• 测什么
• 新版本先放一小撮流量（金丝雀）或并行一套环境（蓝绿），对比错误率、性能，确认安全再全量。
• 怎么做
• 1% 流量切新版本，监控指标无异常再逐步放大；异常即回滚。
• 例子
• 新版本先放 1% 用户，对比错误率与延迟无异常后放大到 100%。
• 注意
• 金丝雀比例太大失去保护意义；没对比指标就全量。

可观测性与监控测试Observability / Monitoring

运维

• 测什么
• 系统出问题时能不能看得见：日志、指标、链路追踪是否齐全，告警是否真响。
• 怎么做
• 故意造一个故障，验证监控大屏、告警、链路是否如预期呈现。
• 工具
• PrometheusGrafanaJaegerELK
• 例子
• 手动让某个接口报错率升高，确认告警在规定时间内触发、值班收到通知。
• 注意
• 告警太多被静音；没有指标等于盲飞。

A/B 测试A/B Testing

业务决策

• 测什么
• 两个或多个版本哪个效果更好（转化、留存、点击），用数据而非直觉做决策。
• 怎么做
• 随机分流，做统计显著性检验，得出胜出版本。
• 例子
• 首页按钮红绿两版各放 50% 流量，一周后对比点击率，保留胜出版本。
• 注意
• 样本太小就下结论；同时改多个变量分不清因果。

全部方法速查表

按类别排好，方便查阅。层级：底=金字塔底层（多、快、廉），顶=端到端（少、慢、贵）。

全用一遍的效果

把上面这些方法在一次发布前全部跑一遍，相当于给系统做一次极尽详细的出厂体检。它能大幅提升当次发布信心、暴露大量显性问题，但并不等于持续的质量保障，也覆盖不了所有长尾风险。

能做到的

• 覆盖面极广：
  从代码逻辑、接口契约、数据一致、UI、权限、异常、性能到安全、容灾、发布，几乎无死角。
• 建立质量基线：
  性能基线、覆盖率、冒烟用例、回归套件一次性沉淀下来，后续可复用。
• 显著提升当次发布信心：
  全检后，已知类型缺陷逃逸率会大幅下降。
• 暴露跨层问题：
  "单测绿、集成崩""接口对、UI 错""功能对、性能崩"这类组合缺陷，只有全套一起跑才暴露。
• 倒逼契约显式化：
  接口对账、配置测试会逼着把隐藏约定写出来。

做不到的

• 一次性不等于持续：
  代码一改，缺陷会重新引入。全检只代表那一刻的质量快照。
• 成本极高、耗时极长：
  45 种全手动跑一遍，人力与时间可能以周计，无法每次发版都做。
• 覆盖率不等于正确性：
  高覆盖、全跑过，仍可能漏掉没想到的业务场景和组合爆炸里的长尾 bug。
• 真实流量难模拟：
  性能、并发、混沌即使做了，也和真实生产流量有差距。
• 安全是动态的：
  一次性渗透、扫描只能发现已知模式，新漏洞每天都在出。
• 全绿可能制造假安全感：
  用例设计得弱（只断言 200 不断言值），全过也不代表没问题。

效果预期（经验参考）

结论：全用一遍是必要但不充分的。真正的质量靠的是把适合自动化的（单测、接口、回归、静态分析、性能基线）固化进持续集成持续跑，把需要人脑的（探索性、可用性、验收、渗透）定期做，再用混沌、监控、金丝雀兜住生产期的未知。