软件测试学习笔记

简介: 《软件测试的艺术》学习笔记 第一章 一次自评价测试 软件测试就是一个过程或者一系列过程,用来确认计算机代码完成了其应该完成的功能,不执行其不该有的操作。 第二章 软件测试的心理学和经济学 1 软件测试更适宜被称为试图发现程序中的错误(假设其存在)的破坏性的过程。 2 黑盒测试:一种重要的测试策略,又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时,将程序视为一

《软件测试的艺术》学习笔记

第一章 一次自评价测试

软件测试就是一个过程或者一系列过程,用来确认计算机代码完成了其应该完成的功能,不执行其不该有的操作。

第二章 软件测试的心理学和经济学

1 软件测试更适宜被称为试图发现程序中的错误(假设其存在)的破坏性的过程。

2 黑盒测试:一种重要的测试策略,又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时,将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关,而是将重点集中放在发现程序不按其规范正确运行的环境条件。——穷举测试

3 白盒测试,也称逻辑驱动的测试,允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查,从中获取测试数据(遗憾的是,常常忽略了程序的规范)。——穷举路径测试

4 回归测试:保留测试用例,当程序其他部件发生更动后重新执行。

第三章 代码检查、走查与评审

1 代码检查、走查以及可用性测试是三种主要的人工测试方法。

2 代码检查是以组为单位阅读代码,它是一系列规程和错误检查技术的集合。




3 代码走查与代码检查类似,都是以组为单位……。

第四章 测试用例的设计

软件测试的关键问题是:在所有的测试用例中,哪个子集最有可能发现最多的错误?

白盒测试

1 逻辑覆盖测试:有价值的目标就是将程序的每条语句至少执行一次。

2 逻辑覆盖准则:判定覆盖准则(分支覆盖)和条件覆盖准则

3 判定覆盖准则要求必须编写足够的测试用例,使得每一个判断都至少有一个为真和为假的输出结果。

4 比判定覆盖更强一些的准则是条件覆盖。在条件覆盖情况下,要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。

5 判定/条件覆盖准则要求设计出充足的测试用例,将一个判断中的每个条件的所有可能的结果至少执行一次,将每个判断的所有可能的结果至少执行一次,将每个入口点都至少调用一次。

6 多重条件覆盖准则要求编写足够多的测试用例,将每个判定中的所有可能的条件结果的组合,以及所有的入口点都至少执行一次。

7 在存在循环的情况下,多重条件覆盖准则所需要的测试用例的数量通常会远远小于其路径的数量。

总结:对于包含每个判断只存在一种条件的程序,最简答的测试准则就是设计出足够多的测试用例,实现:(1)将每个判断的所有结果都至少执行一次;(2)将所有的程序入口都至少调用一次,以确保全部的语句都至少执行一次。而对于包含多重条件判断的语句,最简单的测试准则就是设计出足够数量的测试用例,将每个判断的所有可能的条件组合的结果,以及所有的入口点都至少执行一次(加入“可能”二字,是因为有些组合情况难以生成)。

黑盒测试

1 使用等价划分方法设计测试用例主要有两个步骤:(1)确定等价类;(2)生成测试用例。

2 确定等价类是选举每一个输入条件,并将其划分为两个或更多的组。

  如果有任何理由可以认为程序并未等同的处理等价类中的元素,那么应该将这个等价类再划分为小一些的等价类。

3 边界值分析方法与等价划分方法存在两方面的不同:

(1)      与从等价类中挑选出任意一个元素作为代表不同,边界值分析需要选择一个或多个元素,以便等价类的每个边界都经过一次测试。

(2)      与仅仅关注输入条件不同,还需要考虑从结果空间设计测试用例。

4 因果图:通过生成布尔图来诠释测试用例的所有可能结果,使用该法旨在帮助选择那些有效地测试用例达到比较完整的测试用例设计结果。

错误猜测

错误猜测的基本思想是列举出可能犯的错误或错误易发情况的清单,然后依据清单来编写测试用例。

测试策略

1 如果规格说明中包含输入条件组合的情况,应首先使用因果图分析方法。

2 在任何情况下都应使用边界值分析方法。

3 应为输入和输出确定有效和无效等价类,在必要情况下对上面确认的测试用例进行补充。

4 使用错误猜测技术增加更多的测试用例。

5 针对上述测试用例检查程序的逻辑结构。

第五章 模块(单元)测试

1 模块测试是对程序中的单个子程序、子程序或过程进行测试的过程。

2 模块测试总体上是面对白盒测试的。

3 模块测试中测试用例的设计过程如下:使用一种或者多种白盒测试方法分析模块的逻辑结构,然后使用黑盒测试方法对照模块的规则说明以补充测试用例。


第六章 更高级别的测试

软件开发过程在很大程度上是沟通有关最终程序的信息、并将信息从一种形式转换到另一种形式。由于这个原因,绝大部分软件错误都可以归因为信息沟通和转换时发生的故障、差错和干扰。

目录
相关文章
|
Web App开发 JavaScript 前端开发
NB-loT 之通过 Iwm2m 服务器测试 Coap 协议报文 | 学习笔记
快速学习 NB-loT 之通过 Iwm2m 服务器测试 Coap 协议报文
404 0
NB-loT 之通过 Iwm2m 服务器测试 Coap 协议报文 | 学习笔记
|
2月前
|
Java 测试技术 编译器
JMM测试利器-JCStress学习笔记
JMM测试利器-JCStress学习笔记
|
8月前
java202303java学习笔记第四十六天-请求-postman接口测试
java202303java学习笔记第四十六天-请求-postman接口测试
54 0
|
11月前
|
测试技术
java202304java学习笔记第六十天-ssm-spring配置文件-完善测试环境
java202304java学习笔记第六十天-ssm-spring配置文件-完善测试环境
52 0
|
关系型数据库 OLAP API
测试 API|学习笔记
快速学习测试 API
117 0
测试 API|学习笔记
|
存储 SQL 监控
PolarDB-X 进行 TP 负载测试(三)| 学习笔记
快速学习 PolarDB-X 进行 TP 负载测试。
300 0
PolarDB-X 进行 TP 负载测试(三)| 学习笔记
|
SQL 存储 关系型数据库
PostgreSQL 流复制搭建主从环境,同步和异步的解释,压力测试,主从角色切换|学习笔记
快速学习PostgreSQL 流复制搭建主从环境,同步和异步的解释,压力测试,主从角色切换
724 0
PostgreSQL 流复制搭建主从环境,同步和异步的解释,压力测试,主从角色切换|学习笔记
|
数据可视化 Dubbo Java
MSE 微服务测试---自动化回归最佳实践|学习笔记
快速学习 MSE 微服务测试---自动化回归最佳实践
292 0
MSE 微服务测试---自动化回归最佳实践|学习笔记
|
存储 SQL 监控
27 Postgre sql 建模,压力测试|学习笔记
快速学习27 Postgre sql 建模,压力测试
338 0
27 Postgre sql 建模,压力测试|学习笔记
|
数据采集 运维 安全
全方位的测试质量守护体系,保障交付质量|学习笔记
快速学习全方位的测试质量守护体系,保障交付质量
310 0
全方位的测试质量守护体系,保障交付质量|学习笔记