软件测试是软件质量保证的关键步骤。越早发现软件中存在的问题，修复问题的老本就越低，软件 品质也就越高，软件公布后的维护费用越低。
为了能更好的保障软件品质，在软件测试的实际中，缓缓造成了一些流程用来达到这一指标。上面就来介绍一下常见的测试流程。
传统测试流程
在传统的测试流程中蕴含了如图所示的步骤。
编辑
上面别离介绍下每一步流程的含意。
单元测试
单元测试是对软件中的根本组成单位进行的测试。目标是测验软件根本组成单位的正确性。
测试阶段：编码后
测试对象：最小模块
测试人员：开发
测试根据：代码、正文、具体设计文档
测试方法：白盒测试
集成测试
集成测试是在软件系统集成过程中所进行的测试。目标是查看软件模块之间的接口是否正确。
测试阶段：单元测试实现后
测试对象：模块间的接口
测试人员：开发
测试根据：单元测试模块、概要设计文档
测试方法：黑盒与白盒联合
冒烟测试
冒烟测试是在软件开发过程中的一种针对软件版本包的疾速基本功能验证策略，是对软件基本功能进行确认验证的伎俩。
测试阶段：提测后
测试对象：整个零碎
测试人员：测试
测试根据：冒烟测试用例
测试方法：黑盒测试（手工或自动化伎俩）零碎测试
零碎测试是对曾经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。
测试阶段：冒烟测试通过后
测试对象：整个零碎
测试人员：测试
测试根据：需要文档、测试计划、测试用例
测试方法：黑盒测试
个别零碎的次要测试工作都集中零碎测试阶段。依据不同的零碎，所进行的测试品种也很多。
在零碎测试中，又包含如下测试品种：
功能测试：功能测试是对产品的各性能进行验证，以查看是否满足需要的要求。性能测试：性能测试是通过自动化测试工具模仿多种失常、峰值以及异样负载条件来对系统的各项性能指标进行测试。平安测试：平安测试查看系统对非法入侵的防备能力。兼容测试：兼容性测试次要是测试零碎在不同的软硬件环境下是否可能失常的运行。验收测试
验收测试是部署软件之前的最初一个测试操作。验收测试的目标是确保软件准备就绪，向软件购买都展现该软件系统满足其用户的需要。
测试阶段：公布前
测试对象：整个零碎
测试人员：用户 / 需求方
测试根据：需要、验收规范
测试方法：黑盒测试
软件测试模型
软件测试过程是一种形象的模型，用于定义软件测试的流程和办法。家喻户晓，开发过程的品质决定了软件的品质，同样的，测试过程的品质将间接影响测试后果的准确性和有效性。软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。
随着测试过程治理的倒退，软件测试专家通过实际总结出了很多很好的测试过程模型。这些模型将测试流动进行了形象，并与开发流动有机的进行了联合，是测试过程治理的重要参考根据。
上面介绍几种常见的测试模型。
V 模型
V 模型是开发模型中瀑布模型的一种改良。瀑布模型将软件生命周期划分为打算、剖析、设计、编码、测试和保护六个阶段，因为晚期的谬误可能要等到开发前期的测试阶段能力发现，所以可能带来重大的结果。
V 模型在这点改良了瀑布模型，在软件开发的生存期，开发流动和测试流动简直同时开始，在开发流动进行的时候，测试流动开始进行相应的文档筹备工作，从而改良软件开发的效率和成果。
编辑
V 模型的长处是明确的标注了测试过程中存在着那些不同的测试类型，并且能够分明的表白测试阶段和开发过程各阶段的对应关系。
然而，它也有一些毛病。比方容易让人误会为测试是在开发实现之后的一个阶段。而且因为它的程序性，当编码实现之后，正式进入测试时，这时发现的一些 Bug 可能不容易找到其本源，并且代码批改起来很艰难。在理论工作中，因为需要变更较大，应用 V 模型可能导致要反复变更需要、设计、编码、测试，返工量会比拟大。
W 模型
W 模型从 V 模型演变过去。绝对于 V 模型，W 模型减少了软件各开发阶段中应同步进行的验证和确认流动。
W 模型由两个 V 字型模型组成，别离代表测试与开发过程，图中明确示意出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早的全面发现问题。
编辑
W 模型认为测试随同着整个软件开发周期，而且测试的对象不仅仅是程序，需要、设计等同样要测试。
W 模型有利于尽早地全面的发现问题。例如，需要剖析实现后，测试人员就应该参加到对需要的验证和确认流动中，以尽早地找出缺点所在。
对需要的测试也有利于及时理解我的项目难度和测试危险，及早制订应答措施，这将显著缩小总体测试工夫，放慢我的项目进度。
应用 W 模型的长处很显著。首先测试的流动与软件开发同步进行，而且测试的对象不仅仅是程序，还包含需要和设计。这样能够尽早发现软件缺陷可升高软件开发的老本。
然而 W 模型还是有一些毛病存在。比方开发和测试仍然是线性的关系，需要的变更和调整，仍然不不便。而且如果没有文档，根本无法执行 W 模型。应用 W 模型对于我的项目组成员的技术要求也更高。
H 模型
绝对于 V 模型和 W 模型，H 模型将测试流动齐全独立进去，造成了一个齐全独立的流程，将测试筹备流动和测试执行流动清晰地体现进去。
编辑
这个示意图仅仅演示了在整个生产周期中某个档次上的一次测试“微循环”。图中标注的其余流程能够是任意的开发流程，例如，设计流程或编码流程。也就是说，只有测试条件成熟了，测试筹备流动实现了，测试执行流动就能够（或者说须要）进行了。
H 模型中蕴含了如下概念：
测试筹备：所有测试流动的筹备判断是否到测试就绪点。测试就绪点：测试准入准则，即是否能够开始执行测试的条件。测试执行：具体的执行测试的程序。其它流程：设计流程或编码流程。H 模型揭示了软件测试除测试执行外，还有很多工作。它让测试流动齐全独立贯通整个生命周期与其它流程并发进行。在 H 模型中，软件测试流动能够尽早筹备尽早执行，具备很强的灵活性。而且软件测试能够依据被测对象的不同而分档次、分阶段、分秩序的执行，同时也是能够被迭代的。
然而 H 模型对于治理要求很高，因为须要定义清晰的规定和管理制度，否则测试过程将很难治理和管制。而且对于技能要求也很高，因为 H 模型要求可能很好的定义每个迭代的规模，不能太大也不能太小。在 H 模型中，测试就绪点的剖析也比拟艰难。因为测试过程中，并不知道测试筹备到什么时候是适合的，就绪点在哪，就绪点规范是什么，这就对后续的测试执行启动带来很大的艰难。
三种模型比照
下面介绍的三种测试模型是当初比拟常见的，然而它们的应用场景会有一些不同。
V 模型实用于中小企业。W 模型实用于中大型企业。H 模型人员要求十分高，现阶段应用比拟少。零碎测试工作流程
对于零碎测试来说，工作流程如图所示：
编辑
上面别离解释一下每一步的具体含意。
我的项目打算
形容测试目标、范畴、办法和软件测试的重点等等内容的文档。
需要剖析
测试工程师参加需要剖析，能够减少对需要的理解，缩小前期与产品和开发人员的沟通，节省时间。晚期确定测试用例的编写思路，能够为测试打好根底。在需要剖析的过程中能够获取一些测试数据，为测试用例设计提供帮忙。而且在剖析过程中能够发现需要不合理的中央，升高测试老本。
测试设计
测试设计是指把概括的测试指标转化为具体的测试用例的一系列流动。设计时要同时评审测试根据，也就是需要、零碎架构、设计和接口阐明等文档。通过对测试项、规格阐明、测试对象行为和构造的剖析，辨认测试条件并确定优先级。依据剖析的内容设计测试用例，并确定优先级，同时确定测试条件和测试用例所需的必要的测试数据。
用例评审
测试用例评审个别进行两轮。
一轮是组内评审，组内人员会评审测试用例是否齐全笼罩了需要，提出一些修改意见。
二轮评审须要和产品、研发一起进行，产品和研发会从不同角度对用例进行一些补充。通过用例评审并且把评审中的倡议补充结束之后，测试用例才最终设计结束，进入期待执行的状态。
测试执行
开发人员实现需要的开发之后会提测，也就是把能够测试产品交付给测试人员进行测试。提测后须要先执行冒烟测试，通过之后正式进入测试执行阶段。
开始执行之前要确认曾经正确搭建了测试环境。环境没有问题后，就依据打算的执行程序，通过手工或应用测试工具来执行测试用例。执行过程中须要记录测试执行的后果，以及被测软件、测试工具的标识和版本。将理论后果和预期后果进行比拟。对理论后果和预期后果之间的差别，作为 Bug 上报，并且进行剖析以确定引起差别的起因。缺点修改后，从新进行测试流动。
Bug 治理
软件缺陷（Bug）是一种泛称，它能够指性能的谬误，也能够指性能低下，易用性差等。
公布保护
监控上线后的产品，发现问题及时修复。
Bug 治理流程
Bug 的治理也须要遵循肯定的流程，根本流程如图所示：
编辑
提交 Bug
在提交一个 Bug 的时候，首先尽量形容这个 Bug 的属性。重现环境，类型，等级，优先级以及具体的重现步骤，后果与冀望等。当然，在提交一个问题之前首先应该保障，这个 Bug 是没有被提过的，免得造成反复提交。
指派 Bug
有些公司测试部门与开发部门独立，那么测试人员就不确定本人测试的模块是由哪位开发人员负责的，在这种状况下，测试人员对立把问题指派给我的项目组长或经理，由我的项目组长（或经理）对问题进行确认后再次调配给相应的开发人员。
有些测试人员是和研发团队在一起工作的，这时，测试人员会对开人发员负责的模块十分分明，就能够将问题间接指派给相应的开发人员。
确认 Bug
当开发人员接到一个 Bug 时，首先是对其进行剖析与重现，如果对其进行剖析发现不是 Bug（可能因为测试人员不理解需要）或无奈对此问题进行重现，那么就须要将此问题返回给测试人员再次进行回归，并注明起因。如果确认为是 Bug 则须要对其进行解决。
判断是否推延解决
在解决问题之后，还须要进行一次判断，是否须要推延解决。有些 Bug 曾经确认了是问题，因为其可能在极其状况下才会呈现，或须要对系统架构进行改变，或其优先级非常低，所以临时不须要对此问题进行解决，或到下个版本进再进行修复。
遗留 Bug
对于推延解决的问题能够临时进行遗留。个别遗留的问题须要通过项目经理与测试经理协商后才能够。
解决 Bug
开发人员在确认完一个问题须要解决时，那么就对其进行解决工作。
回归 Bug
确认非 Bug 问题：对于提交的一个 Bug，开人员解决为非 Bug 或无奈重现，而后间接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题敞开。如果非开发人员所说，是因为问题形容含糊或其它起因未重现问题，则再次注明起因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则敞开问题。确认不通过，将问题再次关上并转给开发人员。
确认遗留问题：有打算的对遗留的问题进行确认，有些遗留问题随着工夫的推移，版本的更新或曾经不存在了，对这类问题应该及时敞开。有些遗留问题仍然存在且变得紧急，对于这类问题应该及时关上交给开发人员解决。
敞开 Bug
对于曾经修复的 Bug 进行敞开，这也是一个 Bug 的最初一个状态。
测试左移和测试右移
传统的流程就是接到我的项目后参加需要评审，而后依据需要文写用例和筹备脚本，等开发提测之后正式开始测试、提 Bug、回归，测试通过后就完结了，我的项目交给运维上线，之后投入下一个我的项目持续反复这样的流程。
这样的流程看似没什么问题，但毛病是测试过程是在肯定工夫距离内产生的，测试人员必须期待产品齐全构建能力找到谬误和故障。有时候期待产品破费的工夫超过了能够约定的工夫，期待代码成为测试人员的瓶颈。
而测试左移以及测试右移，可能让测试领有更多的主动权，有更短缺的工夫进行测试，同时不会像之前因为品质差危险高每次都延期上线，并且产品的线上品质也能有保障。
不论是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试流动的开始，上线是测试流动的完结，更不要认为品质只是测试同学须要关注的。
测试左移
测试左移是向测试之前的开发阶段挪动。
测试左移的准则反对测试团队在软件开发周期晚期和所有干系人单干。因而他们能清晰地了解需要以及设计测试用例去帮忙软件“疾速失败”，促使团队更早的批改所有的 Bug。
参加和了解会使测试人员获取产品残缺的常识，彻底想分明各种场景，依据软件行为设计实时的场景，这些都会帮忙团队在编码实现之前辨认出一些缺点。
左移聚焦在使测试人员在全副和最重要的我的项目阶段参加进来。这就是测试人员把焦点从发现 Bug 转移到 Bug 的预防上，同时也驱动我的项目的商业指标。
随着测试团队的责任的进步，团队不在仅仅聚焦在“测试软件去发现 Bug”，而是踊跃团队单干，参加我的项目初始阶段的打算和建设强健无效的测试策略，而测试策略又为团队提供好的测试领导力和领导，使团队聚焦在产品的久远的视角，而不仅仅是测试工作。
左移首先为测试人员提供了设计测试的机会，无论这些测试是被聚焦在客户的体验还是冀望，也促使开发人员依据这些测试去开发软件以满足客户需要。
测试右移
测试右移是测试流动向产品公布之后的步骤挪动。
是产品上线了之后也能够进行一些测试流动。能够在生产环境做监控，监控线上性能和可用率，一旦线上产生任何问题，尽快反映，提前反映，给用户良好的体验。