软件测试(平铺版本)
目录
黑盒测试:
定义:
示例:登录功能的黑盒测试
适合使用黑盒测试的情况
几种常见的黑盒测试方法:
1. 等价类划分(Equivalence Partitioning)
2. 边界值分析(Boundary Value Analysis)
3. 决策表测试(Decision Table Testing)
4. 状态迁移测试(State Transition Testing)
5. 场景测试(Scenario Testing)
6. 错误推测(Error Guessing)
常用的黑盒测试工具:
白盒测试:
定义:
示例:成绩计算函数的白盒测试
测试用例
适合使用白盒测试的情况
几种常见的白盒测试方法:
1. 语句覆盖(Statement Coverage)
2. 分支覆盖(Branch Coverage)
3. 路径覆盖(Path Coverage)
4. 条件覆盖(Condition Coverage)
5. 多条件覆盖(Multiple Condition Coverage)
6. 循环覆盖(Loop Coverage)
7. 数据流测试(Data Flow Testing)
常用的白盒测试工具
面试问题:
项目用例类(功能测试):
工作流程类
测试流程
黑盒测试:
定义:
- 黑盒测试专注于软件的功能性,不考虑内部代码实现。测试人员通过输入和输出来验证软件功能是否符合预期。
应用场景:
黑盒测试用例主要关注软件的功能性,不考虑内部实现。测试用例通常基于需求文档或用户故事来编写。
示例:登录功能的黑盒测试
假设我们在测试一个简单的用户登录功能,功能需求如下:
- 用户可以输入用户名和密码进行登录。
- 用户名和密码必须非空。
- 若输入正确的用户名和密码,用户成功登录,进入主页。
- 若用户名或密码错误,显示错误信息。
- 若用户名或密码为空,显示提示信息。
适合使用黑盒测试的情况
-
功能验证:
- 当你需要验证软件功能是否符合需求和用户期望时,黑盒测试是理想选择。这包括功能测试、界面测试、用户体验测试等。
-
用户视角测试:
- 黑盒测试模拟用户实际操作,不需要了解内部代码,是从用户视角出发进行的测试。
-
系统级别的集成测试:
- 当你需要测试不同模块或系统之间的交互时,黑盒测试可以帮助验证集成点是否工作正常。
-
回归测试:
- 在软件发生变化或修复缺陷后,黑盒测试常用于回归测试,确保新代码没有引入新的问题。
-
验收测试:
- 在项目交付之前进行的最终测试,常用黑盒测试来验证软件是否满足合同或需求文档的所有要求。
几种常见的黑盒测试方法:
1. 等价类划分(Equivalence Partitioning)
**描述**:
将输入数据划分为若干个等价类,每个等价类中的数据在功能上是等效的。测试只需选择每个等价类中的一个代表作为测试用例。
**示例**:
假设有一个输入字段要求用户输入1到100之间的整数。那么可以将输入数据划分为以下等价类:
- 有效等价类:1-100
- 无效等价类:小于1、大于100、非整数输入
2. 边界值分析(Boundary Value Analysis)
**描述**:
边界值分析侧重于测试输入数据的边界值,因为边界值往往是错误的高发区。测试通常选取边界值以及边界值的附近值。
**示例**:
在前述1到100之间的整数输入场景中,边界值可以是:
- 边界值:1, 100
- 边界附近值:0, 2, 99, 101
3. 决策表测试(Decision Table Testing)
**描述**:
决策表是一种系统地表示和分析复杂业务规则的方法,适用于有多种输入条件组合的情况。决策表列出了所有可能的输入条件及其对应的输出。
**示例**:
假设一个登录系统有两个输入条件:用户名和密码。决策表可能如下:
| 用户名有效 | 密码有效 | 输出 |
|------------|----------|----------------|
| 否 | 否 | 登录失败 |
| 否 | 是 | 登录失败 |
| 是 | 否 | 登录失败 |
| 是 | 是 | 登录成功 |
4. 状态迁移测试(State Transition Testing)
**描述**:
状态迁移测试适用于具有不同状态和状态之间转换的软件系统。通过测试不同状态之间的转换,确保系统在不同状态下的行为正确。
**示例**:
一个简单的自动售货机可以有以下状态:
- 空闲
- 接受硬币
- 选择商品
- 退币
- 出货
状态迁移测试会验证在每个状态下的行为以及状态之间的转换。
5. 场景测试(Scenario Testing)
**描述**:
场景测试通过模拟用户的实际使用场景,来验证软件在真实使用情况下的工作情况。这种方法特别适合用户体验和集成测试。
**示例**:
对于一个电商网站的购物车功能,一个测试场景可能包括:
- 用户登录
- 浏览商品
- 添加商品到购物车
- 修改购物车中的商品数量
- 结算并支付
6. 错误推测(Error Guessing)
**描述**:
错误推测依赖于测试人员的经验和直觉,通过推测可能发生错误的地方来设计测试用例。这种方法常用于发现潜在的隐蔽错误。
**示例**:
测试人员可能会猜测在用户输入特殊字符(如`$`、`%`、`#`)或极端数据(如空字符串、极长字符串)时,系统可能会出现问题。
### 7. 正交排列测试(Orthogonal Array Testing)
**描述**:
正交排列测试是一种系统的测试方法,用于减少测试用例的数量而不降低测试覆盖率。它通过数学模型来选择能覆盖所有参数组合的最小测试集。
**示例**:
假设有三个输入参数,每个参数有三个可能的值。正交排列测试会选择一组测试用例,使得所有参数组合尽可能被覆盖。
常用的黑盒测试工具:
Selenium:用于Web应用的自动化测试。
QTP/UFT:用于功能和回归测试的自动化工具。
Postman:用于API测试。
JMeter:用于性能测试和负载测试。
白盒测试:
定义:
- 白盒测试关注软件的内部结构和实现,测试人员需要了解代码逻辑,重点在于代码路径、循环和条件。
应用场景:
白盒测试用例关注软件的内部实现,测试代码逻辑、分支和路径。通常基于代码结构编写。
示例:成绩计算函数的白盒测试
假设我们在测试一个计算学生成绩的函数,代码如下:
def calculate_grade(score):
if score >= 90:
return "A"
elif score >= 80:
return "B"
elif score >= 70:
return "C"
elif score >= 60:
return "D"
else:
return "F"
测试用例
用例1:成绩为95
- 用例编号:WBT001
- 用例名称:成绩为95
- 前置条件:无
- 测试步骤:
- 调用函数
calculate_grade
,传入参数95
- 调用函数
- 预期结果:
- 返回
"A"
- 返回
适合使用白盒测试的情况
-
单元测试:
- 白盒测试广泛用于单元测试,开发人员对代码的每个单元(如函数、方法)进行彻底检查,确保逻辑正确。
-
代码覆盖率:
- 当你需要确保代码的所有路径、分支和条件都被测试覆盖时,白盒测试是必不可少的。
-
性能优化:
- 在需要进行代码优化或性能调优时,通过白盒测试可以深入了解代码的执行路径和瓶颈。
-
安全测试:
- 需要验证内部实现是否存在安全漏洞(如SQL注入、缓冲区溢出)时,白盒测试可以检查代码的潜在风险点。
-
复杂逻辑验证:
- 对于包含复杂算法或业务逻辑的代码,白盒测试有助于全面验证逻辑的正确性和健壮性。
几种常见的白盒测试方法:
1. 语句覆盖(Statement Coverage)
**描述**:
语句覆盖测试的目标是确保程序中的每个语句至少被执行一次。通过这种方式,可以发现一些基本的语法错误和异常。
**示例**:
```python
def check_even_odd(num):
if num % 2 == 0:
return "Even"
else:
return "Odd"
```
测试用例:
- 输入4,得到"Even"
- 输入5,得到"Odd"
2. 分支覆盖(Branch Coverage)
**描述**:
分支覆盖测试的目标是确保程序中每个条件分支(如`if`和`else`)至少被执行一次。通过测试所有分支路径,可以检查条件判断的正确性。
**示例**:
```python
def check_positive_negative(num):
if num > 0:
return "Positive"
elif num < 0:
return "Negative"
else:
return "Zero"
```
测试用例:
- 输入1,得到"Positive"
- 输入-1,得到"Negative"
- 输入0,得到"Zero"
3. 路径覆盖(Path Coverage)
**描述**:
路径覆盖测试的目标是确保程序中所有可能的执行路径都被测试过。这种方法比分支覆盖更严格,因为它不仅检查分支,还检查分支的组合路径。
**示例**:
```python
def complex_condition(a, b):
if a > 0:
if b > 0:
return "A and B are positive"
else:
return "A is positive, B is non-positive"
else:
return "A is non-positive"
```
测试用例:
- 输入a=1, b=1,得到"A and B are positive"
- 输入a=1, b=-1,得到"A is positive, B is non-positive"
- 输入a=-1, b=1,得到"A is non-positive"
4. 条件覆盖(Condition Coverage)
**描述**:
条件覆盖测试的目标是确保每个条件表达式的每个布尔子表达式都至少取过一次`True`和一次`False`值。这种方法可以发现复杂逻辑中的问题。
**示例**:
```python
def check_conditions(a, b):
if (a > 0 and b > 0):
return "Both positive"
else:
return "One or both non-positive"
```
测试用例:
- 输入a=1, b=1,得到"Both positive"
- 输入a=1, b=-1,得到"One or both non-positive"
- 输入a=-1, b=1,得到"One or both non-positive"
- 输入a=-1, b=-1,得到"One or both non-positive"
5. 多条件覆盖(Multiple Condition Coverage)
**描述**:
多条件覆盖测试的目标是确保每个条件表达式中所有可能的布尔子表达式组合都被测试过。这种方法比条件覆盖更严格。
**示例**:
```python
def check_multi_conditions(a, b):
if (a > 0 or b > 0):
return "At least one positive"
else:
return "Both non-positive"
```
测试用例:
- 输入a=1, b=1,得到"At least one positive"
- 输入a=1, b=-1,得到"At least one positive"
- 输入a=-1, b=1,得到"At least one positive"
- 输入a=-1, b=-1,得到"Both non-positive"
6. 循环覆盖(Loop Coverage)
**描述**:
循环覆盖测试的目标是确保程序中的每个循环结构(如`for`、`while`)在不同的循环次数下(如0次、1次、多次)都被测试过。这种方法有助于发现循环相关的错误。
**示例**:
```python
def sum_up_to(n):
total = 0
for i in range(n):
total += i
return total
```
测试用例:
- 输入n=0,循环执行0次
- 输入n=1,循环执行1次
- 输入n=5,循环执行多次
7. 数据流测试(Data Flow Testing)
**描述**:
数据流测试的目标是检查程序中变量的定义和使用是否正确。它关注变量在代码中的生命周期,从定义、赋值到最后使用。
**示例**:
```python
def compute_sum(a, b):
sum = a + b # 定义和赋值
return sum # 使用
```
测试用例:
- 输入a=2, b=3,检查sum的定义和使用
常用的白盒测试工具
JUnit:用于Java应用的单元测试框架。
pytest:用于Python应用的单元测试框架。
CUnit:用于C语言的单元测试框架。
Emma、Jacoco**:用于Java的代码覆盖率分析工具。
gcov:用于C/C++代码覆盖率分析。
白盒测试方法多种多样,每种方法都有其特定的目标和适用场景。通过合理选择和组合这些测试方法,可以深入验证软件的内部逻辑和实现,确保代码的质量和可靠性。
面试问题:
项目用例类(功能测试):
通过场景法和等价类划分,详细讲解了如何针对功能点设计测试用例,特别是针对淘宝购物车等常见功能的测试设计。
给你一个功能让你去设计测试用例?
微信发红包?
淘宝购物车?
你发现的最严重的bug
边界值问题?第三方接口问题?
遇见的最印象深刻的bug?
之前的测试因为偷懒只测试了一天的发放数据,没有去跑批,小伙伴们切记,跟时间周期相关的功能一定要多跑几个周期
工作流程类
详细介绍了从需求评审到项目上线的整个测试流程,包括测试计划的制定、测试用例的编写、bug的跟踪和测试报告的编写。
之前的测试因为偷懒只测试了一天的发放数据,没有去跑批,小伙伴们切记,跟时间周期相关的功能一定要多跑几个周期
测试流程
产品组织开发和测试进行需求评审(熟悉需求或提意见),
制定测试计划(什么人、怎么测试、测试多久),
开发完成接口后制作接口测试,
功能测试(提BUG、修复BUG),
专项测试(弱网测试、兼容测试、安全测试、回归测试)
编写测试报告
线上发布后再进行线上验证测试
注:功能测试可展开为:
有效情况、无效情况(商品限购后还是否能继续添加),边界值测试
**处理开发不认可的bug**:提供了不同情况下的应对策略,如通过演示bug、与开发领导沟通或寻求产品明确需求等方法。
- 📈 **应对产品需求变更**:讨论了在不同时间点遇到需求变更时的应对措施,包括建议延期发布、在测试报告中记录变更影响等。
测试技术类