软件测试基础理论

一、软件测试概述

概念：在规定条件下对程序进行操作，衡量软件质量，以发现程序错误，对其是否满足设计要求进行评估的过程

测试目的：找出缺陷，保证软件质量

测试对象：

• 源程序

• 目标程序

• 数据

• 设计稿/需求文档

二、软件开发理论

软件开发模型：软件开发包括需求、编码、测试等阶段，软件开发模型是规范化的软件开发流程

模型分类：

1. 边做边改模型

2. 快速原型模型

3. 瀑布模型：

三、软件测试流程

3.1 软件测试模型

概念：规范化的测试流程

分类

• V模型（重点）

• W模型（重点）

• X模型

• H模型

3.1.1 V模型

概念：以编码为黄金分割线，将流程分为开发和测试，且开发和测试串行（特点）

缺点：测试介入过晚，返工量大

3.1.2 W模型

概念：由两个V模型组成，一个是开发阶段，一个是测试阶段，开发与测试并行（特点）

缺点：虽然开发测试并行了，但是总体流程依然串行，不支持敏捷开发

四、软件测试分类

4.1 按阶段划分

1、单元测试

概念：对软件最小可测单元进行检查和验证

场景：测试某个函数实现功能是否正确

2、集成测试

概念：在单元测试基础上，将模块组成子系统进行测试

原因：实践表明，一些模块可以单独地正常工作，但不能保证连接起来也能够正常工作

3、系统测试

概念：将软件和操作系统/硬件看作一个整体，在实际运行环境下进行测试

举例：百度在浏览器和手机都能打开，在不同环境下都要进行测试

概念：对完成的系统是否满足最初的需求进行验证

4、验收测试

概念：对完成的系统是否满足最初的需求进行验证

分类：

按用户对象划分

• 项目验收：由甲方发起，验证乙方系统是否符合业务需求

• 产品验收：由产品经理发起，验证自研系统是否满足用户需求

按阶段划分

• α测试（内测）：仅公司内容人员参与

• β测试（公测）：由用户参与

项目环境

概念：指项目运行的环境，是一个“软件+硬件+操作系统”的整体

项目环境分类

• 开发环境

• 测试环境

• 预生产环境

• 生产环境

测试环境--负责人员--具体环境

• 单元测试--开发--开发环境

• 集成测试--开发--开发环境

• 系统测试--测试--预生产环境

• 验收测试--产品/甲方--生产环境

4.2 按是否考虑代码逻辑划分

4.2.1 黑盒测试 

概念：把测试对象看作一个黑盒子，不关注测试对象的内部逻辑，只关注程序的功能是否符合需求文档

依据：需求文档

分类

1、功能测试

• 产品功能是否满足需求

2、界面测试

• UI测试，检查页面元素是否符合UI设计，页面是否美观

3、易用性测试

• 用户体验

4、性能测试

• 模拟用户使用场景，测试系统各项性能指标，查看其是否符合需求

4.2.2 白盒测试 

概念：与黑盒相反，把测试对象看作一个透明盒子，对程序的所有逻辑路径进行测试。检验每条路径是否都能跑通。

重点：检验代码逻辑结构是否符合设计

依据：代码规范，详细设计

4.2.3 灰盒测试 

概念：介于黑盒与白盒之间，了解一部分代码逻辑，重点验证程序的功能

4.2.4 各测试阶段对应关系

• 单元测试--白盒

• 集成测试--白盒/灰盒

• 系统测试--黑盒/灰盒

• 验收测试--黑盒

4.3 按是否运行划分

4.3.1 静态测试

概念：指不运行被测程序本身，只检查文档或源程序的语法、结构、过程等

测试对象

• 需求文档

• 各类设计文档

• 源程序

4.3.2 动态测试

概念：运行程序本身，进行测试

测试对象

• 源程序

• 软件

4.4 按是否自动化划分

4.4.1 手工测试

• 利用手工的方法去测试

4.4.2 自动化测试

• 利用工具或代码去测试

4.4 其他分类

4.4.1 冒烟测试

概念：对最基本的功能和流程进行测试

4.4.2 回归测试

概念：修改代码后，重新进行测试

应用场景

• bug回归：回归bug及相关联功能

• 旧功能回归：回归所有旧功能

缺点

• 工作量大

解决方案

• 自动化测试

4.4.3 随机测试

• 测试一些重要功能或其他人未测试到的部分

4.4.4 探索性测试

• 测试设计和测试执行同时执行

五、软件测试最佳实践流程

5.1 流程

 

 

5.2 以周迭代的时间规划

• 需求分析+需求评审--0.5天

• 测试用例+测试计划+评审--1.5天

• 系统测试--1.5天

• 验收测试--0.5天

5.3 测试在软件开发流程中的职责

六、测试计划和测试方案 

6.1 测试计划 

概念：描述了测试活动的范围、资源和进度的文档

内容：

1、测试目标和范围

2、测试分工/职责

3、任务安排/进度与资源分配

• 人

• 时间

• 其他测试资源

4、风险评估和应急计划

• 时间不够，测不完

• 技术不足，无法进行测试

• 场景无法模拟，无法进行测试

5、测试各项标准

6.2 测试方案 

概念：从测试的技术角度出发，重点在于测试的策略及技术实现

内容：

1、测试策略：

• 功能、UI、易用性（用户）、性能、兼容
• 安全性
• 授权/隐私/数据传输/数据存储
• 可靠性
• 稳定性/健壮性/可恢复性/错误处理/数据完整性
• 可维护性
• 可拓展性/修复
• 可移植性
• 重新使用

2、测试方法：

• 手工/自动化
• 黑盒/白盒/灰盒

3、测试工具的设计和选择

区别：

• 测试计划是管理性文档，测试方案是技术性文档

• 敏捷开发中，测试计划可以看作是测试方案+测试计划，也可以省略文档

七、测试用例

概念：一个为了特定的目的而设计，包含测试输入，执行条件，预期结果的文档

作用：

• 理清测试用例，确保覆盖的测试的功能点无遗漏
• 评估测试工作量（量化）
• 把控测试工作进度
• 提前准备测试数据
• 回归测试
• 组织测试工作
• 提高测试效率
• 降低测试交接成本

包含内容：

 

八、测试用例设计方法

8.1 常见八大测试用例设计方法：（前五种使用较多）

• 等价类

• 边界值

• 判定表

• 场景法

• 流程图法

• 因果图

• 正交法

• 错误推断法

8.2 等价类划分法

应用场景

• 有数据输入的地方就可以使用，如：输入框

• 作用：从大量数据中划分范围，然后从每个范围中挑选代表数据

8.3 边界值

应用场景：

• 与等价划分法组合使用

作用：

• 边界值法是等价划分法的重要补充

• 大量程序错误往往容易发生在边界上

 

 

8.4 判定表

应用场景：

• 用于处理较为复杂的业务逻辑，能避免遗漏测试点

 

8.5 场景法

应用场景：

• 主要应用于系统测试/验收测试阶段，模拟用户操作场景（测试多个功能组合）

8.6 流程图法

应用场景：

• 用流程图的方式去展现基于用户使用场景

• 先用流程图来表示，然后用场景法来组织测试用例

 

8.7 因果图

应用场景：

• 输入条件或者输出条件的组合比较多，组合使用判定表和因果图

为什么用因果图？

• 借助图像手段去分析判定表

8.8 正交法

概念

• 古希腊就有的实验设计方法，基于数学概率学知识，设计最经济的实验路径

应用场景

• 输入条件较多，每个条件取值可能性也比较多时，可以使用正交法

备注：

• 采用正交法设计测试用例需要使用工具：allpairs

8.9 错误推断法

应用场景：

• 测试人员使用经验或直觉发现出现程序错误

举例：

• 新开发功能，与其相关业务，或者数据，容易出现问题

• 分页功能，页码搜索

• 新功能，异常场景

• 列表展示功能，数据为空，是否报错？

• 文本框，对于特殊字符的处理

8.10 测试用例方法设计总结 

 

九、软件缺陷与缺陷管理 

概念：软件缺陷就是软件的毛病,它可能存在于UI/功能/兼容/易用性/性能等各个方面,包括已发现的和未发现的
业内对bug的通俗理解：

• 需求文档要求的功能,未实现
• 需求文档虽未明确提及但应该实现的功能,未实现
• 需求文档未提到的功能,实现了
• 软件难以理解/不易使用/运行缓慢 或(从测试人员角度看)用户会认为不好的
   

简单来说：实际结果与预期结果不一致 

缺陷产生的原因：

• 需求原因: 文档错误/有疏漏等
• 编码原因:设计有误/编码错误等
• 其他原因: 时间紧,沟通理解有问题,甚至比如立项就是个错误等 

描述一个缺陷的要素：
ID: 唯一性
模块
缺陷标题: 见名知意
严重程度

• 严重:主要功能不可用,crash/闪退, 不能启动
• 一般: 次要功能不可用,边界/异常未进行处理等
• 微小: UI问题, 易用性问题, 建议等

优先级

• 高: 阻塞性问题,影响继续测试,需立刻修复
• 中:正常流程,本次迭代上线前修复即可
• 低: 可以延期到下个版本解决复现步骤

预期结果
实际结果
缺陷类型: 代码错误/界面错误/兼容性错误/易用性错误/性能问题/安全问题
缺陷状态

• 新建
• 已指派。
• 已修复(已解决)/拒绝/延期
• 关闭/重新激活

bug的生命周期?[2]
发现-> 确认 -> 提交 ->指派 →> 修复验证 →>关闭 或者 重新激活再次进行指派

十、测试报告

概念

• 测试活动的总结性文档，标志测试活动的结束

包含内容

• 测试工作的经过和结果

• 缺陷的汇总和分析

• 风险评估

• 测试工作的总结和改进

面试题

你们公司的测试报告包含哪些东西：

1、首先是关键信息，如：项目号、版本号、测试结果、完成时间等

2、然后带上缺陷清单和一些统计信息，比如测试用例总数、用例执行率、bug总数、遗留bug总数 3、之后是风险评估：评估未能执行的用例和遗留的bug可能带来的风险，也包含其他业务风险等 4、最后是工作总结，提出具体的工作改进建议