首页 /
...
/
软件工程 / 软件测试方法
╱ 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()
正在生成题目...
AI 服务暂不可用,显示文档预设题目
上一篇 代码重构
下一篇 软件度量