软件的生命周期&测试流程

软件生命周期

软件生命周期(SDLC,Systems Development Life Cycle)是软件开始研制到最终被废弃不用所经历的各个阶段。 —软件开发模型

瀑布型生命周期模型

在1970年人类整理了第一个软件生命周期,即瀑布型生命周期模型也叫瀑布模型。规定了它们自上而下,相互衔接的固定次序,如同瀑布流水,逐级下落,具有顺序性和依赖性。每个阶段规定文档并需进行评审。

在这里插入图片描述

缺点:
1.测试接入项目比较晚,前面的阶段持续问题,不能得到及时发现;
2.出现问题,回溯周期非常长,项目周期长,浪费时间 --项目效率低

V模型

RAD(Rap Application Development,快速应用开发)模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,又称软件开发的V模型。通过开发和测试同时进行的方式来缩短开发周期,提高开发效率。
在这里插入图片描述
系统测试用例根据需求说明书编写出来的。
集成测试用例根据概要设计中模块功能及接口等实现方法编写出来的。
单元测试的测试用例是和详细设计一起出现的,在研发人员做详细设计的时候,相应的测试人员也就把测试用例写了出来。

优点:1.提早介入项目里,提早发现,回溯成本比较低
2.测试提前在准备测试文档(测试用例)–做测试执行依据—可以执行测试==节省准备文档时间→提高项目效率,周期拉短

在这里插入图片描述

问题的定义及规划 --产品

主要确定软件的开发目的及其可行性。制定项目总体开发计划。 --初步需求

需求分析 --需求评审会议

在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析,明确客户的需求(需求评审–产品,开发,测试),输出需求规格说明书终版(原型图)。

设计 – 开发

把需求分析得到的结果转换为软件结构和数据结构,形成系统架构。
概要设计:主要是架构的实现,指搭建架构,表述各模块功能,模块接口连接和数据传递的实现等项事务。
详细设计:对概要设计中表述的各模块进行深入分析等,其中需要包含数据库设计说明。

编码 --写代码

按照详细设计好的模块功能表,编程人员编写出计算机可运行的程序代码

软件测试

软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以改正。

测试的方法主要有白盒测试和黑盒测试两种。建立详细的测试计划并严格按照计划执行。

单元测试(白盒测试):主要是测试程序代码,为的是确保各单元模块被正确的编译,比如由具体到模块的测试,也有具体到类,函数,方法的测试等。

集成测试(灰盒测试 == 接口测试):单元测试后,将各单元组合成完整的体系。测试软件单位之间的接口是否正确,数据能否正常传递。

系统测试(黑盒测试–要求低,入门,几轮):把软件系统搭建起来,按照软件规格说明书中所要求,测试软件其性能功能等是否和用户需求相符合,在系统中运行是否存在漏洞等。

验收测试(UAT–不是测试人员做的):主要就是用户在拿到软件的时候,在使用现场,会根据前边所提到的需求,以及规格说明书来做相应的测试,以确保软件达到符合效果。

用户驱动 --用户验收 --核心功能(功能,性能,安全)
产品,老板 --验收

运行维护

软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的需求。要延续软件的使用寿命,就必须对软件进行维护。软件的维护主要包括纠错性维护和改进性维护两个方面。
纠错性维护:bug–修复–打版本–发布上线–发布项目
改进性维护:优化 添加功能–打版本–发布上线–发布项目

在这里插入图片描述
α测试:内测 —用户公司(测试环境 --搭建一个模拟用户环境) —公司内部,测试 开发在场 --直接修复
β测试:公测 --beta版本:真实的用户现场测试 --测试开发不在场

敏捷开发模型

从1990年开始逐渐引起广泛关注,是一种以以人为本,快速迭代,循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用的状态。
在这里插入图片描述

软件测试的基本流程

测试需求分析阶段:阅读需求,理解需求,主要就是对业务的学习,分析需求点。参与需求评审会议

测试计划阶段:编写测试计划,参考软件需求规格说明书,项目总体计划,内容包括测试范围(来自需求文档),进度的安排,人力物力的分配,整体测试策略的制定,和风险的评估与规避措施有一个制定,一般有测试负责人编写,当然我们可能也会参与相关的评审工作。

测试设计阶段:主要任务是编写测试用例,会参考需求文档(原型图),概要设计,详细设计等文档,有不明确的也会及时和开发,产品经理沟通。用例编写完成后会进行评审

测试执行阶段:首先搭建测试环境,执行预测(冒烟),以判定当前版本可测与否,如果预测通过,正式进入系统测试(2-4轮),遇到问题提交bug到缺陷管理平台,并对bug进行跟踪,直到被测软件达到测试需求要求,没有重大bug,测试结束。 ----(优化,完善测试用例)

测试评估阶段:出测试报告,对整个测试的过程和版本质量做一个详细的评估(剩余bug数量/严重程度,测试用例的覆盖率)。确认是否可以上线。

UAT测试阶段:部署到UAT测试环境,由产品或者领导来验证功能。

笔试题:
1.生命周期模型包含哪些阶段?开发模型是什么? --敏捷
2.测试流程包含哪些阶段?

面试题:
1.开发流程是怎样的?
2.测试流程是怎样的?各个阶段的输出是什么?(需求,计划,用例,bug,报告)
3.开发环境,测试环境,生产环境,预发布环境是什么?
在测试环境后台添加的数据和信息,能够在生产环境看到? --不能

开发环境–开发自测的环境,开发使用
测试环境–测试人员执行测试环境,测试自己维护(运维维护)
生产环境–用户环境(正式),发现上线 --部署到生产环境,用户可以直接使用(不能有测试数据)
预发布环境(UAT环境)–上线之前做的验收测试环境 --验收测试

4.项目发布流程是什么?
发布上线流程:开发测试工作–测试通过(测试报告评估之后,测试通过)–发邮件告知(项目经理,产品,开发,运维)–验收测试通过–开发把最终测试通过的版本打包(签名-包名)–运维,运营,开发,产品–部署到生产环境上–测试验证一下(测试数据不留)–通过–上线成功!

  • 16
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值