测试理论与方法----测试流程的第二个环节：测试计划

最新推荐文章于 2024-08-24 18:02:17 发布

叫我王同学

最新推荐文章于 2024-08-24 18:02:17 发布

阅读量149

点赞数

分类专栏：软件测试文章标签：单元测试测试用例功能测试

本文链接：https://blog.csdn.net/qq_44985444/article/details/132587107

版权

软件测试专栏收录该内容

17 篇文章 6 订阅

订阅专栏

二、软件测试分类与测试计划

1、软件测试的分类(理解掌握)

根绝需求规格说明书，在设计阶段会产出的两个文档：
- 概要设计(HLD)：设计软件的结构，包含软件的组成，模块之间的层次关系，模块与模块之间的调用关系，每个模块的功能等。（大范围描述）
- 详细设计(LLD)：在概要设计的基础上，为每个功能模块做详细的描述，把功能转换为详细，精准化的过程。
按照【开发阶段】划分：
- 单元测试：又被称为“模块测试”，是针对程序的每个模块进行正确性检验的测试工作，目的在于检查程序的每个模块是否能够正确实现详细设计文档中给出的需求。
- 集成测试：又称为“组装测试”，在单元测试基础上，逐步将程序所有的模块有序，递增的集成在一起，最终满足概要设计文档给出的需求。
- 确认测试：又被称为“有效性测试”，验证软件的功能，性能，其他的特性是否和用户的预期结果一致。只有通过确认测试，才会进入系统测试阶段。
- 系统测试：在真实的环境下，运行被测软件，检测软件能否和不同的系统平台相匹配或配置，从而满足用户的需求。
- 验收测试：是检测产品的最后一个环节，根据双方签订的协议，合同书，任务书，交付依据等等，做最后的测试与评审，从而决定接收或拒收产品。（第三方/外包）
按照【测试技术】划分：
- 黑盒测试：把被测对象看成是黑色的盒子，通过程序的外部表现发现错误和缺陷，完全不考虑程序的内部结构，只在程序的界面处进行测试，来检查程序的功能是否符合需求（功能测试）
- 白盒测试：把被测对象看成是透明的盒子，通过对程序内部的结构分析，来发现问题，关注程序内部结构的实现是否正确，所以又被称为“结构测试”
- 灰盒测试：白+黑，既要关注程序的功能(外部表现)，又要关注程序的内部结构
按照【代码运行】划分：——>看程序是否运行
- 静态测试：指的是不实际运行被测对象，只是静态观察代码，界面，文档的正确性。
  - 代码测试：主要检测代码是否符合标准和规范
  - 界面测试：主要检测软件的实际界面与需求说明是否相符合
  - 文档测试：主要测试用户手册和需求文档是否满足用户的实际需求
- 动态测试：指的是实际运行被测对象，通过输入相关的测试数据，来观察实际结果和预期结果是否一致。
按照【软件特性】划分：
- 功能测试：属于黑盒测试一部分，检测软件的功能是否符合用户的需求，以及功能结果的正确性。比如：易用性测试，界面测试，安装、卸载测试，兼容性测试等
- 性能测试：除了功能测试外，另一个测试指标。一个程序除了能够正确实现对应的功能外，还要考虑到功能实现的响应时间，处理速度，承受的负载压力等
- 安全测试：检测系统中嵌入的保护机制，是否真正能够提供保护功能，防止非法入侵，数据丢失等问题
其他测试类型：
- 回归测试：①验证提交的缺陷已经被修复；②确保修复了旧的缺陷没有引发新的缺陷
  - 方式之一：按照之前设计好的测试用例(测试场景)再执行一遍
- 冒烟测试：是在正式进入测试流程前，对软件的可测性进行评判的依据，先来验证软件是否具备可测性的操作，所以也叫做“可测性测试”，只有通过了冒烟测试，才会进入到正式的测试流程中。
- 随机测试：是测试人员根据经验和直觉，再来发现一些边缘性的缺陷
- Monkey测试：把测试人员看成“小白”，对被测软件进行任意随机的操作，看软件多长时间会出现异常（比如，程序未响应ANR），主要测试程序的稳定性，属于移动端自动化测试手段

2、软件测试的原则

所有测试标准是建立在用户需求之上
时间服从于质量
事先定义好测试的标准
不能穷举测试（把软件功能可能会出现的情况全部测一遍，比如：测试计算器的加法功能：把所有的数字全部加一遍——>不现实）
第三方测试更为客观和有效（毕竟第三方是专门做测试，接触的产品类型和测试经验会更多一些；可以让本公司的测试人员能够安排其他的任务，节约了公司的人力成本）
测试计划是做好测试工作的前提
对于错误发现较多的地方，重点关注（缺陷集群效应）
尽早的和不断地测试
妥善保存测试文档
测试应该从“小规模”，逐步转向到“大规模”
对测试错误的结果要有一个确认的过程

测试流程的第二个环节：测试计划

3、测试计划的概述

定义：test plan：规定了测试的活动范围，方法，资源，进度安排；明确正在测试的项目，要测试的特性，要执行的测试任务，每个任务的负责人，以及和计划相关的风险。
编写测试计划的原则：5W1H
- what：测什么，明确测试范围和内容
- why：为什么要测试，测试的目的
- who：谁来测，测试人员的分配
- where：在哪测，测试环境
- when：测试开始的时间和结束的时间
- how：如何测，测试方法和工具

4、测试计划的编写

备注：形式：一个小组出一份，但是每个人都会参与到计划书的编写过程

测试项目的简介
1. 描述测试计划文档的目的
2. 描述项目背景
3. 产品介绍（核心功能）
4. 预期用户（面向的阅读者）
5. 项目功能的说明（每一个模块的说明）
测试参考文档
1. 项目相关的文档（需求文档，说明书，计划书，合同书…）
2. 专业书籍
3. 技术论坛文章
测试提交文档
1. 概述：测试过程中要产出的文档
2. 测试用例：“怎么测”，证明测试的深度，广度
3. 缺陷报告：证明测试的成果
4. 测试报告：整理本轮测试所做的事情
  
  关键在于：做好模板统一
专业术语
1. 测试技术相关的专业术语
2. 业务层面的专业话术（金融，医疗，军工，银行…）
3. 和开发相关的专业术语（基本上可以忽略）
测试策略（最核心的模块）
1. 根据【模块】来明确测试范围和测试类型：
  
  可以按照系统的模块来进行划分，制定测试策略：
  
  系统模块1：功能测试，性能测试，安全测试…
  
  系统模块2：功能测试，UI界面测试…
  
  系统模块3：功能测试，性能测试，易用性测试，兼容性测试…
  
  ……
2. 可以按照【测试类型】来进行划分，制定测试策略
  
  功能测试：系统模块1，系统模块2，系统模块3…
  
  性能测试：系统模块1，系统模块3…
  
  界面测试：系统模块1，系统模块2…
  
  ……
3. 测试范围
  
  测试范围和测试策略是相辅相成，根据明确的系统模块，整理出对应的(功能)测试点
  
  例：信贷系统：用户管理模块：筛选功能，修改功能，删除功能，添加功能…
4. 测试方法和工具
  
  测试过程中会采用的一些测试方法，使用的一些测试工具
  
  例：进行功能测试时，用到的方法：等价类边界值，场景法…；进行性能测试时，用到的工具：LR…
5. 测试进入和退出的标准
  
  ①测试进入标准：当达到某一个目标时，就进行测试
  
  例：当程序的一个模块被开发出来时，就可以进行单元测试
  
  ②测试退出标准：当实现某一个目标时，就可以退出测试
  
  例：当每个模块的检测无误时，就可以退出单元测试
资源
1. 硬件资源：被测项目所需要的最低环境资源支持
2. 软件资源：比如服务器版本，数据库版本…
3. 网络资源：5G 4G WIFI…
  
  上述三点，都属于测试环境资源
4. 人力资源：设定好参与测试的人员，明确分工，哪些人做哪些事情(角色+职责)
5. 设定里程碑事件：在既定的时间节点要完成既定的任务
测试计划中的风险（风险分析）
1. 市场：比如目前市场上同类型竞争产品较多
2. 人员：比如请假，离职….
3. 项目开发和需求：比如需求变更…
4. 技术层面：比如参与人员技术有限…