软件测试笔记三

掌握分类树测试方法

1.分类树测试方法
（1） 分类树的概念
分类树测试方法是由 Grochtmann 和 Grimm 在 1993 年提出，是软件功能测试方面一种有效的测试方法，通过分类树把测试对象的整个输入域分割成独立的类
（2） 分类树测试法的引入背景
（3）分类树测试方法的概念
分类树测试方法以适合测试的方式来评估测试对象的不同特性，并以此为基础考虑测试的输入域。
针对测试对象的每个特性进行部分的或完全的分类（Classification），并可根据需要对分类后的特性作进一步的细分，通过将测试对象不同特性的分类组合而得到不同的测试用例。
按照分类树方法，测试对象的输入域被认为是由各种不同的方面组成并且都与测试相关
分类树测试方法的***主要优点***是将测试用例设计变为结构化和系统的过程，使得测试用例设计更加容易处理、理解和实现文档化
（4）使用分类树测试方法设计测试用例
分类树测试方法有两个重要步骤：
第一，根据测试对象规格说明设计分类树
第二，根据测试要求创建测试用例
引入分类树方法的工具帮助测试者创建和选择测试用例
逻辑扩展分类树编辑器 CTE-XL
2.分类树编辑器CTE-XL
CTE-XL 能方便地实现设计分类树与根据测试要求创建测试用例这两个重要步骤，并针对两个步骤分别提供相应功能，系统且有效地确定测试用例。

分类树 ：创建分类树区域
组合表格：根据分类树得到测试对象的输入参数的组合表格，根据表中不同取值 创建相应的测试用例
属性窗口：修改激活对象的不同属性如名称
测试用例列表：最终生成的测试用例列表
*3.分类树测试方法的应用
（1）生成分类树
（2） 创建完全组合的测试用例 ***
（3）创建特定要求组合的测试用例
（4）生成测试用例报告斜体样式

基于结构的测试有：逻辑覆盖测试法、路径测试 基于规格说明的测试：等价类划分法、边界值分析法、因果图和决策表法、配对测试法、分类树测试法

掌握状态转换测试法

1． 状态转换测试法原理
(1) 关于具有状态转换特性的测试对象的识别
针对，如：针对GUI系统；面向对象的系统；Web应用系统等。这些特定软件的测试用例设计大多采用状态转换测试法来完成。
在采用状态转换测试法时
首先要获得软件（系统）的状态转换 图
状态图是状态机的图解形式。
状态转换图是设计状态转换测试用例的基础，而基于状态转换图实施的测试就是状态转换测试
2. 状态转换测试法
（1） 将状态图转换为状态树
采用这种策略，首先需要将状态图转换为状态转换树，将可能具有无限多的 状态循环的状态图转换为不含循环的、具有一定数目状态的状态转换树。
转换的基本步骤
步骤1：将初始（开始）状态作为状态转换树的根根在整个状态转换树中的层次为1
步骤 2：设当前生成状态转换树的层次为 N, 从左到右检查所有层次为 N 的节点，将该节点对应的下一可能的状态作为其子节点， 状态之间转换作为两状态的边。
步骤 3： 重复步骤，直到位于层次 N 上的节点出现在层次 M 上，且 M≤N。则，该节点成为最终的叶节点，无须继续生成其他子节点；若该节点状态已是结束，则停止进行状态转换
该状态转换数可根据不同的测试强度或覆盖率得到测试用例： 1）至少覆盖所有状态一次。
2）至少覆盖所有事件一次。
但覆盖循环的测试用例对发现一些累计的计算错误或资源使用方面的缺陷很重 要，如内存泄露。所以在设计测试用例时，需确定合适的覆盖率
（2） 状态转换表
状态转换表可直接从状态转换图中得到，或根据测试对象的规格说明得到。
状态转换表由4个部分组成：当前状态、事件、活动、后续状态
创建状态转换表能够发现被测试对象规格说明中可能遗漏的组合，或没有文档化的组合。
（3） 关于N-Switch 的说明
他将N-Switch定义为程序流图中长度为 n+1 的连续的边或弧线 （这通常表示在状态图中的循环）的序列。因此，单独的一条边（或转换）就是一个 0-Switch，两条连续的边的序列就是 1
Switch。
（4） 状态转换测试的覆盖率准则（测试强度）
1）状态覆盖：每个状态至少执行一次。
2）事件覆盖：每个事件至少执行一次。
3）状态转换覆盖：每个状态转换至少执行一次。
4）路径覆盖：每个路径至少执行一次
3. 状态转换测试法的应用举例
（1）堆栈的状态转换测试
堆栈有三种不同的状态：空（empty）、非空(filed)和满(full)。（2）具备健壮性的堆栈测试转换树 (0-Switch)
这种情况实际上是考虑到了堆栈对于异常情况的处理，通过增减健壮性测试来确认是否会出现不应出现的状态转换
（4）状态转换树（1-switch
如要求得到覆盖率达到1-switch，需要扩展0-switch的状态转换树得到
体方法是：1-switch的状态转换树需要在状态‘空’后面增加两条转换，在状态‘非 空’后面增加5条转换，在状态‘满’后面增加3条转换

掌握用例/场景测试法;

1. 用例的相关概念
用例是描述软件（程序）系统需求的一种方法，使用该方法来描述系统需求的过程就是用例建模
采用用例方法能解决传统需求描述方式 （如需求规格说
明）的某些缺点，如传统的需求规格说明很容易混淆需求和设计的界限，造成不清楚系统需求应详细到何种程度。
其次，传统需求描述的一个缺点是需求分割了各个系统功能的应用环境，使开发者较难理解这些功能输入和相关联来实现一个完整的系统服务或功能
用例模型主要由模型元素组成
（1） 参与者（Actor）
（2） 用例（Use case）
用于表示软件系统所提供的服务，定义系统如何被参与者所用，描述的是参 与者为了使用软件系统提供的某个功能而与系统之间发生的一段“对话”。
2．用例规格
用例规格说明主要包括以下内容：

（3）通信关联
用于表示参与者和用例之间的对应关系
 简要说明：概述该用例的作用和目的
 事件流： 包含基本流与备选流，所有场景都需要通过事件流表示
 用例场景：包含成功场景与失败场景。场景主要由基本流和备选流组合
而成
 特殊需求：描述与该用例相关的非功能性需求。它包含性能、可靠性、
可用性、可扩展性等和设计约束（指所使用的操作系统及开发工具等）
 前置条件：执行用例之前系统必须所处的状态
 后置条件：用例执行完毕后系统可能处于的一组状态
3.用例/场景测试法的应用

动态分析指的是在组件（单元）或系统的执行过程中评估其行为的过程

复习第二单元软件测试经典技术所学知识
完成第二单元软件测试经典技术测验；

了解自动化测试基本概念

1，自动化测试原理

1．自动化测试技术的产生
软件自动化测试技术的产生，首先源于软件产品的开发过程呈现出不断改进的特点和发展
转向和发展最主要的特点就是软件开发过程呈现不断迭代的过程，
软件自动化测试已是现代软件测试的重要策略与技术手段。
目前，自动化测试工作正在呈现职业化（系列）的特征，自动化测试规划设 计工程师、自动化测试架构（部署）工程师、自动化测试执行工程师等岗位及工 作分类在软件发达国家和涉及软件开发和运行的各类企业里比比皆是。
2. 自动化测试概念
1） 自动化测试的概念
 使用自动化测试工具来验证各种软件测试需求，测试活动实施与管理； 通过自动化测试工具运用，按测试管理者预定计划自动运行。
 自动化测试通常指测试的自动化过程，在预设条件下自动运行被测软件 或程序（被测对象）并自动分析、评估测试的结果。
 自动化测试是指测试过程的自动化。。这个概念意味着测试手段以非手工 方式逐个对测试用例进行设计或测试的执行 自动化测试的一个显著特点是：测试不会因测试人员的不同而产生不致的测试结果。
***自动化测试作描述性的定义：***使用一种自动化测试工具来验证
各种测试需求，包括测试活动的实施与管理。自动化测试通过运用自动化测试工具，并结合其他手段，按照测试管理的预定计划自动进行，以减轻手工测试工作量或手工无法完成的测试目标
2） 自动化测试的适用范围和其优势
1对涉及非常重要的测试和范围宽广的测试；
2 期望测试结果完全可以预料，测试的复用性要求较强的情形；
3 要求加快软件开发周期，期望通过自动化测试缩短测试周期，并通过自 动化测试希望增加软件信度的测试。如安全性测试等 ；
4 执行某些手工测试困难或不可能进行的测试。如性能测试的负载测试等。
 对运行频繁的测试，或在较少时间内需更多测试。如敏捷开发中的每日 构建中的测试。
 需要进行全面、准确、快速响应的测试，并进行全面的测试管理运用。 如实施测试管理的全过程。
3. 自动化测试原理
自动化测试是软件测试领域的分支，它是自动化理论、人工智能与软件测试技术理论的综合运用
1）自动化测试的实现机理

• 通过测试的自动执行。
• 状态的自动识别
• • 自动的逻辑处理
    - 2）自动化测试的通用流程
     创建和更新测试用例文档
     测试框架设计
    测试框架是自动化测试开发过程中的最重要环节，测试
    脚本基于测试框架
     开发测试脚本
     执行自动化测试用例
     脚本维护
    4. 自动化测试的局限
     当针对不现实的期望
     当缺乏自动化测试的经验时
     当软件开发或测试的相关文档较少或两者不一致时，其自动化测试发现 缺陷或错误的能力将大大降低
     期望通过自动化测试能够发现大量新的缺陷。
     错觉自动化测试的可靠性一定高。
     认为自动化测试无需维护。
     自身技术问题的影响因素

2.自动化测试流程组织框架

1．测试框架
1）框架的概念
这里所说的框架（Framework），通常是指软件应用与软件开发中的一种基础架构。它包含一组供开发使用的组件和公共服务的平台。如，对数据库访问、安全性的功能、消息通信等等的服务和保障
框架定义每个组件之间的通信方式以及对外服务的接口。
所谓架构是指对基础设施所提供的各种功能，它与具体的（软件）业务逻辑无直接的关联。
广义的测试框架包括对测试流程和测试规范的设计的服务和支持。
2）测试框架的作用
测试框架能够实现复用，有两层含义：
① 同一项目内的复用
② 针对某一测试的自动化测试框架，可直接或通过一定修改后被其他同类
型自动化测试项目使用。

测试框架不仅为简单的类库和工具包的集成，还必须通过一定的设计模式来实现其开发形成框架。是其具有结构清晰(松耦合)、易维护(依赖关系小)、易扩展的机制和特点。
3）测试框架的分类
如果按照不同的测试领域划分，有：单元测试框架；功能测试框架；性能测试框架；
如果按照编程语言划分，有：Java测试框架；. NET测试框架等；
如果按照框架使用授权划分，有：开源框架和非开源框架。
2．测试框架的解析
1）功能测试框架
软件的功能是其质量体系的重要组成部分，在自动化测试框架中，基本上都会体现出这个基础和服务。
2）基于数据驱动（Data Driven）的框架
基于数据驱动（Data Driven）的框架是目前较流行且应用广泛的一种测试框架
基于数据驱动的框架的设计思想是使用较少的脚本来产生大量的测试用例。将这种数据驱动的技术应用到自动化测试框架中就形成数据驱动测试框架。

数据驱动测试是将测试过程和测试数据进行分离，其核心思想是将测试用的测试场景与测试数据进行解耦，从而可以有效重用测试逻辑，提高测试覆盖率，从而提高测试用例开发效率的测试方法。
常用驱动方法有：随机驱动；顺序迭代驱动和随机驱动；顺序选择驱动
迭代驱动就是将整个或部分驱动数据集合以循环的方式同测试场景进行动态地耦合，将数据一个个的送入场景。
选择驱动是将测试数据作为整体或经选择子集之后同测试场景进行动态耦合，将选择的数据作为集合送入场景。
基于数据驱动这种测试框架的主要功能或作用是将测试的数据（即输入/输出）是从数据文件中进行读取。
3）关键字驱动（表驱动） 框架
该框架是建立在数据驱动基础之上的一种测试机制，是提高自动化测试的灵活性和扩展性的一种测试框架解决方案

关键字驱动的自动化测试框架是对数据驱动的逻辑扩展，用关键字的形式将测试逻辑封装在数据文件中，测试工具只要能够解释这些关键字即可对其应用自动化，它的核心思想可概括为三个分离
 界面元素名与测试内部对象名的分离
 测试描述与具体实现细节的分离
 脚本与数据的分离
关键字驱动测试框架的优点：
 测试脚本基本等同于手工测试过程的描述，简明、易读。
 测试脚本建立与维护不需要编程知识和技巧。
 框架的实现和脚本编写可同步实施，脚本编写不依赖于任何框架的实现 和程序语言，只需了解关键字的定义即可。
 脚本一次编写，可多处适用。更换测试工具只需要重新启用新的工具实 现关键字解释器即可。
关键字驱动测试框架的缺点：
 框架的开发比较困难。
 关键字解释器的编写需要更高的技巧和专业能力。
关键字描述测试脚本的缺点：
 无法表示复杂的测试逻辑，仅适合顺序的操作流，灵活性较差。
 因为脚本比较简单，则必然会增加对框架的依赖，因此，将会提高框架 的复程度，使开发框架难度加大。
 在框架中，不仅要正确解释各种不同操作对象的不同关键字，还需考虑 那些在其他框架中可以在脚本里实现的对不同错误的恢复和处理的逻辑。

3，自动化测试用例与测试脚本

1．数据驱动测试对自动化测试的影响
数据驱动是以对被测软件的数据模型的测试代替了对功能的测试。从而测试场景的复杂度则会大幅降低，而测试数量则大幅提升。测试脚本的结构得到简化，测试脚本内部的‘硬编码’内容大幅的减少，使得测试的稳定性得到提高，测试用例组获得增加。

2．测试数据的设计
自动化测试数据的设计，主要有几个步骤：
 测试数据规划：结构要符合业务模型，并有效的去重，对有效数据整体 分类。对单一数据划分等价类，可运用在通常划分等价类的所有原则，对数据的修饰，规划测试策略。
 测试数据生成，有三种：采用随机生成方法；将数据组排列；基于统计 学要求的数据生成方法。
 测试数据存储在通用测试工具中，数据的存储方式往往由测试框架内 置来实现。如，使用数据池（Datapool）方法。
 测试数据维护：主要针对数据池进行。
 测试检验：主要是针对着测试点的检验。
3. 自动化测试用例及测试脚本
自动化测试必须要有测试脚本或测试用例的支撑，否则无法进行具体测试。
1）自动化测试用例
自动化测试用例是指在测试执行过程中引用的一个个具体的测试用例。通常为以一个测试用例的集合。或是脚本编辑时指定的测试数据。
2）自动化测试脚本
测试脚本是能够被重复执行的
3）自动化测试脚本的特点
 测试脚本与测试一样，将随着测试模式和测试方法的不同，将以多种形 式出现
 测试脚本是可以变化。
 测试脚本在脱离所依附的系统时，将不能够独自运行。
 自动化测试脚本生成工具，可协助测试人员编制或生成测试脚本。
4）自动化测试脚本种类
 结构化脚本
脚本侧重描述脚本中控制流程的结构化特性。
 共享脚
共享脚本侧重描述脚本中共性的特性。

共享脚本维护开销低于线性脚本（简单的录制-回放），能删除明显的重复，在脚本中增加更智能的功能。
共享脚本开发的配套文档需注意规
范性和完整性。
 数据驱动脚本
脚本式是参数化的。
 关键字驱动脚本
脚本使用采用说明性与描述性的方法。描述的被测软件知识建立在自动化测试环境中，知识是在脚本当中。

关键字驱动脚本的数量不随测试用例数量变化，仅随软件规模而变动
 线性脚本（简单录制/回放）线性脚本是录制手工执行的测试用例得到。
需要很明确该系统的测试机制（原理）是什么，这将决定了要运用什么样的测试脚本的类型。
4. 测试脚本的自动生成
4，自动化测试工具（平台）及应用
1. 自动化测试工具（平台
自动化测试工具或平台的体现的功能和作用，这里归纳如下：
1）自动化测试工具作用和功效
支持软件的关键元素
能记录业务的流程并生成脚本程序
对各种网络设备（客户/服务器）模仿能力，用有限资源生成高质量虚拟 用户
对整个软、硬件系统中各部分具有监控的能力，对测试结果表现和分析。

2) 自动化测试工具功能类型
 支持不同测试环境的测试平台或是测试模拟器。
 提供软件（程序）变更分析和软件风险及复杂度评价的静态分析器和比较器。
 测试执行和回归的测试驱动及捕获/回放工具。
 度量和报告测试结果及覆盖率动态分析工具。
 帮助开发和测试人员了解重要的软件系统信息。
 确定系统最优硬件配置，提供最好的系统性能。
 检查系统的可靠性。系统在负载（压力）下可靠运行时间及系统性能如 何变化。检查系统硬、软件升级对系统性能的影响。
 评估新产品的最佳运行环境与条件。
 能否正确选择工具关系到测试的效率、成本及测试的成败。
2）自动化测试工具的分类
 自动化测试工具也可根据其来源的不同，分为开源工具和非开源工具 （一般为商品化工具）。
 从自动化测试工具能够完成的测试工作或任务来说，有单一功能的特性 工具、多功能综合特性的工具等
 根据测试方法不同，测试工具又分白盒测试工具和黑盒测试工具。
 根据测试对象不同，测试工具分为Web测试工具、数据库测试工具、
移动测试测试工具、嵌入式测试工具和测试管理工具等等。
2. 自动化测试工具简介
1） 白盒测试工具
白盒测试工具通常用于作接口测试、覆盖率分析、复杂度计算、内存分析等。
 可作代码审查
 进行一致性检查
 白盒测试工具能实现
① 作程序的错误检查
② 作接口分析。
③ 输入输出规格说明分析检查
④ 作数据流分析
⑤ 作类型分析，
⑥ 作单元分析，检查单元或者构成实体的物理元件是否定义正确和使 用一致
⑦ 作程序复杂度的分析，并精确规划测试用例的设计。
商用白盒测试工具：如 IBM LogiScope、IBM Rational PurifyPlus、Klocwork、Parasoft C/C++等等, 以及开源测试工具。
2）黑盒测试工具
其主要的功能和作用：
 功能测试工具
作软件或程序的预定功能的确认。用于检测程序能否达
到预期功能要求，并能正常地运行。
 非功能测试工具
。主要是以软件的性能测试、安全性测试、质量度量测
试内容为主的工具。如性能测试，主要是查找影响软件或程序性能的瓶颈
 业界主流的黑盒测试工具
3) 用于测试管理的工具
IBM Rational 系列 DOORS，Rational Team Concert（RTC