静态测试是什么
静态测试不执行代码，通过人工评审与工具检查工作产品：需求文档、设计、代码、配置与测试用例。它能在编码前后低成本发现缺陷，且不需要运行环境，适合纳入提交前检查与 CI。常见手段包括评审（走查、检查单）与静态分析（类型检查、Lint、复杂度与安全检查）。
基本信息
| 对象 | 需求文档、设计、源代码、测试用例、配置脚本 |
|---|---|
| 人工手段 | 走查、技术评审、同行评审、检查单 |
| 工具手段 | 类型检查、Lint、静态分析、依赖漏洞扫描 |
| 特点 | 不执行代码、不依赖运行环境、适合质量左移 |
典型使用场景
- 提交前检查：钩子挂 Lint 与类型检查，阻断低级问题
- CI 流水线：静态分析作为合并前的质量门禁
- 需求评审：检查可测性、歧义与冲突
- 代码评审：同行检查逻辑分支与边界
- 安全扫描：依赖漏洞与危险模式检查
- 配置与脚本：Shell 与部署脚本静态检查
静态检查示例
静态检查示例
python -m mypy src/ # 类型检查：提前暴露类型不一致
python -m flake8 src/ # 风格与潜在问题（未用变量、未定义名）
shellcheck deploy/*.sh # Shell 脚本常见陷阱检查
npx eslint src/ # JS/TS 静态检查
# 在 CI 中把以上命令设为必需检查，失败即阻断合并评审方法对照
| 方法 | 形式 | 适用 |
|---|---|---|
| 走查 | 作者主导讲解，团队提问 | 早期文档快速反馈 |
| 技术评审 | 指定评审人逐项检查 | 设计文档与接口契约 |
| 检查 | 按检查单逐条核对 | 关键模块与安全相关代码 |
| 自动化分析 | 工具扫描全量代码 | 每次提交与每日构建 |
静态发现的问题不需要运行环境，成本随发现阶段左移而下降；把检查单沉淀为团队资产，新成员也能按条目执行。
只挂 Lint 不处理告警，规则形同虚设；应设告警基线并逐步收紧，防止噪声淹没真实问题。