1.两种分类,四种方法:
白盒测试:需要知道软件内部是怎么运行的
静态测试:测试软件不运行的部分--(只是检查和审核)
动态测试:测试软件要运行的部分--(使用和运行软件)
类比:
假如二手车是一个软件,检查二手车过程中:
静态测试指的是踢一下轮胎、看看车漆、打开引擎盖。
动态测试是的是发动汽车、听听发动机的声音、上路行驶。
两种分类方式测试方法的组合就可以形成四种测试方法--静态黑盒测试,动态黑盒测试,静态白盒测试,动态白盒测试。
2 静态黑盒测试---检查产品说明书
2.1 对产品说明书进行高级审查
这更像是研究而不是测试,但是研究的根本是为了更好地了解软件该做什么和怎么做,这样可以更好地进行细节检查。
- 假设自己是客户
- 研究现有的标准和规范
- 审查和测试类似软件
2.2 对产品说明书进行低层次测试
产品说明书属性检查清单
- 完整
- 准确
- 精确
- 一致
- 贴切
- 合理
- 代码无关
- 可测试性
产品说明书术语检查清单
- 总是、每一种、所有、没有、从不 看到绝对的词语,要确认是这样的,然后还要考虑违反这些情况的用例
- 当然、因此、明显、显然、必然 这些话意图说服你接受这些假定,不要中了圈套。
- 某些、优势、常常、通常、惯常、经常、大多、几乎 太过于模糊,那么无法测试。
- 等等、诸如此类、以此类推、例如 无法确定具体有哪些,那么无法测试,功能清单要绝对或者解释明确
- 良好、迅速、廉江、高效、小、稳定 无法量化的术语,那么无法测试
- 处理、进行、拒绝、跳过、排除 这些用于隐含了很多需要大量说明的功能,怎么处理?怎么进行?...
- 如果...那么...(没有否则) 想一想“如果”没有发生会怎么样
3.动态黑盒测试--戴上眼罩测试软件
假如没有产品说明书那就得
把软件当做是产品说明书来对待,系统地逐项了解的功能、记录软件的执行情况、详细描述功能。
通过性测试和失效性测试
通过性测试:确认软件
至少可以做什么,而不考验它的能力。软件测试员并不需要想尽办法让软件崩溃,仅仅运行最简单、最直观的测试用例。
失效性测试:纯粹是为了破坏软件而设计和执行测试用例,即
想尽办法让软件崩溃。
错误提示信息既属于通过性测试,又属于失效性测试;
例如:没有在软驱中插入磁盘而想软盘中保存文件。
原因是:产品规格说明书可能说明某些输入会有错误提示信息,那么这种情况下属于通过性测试;
同时,由于是迫使软件出错(没有磁盘却保存文件),所以也可视为失效性测试。
等价类划分:
数据测试:
通过性测试:
- 边界条件:例如允许输入1~255个字符,那么就输入1个字符和255个字符,还可输入0个和2个,254个和256个字符试一试软件会怎么运行行
- 次边界条件:2的幂,ASCII码表 例如:允许输入1~1000内的数字,那么尝试着输入2的幂的次边界,例如14,15,16和154,255,256等等
- 默认、空白、控制、零值和无;
失效性测试:
非法、错误、不正确和垃圾数据
状态测试:
通过状态测试:
- 建立状态转换图(一般设计文档已有);
- 减少要测试的状态及转换的数量(等价类划分);
- 具体每个状态的变量值是什么;
失效状态测试:
- 竞争条件和时序错乱:例如:两个程序同时保存和打开同一文件这种竞争条件会不会导致软件运行时序错乱(状态错乱)。
- 重复、压迫和负载测试(三者可同时进行)
压迫:尽量
限制软件的资源(如内存空间等),看看软件是否还可以正常运行。
负载:与压迫测试相反,负载测试尽量
提供软件所需的资源,看看它的负载能力,例如:网站连接1000个用户,看它是否会崩溃。
时间也是一种负载测试,某些软件应该恩能够永远运行下去,而不用重新启动。
其他黑盒测试方法:
- 像笨拙的用户那样做
- 在已经找到缺陷的地方再找找
- 像黑客那样思考问题:想想软件有价值的东西在哪里,为什么有人(黑客)想获得它的访问权限。
4.动态白盒测试---检查设计和代码
正式审查
- 同事审查--最不正式的审查
- 走查--中等的审查
- 检验--最正式的审查
通过代码审查清单
- 数据引用错误
- 数据声明错误
- 计算错误
- 比较错误
- 控制流程错误
- 子程序参数错误
- 输入输出错误
其他检查:
- 是否有外语?如何处理扩展字符?统一编码取代ASCII编码?
- 是否要移植?考虑了兼容性?
- 编译是否产生“警告”或者“提示”信息?
5.动态白盒测试---带上X光眼睛测试软件
动态白盒测试和调试的区别:目标不一样
动态白盒测试的目标:
寻找软件缺陷
调试的目标:
修复缺陷
但是两者在
隔离软件缺陷的位置和原因确实
存在交叉现象。
单元测试和集成测试:
术语 | 测试方向 | 作用方式 | 举例 |
测试驱动 | 自底向上 | 替换高级模块(对于要测试的低级模块,驱动输入数据(参数)使其更有效地运行) | 如下图 |
测试桩 | 自顶向下 | 替换低级模块(对于要测试的高级模块,桩的外表和行为就像低级模块一样) | 如下图 |
数据覆盖:
- 数据流:调试器可以看到变量在运行的每一步的值
- 次边界:例如:计算税收的模块在某些财务结算处可能从使用数据表转换到使用公式
- 公式和等式:
- 错误强制:正常运行中不会出现的值,我们要强制设置让错误提示信息显示。
代码覆盖:
- 语句覆盖:
- 分支覆盖:
- 条件覆盖:
语句覆盖:目标是保证每一条语句至少被执行一次
|
print "Hello world" print "The date is: "; Date$ print "The time is: "; Time$ end |
分支覆盖:这里增加了一个if分支,那么要有两个测试用例:Date$=01-01-2000和Date$!=01-01-2000
| ||||||
|
条件覆盖:这里再增加了一个条件Time$="00:00:00",那么要有四个测试用例:
| |||||||||||||||
|
6.测试工具
分类:入侵式工具和非入侵式工具
非入侵式工具:仅用于监视和检查软件而不对其进行修改
入侵式工具:以任何方式修改了程序代码或者控制了操作环境(测试的时候使用侵入性尽量小的工具)
- 查看器和监视器
如:1.代码覆盖率分析器,但是它是入侵式的,因为需要编译并链接到源程序中才能够获得所需的信息;
2.通信分析器:只是监听线路,提取进过的数据。
3.代码调试器
- 驱动程序
- 桩
- 压力和负载工具
不仅允许查看通信线路上的数据,而且允许更改。
- 干扰注入器和噪声发生器
- 分析工具
数据库软件
抓屏和比较软件
调试器等
7.测试自动化:
- 宏录制和回放
录制第一次执行测试用例时的
键盘和鼠标操作,然后再
需要重复执行这些测试时
回放一次。
宏录制软件有:Mac上的Quickeys程序;Windows上Macro Magic共享程序
回放软件:播放器
缺点:
无法验证结果
- 可编程的宏
创建可编程的
宏的时候
编写回放系统遵循的简单
指令。
可编程的宏和录制的宏相比:它可以暂停执行,向测试员提示预期结果,并且询问测试是通过还是失败
缺点:
仍无法验证结果
- 完全可编程的自动测试工具
可视化测试:提供编程环境,宏命令和验证能力的工具。
实现验证结果原理:
通过比较每次捕获的屏幕和初次捕获的屏幕的异同确定是否达到预期结果。
-----------------------控件值和预期的控件值-----------------------------------
-----------------------文件输出和预期的输出-----------------------------------
屏幕捕获
控件值
文件和其它输出
控件值
文件和其它输出