测试理论

一测试定义及原则

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模型步骤，反复执行，返工量很大，灵活度较低。改良：每个步骤都可以进行小的迭代工作。