软件测试基础

錠诗味

381人浏览 · 2026-03-12 20:35:12

錠诗味 · 2026-03-12 20:35:12 发布

软件测试基础

在这里插入图片描述

1.什么是软件测试?

定义:软件测试是通过人工或自动化的方式,验证软件是否满足规定需求,并且发现缺陷的过程

核心目的:

验证软件功能是否符号需求
确认软件满足用户期望
尽早发现缺陷,降低修复成本
提供软件质量信息,帮助决策

重要认知:测试不是为了证明软件没有bug,而且为了发现缺陷,并且评估软件质量

2.测试vs调试

对比项	测试	调试
目的	发现缺陷	定位并修复缺陷
执行者	测试人员	开发人员
阶段	贯穿整个开发周期	开发阶段
方法	设计用例,执行测试	分析代码,单步调试

3.软件开发的生命周期(SDLC)

3.1软件开发周期

需求分析==>概要设计==>详细设计==>编码==>测试==>上线==>维护

3.2软件常用开发模型

3.2.1瀑布模型(Waterfall Model)

特点：线性顺序，阶段分明，像瀑布一样逐级流下

需求分析 → 系统设计 → 编码实现 → 测试验证 → 部署上线 → 运维维护
   ↑___________________________________________________________|
                        发现问题需回溯

优点：

阶段清晰，易于管理
文档完整，适合大型项目
适合需求明确、变更少的项目

缺点：

灵活性差，难以应对需求变更
测试阶段靠后，发现问题修复成本高
用户要到后期才能看到成果

适用场景：需求明确、稳定的项目（如银行核心系统、军工项目）

3.2.2敏捷开发模型(Agile)

特点：迭代快速，小步快跑，拥抱变化

迭代1（2周）    迭代2（2周）    迭代3（2周）    迭代N...
├─ 需求        ├─ 需求        ├─ 需求
├─ 设计        ├─ 设计        ├─ 设计
├─ 开发        ├─ 开发        ├─ 开发
├─ 测试        ├─ 测试        ├─ 测试
└─ 交付        └─ 交付        └─ 交付
   ↑可工作的软件   ↑可工作的软件   ↑可工作的软件

核心原则（敏捷宣言）：

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

优点：

快速响应需求变化
持续交付可用软件
客户参与度高

缺点：

对团队自驱力要求高
文档可能不足
大型团队协作挑战大

3.2.3迭代模型(Iterative Model)

特点：先整体后细化，多次迭代完善

第1次迭代：实现核心框架（粗糙但可用）
第2次迭代：完善主要功能
第3次迭代：优化细节、性能
第N次迭代：最终产品

与敏捷的区别：迭代周期通常更长，不一定是固定时间盒

3.2.4 螺旋模型（Spiral Model）

特点：风险驱动，循环迭代，每圈都包含风险评估

  计划
          ↑
   风险评估 ← 工程实施
          ↓
        客户评估

四个象限：

目标设定（需求）
风险评估（识别风险）
开发和验证（实现）
规划下一阶段

优点：强调风险控制，适合大型复杂项目

缺点：成本高，不适合小项目

3.2.5 V模型（验证与确认模型）

特点：开发与测试对应，强调验证

需求分析 ←────────→ 验收测试
    ↓                  ↑
概要设计 ←────────→ 系统测试
    ↓                  ↑
详细设计 ←────────→ 集成测试
    ↓                  ↑
编码实现 ←────────→ 单元测试

左边：开发活动（自顶向下细化）
右边：测试活动（自底向上验证）

3.2.6 DevOps模型

特点：打破开发与运维壁垒，持续交付

开发 → 构建 → 测试 → 部署 → 监控 → 反馈 → 开发
  ↑___________________________________________|
              自动化循环

核心理念：

持续集成（CI）：频繁合并代码，自动构建
持续交付（CD）：自动部署到生产环境
基础设施即代码（IaC）
监控与反馈

3.3 开发模型对比

模型	灵活性	文档要求	适合项目	测试介入时机
瀑布	低	高	需求稳定的大型项目	后期
敏捷	高	低	需求变化快的项目	持续
螺旋	中	高	高风险大型项目	各阶段
V模型	低	高	传统软件项目	对应阶段
DevOps	高	中	云原生、互联网项目	持续自动化

4.测试生命周期

4.1软件测试生命周期

需求分析==>测试计划==>测试设计==>环境搭建==>测试执行==>测试报告

阶段	主要工作	产出物
需求分析	理解需求，识别可测试点	需求疑问清单
测试计划	确定范围、资源、进度	测试计划文档
测试设计	编写测试用例	测试用例
环境搭建	准备测试数据、环境	可用测试环境
测试执行	执行用例，记录缺陷	缺陷报告、测试日志
测试报告	统计结果，评估质量	测试报告

4.2软件测试常用模型

4.2.1 V模型（测试对应模型）

开发阶段	测试阶段	测试对象
需求分析	验收测试	用户需求
概要设计	系统测试	整体系统
详细设计	集成测试	模块接口
编码	单元测试	代码单元

4.2.2 W模型(双V模型)

特点：测试与开发同步进行，强调测试早期介入

 需求分析
       /        \
    测试设计    开发活动
       \        /
        系统设计
       /        \
    测试设计    开发活动
       \        /
        编码实现
       /        \
    测试执行    开发活动
       \        /
        验收交付

优点：

测试从需求阶段就开始
发现缺陷更早，成本更低
测试准备更充分

4.2.3 H模型

特点：测试是独立的流程，与开发并行

 测试准备
           ↓
    ┌─────测试执行─────┐
    ↓                  ↓
  测试就绪点 ←──────→ 测试完成点
    ↓                  ↓
    └─────测试执行─────┘
           ↓
        测试结束

核心思想：

测试是一个独立的过程
只要测试准备完成，就可以开始测试
不依赖于开发完成度

4.2.4 X模型

特点：强调探索性测试和测试技术

 程序片段1 ←──────→ 测试1
            ↓
        程序片段2 ←──────→ 测试2
            ↓
        程序片段N ←──────→ 测试N
            ↓
        集成测试 ←──────→ 系统测试

特点：

支持单元测试到系统测试的迭代
强调探索性测试
支持测试技术的多样化

4.2.5 敏捷测试模型

特点：适应敏捷开发，测试与开发深度融合

迭代周期（如2周）
├─ Day 1-2: 需求澄清、测试计划
├─ Day 3-8: 开发与测试并行（TDD/BDD）
├─ Day 9-10: 探索性测试、回归测试、验收
└─ 迭代评审、回顾

敏捷测试原则：

测试与开发同步进行
自动化测试优先
全员质量负责（不仅是测试人员）
快速反馈，持续改进

敏捷测试四象限（Brian Marick）：

	面向业务	面向技术
支持团队	Q1: 单元测试、组件测试	Q2: 集成测试、性能测试
评价产品	Q3: 探索性测试、可用性测试	Q4: 压力测试、安全测试

4.3 测试模型对比

模型	核心理念	优点	缺点
V模型	测试与开发对应	结构清晰	测试介入较晚
W模型	测试早期介入	发现缺陷早	需要更多资源
H模型	测试独立流程	灵活性高	协调复杂
敏捷测试	测试与开发融合	快速反馈	对自动化要求高

5.测试类型

5.1按测试阶段分类

测试类型	说明	关注点
单元测试	测试最小代码单元(函数/方法)	代码逻辑正确性
集成测试	测试模块之间的接口	模块间数据传递
系统测试	测试完整系统	端到端业务流程
验收测试	用户确认是否接受系统	业务需求满足度

5.2按测试技术分类

测试类型	说明	示例
功能测试	验证功能是否符合需求	登录、注册、下单
性能测试	测试系统性能指标	并发1000用户，响应时间<2s
安全测试	发现安全漏洞	SQL注入、XSS攻击
兼容性测试	不同环境的表现	Chrome/Firefox/Edge
易用性测试	用户体验	界面友好、操作便捷
可靠性测试	系统稳定性	7×24小时运行不崩溃

5.3其他重要测试类型

类型	说明
回归测试	修改代码后，验证原有功能是否正常
冒烟测试	版本接收前的快速验证，判断能否进入详细测试
探索性测试	不依赖用例，自由探索发现缺陷
压力测试	超出正常负载，测试系统极限

6.测试方法详解

6.1 黑盒测试

特点:不关心内部代码结构，只关注输入和输出

适用场景：功能测试、系统测试、验收测试

常用技术

等价类划分
边界值分析
决策表
状态转换
场景法

输入 --> [黑盒子]-->输出
			↑ 内部实现不可见

6.2白盒测试

特点：基于代码内部逻辑结构进行测试

适用场景：单元测试、代码审查

覆盖标准：

语句覆盖：每行代码至少执行一次
分支覆盖：每个判断的 true/false 都执行
路径覆盖：所有可能的执行路径都覆盖

# 示例代码
def check_age(age):
    if age >= 18:      # 分支1
        return "成年"
    else:              # 分支2
        return "未成年"

# 白盒测试需要覆盖两个分支
# 测试数据：age=20（成年分支）, age=15（未成年分支）

6.3.灰盒测试

特点：结合黑盒和白盒，了解部分内部结构

适用场景：集成测试、API测试

7.软件质量与测试原则

7.1软件质量特征(ISO 25010)

特性	说明
功能性	功能完整、正确
性能效率	响应快、资源占用少
兼容性	与其他系统共存
可用性	易学、易用
可靠性	稳定、容错
安全性	防止未授权访问
可维护性	易修改、易分析
可移植性	易迁移到不同环境

7.2测试基本原则

测试只能证明缺陷存在,不能证明缺陷不存在
穷尽测试是不可能的–>需要设计有效的测试用例
缺陷集群性–>80%的缺陷集中在20%的模块中
杀虫剂悖论–>同样用例反复执行测试,发现缺陷的能力下降
测试活动尽早介入–>越早发现缺陷,修复成本越低
测试依赖于上下文–>安全软件vs游戏软件,测试重点不同

8.测试用例编写格式

8.1什么是测试用例?

定义:测试用例是为特定目的而设计的一组测试输入,执行条件和预期结果,用于验证被测软件的某个特定功能或特征

作用:

指导测试执行(按步骤操作)
保证测试覆盖(不遗漏功能点)
便于回归测试(重复执行)
知识传承(新人快速上手)

8.2标准测试用例模板

字段	说明	示例
用例编号	唯一标识,便于管理	TC_Login_001
用例标题	简明描述测试内容	使用正确账号密码登录成功
所属模块	功能模块分类	用户管理-登录
优先级	P0/P1/P2/P3	P0(核心功能)
前置条件	执行前必须满足的条件	用户已注册,账号状态正常
测试步骤	详细的操作步骤	1.打开登录页 2.输入用户名 3.输入密码 4.点击登录按钮
测试数据	具体输入值	用户名:test01 密码:Test@123
预期结果	应该出现的结果	登录成功，跳转到首页
实际结果	执行后的真实结果	（执行时填写）
执行状态
备注

8.3优先级定义

优先级	定义	执行策略
P0	核心功能，阻塞性缺陷	必须100%执行，冒烟测试用例
P1	重要功能，影响主要业务流程	必须执行，回归测试必测
P2	一般功能，有替代方案	时间允许时执行
P3	边缘功能，影响较小	可选执行，低优先级

8.4.好的测试用例满足原则

独立性:每个用例独立,不依赖其他用例执行结果
可重复性:任何人按步骤执行,结果一致
清晰明确:步骤具体,预期结果可判定
原子性:一个用例验证一个功能点
可追溯:与需求对应,能追溯到需求编号

8.5常见测试用例设计方法

等价类划分
边界值分析
场景法
因果图/判定表法
正交试验法
错误推测法

8.6常见的测试用例管理工具

工具	特点	适用场景
Excel	简单、灵活	小型项目、个人练习
TestLink	开源、免费	中小团队
禅道	国产、集成项目管理	国内团队常用
Jira + X射线/Zephyr	功能强大	大型团队、敏捷开发
腾讯TAPD/阿里云效	国内云产品	使用对应云服务的团队