测试左移和测试右移

测试左移和测试右移

测试左移与右移的基点是瀑布模型的测试阶段，在其测试阶段侧重系统测试，可以涵盖集成测试，其中单元测试属于编程阶段，和编程同时进行：
测试左移：将测试计划与设计提前进行，以及开展需求评审、设计评审、代码评审等。
测试右移：将测试延伸到研发阶段之后的其他阶段，一般主要指产品上线后的测试，包括在线测试、在线监控和日志分析，甚至包括Alpha测试、Beta测试。

从现实角度出发，测试左移也包括加强单元测试，对单元测试有较高的要求，如代码行覆盖做到100%，而且强调代码编写和单元测试同步进行，写好一个类测试一个类、写好一个方法测一个方法，而不是集中写几天代码，再集中做单元测试。发现问题越早越好，避免以后重复犯错。

测试右移指在线测试，传统的Alpha测试、Beta测试也是上线后的测试，分别指内部用户、外部有限用户的试用，通过试用来发现问题。现在软件作为服务，通常部署在软件研发公司的数据中心，有利于监控和分析系统运行的行为，虽然不是真正意义上的主动测试，属于被动测试，但大量用户的操作使用自然是对软件系统的真正考验，有问题还是能够暴露出来。由于系统就部署在自己的数据中心，有问题可以快速及时修复，对用户的影响会控制在比较小的范围内，降低缺陷带来的风险。许多易用性测试（如A/B测试）、性能测试等都可以在线进行（监控、数据收集与分析）。

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

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

系统测试（System Testing）是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。系统测试的目的是验证最终软件系统是否满足用户规定的需求。系统测试主要内容包括：
1）功能测试，即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。
2）健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
比较常见的、典型的系统测试包括恢复测试、安全测试、压力测试。
1）恢复测试
恢复测试作为一种系统测试，主要关注导致软件运行失败的各种条件，并验证其恢复过程能否正确执行。在特定情况下，系统需具备容错能力。另外，系统失效必须在规定时间段内被更正，否则将会导致严重的经济损失。
2）安全测试
安全测试用来验证系统内部的保护机制，以防止非法侵入。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵。
3）压力测试
压力测试是指在正常资源下使用异常的访问量、频率或数据量来执行系统。在压力测试中可执行以下测试：
①如果平均中断数量是每秒一到两次，那么设计特殊的测试用例产生每秒十次中断。
②输入数据量增加一个量级，确定输入功能将如何响应。
③在虚拟操作系统下，产生需要最大内存量或其它资源的测试用例，或产生需要过量磁盘存储的数据。

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

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

软件研发的V模型

基于W模型呈现软件测试和开发的关系

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

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

动态测试：运行程序而进行的测试，测试只是编程之后的阶段，这也是由传统的瀑布模型决定的。

静态测试：在不运行软件系统时对软件或阶段性成果进行评审，包括需求评审、设计评审、代码评审（含代码的静态分析）等。引入静态测试，就可以尽早发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，极大地提高产品的质量，有效地降低企业的成本。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

兼容性测试是指检查软件之间能否正确地进行交互和共享信息。随着用户对来自各种类型软件之间共享数据能力和充分利用空间同时执行多个程序能力的要求，测试软件之间能否协作变得越来越重要。软件兼容性测试工作的目标是保证软件按照用户期望的方式进行交互。
兼容性通常有四种：向前兼容与向后兼容、不同版本间的兼容、标准和规范、数据共享兼容。
1）向前兼容和向后兼容。向前兼容是指可以使用软件的未来版本，向后兼容是指可以使用软件的以前版本。并非所有的软件都要求向前兼容和向后兼容，这是软件设计者需要决定的产品特性。
2）不同版本之间的兼容。不同版本之间的兼容指要实现测试平台和应用软件多个版本之间能够正常工作。如要测试一个流行的操作系统的新版本，当前操作系统上可能有数十或上百万条程序，则新操作系统的目标是与它们百分之百兼容。因为不可能在一个操作系统上测试所有的软件程序，因此需要决定哪些程序是最重要的、必须测试的。对于测试新应用软件也一样，需要决定在哪个版本平台上测试，以及与什么应用程序一起测试。
3）标准和规范。适用于软件平台的标准和规范有两个级别：高级标准和低级标准。
① 高级标准是产品应当普遍遵守的。若应用程序声明与某个平台兼容，就必须接受关于该平台的标准和规范。
② 低级标准是对产品开发细节的描述，从某种意义上说，低级标准比高级标准更加重要。
4）数据共享兼容。数据共享兼容是指要在应用程序之间共享数据，要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据。

主动测试和被动测试
主动测试是指测试人员和被测程序系统直接交互，测试人员根据所要测试的目标，主动向被测程序系统发送特定的测试输入信息，同时检查程序的输出结果，看是否符合预期。在主动测试中，测试程序及其配置和运行环境完全处在测试人员的控制之下，被测程序并不是处于正常的工作状态，而是处于被测状态。主动测试中，测试人员必须花费大量的精力来设计可执行的测试用例被动测试是指被测程序系统运行在真实的环境之下，处于正常的工作状态，测试人员不干预被测程序的运行，只是被动地接收被测程序的输入和输出信息，然后通过分析来判断程序运行是否正常。
被动测试不需要设计测试用例，可以长时间进行测试而无需人工干预，并且不影响被测试线的执行和运行环境。被动测试需要我们对于结果进行充分的分析和判断。目前我们绝大多数的测试都是主动测试，只有线上观察、OP的系统监控、性能测试等属于被动测试。

易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。
A/B测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。

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

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

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

瀑布模型是最早出现的软件开发模型，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试（单元测试，集成测试和系统测试）和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。
（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

测试左移和测试右移，能够让测试拥有更多主动权，有更充足的时间进行测试，同时不会像传统软件开发模式因为质量差风险高导致版本延期上线，且产品的版本质量有所保障。

不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束。

测试左移：测试左移是将关键的测试实践移至开发生命周期的早期，本质上是借助工具和测试手段更早地发现问题和预防问题。
需求：对需求、架构和设计模型的测试；
开发：着重增加对单元、组件和服务层的测试；
持续测试：自动化测试。

测试右移：版本上线后需要持续关注线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。
灰度发布：新版本线上测试；
监控：合理的性能监测、数据监控和预警机制；
用户反馈：线上问题处理、跟踪机制。

测试左移
测试左移的思想本质是越早发现不合理的地方出问题的几率就越低。

测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作。因此能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的bug。

参与和理解会使测试人员获取产品完整的知识，彻底理解各种场景，根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前发现一些缺陷。

测试左移就是通过一系列的活动，提高质量的上限，缩短测试的周期，提高质量的下限。
提高质量上限

• 健康的项目流程（合理并且严格遵守的项目流程）
• 合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）
• 出色的系统架构
• 充分利用静态代码扫描
• 进行研发标准的定义

提高质量下限

• 健康的测试流程
• 优秀的测试用例
• 合理的测试计划
• 合适的自动化
• 适当的探索式测试
• 开发自测（TDD、BDD，测试提供更好的用例、技术支持）
• 尽早的测试
• 团队质量意识的培养

测试左移实现步骤

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

测试右移
左移是往测试之前的开发阶段移，右移是往发布之后移。

测试右移可以理解为若线上发生任何问题，能够第一时间发现问题并解决问题，并保证线上数据的一致性，且尽可能少地影响线上用户，以及实时获取用户反馈。

测试右移实践步骤

• 闭环的线上问题反馈-检查-解决-更新流程
• 更便捷的日志查看、回传服务
• 丰富有效的log，便于问题的快速定位
• 丰富的监控指标（例如业务异常点指标）
• 成本监控（例如短信发送等）
• 关键指标每日监控（服务器指标）
• 生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）

对于测试右移，线上监控是突破点，可以围绕问题反馈、发现、定位、监控展开，参与人员不仅仅局限于运维人员。

参考文章：
《全程软件测试》（第3版）-朱少民著
什么是测试左移和测试右移，如何落地？
测试左移与测试右移