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