软件测试基础

TIP：

A:掌握，知识理解无偏差，熟练应用

B:理解，可以讲出来

C:了解，了解相关知识

目录

• 软件测试基础
  • 1. 软件缺陷的定义(C)
  • 2. 软件测试的目的（C）
  • 3. 软件生命周期（B）
    • 3.1 开发模型（C）
      • 3.1.1 边做边改模型（Build-and-Fix Model）：
      • 3.1.2 瀑布模型（Waterfall Model）
      • 3.1.3 快速原型模型（Rapid Prototype Model）
      • 3.1.4 增量模型（Incremental Model）
      • 3.1.5 螺旋模型（Spiral Model）
      • 3.1.6 演化模型(evolution model)
      • 3.1.7 喷泉模型(fountain model)
      • 3.1.8 智能模型(四代技术（4GL）)
      • 3.1.9 混合模型（hybrid model）
      • 3.1.10 RAD模型
  • 4. 软件的测试原则（C）
  • 5. 软件测试流程（B）
    • 5.1 软件测试常见模型（C）
      • 5.1.1 V模型
      • 5.1.2 W模型（B）
      • 5.1.3 H模型
      • 5.1.4 X模型
  • 6. 软件测试分类（B）
    • 6.1 按照开发阶段划分
    • 6.2 按照代码运行划分
    • 6.3 按照软件特性划分
    • 6.4 按照测试技术划分
    • 6.5 按照测试主体划分
    • 6.6 其他测试
  • 7. 测试用例（A）
    • 7.1 测试用例的属性
    • 7.2 测试用例的设计方法
      • 7.2.1 等价类
      • 7.2.2 边界值
      • 7.2.3 判定表
      • 7.2.4 因果图
      • 7.2.5 正交表
      • 7.2.6 状态迁移
      • 7.2.7 其他方法（C）
    • 7.3 测试用例设计的原则（C）
  • 8. 缺陷（A）
    • 8.1 缺陷属性
    • 8.2 缺陷类型
    • 8.3 缺陷的划分
      • 8.3.1 优先级
      • 8.3.2 严重程度
    • 8.3 缺陷的生命周期
  • 9.其他相关

1. 软件缺陷的定义(C)

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

TIP：

所有不满足需求或超出需求的都是缺陷

没有不存在缺陷的软件，只有迄今为止尚未被发现的缺陷

2. 软件测试的目的（C）

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

3. 软件生命周期（B）

3.1 开发模型（C）

3.1.1 边做边改模型（Build-and-Fix Model）：

3.1.2 瀑布模型（Waterfall Model）

3.1.3 快速原型模型（Rapid Prototype Model）

3.1.4 增量模型（Incremental Model）

3.1.5 螺旋模型（Spiral Model）

3.1.6 演化模型(evolution model)

3.1.7 喷泉模型(fountain model)

3.1.8 智能模型(四代技术（4GL）)

3.1.9 混合模型（hybrid model）

3.1.10 RAD模型

参考资料：软件开发模型

4. 软件的测试原则（C）

• 所有测试的标准都是建立在用户需求之上
• 软件测试必须基于“质量第一”的思想去展开各项工作。当时间和质量冲突时，时间要服从质量
• 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估
• 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试
• 穷举测试是不可能的
• 第三方进行测试会更客观，更有效
• 软件测试计划是做好软件测试工作的前提
• 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试效率，更多的发现错误，提高程序的可靠性

5. 软件测试流程（B）

需求测试--单元测试--集成测试--系统测试--验收测试--alpha测试-（内）--beta测试（外）--UAT测试（用户接受度）--回归测试

5.1 软件测试常见模型（C）

5.1.1 V模型

需求规格说明书（SRS）-->概要设计（HLD:high level design） -->详细设计（LLD:low level design 伪码）--> 编码（Coding）

优点：

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

局限性：

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

5.1.2 W模型（B）

优点：

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

局限性：

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

5.1.3 H模型

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

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

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

5.1.4 X模型

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

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

6. 软件测试分类（B）

6.1 按照开发阶段划分

单元测试（模块测试）

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

单元测试一般要读程序和代码，大多数时候，都是由开发人员自己去完成（交叉，但是一般又不认为是在做测试），测试人员为什么不做单元测试？（大家不懂代码和算法）

集成测试（组装测试）

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

比较多的涉及到接口测试（接口测试工具和方法专门学习）

确认测试（有效性测试、冒烟测试）

确认测试也叫有效性测试。是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试后的软件，才具备了进入系统测试的资质

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

系统测试

系统测试是在真实的系统运行的环境下，检查完整的程序系统是否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确的配置、连接，并最终满足用户的所有需求

验收测试

是软件产品检验的最后一个环节。按照项目任务书或合同、仅需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

供求双方，一般有三种验收测试的主体：

α测试：软件开发商交付前自己进行的测试

β测试：软件需求方自己进行的测试

γ测试：第三方的软件测试

6.2 按照代码运行划分

静态测试：指不实际运行被测对象，而只是静态的检验程序代码、界面或文档中可能存在错误的过程

代码测试：主要测试代码是否符合相应的标准和规范

界面测试：主要测试软件的实际界面与需求中的说明是否相符

文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求

动态测试：指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准是看是否运行程序

6.3 按照软件特性划分

功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求

性能测试：功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常

软件的性能包括很多方面，主要有时间性能和空间性能两种

安全性测试：验证安装在系统内的保护机制是否能在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素干扰

逻辑功能测试

界面测试

易用性测试

安装/卸载测试

兼容性测试

6.4 按照测试技术划分

黑盒测试

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

白盒测试

通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装载一个透明的盒子里，检查是否所有的结构及路径都是正确的，检测软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试

灰盒测试

介于白盒测试和黑盒测试之间的测试。灰盒测试关注输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些象征性的现象、事件、标志来判断内部的运行状态

6.5 按照测试主体划分

手工测试（功能测试）：点点点

自动化测试：利用工具软件或是编写代码的方式测试被测的软件系统

6.6 其他测试

回归测试

是指对软件的新版本测试时，重复执行之前某一个重要版本所有测试用例

目的：

1. 验证之前版本产生的所有缺陷已全部被修复

2. 确认修复这些缺陷没有引发新的缺陷

冒烟测试

是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，也叫可测性测试

随机测试

是指测试人员基于经验和直觉的测试，发现一些边缘性的错误

猴子测试

把自己当成不懂产品的小动物，随便乱点，没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果

7. 测试用例（A）

7.1 测试用例的属性

用例编号、用例标题、所属模块、测试等级、预置条件、测试数据、操作步骤、预期结果、编写人员、编写时间、用例类型、备注、测试环境

测试用例示例

7.2 测试用例的设计方法

等价类、边界值、判定表、因果图、正交表、场景图（流程图法）、错误猜测法、状态迁移。

7.2.1 等价类

穷举（不可取）-->等价类（有效数据和无效数据）

取值规范：

当我的输入或者输出是一定范围的时候，取一个有效和两个无效的

当我的输入或者输出是布尔值的时候，取一个有效和一个无效

当我的输入或者输出是集合的时候，取一个有效和一个无效

当我的输入或者输出是一定规则的时候，取一个有效和n个无效

当我的输入或者输出是不同条件得到不同结果的时候，进行细分

设计用例思路

1. 给需求进行分类

2. 每个分类找出有效和无效

3. 给有效和无效进行编号

4. 设计一条用例,使其尽可能覆盖所有的有效编号

   再设计一条用例,使其尽可能覆盖所有剩下的的有效编号

   ...

5. 设计用例,一个无效写一条用例,确保其他数据有效

   再设计用例,一个无效写一条用例,确保其他数据有效

   ...

7.2.2 边界值

等价类的补充,补充等价类中,可度量的情况下,用边界值用例设计方法

取点 y=4x+1 健壮性高低

7.2.3 判定表

当你的需求是不同条件组合,得到不同结果的时候,并且这里的每个条件取值是只有两种的情况下

设计用例思路

1.从需求里面提取出条件桩

2.画出条件项.2ⁿ

3.从需求里面提取出动作桩

4.根据需求填写动作项

5.合并

6.写测试用例,一种情况一条用例

7.2.4 因果图

7.2.5 正交表

当你的需求是不同条件组合,得到不同结果的时候,并且这里的每个条件取值可能大于等于1，可以使用正交，减少测试用例

7.2.6 状态迁移

7.2.7 其他方法（C）

场景图、错误猜测、输入域、输出域

7.3 测试用例设计的原则（C）

• 测试用例对需求覆盖的完整性
• 测试用例的有效性
• 测试用例的可理解性
• 测试用例的清晰性
• 测试用例的可维护性

8. 缺陷（A）

8.1 缺陷属性

8.2 缺陷类型

遗漏、错误、额外实现、改进

8.3 缺陷的划分

8.3.1 优先级

8.3.2 严重程度

8.3 缺陷的生命周期

9.其他相关

流程管理平台：禅道、Bitnami Redmine Stack Manager Tool

正交表、评审、正规检视

测试基础知识整理