测试-自我学习

一：敏捷测试

1. 定义：

敏捷测试是一种遵循敏捷软件开发规则和原则的测试实践。
敏捷开发（Agile Development）是一种以人为核心、快速迭代、循序渐进的开发方法。
持续交付、持续反馈、持续学习

2. 敏捷测试的核心：

• 质量内建
  敏捷测试的核心是质量内建。
  敏捷测试的目标不是发现更多的 Bug，而是帮助开发人员理解需求，提前预防缺陷
  尽快地交付高质量的软件，这就是质量内建。
• 敏捷测试强调“与开发协作”、“自动化测试”、“客户思维”和“动态的测试策略调整”

3. 敏捷测试的8大原则

• 尽早和持续的开展测试
• 基于风险的测试策略是必须的
• 测试计划、设计、和执行力要求简单
• 能及时的完成质量全面评估
• 软件本身是测试研究和分析的最主要对象
• 满足所需的质量，测试的越快越好
• 对测试技术精益求精
• 不断反思，持续优化测试

和传统测试的区别

传统测试一次性交付整个系统，需要写完整的测试文档，测试计划
而敏捷测试则是将庞大的测试分成N分，每次进行迭代
（1）传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。
而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。
（2）传统测试具有明显的阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告，一个阶段一个阶段往前推进，
但敏捷测试更强调持续测试、持续的质量反馈，没有明确的阶段性界限。
（3）传统测试强调测试的计划性，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。
（4）传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。
（5）传统测试关注测试文档，包括测试计划、测试用例、缺陷报告和测试报告等，要求严格遵守文档模板，强调测试文档评审的流程与执行等，
而敏捷测试更关注产品本身，关注可以交付的客户价值。敏捷测试中，强调面对面的沟通、协作，强调持续质量反馈、缺陷预防。
（6）传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，
但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

二：测试名词介绍

瀑布模型

最早出现的软件开发模型，自上而下，相互衔接的固定次序，将软件的生命周期分为

• 制定计划
• 需求分析
• 软件设计
• 程序编写
• 软件测试（单元测试，集成测试，系统测试）
• 运维

回归测试

回归测试分为局部回归和完全回归
局部回归是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
完全回归是将新增的功能和以前的功能全部测试

Alpha测试

一般指α测试，α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。α测试即为非正式验收测试。

Beta测试

是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

性能测试

是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。

• 负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
• 压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
• 容量测试(Volume Testing): 确定系统最大承受量,譬如系统最大用户数,最大存储量,最多处理的数据流量等。

白盒测试

又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

黑盒测试

它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

灰盒测试

是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

三：测试流程

单元测试 (unit test)

是指对软件中的最小可测试单元进行检查和验证，单元是人为规定的最小的被测功能模块。
单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

集成测试

也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

系统测试（system test）

是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。系统测试的目的是验证最终软件系统是否满足用户规定的需求。
比较常见的、典型的系统测试包括恢复测试、安全测试、压力测试。系统测试主要内容包括：

• 功能测试

即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。

• 健壮性测试

即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。

• 恢复测试

恢复测试作为一种系统测试，主要关注导致软件运行失败的各种条件，并验证其恢复过程能否正确执行。在特定情况下，系统需具备容错能力。另外，系统失效必须在规定时间段内被更正，否则将会导致严重的经济损失。

• 安全测试

安全测试用来验证系统内部的保护机制，以防止非法侵入。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵。

• 压力测试

压力测试是指在正常资源下使用异常的访问量、频率或数据量来执行系统。在压力测试中可执行以下测试：
①如果平均中断数量是每秒一到两次，那么设计特殊的测试用例产生每秒十次中断。
②输入数据量增加一个量级，确定输入功能将如何响应。
③在虚拟操作系统下，产生需要最大内存量或其它资源的测试用例，或产生需要过量磁盘存储的数据。

验收测试

是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

四: 左移测试

定义：

• 左移是在软件交付过程中尽早发现和防止缺陷的一种实践方法，目的是尽量在软件开发生命周期中尽早将测试任务左移，通过借助工具和测试手段更早地发现问题和预防问题，以提高产品质量。
• 左移测试意味着在软件开发过程的早期阶段进行测试。参与需求评审、设计评审、代码评审等。
• 加强了单元测试，代码的编写和单元测试同时进行，写好一个方法测试一个方法。

测试左移实现步骤

• 编写单元测试，通过单元测试提前进行测试
• Code Review，通过代码走读发现一些基础的问题
• 参与需求评审，提出需求不清晰、不合理、遗漏等意见，了解开发的实现方式
• 参与研发需求分解，协助梳理分解遗漏点
• 参与概要、接口设计评审，协助梳理遗漏逻辑
• 提早输出测试导图，开发编码前进行评审
• 部分功能提测，提早开始测试
• 自动化测试，用于回归确保旧版本功能正确性

五：契约测试

通过检查上下游的所有调用与返回是否与实际结果相同。
随着微服务的普及，Web系统越来越大，各模块之间的调用越来越复杂，如果一个服务修改了，那么调用它的所有使用者都得验证一遍是否对自己有影响，导致效率低，成本高，契约测试就是在这一背景下产生的，它能很好的解决这个问题。

通过一个 锲约文件（Json/Yaml） 来约束 消费者和提供者
以前我们通过测试替身（mock 出来一个虚拟的API接口） 来代替服务的提供的接口
导致服务器提供的接口更改，不知道是接口变化还是服务器异常
解决办法
解耦： 解决对外部API的依赖，内部和外部系统都依赖一个双方认可的 契约文件

定义

消费者驱动契约测试，就是消费者和提供者达成的共同协议，

契约测试的作用：

• 测试接口和接口之间的正确性

• 更快速的验证消费端和提供端之间交互的基本正确性

• 验证服务层提供的数据是否是消费端所需要的

• 将本来需要在集成测试中体现的问题前移，更早的发现问题

对比

六：端到端测试

集成测试

定义

端到端（E2E）测试的主要目的是通过模拟真实的用户场景，验证被测系统及其组件的集成性和数据完整性，从最终用户的体验进行测试。

端到端测试的好处

端到端测试因以下优点而更为可靠和广泛采用：

• 扩大测试覆盖范围
• 确保应用程序的正确性
• 缩短发布时间
• 降低成本
• 检测Bug