软件测试 _ 基础知识

软件缺陷的定义

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

软件测试的目的

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

测试和调试的区别

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

软件的生命周期模型

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

瀑布模型

**最早提出的软件开发的过程模型**
存在的问题：
 - 强调时间顺序的严格执行，前一阶段不完成，后阶段不开始；
 - 将测试放在编码之后。没有体现出测试贯穿整个软件生命周期的原则。可以避免需求的问题一直延续到代码完成才暴露或者被发现。
 - 瀑布模型不适应用户需求的变化；
优点：
 - 为项目提供了按阶段划分的检查点；
 - 当前一阶段完成后，只需要去关注后续阶段；

快速原型

增量模型

：把软件分割成独立的模型，分批次的完成和交付。
缺点：打破原有的软件结构和框架，可能带来一定的风险。
增量模型一般和迭代模型一起运用。

迭代模型

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

优点：

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

螺旋模型

引入了其它模型不具备的风险分析，更适合大型的昂贵的系统级的软件应用；

软件测试流程

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

软件测试过程模型

V模型      W模型     H模型     X模型

V模型

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

W模型

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

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

缺点：

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

H模型

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

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

X模型

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

软件测试的分类

	单元测试	集成测试	确认测试	系统测试	验收测试
测试技术	黑盒、白盒	黑盒、白盒、灰盒	黑盒、白盒	黑盒、白盒	黑盒、白盒
代码运行	动态、静态	动态、静态	动态、静态	动态、静态	动态、静态
软件特性	功能、性能、安全	功能、性能、安全	功能 、性能、安全	功能、性能、安全	功能、性能、安全
其它测试			冒烟测试	回归测试	随机测试
测试手段	手工、自动化

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.因果图法

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

因果图实例分析

**产品说明书：**有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。
（1）确定需求中的原因与结果

（2）确定原因与结果的逻辑关系

     C1 与 C2 需要一个中间结果Cm1, C3、C4、C5 需要一个中间结果Cm2.

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

     C1 与 C2 是或的关系, C3、C4、C5 是或的关系。

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

决策表

将原因C1、C2、C3、C4、C5按二进制由小到大分别取值，并分析中间结果的成立与否，进而得出下面的简化版（即中间结果Cm1、Cm2成立的情况）
简化版
（5）根据决策表设计测试用例

4.判定表法

1.定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

2.判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

使用条件： 所有的条件桩在表中的位置和顺序互相不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同。

3、判定表有几个要素：
1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
4、规则及规则合并

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

5、判定表设计法举例：

书籍阅读指南中有以下建议：
如果觉得疲倦并且对书的内容感兴趣，不糊涂的话，回到本章重读
如果觉得疲倦并且对书的内容感兴趣，但糊涂的话，继续读下去
如果不觉得疲倦并且对书的内容感兴趣，但糊涂的话，回到本章重读
如果觉得疲倦并且对书的内容不感兴趣，但不糊涂，跳到下一章去阅读
如果觉得疲倦并且对书的内容不感兴趣，但糊涂的话，请停止阅读，休息
不疲倦，对书的内容感兴趣，书中的内容不糊涂，继续读下去
不疲倦，不感兴趣，书中内容糊涂，跳到下一章去读
不疲倦，不感兴趣，书中内容不糊涂，跳到下一章去读
s1：根据需求将条件桩、条件项、动作桩、动作项分别列出来

s2：根据化简规则对判定表进行化简：
只要觉得疲惫，那么其他两项就不再考虑，直接休息，所以上图1~4可以简化合并成一条
不疲惫且感兴趣时，无论是否糊涂，都直接休息，简化以后的测试用例如下：

5.场景法

• 现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时的场景，有利于设计测试用例，同时使测试用例更容易理解和执行。
• 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
• 备选流： 除基本流之外的各支流，包含多种不同的情况。
  场景法的基本设计步骤：
  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）
• 缺陷状态： 指缺陷通过一个跟踪修复过程的进展情况；（激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息、重复、不是缺陷、需要修正软件规格说明书）
• 缺陷起源： 指缺陷引起的故障或事件第一次被检测到的阶段；（需求、构架、设计、编码、测试、用户）
• 缺陷来源： 指缺陷的起因；（需求说明书、设计文档、系统集成接口、数据流/库、程序代码）
• 缺陷根源： 指发生错误的根本原因；（测试策略、过程，工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境）

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

缺陷的生命周期

缺陷的识别

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

缺陷报告

缺陷编号	所属模块	优先级	严重程度	缺陷概述	缺陷描述	提交人	备注
	一级模块/二级模块、三级模块	p1-p4	s1-s4	一句话描述基本情况	复现步骤、预期结果、实际结果		bug截图