软件测试理论

测试理论

一 测试定义及原则

1 软件定义

一些列按着特定顺序组织的计算机数据和指令的集合：

软件 = 数据 + 指令 + 文档

2 软件分类

• 工具类软件
• 游戏类软件
• 电商类软件
• 社交类软件
• 教育类软件等

3. 软件架构分类

• 单机软件： office、红警等
• 分布式软件

  • C/S 架构

    C指的是客户端软件（Client），S指的服务器端软件（Server）

  • B/S 架构

    B指的是浏览器（Brower）, S指的是服务器端软件（Server），B/S模式，是Web兴起后的一种网络结构模式。Web浏览器（Brower）是客户端最主要的应用软件。这一种模式统一了客户端，将系统功能实现的核心部分集中在服务器上，简化了系统的开发、运维和使用。客户机上秩序只需安装一个浏览器，服务器上安装SQL Server，Oracle或Mysql等数据库；浏览器通过Web Server同数据库进行交互。

4. 软件测试的定义

通过人工或者自动化的方式来验证软件的实际结果与用户需求是否一致的过程

5. 软件测试的原则

• 原则一： 测试显示软件存在缺陷

  测试只能证明软件存在缺陷，但不能证明软件不存在缺陷。软件测试是为了降低软件存在缺陷的可能性，即便没有找到缺陷，也不能证明软件是完美的。

• 原则二：穷尽测试是不可能的

  现在的软件规模越来越大，复杂性越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以依据风险和优先级来进行集中和高强度的测试，从而保证软件的质量

• 原则三：测试今早介入

  为什么测试要尽早介入呢？简单的说是保证软件的质量，降低风险和成本。测试人员一般从需求阶段开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复成本越小。

• 原则四：测试集群性（2/8原则）

  缺陷集群性表明小部分模块包括大部分缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。

  一个功能模块发现缺陷率越高，那存在的未发现的缺陷概率也越高，故发现缺陷和未发现缺陷成正比。

• 原则五：杀虫剂悖论

  反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫，软件测试也一样。如果一直使用相同的测试方法和手段，可能无法发现新的bug。

  为了解决这个问题，测试用例应该定期修订和评审，增加新的或者不同的测试用例帮助发现更多的缺陷。

  测试人员不能一直依赖现有的测试技术，而要不断的提升测试方法以提高测试效率。

• 原则六：测试活动依赖测试内容

  根据业务的不同，软件测试内容也分不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展也有不同，比如测试技术、测试工具的选择、测试流程不仅相同，所以软件测试的活动开展依赖于所测试的内容。

• 原则七：没有错误是好，是谬论

  有可能99.9%没有bug的软件也是不能使用的。如果对错误的需求进行测试的测试，这种情况发生了。软件测试不仅找不出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品满足不了用户的需求，即便找到和修复了缺陷也作用不大。

二 测试模型

2.1 开发模型

2.1.1 瀑布模型

瀑布模型是一个经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里，在项目生命周期的尽早时间，要确定项目范围及交付此范围所需的时间和成本。瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品

• 特点：是线性模型的一种，每一个阶段只执行一次
• 优点：开发的各个阶段比较清晰，当前阶段完成后，只需关注后续阶段；有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率****。可在迭代模型中应用瀑布模型
• 缺点：很难清楚地给出所有的需求，不能响应需求的变化，风险往往在后期才显露；各阶段划分比较固定，阶段之间会产生大量文档，增大工作量。

2.1.2 原型模型

在需求分析阶段对软件的需求进行初步而非完全的分析和定义，用户与开发者在过程中加强反馈，快速设计开发出软件系统可以实际运行的模型；用户在运行使用整个原型的基础上，通过对其评价，提出改进意见，对原型进行修改，统一使用，评价过程反复进行，使原型逐步完善，直到完全满足用户的需求为止。

原型还分为两类：

• 抛弃型原型，此类原型在系统真正实现以后就抛弃不用了
• 进化型原型，此类原型的构造从目标系统的一个或多个基本需求出发，通过修改和追加的过程逐渐丰富，演化成为最终的系统

• 特点：

  实际可行；具有最终系统的基本特征；构造方便、快速、造价低。

• 优点：增加用户与开发人员的交流；用户在项目开发中占主导作用；满足用户的动态需求；降低开发风险。

• 缺点：因为用户的参与，使得忽视原型对实际环境的适应性等技术问题，所以不适合大型、复杂项目开发；对于技术层面远大于其分析层面的问题不宜使用原型法。

2.1.3 增量模型

增量模型是把待开发的软件系统模块化，第1个增量往往是产品的核心，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

• 特点：最大特点就是将待开发的软件系统模块化和组件化；增量模型是瀑布模型和原型进化模型的综合；如同原型进化模型一样，增量模型逐步地向用户交付软件产品，但不同于原型进化模型的是，增量模型在开发过程中所交付的不是完整的新版软件，而只是新增加的构件。
• 优点：将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展；以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统；开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
• 缺点：待开发的软件系统可以被模块化，如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦；对项目管理人员管理全局水平有较高要求；对开发人员也有要求。

2.1.4 敏捷模型

先选择产品，再进行开会、对产品计划，然后对任务进行分工，分工后开始按照计划执行，然后就做出了新的功能模块，然后再进行演示、回顾，最后再领取新的任务，依次循环。

• 特点：适应变化，注重反馈，灵活性强，快速迭代；适用于需求不明确，期限紧迫；
• 优点：频繁交货；与客户面对面的交流；高效的设计并满足业务需求；随时可以接受更改；它减少了总的开发时间。
• 缺点：由于缺少正式文件, 因此会造成混乱, 并且各个团队成员随时可能会误解贯穿各个阶段做出的重要决定；由于缺乏适当的文档, 一旦项目完成并且开发人员被分配到另一个项目, 完成的项目的维护就会变得很困难。

2.2 测试模型

2.2.1 V模型

• 优点：
  • 包含了底层测试（单元测试）和高层测试（系统测试）；
  • 清楚的标识了开发和测试的各个阶段；
  • 自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
• 缺点：
  • 自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；
  • 实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。改良：每个步骤都可以进行小的迭代工作。

2.2.2 W模型

定义：开发一个v；测试一个v组合起来的模型（w模型也叫双v模型）

• 优点：
  • 开发伴随着整个开发周期，需求和设计同样要测试；
  • 更早的介入测试，可以发现初期的缺陷，修复成本低；
  • 分阶段工作，方便项目整体管理。
• 缺点：
  • 开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
  • 如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高.

三 软件测试的流程

四 测试分类

4.1 按技术分类

• 黑盒测试: 把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
• 白盒测试: 是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法
• 灰盒测试: 一种基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法

4.2 按阶段分类

• 单元测试：对一个模块、一个函数或者一个类来进行正确性检验的测试方法；
• 集成测试：单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的测试方法；
• 系统测试：集成测试后，将硬件、软件看作一个整体,对系统的功能及性能的总体测试；
• 验收测试：系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法。

4.3 按内容分类

4.3.1 功能测试

• 功能测试：根据产品操作描述和需求文档，测试一个产品的特性和可操作行为是否满足用户需求的测试方法
• 界面测试：测试用户界面的功能模块的布局是否符合客户使用习惯，界面操作便捷性、导航简单易懂性的测试
• 冒烟测试：验证系统的核心功能是否能够正常运行的测试方法
• 回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的测试方法
• 业务逻辑测试：在基本的功能点都已合格的基础上，准备多种测试数据，来驱动各种约束条件下业务流程，确定最终输出的结果是否符合预期的测试
• 易用性测试：指用户使用软件时是否感觉方便的测试

4.3.2 性能测试：

• 性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行校验的测试方法
• 压力测试：通过逐步增加系统负载，测试系统性能的变化，并确定在什么条件下系统性能处于失效状态
• 负载测试：通过逐步增加系统负载，测试系统性能的变化，在满足性能指标的情况下，系统所能承受的最大负载量的测试
• 并发测试：是一个负载测试和压力测试的过程，即逐渐增加并发用户数负载直到系统的瓶颈，通过分析资源监控指标等来确定系统并发性能

4.3.3 兼容性测试：

• app
  • Android/IOS版本
  • 厂商
  • 型号
  • 分辨率
  • 屏幕：全屏、水滴屏、刘海屏、曲面屏、折叠屏、双面屏
• web
  • 浏览器：四类，根据浏览器内核（78）

4.4 其他分类

• 随机测试：随机测试主要是根据测试者的经验无需测试用例对软件进行功能和性能抽查的测试方法；
• 安全性测试：通过不同的测试方法，检验程序、网络、数据库安全性的测试方法；
• 探索性测试：碰到问题时能随机应变，强调测试人员的主观能动性明确整体的测试计划的测试方法
• Alpha测试：俗称内测，α测试。内部环境下的测试；开发人员或测试人员在现场
• Beta测试：俗称外测、公测，β测试。生产环境下的测试；开发人员和测试人员都不在现场

五 测试分析及用例设计

5.1 用例分析方法

5.1.1 质量模型分析法

针对每个功能使用软件质量模型进行分析，分析应测特性，确认各功能的测试点以及测试项；

5.1.2 功能交互分析法

针对不同的功能确认各功能之间的交互操作，分析各功能交互时的测试特性，测试注意点，确认测试项；

5.1.3 用户场景分析法

针对所有功能，站在用户的角度考虑用户会怎么操作和使用这个功能，分析确认测试点以及测试项；

用例设计方法

5.2 测试用例的格式

用例编号	测试项	测试标题	用例属性	重要级别	预置条件	测试输入	操作步骤	预期结果	实际结果
				高中低

5.3 用例设计方法

5.3.1 等价类

1. 等价类定义

2. 等价类划分

3. 等价类划分规则

4. 进行等价类用例设计

5. 案例

5.3.2 边界值

1. 边界值的三个点

2. 边界值应用场景

3. 边界值的应用步骤

5.3.3 判定表

1. 判定表定义

2. 重要概念

3. 判定表应用步骤

4. 案例

5.3.4 因果图

1. 输入与输入的关系

2. 输入与输出的关系

3. 案例

5.3.5 正交试验

1. 因子和水平的定义

2. 特点

3. 设计流程

4. 注意点

5. 案例

5.3.6 状态转移

1. 定义

2. 状态

3. 状态流程

4. 案例

5.3.7 流程分析法（场景分析法）

1. 设计三个流程

2. 使用方法

3. 注意点

4. 案例