软测入门理念
软件的分类
- 按层次划分:系统软件、应用软件
- 按组织划分:商业软件、开源软件
- 按结构划分:单机软件、
软件缺陷
由来
Grace Hopper发明Cobol计算机语言,也是找出电脑程序中第一个bug的女程序员
- Bug
- Defect
定义
- 软件未实现产品说明书要求的功能
- 软件出现说明书指明不应该出现的功能
- 软件实现了产品说明书未提及的功能
- 软件未实现产品说明书虽未提及但应该实现的功能
- 软甲难以理解、不易使用、运行缓慢(从测试角度看)最终用户会认为不好
所有不满足需求或超出需求的都是缺陷
没有不存在缺陷的软件,只有迄今为止尚未发现的缺陷
软测的定义和目的
定义
- 正向思维:相信产品能够正常运作
- 反向思维:为了发现错误而执行一个程序或系统的过程々
- IEEE定义的测试
- 广义软件测试:软测是对软件形成过程中的所有工作产品(包括程序以及相关文档)进行测试
- 确认(validation):确认功能是否已经实现
- 验证(Verification):是否满足需求
目的
- 找出软件中潜在的各种错误和缺陷,保证各种错误和缺陷得以修复,避免软件发布后由于潜在缺陷和错误造成隐患(找不容易发现的bug)
- 利用测试结果和信息,作为后续项目开发和测试过程改进的重要输入,避免在将来的项目开发和测试中重复同样的错误(将bug作为重要输入,避免出现重复bug)
- 采用高效测试管理手段,提高软测的效率和产品质量(方便开发和测试的对接,如使用
TAPD
等工具)
测试和调试的区别
- 主体、目标、方法、思路不同
- 测试是有预知的结果,调试的结果不可预估
- 测试可以计划,预先定义测试用例和过程,工作量可度量;调试时间相对较多
测试的原则
- 证明软件中存在缺陷
- 不能穷尽测试
- 测试应该尽早介入(避免后置)
- 二八原则(80%的功能只有20%的人用)
- 不存在缺陷谬论
- 妥善保存一切文档
测试基本要求
- 外观测试
- 易用测试
- 兼容性测试
- 安全性测试
- 性能测试
- 功能测试
通用测试技术
软件生命周期
- 需求分析
- 概要设计
- 详细设计
- 编码
- 测试(测试报告)
- 验收
软件生命周期模型
-
瀑布模型:最早提出的软件开发的过程模型(线性)
存在问题:强调时间顺序的严格执行,各阶段耦合度较高;
将测试放在了编码之后(测试后置),增加了开发风险
有点:阶段性明确;只需要关注后续的阶段
-
快速模型:
原型:就是一个模型,可以模拟操作、简单运行
工具:Axure工具制作原型
产品画完原型后给客户确认,通过后交给开发人员进行编码工作。
-
增量模型:软件分割成独立的模块,分批次完成和交付。
会打破原有的软件结构和框架,会带来一定的风险。
增量模型一般会和迭代模型一起运用。
-
螺旋模型:引入其他模型不具备的
风险分析
,使软件在无法排除重大风险时有机会停止,及时止损。 -
迭代模型:不断进行产品功能更新深入(开发迭代试一次完整经过所有工作流程的过程:需求分析、设计、实施、测试)
-
敏捷模型
测试流程
软件测试的分类
- 测试阶段
- 单元测试(编码完成后,如写了一个模块的接口)
- 集成测试(单元测试完成后,模块完成后)
- 系统测试(集成测试完毕后,发布测试环境后测试)
- 验收交付测试(α测试内测,β测试公测)
- 是否覆盖源码
- 白盒测试(测代码)
- 黑盒测试(测功能):功能测试(UI页面、业务、文档测试)、性能测试(响应速度、系统资源的占用、稳定性、负载测试、压力测试)
- 灰盒测试(测功能和代码)
- 是否运行:静态测试、动态测试
- 是否自动化:手工测试、自动化测试
- 地域测试:本地化测试、国际化测试
- 其他:回归测试(复测)、冒烟测试(基本模块是否正常,程序能否跑起来)、随机测试(monkey测试)、探索测试(其他方面)
软件测试过程模型
V模型
- 测试后置,忽视了测试对需求分析、系统设计的验证
- 需求的满足情况一直到后期的验收测试才被验证
W模型
由两个V字模型组成,分别代表测试和开发过程,明确表示测试与开发的并行关系。
优点:
- 测试的活动与软件开发同步进行
- 测试对象不仅是程序,包括需求和设计
- 尽早发现软件缺陷,降低软件开发的成本
缺点:
在W模型中,需求、设计、编码等活动被视为串行的,无法支持灵活迭代。