测试工程师学习笔记

测试的基本理论

• 掌握软件测试的基本流程

• 知道软件测试的V和W模型的优缺点

• 掌握软件测试的分类

软件测试的发展

1960年代是调试时期（测试即调试）

1960年 - 1978年 论证时期（软件测试是验证软件是正确的）和 1979年 - 1982年 破坏性测试时期（为了发现错误而执行程序的过程）

1983年起，软件测试已有了行业标准(IEEE829)，它需要运用专门的方法和手段，需要专门人才和专家来承担。

1990年起软件迅速发展，测试行业也更着发生了巨大变化，开始引入专业测试工具

什么是软件测试

在规定条件下对程序进行操作,从而发现错误,对软件质量进行评估的一个过程.

软件测试的目的

是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。

注意:不要和软件测试的定义混淆

软件测试的定义

使用人工或自动手段来运行或测试摸个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果和实际结果之间的差别.

 软件开发模型

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

软件开发过程模型是软件开发人员在公司里工作的过程.

常见的软件开发过程模型

• 瀑布模型
• 快速原型模型
• 增量模型
• 螺旋模型

瀑布模型

 1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型将软件生命周期划分为制定计划、需求分析、系统设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落

核心思想

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

地位

瀑布模型是最早出现的软件开发模型, 在软件工程中占有重要的地位,它提供了软件开发的基本框架.

优缺点

优点

为项目提供了按阶段划分的检查点,软件开发的每个阶段都很清晰明了
 2. 当前阶段完成后,只要去关注后续阶段
 3. 可在迭代模型中每轮迭代很类似于一个小的瀑布模型
 4. 它提供了一个模版,这个模版使得分析、设计、编码、测试可以在改模版下有一个共同的指导

 缺点

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险
3. 突出缺点是不适应用户需求的变化
4. 软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心

 使用范围

• 用户的需求非常清楚全面，且在开发过程中没有或很少变化；
• 开发工作对用户参与的要求很低。

快速原型模型

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

核心思想

快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。

优缺点

优点:

克服瀑布模型的缺点,适应需求的变化,能够开发出更加让用户更加满意的需求

缺点:

• 所选用的开发技术和工具不一定符合主流的发展；
• 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
• 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

使用范围

1. 不适合大型项目的研发

2. 对所开发的领域比较熟悉而且有快速的原型开发工具

增量模型

介绍

增量模型又称为渐增模型，是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

基本思想

增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

优缺点

优点

• 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
• 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
• 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

缺点

• 要求待开发的软件能给进行增量式的开发,否则会很麻烦
• 在软件开发过程中需求变化是不可避免的,增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性.

使用场景*

• 进行已有产品升级或新版本开发

螺旋模型

 1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型]”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

如图所示，螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： 　　

（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 　　

（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险； 　　

（3） 实施工程：实施软件开发和验证； 　　

(4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

 优缺点

优点:

• 设计灵活可以在项目各个阶段进行变更
• 风险驱动,每个项目上线前都要进行风险分析

缺点:

• 螺旋模型强调风险分析,需要相当丰富的风险评估经验和专门知识,在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；
• 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，

使用场景

• 适合使用大规模的软件项目

测试模型

概述

软件测试和软件开发一样,都遵循软件工程原理,遵循管理学原理,所以理解好软件的开发模型会便于理解测试模型.

软件测试的一般流程:

我们发现一般的软件测试流程和软件开发的流程一样,但是这样的流程测试介入的较晚,对于前期重大的bug很难修复.所以测试的流程进行总结,总结出以下几个常用的测试模型:

• V模型
• W(双V)模型
• H模型

V模型

介绍

V模型和瀑布模型有一些共同的特性，V模型中的过程从左到右，描述了基本的开发 过程和测试行为。

单元测试：是模块测试，验证软件的基本组成单位的正确性，是白盒测试

集成测试：是模块间的测试，测试接口（软件各模块之间的接口和软件与硬件之间的接口）是否正确，是灰盒测试（白盒和黑盒结合)

系统测试：系统测试包括：冒烟测试 系统测试 回归测试

• 冒烟测试：主干流程测试，确认软件的基本功能正常，可以进行后续的测试工作
• 系统测试：是检测系统的功能、质量、性能能否满足系统的要求，包括功能、性能、界面、可靠性、兼容性等等，是黑盒测试
• 回归测试：修改了旧代码之后重新进行测试，确认修改后的代码没有引入新的错误或导致其他代码产生新的错误

验收测试：是确保软件的实现能否满足用户的需求或合同的要求

优缺点

优点:

• 每一个阶段都清晰明了、便于控制开发的每一个过程
• 既包含单元测试又饱含系统测试

缺点:

• 测试介入的较晚,对于前期的一些缺陷无从发现和修改
• 测试和开发串行

W模型

介绍

V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试” 的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W 模型（如下图）。在模型中不难看出，开发是“V”，测试是与此并行的“V”。

W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

优缺点

优点

• 测试伴随软件的整个生命周期,例如,在需求分析结束后就可以进行需求分析测试、
• 测试于开发是并行独立进行

缺点

• 对需求和测试技术要求高
• 适用于大中型企业

H模型

简介

H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。

优缺点

优点:

• 开发的H模型揭示了软件测试除测试执行外，还有很多工作；

• 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；

• 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；

缺点:

• 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；

• 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

• 测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；

小结

在实际工作中应灵活的运用各种模型的优点.

V模型: 强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试

W模型: 补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明

H模型: 强调测试是独立的，只要测试准备完成，就可以执行测试

软件测试分类

从上图我们发现软件测试根据不同的分类条件会有不同的结果.

按照阶段进行划分

1.1 单元测试(Unit Testing)

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。

• 测试阶段：编码后
• 测试对象：最小模块
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：代码和注释+详细设计文档
• 测试方法：白盒测试
• 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

1.2 集成测试(Integration Testing)

集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。

• 测试阶段：一般单元测试之后进行
• 测试对象：模块间的接口
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：单元测试的模块+概要设计文档
• 测试方法：黑盒测试与白盒测试相结合
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

补充说明： 单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个）

1.3 系统测试(System Testing)

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试

• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）
• 测试人员：黑盒测试工程师
• 测试依据：需求规格说明文档
• 测试方法：黑盒测试
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

补充说明： （1）系统测试是从完整的角度，广面去看待问题，不再看模块 （2）虽然系统测试包括冒烟测试和回归测试，但三者之间是有严格的先后顺序的，即：先冒烟、再系统、后回归

按是否覆盖源码划分

2.1 黑盒测试(Black-box Testing)

黑盒测试也称功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据。黑盒测试又分为功能测试和性能测试

• 功能测试

  • 业务测试是指：测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程
  • 易用性（Useability）是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。
  • 界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
  • 安装测试:是指测试程序的安装、卸载。最典型的就是APP的安装、卸载。
  • 兼容性测试:主要是指软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。例如最常见的是浏览器的兼容性测试,不同浏览器在css、js解析的不同会造成页面的不同.

• 性能测试

  检查系统是否满足需求规格说明书中规定的性能。 通常表现在以下几个方面：

  • 对资源利用（如内存、处理机周期等）进行的精确度量
  • 对执行间隔
  • 日志事件（如中断，报错）
  • 响应时间
  • 吞吐量（TPS）
  • 辅助存储区（例如缓冲区、工作区的大小等）
  • 处理精度等进行的监测

2.2 白盒测试(White-box Testing)

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒指的打开盒子，去研究里面的源代码和程序结果。

白盒测试也是接口测试的一种

2.3 灰盒测试(Gray-Box Testing)

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

灰盒测试:功能 + 接口

按是否执行程序划分

3.1 静态测试(Static testing)

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。阿旺分析如下

• 检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。
• 静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。

静态测试:代码静态分析和文档测试都属于静态测试

3.2 动态测试(Dynamic testing)

动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。

(1）动态测试有三部分组成：构造测试用例、执行程序、分析程序的输出结果。 (2）大多数软件测试都属于动态测试。

按是否自动化分

4.1 手工测试(Manual testing)

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。阿旺总结优缺点：

• 优点：自动化无法替代探索性测试、发散思维类无既定结果的测试。
• 缺点：执行效率慢，量大易错。

4.2 自动化测试(Automation Testing)

就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

• 自动化测试有：测试自动化、性能测试自动化、安全测试自动化。（一般情况下，我们说的自动化是指功能测试的自动化）
• 自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。

自动化实施的步骤:

(1) 完成功能测试，版本基本稳定

(2) 根据项目特性，选择适合项目的自动化工具，并搭建环境

(3) 提取手工测试的测试用例转换为自动化测试的用例

(4) 通过工具、代码实现自动化的构造输入、自动检测输出结果是否符合预期

(5) 生成自动测试报告

(6) 持续改进、脚本优化

其他

5.1 冒烟测试(Smoke Testing)

该术语来自硬件，指对一个硬件或一组硬件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试，也可以理解为该种测试耗时短，仅用一袋烟的功夫就足够了。

冒烟测试的目的是确认软件基本功能正常，可以进行后续正式的测试工作。冒烟测试的执行者是版本编译人。 冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续测试。

5.2 回归测试

回归测试是指修改了旧的代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅度降低系统测试、维护升级等阶段的成本.

在整个软件测试过程中占有很大的工作比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

5.3 随机测试

随机测试主要是根据测试者的经验对软件进行功能和性能抽查。

根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。

5.4 验收测试

验收测试是部署软件之前的最后一个测试操作, 也称为交付测试.验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。

• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）。
• 测试人员：主要是最终用户或者需求方。
• 测试依据：用户需求、验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试(功能...各类文档等)

验收测试按照实施的组织不同分为:α测试和β测试

α测试

• α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

• α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

• 大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。

β测试

• Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。

α测试与β测试的区别：

• 测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
• Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
• alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。

基本原则及流程

既然软件测试的目的是寻找软件的错误和缺陷,从而来评估和提高软件质量, 那么软件进行测试时必须要遵一定的原则:

1. 一切测试要追溯到用户的需求

正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。

2. 应该把“尽早测试和不断测试”作为测试人员的座右铭

我们应该在需求模型完成后立马就开始制定测试的计划,详细的测试用例定义也可以在需求的模型确定后立即开始进行.因此测试应该在代码没有产生前就要进行计划和设计.

3. pareto原则(二八原则):80%的错误,发生在20%的模块中

当某个功能出现问题时,评估其对用户的影响有多大,然后根据大小确定测试的优先级别.优先级高的,优先进行测试.

一般来讲针对用户最常用的20%功能(优先级别最高)的测试会得到完全执行, 而低优先级的测试(另外用户不常用的80%功能)就不是必要的,如果时间或经费不够,就暂时不做或者少做.

4. 穷举测试是不可能的

测试无法显示软件潜在的缺陷,测试只能证明全疆存在错误或缺陷,不能证明软件没错误.因为一个大小适度的程序,其路径排列的数量也非常大,因此不可能在测试中运行每一条路径的组合.然而,充分覆盖程序逻辑,并确保程序所有使用的条件是有可能的.

5. 第三方测试会更客观

程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。 要做出“经得起考验和测试的产品”。

6. 测试用例是设计出来的, 不是写出来的

测试用例是要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。 要知道好的测试用例真的会有效且事半功倍。

7. 不可将测试用例置之度外，排除随意性

特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。 其它所有工作都应该避免随意性。

8. 测试贯穿于整个生命周期

由于软件的复杂性和抽象性，在软件生命周期的各个阶段都可能产生错误，测试的准备和设计必须在编码之前就开始，同时为了保证最终的质量，必须在开发过程的每个阶段都保证其过程产品的质量。因此不应当把软件测试仅仅看作是软件开发完成后的一个独立阶段的工作，应当将测试贯穿于整个生命周期始末。 　　软件项目一启动，软件测试就应该介入，而不是等到软件开发完成。在项目启动后，测试人员在每个阶段都应该参与相应的活动。或者说每个开发阶段，测试都应该对本阶段的输出进行检查和验证。比如在需求阶段，测试人员需要参与需求文档的评审

9. 对发现错误较多的程序段，应进行更深入的测试。

一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。越需要深入和多次测试

10. 要妥善的保存一切文档,便于后期进行复用

基本流程

需求分析阶段：

• 阅读需求、理解需求，分析需求点，参与需求评审会议。

测试计划阶段：

• 主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，
• 内容包括测试范围，进度安排，人力物力分配，整体测试策略的制定,风险评估与规避措施，
• 参与测试计划的评审工作。

测试设计阶段：

• 编写测试用例，参考需求分析、概要设计、详细设计，不明确的与开发、产品经理沟通。
• 用例完成后进行评审

测试执行阶段：

• 搭建环境准备数据，执行冒烟测试（预测试）然后进入正式测试（系统测试、回归测试、交叉测试、自由测试），遇到问题提交bug到缺陷管理平台，并对bug进行跟踪，直到被测试软件达到测试需求要求，没重大bug，测试结束。

评估阶段：

• 出测试报告，对整个测试的过程和版本质量做一个详细的评估。

测试用例

测试用例

1. 测试用例定义

测试用例又叫做test case，是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

2. 编写测试用例的原因

2.1 理清思路，避免遗漏

如果测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。

2.2 跟踪测试进展

通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。

2.3 历史参考

​ 在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。

2.4 规范作用

​ 我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。

3. 测试用例的要素

3.1. 测试用例八大要素

测试用例编号	测试项目(测试模块)	预置(前提)条件	测试输入	预期输出	操作步骤	测试用例标题	级别
ST-子项名-01	手机登录	手机正常使用	手机号	正常登录	输入手机号并确认	测试能否手机登录成功	重要

1). 测试用例编号

编号由字符和数字组合成的字符串,用例编号具有唯一性、容易识别, 如下表

测试项目

测试的项目属于哪个项目或者被测试的需求、被测的模块、被测的单元等等

3). 预置条件

执行当前测试用例需要的前提条件,如果前提条件不满足,则后面的测试步骤不能进行或者得不到预期结果

4). 测试输入

测试用例执行过程中需要加工的外部信息.根据测试用例的具体条件有手工输入、数据库等

5). 预期输出

测试用例的预期输出结果,包括返回值内容、界面响应结果等.

6). 操作步骤

执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行

7). 测试用例标题

对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。

8). 级别

对于测试用例的重要程度的区分.包含如下几种:

• 高级别

保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例

• 中级别

重要程度介于高和低之间的测试用例

• 低级别

实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例

3. 2. 其他要素

1. 用例的设计者:能准确找到测试用例的设计人员,对用例修改时能方便找到人员
2. 用例设计日期: 方便检查用例的设计进度
3. 对应的开发人员: 出现bug后能及时找到相应的人员进行修复
4. 测试结果: 执行用例最后执行的结果, 包括:pass、fail、block
5. 测试类型: 功能、性能、压力等等

4. 小结

测试用例要素是为了便于我们快速的设计测试用例,因此要掌握最常用的八大要素,但是每家公司的具体要求不一样,要根据公司要求灵活添加测试的元素.

测试用例设计方法—等价类划分法

掌握常用测试用例设计方法,再结合测试用例的要素能给快速的实现测试用例的设计和编写.但是由于软件系统大小的不同我们不可能把所有的单个或组合的情况都进行测试,所以我们测试时应该根据不同的场景设计不同的测试用例,尽可能的覆盖到全部需要测试的情况.

常用的测试用例设计方法有: 等价类划分话、边界值分析法、判定表法、正交验证法、错误推测法、场景法、因果图法.

等价类划分法

1. 等价类划分的介绍和概念定义

• 划分

指互不相交的一组子集，这些子集的并是整个集合。

对测试的意义：完备性和无冗余性。

• 等价类

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，具有等价特性。

• 等价类合理地假设

测试某等价类的代表值就等于对这一类其它值的测试。

• 等价类划分

在测试中最完美的测试是使用穷举测试,把所有的数据都测一遍.但是实际工作中不能采用,因为效率太低了.

理想的测试时:使用最少的测试数据,达到最好的测试质量.

等价类划分法的测试思想是:

从大量数据里划分范围（每个范围内的数据测试效果是等价的所以每个范围是一个等价类），然后从每个范围中挑选代表数据，这些代表数据能反应这个范围内数据的测试结果。

官方定义:

等价类测试方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。

1.1. 类型划分

等价类的类型划分分为:有效等价类和无效等价类.

(1). 有效等价类

有效等价类是指对对于程序的规格说明来说是合理的、有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

(2). 无效等价类

无效等价类指对程序的规格说明是不合理的、无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。利用无效等价类可校验程序对于无效数据的处理能力,检测程序的健壮性、容错能力

注意:

设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

2. 设计测试用例

步骤:

• 确定需求
• 确定有效等价类和无效等价类
• 对每条等价类设计测试用例

3. 案例

要求:使用等价类划分法测试QQ账号的合法符合规范

明确需求	输入6-10位的自然数
有效等价类	有效等价类	自然数个数大于6小于10个
无效等价类	无效等价类	小于6个、大于10个、中文、空格、英文、特殊字符、小数
设计测试用例	有效等价类测试用例	无效等价类测试用例

测试用例

用例编号	等价类划分	输入	预期结果	测试结果	重要级别
UT-QQ账号-01	有效等价类	12345678	正确	正确	高级
UT-QQ账号-02	无效等价爱类	12	错误	error	高级
….	…..	….	….	….	….

4. 小结

4.1 . 应用场景

• 有输入的地方,可以从大量数据中挑选少量的代表数据进行测试,使用等价类划分法

4.2 . 测试用例的设计

根据等价类划分设计的测试用例,及保证了程序的功能或需求的实现,也一定程度上保证了功能的健壮性的实现, 所以在实际使用中比较多.

边界值测试法

1. 介绍

边界值分析法就是对输入或输出边界值进行测试的,也是一种黑盒测试.

边界值分析法通常作为等价类划分法的补充,其测试用例来自等价类的边界;长期的经验得知,大量的错误是发现在输入或输出范围的边界上，而不是发生再输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多错误.

和等价类划分法的区别:

• 是等价类划分法的补充
• 等价类划分法可以挑选等价范围内任意一个数据作为代表,边界值分析法要求每个边界值都要作为测试条件
• 边界值分析法不仅考虑输入条件,同样考虑输出产生的测试情况

常见的边界值:

• 边界点(上点):输入范围的边界点
• 离点: 离边界点最近的点
• 内点: 输入范围内的任意一个点

对于边界值的说明:

边界值数据本质上属于等价类的范畴,测试时确实是一种冗余（重复），但是为了更好的测试质量（边界值特别容易出bug），边界值必须要单独测,适当必要的冗余是可以接受的.

举例: 0-100内的整数

上点	0, 100
离点	1, 99; -1,101; 1,101; 0, 99;
内点	34

2. 使用边界值设计测试用用例

2.1 步骤:

• 明确需求
• 确定有效和无效等价类
• 明确输入条件中的边界值
• 编写测试用例

注意: 边界值法应用时，如果测试时间紧张，应该优先测试最大值和最小值

2.2 案例

要求:测试qq账号是否符合规范

1. 需求: qq号是6-10位的整数
2. 确定边界值

上点	6个, 10个
离点	5个, 9个, 7个,11个
内点	8个

1. 编写测试用例

用例编号	等价类划分	输入	预期结果	实际结果
UT-QQ是否符合规范-01	有效等价类	6个	正确
UT-QQ是否符合规范-02	有效等价类	10个	正确
UT-QQ是否符合规范-03	无效等价类	5个	错误
UT-QQ是否符合规范-04	有效等价类	7个	正确
UT-QQ是否符合规范-05	无效等价类	11个	错误
UT-QQ是否符合规范-06	有效等价类	9个	正确
UT-QQ是否符合规范-07	有效等价类	8个	正确
UT-QQ是否符合规范-08	无效等价类	特殊符号,例如: #,¥ *、空格等	错误
UT-QQ是否符合规范-09	无效等价类	数字+特殊符号	错误

3. 小结

边界值分析法作为等价类划分法的补充,经常和等价类划分一起使用.

使用的场景是:有输入并且存在边界值的位置.

判定表法

1. 使用场景

适合于有多个输入和多个输出,输入和输出之间有相互的组合关系, 输入输出之间有相互的制约和依赖关系

2. 定义

判定表也称决策表, 是分析和表达多逻辑条件下执行不同操作的工具.

它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表适合于处理这类问题。

3. 组成

判定表是由条件桩、动作桩、条件项、动作项四部分组成,如下图.

条件桩	条件项
动作桩	动作项

1） 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2） 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3） 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

4） 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

4.规则及规则合并

4.1 规则

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

在判定表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。

4.2 化简

规则合并有两条或多条规则具有相同动作,并且其条件项之间存在着极为相似的关系。

5. 测试案例设计

步骤:

1. 明确规则个数
2. 列出所有条件桩和动作桩
3. 填入条件项
4. 填入动作项,等到初始判定表
5. 简化,合并相似规则

6. 案例

1. 案例1

问题要求:对于功率大于50马力的机器、维修记录不全或运行10年以上的机器,应优先维修.

测试案例设计思想

1.1 . 明确规则个数

这里有三个条件:大于50马力、维修记录不全、运行10年以上, 每个条件有2种取值,所以有八种规则.

1.2. 列出条件桩和动作桩

条件桩	功率大于50马力?
	维修记录不全?
	运行超过10年?
动作桩	优先处理

1.3. 填入条件项

1.4. 填入动作项等到初始判定表

条件桩	条件项	1	2	3	4	5	6	7	8
	功率大于50马力?	Y	Y	Y	Y	N	N	N	N
	维修记录不全?	Y	Y	N	N	Y	Y	N	N
	运行10年以上?	Y	N	Y	N	Y	N	Y	N
动作桩	优先处理?	X	X	X		X		X
	其他处理				X		X		X

1.5 . 简化判定表

通过初始的判定表我们发现:

1. 在三个条件中有2个不满足时,剩下的一个完全没有参考价值,可以进行简化.

   只有功率大于50马力、维修记录全的、运行十年以上的才优先处理;

   其他处理的情况是:满足动力大于50马力、维修功能完全、没有运行10年以上中只要满足两项

2. 简化后为

条件桩	条件项	1	2	3	4	5
	功率大于50马力?	Y	Y	N	N	Y
	维修记录不全?	Y	N	-	-	N
	运行10年以上?	-	Y	Y	N	N
动作桩	优先处理?	X	X	X
	其他处理				X	X

注意: “-”表示取值与否不影响触发的动作.即,不影响规则

2. 案例2.

公交一卡通自动充值系统要求:

• 系统只接收50或100元纸币，一次只能使用一张纸币，一次充值金额只能为50元或100元。
• 若输入50元纸币，并选择充值50元，完成充值后退卡，提示充值成功；
• 若输入50元纸币，并选择充值100元，提示错误，并退回50元；
• 若输入100元纸币，并选择充值50元，完成充值后退卡，提示充值成功，找零50元；
• 若输入100元纸币，并选择充值100元，完成充值后退卡，提示充值成功；
• 若输入纸币后在规定时间内不选择充值按钮，找零，并提示错误；
• 若选择充值按钮后不输入货币,提示错误

测试案例实现如下

2.1 明确规则个数

规则个数(条件桩)	输入50元
	输入100元
	充值50元
	充值100元

2.2. 列出条件桩和动作桩

动作桩	提示充值成功
	充值成功并退卡
	退卡
	找零

2.3. 列入条件项

2.4. 填入动作项,等待初始的判定表

输入条件		1	2	3	4	5	6	7	8
	输入50元	Y	Y			X
	输入100元			Y	Y		X
	充值50元	Y		Y				X
	充值100元		Y		Y				X
动作桩	充值成功并退卡	X		X	X
	提示充值成功	X		X	X
	找零		X	X		X	X
	提示错误		X			X	X	X	X

2.5 简化

这个案例中每个条件都是独立的,没有可以简化的

2.6.测试用例设计

上面的表中每一条就是一个测试用例.

7. 小结

优缺点

优点

• 能把复杂问题按照各种可能情况—列举出俩, 简明而易于理解,避免遗漏

缺点

• 不能表达重复执行的动作、例如循环结构

因果图法

1. 概述

因果图法是一种利用图解法分析输入条件、输出结果的各种组合情况,从而设计测试用例的方法.

因果图法适用于有多个输入和多个输出，而且输入和输入之间有相互的组合关系，输入和输出之间有相互的制约和依赖关系.

使用场景和判定表法是一样的.

在界面中有多个控件，控件之间有组合或限制关系，不同的输入组合会对应不同的输出结果，如果想弄清楚不同的输入组合到底对应哪些输出结果，可以使用因果图/判定表法。(因果图/判定表法比较适合测试组合数量较少的情况，一般少于20种)

和判定表法的不同:

• 因果图，只是一个用图形表示，表示因果方式不同而已

关联:

• 判定表和因果图是等价的，判定表是因果图的简化版。

2.核心

2.1 因果图

原因(因): 输入条件

结果(果): 输出结果

因果图: 就是通过画图的方式来表示输入条件（因）和输出结果（果）之间的关系。

2.2 因果图中的图形符号

(1). 恒等(=)

含义: 原因出现结果出现,原型不出现,结果不出现. 例如:若c=10,则d=0.

(2). 非 (~)

含义: 若原因出现,则结果不出现;原因不出现则结果出现.例如: 搜索联系人,若有就不提示错误.

(3). 或 (v)

含义: 若几个原因中有一个出现,这结果出现;若都不出现,结果不出现.

(4). 与(^)

含义: 若几个原因都出现结果才出现,否则,结果不出现.

2.3 约束

输入状态相互之间还可能存在某些互相依赖的关系,称为约束. 输出状态之间也存在某些约束.在因果图中使用特定符号表示这些约束.

(1). 输入条件约束

• E(exclude) 约束: a和b中至多有一个为1.
• I(include) 包含: a、b和c中至少有一个必须是1.
• R(required) 要求: a是1时，b必须是1.
• O(only) 唯一: a和b必须有一个，且仅有1个为1.

(2). 输出条件约束

• M(mandatory) 强制: 若结果a是1,结果b强制为0.

3. 设计测试用例

步骤

1. 了解需求,找出所有的输入条件(因)
2. 找出所有的输出结果(果)
3. 画因果图、填判定表
4. 判定表中每个规则就是一条测试用例

4.案例

问题描述: 如想对文件进行修改,输入的第一列字符必须是a或b,第二列字符必须是一个数字,如果第一列字符不正确则给出信息L,如果第二个字符不正确,则给出字符M

4.1 了解需求,找出输入条件

1— — 第一列字符是a

2 — — 第一列值符为b、

3 — — 第二列必须是数字

4.2 找出所有的输出结果

结果:

4— 信给出息l

5— 信息m

6— 修改文件

4.3 画因果图、填判定表

通过分析得出,原因1和原因2不可能同时出现,添加约束E. 设置9为中间点.

因果图如下:

判定表法

条件(原因)		1	2	3	4	5	6	7	8
	1	Y	Y	N	N	N	N	Y	Y
	2	N	N	Y	Y	N	N	Y	Y
	3	Y	N	Y	N	Y	N	Y	N
中间值	9	Y	Y	Y	Y	N	N
动作(结果)	4					Y	Y
	5		Y		Y
	6	Y		Y			Y

注意: 第7列和第8列不可能出现,所以排除这两种情况.

4.4 根据判定表设计测试用例

5.小结

因果图法是通向判定表法的一个中间过程.我们经常会将因果图法和判定表分析法结合起来使用.

对于业务逻辑比较复杂的我们建议先使用因果图法进行分析,然后再转化为判定表法,最后写测试用例.这样思路比较清晰,

对于简单的可以直接使用判定表法直接分析,然后写测试用例.

 正交法

正交测试工具

链接：https://pan.baidu.com/s/19qzN3r6jwuvz-8ArzGbwVw?pwd=49am 
提取码：49am 

通过分析我们发现,对于图中的程序而言,我们要设计81条测试用例,那么有没有一种方法能够使用最小的测试过程集合获得最大的测试覆盖率呢?

1. 概述

1.1 定义

正交法,也叫正交实验法或者正交排列法, 就是使用最小的测试过程集合获得最大的测试覆盖率。

“正交实验”是研究多因素、多水平的一种实验方法,它利用正交表来对实验进行设计,通过少数实验代替全面的实验.

在一项实验中,把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。

1992年AT&T公司,针对某一个软件做了一个回归测试：

在18个周（4个半月）的时间范围内测试1500条测试用例。后来开发时间推迟了，测试时间被压缩了。测试经理想了一个办法，两个人在8个周（2个月）测试1000条测试用例。但是测试经理不能保证该软件就是完全没有问题的。后来他决定用正交表去重新设计一下测试用例，422条测试用例，42个bug。测试完毕后，软件上线了。在上线的两年时间内。凡事被测试到的领域，都没有发现任何问题。后来呢，他从头到尾有总结了一番：有可能只会测试出32条bug。

前后对比：

• 测试用例的条数少了

• 测试出来bug的数量多了

1.2 正交表的构成

˙正交表时一种特制的表, 一般记为$$Ln(m^k)$$

• n是表的行数,也就是需要测试组合的次数
• k是表的行数, 表示控件个数(因素的个数,或因子的个数)
• m是每个控件包含的取值个数(各因素的水平数,即各因素的状态数)

例如: $$L9(3^4)$$ 正交表如下

2. 使用正交法设计测试用例

2.1 步骤

1. 根据需求把空间即其取值列举出来
2. 根据空间和空间的取值个数,选择一个合适的正交表
   • 根据控件的个数,选择正交表的次幂,也就是正交表中包含的最大值, 例如,4个控件,选择4次幂
   • 根据控件取值个数,选择正交表的底,也就是正交表包含的最大值, 例如, 每个控件有3个取值,底是3
3. 把控件及其取值映射到正交表中
   • 把控件名字分别映射到正交表的列名位置
   • 把正交表中每一列的数字分别用对应的控件取值替代
4. 根据正交表,编写测试用例

2.2 案例

实现“字符属性设置”的测试用例编写

(1). 列举因子表

字体	字符样式	字体颜色	字号
仿宋	粗体	红色	20号
楷体	斜体	绿色	30号
华文彩云	下划线	蓝色	40号

(2) 确定使用的正交表

确定采用的正交表
$$L9(3^4)$$

(3). 把控件及其取值映射到正交表中

(4). 编写测试用例

上图正交表每一行都是一条测试用例,, 此处仅列出2条

用例编号	输入	预期结果	实际结果	是否是bug
UT-设置字符子项测-01	字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:20	仿宋、 粗体、 红色、20号
UT-设置字符子项测-02	字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:30	仿宋、 粗体、 红色、20号

3. 小结

3.1 使用场景

• 需求中条件的组合量比较大的时候
• 需求两个两个相互组合的时候

3.2 局限性

正交表的个数有限,一般要求每个控件的取值相等,但是这在实际中很难应用,所以在实际使用时要进行取舍

• 对于控件个数,如果没有,就选择一个接近的
• 对于控制的取值,应该少数服从多数, 有更多空间的取值一样

场景法

1. 概述

1.1 为什么使用场景法设计测试用例

大多数业务软件由后台管理（比如：用户管理、角色管理、权限管理等等各种管理）和工作流等几个部分组成。终端用户，期望软件能够实现业务需求，而不是简单的功能的组合。对于单点功能利用等价类、边界值、判定表用例设计方法能够解决大部分问题。涉及业务流程的软件系统，采用场景法比较合适。

总之, 对于多个功能组合测试的场景适合使用场景法, 所以场景测试,也是业务场景组合测试.

1.2 概念

场景业务流通常分为: 基本流、备选流、异常流程

(1) 基本流

基本流表示通过业务流程时输入都正确，能达到目标的流程

(2) 备选流

备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到能达到目标的流程.（插卡-->输入错误密码--》输入正确密码--》输入金额--》取款--》取卡）

(3) 异常流

异常流表示通过业务流程时输入错误（或者操作错误）产生异常终止流程

2. 使用场景法设计测试用例

1. 步骤

1. 分析需求,确定基本流程、备选流程、异常流程
2. 绘制流程图,确定流程路径, 根据流程图生成不同的场景
3. 每一个场景就是一条测试用例

2. 案例

2.1 需求描述

用户网上购买商品, 整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。

2.2 测试用例实现

(1). 分蓄需求,确定业务流程(基本流程、备选流程、异常流程)

基本流程	用户登录到网站，书籍的选择，进行订购，把所需图书放进购物车，等进行结帐的时候，登录自己的帐号，登录成功后，生成订单.
备选流程1	账号不存在
备选流程2	账号错误
备选流程3	密码错误
备选流程4	没有选购书籍
备选流程5	退出系统

(2). 绘制流程图,确定流程路径, 根据流程图生成不同的场景

场景1-购物成功	基本流程
场景2-账号不存在	基本流程	备选流程1
场景3-账号错误	基本流程	备选流程2
场景4-密码错误	基本流程	备选流程3
场景5-没有选购书籍	基本流程	备选流程4

(3). 编写测试用例, 对于每一个场景都需要确定测试用例。

测试用例编号	输入条件	账号	密码	是否选购书籍	预期结果
ST-系统测试子项-1	场景1	张三	admin@123	Y	购物成功
ST-系统测试子项-2	场景2	李四	N	N	提示账号不存在
ST-系统测试子项-3	场景3	赵六	admin	N	提示账号错误, 返回基本流程
ST-系统测试子项-4	场景4	张三	Admin123&……	N	提示密码错误,返回基本流程
ST-系统测试子项-5	场景5	张三	admin@123	N	提示没有选购书籍, 返回基本流程

3. 小结

场景流程比较适合于涉及到业务需求的场景, 能够多个功能联合进行测试,不是单个功能进行测试.

功能图法

1.1 简介

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

动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.

对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例.

功能图模型由状态迁移图和逻辑功能模型构成.

• 状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.
• 逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.

逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.

由于覆盖测试的目标不同,逻辑覆盖可分为:

• 语句覆盖
• 判定覆盖
• 判定-条件覆盖
• 条件组合覆盖
• 路径覆盖

1.2 组成

功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置（或时间）,而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.

例如下面的ATM功能图法测试

1.3 设计测试用例

(1). 生成测试用例的规则

从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例. 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题（如白盒测试）问题了.

为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.

在一个结构化的状态迁移（SST）中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.

(2). 步骤

• 生成局部测试用例: 在每个状态中,从因果图生成局部测试用例.局部测试用例由输入数据与对应的输出数据或状态构成。
• 测试路径生成:利用上面的规则（三种）生成从初始状态到最后状态的测试路径。
• 测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

错误推测法

1.1 定义

错误推测法是: 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

1.2 基本思想

根据经验,列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

1.3 使用场景

适用于项目时间比较短促,任务比较繁重的情况下

缺陷管理工具

禅道

1. 禅道介绍

1.1 禅道项目管理软件是做什么的？

禅道由青岛易软天创网络科技有限公司开发，国产开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款专业的研发项目管理软件，完整覆盖了研发项目管理的核心流程。禅道管理思想注重实效，功能完备丰富，操作简洁高效，界面美观大方，搜索功能强大，统计报表丰富多样，软件架构合理，扩展灵活，有完善的API可以调用。禅道，专注研发项目管理！

1.2为什么用禅道这个名字？

禅和道这两个字含义极其丰富，有宗教方面的含义，也有文化层面的含义。禅道项目管理软件取其文化含义，期望通过这两个字来传达我们对管理的理解和思考。这个名字是受《编程之道》和《编程之禅》这两本书的启发。英文里面的禅为Zen，道为Tao，所以我们软件的英文名字为zentao。

2. 禅道的安装

2.1、运行windows一键安装包

双击解压缩到某一个分区的根目录，比如**c:\xampp，或者d:\xampp**， 必须是根目录。​ 进入xampp文件夹，点击 start.exe启动禅道时，如果电脑没有安装过VC运行环境时，会提示安装VC++环境。

​ Windows一键安装包的运行需要安装VC++环境。

2.2、 修改数据库密码

​ 禅道服务启动后，会提示数据库密码太弱，建议修改密码。

​ 会默认显示一个密码，你也可以自己设置一个密码，点OK后数据库密码会自动修改。

​ 

 2.3 Apache、用户访问验证

禅道启动后，默认是开启了Apache用户访问验证。如果不想开启，可以直接不勾选即可。

2.4、 启动并访问禅道

启动控制面板之后，点击“启动禅道”按钮，系统会自动启动禅道所需要的apache和mysql服务。

启动成功之后，点击“访问禅道”，即可打开禅道环境的首页。等会之后，页面会自动跳转到禅道登录的页面, 默认的管理员账号:admin, 密码:123456, 登录后要修改密码,管理员的密码一定要记住。

3. 禅道的使用 

 3.1 修改密码强度检查

3.2 创建部门及角色用户

注意:是以超级管理员角色进行登录

 3.3 产品经理创建产品提出需求

注意:以产品经理角色登录进行操作

(1)、 建立产品

(2)、建立模块

(3)、建立计划

(4)、 提出需求

需求审核通过的状态是:激活;否则是草稿状态

(5)、需求评审及变更需求

1. 产品评审是针对未审核通过的需求进行,即需求的状态是“草稿”

注意:

• 如果选择“有待明确”，会保持需求的草稿状态，并将需求指派回需求的创建者头上，有其继续进行完善。
• 如果选择了“拒绝”，则需要给出相应的拒绝原因，拒绝原因可以有：

需求的变更及评审

凡事对需求标题、描述、验证标准、附件的修改都可以进行变更需求,变更之后的状态是变更中.

3.4 项目经理创建项目、关联需求

注意: 以项目经理角色登录操作

(1). 项目立项

项目立项是通过会议确认, 由项目经理提前准备,告诉团队开会的具体时间和地点, 项目经理事先对需求进行划分,将本期需要实现的需求关联到项目中,

产品经理对需求进行讲解,参会员工对需求提出自己意见,讲解完毕后,对工作量进行评估,并确定每一需求的优先级,然后根据需求的优先级和工作量的大小,将需求做相应的调整,将事先不需要的需求延后开发.

(2). 项目经理创建项目、关联需求

(3) 项目经理设置开发团队

项目创建成功后,会提示设置团队

或者,从项目视图中的团队菜单中也可以进行项目的团队管理

(4). 项目经理分解任务

关联、分解需求

需求:分解需求时要粒度越小越好

3.5 开发领取任务、进行提测

注意: 所有的操作都在开发人员各自账号登录下操作

(1). 开发领取任务、确认工时

注意:一般情况是开发的任务有项目经理指派,然后开发人员登录自己的账号就可以看到自己的任务,只要修改任务的状态从未开始到进行中,开发结束后状态时已完成.

(2). 开发创建版本

当所有的任务开发完成后,会在git上进行版本的集成,然后有专门人员进行提测,一般是leader操作

版本创建完成后就可以看到版本详情页面对应的需求或者bug

(3). 进行提测

3.6 测试人员开发测试用例、提交bug、回归测试

(1)、创建、执行测试用例

在测试用例详情页编写测试用例

(2)、执行测试用例

1. 评审测试用例

2. 关联版本

3. 执行测试用例

(3)、 提交bug

在测试视图下,bug选项进行提交bug

注意:

• 提交测试之后，测试人员展开测试，便会有bug产生。这时候研发团队的一个重要职责便是解决bug。

• 测试人员提交bug => 开发人员解决bug => 测试人员验证关闭，这是比较正常的流程。还有一个流程是激活流程：测试人员提交bug => 开发人员解决bug => 测试人员验证未通过 => 激活bug => 重新解决 =>验证关闭。

• 开发人员所需要做的事情便是处理自己负责bug，并在禅道中登记解决方案

(4)、回归测试

步骤:

1. 开发人员进入bug详情页面进行确认操作,然后线下修改代码进行bug修复,然后进行单元测试,没问题,就关闭bug
2. 关闭的bug不会出现在bug列表中,对于关闭的bug测试人员进行测试,测试加入还不通过,就重新打开bug,并指派给相关开发人员

已解决bug

对于已经解决的bug,验证过后就关闭,不会在出现bug列表中

总结

禅道是测试用的最多的缺陷管理工具,一定掌握测试人员使用部分,其他的相应角色要了解.

测试人员主要使用是:

​ 1. 编写测试用例、执行测试用例

​ 2. 对于测试未通过的,进行bug提交,指派给相应的开发者

​ 3. 开发者修复后的bug及时进行再次测试,测试通过就关闭,否则就再次激活