测试概念

软件测试是以用户需求为基准，运用科学的测试方法对被测对象进行检测，发现其与需求偏离的需求实现。是为了尽快尽早发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。

测试执行可以分为单元测试执行、集成测试执行、系统测试执行：

单元测试执行（UT执行）：一个测试用例的测试执行；
集成测试执行（IT执行）：一个测试用例集的测试执行；
系统测试执行（ST执行）：不同测试阶段的测试执行。

本节内容摘自师兄的博客：测试方法 | Yao’s Blog (zfyao666.github.io)

测试方法

测试方法的分类可以从多个角度来划分

测试流程上划分：单元测试、集成测试、系统测试、验收测试、Alpha 测试和 Beta 测试。
测试过程中程序执行状态：静态测试和动态测试。
从代码和软件的具体实现细节和系统内部结构的情况：黑盒测试、白盒测试和灰盒测试。
根据测试方向划分：功能测试、安全性测试、兼容性测试、界面测试、压力测试、性能测试和需求测试等。
其他测试方法：灰度测试、冒烟测试和回归测试等。

从测试流程分类

单元测试

单元测试主要对软件的组成模块或函数进行测试，是测试中的最细粒度。通常情况下是白盒且静态的，目的是确保模块和函数的正确编码，及早发现代码、程序结构和业务逻辑中不易显现的错误。分为：

孤立单元测试：只测试某一个单元模块，是最好的单元测试策略。
自底向上单元测试：比较合理的策略，缺点是测试周期较长。
自顶向下单元测试：比孤立单元测试的成本高很多。

集成测试

集成测试又被称为联合测试，该阶段会采用适当的集成策略组装程序单元模块，然后测试系统的接口和集成之后的功能。因为集成测试是界于单元测试和系统测试之间的，所以有着承上启下的作用。

常见有以下三种方式：

一次性集成测试：一次性集成所有模块，适合于维护型项目或者规模较小的软件。如果软件体量较大，应该避免一次性集成而使用增量集成。
自定向下集成测试：集成的顺序为首先集成主模块，然后按照控制层次结构向下进行集成。这种集成方式适合结构清晰和稳定的产品，因为高层接口的变化较小，而底层接口通常尚未定义或者可以被修改，需要尽早被验证。
自底向上集成测试：从底层的原子模块开始构造和测试。适用于底层接口比较稳定而高层接口变化频繁的产品。

集成测试中往往使用黑盒与白盒相结合的方法进行测试，验证该阶段设计的合理性和是否实现需求功能。

系统测试

将整个软件看作一个系统进行测试，通常使用黑盒测试法对功能、性能、界面及安全性等进行测试。由于在系统测试阶段不断变更需求造成功能的删除或增加，从而使程序不断出现相应的更改，而程序在更改后可能会出现新的问题，或者原本没有问题的功能由于更改导致出现问题。所以，测试人员必须进行回归测试。

验收测试

验收测试是软件交付最后一个阶段的测试，又称为交付测试。测试对象主要为当前系统，主要是用黑盒测试对功能进行最后的测试。除了功能之外还需要从用户的角度进行 Alpha、Beta 测试。

Alpha 测试

指软件开发公司组织内部人员模拟各类用户行为对即将面市软件产品进行测试，环境可以使开发环境或者是模拟实际环境。Alpha 测试不能由程序员或是测试人员完成。经过 Alpha 测试的软件产品称为 Beta 版本。

Beta 测试

软件产品公司组织典型用户在实际使用环境中测试，并要求用户报告异常情况，提出改进意见，然后软件开发公司再对 Beta 版本进行改错和完善。

从程序执行状态分类

静态测试

不运行测试软件或者代码，只是静态检查源程序的语句、结构、过程等来检查程序是否有错误。通常包括代码评审、UI 界面检查、需求规则说明书，用户手册检查。

动态测试

动态测试通过运行被测试程序，检查运行的结果和预期结果的差异，并分析运行效率、正确性和健壮性等性能。

从程序内部是否可见分类

黑盒测试

黑盒测试一般用来确认软件功能的正确性和可操作性，目的是检测软件的各个功能是否得以实现，把被侧程序当作一个黑盒，不考虑其内部结构，在知道该程序的输入和输出之间的关系或程序功能的情况下，依靠软件规格说明书来确定测试用例和推断测试结果的正确性。

常见的黑盒测试方法：等价类划分法、边界值分析法、场景法等。

优点：

比较简单，不需要了解程序内部的代码及实现，与软件的内部实现无关。
从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题。
基于软件开发文档，所以也能知道软件实现了文档中的哪些功能，在做软件自动化测试时较为方便。

缺点：

不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%。
自动化测试中用例的复用性较低。

白盒测试

白盒测试根据软件内部的逻辑结构分析来进行测试，是基于代码的测试。测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量。白盒测试的主要目的是检查各个逻辑结构是否合理，对应的模块独立路径是否正常以及内部结构是否有效。白盒测试的原则：

保证所有的独立路径至少被测试一次。
所有判定语句中的逻辑值均需要测试为真和假两种情况。
程序的内部数据结构都需要检查并保证其结构的有效性。
在上下边界及可操作范围内运行所有循环。

优点：可以帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

缺点：

程序运行会有很多不同的路径，不可能测试所有的运行路径。
测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求。
系统庞大时，测试开销会非常大。

逻辑覆盖法是主要的白盒测试方法，覆盖点主要有：

语句覆盖：程序中的每个语句至少被覆盖一次。
判定覆盖：程序中的每个判定至少为真和假一次。
条件覆盖：程序中的每个条件语句应该获得各种可能的结果。
判定/条件覆盖：程序中同时满足判定覆盖和条件覆盖。
条件组合覆盖：程序中的每个判定条件的各种可能组合至少出现一次。

但即使使用逻辑覆盖法穷举所有的逻辑路径并测试，程序仍然可能会出现错误，因为：

测试者无法知道程序本身是否不符合设计规范。
测试者不可能检查到程序因为遗漏路径而出错。
可能无法发现和数据相关的错误。

灰盒测试

灰盒测试则介于黑盒测试和白盒测试之间。灰盒测试除了重视输出相对于出入的正确性，也看重其内部表现。但是它不可能像白盒测试那样详细和完整。它只是简单的靠一些象征性的现象或标志来判断其内部的运行情况，因此在内部结果出现错误，但输出结果正确的情况下可以采取灰盒测试方法。

从不同测试方向分类

性能测试

性能测试主要检查系统或者 app 是否满足需要的性能。

常见的 app 性能指标：cpu、内存、流量、电量、启动速度和网络速度。

安全性测试

测试软件使用过程中是否会出现安全问题。例如 SQL 注入攻击，银行转账时的交易是否安全。

兼容性测试

检查软件或系统之间能否正确的进行交互和共享信息。有四种兼容性：

向前兼容和向后兼容；
不同版本之间的兼容；
不同标准规范之间的兼容；
数据能否共享兼容；

界面测试

又称 UI 测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

压力测试

压力测试主要用于验证软件在超过负载设计的情况下是否仍然能够返回正确的结果而不出现崩溃，也就是找到应用的瓶颈。测试环境需要尽可能和生产环境匹配，同时还要关注延迟和吞吐两个指标。

其他测试方法

冒烟测试

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

灰度测试

灰度测试指的是在产品上线或者正式应用之前，选择特定的人群进行使用，然后逐步扩大试用者数量，从而及时发现和纠正产品中的错误，实现由“灰”到“黑”。

回归测试

回归测试指的是对于一个新的版本，重新运行之前的测试用例进行测试。主要发生在：

开发人员对于代码进行了一定改动，需要回归确保现有的功能没有被破坏。
Bug Fix 之后，确保新的代码修复了 bug，并且之前的功能没有被破坏。
项目后期需要进行一次完整回归测试，确保所有功能的完整。

回归测试在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试，它的成本随着系统变大而变大，所以需要选择正确的回归测试策略（如自动化）来提升回归测试的效率和有效性。

测试模型

本节内容摘自测试基础【第二篇】软件测试模型 - 全栈测试笔记 - 博客园 (cnblogs.com)

常见的软件测试模型有 V 模型、W 模型、X 模型、H 模型和敏捷测试 AT 模型。这类知识属于了解一下即可。

V模型

在软件测试方面，V模型是最广为人知的模型，尽管很多富有实际经验的测试人员还是不太熟悉V模型，或者其它的模型。V模型已存在了很长时间，和瀑布开发模型有着一些共同的特性，由此也和瀑布模型一样地受到了批评和质疑。V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。测试工作在编码完成后才开始进行，不符合软件测试的“3早”原则。

W模型

V模型的局限性在于没有明确地说明早期的测试，无法体现“尽早地和不断地进行软件测试” 的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W 模型（如下图）。在模型中不难看出，开发是“V”，测试是与此并行的“V”。
W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。比如在进行需求分析，SRS评审，SRS基线化后，系统测试计划，方案，用例也设计完毕，接着是概要设计与集成测试设计，详细设计与单元测试设计，直到编码完成后，进行代码审查，继续执行UT，IT，ST（单元测试执行、集成测试执行、系统测试执行）。

W模型也有局限性，W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。

X模型

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

X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

H模型

　　H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。

这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。

　　H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

测试模型结语

在实际工作中应灵活地运用各种模型的优点，
V模型：强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试；
W模型：补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明；
H模型：强调测试是独立的，只要测试准备完成，就可以执行测试。

学习记录--测试基础