然而，在实际项目中，如何设计合理的测试策略、平衡测试覆盖率与开发效率、选择合适的测试工具和技术，都是需要深入思考的问题。
UI/手动测试：金字塔之外，补充测试手段。
引言
软件质量是现代软件开发的基石，而测试是保障质量的关键环节。从简单的单元测试到复杂的端到端测试，软件测试策略已经发展成为一个完整的知识体系。
测试金字塔是软件测试的经典理论，它强调了不同层次测试的重要性。然而，在实际项目中，如何设计合理的测试策略、平衡测试覆盖率与开发效率、选择合适的测试工具和技术，都是需要深入思考的问题。
本文将深入探讨软件测试策略的设计原理，从单元测试到端到端测试，分析各种测试方法的特点和适用场景，以及如何在实践中构建有效的测试体系。
测试金字塔理论
测试金字塔是软件测试设计的核心理论，它指导我们如何构建平衡的测试策略。
金字塔结构
单元测试：金字塔底部，数量最多，执行速度最快。
集成测试：金字塔中部，数量适中，测试组件间交互。
端到端测试：金字塔顶部，数量最少，执行速度最慢。
UI/手动测试：金字塔之外，补充测试手段。
graph TB
subgraph 测试金字塔
A[端到端测试<br/>E2E Tests<br/>数量少，速度慢]
B[集成测试<br/>Integration Tests<br/>数量中等，速度中等]
C[单元测试<br/>Unit Tests<br/>数量多，速度快]
end
subgraph 测试特征
D[执行成本]
E[维护成本]
F[反馈速度]
G[测试覆盖率]
end
A --> D: 高
B --> D: 中
C --> D: 低
A --> E: 高
B --> E: 中
C --> E: 低
A --> F: 慢
B --> F: 中
C --> F: 快
A --> G: 低
B --> G: 中
C --> G: 高
style C fill:#90EE90,stroke:#006400,stroke-width:2px
style A fill:#FFB6C1,stroke:#FF0000,stroke-width:2px
金字塔原则
数量原则：单元测试数量应该远多于集成测试和端到端测试。
速度原则：底层测试应该快速执行，为开发提供即时反馈。
可靠性原则：底层测试应该更加稳定可靠，减少假阳性。
成本原则：在保证质量的前提下，优先选择成本更低的测试类型。
单元测试实践
单元测试是测试金字塔的基础，是保证代码质量的第一道防线。
单元测试设计原则
独立性：每个测试应该独立运行，不依赖其他测试的状态。
可重复性：测试结果应该是可重复的，不受环境或执行顺序影响。
可读性：测试代码应该清晰易懂，描述测试意图。
快速执行：单元测试应该快速执行，支持频繁运行。
sequenceDiagram
participant Dev as 开发者
participant Test as 测试代码
participant Code as 被测代码
participant Mock as Mock对象
participant Assert as 断言
Dev->>Test: 编写测试用例
Test->>Mock: 创建Mock对象
Test->>Code: 调用被测函数
Code->>Mock: 依赖Mock返回
Mock-->>Code: 返回模拟数据
Code-->>Test: 返回实际结果
Test->>Assert: 验证结果
Assert-->>Dev: 测试通过/失败
Note over Dev,Assert: 单元测试执行流程
测试驱动开发（TDD）
红绿重构循环：TDD的核心是红绿重构的循环过程。
红阶段：先写一个失败的测试，明确需求。
绿阶段：编写最简单的代码让测试通过。
重构阶段：优化代码结构，保持测试通过。
持续循环：重复这个过程，逐步完善系统。
stateDiagram-v2
[*] --> 红阶段: 编写失败测试
红阶段 --> 绿阶段: 编写实现代码
绿阶段 --> 重构阶段: 重构代码
重构阶段 --> 红阶段: 编写新测试
重构阶段 --> [*]: 功能完成
note right of 红阶段
明确需求，测试失败
end note
note right of 绿阶段
最简实现，测试通过
end note
note right of 重构阶段
优化结构，保持测试通过
end note
Mock与Stub技术
Mock对象：模拟外部依赖的行为，控制测试环境。
Stub对象：提供预先定义的返回值，简化测试场景。
Spy对象：记录方法的调用次数和参数，验证行为。
Fake对象：简化的实现版本，用于替代复杂依赖。
graph TB
subgraph 测试替身类型
A[Mock对象]
B[Stub对象]
C[Spy对象]
D[Fake对象]
end
subgraph 使用场景
E[模拟数据库]
F[模拟API调用]
G[记录方法调用]
H[替代复杂实现]
end
A --> E
B --> F
C --> G
D --> H
subgraph 特性对比
I[行为验证]
J[数据提供]
K[调用记录]
L[简化实现]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#FFD700,stroke:#DAA520,stroke-width:1px
集成测试策略
集成测试验证多个组件之间的交互，是单元测试和系统测试之间的桥梁。
集成测试层次
组件集成测试：测试模块或组件之间的集成。
服务集成测试：测试微服务或服务之间的集成。
外部系统集成测试：测试与外部系统的集成。
数据库集成测试：测试与数据库的交互。
graph TB
subgraph 集成测试层次
A[组件集成测试]
B[服务集成测试]
C[外部系统集成测试]
D[数据库集成测试]
end
subgraph 测试范围
E[模块间交互]
F[服务间通信]
G[第三方API]
H[数据持久化]
end
A --> E
B --> F
C --> G
D --> H
subgraph 技术栈
I[内存数据库]
J[测试容器]
K[WireMock]
L[Testcontainers]
end
A --> I
B --> J
C --> K
D --> L
style B fill:#87CEEB,stroke:#1E90FF,stroke-width:2px
style D fill:#FFD700,stroke:#DAA520,stroke-width:1px
测试容器技术
真实环境：使用真实的服务环境进行测试。
隔离性：每个测试使用独立的容器环境。
可重复性：容器环境是可重复和一致的。
轻量级：相比完整部署，容器更加轻量。
sequenceDiagram
participant Test as 测试启动
participant Container as 容器管理
participant Service as 被测服务
participant DB as 数据库容器
participant Redis as Redis容器
participant Assert as 断言验证
Test->>Container: 启动测试容器
Container->>DB: 启动数据库
Container->>Redis: 启动Redis
Container-->>Test: 容器就绪
Test->>Service: 初始化服务
Service->>DB: 连接数据库
Service->>Redis: 连接Redis
Test->>Service: 执行测试用例
Service->>DB: 数据操作
Service->>Redis: 缓存操作
Service-->>Test: 返回结果
Test->>Assert: 验证结果
Assert-->>Test: 测试通过/失败
Test->>Container: 清理容器
Container->>DB: 停止数据库
Container->>Redis: 停止Redis
Note over Test,Container: 测试容器生命周期
API测试实践
契约测试：验证API契约的合规性。
集成测试：测试API的完整集成场景。
性能测试：测试API的性能表现。
安全测试：测试API的安全性。
graph TB
subgraph API测试类型
A[契约测试]
B[集成测试]
C[性能测试]
D[安全测试]
end
subgraph 测试内容
E[接口规范]
F[业务流程]
G[响应时间]
H[权限控制]
end
A --> E
B --> F
C --> G
D --> H
subgraph 测试工具
I[Pact]
J[RestAssured]
K[JMeter]
L[OWASP ZAP]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style C fill:#FFD700,stroke:#DAA520,stroke-width:1px
端到端测试
端到端测试模拟真实用户的操作流程，验证系统的完整性。
E2E测试设计
用户场景：基于真实的用户使用场景设计测试。
跨平台：支持多种浏览器和平台的测试。
真实环境：在接近生产的环境中进行测试。
关键路径：关注系统的关键业务路径。
sequenceDiagram
participant User as 用户
participant Browser as 浏览器
participant App as 应用程序
participant API as API服务
participant DB as 数据库
participant Payment as 支付系统
User->>Browser: 访问网站
Browser->>App: 加载页面
App->>API: 请求首页数据
API->>DB: 查询数据
DB-->>API: 返回数据
API-->>App: 返回数据
App-->>Browser: 渲染页面
User->>Browser: 添加商品到购物车
Browser->>App: 提交请求
App->>API: 更新购物车
API->>DB: 保存数据
DB-->>API: 保存成功
API-->>App: 返回成功
App-->>Browser: 更新UI
User->>Browser: 提交订单
Browser->>App: 提交支付
App->>Payment: 调用支付
Payment-->>App: 支付成功
App-->>Browser: 显示订单确认
Note over User,Payment: 完整的用户购买流程
E2E测试框架
Cypress：现代化的E2E测试框架，提供优秀的开发者体验。
Playwright：支持多浏览器的E2E测试框架。
Selenium：经典的Web自动化测试框架。
TestCafe：基于Node.js的E2E测试框架。
graph TB
subgraph E2E测试框架
A[Cypress]
B[Playwright]
C[Selenium]
D[TestCafe]
end
subgraph 框架特性
E[时间旅行调试]
F[多浏览器支持]
G[生态系统成熟]
H[无需WebDriver]
end
A --> E
B --> F
C --> G
D --> H
subgraph 适用场景
I[现代Web应用]
J[跨浏览器测试]
K[传统Web应用]
L[快速上手]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style B fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
E2E测试最佳实践
等待策略：使用智能等待而非固定延时。
测试隔离：每个测试应该是独立的，避免相互影响。
数据管理：合理管理测试数据，避免数据污染。
失败处理：完善失败处理和诊断机制。
graph TB
subgraph E2E测试最佳实践
A[等待策略]
B[测试隔离]
C[数据管理]
D[失败处理]
end
subgraph 实施方法
E[智能等待]
F[清理机制]
G[数据工厂]
H[截图录像]
end
A --> E
B --> F
C --> G
D --> H
subgraph 效果
I[减少假阳性]
J[提高可靠性]
K[维护简单]
L[快速定位问题]
end
E --> I
F --> J
G --> K
H --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#FFD700,stroke:#DAA520,stroke-width:1px
性能测试
性能测试确保系统在负载情况下的稳定性和响应能力。
性能测试类型
负载测试：测试系统在预期负载下的表现。
压力测试：测试系统在超出预期负载下的极限。
容量测试：确定系统的最大容量和瓶颈。
稳定性测试：测试系统在持续负载下的稳定性。
graph TB
subgraph 性能测试类型
A[负载测试]
B[压力测试]
C[容量测试]
D[稳定性测试]
end
subgraph 测试目标
E[正常负载表现]
F[极限承载能力]
G[系统容量上限]
H[长期运行稳定性]
end
A --> E
B --> F
C --> G
D --> H
subgraph 关键指标
I[响应时间]
J[吞吐量]
K[错误率]
L[资源利用率]
end
A --> I
B --> J
C --> K
D --> L
style B fill:#FFB6C1,stroke:#FF0000,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
性能测试实施
测试设计：设计合理的性能测试场景。
环境准备：准备性能测试所需的测试环境。
测试执行：执行性能测试并收集数据。
结果分析：分析测试结果，识别性能瓶颈。
sequenceDiagram
participant Plan as 测试计划
participant Script as 脚本开发
participant Env as 环境准备
participant Execute as 测试执行
participant Monitor as 监控收集
participant Analyze as 结果分析
participant Report as 报告输出
Plan->>Script: 定义测试场景
Script->>Script: 开发测试脚本
Script->>Env: 提供测试需求
Env->>Env: 准备测试环境
Env->>Env: 配置监控系统
Env-->>Execute: 环境就绪
Execute->>Execute: 执行性能测试
Execute->>Monitor: 收集性能数据
Monitor->>Monitor: 实时监控指标
Execute->>Analyze: 测试完成
Analyze->>Analyze: 分析测试结果
Analyze->>Report: 生成测试报告
Note over Plan,Report: 性能测试完整流程
性能优化流程
瓶颈识别：识别性能瓶颈所在。
根因分析：分析性能瓶颈的根本原因。
优化实施：实施性能优化措施。
效果验证：验证优化效果。
graph TB
subgraph 性能优化流程
A[瓶颈识别]
B[根因分析]
C[优化实施]
D[效果验证]
end
subgraph 优化方向
E[代码优化]
F[架构优化]
G[基础设施优化]
H[缓存优化]
end
C --> E
C --> F
C --> G
C --> H
subgraph 验证方法
I[基准测试]
J[对比测试]
K[压力测试]
L[长期监控]
end
D --> I
D --> J
D --> K
D --> L
style A fill:#FFB6C1,stroke:#FF0000,stroke-width:1px
style D fill:#90EE90,stroke:#006400,stroke-width:1px
测试覆盖率分析
测试覆盖率是评估测试质量的重要指标，但需要合理使用。
覆盖率类型
行覆盖率：代码行的执行覆盖情况。
分支覆盖率：条件分支的执行覆盖情况。
函数覆盖率：函数的调用覆盖情况。
语句覆盖率：语句的执行覆盖情况。
graph TB
subgraph 覆盖率类型
A[行覆盖率]
B[分支覆盖率]
C[函数覆盖率]
D[语句覆盖率]
end
subgraph 覆盖内容
E[执行的代码行]
F[条件分支判断]
G[被调用的函数]
H[执行的语句]
end
A --> E
B --> F
C --> G
D --> H
subgraph 工具支持
I[Istanbul]
J[JaCoCo]
K[Coverage.py]
L[gcov/lcov]
end
A --> I
B --> J
C --> K
D --> L
style B fill:#FFD700,stroke:#DAA520,stroke-width:1px
覆盖率目标设定
分层目标：不同层次代码设定不同的覆盖率目标。
业务关键：核心业务代码要求更高覆盖率。
变化频繁：频繁变更的代码要求更高覆盖率。
合理平衡：平衡覆盖率目标与开发效率。
graph TB
subgraph 覆盖率目标分层
A[核心业务逻辑<br/>目标: 80-90%]
B[公共服务模块<br/>目标: 70-80%]
C[工具函数<br/>目标: 60-70%]
D[配置和常量<br/>目标: 40-50%]
end
subgraph 目标考量因素
E[业务重要性]
F[变更频率]
G[失败风险]
H[维护成本]
end
A --> E
B --> F
C --> G
D --> H
subgraph 覆盖率工具集成
I[CI/CD集成]
J[门禁检查]
K[趋势分析]
L[报告生成]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:2px
style D fill:#FFB6C1,stroke:#FF0000,stroke-width:1px
持续测试与CI/CD集成
将测试集成到CI/CD流程中，实现持续的质量保障。
CI/CD测试流程
代码提交：开发者提交代码触发CI流程。
自动构建：自动构建项目。
自动测试：自动运行各种测试。
质量门禁：根据测试结果决定是否继续。
sequenceDiagram
participant Dev as 开发者
participant Git as Git仓库
participant CI as CI系统
participant Build as 构建服务
participant Test as 测试服务
participant Deploy as 部署服务
participant Monitor as 监控系统
Dev->>Git: 提交代码
Git->>CI: 触发CI流程
CI->>Build: 开始构建
Build->>Build: 编译打包
Build-->>CI: 构建完成
CI->>Test: 运行测试
Test->>Test: 单元测试
Test->>Test: 集成测试
Test->>Test: E2E测试
Test-->>CI: 测试结果
alt 测试通过
CI->>Deploy: 自动部署
Deploy->>Monitor: 部署监控
else 测试失败
CI->>Dev: 通知失败
end
Note over Dev,Monitor: CI/CD测试流程
测试环境管理
环境隔离：不同的测试使用独立的环境。
环境复用：合理复用测试环境，降低成本。
环境一致性：保证测试环境与生产环境一致。
环境自动化：自动化测试环境的创建和销毁。
graph TB
subgraph 测试环境
A[开发环境]
B[测试环境]
C[预发布环境]
D[生产环境]
end
subgraph 环境特性
E[快速反馈]
F[稳定测试]
G[验证发布]
H[真实运行]
end
A --> E
B --> F
C --> G
D --> H
subgraph 管理策略
I[基础设施即代码]
J[容器化部署]
K[环境即服务]
L[自动化运维]
end
B --> I
C --> J
D --> K
A --> L
style B fill:#90EE90,stroke:#006400,stroke-width:1px
style C fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
测试质量管理
有效的测试质量管理是持续改进测试体系的基础。
测试指标监控
测试通过率：监控测试的通过率趋势。
测试执行时间：监控测试的执行时间变化。
缺陷发现率：监控测试发现的缺陷数量。
测试覆盖率：监控测试覆盖率的变化。
graph TB
subgraph 测试质量指标
A[测试通过率]
B[测试执行时间]
C[缺陷发现率]
D[测试覆盖率]
end
subgraph 指标分析
E[趋势分析]
F[异常检测]
G[根因分析]
H[改进建议]
end
A --> E
B --> F
C --> G
D --> H
subgraph 告警机制
I[指标阈值]
J[告警通知]
K[问题跟踪]
L[改进闭环]
end
E --> I
F --> J
G --> K
H --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style C fill:#FFB6C1,stroke:#FF0000,stroke-width:1px
测试用例管理
用例设计：设计高质量的测试用例。
用例组织：合理组织和管理测试用例。
用例维护：持续维护和更新测试用例。
用例复用：提高测试用例的复用性。
graph TB
subgraph 测试用例管理
A[用例设计]
B[用例组织]
C[用例维护]
D[用例复用]
end
subgraph 管理维度
E[功能维度]
F[业务维度]
C[技术维度]
H[优先级维度]
end
B --> E
B --> F
C --> G
D --> H
subgraph 工具支持
I[测试管理平台]
J[用例追踪系统]
K[自动化集成]
L[报告生成]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#FFD700,stroke:#DAA520,stroke-width:1px
特殊测试场景
针对特定领域的特殊测试需求。
安全测试
渗透测试：模拟攻击者行为测试系统安全性。
漏洞扫描：自动扫描已知安全漏洞。
代码审计：审计代码中的安全问题。
安全合规：验证系统是否符合安全合规要求。
graph TB
subgraph 安全测试类型
A[渗透测试]
B[漏洞扫描]
C[代码审计]
D[安全合规]
end
subgraph 测试内容
E[身份认证]
F[权限控制]
G[数据加密]
H[输入验证]
end
A --> E
B --> F
C --> G
D --> H
subgraph 安全工具
I[OWASP ZAP]
J[SonarQube]
K[Burp Suite]
L[Checkmarx]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#FFB6C1,stroke:#FF0000,stroke-width:1px
兼容性测试
浏览器兼容性：测试在不同浏览器中的兼容性。
设备兼容性：测试在不同设备上的兼容性。
操作系统兼容性：测试在不同操作系统上的兼容性。
版本兼容性：测试在不同版本间的兼容性。
graph TB
subgraph 兼容性测试维度
A[浏览器兼容性]
B[设备兼容性]
C[操作系统兼容性]
D[版本兼容性]
end
subgraph 测试覆盖
E[Chrome]
F[Firefox]
G[Safari]
H[Edge]
end
A --> E
A --> F
A --> G
A --> H
subgraph 测试策略
I[矩阵测试]
J[渐进增强]
K[优雅降级]
L[特性检测]
end
B --> I
C --> J
D --> K
A --> L
style A fill:#87CEEB,stroke:#1E90FF,stroke-width:2px
测试团队建设
构建高效的测试团队是测试成功的关键。
团队角色分工
测试工程师：负责测试设计和执行。
自动化测试工程师：负责测试自动化开发。
测试架构师：负责测试架构设计。
QA负责人：负责整体质量把控。
graph TB
subgraph 测试团队角色
A[测试工程师]
B[自动化测试工程师]
C[测试架构师]
D[QA负责人]
end
subgraph 角色职责
E[用例设计执行]
F[自动化开发维护]
G[架构设计规划]
H[质量管理决策]
end
A --> E
B --> F
C --> G
D --> H
subgraph 技能要求
I[业务理解]
J[编程能力]
K[架构思维]
L[管理能力]
end
A --> I
B --> J
C --> K
D --> L
style C fill:#FFD700,stroke:#DAA520,stroke-width:2px
style D fill:#FFB6C1,stroke:#FF0000,stroke-width:1px
团队协作模式
开发测试协作：开发者和测试者紧密协作。
质量文化建设：建立全员参与的质量文化。
知识共享：促进团队间的知识共享。
持续改进：建立持续改进的机制。
graph TB
subgraph 团队协作模式
A[开发测试协作]
B[质量文化建设]
C[知识共享]
D[持续改进]
end
subgraph 协作机制
E[结对编程]
F[代码审查]
G[技术分享]
H[复盘总结]
end
A --> E
B --> F
C --> G
D --> H
subgraph 协作效果
I[提高代码质量]
J[增强团队凝聚力]
K[提升技术水平]
L[优化工作流程]
end
E --> I
F --> J
G --> K
H --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style B fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
未来发展趋势
软件测试技术仍在不断发展，未来的趋势包括：
AI辅助测试
智能用例生成：使用AI自动生成测试用例。
缺陷预测：基于历史数据预测潜在缺陷。
测试优化：AI优化测试执行顺序和策略。
自动化测试：提高测试自动化的智能化水平。
graph TB
subgraph AI辅助测试
A[智能用例生成]
B[缺陷预测]
C[测试优化]
D[自动化测试]
end
subgraph AI技术
E[机器学习]
F[深度学习]
G[自然语言处理]
H[强化学习]
end
A --> E
B --> F
C --> G
D --> H
subgraph 应用效果
I[提高效率]
J[降低成本]
K[提升质量]
L[减少人力]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#FFD700,stroke:#DAA520,stroke-width:1px
测试左移与右移
测试左移：在开发早期就进行测试活动。
测试右移：在生产环境进行测试监控。
持续测试：贯穿整个软件生命周期的测试。
质量内建：将质量内建到开发过程中。
graph TB
subgraph 测试左移
A[需求阶段]
B[设计阶段]
C[编码阶段]
end
subgraph 测试右移
D[部署阶段]
E[监控阶段]
F[反馈阶段]
end
subgraph 持续测试
G[需求分析]
H[测试设计]
I[测试执行]
J[质量反馈]
end
A --> G
B --> H
C --> I
D --> J
E --> J
F --> G
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style E fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
结论
软件测试是保障软件质量的核心环节，从单元测试到端到端测试，从性能测试到安全测试，完整的测试策略需要多个层次的协同配合。
测试金字塔理论为我们提供了设计测试策略的指导原则，但实际应用中需要根据项目的具体情况进行调整。单元测试提供快速反馈，集成测试验证组件协作，端到端测试确保系统完整性，三者缺一不可。
随着技术的发展，AI辅助测试、测试左移右移等新理念正在改变传统的测试模式。测试不再是质量保障的最后一个环节，而是贯穿整个软件生命周期的持续活动。
对于技术团队而言，建立完善的测试体系，培养测试文化，是构建高质量软件系统的基础。在快速迭代的软件开发环境中，测试策略的设计和实施，将直接影响产品的质量和用户的体验。
在数字化转型的浪潮中，软件系统的复杂性和重要性不断提升，软件测试的重要性只会与日俱增。深入理解软件测试的原理和实践，有助于构建更加可靠、高效的软件系统。
本文深入探讨了软件测试策略的设计原理，涵盖了测试金字塔理论、单元测试实践、集成测试策略、端到端测试、性能测试、测试覆盖率分析、CI/CD集成、测试质量管理、特殊测试场景以及团队建设，并通过 Mermaid 图表展示了测试金字塔结构、单元测试流程、TDD循环、测试替身类型、集成测试层次、测试容器生命周期、API测试类型、E2E用户流程、E2E测试框架对比、性能测试类型、实施流程、优化循环、覆盖率类型、目标分层、CI/CD流程、环境管理、质量指标监控、用例管理、安全测试、兼容性测试、团队角色和协作模式。
版权声明: 本文首发于
指尖魔法屋-关于软件测试策略的几点记录（https://blog.thinkmoon.cn/post/40-software-testing-strategy-notes/）
转载或引用必须申明原指尖魔法屋来源及源地址！