软件测试final

最新推荐文章于 2021-11-12 12:19:12 发布

Java the world

最新推荐文章于 2021-11-12 12:19:12 发布

阅读量192

点赞数

分类专栏：软件测试文章标签：软件测试

本文链接：https://blog.csdn.net/u013140841/article/details/103810274

版权

软件测试专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一

什么是软件

软件 = 程序 + 数据库 + 文档 + 服务

什么是软件测试

使用人工或自动手段来运行或测试某个系统的过程，目的在于检验其是否满足规定的需要或是弄清楚预计结果与实际结果之间的差别

软件测试说明书
软件测试的原则
1. 尽早地和及时地测试，从需求阶段开始介入
2. 测试前做好测试数据和与之对应的预期结果这两部分
3. 测试输入的数据应包括合理的输入条件和不合理的输入条件
4. 程序提交测试后，应当由专门的测试人员进行测试
5. 严格执行测试，排除测试的随意性
6. 测试用例的所有相关的预期结果做全面的检查
7. 充分注意测试当中的群集现象
8. 保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料
9. 0 bug 与 good enough
10. 缺陷具有免疫性（每修复3-4个缺陷，就会产生一个新的缺陷）
为什么进行软件测试

提高软件质量
确保软件满足需求

测试用例定义

是一组测试输入、执行条件和预期结果

测试用例设计的基本原则

数量越少越好
典型性越高越好
对缺陷的定位性越强越好

软件测试的分类

是否关心内部结构：黑盒测试白盒测试
是否运行被测程序：静态测试，动态测试
是否需要人工干预：人工测试自动化测试
软件开发的过程：单元测试，集成测试，系统测试，验收测试（单元集成系统验收）
测试实施组织：开发方测试用户测试第三方测试

开发模型

什么是开发模型

软件开发的全部过程、活动、任务和管理的结构框架。它给出了软件开发活动各阶段之间的关系

开发模型

大爆炸模型
1. 优点：思路简单，通常可能是开发者的突发奇想
2. 缺点：开发过程是非工程化的，随意性大，结果不可预知
3. 测试：开发任务完成后，修复较困难
边写边改模式
1. 优点：简单考虑到了软件的需求，产品周期短
2. 缺点：没有计划和文档的编制
3. 测试：新的版本不断产生，测试工作产期循环
瀑布模型
1. 需求分析（需求说明书）- 概要设计（系统说明书）- 详细设计（程序设计书）- 编码（程序清单）- 测试（测试报告）- 上线运行及维护（维护报告，改进的系统）逐级下落
2. 优点
  1. 将软件生存周期各活动规定为依线性顺序联结的若干阶段的模型
  2. 易理解，阶段明显，强调需求分析，明确测试阶段，提供了一套模板
3. 缺点：
  1. 风险大
  2. 灵活性差
  3. 适应性差
  4. 代价大
4. 适用于功能、性能明确完整，需求固定，无重大变动
螺旋模型
1. 确定目标，选择方案 - 评估方案，解决风险 - 本阶段的开发和测试 - 计划下一阶段 - 确定下阶段方法
2. 严格的全过程风险管理，强调各开发阶段的质量，提供机会评估项目是否有价值继续下去
敏捷模型
1. 以用户的需求为核心，采用迭代，循序渐进的方法进行软件开发

测试模型

V模型（瀑布模型的变种）

动态测试行为与开发行为对应
局限性：测试滞后缺少静态测试

W模型

静态测试和动态测试伴随整个开发阶段
局限性：
1. 将软件开发看成需求分析，设计和编码等一系列串行的活动
2. 开发、测试之间保持着线性的前后关系，无法支持迭代的开发模型，无法支持变更调整
3. 未体现测试流程的完整性
H模型
1. 保持自身的完整性
2. 测试是一个独立的流程
3. 测试准备和执行活动是分离的
X模型
1. 单元测试集成测试系统测试

宏观上以W模型为基本框架，将软件开发和软件测试作为两个并行的过程，测试伴随整个开发过程

微观上对每个测试阶段以H模型为指导，进行独立测试

软件测试流程

熟悉需求- 拟定测试计划 - 测试计划评审 - 设计测试用例/开发测试脚本 - 搭建测试环境 - 实施测试 - 测试评估 - 测试总结

测试用例

为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果等信息的一个特定的集合

测试环境：

开发环境
测试环境
正式环境

黑盒测试

功能测试数据驱动测试
不考虑程序内容结构和处理过程，仅根据需求确定测试用例和推断测试结果的正确性
局限性：测试结果的覆盖度不易测量，测试的潜在风险较高
用例方法：
1. 边界值分析法
  - 边界值：可能导致被测系统内部处理机制发生变化的点
  - 基于单缺陷的假设，仅覆盖输入条件的单个边界点即可
  - 如何选择合适的输出域，边界值附近的邻域大小，顺利确定对应的测试用例
2. 等价类划分
  1. 什么是等价类划分
    - 根据需求对输入域进行细分，然后在分出的每一个子集中选取一个有代表性的测试数据开展测试
  2. 3个约束：分而不交，合而不变，类内等价
  3. 如何确立被划分对象
    - 针对整体输入域或个体输入域进行等价划分（前提：独立性假设）
    - 可以对输出域进行划分
  4. 有效等价类：
    - 考查软件的正常工作能力
  5. 无效等价类
    - 考查软件的容错能力
3. 因果图
4. 错误推测法

白盒测试

结构测试透明盒测试逻辑驱动测试基于代码的测试

正交表（emm）
决策表
- 也叫判定表法，是分析和表达多种逻辑下执行不同操作情况的工具
1. 条件桩：
2. 动作桩
3. 条件项
4. 动作项
因果图（3.5）
场景法

通过分析不同事件的触发顺序和处理结果，构建各个事件流
基于场景设计测试用例
基本流（正确操作并得到结果）
备选流（操作不当）
场景的确定（基本流个数+备选流个数）
要求：会画流程图（判断环境复杂度）

状态转换图（树）

碰到相同状态时不必再画
设计测试用例
编号前提条件标题测试步骤预期结果实际结果
最少的场景数等于事件流的总数，基本流与备选流的总数
有且仅有一个场景包含基本流
对于每个备选流，至少应有一个场景覆盖，且在场景中应该避免覆盖其他备选流

错误推测法

对路径的测试

独立路径：

将全路径看做一个向量空间，从全路径集合中抽取一组线性无关的独立路径看做一组向量基
通过对独立路径的测试达到对所有路径的测试覆盖
独立路径个数 = 环复杂度

主路径

包含尽可能多的判定结点，尽可能复杂的判定表达式，尽可能高的执行概率，尽可能多的执行语句
根据主路径抽取其他独立路径

不可行路径：多个简单路径之间存在一定关联
画出程序图
计算环复杂度
写出独立路径
分析有无不可行路径（有则修改）
分析有无遗漏

关于循环的测试

重复多次循环可能导致内存泄漏
循环的边界和界限内对循环体的执行过程

单元测试

静态测试：通过走查，审查等会议方式，根据模块的详细设计，将代码与缺陷检查表进行对照，查看代码是否符合标准和规范
动态测试主要包括对模块接口、模块边界条件、模块独立路径和错误处理进行测试
步骤

做静态和动态检查
编写测试用例做相应测试（借鉴黑盒测试用例设计方法：等价类边界值等）
使用判定覆盖或独立路径覆盖进行测试（有时会与黑盒测试用例重合，选其一即可）

集成测试

在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统，并进行测试的过程，目的是确保各单元模块组合在一起后能够按照既定意图写作运行，并确定增量的行为正确
每个模块能够单独工作，但这些模块集成在一起，某些模块可能不能正常工作
内容：

将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失
判断各子功能组合起来能否到达预期要求的父功能
检查一个模块的功能是否会对其他模块的功能产生不利影响
检查全局结构数据是否正确，以及在完成模块功能的过程中是否会被异常修改
单个模块的误差累加起来，是否会放大到不可接受的程度

驱动模块：模拟被测单元的上级模块，用于接收测试数据、启动被测模块和输出结果
桩模块：模拟被测单元调用的模块
集成测试的方法：

成对集成
共m个模块，n条边，每条边对应一对调用接口，确定一个成对测试用例，因此包含n个测试用例
容易定位缺陷
邻居集成
某个指定模块及其所有直接调用该模块的上层模块以及所有被该模块直接调用的下层模块
一般是三个模块一个测试用例
缺陷定位较困难
基于独立路径的集成
将函数调用图看做程序图，每个从根节点到叶子节点的调用形成了路径，每条独立路径即可构成一个集成测试用例
减少桩模块和驱动模块的开发量
缺陷定位困难