功能测试 - 软件测试方法与理论-CSDN博客

本文链接：https://blog.csdn.net/shumeizwb/article/details/139712574

1. 软件开发流程

软件包含：程序、文件、文档、数据

软件开发流程演变：传统瀑布模型 → 敏捷开发模型 → DevOps 模型

瀑布模型

瀑布模型流程：需求分析 → 设计 → 编码 → 实现 → 软件测试 → 完成 → 维护
瀑布模型特点：线性
瀑布模型优点：阶段清晰、强调早期计划和需求调查、适合需求稳定产品
瀑布模型缺点：增加开发风险、错误发现晚

敏捷开发模型

敏捷开发模型：XP、SCRUM

1、极限编程-XP：分多个周期

编程方法：简单设计、结对编程、测试驱动开发、重构

小组实践：代码集体所有、编码标准、稳定高速的步伐、持续集成、隐喻

交付和管理：小规模发布、计划游戏、完整的团队、现场客户

2、SCRUM：产品backlog、sprint计划会议、sprint backlog→2-4周sprint、潜在交付产品增量

敏捷模型特点：增量迭代、小步快跑

Devops

DevOps：开发、测试、运维

DevOps生命周期：持续开发、持续测试、持续集成、持续部署、持续监控

DevOps特点：减少变更范围、加强发布协调、自动化

持续集成（CI）持续交付（CD）

2. 系统架构与数据流

理解公司产品的整体架构-测试架构思维

1．业务架构

商业模式
业务流程：角色、资源、数据
系统架构：角色、行为、数据集成关系

2．系统架构

架构角色与技术栈
部署架构

3．使用统一建模语言UML（梳理业务逻辑关系）

用例图-梳理业务流程：商业模式、业务角色
时序图-分析数据流：业务流程、调用关系
部署图：系统架构与集成关系
活动图-分析测试用例：业务逻辑分析
思维导图（活动图）-分析功能点（流程、分类）

3. 软件测试概念

3.1 软件测试原则

测试显示缺陷的存在
穷尽测试是不可能的
测试尽早介入
缺陷集群性（2/8原则）
杀虫剂悖论
测试活动依赖于测试内容
没有错误是好事谬论

3.2 软件测试模型

3.2.1 V模型

V模型：需求分析 → 概要设计 → 详细设计 → 编码 → 单元测试 → 集成测试 → 系统测试 → 验收测试

优点：既有底层测试又有高层测试、开发阶段清晰

缺点：误解为测试是在开发后进行的阶段

3.2.2 W模型

W模型：测试开发并行、测试伴随整个软件开发周期（包括需求、设计）

用户需求 → 需求分析 → 概要设计 → 详细设计 → 编码 → 集成 → 实施 → 交付

验收测试设计 → 确认与系统测试设计 → 集成测试设计 → 单元测试设计 → 单元测试 → 集成测试 → 确认测试系统测试 → 验收测试

优点：测试贯穿整个项目周期、更早介入早发现问题、测试开发并行

缺点：无法支持迭代的开发模型、有些项目无文档产出、对需求和设计的测试技术要求高

3.2.3 H模型

H模型：把测试活动完全独立出来

测试准备→测试就绪点→测试执行→测试流程

优点：完全独立并发进行、尽早准备执行灵活

缺点：测试就绪点分析困难、对人员要求高

4. 测试流程体系（软件项目管理）

项目流程：开发→单元测试→集成测试→持续集成→冒烟测试→系统测试→验收测试→发布→持续监控

测试流程：需求分析→测试计划（计划评审）→测试用例（用例评审）→集成测试（准备测试数据、准备自动化测试用例）→搭建测试环境（补充测试数据、功能测试、自动化测试）→系统测试报告（缺陷报告）

软件测试范围：传统测试流程、测试左移（开发）和测试右移（运维）

4.1 传统测试流程

完整测试流程：单元测试→集成测试→冒烟测试→系统测试→回归测试→验收测试

系统测试流程：需求分析→测试计划→测试设计（用例）→用例评审→测试执行→bug管理→发布维护

Bug管理流程：

提交缺陷→指派缺陷→确认缺陷（是）→推迟处理（是）→遗留缺陷（后续版本处理）→处理缺陷→回归缺陷（通过）→关闭缺陷

确认缺陷（是）→推迟处理（否）→处理缺陷→回归缺陷（通过）→关闭缺陷

确认缺陷（否）→回归缺陷（通过）→关闭缺陷

回归缺陷（未通过）→重新打开→确认缺陷

4.2 测试左移（开发）

测试左移：开发早期介入、代码测试、预防bug

质量保障手段：代码评审、代码审计、单元测试、自动化冒烟测试、研发自测

4.3 测试右移（运维）

测试右移：发布之后、线上监控

质量保障手段：闭环的线上问题反馈检查解决更新流程、查看日志、log 快速定位

5. 需求分析

查看需求文档-模拟宣讲-需求评审

5.1 需求评审

业务场景角度：

用户故事（站在用户使用角度）
业务流程图（业务整体流程逻辑）

功能点角度：

数据约束是否全面、合理
存在分支的逻辑、描述是否覆盖所有路径
多状态流程，状态流转描述是否合理且完整
权限描述是否明确

5.2 需求分析

明确测试范围
明确功能点
明确业务流程
明确输出结果
分析异常流程
预估测试需要的时间和资源

6. 测试技术体系

6.1 软件测试分类

按开发阶段分类

单元测试
集成测试
系统测试（功能测试、兼容性测试、性能测试、安全测试）
验收测试（α测试、β测试）

按是否查看代码分类

黑盒测试
白盒测试
灰盒测试

按测试执行方式分类

静态测试（查看代码文档）
动态测试（运行程序）

按是否手工执行分类

手工测试
自动化测试

其他分类

冒烟测试
回归测试
随机测试
探索性测试

6.2 分层测试体系

70%单元测试、20%服务测试（接口）、10%用户界面测试（UI）

单元测试方法（白盒，开发人员自己编写）

java（JUnit、TestNG）
python（unittest、pytest）

接口测试（API，灰盒，测试编写）

抓包工具：Charles、Fiddler
自动化测试：postman、python（Requests、HttpRunner）、java（HttpClient、RestAssured）
性能测试：Jmeter、loadRunner

用户界面测试（UI）

人工测试
自动化方式（web：selenium、app：appium）

7. 常用测试平台

测试用例管理与bug管理平台：jira、redmine、testlink、tapd、云效、禅道、gitlab

代码管理平台：gitlab、subversion、github、bitbucket

持续集成管理平台：jenkins、gitlab runner、github action、自建 devops 平台

JIRA基本功能模块

Project 项目（产品、用例管理、bug管理）
Issue 问题（任务）
Field 字段（任务的属性）
Workflow 工作流（任务状态）
Screen 视图（字段的合集）

8. 测试用例设计

1、测试用例概念：测什么？怎么测？

2、测试用例组成：用例编号、测试模块、测试点、前提条件、测试步骤、预期结果、实际结果

3、测试用例等级

P0（核心-冒烟）
P1（高优先级-基本功能）
P2（中优先级-异常、边界、中断、网络、容错、UI）
P3（低优先级-性能、压力、兼容性、安全性、可用性）

4、测试用例设计工具

思维导图
excel

测试用例设计方法

8.1 白盒测试方法论

根据待测产品的内部实现细节来设计测试用例

白盒测试手段：涵盖单元测试、集成测试

白盒测试度量：代码覆盖率

代码覆盖率常见概念：

语句覆盖：每行代码都要覆盖至少一次
判定覆盖：判定表达式的真假至少覆盖一次
判定/条件覆盖：判定覆盖与条件覆盖都必须覆盖
条件组合覆盖：判定表达式中的所有条件组合都需要覆盖
分支覆盖：控制流中的每条分支都要被覆盖一次
路径覆盖：所有的路径都要尽量覆盖
指令覆盖：一行代码会被编译为多条指令，尽可能的覆盖所有指令
方法覆盖：每个方法至少被覆盖一次
类覆盖：每个类至少被覆盖一次
文件覆盖、模块覆盖等等扩展覆盖

覆盖率统计工具：emma、cobertura、jacoco

流程覆盖

利用代码执行流代表流程
流程覆盖用路径覆盖率表达
对流程进行裁剪获得一个适合业务的小规模的业务子集
流程覆盖率=测试经过的路径/业务子集路径

精准化测试（控制流延申）

代码调用链与黑盒测试用例的关联
根据代码变更自动分析影响范围
黑盒测试过程中借助代码流程覆盖数据指导探索式测试
利用线上数据推导有效测试用例
代码流程分析与覆盖率统计

8.2 黑盒测试方法论

常用测试方法：等价类划分、边界值分析、因果图与判定表（决策树-流程图）、场景法

8.2.1 等价类划分法

等价类划分设计步骤：先划分等价类、有效等价类、无效等价类，挑选测试用例数据

可能数据：整数、小数、字母、汉字、符号、空格、回车、不输入

示例

需求：1～100 加法测试

1-100 整数
两个输入框

有效等价类：[1，100] 整数

无效等价类：负数、0、小数、字母、汉字、特殊符号、空

边界值： 0、1、2、99、100、101

8.2.2 边界值分析法

等价类划分的补充方法，通常同时使用

编号	所属等价类	输入框1	输入框2	预期结果
1	有效	1	100	101
2	有效	2	99	101
3	有效	99	2	101
4	有效	100	100	200
5	无效	0	40	给出错误提示
6	无效	40	0	给出错误提示
7	无效	101	50	给出错误提示
8	无效	50	101	给出错误提示
9	无效	3.23	45	给出错误提示
10	无效	45	3.23	给出错误提示
11	无效	ab	11	给出错误提示
12	无效	11	ab	给出错误提示
13	无效	我	34	给出错误提示
14	无效	34	我	给出错误提示
15	无效	%	56	给出错误提示
16	无效	56	%	给出错误提示
17	无效		78	给出错误提示
18	无效	78		给出错误提示

8.2.3 因果图

利用图解法分析输入的各种组合情况，从而设计测试用例的方法，适合检查程序输入条件的各种组合情况。

因 - 输入条件
果 - 输出结果

基本符号

c1-e1 恒等
c1~e1 非
c1/c2/c3ve1或 c1/c2^e1 与

约束条件

E 互斥（至多 1 个）
I 包含（至少 1 个）
O 唯一（有且只有 1 个）
M 屏蔽（有 a 无 b）
R 要求（有 a 必有 b）

因果图设计步骤

找出所有输入条件（因）
找出所有输出条件（果）
输入条件之间的制约和组合关系
输出条件之间的制约和组合关系
输入条件组合产生的输出结果
因果图转化为判定表

设计测试用例

充值条件：投币50/100，充值50/100

输入条件	输出条件
1、投币50	a、完成充值，退卡
2、投币100	b、提示充值成功
3、充值50	c、找零（退钱）
4、充值100	d、提示错误

输入条件：1 和 2 互斥、3 和 4 互斥，共 8 种情况：1、2、3、4、13、14、23、24

输出条件：a 和 d 互斥、b 和 d 互斥，共 4 种情况：ab、abc、cd、d

1、2→cd；3、4→d；13、24→ab；14→cd；23→abc

编号	1	2	3	4	5	6	7	8
输入
1. 投币50元	1				1	1
2. 投币100元		1					1	1
3. 充值50元			1		1		1
4. 充值100元				1		1		1
输出
a. 完成充值退卡					1		1	1
b. 提示充值成功					1		1	1
c. 找零（退钱）	1	1				1	1
d. 提示错误	1	1	1	1		1

8.2.4 判定表组成

条件桩 - 问题的所有条件
动作桩 - 问题的所有输出
条件项 - 针对条件桩的取值
动作项 - 条件项的各种取值情况下的输出结果

判定表设计步骤：列出所有的条件桩和动作桩、确定规则数-每个条件桩的取值个数^条件桩个数、填入条件项、填入动作项得到初始判定表、简化判定表。

示例

判断三角形：三条边a、b、c，判断是否构成三角形、三角形的类型

条件桩条件项2^4

C1：a、b、c是否构成三角形 1、0

C2：a=b？ 1、0

C3：a=c？ 1、0

C4：b=c？ 1、0

动作桩动作项

A1：不是三角形 1

A2：普通三角形 1

A3：等腰三角形 1

A4：等边三角形 1

A5：不可能出现 1

条件桩
C1：a、b、c是否构成三角形	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1
C2：a=b？	0	0	0	0	1	1	1	1	0	0	0	0	1	1	1	1
C3：a=c？	0	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1
C4：b=c？	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1

动作桩
A1：不是三角形	1	1	1	1	1	1	1	1
A2：普通三角形									1
A3：等腰三角形										1	1		1
A4：等边三角形																1
A5：不可能出现												1		1	1

简化后的判定表为：

条件桩
C1：a、b、c是否构成三角形	0	1	1	1	1	1
C2：a=b？	-	0	0	1	1	1
C3：a=c？	-	0	1	0	1	1
C4：b=c？	-	0	1	1	0	1

动作桩
A1：不是三角形	1
A2：普通三角形		1
A3：等腰三角形
A4：等边三角形						1
A5：不可能出现			1	1	1