测试基础理论

1，软件的定义

软件 = 数据 + 指令 +文档

软件就是一系列按照特定顺序排列的数据和指令的合集

2，软件的分类

2.1 按照应用场景分类

工具类 ，金融类，娱乐类，教育类等等

2.2，按照软件架构分类

单机版软件：例如office  红警，

分布式软件：C/S架构分布：

                      B/S架构分布

3，软件测试的定义

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

4，软件测试的原则

一，显示软件中存在的缺陷

       1.1 测试只能证明软件中存在缺陷，并不能证明软件中不存在缺陷，，软件测试是为了降低软件中存在缺陷的可能性，就算没有找到缺陷，也不能证明软件是完美的。

二， 穷尽测试是不可能的

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

三，缺陷集群性（28原则）

        1.3，就是%80的缺陷出现在%20的程序模块中，缺陷集群性表明小部分模块包含大部分的缺陷

四，测试尽早介入

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

五，杀虫剂悖论

        1.5，反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用                  同的测试方法或手段，可能无法发现新的bug。解决这个问题，测试用例应当定期修订和评审，增加新                    的或不同的测试用例帮助发现更多的缺陷。

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

六，测试活动依赖于测试内容

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

七，没有错误是好还是谬论？？？？？

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

八，程序员应该避免检查自己的程序

1.3 开发与测试模型的介绍

1.3.1 开发模型

瀑布模型：

引入：做饭最终不能返回

定义：将软件生命周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品的项目。

瀑布模型.jpg

优点：

为项目提供了按阶段划分的检查点

当前一阶段完成后，只需要去关注后续阶段。

缺点：

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

瀑布模型的突出缺点是不适应用户需求的变化。

快速原型模型：在需求分析阶段对软件的需求进行初步而非完全的分析和定义，用户与开发者在过程中加强反馈，快速设计开发出软件系统可以运行的模型；

增量模型：把待开发的软件系统模块化，第1个增量往往是产品的核心，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件；

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

1.3.2 测试模型

V模型：

V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

V模型.优点，不仅包含了底层测试，还包含了高层测试

            缺点：当需求发生变更时，返工量非常大，，模型不够灵活

W模型：

相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

W模型.jpg

1.4 软件测试的流程

阶段名工作内容产出物

测试准备阶段项目立项、需求分析、需求评审需求文档、产品PRD

测试计划阶段编写测试计划、计划评审测试计划

测试设计阶段提取测试点、编写测试用例、用例评审测试用例

测试执行阶段冒烟测试、执行测试用例、提bug、回归测试缺陷报告

测试完成阶段验收测试、编写测试报告、项目上线测试报告

image.png

1.5 软件测试的分类

image.png

1.5.1 按技术划分

黑盒测试、白盒测试、灰盒测试

黑盒测试(Black Box -Test)：把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果

白盒测试：是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法

灰盒测试：一种基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法

1.5.2 按阶段划分

单元测试、集成测试、系统测试、验收测试

单元测试：对一个模块、一个函数或者一个类来进行正确性检验的测试方法

集成测试：单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的测试方法

系统测试：集成测试后，将硬件、软件看作一个整体,对系统的功能及性能的总体测试

验收测试：系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法

1.5.3 按内容划分

功能测试、性能测试、兼容性测试

3.1  功能测试：

界面测试、冒烟测试、回归测试、业务逻辑测试、易用性测试

功能测试：根据产品操作描述和需求文档，测试一个产品的特性和可操作行为是否满足用户需求的测试方法

界面测试：测试用户界面的功能模块的布局是否符合客户使用习惯，界面操作便捷性、导航简单易懂性的测试

冒烟测试：验证系统的核心功能是否能够正常运行的测试方法

回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的测试方法

业务逻辑测试：在基本的功能点都已合格的基础上，准备多种测试数据，来驱动各种约束条件下业务流程，确定最终输出的结果是否符合预期的测试

易用性测试：指用户使用软件时是否感觉方便的测试

1.5.3.2 性能测试：

性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行校验的测试方法

压力测试：通过逐步增加系统负载，测试系统性能的变化，并确定在什么条件下系统性能处于失效状态

负载测试：通过逐步增加系统负载，测试系统性能的变化，在满足性能指标的情况下，系统所能承受的最大负载量的测试

并发测试：是一个负载测试和压力测试的过程，即逐渐增加并发用户数负载直到系统的瓶颈，通过分析资源监控指标等来确定系统并发性能

1.5.3.3 兼容性测试：

app

Android/IOS版本

厂商

型号

分辨率

屏幕：全屏、水滴屏、刘海屏、曲面屏、折叠屏、双面屏

web

浏览器：四类，根据浏览器内核（78）

1.5.4 按其他划分

冒烟测试、随机测试、安全性测试、探索性测试、回归测试、Alpha测试、Beta测试

随机测试：随机测试主要是根据测试者的经验无需测试用例对软件进行功能和性能抽查的测试方法

安全性测试：通过不同的测试方法，检验程序、网络、数据库安全性的测试方法

探索性测试：碰到问题时能随机应变，强调测试人员的主观能动性明确整体的测试计划的测试方法

Alpha测试：俗称内测，α测试。内部环境下的测试；开发人员或测试人员在现场

Beta测试：俗称外测、公测，β测试。生产环境下的测试；开发人员和测试人员都不在现场

                                          部分来自  Anwfly  的简书