软件测试v模型-安博测试空间技术中心软件测试与质量保证的区别

软件测试与质量保证的区别由安博测试空间技术中心提供软件测试人员的一项重要任务是提高软件质量，但不等于说软件测试人员就是软件质量保证人员，因为测试只是质量保证工作中的一个环节。软件质量保证和软件测试是软件质量工程的两个不同层面的工作。质量保证(QA)：质量保证的重要工作是通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作。所关注的是软件质量的检查与测量。虽然在QA的活动中也有一些测试活动，但所关注的是软件质量的检查与测量。QA的工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求，因此主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估。软件测试：测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行”软件，对过程中的产物－－－开发文档和源代码进行走查，运行软件，以找出问题，报告质量。测试人员必须假设软件存在潜在的质量问题，测试中所做的操作是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。对测试中发现的问题的分析、追踪与回归测试也是软件测试中的重要工作，因此软件测试是保证软件质量的一个重要环节。

软件测试原则所有的软件测试都应追溯到用户需求。应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。由于软件的复杂性和抽象性，在软件生命周期各个阶段都可能产生错误，所以不应把软件测试仅仅看作是软件开发的一个独立阶段的工作，而应当把它贯穿到软件开发的各个阶段中。在软件开发的需求分析和设计阶段就应开始测试工作，编写相应的测试文档。同时，坚持在开发的各个阶段进行技术评审和验证，这样才能在开发过程中尽早发现和预防错误，杜绝某些缺陷和隐患，提高软件质量。只要测试在生命周期中进行的足够早，就能够提高被测软件的质量，这就是预防性测试的基本原则。完全测试是不可能的，测试需要终止。测试无法显示软件潜在的缺陷。充分注意测试中的群集现象。程序员应避免检查自己的程序。尽量避免测试的随意性。应该从工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。软件测试对象根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。软件测试应贯穿于整个软件生命周期中。在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。

在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，这就称为“确认测试”。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。为了把握各个环节的正确性，人们需要进行各种验证和确认(verificationvalidation)工作。验证(verification)是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。确认(validation)是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。软件测试分类按照全生命周期的软件测试概念，测试对象应该包括软件设计开发的各个阶段的内容。按照开发阶段划分按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。

单元测试单元测试又称模块测试，是针对软件设计的最小单位－－－程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。集成测试集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。软件集成的过程是一个持续的过程，会形成很多个临时版本，在不断的集成过程中，功能集成的稳定性是真正的的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。确认测试确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。系统测试系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接、并满足用户需求。

验收测试按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。按照测试实施组织划分按照测试实施组织划分，软件测试可分为开发方测试、用户测试(β测试)、第三方测试。开发方测试。通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。用户测试。在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。测试通常被看成是一种“用户测试”。β测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。通过用户各种方式的大量使用，来发现软件存在的问题与错误，把信息反馈给开发者修改。β测试中厂商获取的信息，可以有助于软件产品的成功发布。

第三方测试。介于软件开发方和用户方之间的测试组织的测试。第三方测试也称为独立测试。软件质量工程强调开展独立验证和确认(IV&V)活动。IV&V是由在技术、管理和财务上与开发组织具有规定程度独立的组织执行验证和确认过程。软件第三方测试也就是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。按照测试技术划分按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不运行程序，通过人工对程序和文档进行分析与检查；静 态测试技术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设 计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、符号执行、 需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分析程序的 执行状态和程序的外部表现。我们这里讨论的白盒测试、黑盒测试、灰盒测试， 在实现测试方法上既包括了动态测试也包括了静态测试。 白盒测试 通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一 个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构 及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。

白盒 测试又称结构测试。 黑盒测试 通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒 子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试， 它只是检查程序是否按照需求规格说明书的规定正常实现。 灰盒测试 介于白盒测试和黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同 时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表 征性的现象、事件、标志来判断内部的运行状态。 灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识 和操作环境。它在系统组件的协同性环境中评价应用软件的设计。 软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周 期。走查、单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。开 发文档和源程序可以应用单元测试应用走查的方法；单元测试可应用白盒测试方 法；集成测试应用近似灰盒测试方法；而系统测试和确认测试应用黑盒测试方法。 1.软件测试过程模型－V 模型 是软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系； 局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到 后期的验收测试才能发现 2.软件测试过程模型－W 模型 模型的基础上，增加千开发阶段的同步测试，形成W模型；测试与开发同步 进行，有利用尽早的发现问题 局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段 完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整 3.软件测试过程模型－H 模型 模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶 段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进 测试模型使用在实际工作中应灵活地运用各种模型的优点 模型:强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、 设计的测试 模型:补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需 求和系统设计的测试；与V 模型相同，没有对软件测试的流程进行说明 模型:强调测试是独立的，只要测试准备完成，就可以执行测试软件测试过程模型 目前主流的开发模型主要有：瀑布模型、原型模型、螺旋模型、增量模型、渐进 模型、快速软件开发(RAD)以及Rational 统一过程(RUP)等，这些模型对于软件 开发过程具有很好的指导作用，但是，非常遗憾的是，在这些过程方法中，并没 有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型无法更好地 指导测试实践。

软件测试是与软件开发紧密相关的一系列有计划的系统性的活 动，显然软件测试也需要测试模型去指导实践。下面对主要的模型做一些简单的 介绍。 模型是最具有代表意义的测试模型。在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成后的一 个阶段，尽管有时测试工作会占用整个项目周期的一半的时间，但是有人仍然认 为测试只是一个收尾工作，而不是主要过程。V 模型的推出就是对此种认识的改 模型是软件开发瀑布模型的变种，它反映了测试活动与分析与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试 过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段 的对应关系，如模型图中所示，图中的箭头代表了时间方向，左边下降的是开发 过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。 模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。 模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性 能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试 和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需 求或合同的要求。

模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶 段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期 的验收测试才被发现。 模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V 模型中增加软件各开发阶段应同步进行的测试，被演 化为一种W 模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于 “尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动 应遵循IEEE std1012-1998《软件验证和确认(V&V)》的原则。 一个基于V&V 原理的W 模型示意图如下所示： 模型应用相对于V 模型，W 模型更科学。W 模型可以说是V 模型自然而言的发展。它强调： 测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设 计同样要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，可 以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需 求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的 验收测试。

如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可 用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早 地面的规格说明书中的挑战。这意味着测试不仅仅是评定软件的质量，测试还可 以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测 试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进 根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用 例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的 测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找 该阶段的设计缺陷。 模型也是有局限性的。W模型和V 模型都把软件的开发视为需求、设计、编码 等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要 有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段。这样就无法 支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本没 有文档的做法下(这已成为一种开发的文化)，开发人员和测试人员都面临同样的 困惑。 模型和W模型均存在一些不妥之处。

首先，如前所述，它们都把软件的开发视 为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相 互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望 有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理 想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以， 相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复 触发、迭代和增量关系。其次，V 模型和W 模型都没有很好地体现测试流程的完 为了解决以上问题，提出了H模型。它将测试活动完全独立出来，形成一个完全 独立的流程，将测试准备活动和测试执行活动清晰地体现出来。 模型的简单示意图如下所示：这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图 中的其他流程可以是任意开发流程。例如软件测试v模型，设计流程和编码流程。也可以是其他 非开发流程，例如，SQA 流程，甚至是测试流程自身。也就是说，只要测试条件 成熟了，测试准备活动完成了，测试执行活动就可以(或者说需要)进行了。 概括地说，H 模型揭示了： 软件测试不仅仅指测试的执行，还包括很多其他的活动。

软件测试是一个独立的过程，贯穿产品整个生命周期，与其他流程并发地进行。 软假测试要尽早准备，尽早执行。 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按 照某个次序先后进行的，但也可能是反复的。 模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试 执行阶段。 其他模型 模型介绍另外一种测试模型，即X 模型，其目标是弥补V 模型的一些缺陷。 软件测试X 模型如下图所示： 模型的基本思想是由Marick提出的，Marick 模型最主要的批评是V模型 无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交 接、频繁重复的集成以及需求文档的缺乏等。Maricke 认为一个模型不应该规定 那些和当前所公认的实践不一致的行为。 模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得 以体现，而且这些可执行程序还需要进行测试，已通过集成测试的成品可以进行 封版并提交给用户，也可以作为更大规模和范围内集成的一部分。

同时，X 模型还定位了探索性测试，即如图中右下方所示。这是不进行事先计划 的特殊类型的测试，诸如“我这么测一下，结果会怎么样”，这一方式往往能 帮助有经验的测试人员在测试计划之外发现更多的软件错误。 Marick 模型提出质疑，也是因为V模型是基于一套必须按照一定顺序严格 排列的开发步骤，而这很可能并没有反映实际的实践过程。因为在实践过程中，很多项目是缺乏足够的需求的软件测试v模型，而V 模型还是从需求处理开始。 Marick 也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过 单元测试而热衷于直接进行集成测试。Marick 担心人们盲目地跟随“学院派的V 模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。 2、前置测试模型 前置测试模型，它是将测试和开发紧密结合的模型，该模型提供了轻松的方式， 可以使你的项目加快速度。 前置测试模型如下图所示： 前置测试模型体现了以下的要点： 开发和测试相结合：前置测试模型将开发和测试生命周期整合在一起，标识了 项目生命周期从开始到结束之间的关键行为。并且标识了这些行为在项目周期中 的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的可能性就 会因此而有所降低。

如果有业务需求，则系统开发过程将更有效率。我们认为在 没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计 和开发之前就被正确定义。 对每一个交付内容进行测试：每一个交付的开发结果都必须通过一定的方式进 行测试。源程序代码并不是唯一需要测试的内容。图中的椭圆框表示了其他一些 要测试的对象，包括可行性报告、业务需求说明，以及系统设计文档等。这同V 模型中开发和测试的对应关系是一致的，并且在其基础上有所扩展，变得更为明 在设计阶段进行测试计划和测试设计：设计阶段是作测试计划和测试设计的最好时机。很多组织要么根本不作测试计划和测试设计，要么在即将开始执行测试 之前才飞快地完成测试计划和测试设计。在这种情况下，测试只是验证了程序的 正确性，而不是验证整个系统本该实现的东西。 测试和开发结合在一起：前置测试将测试执行和开发结合在一起，并在开发阶 段以编码---测试---编码---测试的方式来体现。也就是说，程序片段一旦编写 完成，就会立即进行测试。一般情况下，先进性的测试是单元测试，因为开发人 员认为通过测试来发现错误是最经济的方式。但也可参考X 模型，即一个程序片 段也需要相关的集成测试，甚至有时还需要一些特殊测试。

对于一个特定的程序 片段，其测试的顺序可以按照V 模型的规定，但其中还会交织一些程序片段的开 发，而不是按阶段完全地隔离。 让验收测试和技术测试保持相对独立：验收测试应该独立于技术测试，这样可 以提供双重的保险，以保证设计及程序编码能够符合最终用户的要求。验收测试 既可以在实施的第一步来执行，也可以在开发阶段的最后一步执行。前置测试模 型提倡验收测试和技术测试沿循两条不同的路线来进行，每条路线分别地验证系 统是否能够入预期设想的那样进行正常工作。这样，当单独设计好的验收测试完 成了系统的验证时，我们即可确信这是一个正确的系统。 测试模型的使用 前面我们介绍了几种典型的测试模型，应该说这些模型对指导测试工作的进行具 有重要的意义，但任何模型都不是完美的。我们应该尽可能地去应用模型中对项 目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。 在这些模型中，V 模型强调了在整个软件项目开发中需要经历的若干个测试级 别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅 仅包括程序，或者说它没有明确地之处应该对软件的需求、设计进行测试，而这 一点在W 模型中得到了补充。

W 模型强调了测试计划等工作的先行核对系统需求 和系统设计的测试，但W模型和V模型一样也没有专门对软件测试流程予以说明， 因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为 一个独立于软件开发部的组织，就每一个软件测试的细节而言，它都有一个独立 的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试案例编写， 到测试实施以及测试报告编写的全过程，这个过程在H 模型中得到了相应的体 现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始进行测 试了。当然，X 模型和前置测试模型又在此基础上增加了许多不确定因素的处理 情况，因为在真实项目中，经常会有变更的发生，例如需要重新访问前一阶段的 内容，或者跟踪并纠正以前提交的内容，修复错误，排除多余的成分，以及增加 新发现的功能等。 因此，在实际的工作中，我们要灵活地运用各种模型的优点，在W 模型的框架下， 运用H 模型的思想进行独立地测试，并同时将测试与开发紧密结合，寻找恰当的 就绪点开始测试并反复迭代测试，最终保证按期完成预定目标 --------下面红色部分是赠送的工作总结，不需要的朋友 可以编辑删除！谢谢 行政管理干部个人总结 20XX 年上半年，在公司的正确领导下，在各科室部门的大力支持下，我按照公司的工 作部署和工作要求，严格执行公司的工作方针，围绕中心，突出重点，狠抓落实，注重实效， 在自身工作岗位上认真履行职责，做好各项行政管理工作，较好地完成了工作任务，取得了 一定的成绩。

现将 20XX 年上半年个人工作情况总结如下： 一、抓好自身建设，全面提高素质 我作为一名负责公司行政管理的干部，肩负着公司赋予的重要工作职责，知道自己责任 重大，努力按照政治强、业务精、善管理的复合型高素质的要求对待自己，加强政治理论与 业务知识学习，把它学深学透，领会在心里，运用到具体实际工作中，以此全面提高自己的 政治、业务和管理素质。在实际工作中，我做到公平公正、清正廉洁，爱岗敬业、履行职责， 吃苦在前，享乐在后，全力实践“团结、务实、严谨、拼搏、奉献”的时代精神，提高工作效 率与工作质量，为职工群众做好表率作用，促进公司整体工作发展。 二、刻苦勤奋，全面做好行政管理工作 行政管理工作范围广，日常事物多，涉及车辆、食堂、安全、卫生等方方面面工作，工 作看起来虽然细小，但都与公司的整体工作紧密相关，丝毫不能马虎。为此，我严格要求自 己，精益求精、一丝不苟地认真做好各项工作，确保工作质量，让公司领导放心，让职工群 众满意。 (一)加强车辆管理，保障公司用车需求 我分管公司 辆汽车，按照公司车辆管理要求，认真做好各项工作，确保行车安全。一是抓好驾驶员管理，要求驾驶员必须严格遵守国家法律、交通法规和公司的各项规章制度， 认真学习业务知识，提高驾驶技术，按规定参加安全教育和学习，增强法律观念，确保行车 安全。

二是抓好车辆管理，严格执行派车制度，规范使用车辆派车单，用车结束后，执行车 辆归位制度，将车辆停放在规定范围内。同时要求驾驶员做好日常保养维护、清洗工作，每 月对车辆安全和技术状况进行一次检查，保持车辆性能良好、卫生整洁;做好出车前和收车 后的检查工作，排查车辆存在的安全隐患，坚决不让车辆带病行使。三是做好每月用油统计 分析，包括过路费、保养费和车辆公里数工作，制定好下月用油计划，做好车辆保险年审工