软件缺陷的定义

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

软件测试的目的

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

测试和调试的区别

软件的生命周期模型

需求分析（需求规格说明书）—->概要设计（架构文档）——>详细设计（详设文档）——–>编码（源代码）———>测试（测试报告）——->验收（产品）

瀑布模型

快速原型

增量模型

迭代模型

优点：

• 降低了在一个增量上的开支风险；
• 降低了产品无法按照既定既定进度进入市场的风险；
• 加快了整个开发工作的进度；
• 迭代过程这种模式使适应需求的变化更容易些。

螺旋模型

软件测试流程

1. 获取测试需求；
2. 编写测试用例；
3. 制定测试用例；
4. 开发与设计测试用例；
5. 执行测试；
6. 提交缺陷报告；
7. 测试分析与评审；
8. 提交测试报告；
9. 准备下一版本测试；

软件测试过程模型

V模型

揭示了开发和测试过程中各个阶段的对应关系；
缺点和不足：
1. v模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证；
2. 需求的满足情况一直到后期的验收测试才被验证；

H模型

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

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

软件测试的分类

1.按照开发阶段划分

1. 单元测试
   又称模块测试 ，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作，其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。各个模块可以平行地独立进行单元测试。

2. 集成测试
   又称组装测试。通常在单元测试的基础上将所有的程序模块进行有序的、递增测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

3. 确认测试(冒烟测试 )
   功能是否实现。一般都是正向测试。一般不作为 正式的测试环节或者测试阶段。

4. 系统测试
   全面的，系统所有功能的测试，模拟所有的软件用户的操作；全方位的；和硬件系统的联系；和系统软件的联系；和其它软件的关系；

5. 验收测试
   一般供求双方。一般有三种验收测试主体：①α 测试：软件的开发商自己进行的交付测试；②β 测试： 软件的需求方自己进行的测试；③ γ 测试：第三方的软件测试。

2.按照测试技术划分

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

3.按照代码运行划分

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

4.按照软件特性划分

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

5. 其它测试类型

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

测试用例

• 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果；

测试用例包括

• 测试用例编号： 一般编号规则：TestCase_项目名称_模块_名称_功能名称_0001；
• 测试项： 测试用例的测试目的（一般保证一个测试目的）。一般用一句话表明目的。
• 依赖用例：（前置条件） 一般功能流程上，下游的功能测试依赖于上游的功能测试的用例；
• 测试步骤： 简洁易懂、尽量详细的描述操作步骤。
• 输入数据：
• 预期结果：
• 测试结果：在测试执行后添加，没有执行则保持为空。测试结果只有两个：Pass 和 Failed。
• 测试人：
• 备注：

用例按照测试分类

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

测试用例设计和编写的作用

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

黑盒测试用例设计方法

• 测试数据选择
  – 等价类划分法
  – 边界值分析法
• 测试步骤设计
  – 因果图法
  – 判定表法
  – 正交实验法
  – 功能图法
  – 场景法

1. 等价类划分法

等价类划分的原则：

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

2. 边界值分析法

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

常见问题：
6 <= x <= 12， x的边界值要选哪几个——– 5，6， 7， 11， 12， 13
6 < x < 12， x的边界值要选哪几个———6，7，8， 10， 11， 12

3.因果图法

• 一种适合于描述对于多种输入条件组合的测试方法；
• 根据输入条件的组合、约束条件和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法；
• 它适合于检查程序输入条件涉及的各种组合情况；
  
  
  （2）确定原因与结果的逻辑关系

  （3）确定因果图中的约束

  （4）画出因果图并转化为决策表
  

  
  简化版
  4、规则及规则合并

  1)规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
  2)化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。
  

  
  s2：根据化简规则对判定表进行化简：
  只要觉得疲惫，那么其他两项就不再考虑，直接休息，所以上图1~4可以简化合并成一条
  不疲惫且感兴趣时，无论是否糊涂，都直接休息，简化以后的测试用例如下：
  
  场景法的基本设计步骤：
  1、根据说明，描述出程序的基本流及各项备选流
  2、根据基本流和各备选流生成不同的场景
  3、对每一个场景生成相应的测试用例

6.正交试验法

正交表是一种特制的表格，一般用Ln(mk)表示，L代表是正交表，n代表试验次数或正交表的行数，k代表最多可安排影响指标因素的个数或正交表的列数，m表示每个因素水平数，且有n=k*(m-1)+1。

（1）因素（Factors）。表示在一项试验中，需要观察的变量称为因素。

（2）水平位（（Levels）。表示在试验范围内，因素被考察的值称为水平位（变量的取值）

（3）正交表的组成。由行数（正交表的行的个数，即试验的次数）、因素数（正交表列的个数）、水平数（任何单个因素能够取得的值得最大个数）。

正交表必须满足这两个特点，有一条不满足，就不是正交表。
1、每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的，从而保证了在各个水平中最大限度地排除了其它因素水平的干扰，能有效地比较试验结果并找出最优的试验条件。
2、在任意2列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中，因此具有很强的代表性。

使用 ” 正交设计小助手 ” 来设计正交表

7.功能图法

• 功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置（或时间）,而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.
  步骤：
• 1.识别和列举所有的输入（操作）事件。以IP N(input)（N= 1，2，3）
• 2.定义空闲状态（初始状态）。一般以软件刚启动时打开的界面状态为” 空闲 “ 状态
• 3.为空闲状态加操作（只加一次）
• 4.为第3)步所产生的新状态加操作（只加一次，并且曾经加过的操作，不再重复添加）
• 5.循环为所有的新增状态加操作，直到没有新状态产生为止
• 6.组合任意的状态，以列表的形式展现，设计和编写测试用例。

8.其他用例设计方法

1. 测试大纲法：一种着眼于需求的方法，进行详细的需求分析，将其转化为思维导图(树形结构)。无需用例设计，一般从根节点开始分析，到叶节点为止，这样一条路径即为一条测试用例。
2. 探索性测试法： 基于经验和直觉，是计划内测试用例设计的补充。探索性测试在测试前也需要设计测试用例。
3. 猴子测试： 随意测试。无测试用例。缺点： 测试往往不太真实、不能达到一定的覆盖率、重现度难。

用例设计方法的选择

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

缺陷的基本概述

缺陷的属性：

• 缺陷的类型： 根据缺陷的自然属性划分缺陷的种类；（功能、用户界面、文档、软件包、性能、系统/模块接口）
• 缺陷的严重程度： 指因缺陷引起的故障对软件产品的影响程度；（致命、严重、一般、较小）
• 缺陷的优先级： 指缺陷必须被修复的紧急程度；（立刻解决、高优先级、正常排队、低优先级，P1-P4）
• 缺陷状态： 指缺陷通过一个跟踪修复过程的进展情况；（激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息、重复、不是缺陷、需要修正软件规格说明书）
• 缺陷起源： 指缺陷引起的故障或事件第一次被检测到的阶段；（需求、构架、设计、编码、测试、用户）
• 缺陷来源： 指缺陷的起因；（需求说明书、设计文档、系统集成接口、数据流/库、程序代码）
• 缺陷根源： 指发生错误的根本原因；（测试策略、过程，工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境）

严重程度和优先级没有直接的关系！！！！

缺陷的生命周期

缺陷的识别

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

缺陷报告

来源：这把稳赢