软件生命周期(SDLC, Systems Development Life Cycle)是软件开始研制到最终被废弃不用 所经历的各 个阶段。— 软件开发模型
在周期内,我们无论是开发还是测试都依赖于某个模型进行作为依据,有效地提高开发、测试效率。
在软件开发的实践中,人们总结了很多软件的开发模型来描述和表示一个复杂的开发过程,如果瀑布模 型、快速原型模型、螺旋模型等。
软件测试与软件开发模式有着紧密的关系,作为一名测试人员,应该充分理解软件的开发模式,尽快的 找准自己的位置,从而尽快的发挥自己的价值。
瀑布模型
瀑布模型是线性模型的一种,在所有的模型中占有重要的地位,是所有其他模型的一个基础。瀑布模型如同工地里的建造盖房流程,使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果 达不到要求的输出,下一阶段的工作就不展开。
测试的切入点,开发完成后,必须留给测试足够的时间给测试人员,否则可能会导致测试不充分,导致 很多问题到项目的后期才体现出来。
优点
明确划分了软件生命周期的各个环节。 强调早期软件计划,需求分析比较重要。 清晰的工作流程,便于分工协作。 适合需求稳定的产品开发。 每个阶段都有一个检查点。
缺点
线性的开发流程,存在巨大的风险。 依赖于早期的需求调查,不适应需求的变化,单一流程不可逆。 风险在后期可能才会暴露,且无法纠正,导致项目的失败。 无法保证用户的产品需求不变,开发过程无法更改。比如盖房子,照着图纸打好的地基可以承载7 层楼,现在用户突然要加五层,那么地基就得重打,已经盖好的楼就得爆破,当然这是不可能的操 作。
改良
沿用瀑布模型的线性思想,细化了各个阶段,在某些重要关注的阶段之间掺入迭代的思想。问题的定义及规划 确定软件开发目的以及可行性,指定开发计划。
需求分析 在确定软件开发可行性正确下,对软件所需的功能进行详细分析,明确客户需求,输出原型 图。
软件设计 概要设计:架构的实现,表述各模块功能、模块接口和数据传递等事务。 详细设计:对表述的 各模块深入分析,要求达到代码级别,将程序具体的实现描述出来,以及数据库设计。
软件编码 按照详细的模块功能表,编程人员编写出计算机可运行代码。
快速原型模型
在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。
第一步是构建一个快速原型,实现用户与系统的交互,用户对原型进行评价,进一步细化待开发软件的 需求,通过逐步调整原型使其满足用户的要求,开发人员可以确定用户的真是需求是什么。
第二步是在第一步的基础上开发出用户满意的软件产品。
优点
克服瀑布模型的缺点,更好的满足用户的需求并减少由于软件需求不明确带来的项目开发风险,适合预 先不能确切定义需求的软件开发。适合开发小型的、灵活性高的系统。
缺点
不适合大型系统的开发,前提要有一个展示性的产品原型作为参考,因此在一定程度上可能会限制开发 人员的创新。
螺旋模型
将开发过程分为螺旋周期,每个螺旋周期和瀑布模型相符,沿着螺旋线旋转,坐标轴的四个象限表示四个活动。
1988年由 巴里·勃姆 提出的软件开发模型升级版,兼顾了瀑布模型的优点。 螺旋模型 的核心就在于不需 要在刚开始的时候就把所有事情都定义的清清楚楚。轻松上阵,定义最重要的功能,实现它,然后听取 客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到用户满意的最终产品。
制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件; 风险分析:分析评估所选方案,考虑如何识别和消除风险; 实施工程:实施软件开发和验证;
客户评估:评价开发工作,提出修正建议,制定下一步计划。 螺旋模型很大程度上是一种风险驱动 的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。
螺旋模型的优点 引入了其他模型不具备的风险分析,使得软件遇见风险时可以停止,减少损失。 要求每 个迭代阶段都需要构建原型,进行软件测试以减小项目开发风险。 整个过程有较高灵活性,开发过程的 任意阶段自由应对变化。
缺点需要测试人员有丰富的风险评估经验和专业知识才能及时标识风险,减少软件缺陷损失,过多的评 审迭代,造成开发成本压力。
敏捷开发模型
软件测试 & 软件工程
软件测试是软件工程的一部分,并且是整个软件工程组成中不可或缺的部分。
在软件工程、项目管理、质量管理得到规范化应用的企业,软件测试也会进行的比较顺利,软件测试发 挥的价值也会更大。
而我们要关注的是,软件工程、项目管理、质量管理、配置管理与软件测试的关系,在不同的软件开发 模式下,如何进行软件测试。
随着软件测试的发展,测试人员在大量实践中总结出一些测试模型,对测试活动进行抽象,如V模型、W 模型等。
V模型(掌握)
V模型是最具代表意义的测试模型,最早是由 Paul Rook 在20世纪80年代后期提出,由英国国家计算机 中心发布,旨在改进软件开发的效率和效果。
在V模型推出之前,人们通常吧测试过程作为在需求分析、概要设计、详细设计、编码全部完成后的一个 阶段,尽管在那个时候,已经出现了有的测试工作会占用项目周期的一半时间,但是大多数人仍然认为 测试只是一个收尾工作,而V模型的推出,就是为了改变行业对测试的普遍认识。
V模型本身是软件开发中瀑布模型的变种,它反映了测试活动与分析和设计的关系。 V模型标明了测试过程中本身存在的不同阶段,从左到右,描述了开发过程间的阶段对应关系。
V模型和瀑布开发模型有着一些共同的特性,V模型中的过程从左到右,描述了基本的开发过程和测试行 为。
在开发做用户需求的时候我们测试就可以准备验收测试,需求分析的时候就可以去做系统测试的用例也 就是说测试一直可一介入同步,节约时间 大大提升效率
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段 和 开发过程期间各阶段的对应关系。 局限性:把测试作为编码之后的最后一个活动,需求分析等前期产生 的错误直到后期的验收测试才能发现。
V模型的优点
V模型既包含了底层测试有包含了高层测试:
底层测试,如单元测试。 高层测试,系统测试。
V模型清晰的标出了软件开发的各个阶段。
V模型自顶而下逐步求精的方式把整个开发过程分成不同的阶段,每个阶段的工作都很明确,因此
便于控制开发过程,当所有的阶段都完成后,该软件开发过程也随之结束。
V模型的缺点
缺点也显而易见,正是它自身的顺序性导致,只有到了测试阶段,才开始执行测试流程。但有些错 误直到这时才被发现,甚至无法发现,沉珂已久,回天乏术… 另外,在实际的开发过程中,在需求阶段很难把用户的需求完全明确下来,因此,当需求变更时将 会导致阶段反复(如重新分析需求、设计、编码、测试等过程),返工量非常大,模型灵活性比较 低。
改良:正如开发瀑布模型的改良一样,在相关步骤中进行小的迭代工作。
W模型(熟悉)
IEEE Std1012-1998《软件验证和确认》原则中提出在软件需求设计阶段,也得有测试活动。 W模型由 Evolutif 公司提出,在软件开发中,开发一个V,测试一个V,组合而来的W,所以W模型也称双V模 型。
测试伴随着整个软件开发周期,并且测试对象不仅仅是程序,需求和设计阶段同样需要测试。
开发和测试的协调工作图,绿色为开发V,橙色为测试V。
W模型优点
测试伴随整个软件开发生命周期,测试对象不仅仅是程序,需求和概要同样需要测试。 更早介入测试,可以更好的发现需求设计中的缺陷,修复成本也更低。 同样分阶段工作,便于控制项目过程。
W模型缺点
依赖于软件开发和测试的前后线性关系,还是无法解决需求变更调整的问题。也就是无法支持迭 代,自发性和需求变更调整。 对于有些项目,在执行过程中根本不产生文档,那么W模型也基本无法适用(小型公司直接产出原 型图,并不写需求说明书)。 W模型的技术复杂度较高,对于需求设计和测试人员要求较高,实践起来,门槛较高。
一般,仅有中大型企业使用W模型。
H模型(了解)
在实践中,人们发现,虽然软件开发中的需求、设计、编码等被分阶段执行。但是并不是完全串行执行 的,更多的是交叉、迭代进行。 所以,有专家就提出了H模型,H模型将活动完全独立出来,形成一个 完全独立的流程,同时将测试准备和测试执行也清晰的表现出来。
H模型的测试流程
测试准备:所有测试执行活动的准备,判断是否到测试的就绪点。 测试就绪点:测试准入准则,即是否可以开始执行测试的条件。 测试执行:具体的执行测试的程序。
其他流程
具体开发中的流程,比如设计流程、小型迭代工作。
H模型的优点
H模型揭示了软件测试除了测试执行外,还需要有很多的其他工作。 软件测试完全独立,贯穿整个生命周期,且与其他流程并行进行。 软件测试活动可以尽早的进入准备阶段,尽早执行,灵活性较强。 软件测试可以根据被测对象的不同可以分为多层次、分阶段、分次序的执行,同时也是可以被迭 代。
H模型的优点
管理型要求高:由于模型的灵活性,必须有相应清晰的规划和管理制度。否则测试过程将非常难以 管理控制。
技能要求高:H模型要求能够很好的定义每个迭代的规模,不能太大也不能太小。 测试就绪点分析困难:在测试阶段,我们并不知道测试准备到什么程度算是合适的,也就是就绪点 很难把握。比如说就绪点在哪里?就绪的标准是什么?这对测试的执行带来很大的困难。 对于整个项目的人员素质要求非常高:在规范的制度下,工作的效率很高,但是由于个人的技能不 足,会导致因为一个点出问题,导致整个项目的进度受到干扰。
H模型虽好,但是,大家很少用,因为H模型对于上到管理层,下到各项目组成员的要求非常高。
V、W、H模型总结
V模型适用于中小企业。 W模型适用于中大型企业,因为对于项目组成员要求高。 H模型对项目组成员要求非常高,很少有公司采用。
一、问题的定义及规划—产品 主要确定软件的开发目的及其可行性。制定项目总体开发计划。- -初步需 求 二、需求分析 —需求评审会议 在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细 分析,明确客户的需求(需求评审–产品,开发,测试),输出需求规格说明书终版(原型图)。
三、设计— 开发文档 把需求分析得到的结果转换为软件结构和数据结构,形成系统架构。概要设计:主要是架构的实 现,指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。详细设计:对概要设计中 表述的各模块进行深入分析等,其中需要包含数据库设计说明。
四、编码–写代码 按照详细设计好的模块 功能表,编程人员编写出计算机可运行的程序代码
五、软件测试 软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正 测试的方法主要有白盒测试跟黑盒测试两种。建立详细的测试计划并严格按照计划进行。
单元测试:主要是测试程序代码,为的是确保各单元模块被正确的编译,比如有具体到模块 的测试,也有具 体到类,函数、方法的测试等。—一般是开发自己测试
集成测试:单元测试后,将各单元组合成完整的体系,测试软件单位之间的接口是否正确、 数据能否正常 传递。—注册与登陆
系统测试:把软件系统搭建起来,按照软件规格说明书中所要求,测试软件其性能功能等是 否和用户需求 相符合,在系统中运行是否存在漏洞等。—多轮测试’完成输出测试报告
验收测试:主要就是用户在拿到软件的时候,在使用现场,会根据前边所提到的需求,以吸 规格说明书来做 相应测试,以确定软件达到符合效果的。----不是去测试去测试一般是产品或者开发或者老板去验收 一般 验收核心功能 六,运行维护 软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使 用后,由于多 方面的原因,软件不能继续适应用户的需求。要延续软件的使用寿命,就必须对软件进行 维护 。软件的维护主要包括纠错性维护(修复bug)和改进性维护(增加功能)两个方面。
a测试是由一一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的 受控测试:a测试不能由程序员或测试员完成。也有可能不在公司里测试 看公司要求 比如我是小米内测我 就要去网上申请自己手机体验— 测试开发在场— 直接修复(这个公司标准不一样也不一定在场)
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。 开发者通常不在测试现场,
Beta测试不能由程序员或测试员完成。
灰度测试。系统测试通过后,将测试版本发布到线上环境,替换部分的线上服务器进行预测试。当灰度测试
结束后,线上版本实现会统-.本质上是上线前的测试,收集用户的反馈
A/B测试 指的是系统测试通过并发布后,同个软件功能不同的用户会看到不同的实现方式,收集每个用 户的反馈。本质上是上线后的测试,收集用户的反馈。
作者:软件测试开发-虚竹
原文链接:https://blog.csdn.net/shuaigezhou10086/article/details/110844590