128 lines
3.3 KiB
Markdown
128 lines
3.3 KiB
Markdown
---
|
||
title: 测试方法
|
||
date: 2023-04-12 14:57:27.964
|
||
updated: 2023-04-13 07:58:41.373
|
||
url: /archives/ceshifangfa
|
||
categories:
|
||
- 软件测试
|
||
tags:
|
||
- 测试基础
|
||
---
|
||
|
||
## 黑白灰测试
|
||
|
||
### 黑盒测试
|
||
|
||
根据外在特性展开测试，只知道被测对象外在特性，不知道内部实现细节
|
||
- 系统测试的主要依据是需求规格
|
||
- 需求规格告诉我们软件的功能
|
||
- 系统测试主要采用黑盒测试
|
||
|
||
### 白盒测试
|
||
|
||
根据内部结构开展测试，只知道被测对象内部实现细节，不知道外在特性
|
||
|
||
- 单元测试的主要依据是详细设计
|
||
- 详细设计主要是函数的内部逻辑，也有函数的功能
|
||
- 单元测试根据函数内部结构和功能开展测试，主要采用白盒测试
|
||
|
||
### 灰盒测试
|
||
|
||
同时根据外在特性和内部结构开展测试。既知道外在特性，也知道内部实现细节。
|
||
|
||
- 集成测试的主要依据是概要设计
|
||
- 概要设计有每个模块的功能（外在特性），和每个模块内部有哪些函数（内部结构）
|
||
- 集成测试根据模块功能以及内部组成来开展测试，采用灰盒测试
|
||
|
||
## 静态动态测试
|
||
|
||
### 静态测试
|
||
|
||
不执行被测对象进行测试
|
||
|
||
**分类**
|
||
|
||
- 人工静态测试 同行评审
|
||
- 自动化静态测试 代码编译
|
||
|
||
**测试对象** 需求规格，概要设计，详细设计，代码，用户手册，帮助
|
||
|
||
### 动态测试
|
||
|
||
执行被测对象进行测试
|
||
|
||
**分类** 功能测试，性能测试，安全性测试，可靠性测试，语句覆盖测试
|
||
|
||
**测试对象** 代码，程序
|
||
|
||
## 人工自动化测试
|
||
|
||
### 人工测试
|
||
|
||
人工测试是自动化测试的基础
|
||
|
||
### 自动化测试
|
||
|
||
重复性高、技术难度低的工作可交给电脑完成
|
||
|
||
- 测试工作的特点
|
||
|
||
- 编写测试计划
|
||
|
||
只做一次，后面修改。不同人的测试计划差异很大。
|
||
|
||
- 编写测试方案
|
||
|
||
不同人的测试方案差异大。重复性不高，技术难度高。
|
||
|
||
- 编写测试用例
|
||
|
||
不同人的测试用例有差异。重复性不是很高，技术难度较高。
|
||
|
||
- 搭建测试环境
|
||
|
||
按照环境搭建手册搭建环境。不同人需要搭建相同的环境。重复性较高，技术难度中等。
|
||
|
||
**比较适合自动部署**
|
||
|
||
- 执行测试用例
|
||
|
||
按照步骤执行，会执行多次。重复性高，技术难度低。
|
||
|
||
**最适合自动化测试**
|
||
|
||
- 自动化测试优点
|
||
|
||
- 确保软件之前正常的功能没有问题
|
||
- 提高回归测试效率
|
||
- 具有很好的一致性
|
||
|
||
- 自动化测试局限性
|
||
|
||
- 当界面发生变化或者位置发生变化时，脚本失效
|
||
- 脚本维护工作量大大增加
|
||
- 无法提高测试效果
|
||
- 很难发现新的问题
|
||
|
||
- 自动化测试何时引入
|
||
|
||
- **界面不发生变化时可引入**
|
||
- **需要重复执行10次以上**
|
||
|
||
- 狭义自动化测试
|
||
|
||
- 用自动化测试脚本替代人做执行
|
||
|
||
- 广义自动化测试
|
||
|
||
- 四个活动是否可以利用计算机替代人的工作
|
||
- 测试计划（自动分工）
|
||
- 测试设计实现（测试用例自动生成）
|
||
- 测试执行（测试环境自动搭建部署，测试用例自动执行）
|
||
|
||
- 自动化测试工具
|
||
|
||
- 基于图形用户界面（GUI）的自动化测试：Selenium，Appium，QTP
|
||
- 基于应用程序接口（API）的自动化测试：Postman，SoapUI，JMeter
|
||
|