1.测试原则

• 尽早并持续测试：测试应在软件开发早期开始，并在整个开发周期中持续进行。
• 独立测试：测试工作最好由与开发人员不同的小组或人员承担，以保证客观性。
• 预期结果明确：设计测试方案时，不仅要确定输入数据，还要明确预期输出结果。
• 覆盖正反场景：测试用例应包括有效、合理的情况，也要包含无效或异常情况。

2.测试核心目标

• 验证功能：检验程序是否做了该做的事。
• 防止异常：检验程序是否做了不该做的事。
• 规范执行：严格按照测试计划进行操作。
• 文档管理：妥善保存测试计划和测试用例，可重复使用或追加测试。

3.测试方法分类

3.1测试方法（How – 怎么测）

这一维度是实施手段的选择，不同方法可以组合使用。

• 黑盒 / 白盒 / 灰盒
• 静态 / 动态（SAST/DAST/SCA 属于静态/动态安全）
• 人工 / 自动化
• 探索式测试（有脚本也有探索，补盲区）
• Fuzz 模糊测试（安全/健壮性）

3.1.1 静态测试方法

静态测试方法是一种不运行程序就进行测试的方式，重点是通过分析、审查或工具扫描来发现缺陷、漏洞和规范偏差。它常用于早期发现问题、降低修复成本，尤其在代码还未部署或上线前就能介入。

（1）静态测试的核心特点

• 不执行代码：只分析程序的静态形式（源代码、二进制、文档等）。
• 提前介入：可在开发早期进行，缺陷越早发现，修复成本越低。
• 适用范围广：不仅限于代码，还包括需求、设计、配置等。
• 可人工，也可自动化：手工审查和工具扫描可以结合使用。

（2）常见的静态测试方法

① 静态分析（Static Analysis）

• 自动化工具分析源代码/字节码/二进制，检测潜在缺陷、安全漏洞或不符合规范的写法。
• 代表工具：
• 安全类（SAST）：Fortify、Checkmarx、SonarQube
• 质量类：ESLint、Pylint、FindBugs
• 检查内容：
• 语法错误、变量未初始化
• 代码规范问题
• 潜在的空指针、数组越界
• 硬编码密码、敏感信息泄露
• SQL 注入、XSS 等安全风险

② 代码审查（Code Review）

• 人工逐行检查代码，找出逻辑错误、设计缺陷、安全隐患。
• 形式：
• 同行评审（Peer Review）
• 走查（Walkthrough）
• 检查表评审（Checklist Review）
• 优点：能发现自动化工具无法捕捉的业务逻辑问题。
• 常用平台：GitHub PR、GitLab Merge Request、Gerrit

③ 文档审查（Documentation Review）

• 审查 需求规格说明书（SRS）、设计文档、接口文档等，确保描述准确、完整、无歧义。
• 目标：
• 需求可测性（Testability）
• 接口定义一致性
• 业务规则正确性

④ 配置与脚本审查

• 检查配置文件、基础设施脚本（IaC）、CI/CD Pipeline等，避免错误配置导致的安全/可用性问题。
• 工具：
• Terraform/Lambda 配置扫描（Checkov、tfsec）
• Kubernetes YAML 审查（kube-score、kube-linter）
• Dockerfile 安全基线检查

（3）静态测试的优势

• 早期发现问题，降低修复成本
• 无需运行环境，速度快
• 易于集成到 CI/CD 流程
• 能发现潜在的安全漏洞和质量问题

（4）静态测试的局限

• 无法验证运行时行为（需配合动态测试）
• 工具可能出现误报或漏报
• 某些业务逻辑缺陷只能在运行时发现

3.1.2 动态测试方法

（1） 按测试策略分类

① 黑盒测试（功能测试）

• 定义：只关注软件功能和输出是否符合预期，不考虑内部实现。
• 目标：验证功能正确性、业务规则、输入输出关系。
• 方法：
• 等价类划分
• 边界值分析
• 决策表测试
• 状态转换测试
• 随机测试 / 错误推测
• 典型用途：功能测试、系统测试、验收测试

② 白盒测试（结构测试）

• 定义：基于程序内部逻辑结构进行测试。
• 目标：覆盖代码路径，发现逻辑错误、潜在缺陷。
• 方法：
• 语句覆盖
• 判定覆盖（分支覆盖）
• 条件覆盖
• 路径覆盖
• 循环覆盖
• 典型用途：单元测试、集成测试

③ 灰盒测试

• 定义：部分了解内部结构，同时关注输入输出。
• 目标：结合黑盒和白盒优点，既考虑业务功能，也关注内部逻辑。
• 典型用途：Web 应用安全测试、API 测试

（2） 按执行方式分类

① 手工测试

• 测试人员手动执行用例。
• 优点：灵活，可发现隐藏缺陷。
• 缺点：效率低，难以重复执行。

(2) 自动化测试

• 使用测试工具或脚本执行用例。
• 优点：高效、可重复、便于回归测试。
• 常用工具：
• 单元测试框架：JUnit、pytest、TestNG
• UI 自动化：Selenium、Appium
• 接口自动化：Postman、RestAssured
• 性能测试：JMeter、LoadRunner

（3） 特殊类型动态测试

① 探索式测试

• 测试人员在执行过程中动态设计测试步骤，发现未知缺陷。
• 强调经验与灵活性。

② Fuzz 测试（模糊测试）

• 输入大量随机或异常数据，检测程序的健壮性和安全性。
• 适用于安全测试、边界条件测试。

③ 性能/压力测试

• 验证系统在高负载、长时间运行下的稳定性和响应速度。
• 工具：LoadRunner、JMeter

④ 安全测试

• 动态检测应用在运行时的安全漏洞，如 SQL 注入、XSS、权限绕过等。

💡 实战建议：

• 黑/白/灰盒可以结合使用，比如功能测试用黑盒、接口测试用灰盒、单元测试用白盒。
• 静态+动态安全扫描（SAST+DAST+SCA）是 DevSecOps 的核心。
• 自动化优先覆盖回归、高频执行、容易出错的场景。

3.2 测试目标（What – 测什么）

这一维度是关注的质量属性，可以映射到非功能/功能需求。

3.2.1 功能

• 校验业务逻辑正确性（正向用例）
• 边界条件（最大值、最小值、空值）
• 异常场景（网络断开、输入非法）

3.2.2 性能

3.2.3 安全

• 渗透测试（黑客模拟攻击）
• 漏洞扫描（已知漏洞检测）
• 权限/越权验证
• 鉴权与会话安全
• Web 安全（CSRF、XSS、SQL 注入）
• 供应链安全（依赖扫描 SCA）
• 配置基线检查
• 隐私合规（GDPR、等保）

3.2.4 兼容性/移植性

• OS、浏览器、设备、芯片、网络类型、分辨率、向后兼容

3.2.5 可用性/可达性

• 用户体验（UX）：导航流畅、可读性好
• 无障碍（a11y）：键盘可达、屏幕阅读器支持

3.2.6 可靠性/恢复性

• 异常注入（Chaos Testing）
• 断网/断电恢复
• 备份/还原
• 故障转移（Failover）

3.2.7 安装/升级/回滚

• 版本迁移
• 灰度升级
• 数据迁移一致性

3.2.8 国际化/本地化

• 多语言、时区、货币符号
• 本地日期/姓名/数字格式

3.2.9 数据质量/一致性

• 幂等性
• 精度、约束
• 数据脱敏

3.2.10可观测性

• 日志级别配置
• 性能指标采集
• Trace 链路追踪
• 告警触发验证

3.2.11 合规性

• 行业标准（ISO、PCI DSS）
• 隐私法规（GDPR、CCPA）
• 审计追溯能力

💡 实战建议：

• 建立”质量属性→测试项→指标”的映射表，每个属性都要有可量化指标（如 p95 延迟 ≤ 1s）。
• 非功能性测试（性能/安全/兼容等）要早期介入，否则后期修复成本高。

3.3 策略与阶段（When – 什么时候测）

这一维度决定了测试的时机和节奏，直接影响交付风险。

• 冒烟（Smoke）、构建验证（Build Verification）
• 回归（Regression）（强烈建议自动化）
• 验收/UAT、Alpha/Beta、A/B 实验
• 金丝雀/蓝绿/灰度发布、灾备演练（演练亦应纳入测试）

💡 实战建议：

• CI/CD 管道中冒烟→回归→非功能性测试→预发布→灰度→全量是比较成熟的节奏。
• 灾备演练不能忽视，特别是高可用/关键业务系统。

✅ 总结：

• How 解决”用什么手段去测”
• What 解决”关注哪些质量维度”
• When 解决”在什么阶段执行哪些测试”
• 三者结合，就能形成完整的测试策略矩阵，既可指导日常工作，也能作为项目质量管理的蓝本。

4.物联网智能挂锁场景的落地示例

建议的执行顺序

1）冒烟 → 2) 功能（含探索式） → 3) 回归（自动化） → 4) 兼容 → 5) 性能（负载→压力→稳定性） → 6) 安全（DAST/SAST/SCA/渗透） → 7) 验收/UAT → 8) 灰度发布与监控验证。

发布门槛（示例）

• Smoke 100% 通过；回归通过率 ≥ 98%；P0/P1=0；单测覆盖率（语句/分支）≥ 70%/60%；
• p95 延迟与错误率达标；高危安全项=0；关键监控/告警就绪。