瀑布模式(传统测试)、敏捷开发Scrum(敏捷测试)及DevOps（测试左移/测试右移）的区别

一、瀑布模式（传统测试）：将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护6个基本步骤；

二、敏捷开发（敏捷测试）：高度迭代、快速响应

敏捷测试的优缺点：

一定程度上提高了测试效率但可能会导致漏测。

敏捷测试是伴随着敏捷开发双双出现的，先说说敏捷开发的最大特点：积极响应客户需求，快速高质量的交付软件。
所以在一个敏捷的项目流程中，首先会将需求按照用户的需求程度分为多个迭代，而每个迭代都可视为小的版本周期。

敏捷测试的流程，主要专注于两方面：
一是新功能的测试：从需求评审开始，到最终上线，测试人员需持续关注迭代的新功能，针对新功能进行足够的测试，保证新功能验收。
二是原有功能的测试：这一点也是敏捷测试提高效率所在，一般这个过程会通过自动化的回归测试。

由于敏捷流程的迭代周期短，测试人员要做到尽早开始测试，这个过程包含前期需求评审，开发设计评审，以及测试用例评审；敏捷测试最重要的是能及时、持续的对软件的质量进行反馈。简单的说，敏捷测试就是持续的对软件问题产生及时反映，一个 bug 被隐藏的时间越长，修复这个 bug 的代价就越大。

一般来说，一个大的需求经过敏捷流程会被分解成如下：

 

 

敏捷测试什么时候介入？该做些什么？

1.story需求评审
要求全部人员参加，预先尽早发现遗漏的功能点和对其他模块的影响点，主要是需求人员讲解，其余人员头脑风暴，从各自对需求的理解提出问题。
此阶段的输出有：需求验收标准（有利于后期测试用例的测试点编写）
2.接口设计评审
参与开发人员的api评审，结合需求针对接口提出问题。
此阶段的输出有：api接口文档，文档对于接口自动化非常重要
3.用例评审
测试人员根据需求评审中的标准进行测试用例的设计和编写，交于相关人员主要是开发人员，进行用例评审，一般情况下会有各种遗漏和修改，甚至会发现更大的影响点，小编曾经碰到一个潜藏测试点，之后不得不重定测试计划[捂脸]；最后针对修改的再过一遍，最终上传到用例库，如禅道之类。
此阶段的输出：测试用例文档
4.分配用例
由于敏捷流程中倡导的是全民测试，一些基础功能用例，可以分配给开发人员等
5.执行用例
测试人员执行测试用例，并对发现的问题分P级提交bug，待开发修改后，根据影响点及时回归问题，最后关闭bug。
此阶段的输出：bug
6.分析问题
分析问题产生的原因，找出是流程中哪个环节遗漏，然后针对相关阶段进行补救，以防下次出错。比如测试用例设计遗漏，则下次用例评审中针对用例深挖；如果是老版本遗留问题，则针对bug进度规范修改；如果是修改引起的联动性问题，则从执行用例过程中，以及分析自动化回归没有覆盖等方面分析。
7.质量报告
针对上述分析，输出质量报告，从发现问题的多少，P级各占百分比，与上期对比，bug的严重性给出评价。对出现问题的原因进行分析，如何改良流程，避免再现，并提出合理化的意见。

 

三、DevOps：https://www.jianshu.com/p/364521f8d97e

DevOps是一套实践方法，在保证高质量的前提下，缩短系统变更从提交到部署至生产环境的时间。

DevOps五要素

• 敏捷
• 持续
• 协作
• 系统性
• 自动化

部署流水线

部署流水线是从开发提交代码，到代码实际部署到正式生产环境的流程。

 

 

1. 开始：开发人员把代码提交至联合版本（dev、test、master）
2. 在本地环境执行提交前测试
3. 测试通过后，提交代码，提交操作触发集成构建，并进行集成测试
4. 集成测试通过，提升到准生产环境（预发布环境），再次测试
5. 测试通过后，部署到生产环境，并进行密切监控
6. 经过一段时间的密切监控后，部署到正式生产环境
7. 结束

• 持续集成：通过自动触发器进行集成，直到集成测试
• 持续交付：使用自动触发器，直到预发布系统
• 持续部署：直到部署到生产系统，都是自动化的

环境

不同环境用于不同的测试类型。成功完成的测试越多，对系统版本质量更有信心。

• 提交前：开发本地环境或开发服务器，有更详细的日志记录以帮助发现缺陷
• 构建与集成测试：持续集成服务器，有足够多的测试数据
• 用户验收测试/预发布/性能测试：尽可能接近生产环境。数据库应包含真实生产数据的一个子集
• 生产：正式生产环境，应有足够的资源以满足其日常需要

测试关注点

• 测试框架
  软件以及配置的测试数据，通过在各种条件下运行它，并对行为和输出进行监控，来测试一个程序单元。测试框架会产生报表，并识别测试失败的测试用例。
• 负面测试
  即异常测试。违背正确输入和执行顺序操作的测试。在进行异常测试时，常见期望是程序可能优雅地降级或失败。若故障不可避免，反馈有意义的错误信息，并以可控方式退出。
• 回归测试：
  ①在程序变更后力求发现新的缺陷
  ②确保已经被修复的缺陷不再被引入

部署流水线的不同测试

在部署流水线流程中，代码提交前、构建后、预发布环境、生产环境都有测试参与。

在开发和提交前测试中的测试

在开发过程中有两种类型的测试过程。测试驱动开发和单元测试。

• 测试驱动开发
  传统开发流程：先概要设计，再详细设计，编码完成后进行测试。
  测试驱动开发：先开发自动化测试，再编码开发功能，直到测试通过。

• 单元测试
  在知晓系统代码的前提下，对单独类或方法进行测试。

在执行提交前，自动地运行以上测试。提交前测试通常包含一组相关的单元测试，还有几个冒烟测试。目标是在集成测试前可以发现通过单元测试但未破坏整体系统的缺陷。一旦测试通过，就可以执行代码提交操作了。

集成测试

对系统已构建的可执行部分的测试。

功能测试

对已构建提交的整体系统的功能进行逐个测试，测试是否满足需求，功能能否正常，满足用户使用需求。

接口测试

对已提交的功能对应的接口进行测试，从接口层面底层是否满足健壮性，容错性，易用性。

自动化测试

丰富自动化测试用例，将测试过的主流测试功能转化为自动化脚本，在后期的回归测试中更加容易减少人工投入，丰富测试手段。

用户验收测试/预发布/性能测试

预发布是系统部署到生产环境前的最后一步，因此预发布环境应尽可能贴近生产环境。在这个步骤中有以下测试类型：

• 用户验收测试（UAT）
  相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。
  可根据测试脚本测试，也可使用探索性测试。
• 自动化验收测试
  对最重要的、需要重复执行的，且不太需要做很多维护的检查点实现自动化
• 冒烟测试
  是自动化验收测试的一个自己，用于快速分析提交的代码是否影响到系统的某些核心功能
• 非功能测试
  对性能、安全、容量以及可用性等方面的测试

生产环境

在系统部署到生产环境后，还会继续进行观察和测试。

早期发布

• beta发布
  将产品有计划地发布给特定用户，让用户大量使用来发现软件存在的问题与错误，再把信息反馈给开发者修改。

• 金丝雀发布
  若系统部署有多台服务器，先将新版本部署到其中几台服务器上，然后观察验证。确认没有异常后，后续再更新剩余的所有服务器。
  若只有一台服务器，不可以使用金丝雀发布。

• A/B测试
  beta发布与金丝雀发布是发布策略，A/B测试关注的是发布效果。
  线上同时运行多个版本的服务，不同服务会有一些体验上的差异。相关人员通过分析各个版本的实际效果确定哪个版本执行得更好。
  例如：推荐算法、用户界面

错误检测

即使系统通过所有测试，还是有可能存在缺陷。
对于检测非功能的错误，可以对系统信息进行监控。监控包括：用户请求的响应时间、队列长度等。当监控数据与历史数据有偏差时，会触发报警并通知给相关人员。
在检测到错误后，为了对错误进行跟踪溯源，一般要求系统日志有合适的记录。
在错误诊断并修复后，会在未来发布的版本进行回归测试。

现场测试

在系统部署后，通过特殊手段干扰正在运行的系统。例如：宕服务、宕虚拟机、模拟网络变慢等。