软件测试-基础知识

软件测试（一）

提示：该文章是为了记录本人软件测试的学习过程 软件测试开发技术视频教程

---

1. 绪论

1.1 软件及分类

软件测试

• 程序
• 数据
• 文档

软件分类

• 按层次划分
  • 系统软件
  • 应用软件
• 按组织划分
  • 商业软件
  • 开源软件
• 按结构划分
  • 单机软件
  • 分布式软件

1.2 软件缺陷的定义

笼统地来说：所有不满足需求或超出需求的都是缺陷，没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷。

专业来说：

1. 软件未实现产品说明书要求的功能
2. 软件出现了产品说明书指明不应该出现的功能
3. 软件实现了产品说明书未提到的功能（即作为隐形需求不应该实现的功能）
4. 软件未实现产品说明书虽未提及但应该实现的功能
5. 软件难以理解、不易使用、运行缓慢或者（从测试的角度来看）最终用户会认为不好

1.3 软件测试的由来

• 起源于上世纪70年代中期
  • 《测试数据选择的原理》
  • 《软件测试艺术》
• 20世纪80年代早期，软件行业开始逐渐关注软件产品的质量，并在公司建立软件质量保证部门QA(Quality Assurance)或SQA。

软件测试在国内起步较晚，大概在上世纪90年代到21世纪，软件测试大规模爆发是在2010左右。

1.4 软件测试的定义和目的

1.4.1 软件测试的定义

正向思维的定义

出发点：让自己确信产品是能够正常工作的，然后去评价一个程序和系统的特性或者能力，并确定它是否达到期望结果，软件测试就是以此为目的的任何行为。

反向思维的定义

• 提出：最早是在Glenford·J·Myers的《软件测试的艺术》中提出
• 出发点：测试是为了发现错误而执行一个程序或者系统的过程
• 测试是为了证明程序有错，而不是证明程序无错误（怀疑一切）
• 一个好的测试用例在于它能发现以前未发现的错误
• 一个成功的测试是发现了以前未发现的错误的测试

反向思维是目前主流的测试思想。

IEEE定义的软件测试

电气与电子工程师协会（Institute of Electrical and Electronics Engineers），简称IEEE。

• 在规定条件下运行系统或构件的过程：观察和记录结果，并对系统或构件的某些方面给出评价
• 分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性

IEEE定义的软件测试较为全面，不仅考虑到在测试环境下的情况，还考虑了在整个软件项目中的测试情况。

广义的软件测试定义

软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进而不仅仅是对程序的运行进行测试。

• 确认（Validation）
  通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现。
• 验证（Verification）
  通过检查和提供客观证据来证实指定的需求是否满足。

1.4.2 软件测试的目的

• 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。
• 同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误。
• 采用更加高效的测试管理手段，提高软件测试的效率和软件产品的质量。

1.4.3 软件测试和软件调试的区别

• 在主体，目标，方法和思路上有所不同。
• 测试是从已知条件开始，使用预先定义的过程，并且有预知的结果；调试是从未知的条件开始，结束的过程可能不可预计。
• 测试可以计划，可以预先指定测试用例和过程，工作进度可以度量；描述调试的过程或持续时间比较困难。
• 测试的对象包括软件开发过程中的文档，数据以及代码；调试的对象一般来说只是代码。

	测试	调试
主体	测试人员	开发人员
目标	找bug	将错误修改正确
方法	等价类、边界值	程序和逻辑算法
思路	反向思维占据主流	正向思维占据主流

2. 生命周期和模型

2.1 软件危机和软件工程

软件危机

是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重的问题。

基于软件危机对于计算机发展的阻碍,1968年，在联邦德国召开的国际会议上，北大西洋公约组织的计算机科学家讨论软件危机问题。提出了软件工程这个名词，从此软件生产进入了工程化时代。

软件工程包括两方面的内容

• 软件开发技术：软件开发方法学，软件工具和软件工程环境。
• 软件项目管理：软件质量（软件测试归属其中），项目估算，进度控制，人员组织，配置管理，项目计划。

引起软件危机的主要原因就是软件质量问题，软件工程主要就是解决的软件质量问题，软件测试是软件质量管理体系中一个非常重要的手段（重要性）。

2.2 软件生命周期

软件生命周期模型如下：

2.3 软件开发模型（重点）

2.3.1 瀑布模型

瀑布模型是最早提出的软件开发的模型。

存在的问题

• 强调时间顺序的严格执行，前阶段不完成，后阶段也无法开始，即缺乏灵活性。
• 将测试放在了编码之后，没有体现测试贯穿软件生命周期的原则，即测试人员在需求的时候就要参与进去（避免需求的问题一直延续到代码完成才得以暴露）。
• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
• 线性开发，用户等到整个过程的末期才能见到开发成果，从而增加了开发风险。
• 瀑布模型不适应用户需求的变化。

优点

• 为项目提供了按阶段划分的检查点。
• 当前一阶段完成后，只需要关注后续阶段。

2.3.2 快速原型模型

快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。

就目前来说，在企业中运用的越来越多，应用领域越来越广泛。

原型:就是一个模型，可以模拟操作，简单运行。

典型的应用和工具：Axure(制作原型)

大致工作流程：产品经理制作原型—>给客户讲解原型，客户觉得不行，产品经理改进原型，客户满意，原型交给开发人员依照原型开发产品。

2.3.3 增量模型

增量模型：把软件分割成若干独立的模块，分批次的完成和交付(跟迭代有相通之处)。

缺点：最明显的缺点就是如果打破原有的软件结构和框架，可能会带来一定的风险。

增量模型一般会和迭代模型一起使用。增量体现在软件更新的内容-增加了新的功能；迭代体现在软件更新的内容-优化了某些功能，修复了bug等。

2.3.4 迭代模型

• 迭代包括产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必须的所有其他元素，强调开发的深入。
• 在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析，设计，实施和测试工作流程。

迭代模型的优点

• 降低了在一个增量上的开支风险。
• 降低了产品无法按照既定进度进入市场的风险。
• 加快了整个开发工作的进度（发布一个原始版本抢占市场份额，之后再逐步的深入和优化）。
• 迭代过程这种模式使适应需求的变化会容易些。

迭代-每次都会将下面流程全部走一遍

2.3.5 螺旋模型

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。

特征

• 引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失。
• 螺旋模型更适合大型的昂贵的系统级的软件应用。

2.3.6 敏捷开发模型（敏捷开发—Scrum）

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

敏捷宣言，也叫做敏捷软件开发宣言，正式宣布了四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。

核心价值

敏捷开发流程

3. 测试过程模型和流程

3.1 软件测试流程

软件测试流程如下：

• 开发流程与测试流程在执行测试这里是唯一有交集的地方；
• 制定测试方案大多数时候会和编写测试计划合并在一起；
• 在没有软件的时候就要开发和设计测试用例，测试用例是指导测试的最直接的一项工作，也是判断软件在运行过程中有没有缺陷的一种重要的手段；
• 执行测试一定是在软件开发后进行;
• 当发现了缺陷后，测试人员要提交缺陷报告，开发人员要进行处理，这里会有专门处理缺陷的流程。

3.2 软件测试过程模型

软件测试的过程模型跟软件开发的过程模型，具有同等的效用；软件开发的过程模型指导软件项目研发，软件测试的过程模型用于指导软件测试的。

软件测试过程模型

• 如同软件开发过程一样，软件测试也有自己的过程模型。软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法。
• 测试过程的质量将直接影响到测试结果的准确性和有效性。软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。
• 一个标准的软件测试过程，应当包含不仅限包含以下测试活动
  • 需求分析、测试计划、测试设计、测试执行、测试总结…

3.2.1 V模型（重要）

V模型并不是我们测试工作中的一种科学有效的模型，V模型是早期的测试工作的指导模型。

由于其模型构图形似字母V，所以又称软件测试的V模型。

V模型的工作流程是线性的。

V模型揭示了开发过程与测试过程中各阶段的对应关系。

缺点

• V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证。
• 需求分析的满足情况一直到后期的验收测试才被验证。
• 没有提现出“尽早地和不断地进行软件测试”的原则。

总结来说就是，V模型没有体现测试贯穿软件生命周期的原则，测试介入的时间太晚，它是在编码后才进行测试，导致很多问题会在最后的环节才发现。
这种模型是不科学的，不足之处非常明显，然而现在许多公司仍在使用这种模型。
这种模型，软件测试不会提前做准备，而且没有体现迭代的思想。

3.2.2 W模型（重要）

相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。

W模型由两个V字形模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。

优点

• 测试活动与软件开发同步进行
• 测试的对象不仅仅是程序，还包括需求和设计
• 尽早发现软件缺陷可降低软件开发的成本

局限性

• 在W模型中，需求，设计，编码等活动被视为串行的，这样就无法支持灵活的迭代。

3.2.3 H模型（专门针对测试过程）

H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

H模型揭示了一个原理：软件测试一个独立的流程。

特点：H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到了准备就绪点，测试执行活动就可以开展，并且不同的测试活动可以按照某个次序先后进行，也可以反复进行。

如果一个公司是测试人员和开发人员都有，那么它大概率使用的是V模型或者W模型；如果这个公司是一个专门测试的外包公司，就不适合使用V模型或者W模型。

3.2.4 X模型

X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终成为可执行的程序。

X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

3.3 软件测试过程理念

• 尽早测试
  • 测试人员早期参与软件项目
  • 尽早的开展测试执行工作
• 全面测试
  • 对软件的所有产品进行全面的测试
  • 软件开发及测试人员（有时包括用户）全面的参与测试工作中
• 全过程测试
  • 测试人员要充分关注开发过程
  • 测试人员要对测试的全过程进行全程的跟踪
• 独立的、迭代的测试
  • 测试活动是独立的
  • 测试活动应该是循环往复、不断的进行

4. 软件测试分类

4.1 软件测试分类

1.按照开发阶段划分

• 单元测试
  • 单元测试又称为模块测试，是针对软件设计的最小单元——程序模块进行正确性验证的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
• 集成测试
  • 集成测试又称组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
• 确认测试
  • 确认测试也叫有效性测试，是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质。
• 系统测试
  • 系统测试是在真实的系统运行的环境下，检查完整的程序系统是否和系统（包括硬件、外设、网络和系统软件、支持平台）正确配置、连接、并最终满足用户的所有需求
• 验收测试
  • 是软件产品检验的最后一个环节，按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

单元测试一般要读程序和代码，在国内大多数时候，单元测试都是由开发人员自己去完成（交叉）（但是一般不认为是在做测试）。

集成测试比较多的涉及到接口测试（接口测试工具和方法）。

确认测试一般都是正向测试（功能是否实现）；确认测试又称为冒烟测试，一般不作为正式的测试环节。

系统测试是全面的，系统所以功能的测试；模拟所有软件用户的操作；全方位的，测试软件和硬件系统的联系，和系统软件的联系，和其他软件的联系。

验收测试一般由供求双方进行，有三种验收测试的主体。
α测试：软件的开发商自己进行的交付前的测试。
β测试：软件的需求方自己进行的测试。
γ测试：第三方的软件测试。

2.按照测试技术划分

• 黑盒测试：通过软件的外部表现来发现其缺陷和错误。黑盒测试把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。黑盒测试又称功能测试。
• 白盒测试：通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。
• 灰盒测试：介于白盒测试和黑盒测试之间。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细，完整，知识通过一些表征性的现象，时间，标志来判断内部的运行状况。有些地方也把灰盒测试叫做接口测试。

3.按照代码运行划分

• 静态测试
  • 指不实际运行被测试对象，而只是静态地检查程序代码，界面或文档中可能存在错误的过程
  • 代码测试：主要测试代码是否符合相应的标准和规范
  • 界面测试：主要测试软件的实际界面与需求中的说明是否相符
  • 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求
• 动态测试
  • 指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。

4.按照软件特性划分

• 功能测试：是黑盒测试的一方面，它是检查实际软件的功能是否符合用户的需求
  • 逻辑功能测试
  • 界面测试
  • 易用性测试
  • 安装/卸载测试
  • 兼容性测试
• 性能测试
  • 功能的另一个指标，主要关注软件中的某一个功能在指定的时间，空间条件下，是否使用正常。
  • 软件的性能包括很多方面，主要有时间性能和空间性能。
• 安全测试
  • 验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法侵入，不受各种因素的干扰。

5.其他测试类型

• 回归测试
  • 是指对软件的新版本测试时，重复执行之前某一个重要版本的测试用例
  • 目的：1.验证之前版本产生的所有缺陷是否被完全修复；2.确认修复这些缺陷没有引发新的缺陷。
• 冒烟测试（确认测试）
  • 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，也叫可测性测试。（是正向的测试）冒烟测试一开始并不产生于IT行业，产生于电子行业。
• 随机测试（类似探索性测试）
  • 是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
• 猴子测试
  • 把自己当成不懂产品的笨蛋或小动物，随便乱点，没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果。

6.按照测试运行主体划分

• 手工测试（功能测试）：手动地测试功能。
• 自动化测试：利用工具软件，或者编写代码的方式，去测试被测的软件系统。

按开发阶段划分	单元测试	集成测试	确认测试	系统测试	验收测试
按测试技术划分	黑盒测试 白盒测试	黑盒测试 白盒测试 灰盒测试	黑盒测试 白盒测试	黑盒测试 白盒测试	黑盒测试 白盒测试
按代码是否运行划分	静态测试 动态测试	静态测试 动态测试	静态测试 动态测试	静态测试 动态测试	静态测试 动态测试
按软件特性划分	功能测试 性能测试 安全测试	功能测试 性能测试 安全测试	功能测试 性能测试 安全测试	功能测试 性能测试 安全测试	功能测试 性能测试 安全测试
按其他测试划分			冒烟测试	回归测试	随机测试 猴子测试

黄色标记的测试是每一个阶段的主要测试。

4.2 软件测试原则

• 所有测试的标准都是建立在用户需求之上。
• 软件测试必须基于“质量第一”的想法去开展各项工作，当时间和质量冲突时，时间要服从质量。
• 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。
• 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。
• 穷举测试是不可能的。
• 第三方进行测试会更客观，更有效。
• 软件测试计划是做好软件测试工作的前提。
• 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
• 对发现错误较多的程序段，应进行更深入的测试，一般来说，一段程序中已经发现的错误越多，其中存在的错误概率也就越大。
• 重视文档，妥善保存一切测试过程（测试计划、测试用例、测试报告等）。
• 应该把“尽早和不断地测试”作为测试人员的座右铭。
• 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
• 测试应从“小规模”开始，逐步转向“大规模”。
• 不可将测试用例置之度外，排除随意性。
• 必须彻底检查每一个测试结果
• 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
• 对测试错误结果一定要有一个确认的过程。

4.3 软件测试人员职业发展

软件测试的职业发展方向基本上可以分为3类：
一. 技术类
技术类测试主要有以下3种测试职位：
1、自动化测试工程师
2、性能测试工程师
3、测试开发工程师
想往这方面发展的话需要掌握至少一门编程语言，也许有人会问自动化和性能测试工具那么多，会用工具不就可以了吗？的确工具可以做到入门级别的自动化和性能测试，但如果想做到更深层次的话还是需要手动改脚本代码，毕竟工具仅仅提供了基础的方法而已。当然通过工具入门也是非常有必要的，但最终还是需要通过编写脚本来完成相关测试的。
二. 产品类
产品类主要有以下2种职位：
一、数据分析师
二、产品经理
想往这方面发展的话只需要利用好测试经验，在设计产品或者数据分析之中考虑到用户可能产生行为（就是测试思维），从而设计出更好的产品。这点相比于没有测试经验的人来说会有很大的优势，而且也更容易和开发打交道。因此产品类的转型是非常适合不想往技术类发展的测试人员的。
三. 管理类
管理类主要有以下2种职位：
1、测试主管
2、项目经理

5. 测试用例和设计方法

5.1 测试用例和设计方法（一）

5.1.1 什么是测试用例

5.1.1.1 测试用例的定义

测试用例：设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所预期结果。

如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件测试人员已经测出了该软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内。

软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。（回归测试）

5.1.1.2 测试用例模板和包含的内容

设计测试用例，可以使用Excel来进行设计，如下：

测试用例应该包含以下内容：

• 标识符：由测试设计过程说明和测试程序说明引用的唯一标识符。
• 测试项：描述被测试的详细特性，代码模块等，应该比测试设计说明中所列的特性更加具体。还要指出引用的产品说明书或者测试用例所依据的其他设计文档。
• 输入说明：该说明列举执行测试用例的所有输入内容或者条件。
• 输出说明：描述测试用例预期的结果。
• 环境要求：是指执行测试用例必要的硬件，软件，测试工具，人员等。
• 特殊要求：描述执行测试所需要的特殊要求。
• 用例之间的依赖性：如果一个测试用例依赖于另一个测试用例，或者受其他测试用例的影响，就应该在此注明。

用例设计模板中的说明：
1.标识符（用例编号）：一般编号规则：TestCase_项目名称_模块名称_功能名称_0001
2.测试项：测试用例的测试目的，一般情况下，用一句话表明目的（将你要做的测试说明白，表明你要测试的模块，测试对象，测试方式，事件，eg：使用谷歌浏览器打开百度首页）。
3.依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例。（eg:登陆一个用户的测试用例依赖于先前注册这个用户的测试用例；删除一个数据的测试用例依赖于先前增加这个数据的测试用例）。
4.测试步骤：用最朴实的语言，写出来软件的操作步骤，要尽量详细。
5.测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致。
6.预期结果：对象的准确性，内容的准确性；原则上，每一个操作，都要有一个结果，在重要的步骤之后，设定预期结果；一般与测试目的密切相关，测试目的决定了测试步骤和预期结果（比如：页面跳转到xxx，弹出提示框，提示：xxx）。
7.测试结果：要求在测试执行完成后添加，没有执行保持为空。 8.测试人：测试的执行人，可以和设计者相同，也可以不同。
9.备注：为了测试用例正常执行而做的特殊准备（eg：专门制造网络不畅情况下，软件错误提示）。

5.1.1.3 设置测试用例的作用

• 有效性：测试用例是软件测试人员的测试过程中重要参考依据；
• 可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率；
• 易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用；
• 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证；
• 可管理性：测试用例也可以作为测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

5.1.2 测试用例编写注意事项

• 不是试图“穷举测试用例”
• 在详细测试用例与有效测试时间中找到平衡点
• 好的测试用例应该多关注“反向测试问题”
• 测试用例库应该不断更新和维护
• 测试用例可以复用，但要注意数据有效性与环境变化
• 测试用例是设计出来的，不是写出来的
• 多去学习经验丰富的测试工程师所设计的测试用例
• 针对不同的需求类型和测试对象，灵活采用不同测试用例设计方法

5.1.3 黑盒测试用例设计方法（一）

5.1.3.1 黑盒测试用例设计方法概述

黑盒测试：通过软件的外部表现来发现其缺陷和错误。黑盒测试把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。黑盒测试又称功能测试。

测试数据的选择：

测试步骤设计：

测试用例的设计方法，没有哪一种是单独使用的：

1. 所有的软件，都是因为某种操作才会导致一定的结果；—考虑使用因果图
2. 所有的软件都有文本框；—考虑使用等价类、边界值

5.1.3.2 等价类划分法（用于测试数据选择）

等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，以此发现更多的软件缺陷，统计好数据后由此对软件进行改进升级。

等价类划分原理

• 把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例；
• 每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；
• 反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。

等价类划分法设计步骤（确定等价类的原则）

• 在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和一个无效等价类；
• 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类；
• 在输入条件是一个布尔量的情况下，可确立一个有效等价类和一个无效等价类；
• 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类；
• 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则）；
• 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。

eg:

一个文本框规定，输入字符个数为6~18位（规定了取值范围）	一个有效等价类：范围内个数；两个无效等价类：小于6，大于18
一个文本框规定，输入11位的手机号（规定了输入值的集合）	一个有效等价类：11位；一个无效等价类：不是11位
一个单选框，选择“是”或者“不是”（布尔量）	一个有效等价类：是（真）；一个无效等价类：不是（假）
登陆中要输入用户名和密码（数据的一组值）	2个有效等价类：用户名和密码分别代表一个有效等价类（两个都为真）；一个无效等价类：除了这2个等价类都为真的情况
用户名要求6~18；由字母，数字，下划线组成；字母区分大小写；（数据必须遵守的规则）	1个有效等价类：3个规则都满足（三个都为真）；一个无效等价类：除了这3个等价类都为真的情况

等价类划分法

1. 首先，我们要划分出等价类和列出等价类表
   a. 有效等价类
   b. 无效等价类
2. 确定测试用例
   a. 为每个等价类规定一个唯一的编号；
   b. 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例覆盖；
   c. 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。

eg（以百度的注册页面为例）:

这里对用户名进行等价类分析：

用户名规则：设置后不可更改，中英文均可，最长14个英文或7个汉字

这里面隐含规则：用户名不可重复；不能为空；

有效等价类	无效等价类
中文、英文	数字、特殊符号
14英文/7个中文	英文超过14个/中文超过7个
不能为空	为空
不能重复	使用重复的数据进行测试

当然可以继续往下细分…
测试用例可以这样来设计：

关于测试用例设计的一些问题

1. 测试用例可以测试：功能（Function）、界面（UI）、性能（Performance）、安全（Security）、接口（Interface）等；
2. 测试项：可以不写目的产生的结果，但测试项必须有明确的目的，不能模棱两可，最后不知道到底测试什么；某些常识性的不要附加上去，避免写的太长；测试项一般只写一个测试目的，不要一次测试多个点；一个无效等价类的测试数据（反向的），只要违反一个需求（比如非法的身份证号）；
3. 依赖用例：一定是下游的测试用例依赖上游的测试用例；如果本身就是按照顺序做的测试用例，可以不写依赖用例，如果跨过了一定的过程或步骤，这时一定要写依赖用例；依赖用例也可以跨模块；
4. 测试步骤：表明操作的对象和方式、数据；
5. 测试数据：没有使用测试数据可不写；如果要求输入不为空，不输入就不写（需要在测试项中标注某一个内容为空）； 如果要对空格进行测试，建议不要将空格这个字符放在数据的最前面或者最后面；
6. 测试结果不执行就不填；
7. 用例中不用说明是正向测试还是反向测试。

等价类划分，不要出现重复的情况，也不要出现缺失的输入部分（比如 x 这种情况不可能同时属于A有效等价类和B有效等价类）

5.1.3.3 边界值分析法（用于测试数据选择）

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

边界值的选择原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超过这个范围边界的值作为测试数据；
• 如果输入条件规定了值的个数，则用最大个数、最小个数，比最大个数多一，比最小个数少一的数作为测试数据；
• 分析规格说明，找出其他可能的边界条件；
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例；
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

边界值选取

• 边界值：特定数据
• 次边界值：按照系统规定的单位或者计算方式，有一个数据的差异

eg:

1. 文本框需要输入6~18位字符，要怎样取值进行测试？
   边界值：6个字符，18个字符
   次边界值：7个字符，17个字符，5个字符（无效），19个字符（无效）
2. 已知x的取值范围，6≤x≤12，请问在测试中要怎样取值进行测试？
   边界值：6，12
   次边界：7（无效），11，5，13（无效）
3. 已知x的取值范围，6＜x＜12，请问在测试中要怎样取值进行测试？
   边界值：7，11
   次边界：6（无效），8，10，12（无效）
4. 已知文本框的输入字符个数要求是不大于150字，要怎样取值进行测试？
   隐含信息：0≤x≤150
   边界值：空，150个字符
   次边界：1，149，151（无效）

实战案例：多边形判断小程序（等价类和边界值综合）
输入多边形的各个边长，注意是整数，该程序可以判断三角形，四边形，五边形；
三角形判断
（1）构成三角形 （2）构成直角三角形 （3）构成等腰三角形 （4）构成等边三角形 （5）构成钝角三角形 （6）构成锐角三角形
四边形判断
（1）平行四边形 （2）正方形 （3）长方形
五边形判断

这里只对三角形进行了等价类分析和设计测试用例：

5.1.4 黑盒测试用例设计方法（二）

5.1.4.1 因果图法

什么是因果图

• 因果图法是一种适合于描述对于多种输入条件组合的测试方法；
• 根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法；
• 它适合于检查程序输入条件涉及的各种组合情况。

建立因果图的步骤

• 第一步：根据功能说明书中规定的原因和结果之间的关系画出因果图

• 第二步（原因之间存在关系，结果之间也存在关系）：根据功能说明在因果图中加上约束条件
  • 其中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束；
  • 互斥(Eclusive)：表示不同时为1，即a、b、c中至多只有一个;
  • 包含(Include)：表示至少有一个1，即a、b、c中不同时为0;
  • 唯一(Only)：表示a、b、c中有且仅有一个1;
  • 要求(Request)：表示若a=1，则b必须为1，即不可能a=1且b=0;
  • 屏蔽(Mask)：表示若a=1，则b必须为0。

因果图使用的局限性：当原因和结果很多的时候，他们之间的关系连线就会很多，导致因果图的可读性变差，因此用作局部的小功能分析（即原因和结果不是很多的时候）

因果图使用实例
阅读和分析功能说明书，识别出“原因”和“结果”，并加以编号;
有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明如下:
若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来;
若投入1元钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来，并同时退回5角钱的硬币。

首先分析有哪些原因、结果—然后分析原因、结果的约束：

这个示例里没有强调投币和选饮料的先后性，所以“要求”约束可以不用画。

列出所有的原因和结果的列表，设计初步的测试用例步骤：

设计测试用例：

5.1.4.2 判断表法（判定表驱动法）

什么是判定表法

判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来；其缺点是判定表的建立过程较烦杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用。

是分析和表达多逻辑条件下执行不同操作情况的工具。它由以下几部分组成：

• 条件桩（Condition Stub）:列出了问题的所有条件（原因），通常认为列出的条件的次序无关紧要；
• 动作桩（Action Stub）：列出的问题规定可能采取的动作（结果），这些操作的排列顺序没有约束；
• 条件项（Condition Entry）：列出针对它左列的条件的取值，在所有可能情况下的真假值；
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

因果图法和判定表法类似，因果图法和判定表法经常会结合在一起使用。

应用场合：主要适用于多条件的内容组合与结果分析，一般判定表法的应用比因果图更广。

使用条件：所有的条件桩在表中的位置和顺序互相不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同。（这点与因果图不同，因果图中的原因和结果是有各自约束的）

• 规格说明以判定表的形式给出，或很容易转换成判定表；
• 条件的排列顺序不影响执行哪些操作；
• 规则的排列顺序不影响执行哪些操作；
• 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
• 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。
  

建立判定表的步骤

• 第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），则有2^n种规则。
• 第二步：列出所有的条件桩和动作桩（原因和结果）。
  • 填入条件项
  • 填入动作项，制定初始判定表
• 第三步：简化，合并相似规则或者相同动作（简化原因或者结果，排除一些不可能存在的情况）。

判定表使用实例

案例一：订购单检查：
如果金额超过500元，由未过期，则发出批准单和提货单；
如果金额超过500元，但过期了，则不发批准单；
如果金额不超过500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。

首先分析条件和动作：

条件1	条件2	动作
金额>500	未过期	发出批准单、提货单
金额>500	过期	发提货单
金额≤500	未过期	发出提货单、提货单
金额≤500	过期	发出提货单、提货单、通知单

然后进行判定表优化：

观察判定表可以发现，不管金额的高低，只要过期，就会发送批准单和提货单（在测试时间不充足的情况下，可以选两者中的一个情况下进行测试）—当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

所以优化后，条件项就减少成为3个。

最后将判定表中的每一列也（条件项和对应的动作项）作为测试用例的数据和操作以及对应的预期结果。

实际上，做项目测试用的最多的方法就是等价类划分和边界值分析。

案例二：该判定表为一个杂志的阅读指南判定，指导读者能够良性阅读。

读完表格后，请对表格内容进行优化，将重复的内容去掉，并且说明原因，为什么能合并。

在时间充足的情况下，就把所有可能的条件组成测试一遍，时间不充足的情况下，要想进行全面的覆盖，只能采用科学的方法进行优化。

5.1.4.3 场景法

场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

场景法基本原理

现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。

基本流：软件功能按照正确的事件流实现的一条正确的流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）

备选流：除了基本流之外的各支流，包含多种不同的情况。采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）

每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
…

注意：

1. 场景中必须有基本流
2. 场景中必须有流从用例的开始，到用例的结束

场景法设计用例步骤

• 根据说明，描述出程序的基本流及各项备选流；
• 根据基本流和各项备选流生成不同的场景；
• 对每一个场景生成对应的测试用例；
• 对生成的所有测试用例进行复审，去掉多余的测试用例；
• 测试用例确定后，对每一个测试用例确定测试数据值。

场景法适用于解决业务流程清晰的系统或功能。

场景法设计实例
案例：ATM机的取款流程。
简单的分析：

详细：
基本流：插卡—输入—选择取款服务—选择取款金额—等待出钞—退卡

备选流：

1. 卡片不是银行卡
2. 卡片不是银联卡
3. 密码输错1-2次，第三次输入正确
4. 密码输错3次，冻结银行卡
5. 选择存款服务
6. 选择转账服务
7. 选择修改密码服务
8. 取款机没有纸币了
9. 取款机没有信号了
10. 等…

场景设计：
场景1：基本流
场景2：基本流 备选流1
场景3：基本流 备选流4
场景4：基本流 备选流2 备选流3
…

设计测试用例步骤（每一个场景都是一个测试用例）：
以场景4为例：
假定ATM只能识别银联卡
1.插卡—用万事达卡，ATM不识别
2.换卡—银联卡
3.输入密码-第一次输入错误
4.输入密码—第二次输入密码
5.输入密码—第三次输入密码正确
6.选择取款服务
6.选择取款金额
8.等待出钞
9.退卡

为用例的步骤设计测试数据…

5.1.5 黑盒测试用例设计方法（三）

5.1.5.1 正交试验法

正交试验法原理介绍

正交试验法就是利用排列整齐的表—正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最好的效果。

这种试验设计方法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格—正交表来安排试验并进行数据分析的方法。

正交试验法是由日本的一个统计学家提出；
使用的工具：正交表；
统计和分析实验数据，从大量实验中找到合适的实验数据（原本用于工业生产的数据组合与实验室的数据挑选）；
类似于数独；
大量的实验组合中，挑选一部分具有代表性的点进行实验，分析数据。

涉及到的数学原理：线性代数、概率论、数理统计。

正交试验法来源于n阶拉丁方；
比如3阶拉丁方：

用数字代替拉丁字母进行正交运算：

基本思想

• 在一项实验中，把影响试验结果的量称为试验因素（因子），简称因素。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平；
• 每列不同的数字出现的次数相同。这一特点表明每个因素的每个水平与其它因素的每个水平参与实验的几率是完全相同的，能有效地比较试验结果并找出最优的试验条件；
• 在任意2列其横向组成的数字对中，每种数字对（水平对）出现的次数相等。这个特点保证了试验点均匀地分散在因素和水平的完全组合当中。

eg：
字的显示效果—字体、字号、因素（这些被称为因素）
字体选择可以选择宋体、微软雅黑等（这些状态或值被称为水平）

正交试验法实现步骤

1. 确定因素：这里的因素是指对软件运行结果有影响的软件（从多个角度、方式进行分析，无论是显性的还是隐形的需求）
   确定因素的取值范围或集合（该步为步骤3准备）；
   因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源。
2. 确定每个因素的水平
   根据因素的取值范围或集合、采用等价类划分、边界值分析以及其他的软件测试技术，在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试值。
3. 选择正交表（在现实中，找最贴近的正交表，正交表的因素数和水平数一般要大于实际的因素数和水平数）
   根据确定的因素和水平，选择适合的正交表；
   如果没有合适的正交表可用或需要的测试用例个数太多，需要对因素和水平进行调整；

正交表的表示
正交表是一种特制的表，一般的正交表记为：

• m是水平数，k是因素数，n是需要进行实验的行数（注意：这三个数之间没有任何数学关系）；
• 行数：正交表中行的个数，即实验的次数，也是通过正交实验法设计的测试用例的个数；
• 因素数：正交表中列的个数。即要测试的功能点；
• 水平数：任何单个因素能够取得的值的最大个数，即要测试功能点的输入值。

正交表的种类

• 各列水平数均相同的正交表
• 混合水平正交表

正交表的特性：整齐可比，均衡分散

实际案例

正交试验法案例：有一个工业产品，其生产工艺受到操作方式、温度、洗涤时间三个因素的影响，并且每个因素都有三种可能的取值，具体如下所示，请设计试验组合。

因素	操作方式	温度(℃)	洗涤时间(min)
	Ⅰ	60	15
	Ⅱ	80	20
	Ⅲ	100	25

完全排列组合：3*3*3=27
使用小工具完成正交实验的设计：正交设计助手

正交设计助手（工具）

以上面的案例为例使用该工具：

文件→新建工程→右键“未定义工程”→修改工程

实验→新建实验→设计向导（实验说明）

设计向导（选择正交表）：这个案例是3水平3因素，我们选择3水平4因素的正交表（L9_3_4），这里是选择最贴切的正交表，如果因素个数选小了，就无法覆盖所有可能的测试用例。

设计向导（因素和水平）→填写数据后→点击确定

完成后的正交表设计：

至于推导的过程，这个可以不要求清楚。

观察以上设计的正交表：
每一列中，同一个数字出现的次数相等（这里是出现了3次）
任意两列中，同一个数字对出现的次数相等（这里是出现了1次）

5.1.5.2 功能图法（状态迁徙图）

这个用的比较少，会用就行。

功能图法原理介绍

功能图方法是用功能图形象的描述程序的功能说明，并机械的生成功能图的测试用例。功能图由状态迁移图和逻辑功能模型构成。

来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时，如何进行测试用例的设计就比较麻烦。

状态迁徙图的目标：设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁徙图路径的覆盖。

使用场合：软件的状态会根据某些内容、条件、操作的变化而变化。（比如Tim的隐身、在线、离线、忙碌等状态）

比如说，以操作系统的进程调度算法为例：
操作系统的四大功能：存储器管理、文件管理、设备管理、处理机管理；
而处理机管理的内容：进程控制、进程同步、进程通信、进程调度

功能图法步骤

1. 列出所有可能的输入（操作）事件，以ip N（ip就是input）的方式命名（N为1，2，3，4…）；
2. 定义空闲状态（初始状态），一般把软件的打开的初始状态定义为“空闲”状态；
3. 在“空闲”状态上加所有可能的输入（只加一次）；
4. 为上一次产生的所有新状态，分别加所有可能的输入（只加一次，并且曾经加过的操作，不再重复）；
5. 循环执行上一步；
6. 直到再没有任何新状态的产生，列出所有状态，生成状态表；
7. 组合任意可能的状态组合，写出相应的测试用例。

实际案例
这里以老版的QQ登陆界面为例，说明功能的变迁：

1）首先识别出可以进行的操作：
IP1:输入账号
IP2:输入密码
IP3:点击登录
IP4:点击关闭按钮

2）定义QQ登录界面为 “空闲” 状态；

3）给“空闲”状态加操作，就产生了新的状态；

4）在新状态的基础上加操作，得到了一个新的状态 “QQ号，密码已输入”；

5）在新状态的基础上加操作，得到得到了一个新的状态 “QQ登录后的界面”，但这个状态和“空闲”状态发生了“隔断”，因此可以将其视为空闲状态的结束，而结束整个分析过程；

6）将状态变化过程列表化，准备设计测试用例；

状态名/序号	A	B	C	D	…
空闲	1	1	1	1
QQ号已输入		2		2
密码已输入			2
QQ号、密码已输入				3
QQ登录后的界面				4
退出	2	3	3

每列的含义：
A列：从QQ登陆界面，直接点击登录按钮，QQ登录退出；
B列：…
C列：…
D列：从QQ登陆界面，先输入QQ号（状态变为 “QQ号已输入”）；在输入密码（状态变为QQ号，密码已输入），点击登录，状态变为“QQ登录后的界面”；
…
x列：…

好的测试用例，越简单越好，做到：大道至简，大巧若拙。

6）写出测试用例…

5.1.5.3 其他用例设计法

测试大纲法

• 是一种着眼于需求的方法；
• 为列出各种测试条件，将需求转换为大纲的形式，就类似于思维导图（树形结构）；
• 无需测试用例，一般从<根节点开始分析，到叶节点>为止，这样的一条路径就是一条测试用例；
• 一般用于快速的测试和记录，至于用例实际上一般用于后补。

探索测试法

• 基于经验和和直觉；
• 是计划内测试用例设计的补充；
• 探索性测试执行前也需要设计测试用例。

猴子测试（随意性测试）

• 一种没有书面测试用例，记录期望结果、检查列表、脚本或指令的测试（无意识的测试）；
• 缺点：
  • 测试往往不太真实；
  • 不能达到一定的覆盖率；
  • 许多测试都是冗余的；
  • 需要使用同样的随机数才能重建测试，即想要重复的操作及其困难。

5.1.5.4 用例设计方法综合选择

• 首先进行等价类划分
• 在任何情况下都必须使用边界值分析法
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
• 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳的效果
• 状态迁徙图也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据
• 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
• 可以用错误推测法（探索性测试）追加一些测试用例
• 对照程序逻辑，检查已设计出的测试用例看的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

只要软件有文本框，那么等价类划分和边界值分析就必不可少；
用例的设计方法不是孤立存在的、而是存在于一个项目中。

应用案例

这里以教育App—"正教"为例，来说明用例设计方法的应用：

1)启动页中，有如下需求：

• 读取版本更新信息。匹配当前App与当前线上需要更新的App版本是否一致；
• 读取用户信息。未登录用户，则不用获取，已登录用户，验证是否登录过期。

♩ 用例设计方法：采用场景法

设计场景：
场景一：App的安装版本比最新版要低，启动需要进行版本检测，并进行提示。
场景二：App安装版本与最新版一样，默认检测过程成功。
场景三：App启动检测用户登录状态，如果登录过期或者未登录，启动完成后直接登录界面。
场景四：App启动检测用户登录状态，如果登录信息有效，启动完成后直接App首页界面。

2)登录页中，有如下需求：

• 手机号：只支持大陆；
• 验证码：长度为6位数字；
• 短信验证码文本内容：【正教】456712（正教）验证码，30分钟内有效，为确保您账号安全，请勿把验证码告诉他人。感谢您关注正教！
• 登录按钮点击后，系统可能的弹框提示。

用例设计方法：等价类划分法、边界值分析法

等价类划分法：
1.手机号的有效性（手机号包含各种不合法字符）；
2.验证码包含各种不符合需求的字符。

边界值分析法:
1.手机号超过/超过长度限制；
2.验证码超过/超过长度限制；
3.验证码有效性为30分钟，所以超过30分钟后使用验证码，就是边界值的使用；
4.弹窗提示1s消失，超过或者不足的测试都是边界值的应用。

♪ 用例设计方法：采用因果图法
1.提交数据时，App网络中断，有网络异常的提示；
2.提交数据时，服务端崩溃或者无法提供正常服务，有服务器报错提示或者等待提示；
3.提交数据时，手机号不符合要求（不存在），有手机号错误提示；
4.提交数据时，验证码输入不是收到的验证码、超时，有验证码错误提示。

3)课程内容页，有如下需求：

• 日期选择：点击跳出日期选择页面
  方式1（下拉列表）：
  ݶ 点击选择对应的月份
  ݶ 没有内容的月份则不显示
  ݶ 上滑显示更多的月份
  方式2（日期组件）：
  ݶ 点击日子选择对应日期
  ݶ 上滑显示更多的月份
• 返回：返回到上一级页面
• 星期提示：
  ݶ 只展示该星期所有日期
  ݶ 当天日期凸显出来

用例设计方法：场景法、等价类划分法、边界值分析法

场景法：
场景1：该课程今日有作业、有提问的内容展示
场景2：该课程今日有作业、无提问的内容展示
场景3：该课程今日无作业、有提问的内容展示
场景4：该课程今日无作业、无提问的内容展示

等级类划分法、边界值分析法：
1.日期的显示，有没有出现2017年2月29天的现象；
2.日期的显示，会不会出现2017年2月1日和2017年1月31日重复或者相隔一天的现象。

所有测试用例的设计方法，没有独立使用的，都是融合在一起使用，往往在一个软件的界面中，都可以使用好几种测试用例的设计方法。
正交试验法是一种及其特殊的设计方法，在软件中很少使用，一般用于要选择具体设置参数的界面。

6. 缺陷和缺陷报告

6.1 缺陷的基本概述

缺陷的定义
笼统地来说：所有不满足需求或超出需求的都是缺陷，没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷。

专业来说：

1. 软件未实现产品说明书要求的功能；
2. 软件出现了产品说明书指明不应该出现的功能；
3. 软件实现了产品说明书未提到的功能（即作为隐形需求不应该实现的功能）；
4. 软件未实现产品说明书虽未提及但应该实现的功能；
5. 软件难以理解、不易使用、运行缓慢或者（从测试的角度来看）最终用户会认为不好。

缺陷的属性

缺陷类型	描述
缺陷类型（type）	缺陷类型是根据缺陷的自然属性划分的缺陷种类
缺陷严重程度（Severity）	缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度
缺陷严重程度（Priority）	缺陷的优先级指缺陷必须被修复的紧急程度
缺陷状态（Status）	缺陷的状态指缺陷通过一个跟踪修复过程的进展情况/td>
缺陷起源（Origin）	缺陷的起源指缺陷引起的故障第一次被检测到的阶段
缺陷来源（Source）	缺陷的来源指缺陷的起因/td>
缺陷根源（Root Cause）	缺陷的根源指发生错误的根本因素

缺陷的类型：缺陷类型是根据缺陷的自然属性划分的缺陷种类。

缺陷类型	描述
功能（Function）	影响了各种系统功能、逻辑的缺陷
用户界面（UI）	影响里用户界面、人机交互特性、包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷
文档（Documentation）	影响发布和维护、包括注释、用户手册、设计文档
软件包（Package）	由于软件配置库、变更管理或版本控制引起的错误
性能（Performance）	不满足系统可测量的属性值、如执行时间、事务处理速率等
系统/模块接口（Interface）	与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突

注意：
需求分析、设计阶段，文档类型的缺陷较多；
集成测试阶段，一般接口类型的缺陷较多；
系统测试阶段，功能、界面类型的缺陷较多；
验收测试阶段，更多的会关注性能缺陷；
实施阶段，可能会遇到软件包的缺陷。

缺陷的严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

缺陷严重等级	描述
致命（Fatal）	系统任何一个主要功能完全缺失，用户数据收到破坏，系统崩溃、悬挂、死机、或者危及人身安全
严重（Critical）	系统的主要功能部分丧失，数据不能保存，系统次要功能完全丧失，系统所提供的功能或服务受到明显的影响
一般（Major）	系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题
较小（Minor）	操作者不方便或遇到麻烦，但它并不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题

缺陷的修复等级：缺陷的优先级指缺陷必须被修复的紧急程度。

缺陷优先级	描述
立即解决（P1级）	缺陷导致系统几乎不能使用或测试不能继续，需立即修复（一般几个消失内，比如四个小时）
高优先级（P2级）	缺陷严重，影响测试，需要有限考虑（一般一天内）
正常排队（P3级）	缺陷需要正常排队等待修复（在新版本发布之前）
低优先级（P4级）	缺陷可以在开发人员有时间的时候被纠正（有些缺陷甚至跨越几年都没有修复）

缺陷的修复优先级，很大程度上取决于缺陷对测试工作的影响的影响程度，例如：电商系统的用户注册功能无法使用（无法登陆、购买、结算、支付、下订单、物流跟踪、收货、评论等功能都无法进行），就必须立即修复；电商系统中关于用户购买流程帮助说明的网页链接点击404页面，这样的就可以不用急着改正。
注意：修复优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能缺陷，优先级高，甚至需要立即解决；软件功能测试中的反向测试的内容，优先级较低，甚至有些是可改可不改。

缺陷的状态：缺陷的状态指跟踪缺陷修复过程的进展情况。

缺陷状态	描述
激活/打开	问题还没有解决，存在于源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷
已修复/修复	已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证
关闭/非激活	测试人员验证后，确认缺陷不存在之后的状态
重新打开	测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复
推迟	这个软件缺陷可以在下一个版本中解决
保留	由于技术原因或第三方软件的缺陷，开发人员不能修复的缺陷
不能重现	开发不能再现这个软件缺陷，需要测试人员检查缺陷复现的步骤
需要更多信息	开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等
重复	这个软件缺陷已经被其他软件测试人员发现
不是缺陷	这个问题不是软件缺陷
需要修改软件规格说明书	由于软件规格说明书对软件设计的要求，必须要修改软件规格说明书

发现缺陷是缺陷处理的前提，但是还没有进入缺陷的处理流程。
1.激活/打开（新建）。由开发人员进行标注。
2.确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、或者质量保证（OA）、由产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理。
3.已修复/修正。在缺陷被修复后，一般由开发人员进行
4.关闭/非激活。缺陷被修复完成后，经测试人员的验证后，没有问题。
5.重新打开。经测试人员验证后，发现缺陷并没有被修复成功，需要开发人员重新打开进行再次处理和修复
6.推迟。缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或者其他相关管理人员进行确认（推迟的这个状态要去确认）
7.保留。缺陷暂时修复不了。一般由开发人员去设定，测试人员进行确认。
8.不能重现。一般闪退、崩溃类型的缺陷具有类似的特征，或者由于操作系统的差异、浏览器缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要再三的确认bug。
9.需要更多信息。作为测试人员，提交bug的时候，要尽可能的把所有相关文件一起提交。（比如测试用的图片、视频）
10.重复。测试中，一定要避免这种情况出现。尤其在软件的某一个功能频繁被多个模块（由不同的测试人员测试）调用的情况下。
11.不是缺陷。注意不要出现这种情况。
12.需要修改软件规格说明书。缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成的。

缺陷的起源：缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段。

缺陷起源	描述
需求	在需求阶段发现的缺陷
架构	在系统架构设计阶段发现的缺陷
设计	在程序设计阶段发现的缺陷
编码	在编码阶段发现的缺陷
测试	在测试阶段发现的缺陷
用户	在用户使用阶段发现的缺陷

缺陷的来源：缺陷来源指的是缺陷的起因（即缺陷的直接因素）。

缺陷来源	描述
需求说明书	需求说明书的错误或不清楚引起的问题
设计文档	设计文档描述不准确和需求说明书不一致的问题
系统集成接口	系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
数据流（库）	由于数据字典、数据库中的错误引起的缺陷
程序代码	是由编码中的问题引起的缺陷

缺陷的根源：是指发生错误的根本原因。（更多的是在软件测试最后的总结阶段，总结测试过程中的经验、技术的不足，及未来的改进问题）

缺陷根源	描述
测试策略	错误的测试范围，误解了测试目标，超越测试能力等
过程、工具和方法	无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等
团队/人	项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气或动机不纯
硬件	硬件配置不对，或者处理器导致算法精度丢失，内存溢出
软件	软件设置不对，操作系统错误导致无法释放资源，工具软件错误、编译器错误、千年虫等问题
工作环境	组织机构调整，预算改变，工作环境恶劣，如噪音过大

缺陷的起源、来源、根源，一般关注较多的是缺陷的来源（直接原因），在测试总结的时候，关注的缺陷的根源。

6.2 缺陷的生命周期

确认缺陷：一般由测试主管或者质量保证（OA）、产品经理进行确认。
分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配，分配的对象可能是开发、也可能是UI，也可能是产品经理。
验证缺陷：测试人员去验证缺陷有没有修复。
关闭缺陷：只能是测试人员进行，否则出了问题，测试人员一律不背锅。

6.3 缺陷的识别

• 通过测试用例中的预期结果进行识别
• 通过需求规格说明书进行识别
• 通过用户手册及其他文档进行识别
• 通过同行业相类似成熟的商业软件来识别
• 通过和开发人员的沟通进行识别
• 通过和有经验的测试人员沟通进行识别
• 参照同行业隐形需求进行识别

缺陷识别的依据

• 客观的依据：需求文档，设计文档，产品原型，测试用例
• 主观的依据：同行业的类似成熟的软件，和开发人员沟通，跟有经验的测试人员沟通，参照同行业隐形需求进行识别

所以测试人员识别缺陷的时候，要很灵活的对待。

6.4 缺陷报告

编写目的和预期读者

缺陷报告的编写目的：

• 易于搜索软件测试报告的缺陷
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
• 软件开发人员希望获得缺陷的本质特征和复现步骤
• 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度

缺陷报告的预期读者：开发人员、质量管理人员、市场人员、运维人员…等很多人都会阅读缺陷报告，所以缺陷报告一定要用语直白、清晰、明了。

缺陷报告编写准则（准确、清晰、简洁、完整、一致）

• 准确（Correct）：每个组成部分的描述准确，不会引起误解
• 清晰（Clear）：每个组成部分的描述清晰，易于理解
• 简洁（Concise）：只包含必不可少的信息，不包含任何多余的内容
• 完整（Complete）：包含复现该缺陷的完整步骤和其他本质信息
• 一致（Consistent）：按照统一的格式书写全部缺陷报告

缺陷报告模板

1. 缺陷编号：Bug_项目名称_模块名称_功能名称_000x
2. 所属模块：一级模块名称/二级模块名称/三级模块名称（有利于修改的人员快速定位缺陷位置）
3. 优先级：缺陷的修复紧急程度 P1>P2>P3>P4
4. 严重程度：S1>S2>S3>S4
5. 缺陷概述：一般用一句话来描述缺陷的基本情况（时间、地点、人物、事件）
6. 缺陷描述：将缺陷的复现步骤、实际结果和预期结果列出来
7. 提交人：是谁提交的就写谁的名字
8. 备注：一般写产生该缺陷的特殊情况；如果没有特殊情况，将bug的截图作为备注信息

<缺陷描述>准则
指缺陷报告中这一部分的准则：

• 单一准确
• 可以再现（大部分的缺陷可以再现，但类似于偶尔出现的闪退、崩溃这种缺陷，就无需做到）
• 完整统一
• 短小简练
• 特定条件
• 补充完善
• 不做评价（不对缺陷出现的严重程度和缺陷表现出来的效果进行主观臆断，不要调侃）

缺陷跟踪系统

• Bugzilla（英文），安装比较繁琐
• Bugfree（中文），国产，安装简单，用例，缺陷跟踪，但功能单一（现已被禅道收购）
• 禅道（中文），国产，项目，产品，测试，功能齐全，组织机构，人员，开源，免费
• QC（ALM），外国，可做性能测试，功能齐全，但收费高昂
• JIRA 国外软件 Java环境 主流（商业）
• 企业用自己开发的