按开发阶段划分软件测试类型
阶段划分单元测试->集成测试->确认测试->系统测试->验收测试 单元测试编码完成后，测试最小功能单元(函数、类、模块)是否正确 集成测试单元测试之后，测试模块之间的接口、交互是否正确 确认测试组件集成后、系统测试前，验证软件是否符合规格说明书(SRS),也叫验证测试 系统测试整个系统开发完成后，对整个系统进行功能、性能、安全等全面测试 验收测试上线前，用户验证系统是否满足业务需求，α\alphaα测试、β\betaβ测试
软件质量管理之QM、QA、QC
总览QM = 管理质量体系（制定制度）QA = 过程质量保证（监督执行）QC = 产品质量控制（具体测试） QM“做制度的” QM 是一个组织层面上的质量管理活动，负责制定整体质量目标、规范、流程。 关键词：制度、流程、策略、标准、体系（ISO9001、CMMI） 企业层面的“质量管理体系建设者”。 QA“看着流程走，确保做对事” QA 的核心是：过程导向，预防缺陷。它不具体写测试用例，而是保证整个开发流程按质量体系执行。 关键词：过程、审核、评审、预防缺陷、监控执行情况 QA 做什么？ 监督开发过程是否遵循规范 检查需求评审、设计评审是否完成 做质量审计 推动缺陷根因分析 推进流程改进 QA 不测功能，也不会直接测试产品。 QA 保证“事情是按正确的方法做的”。 QC“动手实测产品，发现问题” QC 就是传统意义上的测试人员，面向产品，发现缺陷。 关键词：产品、测试、缺陷识别、验证、结果导向 QC 做什么？ 功能测试 性能测试 安全测试 测试用例编写与执行 缺陷报告 回归测试 QC 是“直接发现问题的人”。 对比 角色 关注点 做什么 ...
强度测试
定义强度测试（Strength Testing）是软件性能测试的一种，用于验证系统在长时间高压力、高强度条件下是否能够稳定运行。它关注的是系统在接近极限的情况下能否保持可用性，而不是瞬时吞吐或峰值性能。 强度测试是让系统在高压力、极端资源消耗或恶劣环境下长时间运行，验证系统是否会出现崩溃、内存泄漏、死锁、性能下降等问题。它主要评估系统的 稳定性（Stability） 和 鲁棒性（Robustness）。 强度测试又称：耐久性测试（Endurance Test）、浸泡测试（Soak Test）、稳定性测试（Stability Test） 目标 检查系统在压力不断累积下是否会出问题 发现隐藏的性能瓶颈 找出资源耗尽类型缺陷（内存泄漏、线程泄漏、死锁） 评估系统的恢复能力（是否能自愈或降级） 强度测试常测哪些问题 内存泄漏（memory leak） 句柄泄漏（file handle / socket 不释放） 线程池耗尽 数据库连接池耗尽 服务长期运行后响应变慢 CPU 持续高占用导致系统卡死 缓存击穿 / 缓存雪崩 日志无限增长导致磁盘满 这些都 短期压力测试...
E2E测试
定义E2E 测试（End-to-End Test，全流程测试）是软件测试中最高层级的一种测试方法，它通过模拟真实用户场景，从系统的入口到出口，验证整个系统在真实使用流程下是否能正确运作。 E2E测试就是模拟用户真实使用行为，从开始操作到最终结果，验证整个系统（前端 + 后端 + 数据库 + 外部服务）是否真正能跑通。 特点 测试的是 完整业务流程（例如：登录 → 搜索 → 下单 → 支付）。 覆盖多个系统组件：前端、后端、数据库、API、第三方服务。 验证系统能否像用户实际操作一样 端到端跑通。 往往是跨模块、跨系统的集成验证。 E2E测试常见场景 场景 说明 注册登录流程 用户注册 → 邮箱验证 → 登录成功 购物流程 选择商品 → 加入购物车 → 下单 → 支付 权限流程 普通用户不能访问管理员页面 多系统协作流程 业务系统 A → 调用 B → 写入数据库 → 显示结果 常用E2E测试工具前端：Cypress、Playwright、Selenium移动端：Appium后端API E2E：Postman+Newman、k6(API负载+E2E) 优...
负载测试
定义负载测试是在逐步增加并发量和请求量的情况下，验证系统在接近设计容量范围内的性能表现，确定系统能承受多大的稳定负载而不出现性能下降。 负载测试（Load Test）是一种性能测试，用来评估系统在正常和接近高负载情况下是否仍能保持：正确性、稳定性、性能指标达标（响应时间、QPS、吞吐量等），它模拟大量用户同时访问系统，通过持续施压来观察系统极限。 目标 验证系统承载能力是否达到设计值（如承诺 10k QPS 是否能达到） 找出性能瓶颈（数据库、缓存、CPU、锁竞争等） 确保系统在高负载下仍能稳定运行 为扩容、容量规划提供依据 发现隐藏问题（慢查询、内存泄漏、线程池耗尽） 常见负载测试指标 指标 含义 QPS 每秒请求数 TPS 每秒事务数 响应时间(P50,P90,P95,P99) 延迟表现 吞吐量 系统每秒处理的数据量 CPU、内存、I/O、网络使用率 监控资源瓶颈 错误率 请求失败占比 饱和度(Saturation) 系统举例极限有多近 通用流程 明确性能目标：例如：QPS ≥ 5000、P99 响应时间 ≤ 50ms、错误率...
阿尔法测试和贝塔测试
定义α\alphaα测试是内部测试,β\betaβ测试是公开给部分真实用户的外部测试。 α\alphaα测试在软件接近完成但仍不稳定时，由 内部团队（开发、测试、产品） 在受控环境下进行的测试。 特点： 内部人员参与 在公司内部环境进行 发现严重缺陷、功能性问题 目标是“验证功能基本可用” 测试方式包括黑盒 + 白盒 会模拟用户行为，但不是现实使用环境 目的：找出主要缺陷，使软件达到可公开给用户试用的质量。 β\betaβ测试在阿尔法测试完成后，将软件发布给 真实用户（外部用户）在实际场景中使用，收集反馈。 特点： 外部真实用户参与 在真实环境、真实设备上使用 注重用户体验、性能、兼容性 测试人员不受控，范围更宽 收集用户反馈和未知问题 目的：验证软件在真实场景是否稳定、好用，是否能正式上线。 对比 对比项 α\alphaα测试 β\betaβ测试 测试执行者 内部员工 外部用户 测试环境 受控环境（公司内部） 真实用户环境 主要目标 找出功能性缺陷、严重 Bug 用户反馈、体验问题、真实使用问题 软件稳定性 较不稳定 较稳定 覆盖场景...
测试驱动开发
定义测试驱动开发（TDD，Test-Driven Development） 是一种先写测试、后写代码的敏捷开发方法，通过“红 → 绿 → 重构”三步循环来驱动功能实现，使代码质量更高、设计更清晰、Bug 更少。 TDD 是先写失败的测试，再写最少量代码让测试通过，最后重构代码，在保证测试仍然通过的前提下持续优化设计的开发方式。 TDD核心循环:Red->Green->Refactor Red(写测试，测试失败)：编写一个针对某个功能的单元测试，因为功能未实现，测试必然失败(Red) Green(让测试通过)：编写实现代码，不追求完美，只写最少代码让测试通过 Refactor(重构)：优化代码结构、命名、抽象，确保测试仍全部通过，不改变对外行为 优势与价值 减少 Bug：因为先写测试，功能未覆盖的场景立即暴露 保证可维护性：持续的自动化测试确保重构安全 让设计更清晰：写测试时你必须明确需求和 API 降低回归成本：所有测试自动运行 避免过度设计：你只写让测试通过所需最少代码 适用于中大型后端项目、复杂逻辑、核心业务模块。
99分位响应时间
定义99 分位响应时间（P99 响应时间） = 在所有请求中，99% 的请求响应时间都比它更快，只有最慢的 1% 的请求比它更慢。 P99 = “最慢的那 1% 的用户体验”，用于衡量系统在极端情况下的稳定性，非常适合高并发、强 SLA 的系统（支付、直播、游戏、接口网关等）。 平均值会被部分极慢请求“拉低”，无法反映极端情况。中位数（P50）很好看，但不能说明峰值延时。P99 是系统瓶颈、队列、锁竞争、GC 暴涨、网络抖动的最佳暴露点 特别适合高并发场景：支付、直播间消息、微服务网关、数据库查询。 如何计算P99直接从数据排序计算123# 假设 resp_times 是响应时间列表（单位 ms）resp_times.sort()p99 = resp_times[int(0.99 * len(resp_times))] 使用监测/压测工具自动计算Prometheus + Grafana：histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) k6：自动输出 h...
常用测试工具总结
单元测试(Unit Test)工具JUnit最主流的Java单元测试框架 TestNG类似于JUnit，但功能更强(分组、依赖) Google Test(gtest)C++最常用的单元测试框架 pytest最强python测试框架 Mocha/Jest前端单元测试最常用工具 Go testing pkgGo自带的单元测试框架 接口/API测试工具PostmanAPI调试/测试，最常用，请求构造、环境变量、脚本测试 JMeter可做接口测试+压力测试，企业常用 SoapUI支持SOAP/REST API，适合老项目 Insomnia类似于Postman，界面更精简 HoppscotchWeb工具，在线API测试，轻量化 自动化测试(UI测试)工具SeleniumWeb，最经典Web UI自动化框架 PlaywrightWeb，新一代自动化测试，更快、更稳定 CypressWeb，前端使用，简单、直观 Appium移动端，Android/IOS自动化测试框架 Robot Framework通用，基于关键字的自动化测试框架 性能测试&#...
契约测试
定义契约测试（Contract Testing）是一种用于微服务或前后端分离系统中的测试方式，主要目的是确保服务提供方（Provider）和服务调用方（Consumer）之间的接口“契约”始终保持一致、不会被意外破坏。 Consumer 定义“我需要什么样的 API”，Provider 承诺“我提供的 API 符合你的要求”，并通过测试自动验证双方是否匹配。 契约测试就是为了解决接口不一致、沟通不清导致的问题。 howConsumer Contract(消费者契约)由消费者写下“我调用这个 API 时，我需要的数据结构是什么”。 Provider Verification(服务提供方验证)Provider 必须验证自己返回的数据结构与消费者要求一致。如果不一致，则无法上线，防止破坏接口。 常用toolsPact（最流行） Spring Cloud Contract（Java/微服务中常用） Hoverfly（API 模拟） 契约测试的特殊点是 双方共同维护，不需要全部服务都跑起来。