测试中V模型

测试中V模型

V模型

软件测试若使用经典的V模型阶段可以分为

• 单元测试
• 集成测试
• 系统测试

• V模型是最具有代表意义的测试模型 。
• V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。
• 从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。
• 左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。

      用户需求                      验收测试  
        需求分析和系统设计      确认测试和系统测试 
             概要设计         集成测试
                详细设计   单元测试
                       编码

• V模型问题：
• 1.测试是开发之后的一个阶段。
• 2.测试的对象就是程序本身。
• 3.实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
• 4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度

V模型是在快速应用开发 (RAD，Rap Application Development)模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。

下面通过对这种模型的水平和垂直的关联和比较分析，理解软件开发和测试的关系，理解V模型具有面向客户、效率高、质量预防意识等特点，能帮助我们建立一套更有效的、更具有可操作性的软件开发过程。

从水平对应关系看

左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动——审核的过程，也就是静态的测试过程；右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。如：

需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例(Use Case)并策划测试活动。

当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以设计系统的测试方案和测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上是要花去很多时间。

当设计人员在做在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例以开发测试脚本。

在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试可以大幅度提高程序质量、减少成本。

从中可以看出，V模型使我们能清楚地看到质量保证活动和项目同时展开, 项目一启动，软件测试的工作也就启动了,避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。

 

从垂直方向看

水平虚线上部表明，其需求分析、定义和验收测试等主要工作是面向用户，要和用户进行充分的沟通和交流，或者是和用户一起完成。水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行，主要是由工程师、技术人员完成。

从垂直方向看，越在下面，白盒测试方法使用越多，到了集成、系统测试，更多是将白盒测试方法和黑盒测试方法结合起来使用，形成灰盒测试方法。而在验收测试过程中，由于用户一般要参与，使用黑盒测试方法。

 

他通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。可以说，V模型是软件开发测试中最重要的一种模型。
V模型大体可以划分为下面几个不同的阶段步骤，既需求分析、概要设计、祥细设计、编码、单元测试、集成测试、系统测试、验收测试。
需求分析：既你首先要明确客户需要的是什么，需要软件作成什么样子，需要有那几项功能，这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出规格文档说明书。
概要设计：主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
祥细设计：对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。
编码：按照祥细设计好的模块功能表，编程人员编写出实际的代码。
单元测试：按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。
集成测试：经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等。是软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
系统测试：经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。
验收测试：主要就是用户在拿到软件的时候，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。
下边这张表格可以更明确的表述这几种步骤的过程：

名称	目标	活动描述
需求分析	明白客户需要，表述客户需要。	与客户交流，了解客户需求，写出说明书
概要设计	搭构架，明确模块功能，各模块间交互的实现方法，数据传送方法等。	把客户需要细分,确定不同的功能模块，把各模块连接方法，数据传输方法确定。
祥细设计	表述出模块间组合功能实现方法	对各模块进行进一步分析，设计模块间组合功能实现过程，写出伪代码。
编码	写程序	按照设计好的功能模块功能需求，设计不同的功能模块，写出代码，写出连接模块的代码。
单元测试	测试需要的最小单元的功能	按照设定好的最小测试单元（或者叫组件）进行按测试，确保各模块被正确的编译执行。
集成测试	检查单元和单元间组合成后是否存在问题，如组合后的功能，接口等。	将已经分别通过测试的单元模块按设计需求组合进行整体功能，性能等测试。
系统测试	把集成后的软件放到系统中进行测试	搭建不同的计算机软硬件系统，把被测软件放入其中进行的非功能性测试，主要包括安全可靠性，性能等。
验收测试	验证系统是否达到了客户需求	用户进行易用性，兼容性，安装测试等。

对于软件测试过程来说，所有的测试都应追溯到用户需求。软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。所以，V模式要求在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始或者说应该和需求分析一起进行，在进行需求分析的时候就把系统测试用例根据需求文档说明书而作出来，详细的测试用例定义可以在概要设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。这其实是V 模型占软件开发测试模型中重要地位的原因。
从这个角度上来说，就可以这样来考虑：单元测试所对应的是祥细设计环节，也就是说，单元测试的测试用例是和祥细设计一起出现的，在做研发人员做做祥细设计的时候，相应的测试人员也就把测试用例写了出来。集成测试呢，对应的为概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出

 

•需求、功能、设计和编码的开发活动随时间而进行，而相应的测试活动（即针对需求、功能、设计和编码的测试）开展的次序正好相反。

•成功应用V模型的关键因素是设计测试案例的时机。

 

•测试是开发之后的一个阶段。

•测试的对象就是程序本身。

•实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

 

 

V模型体现了测试 设计分层和测试执行 分 层的概念，本文以作者自身的理解谈谈测试执行分层，不过从实际项目运作情况来看，

真正做到测试执行分层的并不多，这里原因有很多种，暂且不论。
 
　 　1. UT

　　单元测试 的对象是LLD中所划分定义的程序单元或模块，它也是 单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。
 
　　UT的目的，是通过函数运行来检查模块代码对于LLD文档的顺从性，验证每个函数的输入输出响应，与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位，下一个实现单位是模块，从测试的角度看，希望UT完成后，每个函数都牢固可靠，下一步的IT测试将聚焦在函数之间配合能否实现分配需求，而不用担心函数本身的输入输出响应问题。
 
　　单元测试比较适合开发人员做。
 
　　2. IT

　 　集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试，集成测试应依据HLD，主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合，至少为两个。
 　　IT的目的，是根据模块设计对模块的分解，从已验证的函数开始，逐层向上集成，得到一个可运行的模块。
 　　IT可以由开发人员做，也可以由测试人员做。
 　　不难看出，UT是面向每一个单元的测试，IT是测试单元之间的 接口，可以把UT/IT归为“单元级”测试。
 
　　3. ST

　　CMM定义的系统测试 ： 系统测试是针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试 ，即不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。

　　可见ST的测试对象是规格说明书，更确切的说，是模块需求规格说明书，所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后，每个模块是牢固可用的。
 
　　4. BBIT

　　BBIT为模块间接口测试，验证模块之间的接口能不能配合，有时和联调混在一起，其实目的并不相同。 BBIT的目的，是根据系统设计对系统的分解，从已通过验证的模块开始，逐层向上集成，得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的 配合测试。MST和BBIT可以归到“模块级” 的测试，一个验证模块，一个验证模块间的接口。
　　以上UT/IT/MST/BBIT一般 由开发人员完成，系统基本可以运行起来了，测试人员可以开展SDV、SIT、SVT了。
 
　　5. SDV

　 　SDV虽然属于测试人员开展的系统测试，但是有点偏灰盒测试，因为SDV验证各子系统的配合是否满足设计需求（DR），对内部的实现还是关注的，验证多个模块集成以后是否满足设计需求。
 
　　6. SIT

　　SIT也是验证设计需求是否得以 满足，与SDV不同的是，SIT完全把系统当作一个黑盒来测试，不关心内部具体的实现。实际应用中，SDV和SIT 虽然都属于系统一级的测试，往往由不同项目组（子系统）的测试人员分别测试，他们只关注各自的子系统，所以还是把SDV和SIT归为“子系统级”的测试比较好。
 
　　7. SVT

　　SVT是验收测试，其测试对象是产品包需求OR。产品包需求 给出了产品的范围，从产品可能的应用环境的角度刻画系统，SVT的目的就是确认（或验收）产品包需求给出的各种应用场景产品均能满足。
　　 产品包需求不考虑内部实现的差异，SVT也是从整个系统的角度考虑包需求的各种应用场景，属于“系统级”的测试。
　　各个级别的测试描述完毕，回头再看看这个分层测试的模型图，不难发现以下几个特征：
 
　　1）基于系统架构的分解结构（系统－子系统－模块－单元），开发按照自顶 向下的顺序逐层设计，测试按照自底向上的顺序逐层验证，这个分解结构在每一层或每一个阶段，将开发和测试过程统一起来。
　　2）在每一层， 测试的对象是开发相应阶段设计的输出（包括需求和这个阶段的设计文档），测试的目的与开发相应阶段设计的思路是相辅相成的，所以决定每个阶段的测试如何开 展、评价一个测试过程时，如果离开开发过程，只谈测试自身的话，是不系统、不全面的。
　　3）除了“系统级”的SVT测试以外，其他 各层的测试均包含两个方面：一是对这个层每个构件的测试，有n个构件就要测试n次，二是这n个构件之间接口的测试。例如：nSDV（每个测试项目组的SDV是一个SDV）和SIT、nMST（每个开发项目组 的MST是一个MST）和BBIT、nUT和IT。

 

 
转:

　　最近在各博客中看到不少同仁在聊现在越来越热的测试技术和测试工程方法，而本人也在一个通讯公司专职测试摸爬滚打了多年，其中有些心得，希望使用容易理解的语言组织成系列和广大同仁分享。其中可能涉及测试技术、测试设计方法、测试建模、测试流程/开发流程、测试管理、测试度量等方面，如有不确之处，还请多多讨论。

　　搞技术的都知道，技术钻研的越深，越容易有技术情节，但不论如何，测试本身就是一个发展中的行业，特别需要不同方面的声音，希望大家着重关心不同情况下适用的技术本质，而不是无谓的争吵。

　　总体来介绍一下一般的测试活动，目前一般比较上规模的创新技术公司或企业，会设立专门的测试岗位，而测试岗位根据具体职位不同有很大的区别，例如厂验（出厂测试，抽样检验产品的合格率），SIT系统集成测试（在开发后期，根据用户使用场景进行测试），SDV系统设计验证（在系统开发阶段，转测试的第一个环节）等等，总体来说，测试工作越向前介入开发阶段，测试含金量越高。而目前各大技术公司逐渐从瀑布、螺旋开发模式逐渐向迭代开发、增量开发、敏捷开发靠拢，越来越关注测试在设计阶段的重要作用，这些都会在后面系列逐一介绍。

　　我们一般用户接触到的也有测试，例如最近Firefox的Beta测试，微软的体验测试等，这些测试都有一个共性--看不到系统的实现方式，纯黑盒体验测试。方才也提到，测试活动越靠前，越了解系统，越懂得各个开发阶段所使用的测试方法。

　　在瀑布模型中，开发一般必做的是单元测试，自己写代码，自己打桩写测试代码，主要验证语法、逻辑等基本问题，这里有个问题，测试有个主要的思想是“避免让程序员测试自己的程序”，这是一般是指系统测试，开发人员进行单元测试的效率是很高的，首先自己保证没有导致编译不通过的低级错误、内存泄露等隐藏很深的错误，此类错误在系统测试也可以测试，但成本太高；同事之间的代码Review也是很好的错误检测方法；在各个模块接口完成后，可以进行基本功能联调，这时出现的接口问题是主要的拦路虎。一般有积累的系统，会使用模拟器仿真系统，在实际仿真环境调试，这样效率很高。

　　对于转测试后的系统，一般有BBIT、SDV、SIT、发布测试等环节，BBIT是在开发系统转测试前，由测试人员对开发人员交付的系统进行转测试验收的测试活动，保证转测试的系统满足可测试性要求，如果是分几段合入得子特性，也可以做BBIT测试，依避免新合入的特性对主线版本较大的质量冲击，BBIT 测试是一个很好的测试把关环节，如果BBIT不通过，可根据情况打回版本或特性，并针对DI（遗留缺陷）进行质量回溯，避免重复错误。SDV测试时针对系统中不同的功能特性进行单独验证，一般是搭建一个完整的系统环境，由不同的测试人员进行单个功能特性测试，例如通信系统中OSPF、BGP、MPLS LDP等是组成路由器的核心功能，可以由三个测试人员分别验证这三个特性，可根据特性规格、产品规格、标准、使用场景等进行单个特性的功能点测试，保证单个特性的可交付性，这里，在SDV阶段一般不进行性能测试和压力测试，因为此时在基本功能还存在Bug的是否进行性能、压力测试只能让开发忙于解决致命问题，可能有火上浇油的意思，而没有时间思考和反复验证合入的修改代码是否会引起新问题。在SDV各个功能点验证基本充分后时，可以进行性能摸底测试，输出性能摸底报告，给出性能结论。此时，如果性能远不满足要求，而提升的手段也不足以产生质的变化时，这时，就有必要反思一下系统设计阶段的结论了。例如在非常复杂的路由器系统中，可以使用性能建模来分析将来系统的指标。SIT测试中，主要是针对实际应用场景进行特性叠加测试，例如一般在接入侧用户会同时使用 OSPF和MPLS完成域内隧道搭建，这两个特性同时使能是否会有干扰，例如目前很火的VPN技术就是BGP+MPLS的交叉技术，此时在系统中同时使能 L3VPN+MPLS+BGP+OSPF是否可以顺利完成各自的功能，性能是否有影响等。

　　总之，测试层次分的越深，各个环节的输入件和交付件的质量关系到整个测试环节的整体质量。后面的系列中会介绍在测试流程中的各个环节是如何紧密结合的，各个环节的输入和交付件等。