软件测试知识概述

软件测试

• 是提高软件产品质量的重要手段
• 开销占总成本的 30%-50%
• 经济观点 以最小的代价获得最高的软件产品质量
• 两面性： 正向思维：验证软件工作正常。逆向思维：假定软件有错误。为了发现尽可能多的错误，而不是证明程序无错
• 是SQA(软件质量保证)的重要手段之一，提供所需数据，作为质量评价的客观依据，他们都贯穿整个软件生命周期，SQA 是一项管理工作（对流程），测试是一项技术性工作（对产品）
• 测试驱动开发思想： 测试在先，编码在后
• 软件质量 满足用户规定的需求的程度
• 软件缺陷 从产品内部看是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看是系统所需要实现的某种功能的失效或违背
• 软件缺陷的变现行为 用户的功能没有完全实现
• 测试用例是测试设计的产物
• 被动测试方法中，软件产品运行在实际环境中，测试人员不干预产品运行，而是监控产品的运行，获取系统运行的数据，包括输入和输出数据。

V 模型

软件测试 V 模型贯穿着整个软件生命周期，避免了瀑布模型所带来的的误区–软件测试在代码完成之后进行。

软件验证的 4 个层次：

1. 需求验证 —> 验收测试，客户需求的确认测试
2. 系统架构设计的验证 —> 系统非功能性测试
3. 产品详细设计的验证 —> 功能测试
4. 代码的验证 —> 单元测试和集成测试

软件测试的分类

1. 按测试阶段或层侧：（需求评审、设计评审）、单元测试、集成测试、系统测试、验收测试
   1. 单元测试：针对系统中最小的单元–类、函数、模块或组件。主要采用白盒测试，检查功能和编码错误
   2. 集成测试：将模块按照设计要求组装起来进行测试。目标是发现单元之间的接口问题
   3. 系统功能测试：一般在集成测试后进行，针对系统从用户角度进行功能验证（用户界面、操作、数据输入输出、存储）
   4. 验收测试：验证软件的功能和性能及其他特性是否和用户的要求一致（同用户）
2. 按方法：黑盒测试、白盒测试
3. 按目标/特性：强壮性测试、性能测试、适用性测试、安全性测试、可靠性测试
4. 被测软件是否被执行：静态测试、动态测试

1.为什么软件需求规格说明书是软件缺陷存在最多的地方？
（1）用户是非计算机专业人员，沟通存在困难，理解不一致
（2）完全靠想象描述系统，有些特性不够清楚
（3）用户需求不断变化，易出现前后文、上下文矛盾
（4）对规格说明书不够重视，投入的人力、时间不够
（5）没有在整个开发队伍中进行充分沟通

软件测试的方法

1. 黑盒测试和白盒测试
   1. 黑盒测试（功能测试、数据驱动测试）：分析事物的输入输出以及周边条件
      1. 特点：不关注内部结构 ，关注外部界面、输入输出、用户需求。验证产品每个功能是否能正常使用，评估软件质量。
      2. 方法： 等价类划分、边界值分析（也可用于白盒测试）、错误推测（基于人的直觉和经验）
      3. 局限性： 不可能穷举测试、覆盖率难以测定或达到一定水平就难以提高
   2. 白盒测试（结构化测试、逻辑驱动测试）：分析事物内部结构和运行机制。
      1. 基本原则：分支覆盖–>逻辑覆盖
      2. 局限性：不能穷举出所有路径、不能检查出程序违反了设计规范（实现了用户不需要的功能）、不能检查程序因遗漏路径而出错、可能发现不了与数据相关的异常错误
      3. 方法： 语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、基本路径覆盖

	白盒测试方法	黑盒测试方法
静态测试方法	对源程序代码的语法检查、扫描、评审等	对需求文档、需求规格说明书的审查活动
动态测试方法	在单元测试中，一边运行代码，一边对结果进行检查、验证和调试	在运行程序时，通过数据驱动对软件进行功能测试，从用户角度验证各项功能

2. 基于直觉和经验的方法：错误推测
3. 基于输入域的方法（适合单变量，输入变量独立）：等价类划分、边界值分析
   1. 等价类划分： 有效等价类、无效等价类。建立等价类表–>生成测试用例
   2. 边界值分析：（通常作为等价类划分法的补充）使用等价类的边界作为测试条件，不仅要考虑输入条件，还要考虑输出条件
   3. 常见的边界值：
      1. 16bit 整数：32767 和 -32768
      2. 报表：第一行和最后一行
      3. 数组：第一个和最后一个
      4. 循环：第 0 次、第 1 次和倒数第 2 次、最后一次
4. 基于组合及其优化的方法（适用于多种条件组合）：判定表法、因果图法、正交实验法
   1. 判定表法：
      1. 定义：把所有输入的各种组合值以及对应输出值都罗列出来
      2. 适用条件：多因素输入和输出，根据某一个输入组合能直接判断出结果，只有 0、1 两个取值
      3. 组成：
         1. 条件桩（列出问题的所有条件）
         2. 动作桩（问题规定可能采取的操作）
         3. 条件项（针对左侧条件的取值 0、1、—) “—“表示与之取值无关
         4. 动作项（在条件项的各种取值下应采取的动作）、规则（某一个条件组合的取值及对应的操作）
      4. 判定表简化：规则合并、规则包含
   2. 因果图法：找出因和果，画出因果图，通常和判定表结合使用
      1. 介绍：Ci 表示原因，Ei 表示结果，各结点状态可表示为 0 或 1
      2. 原因与结果之间的关系：恒等、非~、或 ∨、与 ∧
      3. 约束关系：互斥 E、包含 I、唯一 O、要求 R、强制或屏蔽 M
5. 基于逻辑覆盖的方法
   1. 覆盖率：度量测试完整性。
   2. 逻辑覆盖
      1. 点覆盖：语句覆盖、块覆盖
      2. 边覆盖：判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖
   3. 语句覆盖（最弱的）：程序中每个可执行语句至少执行一次
   4. 块覆盖：语句覆盖的变体，指令块是函数体内部的一组语句，这组语句中不存在（会引起分支的）控制语句
   5. 判定覆盖（分支覆盖）：每个判定的每种可能的结果（真或假）都至少执行一遍
   6. 条件覆盖：每个判定中的每个条件的每种可能结果都至少执行一次
   7. 判定-条件覆盖：每个判定中的每个条件的每种可能结果都至少执行一次，同时每个判定语句本身所有可能分支也至少执行一次
   8. 条件组合覆盖：每个判定中所有可能的条件取值组合都至少执行一次
   9. 基本路径覆盖：程序中所有可能的路径都至少执行一次
   10. 逻辑覆盖关系

graph LR
语句覆盖-->判定覆盖
判定覆盖-->判定-条件覆盖
条件覆盖-->判定-条件覆盖
判定-条件覆盖-->条件组合覆盖
判定覆盖-->路径覆盖

软件测试过程和规范

1. 传统的软件测试过程：需求评审、设计评审、单元和集成测试、系统测试、验收测试
2. W 模型：测试过程和开发过程是同步关系，相互依赖
3. TMap（测试管理方法）：是一种业务驱动的、基于风险策略的、结构化的测试方法体系。基本内容：计划、控制、基础设施、准备、说明、执行、完成
4. 敏捷测试特征：有鲜明的敏捷开发特征，测试驱动开发是核心，单元测试是基础；开发人员承担更多的测试，更依赖整个团队
5. 敏捷测试与传统测试的区别
   1. 强调整个团队对测试负责
   2. 强调持续集成，持续质量反馈
   3. 强调测试速度和适应性
   4. 不离用户需求，将验证和确认统一起来
   5. 清掉面对面沟通协作、强调团队责任
   6. 更关注产品本身
   7. 高度的自动化
6. 敏捷测试 = 持续的质量反馈
7. 基于风险的测试策略：评估测试的优先级，先做高优先的测试
8. 软件测试规范：对软件测试的流程过程化并对每一过程元素进行明确的界定，形成完整的规范体系
9. 软件测试规范的内容：角色、进入准则、输入项、活动、输出项、验证与确认、退出准则、度量

单元测试和集成测试

• 按阶段进行测试是一种基本的测试策略
• 单元测试是测试过程中的第一个阶段
• 集成测试确保每个单元能够正常结合起来构成系统
• 单元测试和集成测试可交替、同步进行
• 主要采用白盒测试方法，包括对代码的评审、静态分析和结合测试工具进行动态测试
• 静态分析的查错和分析功能是其他方法不能替代的 -单元测试是为了及早发现错误，降低成本

1. 单元测试的任务

   1. 单元独立执行路径的测试
   2. 单元局部数据的测试
   3. 单元接口的测试
   4. 单元边界条件的测试
   5. 单元容错性的测试
   6. 内存分析

2. 走查和审查对比

	代码走查	会议审查
准备	通过设计和编码	事先准备 Spec、程序设计文档、源代码清单、代码缺陷审查表等
形式	非正式会议	正是会议
参加人员	开发人员为主	项目组成员，包括测试人员
主要技术方法	无	缺陷检查表
生成文档	会议记录	静态分析错误报告
目标	代码标准规范无逻辑错误	代码标准规范无逻辑错误

3. 桩程序和驱动程序
   桩程序：替代被测模块工作过程中所调用的下层模块
   驱动程序：替代被测模块的上级模块，可以调用被测模块
4. 集成测试：将通过测试的单元按照设计要求集成起来再进行测试，以检查这些单元接口是否存在问题
5. 非渐增式模式和渐增式模式

非渐增式	渐增式
先分别测试每个模块，再把所有模块按设计要求结合成所要的程序。如大棒模式	把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完成以后下一个应该测试的模块结合进来测试，测试范围逐步增大
开销小	要编写的软件较多，工作量大
发现模块间错误时间晚	发现模块间错误时间早
发现错误，较难诊断	发生的错误往往和最近加进来的那个模块有关
测试不彻底	测试更彻底
可以并行测试	需要较多的机器时间
尽可能的缩短测试时间，使用最少的测试用例验证系统

系统测试

• 系统测试 是将经过集成测试后的软件，作为计算机系统的一部分，与计算机硬件、某些支持软件、数据和平台等系统元素结合起来，在真是运行环境下对计算机系统进行一系列严格有效的测试
• 系统测试目的：充分运行系统，验证整个系统是否满足功能和非功能性的质量需求
• 回归测试 在程序有修改的情况下保证原有功能正常，不需要进行全面测试，而是根据修改的情况进行有效测试，保证改动不会带来新的验证错误。
• 在软件开发和测试的各个阶段都可能需要进行多次回归测试
• 回归测试的目的 验证缺陷得到了正确的修复,同时对系统的变更,没有影响以前的功能
• 回归测试的策略（要兼顾效率和有效性）： 再测试全部用例、基于风险选择测试、基于操作剖面选择测试、再测试修改的部分、更智能的选择方法
• 常见的性能问题 资源耗尽、资源泄露、资源瓶颈
• 系统性能指标 资源使用率、行为表现
• 性能测试的过程 确定性能测试需求、开发测试脚本、建立性能测试负载模型、执行性能测试、提交性能测试报告
• 压力测试（强度测试） 是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行软件，来测试系统的性能、可靠性、稳定性等
• 容量测试的作用 了解软件系统的承载能力，确定软件系统还能保持主要功能正常运行的指标极限值。帮助用户经济地规划系统，优化系统和网略配置。
• 安全性测试 检查系统对非法入侵的防范能力
• 容错性测试 检查系统 的容错能力，检查检查软件在异常条件下自身是否具有防护性措施或某种灾难性恢复的手段
• 软件的可靠性（软件质量的重要指标） 软件系统在规定的时间及规定的环境条件下，完成规定功能的能力
• 可靠性测试、兼容性测试

验收测试

• 验收测试（交付测试） 在软件产品完成了系统功能和非功能测试之后、产品发布之前所进行的的软件测试活动。是软件测试的最后一个阶段。
• 验收测试的目的
  1. 验证系统是否达到了用户需求规格说明书中要求
  2. 测试尽可能多的发现软件中留存的缺陷，从而为软件进一步改善提供帮助，并保证系统或产品最终被用户接收
  3. 验收测试主要包括易用性测试、安装测试、文档（如用户手册）测试等几个方面的内容
• 产品规格说明书验证 根据产品说明书，验证产品的每一项特性，并在验证结束时提交基于产品规格说明书的报告
• 用户界面的 7 个因素 符合标椎和规范、直观性、一致性、灵活性、舒适性、正确性、实用性
• 可用性测试

测试自动化

手工测试	自动化测试
发现缺陷率高	高效率（速度）
容易实施	高复用性
创造性、灵活性	覆盖率容易度量
覆盖率量化困难	准确、可靠
重复测试效率低	不知疲劳
不一致性、可靠性低	激励团队士气
依赖人力资源	机械、难以发现缺陷
	一次性投入大

1. 测试自动化 是提高测试效率、覆盖率和可靠性的重要手段
2. 适用范围
   1. 在系统功能逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，多采用手工测试（黑盒）方法
   2. 单元测试、集成测试、系统负载或性能、稳定性、可靠性测试等比较适合采用测试自动化
   3. 对那种不稳定软件的测试、开发周期很短的测试、一次性的软件等不适合测试自动化
3. 自动比较技术 是测试自动化不可缺少的技术
4. 测试工具的使用是自动化测试的主要特征，也是自动化测试的主要手段