软件测试概述
软件测试的定义
对软件形成过程中产生的程序和相关文档等进行测试,不仅仅是对程序的运行进行测试
-
确认
应用和功能是否实现
-
验证
需求是否实现
软件测试的目的
- 以最少的人力物力时间找出软件中潜在的各种错误和缺陷,保证各种错误和缺陷得以修复,避免软件发布后由于潜在的错误和隐患导致的商业风险
- 利用测试过程中的结果和信息,作为后续软件开发和优化的重要输入,避免在将来开发过程中出现同样的错误
- 采用更高效的管理方式,提高软件测试效率和软件产品的质量
测试和调试的区别
测试 | 调试 | |
---|---|---|
主体 | 测试人员 | 开发人员 |
目标 | 找bug | 改正错误 |
方法 | 等价类,边界值 | 程序和逻辑算法 |
思路 | 尽量找出错误 | 尽量不出错误 |
测试流程
获取测试需求–编写测试计划–制定测试方案–设计开发测试用例–执行测试–提交缺陷–测试分析和评审–测试总结–准备下一版测试
测试模型
V模型
揭示了开发过程和测试过程中各阶段的对应关系
缺点
- 只把测试过程作为最后的阶段,忽视了测试对需求分析和系统设计的验证
- 需求满足的情况一直到后期的验收测试才被验证
- 没有尽早、不断测试
W模型
两个V,一个是开发,一个是测试
优点
- 测试开发同步进行
- 测试对象全面
- 尽早发现缺陷
缺点
需求、设计、编码等被视为串行的,不支持灵活的迭代
H模型
独立的测试活动
满足尽早测试、反复测试
X模型
对V模型的改进,提出了针对单独的程序片段进行相互分离的编码和测试,之后通过频繁交接,通过集成最终合成为可执行程序
定位了探索测试,帮助有经验的测试发现更多缺陷
软件测试分类
按开发阶段分
单元测试
模块测试,最小的单位,检测每个程序单元能否实现需求的功能,多模块可以平行的独立进行单元测试
集成测试
在单元测试的基础上,将所有模块进行有序测试。多用到接口测试
确认测试
确认所有功能都已经实现,冒烟测试
系统测试
全面全方位测试:所有功能,所有用户的操作,硬件系统,软件系统,和其他软件的关系等
验收测试
- α测试:开发商交付前的测试
- β测试:需求方测试
- γ测试:第三方测试
按代码运行分
-
静态测试
不实际运行被测对象,执行检查代码,界面,文档中的问题
-
动态测试
运行被测对象,输入测试数据,检查输出结果
按照软件特性划分
-
功能测试
逻辑功能,界面,易用性,安装卸载,兼容性
-
性能测试
时间性能,空间性能
-
安全性测试
验证系统中的安全机制对系统的保护
-
其他测试
- 回归测试
用之前某版本的测试用例测试新版本。验证之前的缺陷是否修复,确认是否引发了新缺陷
- 随机测试
基于经验和直觉测试边缘性错误
- 猴子测试
假装自己是猫猫,乱点
按照测试技术
黑盒测试
用测试的外部表现来发现其缺陷和错误,完全不考虑程序的内部结构和处理过程,检查程序是否按照需求规格说明书的规定实现
白盒测试
对程序内部结构的分析、检测来寻找问题,检测所有结构和路径是否正确,软件内部动作是否按照设计说明执行
灰盒测试
关注输入输出,也关注内部表现,但没有白盒那么详细
按测试运行主体
- 手工测试
- 自动化测试
软件测试原则
- 测试标准建立在用户需求上
- 基于质量第一
- 事先定义质量标准
- 项目一启动就开始测试
- 不能穷举测试
- 第三方测试更客观
- 测试计划是前提
- 测试用例要根据目的和相应方法去设计
- 错误多的模块深入测试
- 重视保存一切测试文档(测试计划,测试用例,测试报告)
- 尽早测试,不断测试
- 重视回归测试的关联性
- 从小规模转向大规模
- 彻底检查测试结果
- 认真确认错误结果
- 提交Bug数>=执行失败的测试用例数
- 通过的测试用例/执行的测试用例 表现系统的质量
- 执行的测试用例/总测试用例 表现需求是否满足
测试需求
- 通过需求分析,了解测试的方向和内容
- 模块和组织结构
- 软件的功能和业务流程
- 主要功能和次要功能
测试计划
测试中需求的正反向和优先级
针对每个需求点进行设计
需求覆盖程度 = 被测试用例覆盖的需求数/需求点总数