1. what is testing

   1. software testing is a set of processes aimed at investigating, evaluating and ascertaining the completeness and quality of computer software. Software testing ensures the compliance of a software product in relation with regulatory, business, technical, functional and requirements
   2. test process:

2. Basic problems of testing

   1. Adequancy of test suite
   2. Oracle:
      1. expert knowledge
      2. metamorphic relation

1. 概念
   1. 侧重软件的最小可测试元素
   2. 应用于实现模型中的模块
   3. 主要是功能正确前提下的控制流和数据流的覆盖测试
   4. 主要针对单元的内部结构
   5. 更注重白盒测试
2. 测试内容
   1. 算法和逻辑 无法直接测试
   2. 单元接口
   3. 数据结构
   4. 边界条件
   5. 独立执行
   6. 错误处理

1. 原因
   1. 一个模块可能对另一个模块产生不利影响
   2. 将子功能合成时不一定产生所期望功能
   3. 独立可接受误差，在集成后不一定可接受
   4. 可能会发现单元测试中未发现的接口方面的错误
   5. 发现单元测试中无法发现的时序问题
   6. 发现单元测试中无法发现的资源竞争问题
2. 概念
   1. 前提是集成的单元能够正确执行用例
   2. 测试对象是实现模型中的一个或一组包
   3. 集成的包通常来自于不同的开发组织
   4. 继承测试将揭示包接口规约中不完全或错误的地方
3. 测试方法
   1. 非增式测试：一步到位构造测试
   2. 增式测试：将要测试的模块同已测试好的模块组合起来进行测试，一次增加一个人测试模块
4. 增式集成
   1. 自顶向下的结合：
      1. 集成步骤
         1. 主控模块作为测试驱动，所有与主空间模块直接相连的模块作为桩模块
         2. 根据集成的方式深度或广度，每次用一个替换从属的桩模块
         3. 在每个模块被集成时，都必需完成单元测试
         4. 进行回归测试以确定集成新模块后没有引入错误
   2. 自底向上的结合
      1. 集成步骤
         1. 从最低层的模块开始，组合成一个构建，用以完成指定的软件子功能
         2. 编制驱动程序，协调测试用例的输入和输出
         3. 测试集成后的构件
         4. 按程序结构向上组装测试后的构件，同时除掉驱动程序
   3. 比较：

1. 概念
   1. 前提：所有集成测试完成
   2. 软件系统之间的联合测试
   3. 软件、硬件等之间的联合测试
   4. 模拟真实运行环境的测试

1. $\alpha$测试：在开发即将完成时，对应用进行测试，此时仍然允许对设计做微小的变动
2. $\beta$测试：在开发基本完成时运行，用于正式发布之前寻找程序中的错误

• 单元测试：
  • 目标
    • 检验程序最小单元有无错误：接口、数据结构、边界、覆盖、逻辑
    • 检验单元编码与设计是否吻合
• 集成测试
  • 目标：
    • 代码组组成系统的模块接口有无错误
    • 代码实现的系统设计与需求定义是否符合
• 系统测试
  • 目标
    • 检验组成整个系统的代码、以及系统的软硬件配合是否有误
    • 代码实现的系统与用户需求是否吻合
    • 检验系统的各种文档是否完整有效
    • 模拟验收测试的要求，检查系统是否符合用户的验收标准
• 验收测试
  • 目标
    • 使客户是否验收签字
    • 系统是否符合事先约定的验收标准
• 回归测试
  • 目标
    • 验证程序修改或版本更新有，以前正确的功能和其他的指标仍旧正确

• 接口测试
  • 那些子系统的接口需要测试
• 性能测试，负载测试等
  • 那些功能需要做性能测试

• 数据和数据库集成测试
• 功能测试
• GUI测试
• 性能测试
• 安全测试
• 压力测试
• 负载测试
• 容量测试
• 失效/恢复测试
• 安装测试
• 配置测试

• Code coverage stragegies
  • Decision coverage
  • data flow testing (define -> use)
• Specification based testing
  • Equivalence partitioning
  • Boundary value analysis
  • Combinaiton strategies
• State based testing

• 角色：经理、设计人、测试人等
• 系统资源：硬件、软件

• 测试计划
• 测试环境
• 测试包
• 测试日志
• 缺陷报告

• 确认和详细描述测试用例
• 确认和设计测试成本
• 评测测试覆盖

• 测试脚本：一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行
• 测试脚本可以被创建，或使用测试自动化工具自动生成，或用编程语言来完成，也可以综合前三种方法来完成
• 测试脚本语言

• 覆盖率
• 控制流覆盖率
• 数据流覆盖率
• 分支覆盖率
• 路径覆盖率

• 建立测试环境
• 录制或编写测试脚本
• 开发测试驱动器和桩模块
• 建立外部数据集

• 执行测试脚本
• 测试执行情况分析
• 结果验证
• 研究未预期的结果
• 写日志
• Bug报告、追踪

• 分析测试用例覆盖
• 分析代码覆盖
• 分析缺陷
• 分析是否达到测试停止、成功的标准
• 写测试分析报告

• 静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性
  • 方法：
    • 走查：开发组内部进行的，采用讲解、讨论和模拟运行的开发方式进行的查找错误的活动
    • 审查：开发组内部进行的，采用讲解、提问并使用CheckList方式进行的查找错误的活动。一般有正式的计划、流程和结果报告
    • 评审：开发组、测试组和相关人员联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告
    • 审计
• 动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标
• 异同点
  • 被测部分不同：静态测试是指测试不运行的部分，只是检查和审阅，如规范测试、软件模型测试、文档测试；而动态测试是通常意义上的测试，也就是运行和使用软件
  • 测试方法不同：静态测试通过文档评审、代码阅读等方式测试软件；动态测试通过运行程序测试软件

从是否关心内部结构来看：

• 白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法
  • 特点：要求对某些程序的结构特性做到一定程度的覆盖
    • 语句覆盖：要求被测程序的每一个可执行语句在测试中尽可能地都检验过，是最弱的逻辑覆盖准则
    • 分支或判定覆盖：要求程序中所有判定的分支尽可能得到检验
    • 判定/条件覆盖：同时考虑条件的组合值以及判定结果的检验
    • 路径覆盖：只考虑对程序路径的全面检验
• 黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅根据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试
• 灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术

• 单元测试：又称模块测试，是针对软件设计的最小单位——程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求
• 集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件
• 系统测试：是为判断系统是否符合要求而对继承的软硬件进行的测试活动，它是将已经继承好的软件系统作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试
• 验收测试：检查交付的软件是否满足用户的需求

• 手工测试：测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输入执行，包括与被测软件进行交互，然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有异常发生，属于比较原始但是必须执行的一个步骤
• 自动化测试：将大量的重复性的测试工作交给计算机完成，通常是使用自动化测试工具来模拟手动测试步骤，执行某种程序设计语言编写的过程

• 开发者测试：开发人员进行测试
• 用户测试：用户方进行测试
• 第三方测试：专业的第三方承担测试

• $\alpha$测试：一个用户在开发环境下进行的测试，也可以是公司内部的哟农户在模拟实际操作下进行的测试
• $\beta$测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用$\beta$版本，并要求用户报告

• 基于对用户如何使用被测试软件的了解来进行测试的方法
• 经验告诉我们：复杂的软件产品有许多错误，但用户一般只能找出这些错误中很少的一部分
• 为给用户带来最大利益，要着重对那些用户可能发现的错误进行测试和修改工作

• 定义
  • 一种基于规格说明，不要求考察代码，以用户视角进行的测试
• 意义
  • 有助于软件产品的总体功能验证
  • 检查明确需求和隐含需求
  • 采用有效输入和无效输入
  • 包含用户视角
• 实施者
  • 软件测试部门，有经验的测试人员
• 步骤
  • 熟悉规格说明书，理解测试需求
  • 生成测试用例
  • 执行测试
  • 判定测试结果

• 一种基于需求的测试
• 目的
  • 确认软件需求规格说明书列出的需求是否都正确实现
• 前提
  • 软件需求规格说明书已经过仔细评审
  • 隐含需求已经明确化
• 优点
  • 黑盒测试与软件具体实现无关，所以如果软件实现发生了变化，测试用例仍然可以使用
  • 设计黑盒测试用例可以和软件实现同时进行，因此可以压缩项目总的开发时间

• 正面测试
  • 通过正面测试用例产生一组预期输出验证产品需求
  • 目的：证明软件对于每条规格说明和期望都能通过
• 负面测试：
  • 展示输入为非预期输入时，产品没有失败
  • 目的：产品没有设计、没有预想到的场景，尝试使系统垮掉
    

• 定义：等价类是
  • 测试相同目标或暴露相同软件缺陷的一组测试
  • 等价类是指输入域的某个自己，该子集中的每个输入数据对介入软件中的错误都是等效的，
• 原理
  • 将程序的输入域划分为等价类，以便导出测试用例
  • 它视图通过设计一个测试用例来尽可能发现多个错误，从而减少测试用例数目，降低测试工作量
• 等价类划分
  • 如果软件行为对一组值来说是相同的，则称这组值为等价类
  • 产生相同预期输出的一组输出值叫一个划分
• 有效等价类和无效等价类
  • 有效等价类：完全满足产品规格说明的输入数据，即有效的、有意义的输入数据构成的集合
  • 无效等价类：不满足程序输入要求或者无效的输入数据构成的集合
• 等价划分准则
  • 输入条件是布尔表达，则可以定义一真一假的有效等价类和无效等价类
  • 输入条件为一个范围，则可以定义一个有效等价类和两个无效等价类
  • 输入数据个数有规定，则可以定义一个有效等价类和两个无效等价类
  • 输入条件代表集合的某个自己，则可以定义一个有效等价类和一个或多个无效等价类
  • 输入条件代表一组列表形式的数据，则可以定义N个有效等价类和无效等价类
  • 输入条件代表符合某几个规则，则可以定义多个有效等价类和若干个无效等价类
    

• 原理

  • 软件的输入和输出之间存在因果逻辑关系，可以用因果图刻画
  • 因果图可以从规格说明书中获得

• 过程

• **$C_i$表示原因，$E_i$**表示结果

  • 恒等：

  • 非：

  • 或：

  • 与：

• 互斥(E)：多个原因不能同时成立，最多有一个能成立 即Ci不能同时为1：

• 包含(I):多个原因中至少有一个必须成立 即Ci不能同时为0:

• 唯一(O):多个原因中必须有一个且只有一个成立 Ci只有一个为1：

• 要求®:当C1成立，C2也必须成立:

• 屏蔽(M):当E1是1时，E2必须是0，当E1是0，E2的值不定：

• 组成
  • 条件桩：列出所有可能问题
  • 条件项：列出条件所有可能取值
  • 动作桩：列出可能采取的操作
  • 动作项：指出在条件项的各种取值情况下应采取的动作
• 决策表化简

• 略

• 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是对等价划分发的补充，这种情况下，其测试用例来自于等价类边界

• 软件的主要缺陷源：条件、边界
  • 条件：变量取值需要满足各种约束
  • 边界：变量的各种极限取值
• 边界值分析
  • 能够有效补货出现在边界处缺陷的一种测试方法，利用并扩展了缺陷更容易出现在边界处的理念
• 缺陷容易出现在边界的原因
  • 使用比较操作符未仔细分析
  • 等等等等

• 使用边界值分析方法设计测试用例吗
  1. 确定边界情况，通常是输入和输出的等价类的边界
  2. 应当选取正好等于、恰好大于、恰好小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据

• Paul Jorgensen公式
  • $n$：存在边界值的参数个数
  • $m$：边界值条件数
  • $4n+1$：基本边界测试
    • Min, min+1, max, max-1 nom 其他参数典型值
  • $6n+1$：健壮性边界测试
    • min,min+1,min-1,max,max+1,max-1,nom
  • $3m$：边界条件测试
    • 条件本身、条件$\pm 1$

• 边界值需要彻底测试
• 考虑资源极限，如有限缓存
• 需求规格中对硬件资源的限制
• 输出值和边界也需要考虑

• 特点

  • 基于代码
  • 尽可能覆盖实现的行为

• 原因

  • 确保每段代码都被执行，避免对应的缺陷
  • 某些白盒测试技术可以实现自动化测试
  • 是黑盒测试/功能测试的补充
  • 能够覆盖高层规范说明中忽视的底层细节

• 定义

  • 一种基于源程序或代码的测试方法
  • 根据源程序或代码结构与逻辑，生成测试用例以尽可能地多发现并修改源程序错误
  • 白盒测试分为静态和动态两种类型

• 实施者

  • 单元测试阶段：开发人员
  • 集成测试阶段：测试人员和开发人员

• 步骤

  • 程序图
  • 生成测试用例
  • 执行测试
  • 分析覆盖标准
  • 判定测试结果

• 进入和退出条件

  • 进入条件：
    • 编码开始阶段
  • 退出条件：
    • 完成测试计划
    • 发现并修正了错误
    • 预算和开发时间

1. 定义：在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有事也成为了结构化分析
2. 理由
   1. 尽早发现软件缺陷
   2. 为后继测试中设计测试用例提供思路
3. 优点
   1. 可能发现某些机器发现不了的错误
   2. 利用不同人对代码的不同观点
   3. 对照设计，确保程序能完成预期功能
   4. 不但能检测出错误，还可以尝试确定错误的根源
   5. 以增加人工成本为代价，节约计算机资源
   6. 尽早发现缺陷，避免后期缺陷修复造成的巨大压力

1. 不但要提供软件源代码，还要提供可执行程序，测试过程需要在计算机上执行程序

2. 测试流程：

3. 覆盖准则：

   1. 意义：定义“测试执行到何时才算充分”
   2. 作用：软件测试的一种度量标准，描述程序源代码被测试的程度
   3. 一种测试技术通常有一种对应的覆盖准则

1. 基于控制流的方法
   1. 语句覆盖测试：
      1. 语句覆盖：保证程序中的每条语句都执行一遍
   2. 条件测试：
      1. 判定覆盖：表征判断取True False都执行一遍
      2. 条件覆盖：保证每个条件取值都执行一遍
   3. 路径测试：
      1. 路径覆盖：覆盖程序中所有的可能路径
2. 基于数据流的方法
   1. 数据流测试