首页 / ... / 软件工程 / 软件测试方法
╱ E2E测试 ╲ 少量，慢，脆弱 ╱─────────────╲ ╱ 集成测试 ╲ 适量，中速 ╱───────────────────╲ ╱ 单元测试 ╲ 大量，快速，稳定 ╱─────────────────────────╲ 层级 数量 速度 范围 目的 单元测试 70% 毫秒 单个函数/类 验证逻辑正确性 集成测试 20% 秒 模块 交互验证组件协作 E2E测试 10% 分钟 完整流程 验证用户场景
类 型说明 示例 单元测试 测试最小可测试单元 函数、方法 集成测试 测试模块 间交互 API调用、数据库操作 系统测试 测试完整系统 端到端流程 验收测试 用户确认需求满足 UAT
类 型说明 功能测试 验证功能是否正确 性能测试 验证响应时间和吞吐量 安全测试 验证安全漏洞 兼容性测试 验证不同环境下的表现 回归测试 验证修改未引入新缺陷
类 型说明 特点 白盒测试 基于代码结构 路径覆盖、条件覆盖 黑盒测试 基于功能规格 等价类 、边界值 灰盒测试 部分了解内部结构 结合黑白盒
1. 红：写一个失败的测试 2. 绿：写最少的代码使测试通过 3. 重构：优化代码，保持测试通过 4. 重复1-3 # 第1步：红 - 写失败测试 def test_add (): assert add( 2 , 3 ) == 5 # NameError: add未定义 # 第2步：绿 - 最少代码通过 def add (a, b): return a + b # 第3步：重构 - 优化（此处已足够简洁） # 继续添加测试 def test_add_negative (): assert add( - 1 , 1 ) == 0 def test_add_zero (): assert add( 0 , 0 ) == 0 原则 说明 测试先行 先写测试再写代码 小步前进 每次只添加一个测试 最少代码 只写让测试通过的最少代码 持续重构 每次通过后立即重构
维度 TDD BDD 关注点 代码正确性 业务行为 语言 编程语言 自然语言 参与者 开发者 开发者+QA+业务 规格形式 测试函数 场景描述
Feature : 用户登录 作为注册用户 我希望登录系统 以便访问我的账户 Scenario : 成功登录 Given 用户在登录页面 And 用户输入正确的用户名和密码 When 用户点击登录按钮 Then 用户跳转到首页 And 显示欢迎消息 Scenario : 密码错误 Given 用户在登录页面 And 用户输入正确的用户名和错误的密码 When 用户点击登录按钮 Then 显示 "密码错误" 提示 And 用户仍在登录页面 语言 工具 Java Cucumber-JVM Python Behave JavaScript Cucumber.js .NET SpecFlow
类 型说明 语句覆盖 每条语句至少执行一次 分支覆盖 每个分支至少执行一次 路径覆盖 每条可能路径至少执行一次 条件覆盖 每个条件的真假至少一次 MC/DC 每个条件独立影响结果
场景 建议覆盖率 核心业务逻辑 90%+ 通用工具类 80%+ UI层 50%~70% 遗留代码 逐步提升
类 型说明 特点 Stub 返回预设值 简单，不验证交互 Mock 验证交互行为 验证方法是否被调用 Spy 记录调用信息 部分模拟 Fake 简化实现 如内存数据库
from unittest.mock import Mock, patch # Mock db = Mock() db.save.return_value = True assert db.save({ "name" : "test" }) == True db.save.assert_called_once() # Patch with patch( 'module.external_api' ) as mock_api: mock_api.return_value = { "status" : "ok" } result = my_function() 上一篇 代码重构
下一篇 软件度量