软件定制网

觅识小课堂《软件生命周期详解》-软件测试第4篇

三人觅识2019-02-13 14:33:40

软件生命周期详解


    大家好,我是十一,前面我们已经为大家准备了测试和开发的现状分析,概念,行情以及需求介绍,今天我们就软件生命周期进行详细的解说。让大家整体的认识下软件的"成长历程"。


    什么是软件生命周期?


    软件生命周期是软件从产生到废弃的整个过程,周期内有问题定义、可行性分析、需求分析、系统设计、编码、调试和测试、部署/发版、维护升级到废弃等阶段。


    那软件生命周期各个阶段都是什么呢?


    我们先看张购物图(为了这张图我眼睛也是要废了~)


    

    上图呢就是一个完整的淘宝定制购物过程图了,那么购物过程跟咱们软件又有什么关系呢?整个过程对比《浅聊软件开发》里的软件生命周期图你能一一对应上吗?



大家先自己想想~(来,闭上眼睛,想一想~)


    好啦,我来揭晓答案,大家看看你想的对不对!


    首先,为故事找一主人公,暂且叫心心吧,心心定制了需求,然后跟客服沟通是否可做(需求可行性分析),沟通后选择喜欢的样式、尺码等下单,商家拿到订单后根据订单要求出设计图(原型设计),出图后跟心心沟通看是否是心心想要的(需求确认),得到肯定答复后投入生产(开发),生产完成后内部质检员检查(测试),检查无误后快递给心心(上线/发版),心心拿到衣服开始试穿以及查看是否有质量问题(测试),很满意此次购物,于是给了满意好评后,订单关闭,整个购物过程完成。


    大家可能会说那支持维护没体现呀?


    那如果心心穿了一周后发现衣服有掉色/图案一洗就花了等等质量问题呢?是不是就该去找客服了,跟客服沟通后商家会进行处理,换货/退货/修复等等,这个就是支持维护啦。


    注意哦:购物图中的“商家根据要求出设计图样式” 这个跟软件流程图中的设计不是一个东西!


  • 商家根据要求出设计图样式:是原型设计,即做一个静态的类似成品展示给客户,让客户确认是否是自己想要的,属于需求确认

  • 软件流程图中的设计:是开发设计,设计要实现产品那么需要用的语言、框架、技术等等;对应购物图中的商家生产部分,商家生产前需要决定各种用什么布、线、缝制方式、配图材料/方法等等。


    上述整个过程其实跟实际的软件产品的整个流程比较贴切了。你了解了吗?我画了一张完整的软件流程图,供大家欣赏~





    下面我们依据上图来分别介绍各个阶段。着重介绍每个阶段的概念以及参与者。 



需求定义(Ruquest for Proposal):

描述:定义出本次任务都需要做什么,做成什么样子(比如,买家跟卖家说我要什么样子的衣服,然后双方开始协商,最终达成一致意见,这个过程就是需求定义)。

参与者:产品经理,需求,客户

可行性分析:

描述:由项目组相关成员去研究需求是否可行,能不能做出来(比如:商家拿订单需求去找设计和工厂,问设计图形或者样式能否做出来;问工厂在相应的布料上能不能做出设计图样式的衣服,这个过程就是可行性分析)

参与者:产品经理,项目经理,开发,架构师

需求分析/用户需求(Requirements Analysis):

描述:需求分析其实是在做需求细化,按照任务说明书中的任务内容和指标具体细化各个点,细化到每个框每个按钮的样式,输入输出等各项值(比如:设计和工厂分别就这个衣服做材料分析,分析出这个衣服需要多少布料,扣子什么样式、颜色,不同布料具体用多少等等,这个过程叫做需求分析);统一整理编写成《需求说明书/需求规格说明书》。

参与者:产品经理,项目经理,测试/质量管理员(很多公司把这个统称为QA),开发,架构师


评审:(从图中可以看出,各个阶段几乎都需要做评审,在此处统一描述)

描述:评审就是做审查,对这个阶段的工作进行审查,看是否偏离或者有遗漏(比如:设计和工厂的各个环节都有相关的审查,审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等,这些审查都是评审);评审一般由相应工作人员来参与

参与者:每个阶段的评审一般都是各职能部门内部审核,也可以申请其他相关人员审核,比如需求评审,一般是产品经理、项目经理、测试、开发一起评审;系统设计一般是项目经理、开发评审;测试策略评审一般是测试组内部评审等等

开发线
0
1

设计(Design):

描述:

架构师根据需求确定产品或者项目的场景、特点,选择合适的框架,技术使项目实现最优化。在此上将系统进行概要设计,包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计,包括接口参数、参数等。此处设计会形成概要设计文档和详细设计文档。

参与者:项目经理,架构师,开发,测试


编码(Coding):

描述:开发人员根据详细设计文档对系统进行模块化开发,在确定参数和接口的情况下,根据需求对模块内部进行方法级别的设计和编码以及自测,对产品功能进行一一实现

参与者:开发


提测:

描述:开发人员完成一个小迭代/小功能,且完成自测(开发编码完成后,一般都会自己检测下),于是向测试部门发起提测,一般以邮件方式或者任务管理工具任务流方式向测试部门通知xxx模块/功能可以测试

参与者:任务责任人(开发)、测试



测试线
0
2


测试策略:

描述:测试组长要根据《任务说明书》和《需求说明书》来决定此次测试的思路/类别(功能测试/性能测试/文档性测试或者几种组合)、测试方式方法、flag(任务指标,做到什么程度)等。也有很多公司把测试策略作为测试方案中的一部分。

参与者:测试组长/测试leader/自身的测试工程设计师


测试计划(Testing plan):

描述:测试组长要根据《任务说明书》和《需求说明书》开始编写《测试计划》,其中包括人员,软件硬件资源,测试点,集成顺序,进度安排和风险识别等内容。

参与者:测试组长/测试leader


测试方案

描述:测试方案一般由对需求很熟的高资深的测试工程师设计,测试方案要求根据《需求说明书》上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案

参与者:测试工程师


测试设计:

描述:主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的,测试用例需要包括测试项,用例级别,预置条件,操作步骤和预期结果。同样,测试用例也需要评审。

参与者:相关测试工程师


测试执行(Testing)

描述:

根据测试用例对开发提测部分进行,通过的标记通过,不通过的提交有质量的Bug(问题缺陷)。这里要说下bug,测试对出问题的部分提交bug到相关开发工程师,开发根据问题描述,进行修订,修订完成后会将bug流转给相关测试人员(通过缺陷管理工具分配/邮件通知相关测试人员bug修订完成,可测),测试需要对bug以及bug相关模块进行测试回归。

参与者:相关测试工程师、责任开发工程师


测试报告:

描述:最终测试完成(所有测试用例通过/已挂起)会出测试报告对以上测试进行总结性描述。

参与者:相关测试工程师


部署/发版(Deploy):

描述:经过前面的各个阶段,产品已经可以出售或者面见大众了;由测试进行冒烟测试,冒烟测试通过后配置管理人员进行封版、版本制作(针对产品来说)/部署上线(针对项目应用来说)。

参与人:配置管理人员,测试


支持维护(Production Support):

描述:支持维护类似于我们日常中的售后,主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。

参与人:支持维护人员/售后工程师

    以上就是整个软件的流程介绍了,内容有点多,但是我希望你能认真的看完,并且加以理解变成你自己的知识。


注意:以上的软件开发流程只是一个最基本的模板,但是公司内部有自己的组织架构,可根据项目酌情调整。只要适合自己的项目那么就是对的,就是好的。




     好了今天的内容到此结束,欢迎进群与我沟通!我们下次再见~


    我想听见你的声音,关注公众号,回复”加入觅识帮“,识别群二维码,期待你的加入。


让我们共同相伴,开启软件知识之旅。


关注我们