测试理论基础(重点)

软件测试的原则

1. 只能证明软件存在问题，不能把证明不存在问题
2. 不能进行穷尽测试，应该分类别测试
3. 测试工作尽早介入，降低修复成本
4. 缺陷存在集群现象，二八原则：20%的模块中存在80%的缺陷
5. 测试依赖环境
6. 杀虫剂现象
7. 不存在缺陷谬论

软件开发模型

瀑布流模型

1.1 瀑布流模型的特点
- 1. 是线性模型的一种，每一个阶段只执行一次。
- 2. 文档驱动

1.2 瀑布模型的优缺点
– 优点： 开发各个阶段比较清晰
– 缺点： 不适应需求变化， 风险往往延至后期才显漏

快速开发模型， 螺旋模型 (了解)

软件测试模型

V模型

v模型的优缺点

• 优点： 测试v模型及包含了底层测试，又包含了高层测试
• 缺点： 当需求变更时将会导致返工量非常大， 模型灵活性比较低

W模型

• W模型的优缺点

  • 优点：强调测试伴随整个开发周期，而且测试的对象不仅仅是程序，还包括需求和设计

  • 更早的介入测试，能尽早发现缺陷进行修复

  • 缺点

  • 对于测试技术要求高， 实践起来比较困难

软件质量模型

1. 功能性: 满足某种功能需求的一种属性或能力
2. 性能效率： 在规定条件下，相对应所用资源的数量，软件产品提供适当性能的能力
3. 兼容性：在一定条件下兼容其他软件的能力
4. 易用性： 在指定条件下，产品被理解、学习、使用和吸引用户的能力
5. 可靠性：产品在规定条件下，在规定时间内完成规定功能的能力
6. 信息安全性：信息在传输或者存储过程的安全程度
7. 可维护性： 在规定条件下，使用规定的工具或方法修复规定功能的能力
8. 可移植性： 从一种环境迁移到另一种环境的能力

软件测试的分类

单元测试

• 又称模块测试，针对软件设计中的最小单位-程序模块，进行正确性检查的测试工作。单元测试需要从程序内
  部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
• 单元定义： C中指一个函数，JAVA中指一个类
  -

集成测试

• 又叫组装测试， 通常在单元测试的基础上，将所有程序模块进行有序、递增的测试
  

系统测试

• 指的是将整个软件系统看为一个整体进行测试，测试的依据是软件需求说明书

验收测试

• α测试： 内测
• β测试： 公测
• γ测试：软件版本正式发行的候选版，版本比较成熟
• 灰度测试：在软件上线之前，抽取部分用户进行使用测试

是否查看源代码

• 黑盒测试： 只关注功能实现，不关心内部的结构设计和代码组成
• 白盒测试： 只看代码，查找代码中的缺陷
• 灰盒测试：查看部分代码， ui不可见，即关注输入输出的正确性又要关注程序内部的情况

###软件测试的更多分类

测试用例

• 定义： 是为特定的目的而设计的一组测试输入、执行条件和预期结果的文档。用于描述什么？怎么测

测试用例的核心八大要数

• 用例编号: 表示用例的唯一性， 有时也叫用例ID
• 用例标题： 表示要测试或验证的目的，通常用一句话简要描述
• 测试项目： 当前测试的功能所属范围
• 测试级别: 表示用例测试功能的重要程度或影响力
• 预置条件：验证该功能需要的前提条件
• 输入数据： 必要的数据数据输入
• 执行步骤： 验证该功能需要的先后操作步骤
• 预期结果： 希望得到的结果

测试理论 => 测试的常用方法

1. 等价划分法(重点)

• 等价类别划分法
  • 等价类的概念： 在所有测试数据中，具有某种共同特点的数据子集
  • 等价类划分为：
    • 有效等价类：满足需求的数据子集
    • 无效等价类：不满足需求的数据子集

等价类划分法设计用例步骤

• 1. 明确需求
• 2. 确定有效等价类和无效等价类
• 3. 提取数据编写测试用例
     

• 适用场景

  • 针对需要数据量大，有测试数据输入的地方
  • 典型代表： 页面级的输入框类测试

二 边界值分析法

• 边界范围的确定

  • 上点： 边界上的点(正好等于)
  • 离点：距离上单最近的点(刚好大于、刚好小于)
  • 内点： 范围内的点(区间范围内的数据)
    

• 边界值法设计用例步骤

  • 1. 明确需求
  • 2. 确定有效和无效等价类
  • 3. 确定边界范围值
  • 4. 提取数据编写测试用例

• 适用场景

  • 在等价类的基础上针对有边界范围的测试数据输入的地方
  • 常见词语描述：大小、尺寸、重量等修饰符
  • 典型代表： 有边界范围的输入框类测试

判定表法

• 判定表法设计用例步骤
  • 1. 明确需求
  • 2. 画出判定表
    • 列出条件桩和动作桩
    • 填写条件项， 对条件进行全组合
    • 根据条件项的组合确定动作项
    • 简化、合并相似规则(有相同的动作)
• 使用场景
  • 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制
    约）关系

场景法、错误推测法、因果图法、正交法(了解)

流程图法 (重要)

• 1. 概念： 流程图法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计
• 流程图法设计测试用例步骤
  • 1. 详细了解需求
  • 2. 根据需求说明或界面原型，找出业务流程的各个页面以及各个页面之间的流转关系
  • 3. 画出业务流程
  • 4. 编写用例

案例

简单画图

流程图

流程图中各个标签所表示的含义

流程图法的使用范围

1. 多个功能间的组合测试
2. 在冒烟测试时主要采用流程图法进行测试

测试理论 => 软件的缺陷

缺陷的定义

• 软件在使用过程中存在的任何问题（如：错误、异常等），都叫软件的缺陷，简称bug。

缺陷的判定标准

软件缺产生的原因

软件缺陷的核心内容

- 缺陷的标题 、缺陷的预置条件、缺陷的复现步骤、缺陷的预期结果、缺陷的实际结果、缺陷的必要附件

构成缺陷的基本要素

• 缺陷编号： 缺陷的唯一性标志
• 缺陷状态： 表示缺陷当前处于哪个阶段
  
• 缺陷所属模块：缺陷属于哪个被测的模块
• 缺陷严重程度： 该缺陷的破坏程度或者影响程度
  
• 缺陷的优先级： 处理该缺陷的优先程度
  

软件缺陷的类型

软件缺陷的信息

缺陷的严重程度

缺陷的优先级

缺陷管理

• 认识缺陷报告
  

缺陷的跟踪(原则：谁创建的谁去关闭)

• 流程一： 测试人员提交缺陷 -> 开发人员修复缺陷 -> 测试人员回归测试 -> 测试人员关闭缺陷
• 流程二： 测试人员提交缺陷 -> 开发人员修复缺陷 -> 测试人员回归测试 -> 测试人员重新打开缺陷
• 流程三：测试人员提交缺陷 -> 开发人员延后处理
• 流程四： 测试人员提交缺陷 -》 开发人员拒绝缺陷 -> 测试人员关闭缺陷