软件测试基本概念、模型与用例
1. 测试理论概念
1. 软件测试分类
1. 是否覆盖源代码
-
黑盒测试:只关注输入与输出,不关注代码逻辑
-
白盒测试:打开整个源代码进行查看,查看具体实现逻辑
-
灰盒测试:介于黑盒测试与白盒测试之间,即关注输入输出,又关注程序内部情况,多用于集成测试阶段
2. 按阶段划分
- 单元测试:
- 测试方面:针对单个功能进行测试,例如:登录
- 开发方面:针对代码进行测试(一般由开发负责,或使用自动化测试)
- 集成测试:
- 又称为组装测试,通常在单元测试的基础上,将所有程序模块进行有序的、递增的测试
- 重点测试不同模块的接口部分
- 系统测试:
- 将整个软件系统看成一个整体进行测试(软件层面、硬件层面)
- 测试的依据是软件需求说明书
- 验收测试:
- 检验是否符合最终用户需求的测试
- 分类:
- α测试:内测,bug多
- β测试:公测
- γ测试:候选发布版本
3. 按是否运行划分
- 静态测试:不运行被测试程序
- 测试对象:文档、代码
- 动态测试:运行测试程序
- 测试对象:运行中的程序
4. 按是否自动化划分
- 手工测试:功能测试
- 自动化测试:利用代码或者工具帮助测试人员进行自动化测试
5. 其他测试方法
- 冒烟测试:
- 开发提交测试版本的接受性测试
- 测试点:
- 最基本的功能,如登录功能
- 最核心的业务流程,如电商购买商品的全过程
- 回归测试
- 测试点:
- bug 回归
- 旧功能回归
- 测试点:
- 随机测试
- 主要根据测试者经验对软件的功能与性能进行抽查
- 探索测试
2. 软件测试模型
1. 瀑布模型
-
组成:
- 定义阶段:可研与计划(可行性研究报告)、需求分析(需求规格说明书)
- 开发阶段:概要设计(概要设计文档)、详细设计(详细设计文档)、编码(程序)、软件测试(测试报告)
- 运维阶段:运行维护
-
特点:
- 线性模型
- 文档驱动
-
优缺点
- 优点:只需要关注当前进行的阶段
- 缺点:不响应需求变化
-
应用场景
- 需求清晰的大型项目,如银行、保险、建筑等
2. V 模型
- 组成:
- 需求分析->概要设计->详细设计->编码->单元测试->集成测试->系统测试->验收测试
- 优缺点:
- 优点:只需要关注当前阶段、文档驱动、线性模型
- 缺点:不响应需求的变化、不灵活
3. W 模型
-
双V模型:
- 开发 V:需求分析->概要设计->详细设计->编码**->集成->实施->交付**
- 测试 V:验收测试设计->系统测试设计->集成测试设计->单元测试设计->单元测试->集成测试->系统测试->验收测试
-
优缺点:
- 优点:测试贯穿软件开发的全生命周期,早参与、早发现、早解决
- 缺点:技术与管理要求较高
4. 软件质量模型
- 功能:关注业务功能使用
- 可靠性:容错能力,纠错能力
- 易用性:易读、易用
- 效率:时间、性能要求
- 可维护性:运维人员去维护公司现有项目
- 可移植性:在不同软件硬件平台都能正常工作
- 标准
- ISO标准:国际标准
- GB标准:中国标准
3. 软件测试用例
- 概念:一个为了特定目的(检验产品功能实现是否满足用户需求)而设计的包含(测试输入、执行条件、预期结果)的文档,文档形式包括excel、xmind等
- 案例
标题 | 测试输入 | 执行条件 | 预期结果 |
---|---|---|---|
验证电脑是否能够开机 | 有电 | 按下开机键 | 开机 |
-
测试用例八大要素
-
常见八大核心要素:
- 用例编号:表示用例的唯一性,也称为用例id
- 用例标题:表示要测试或验证的目的,通常一句话简要描述
- 测试项目:当前测试的功能所属范围
- 用例级别:表示用例测试功能的重要程度或者影响力
- 预置条件:验证用例测试功能需要的前提条件
- 输入数据:必要的输入数据
- 执行步骤:验证该功能需要的先后操作步骤
- 预期结果:希望得到的结果
-
用例模板
- ID:唯一性
- 模块
- 优先级:体现用例执行的先后顺序
- 用例标题:见名知意
- 预置条件
- 测试步骤:尽可能详细
- 测试数据
- 预期结果
-
-
软件测试用例作用
- 便于理清测试思路,确保需覆盖的测试功能点无遗漏
- 便于测试工作量的评估
- 便于提前准备测试数据
- 便于把控测试工作进度
- 便于回归测试
- 便于测试工作的组织,提高测试效率,降低测试交接成本