一、测试层级与 V 模型、文档规范
- V 模型对应关系
需求分析→系统测试；概要设计→集成测试；详细设计→单元测试；验收测试面向整套完整系统，由用户对照需求验收。
- 四大测试层级核心
- 单元测试：聚焦单个模块、函数，引入桩模块、驱动模块隔离依赖；
- 集成测试：重点验证模块间接口与数据交互，迭代开发必做回归测试；
- 系统测试：全系统功能 + 非功能（性能、安全、兼容、易用性）；
- 验收测试：针对上线完整系统开展验收。
- 测试计划：记录测试范围、资源、工期、项目风险，不含用例步骤；
- 测试用例：存放输入步骤、预期结果；
- 测试报告：包含测试环境、缺陷统计、测试结论，不附带用例详细步骤。
- 缺陷纠纷处理：开发与测试对缺陷存疑无法统一时，由产品经理依照需求文档最终裁定。
二、黑盒 & 白盒用例设计
黑盒测试（基于需求，不关注代码）
- 等价类划分：划分有效、无效输入区间，精简用例数量；
- 边界值分析：主攻临界数值，例如密码 8~16 位，6 位、8 位、16 位、17 位都是典型边界；
- 判定表：专门处理多输入条件互相组合的场景；
- 正交试验、场景法同样属于黑盒范畴。
小知识点：软件测试分为功能测试、非功能测试，性能、安全、兼容性属于非功能，功能测试不属于非功能范畴。
白盒测试
- 语句覆盖：保证程序每一行代码都被执行一次；
- 判定（分支）覆盖：每个 if 判断的真假分支全部覆盖；
- 条件覆盖：判定里每一个独立条件的真假值全部覆盖（易错：区分判定覆盖）；
- 路径覆盖：遍历程序所有可行路径，成本最高。
- 环形复杂度：计算公式\(V(G)=E-N+2\)，复杂度数值等于程序独立基本路径数量，判定节点数 = 环复杂度 - 1。
静态测试 VS 动态测试
- 静态：不运行程序，需求评审、文档校对、代码审查、代码规范检查；
- 动态：运行程序执行测试用例，绝大多数手工、自动化测试都属于动态。
三、单元测试：桩模块 & 驱动模块
- 桩模块 Stub：被测模块需要调用下层未开发依赖时，用桩模拟被调用的底层函数；
- 驱动模块 Driver：上层程序还未实现，通过驱动主动调用被测模块，传入参数驱动代码运行；
- 集成策略：自底向上集成（底层开发完成、顶层未完工优先选用），底层模块单元测试充分，需要编写驱动，不用桩模块。
四、自动化测试：JUnit5 + Selenium
- JUnit5 注解
@BeforeEach：每一条 @Test 测试方法执行前运行一次；@BeforeAll：整个测试类启动前仅执行一次。
断言区分：assertEquals 对比数值相等，assertSame 对比对象内存地址一致。
- Selenium WebDriver
原生支持页面刷新、获取窗口句柄、input 标签文件上传、执行 JS 脚本；无法拦截修改 HTTP 响应码、不能直接操作系统剪贴板，需要借助代理工具拓展能力。
五、性能测试三大类型
- 负载测试：系统在常规业务负载下运行，验证预期负载的响应时间；
- 压力测试：超出系统设计阈值持续施压，观测系统报错、宕机等极限表现；
- 容量测试：不断加压直至 CPU、内存资源耗尽，测出系统最大承载上限；
- 补充：TPS 吞吐量是衡量系统处理能力上限指标；分布式压测部署多台施压机器，模拟全国各地用户并发访问。
六、安全 & 接口测试
- SQL 注入是 OWASP Top10 首位高危漏洞，测试方式：输入
' or 1=1 --等特殊 SQL 字符试探注入漏洞；
- 接口正向测试：合法参数校验业务；负向测试：传入异常、无效参数，校验错误返回码（如 400）。
七、测试经典理论 + DevOps
- 测试基础原则
①测试无法证明软件没有缺陷，只能发现缺陷；②尽早测试减少修复成本；③缺陷集群分布；
④杀虫剂悖论：同一批用例反复执行，很难再发现新缺陷，需要定期更新维护用例。
- CI 持续集成：开发提交代码至代码仓库，自动触发编译、单元、集成自动化测试，提前暴露集成问题；
- DevOps 质量内建：开发、测试、运维全员对产品质量负责，质量前置，避免全量问题堆积在测试阶段。
八、个人刷题易错总结
- 桩、驱动模块作用极易记反：被测调下层→桩；上层调被测→驱动；
- 条件覆盖、判定覆盖定义混淆，做题优先抓关键词：条件看单个条件，判定看分支；
- 负载 / 压力 / 容量三种性能测试场景分不清，牢记三者施压目的；
- 分清测试计划、测试报告、测试用例各自承载内容。
