[开发测试]软件测试基础学习

1.软件和软件测试

1.1 软件

软件组成：

• 程序
• 数据
• 文档

软件的分类

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

1.2缺陷的由来

软件缺陷的由来

• Bug
• Defect

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

软件缺陷的定义

• 软件未实现产品说明书要求的功能
• 软件出现了产品说明书指明不应该出现的功能
• 软件实现了产品说明书未提到的功能
• 软件未实现产品说明书虽未明确提及但应该实现的目标
• 软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

软件测试的由来

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

1.3软件测试的定义

正向思维

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

反向思维

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

IEEE定义的测试

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

广义软件测试定义

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

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

1.4软件测试的目的

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

1.5测试和调试的区别

• 在主体、目标、方法和思路上有所不同

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

2.软件工程

2.1 软件危机

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

2.2 软件工程

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

• 软件开发技术：软件开发方法学、软件工具和软件工程环境
• 软件项目管理：软件质量、项目估算、进度控制、人员组织、配置管理、项目计划

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

2.3 生命周期

需求分析、概要设计、详细设计、编码、测试、验收

2.4 软件生命周期模型

1、瀑布模型

最早提出的软件开发的过程模型
优点：

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

缺点：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量（强调时间顺序的严格执行：前阶段不完成，后阶段不开始）
• 线性开发，用户等到整个过程的末期才能开到开发成果，从而增加了开发风险（将测试放在了编码之后，没有体现出测试贯穿软件生命周期的原则。可以避免需求的问题一直延续到代码完成才暴露或者被发现）
• 不适应用户需求的变化

2、快速原型模型

应用领域越来越多
原型：就是一个模型，可以模拟操作、简单运行
典型应用和工具：Axure 制作原型

3、增量模型

把软件分割成独立的模块，分批次的完成和交付
缺点：打破原有的软件结构和框架，可能会带来一定的风险
增量模型一般会和迭代模型一起运用
1）软件增加了新功能
2）优化了…功能
3）修复了某些未知/已知的bug

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

• 降低了在一个增量上的开支风险
• 降低了产品无法按照既定进度进入市场的风险
• 加快了整个开发工作的进度
• 迭代过程这种模式使适应需求的变化会更容易些
  
  敏捷宣言，也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。
  

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

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

3.软件测试

3.1 软件测试流程（重点）

获取测试需求–>编写测试计划–>制定测试方案–>开发与设计测试用例–>执行测试–>提交缺陷报告–>测试分析与评审–>提交测试总结–>准备下一版本测试

3.2 软件测试过程模型?????

测试过程的质量将直接影响测试结果的准确性和有效性

3.2.1 V模型（重点）

揭示了开发过程与测试过程中各阶段的对应关系
缺点：

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

3.2.2 W模型（重点）

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

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

局限性：

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

3.2.3 H模型

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

H模型揭示了一个原理：软件测试是一个独立的流程！
软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，也可以反复进行。

3.2.4 X模型

X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序
X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

3.3 软件测试过程理念

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

4 软件测试的分类

4.1 软件测试的分类

1.按照开发阶段划分

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

2.按照代码运行划分

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

3.按照软件特性划分

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

4.按照测试技术划分

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

5.其他测试类型

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

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

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

4.2 软件测试的原则

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

5.测试用例

5.1 测试用例的定义

简单地说，测试用例就是：
设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果。
如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内
软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。

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

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

• 标识符（用例编号）：由测试设计过程说明和测试程序说明引用的唯一标识符。一般编号规则：TestCase_项目名称_模块名称_功能名称_0001
• 测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体，还要指出引用的产品说明书或者测试用例所依据的其他设计文档。测试用例的测试目的，必须是确定的，可以不写目的产生的结果，测试目的决定了测试步骤和预期结果，一般情况下，用一句话表明目的（表明测试模块、测试对象、方式、事件）。例如：使用谷歌浏览器打开百度首页；在QQ登录界面输入正确的用户名密码能登录上。
• 依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例（已经存在的测试用例），用例依赖可以跨越模块（A设计员可能会依赖B设计员的测试用例）。例如：增加了一个数据的测试用例，将会被删除该数据的测试用例依赖
• 测试步骤：用最朴实的语言，写出软件的操作步骤，表明操作的对象和方式，数据，要尽量详细。例如：在用户名文本框输入：XXX；在省份下拉列表选择：北京 城市下拉列表选择：北京
• 测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致；没有数据，空着不写。例如输入要求不为空，不输入就不写（须在测试项中标注某一个内容为空）；如果要对空格进行测试，不要将空格放在数据的最前面或最后面（123 456）
• 预期结果：准确（对象的准确、内容的准确），原则上每一个操作都要有一个结果，在重要的步骤之后，设定预期结果，一般和测试目的密切相关。例如：页面跳转到XXX；程序弹出对话框，提示用户名或密码错误，请重新输入！
• 测试结果：要求在测试执行完成后添加，没有执行保持为空。测试结果只有两个：通过（Pass）/ 失败（Failed），和预期结果一致即为通过，不一致即为失败
• 测试人：测试的执行人，可以和设计者相同，也可以不同
• 备注：为了测试用例正常执行而做的特殊准备。例如：专门制造网络不畅情况下，软件错误提示
• 输入说明：该说明列举执行测试用例的所有内容或者条件
• 输出说明：描述进行测试用例预期的结果
• 环境要求：指执行测试用例必要的硬件、软件、测试工具、人员等
• 特殊要求：描述再执行测试必须的特殊要求
• 用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明

用例按照测试分类：

• 功能（Function）
• 界面（UI）
• 性能（Performance）
• 安全（Security）
• 接口（Interface）

5.3 设计测试用例的作用

用例设计和编写的作用

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

5.4 测试用例编写注意事项

• 不要设计“穷举测试用例”
• 在详细测试用例与有效测试时间中找到平衡点
• 好的测试用例应该多关注“反向测试问题”（测试用例需要经常更新，尤其是发现过缺陷的测试用例。“杀虫剂效应”，一个发现过缺陷的测试用例，就相当于杀虫剂，必选使用“更强的杀虫剂”-----新的测试用例，与之 前的用例中数据类型保持一致，进行重新测试）
• 测试用例库应该不断更新和维护
• 测试用例可以复用，但要注意数据有效性与环境变化
• 测试用例是设计出来的，不是写出来的
• 多去学习经验丰富的测试工程师所设计的测试用例
• 针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法

5.5 黑盒测试用例设计方法

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

5.5.2 测试数据选择方法–等价类划分法

1、等价类划分法原理

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

2、等价类划分法设计步骤

确定等价类的原则：

• 在输入条件规定了取值范围或值的个数得情况下，可以确立一个有效等价类和两个无效等价类（例如：一个文本框规定，输入字符个数为6~18位。一个有效等价类：范围内个数；两个无效：＜6，＞18）
• 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类（例如：请输入11位地手机号。有效等价类：11位；无效等价类：不是11位）
• 在输入条件是一个布尔值的情况下，可确定一个有效等价类和一个无效等价类（真、假）
• 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类（例如：登录时输入用户名、密码）
• 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）（例如：用户名输入要求：6~18位；由字母、数字、下划线组成；字母区分大小写；以大写字母开头。“若干个”由规则地个数确定）
• 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小地等价类
  3、等价类划分法

①划分等价类和列出等价类表

• 有效等价类
• 无效等价类

例：

②确定测试用例

• 为每个等价类规定一个唯一的编号
• 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖地有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖
• 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖
  

5.5.3 测试数据选择方法–边界值分析法

如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据；如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1得数作为测试数据；分析规格说明，找出其他可能的边界条件

边界值只是一个特定的数据。例如，文本框需要输入6~18位字符
边界值有：6个字符；18个字符
次边界：边界附近的值，按照系统规定的单位或计算方式，一个数据的差异。
例如，字符就是个，一个字符，没有半个字符的说法；人民币金额，最小单位是0.01元（1分），ATM机取款和存款，最小单位就是100元，只能是100元的整数倍
思考：
1）6≤x≤18，测试中x的边界值要选取哪几个进行测试？（5，6，7，17，18，19）
2）6＜x＜18，测试中x的边界值要选取哪几个进行测试？（6，7，8，16，17，18）
3）文本框输入字符的个数要求是不大于150字，测试时如何选择边界值？（0≤x≤150，空，1，149，150，151）

边界值的选择原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
• 根据规格说明的每个输出条件，使用前面的原则①
• 根据规格说明的每个输出条件，应用前面的原则②
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例

5.5.4 因果图法

1、什么是因果图

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

2、因果图的符号

第一步：根据功能说明书中规定的原因和结果之间的关系画出因果图（一般左边是原因，右边是结果）

第二步：根据功能说明在因果图中加上约束条件
其中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束，它们的含义如下（假设原因成立用1表示，不成立用0表示）：

• 互斥（Exclusive）：表示不同时为1，即a，b，c中至多只有一个1，a+b+c≤1
• 包含（Include）：表示至少有一个1，即a，b，c中不同时为0，1≤a+b+c≤3
• 唯一（Only）：表示a，b，c中有且仅有一个1，a+b+c＝=1
• 要求（Request）：表示若a=1，则b必须为1，即不可能a=1且b=0
• 屏蔽（Mask）：表示若a=1，则b必须为0
  
  3、因果图使用实例

阅读和分析功能说明书，识别出”原因“和”结果“，并加以编号

1、分析原因和结果

2、根据需求分析画出原因和结果之间的关系（部分关系），并进行关系的连接

3、按照需求描述原因、结果之间的约束

因果图使用中的局限性：当原因和结果很多的时候，它们之间的关系连线就会很多，导致因果图的可读性变差。因此用作局部的小功能（原因和结果不是很多的时候）分析。
因果图优势：能够发现设计中存在的不足
4、列出所有的原因和结果的列表，设计初步的测试用例步骤
将因果图中的每一个分支用表格列出来，而列表中的每一列都是一条测试用例

C5、C6、C7：这是一种bug，不能做测试设计
经过分析发现：
1）只选择饮料，没有投币的时候，软件没有任何结果
2）只投币，没有选择饮料的时候，软件没有任何结果
3）不能把软件的缺陷设计成测试用例

5.5.4 判定表法

1、什么是判定表法（判定表驱动法）
是分析和表达多逻辑条件下执行不同操作地情况的工具。
应用场合：主要适用于多条件的内容组合与结果分析
它由以下几个内容组成：

• 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要
• 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束
• 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作
  
  2、建立判定表的步骤
  第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有2^n种规则
  第二步：列出所有的条件桩和动作桩。填入条件、动作桩，制定初始判定表
  第三步：简化，合并相似规则或者相同动作
  1）识别出操作条件（原因）和对应的动作（结果）
  2）分析条件的条件项（组合数量）；如果有n个条件，每个条件有成立和不成立两种情况，那么最后一共有2^n个数量
  3）简化和优化结果，排除一些不可能存在的情况

3、判定表使用实例

1）分析条件和动作

2）写入条件桩、动作桩、条件项、动作项

判定表

3）对判定表进行简化和优化，对其中不合理或重复的进行取舍
无论金额高低，只要未过期，都会发批准单和提货单（在测试时间不充足的情况下，可以选二者中的一个情况进行测序；在测试时间充足的情况下，每一个都要测试），所以优化之后，条件项就减少为3个

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

4、适合使用判定表设计测试用例的条件

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

测试用例的设计方法：没有哪一种方式是单独使用
1）所有的软件，都是因为某种操作才会导致一定的结果。–考虑使用因果图
2）所有的软件都有文本框。–考虑必须一定使用等价类、边界值

5.5.5 场景法

1、场景法基本原理

现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
基本流：软件功能按照正确的事件流实现的一个正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
备选流：除了基本流之外的各支流，包含多种不同的情况。

2、场景列表：

• 场景1 基本流
• 场景2 基本流 备选流1
• 场景3 基本流 备选流1 备选流2
• 场景4 基本流 备选流3

注意：

• 场景中必须有基本流
• 场景中必须有内容从用例的开始，到用例的结束

3、设计用例的步骤

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

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

案例：ATM机取款

基本流：插卡–输入密码–选择取款金额–等待出钞–取卡
备选流：
1、卡不是银行卡
2、卡不是银联的卡
3、密码输错一次
4、密码输错两次，第三次输入正确
5、密码输错三次，冻结账号或吞卡
6、选择存款服务
7、选择查询服务
8、选择转账服务
9、选择修改密码服务
10、选择取款金额100、200、…
11、选择其他金额
12、账户余额
13、ATM机没钱了
14、账户取款金额达到取款机的当日取款上线
15、账户取款金额达到账户当日取款交易上限
16、取款机掉线
17、取款机停电
18、…
场景设计
场景1：基本流
场景2：基本流 备选流1
场景3：基本流 备选流5
场景4：基本流 备选流4
场景5：基本流 备选流2 备选流4

设计测试用例（场景5）：
假定ATM只能识别银联卡
1、插卡（先用万事达卡）
2、换卡（银联卡），再进行插卡
3、输入密码（第一次输入错误）
4、再次输入密码（第二次输入错误）
5、第三次输入密码（输入正确）
6、选择服务–取款
7、选择取款金额–500
8、等待出钞
9、取卡

为用例的步骤设计数据

5.5.6 正交试验法

1、正交法原理介绍
正交实验法就是利用排列整齐的表-正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的试验次数找到较好的生产条件，以达到最好效果。
这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格-正交表来安排试验并进行数据分析的方法。

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

2、正交实验法实现步骤
（1）确定因素
这里的因素指对原件运行结果有影响的软件
确定因素的取值范围或集合，因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源；要从多个角度和方式进行分析（不要放过文本框、按钮等需求中提及或没有提及）
（2）确定每个因素的水平
根据因素的取值范围或集合，采用等价类划分、边界值分析以及其他软件测试技术，在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试值
（3）选择正交表
根据确定的因素和水平，选择适合的正交表（只要特定的因素数和水平数的组合才有对应的正交表）；如果没有合适的正交表可用或需要的测试用例个数太多，要对因素和水平进行调整

• m是水平数，k是因素数，n是需要进行试验的行数。这三个数字之间没有任何数学关系
• 行数：正交表中的行的个数，即试验的次数，也是通过正交试验法设计的测试用例的个数
• 因素数：正交表中列的个数，即要测试的功能点
• 水平数：任何单个因素能够取得的值的最大个数，即要测试功能点的输入值
• 仅适合用于每一个因素的水平都相同的正交表
  正交表的种类：
  1）各列水平数均相同的正交表
  2）混合水平正交表
  正交表的特性：整齐可比、均衡分散

3、实际案例

完全排列组合：3×3×3=27
正交表设计助手：latin、blend
L9_3_4：3水平4因素，9次实验

每一列，同一个数字出现的次数相等（3次）
任意2列中，同一个数字对出现的次数相等（1次）

5.5.7 功能图法

1、功能图法原理
功能图法又叫做状态迁徙图。
来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时（软件的状态会根据某些内容、条件、操作的变化而变化），如何进行测试用例的设计就比较麻烦。
状态迁徙图的目标：设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖

2、功能图法步骤

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

3、案例：以QQ登录界面为例，说明功能的变迁

1）列出所有可能的事件
IP1：输入账号
IP2：输入密码
IP3：点击登录按钮
IP4：点击关闭按钮
2）定义QQ登录界面为“空闲”状态
3）给空闲状态加操作：第一轮分析后产生了新的状态

针对新的状态进行分析（第二轮）

得到一个新的状态，继续进行分析

虽然得到了一个全新的界面（状态），但是和空闲状态发生了“隔断”，因此将其视为空闲状态的结束，可以结束分析过程。
4）将状态变化过程列表化，准备设计测试用例

设计用例时：
①A列：从QQ的登录界面，直接点击关闭按钮，QQ登录退出
②D列：从QQ的登录界面，先输入QQ号（状态变为QQ号已输入）；再输入密码（状态变为QQ号、密码已输入）；点击登录，状态变为QQ主界面

5.5.8 其他用例设计方法

1、测试大纲法

一种着眼于需求的方法。为列出各种测试条件，将需求转化为大纲的形式（进行详细的需求分析，将其转化为思维导图–树形结构）。
无需用例设计，一般从根节点开始，到叶节点结束，这样的一条路径就是一条测试用例。
一般用于快速的测试和过程记录。用例一般进行后补

2、探索性测试法
基于测试人员经验和直觉的测试方法。
是计划内测试用例设计的补充。
探索性测试法执行前也需要设计测试用例

3、猴子测试（随意性测试）
一种没有书面测试用例（无意识的行为）、记录期望结果、检查列表、脚本或指令的测试。
缺点：

• 测试往往不太真实
• 不能达到一定的覆盖率
• 许多测试都是冗余的
• 需要使用同样的随机数才能重建测试

5.5.9 用例设计方法综合选择

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

总结：所有测试用例方法的使用，都不是独立的，往往在一个软件的页面中，需要好几个测试用例方法融合在一起使用。正交试验法是一种及其特殊的用例设计方法，一般没地方用

案例：教育APP
1、启动页面
需求：
1）读取版本更新信息：匹配当前APP与线上需要更新的APP版本是否一致
2）读取用户信息：未登录用户，则不用获取；已登录用户，验证是否登录过期

用例设计方法–场景法
设计场景：
①APP的安装版本比最新版低。启动就需进行版本检测，并进行提示
②APP的安装版本与最新版一样。默认检测成功
③APP启动检测用户登录状态，如果登录过期或未登录，启动完成后直接跳转登录界面
④APP启动检测用户登录状态，如果登录信息有效，启动完成后直接跳转首页界面

2、登录界面

需求：
1）手机号：只支持大陆手机
2）验证码：长度为6位数字
3）短信验证码文本内容：【正教】456712（正交验证码），30分钟内有效，为确保您账号安全，请勿将验证码告诉他人！
4）登录按钮点击后，系统可能的弹窗提示

用例设计方法–等价类划分法、边界值分析法、因果图法
等价类划分法：
①手机号的有效性（手机号包含各种不合法字符）
②验证码包含各种不符合需求的字符
边界值分析法：
①手机号超过/不足长度限制
②验证码超过/不足长度限制
③验证码有效期为30分钟，所以超过30分钟后使用验证码，就是边界值的使用
④弹窗提示1s消失，超过/不足的测试都是边界值的应用
因果图法：
①提交数据时，APP网络中断，有网络异常的提示
②提交数据时，服务端崩溃或者无法提高正常服务，有服务器报错提示或等待提示
③提交数据时，手机号不符合要求（不存在），有手机号错误的提示
④提交数据时，验证码输入不是收到的验证码、超时，有验证码错误提示

3、课程内容页面，需求如图所示：

用例设计方法：场景法、等价类划分法、边界值分析法
场景法：
①该课程今日有作业、有提问的内容展示。老师发布作业时，学生提问
②该课程今日有作业、无提问的内容展示。老师发布作业时，学生无提问
③该课程今日无作业、有提问的内容展示。老师没有发布作业时，学生提问
④该课程今日无作业、无提问的内容展示。老师没有发布作业时，学生无提问
等价类划分法、边界值分析法：
①日期的显示。有没有出现2017年2月有29的现象？
②日期的显示。有没有出现2017年2月1日和2017年1月31日重复或者相隔一天的现象？

6、缺陷

6、1 缺陷的基本概述

6.1.1 缺陷的定义?

软件未实现产品说明书要求的功能；
软件出现了产品说明书指明不应该出现的功能；
软件实现了产品说明书未提到的功能；
软件未实现产品说明书虽未明确提及但应该实现的目标；
软件难以理解、不易使用、运行缓慢或者最终用户会认为不好

6.1.2 缺陷的属性

6.1.2.1 缺陷的类型

缺陷类型时根据缺陷的自然属性划分的缺陷种类

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

6.1.2.2 缺陷的严重程度

缺陷的故障对软件的影响。

6.1.2.3 缺陷的修复优先级

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

面试：缺陷的严重程度和优先级有什么关系？
1）没有任何直接的关系
2）不要认为严重的缺陷，修复优先级就越高
3）若碰到优先级和严重程度都高的缺陷，也只是偶然。例如，QQ的帮助按钮，会有经常闪退现象，严重程度很高，但优先级很低

6.1.2.4 缺陷的状态

①激活/打开（新建）。由测试人员进行标注
②确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、质量保证（QA）、产品经理确认，经确认后，有效的缺陷会指派给相关人员进行处理
③已修复/修正。在缺陷被修复后，一般由开发人员进行
④关闭/非激活。缺陷被修完成后，经测试人员验证后无问题
⑤重新打开。经测试人员验证后缺陷没有修复成功，需要重新打开进行再次处理和修复
⑥推迟。缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或其他相关管理人员进行确认
⑦保留。缺陷暂时修复不了。一般由开发人员设定，也需测试人员进行确认
⑧不能重现。开发按照缺陷复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷育有类似特征；由于操作系统差异、浏览器缓存等信息出现的问题。作为测试人员，提交bug之前要再三确认bug
⑨需要更多信息。作为测试人员，提交bug时要尽可能把所有相关文件一起提交（图片、视频）
⑩重复。测试中，一定要避免类似情况出现。尤其在软件的某一个功能频繁被多个模块调用的情况下

6.1.2.5 缺陷的起源

6.1.2.6 缺陷的来源

直接原因

6.1.2.7 缺陷的根源

测试总结时关注缺陷的根源

6、2 缺陷的生命周期?

①发现缺陷：测试人员
②提交缺陷：测试人员
③确认缺陷：测试主管、质量保证（QA）、产品经理确认
④分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理，一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、UI、产品经理
⑤修复缺陷：主要由开发（代码）修复，也有可能是产品经理（需求）修复问题，也有可能是UI（界面）修复
⑥验证缺陷：测试人员验证缺陷是否修复成功
⑦关闭缺陷：只能是测试人员进行

面试提问：针对你工作中发现的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么）

6、3 缺陷的识别

客观依据：需求文档、设计文档、产品原型、测试用例
主观依据：同行业的类似成熟软件、和开发人员沟通、和有经验的测试人员沟通、同行业隐性需求

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

6、4 缺陷报告

6.4.1 缺陷报告编写目的

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

预期读者：开发人员、质量管理人员、市场人员、运维人员

6.4.2 缺陷报告编写准则

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

6.4.3 缺陷描述的准则

• 单一准确
• 可以再现：针对绝大多数缺陷都是如此，但小部分缺陷难以做到（闪退、崩溃这种不可再现的缺陷，无法做到。针对一些可以重复出现的闪退缺陷，也要进行步骤的详细描述）
• 完整统一
• 短小简练
• 特定条件
• 补充完善
• 不做评价：不对缺陷出现的严重程度和缺陷表现出来的效果进行主观臆断

6.4.4 缺陷报告模板

1）缺陷编号。Bug_项目名称_模块名称_功能名称_0001
2）所属模块。一级模块/二级模块/三级模块
3）优先级。缺陷修复的紧急程度。P1＞P2＞P3＞P4
4）严重程度。S1＞S2＞S3＞S4
5）缺陷概述。用一句话描述缺陷的基本情况

6）缺陷描述。将缺陷的复现步骤、实际结果、预期结果列出

7）提交人。
8）备注。一般写产生改缺陷的特殊情况；bug截图

6.4.5 缺陷跟踪系统

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

6.4.6 测试需求和测试用例、缺陷报告的关系

测试的基本流程：
获取测试需求–>编写测试计划–>制定测试方案–>开发与设计测试用例–>执行测试–>提交缺陷报告–>测试分析与评审–>提交测试总结–>准备下一版本测试

获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：
1）分析出系统的模块和组织结构
2）分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者角色要用
3）识别出软件的重要功能和次要功能
获取测试需求的过程中，测试人员要有相应的分析成果，一般用Xmind思维导图工具进行分析，或使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试中需求的正、反向和优先级

当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计，即每一个需求点都要被测试。因此，测试过程中，衡量需求的覆盖程度就非常重要，使用：
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数
进行计算和说明。如果需求覆盖度＜100%，那一定说明了测试的覆盖度不够。

测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
1）设计的测试用例总量 TC
2）执行的测试用例数量 EC
3）未执行的测试用例数量 WC
4）执行通过的测试用例总量 SC
5）执行失败的测试用例总量 FC
6）提交的缺陷的总量 BC
以上六个数据，要符合如下数量关系：
1）TC≥EC
2）TC=EC+WC
3）EC=SC+FC
4）BC≥FC 一条测试用例的预期结果数量是固定的（甚至是唯一的）。测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的
5）通过SC/EC 可以表现出系统的质量是否合格
6）通过EC/TC 可以表现出系统的需求是否得到满足