软件质量保证与测试 期中复习

第一章 引论

软件测试

软件测试的正向思维

• 软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果

软件测试的反向思维

• 测试是为了证明程序有错，而不是证明程序无错误

软件测试的定义

IEEE的定义

• 在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价
• 分析某个软件项以发现现存的和要求的条件之差别（即错误）并评价此软件项的特性

更完整的定义

• 软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体

软件质量保证SQA

• 测试 VS SQA：
  • SQA是一项管理工作，侧重于对流程的评审和监
  • 测试是一项技术性的工作，侧重对产品进行评估和验证

软件测试的目的

• 以更少的支出（需求变更、维护、客服等成本）来谋取收入支出比达到最大化

第二章 基本概念

2.1 软件缺陷

软件质量

• 软件缺陷是相对质量存在的，质量是缺陷的对立面

• 定义

  • IEEE的定义：质量是系统、部件或过程满足　①明确需求 ②用户期望的程度不同
  • 软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和(ISO 8492)
  • 软件质量：软件产品满足使用要求的程度

• 软件质量的标准：功能性、可用性、可靠性、性能、容量、可伸缩性、可维护性、兼容性、可扩展性

• 软件质量特征（ISO 9126）：功能、可靠、易用（可用）、效率、可维护、可移植

• Boehm软件质量模型

  • 产品操作：正确性、可靠性、效率、完整性、可用性

  • 产品修改：可维护性、可测试性、灵活性

  • 产品维护：可移植性、重复性、复用性

软件缺陷的定义*

• 任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求
• IEEE的定义：
  • 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。
  • 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背

软件缺陷的产生

• ①技术问题：算法错误，语法错误，计算和精度问题，接口参数传递不匹配
• ②团队工作：沟通不充分，误解
• ③软件本身：文档错误、用户使用场合(user scenario)，时间上不协调、或不一致性所带来的问题，系统的自我恢复或数据的异地备份、灾难性恢复等问题

2.2 软件测试的分类

• 测试阶段或层次：验收测试、系统测试、集成测试、单元测试
• 是否需要了解系统内部实现/方法：白盒测试、黑盒测试
• 目标/特性：功能测试、强壮性测试、性能测试、适用性测试、安全性测试、可靠性测试
• 不同的分类：
  • 按测试的对象或范围分类，如单元测试、文档测试、系统测试等
  • 按测试目的分类，如功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等
  • 根据测试过程中被测软件是否被执行，分为静态测试和动态测试
  • 根据是否需要了解系统内部实现，可分为白盒测试和黑盒测试

2.3 静态测试和动态测试

• 将需求和设计的评审纳入测试的范畴，可看作是广义测试
• 静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等
• 静态分析的查错和分析功能是其他方法所不能替代的
• 动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证

产品评审*

• 评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范
• 评审的形式/方法：互为评审、轮差、走查、会议评审
• 评审分类：管理评审、技术评审、文档评审、流程评审

静态分析*

• 人工检测：人工检测偏重于编码风格、质量的检验，对设计、代码进行分析，有效地发现逻辑设计和编码错误
• 计算机辅助静态分析：利用静态分析工具对被测程序进行特性分析

验证与确认*

• Verification：验证产品满足规格设计说明书的一致性
• Validation：验证产品所实现的功能是否满足用户的需求

2.4 主动测试和被动测试

• 主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果
• 被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据

2.5 黑盒测试和白盒测试

2.6 软件测试级别

单元测试*

• 单元测试针对程序系统中的最小单元—模块或组件进行测试，一般和编码同步进行，主要采用白盒测试方法，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误
• 单元测试一般由编程人员和测试人员共同完成，而以开发人员为主

集成测试

• 也称组装测试、联合测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题。两种集成方式：一次性集成方式和增殖式集成方式

系统功能测试

• 在完成集成测试后进行，而且是针对应用系统进行测试。基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证

系统非功能测试

• 将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试

验收测试

• 向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样

安装测试

• 按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试

第三章 软件测试方法

• 黑盒：基于经验和直觉、错误推测法等价类划分法边界值分析法判定表方法因果图法正交试验法功能图法
• 白盒：语句覆盖、判定覆盖条件覆盖、判定条件覆盖条件组合覆盖、基本路径覆盖

（黑盒方法）

3.1 基于直觉和经验的方法*

• 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例
• ALAC测试方法：是一种基于客户使用产品的知识开发出来的测试方法
• 错误推测法：是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性的进行测试

3.2 基于输入域的测试方法

等价类划分法*

• 等价类：是某个输入域的子集，在该子集中每个输入数据的作用是等效的。将输入数据分成若干个子集，从每个子集选取一个代表性的数据作为测试用例
• 分为有效等价类和无效等价类

边界值分析法*

• 很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以更有效地发现缺陷
• 设计方法：
  • 确定边界情况（输入或输出等价类的边界）
  • 选取正好等于、刚刚大于或小于边界值作为测试数据

3.3 基于组合技术和组合优化的方法*

判定表/决策表方法

• 判定表由“条件和活动”两部分组成，即列出一个测试活动执行所需的条件组合

  • 条件桩：列出问题的所有条件

    动作桩：列出可能针对问题所采取的操作

    条件项：针对所列条件的具体赋值

    动作项：列出在条件项（各种取值）组合情况下应该采取的动作

    规则：任何一个条件组合的特定取值及其相应要执行的操作

因果图

• 多种输入条件的组合，产生多种结果设计测试用例

两两组合方法（Pairwise）

• 大部分缺陷是在两个变量取值冲突的测试时被发现的

正交实验法

• 本质上是用数据统计统计学中的方法进行测试通过正交法可以用少量测试用例来覆盖大多数的测试情况
• 适用于存在多个或者输入和多个输出的情况
• 正交实验设计方法：从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（条件组合），从而合理地安排实验（测试）的一种科学实验设计方法
• eg：4因子 3水平（状态）3×3×3×3

（白盒方法）

3.4 基于逻辑覆盖的方法

• 设计若干测试用例，执行被测程序以后，要使…

语句覆盖*

• 语句覆盖：使程序中的每个可执行语句至少被执行一次

• 优点：可以很直观的从源代码获得用例，无需细分每条判定表达式

  缺点：仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。语句覆盖是最弱的逻辑覆盖

判定覆盖*

• 判定覆盖：使程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足

• 优点：比语句覆盖具有更强的测试能力。同时具有和语句覆盖一样的简单性

  缺点：大部分的测试用例是由多个逻辑条件组合，若仅判断其整个的最终结果，必然会遗漏部分测试路径，仍是很弱的逻辑覆盖

条件覆盖*

• 条件覆盖：使每个判断中的每个条件的可能取值至少满足一次

• 优点：增加了对条件判断情况的测试，增加了测试路径

  缺点：条件覆盖不一定包含判定覆盖

判定条件覆盖*

• 是判定和条件覆盖设计方法的交集，即设计足够的测试用例。使得使判定条件中的所有可能（条件成立、不成立）至少执行一次取值.同时,所有判断的可能结果（取真，取假）至少执行一次

• 优点：能同时考虑到判定，条件两种覆盖

  缺点：未考虑条件的组合情况

条件组合覆盖*

• 使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次

• 与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次

• 优点：组合覆盖满足了判定覆盖、条件覆盖、和判定、条件覆盖准则。

  缺点：线性的增加了测试用例的数量；条件组合效率不高，有些测试是不必要的；判定/条件 还不够强

优化 条件/判定覆盖

• 每个判定的所有可能结果至少能取值一次；

• 判定中的每个条件的所有可能结果至少取值一次；

• 一个判定中的每个条件曾经独立地对判定的结果产生影响；

• 每个入口和出口至少执行一次
  

基本路径测试

• 设计所有的测试用例，来覆盖程序中的所有可能的执行路径

• 并不是测试所有路径的组合，仅仅保证每条路径被执行一次

• 优点：这种测试方法可以对程序进行彻底的测试

  缺点：需要设计大量的，复杂的测试用例，使得工作量呈指数增长，不见得能把所有的条件组合都覆盖

其他

MBT方法

• 基于模型的测试(MBT，Model-based testing）：通过构建能够正确描述被测软件系统功能特性的模型，然后基于这个模型产生测试用例并执行这些测试用例的过程

功能图法

• 每个程序的功能通常由静态说明和动态说明组成

• 静态说明描述了输入条件和输出条件之间的对应关系

• 动态说明描述了输入数据的次序或者转移的次序

• 功能图法就是为了解决动态说明问题的一种测试用例的设计方法

• 功能图由状态迁移图（state transition diagram，STD）和逻辑功能模型（logic function model， LFM）构成

模糊测试方法

• 就是构造大量的变异数据作为系统的输入，从而检验系统在各种数据情况下是否会出现问题

总结

第四章 软件测试流程和规范

4.1 传统的软件测试过程

V模型

W模型

TMap

• TMap(Test Management Approach，测试管理方法)是一种结构化的、基于风险策略的测试方法体系
• TMap所定义的测试生命周期由：计划和控制、准备、说明、执行和完成等阶段组成
  

4.2 敏捷测试过程

敏捷测试的特征*

①尽早和持续地开展测试

②能及时完成对软件质量全面评估

③软件本身是测试研究和分析最主要的对象

④在满足所要求的质量，测试进行得越快越好

⑤测试人员必须和项目干系人保持密切协作

①对测试人员足够信任和尊重

②测试计划、设计和执行力求简单

③对测试技术精益求精

④不断反思，持续优化测试设计

敏捷测试流程