118 lines
2.9 KiB
Markdown
118 lines
2.9 KiB
Markdown
---
|
||
title: 软件测试
|
||
date: 2023-02-21 20:14:58.891
|
||
updated: 2023-04-11 18:27:44.423
|
||
url: /archives/testbase01
|
||
categories:
|
||
- 软件测试
|
||
tags:
|
||
- 测试基础
|
||
---
|
||
|
||
# 测试基础
|
||
|
||
## 什么是软件测试
|
||
|
||
**软测定义：**软件测试是对软件的认知活动。软件测试不仅仅是发现缺陷，测试不一定要运行软件。
|
||
|
||
**软测目的：**
|
||
|
||
- 证明 证明软件可用
|
||
- 检测 检测软件的质量，发现软件的缺陷，错误和不足
|
||
- 预防 预防缺陷的产生
|
||
|
||
**不同阶段测试的目的：**
|
||
|
||
- 项目早期 预防缺陷的产生
|
||
- 1. 项目计划评审
|
||
- 2. 需求文档评审
|
||
- 3. 设计文档的评审
|
||
- 4. 测试用例文档的评审
|
||
- 项目中期 先发现严重的缺陷，让软件尽快稳定
|
||
- 项目后期 证明软件的功能都实现，可用正常使用
|
||
|
||
## 什么是缺陷
|
||
|
||
### 缺陷、故障、失效的区别
|
||
|
||
- **缺陷是软件内隐藏的问题**
|
||
- 缺陷诱发出来产生故障
|
||
- 故障不能很好处理就可能导致失效
|
||
|
||
### 缺陷分类
|
||
|
||
- 额外实现 做多了，需求里没有的功能实现了
|
||
- 实现缺失 做少了，需求里有的功能没有实现
|
||
- 实现错误 做错了，需求里的功能实现了，但和预期不一致
|
||
|
||
|
||
|
||
## 软件生命周期
|
||
|
||
### 计划
|
||
|
||
项目经理输出项目计划
|
||
|
||
主要内容：项目目标，大致需求，人员安排，时间安排等等内容
|
||
|
||
### 需求分析
|
||
|
||
产品/需求输出**需求规格说明书（SRS）**
|
||
|
||
- 进一步确定用户的需求
|
||
- 软件功能的具体描述
|
||
- 解决系统 **做什么** 的问题
|
||
|
||
### 设计
|
||
|
||
架构师输出**概要设计文档**，资深开发输出**详细设计文档**
|
||
|
||
- 软件-子系统-模块-函数
|
||
- 解决系统 **怎么做** 的问题
|
||
|
||
### 编码
|
||
|
||
开发实现编写代码实现产品功能
|
||
|
||
### 测试
|
||
|
||
测试输出**测试计划、测试方案、测试用例、测试结果、缺陷报告、测试报告**
|
||
|
||
- 检查软件的实现是否和需求一致
|
||
- 检查软件的实现是否有遗漏
|
||
|
||
### 运维
|
||
|
||
运维工程师：
|
||
|
||
技术支持：系统的安装，部署，升级，问题排查
|
||
|
||
# 瀑布模型
|
||
|
||
**串行的顺序流程**
|
||
|
||
- 从计划到维护
|
||
- 重视文档，上一阶段输出的文档是下一阶段的输入。
|
||
- 一个阶段完成，资源会大部分释放给其他项目。一般资源是多项目共享。
|
||
- 一个阶段发现的问题，返回上一个阶段解决。
|
||
- 适合需求在项目初始阶段可以明确的周期较长的项目
|
||
- 可以运行在软件在项目后期才能拿到
|
||
|
||
分成三个阶段：
|
||
|
||
- 定义阶段 计划和需求分析
|
||
- 开发阶段 设计，编码和测试
|
||
- 维护阶段 运行维护
|
||
|
||
|
||
|
||
|
||
## 螺旋模型
|
||
|
||
**串行的顺序流程**
|
||
|
||
- 分阶段实现功能，每个功能的开发都是采用瀑布模型
|
||
- 较早可以看到能运行的软件
|
||
- 一个原型完成后，经过风险评估进行进行下一个原型的开发
|
||
|
||
 |