软件测试的分类

比眉伴天荒 2023-06-17 04:53 5阅读 0赞

# 软件测试的分类 #

## 1. 按照软件测试的阶段分 ##

### 1.1. 单元测试 ###

单元测试又称为模块测试，是针对软件测试中最小单位——程序块，进行正确性的检查

### 1.2. 集成测试 ###

又叫组装测试，是在单元测试的基础上，将程序模块进行有序的、递增的测试。重点测试不同模块之间的接口部分

##### 1.2.1 集成测试的过程 #####

1.  构建确认过程
2.  补丁的确认过程
3.  系统集成测试测试组提交过程
4.  测试用例编写
5.  测试代码编写过程
6.  Bug的报告过程
7.  每周构建过程
8.  点对点测试
9.  组内培训

### 1.3. 系统测试 ###

将软件系统看做一个整体来测试。包括功能，性能以及运行是软硬件环境进行测试。

##### 1.3.1 功能测试 #####

验证当前软件的主体功能是否可用。

##### 1.3.2 兼容测试 #####

验证当前软件在不同的环境下是否还可以使用。

##### 1.3.3 安全测试 #####

验证软件是否是能授权用户提供功能使用。

##### 1.3.4 性能测试 #####

相对于当前软件消耗的资源，它的产出能力。

### 1.4. 验收测试 ###

##### 1.4.1. α测试 #####

Alpha 是内测版本，即现在所说的CB，此版本表示该软件仅仅是一个初步完成品, 通常只在软件开发者内部交流, 也有很少一部分发布给专业测试人员。一般而言, 该版本软件的bug 较多, 普通用户最好不要安装。

##### 1.4.2. β测试 #####

Beta是公测版本，是对所有用户开放的测试版本。该版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过大规模的发布测试来进一步消除。

##### 1.4.3. γ测试 #####

Gamma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了, 与即将发行的正式版相差无几, 成为正式发布的候选版本。

## 2. 按是否覆盖源代码 ##

### 2.1. 黑盒测试 ###

黑盒测试有成为结构测试，不关心程序内部结构特征，注重软件功能需求，只关心软件的**输入数据与输出数据**。

##### 2.1.1 黑盒测试常见错误分类 #####

1.  功能不对或或者功能遗漏
2.  界面错误
3.  数据库访问或者处理错误
4.  性能问题等

##### 2.1.2. 黑盒测试的优点 #####

1.  测试人员不需要了解实现得细节，包括特定的编程语言（没有编程经验的人也可以设计测试用例）；
2.  测试人员和编程人员是相互独立的（黑盒测试用例设计与程序如何实现无关）；
3.  从用户的角度进行测试，很容易被接受和理解；
4.  有助于暴露任何与规格不一致或者歧异的地方；

##### 2.1.3. 黑盒测试的缺点 #####

1.  不能测试程序内部特定部位；
2.  如果程序未执行的代码无法发现；
3.  不可能做到穷举测试

##### 2.3.4. 黑盒测试的分类 #####

1.  功能测试
    
    1.  逻辑功能测试
    2.  界面测试
    3.  易用性测试
    4.  安装测试
    5.  兼容性测试
2.  性能测试
    
    1.  时间性能（事务响应时间）
    2.  空间性能（系统资源消耗）
    3.  一般性能测试
    4.  稳定性
    5.  负载测试
        
        通过负载测试来确定在各种工作负载下，系统各项性能指标的变化情况。
    6.  压力测试
        
        通过确定一个系统的瓶颈或者刚好不能接受的性能点，来获得系统能够提供的最大服务级别。

### 2.2. 白盒测试 ###

白盒测试需要知道程序的内部结构，去研究源代码。

##### 2.2.1. 白盒测试优点 #####

1.  测试人员需要去仔细的思考软件的实现；
2.  可以检测代码中的每条分支和路径；
3.  可以揭示隐藏在代码中的错误；
4.  对代码的测试比较彻底；

##### 2.2.2 白盒测试缺点 #####

1.  测试代价昂贵；
2.  无法检测代码中遗漏的路径和数据敏感性错误；
3.  是不验证规格的正确性。

### 2.3. 灰盒测试 ###

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，既可保证黑盒的关注点又可掌控白盒的内部结构，但不会去对内部程序功能和运作做详细了解，灰盒测试结合了白盒测试和黑盒测试的要素。

## 3. 按照是否运行来分 ##

### 3.1 静态测试 ###

不运行测试软件，静态的检查代码、界面、文档中可能存在的错误。

### 3.2 动态测试 ###

指实际运行被测软件，输入相应的测试数据，检查实际输出结果与预期输出结果是否相等的过程。

## 4. 是否自动化测试 ##

### 4.1 人工测试 ###

人工测试是由测试人员手工逐步执行，所有的活动并观察每一步是否成功完成，主要包含**走查**、**审查**和**正式评审**。

### 4.2 自动化测试 ###

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。

### 4.3 自动化测试与人工测试比较 ###

##### 4.3.1自动化测试的优势 #####

1.  自动化测试可以执行手工测试相当困难或根本做不到的测试
2.  自动化测试具有一致性和可重复性
3.  自动化脚本完全可复用
4.  自动化测试使软件更有信任度
5.  自动化测试适合做兼容性测试
6.  自动化测试使回归测试更方便、可靠

##### 4.3.2自动化测试的劣势 #####

1.  手工发现的缺陷远远比自动化测试得多
2.  自动化测试对测试人员的技术要求较高
3.  自动化测试成本投入高、风险大
4.  自动化测试是死的，不具有情感
5.  自动化测试完全不可能取代手工测试

## 4. 其他划分 ##

### 4.1 回归测试 ###

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

### 4.2 冒烟测试 ###

这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

### 4.3 随机测试 ###

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressivetesting)一起进行。