软件测试`

1.软件测试

1.1软件测试初识

测试在我们生活中也是非常常见的,比如我们去商场买衣服.整个购买衣服的就包含了测试

外观测试:对服装店内的衣服挑选,测试是不是符合自己的审美

试穿测试:穿上衣服测试是不是合身

面料测试:测试衣服是腈纶,纯棉....

价格测试:询问价格,测试是否超出心理预期

最后完成购买

1.2 软件测试的定义

软件测试就是验证软件产品特性是不是符合用户的需求.

软件产品的特性包含:功能测试(都包括什么功能),性能测试(客户端发送请求,服务器的响应速度),界面美化,易用性(用户第一次使用能否快速上手)等,软件特性还包含很多方面.

高频面试题1:

软件测试开发工程师和测试工程师的区别

        相同点:

                1.都统称为测试人员

                2.都是对产品质量进行测试,保障产品质量

        不同点:

                测试开发只是比测试多了"开发"两个字,这两个字并不是后端负责的业务开发,而是                     这里指的是需要开发测试效率的工具.通过效率工具来提升效率和测试质量

                比如自动化测试,性能测试等就是效率工具.

高频面试题2

⾛测试岗位为什么还要学习开发知识?
1)测试⼈员也需要编写代码,如⾃动化测试、性能测试、开发测试效率⼯具等。测试⼈员
需要能够看懂代码、了解开发框架。
2)学好开发知识能够提⾼软件测试质量。通过查看代码中数据的⾛向能够更好的从代码层
⾯去发现问题。
为什么⾛测试岗位⽽不⾛开发岗位?
回答思路:从岗位⼯作性质分析+个⼈性格/爱好+个⼈职业规划三个⽅⾯阐述。
1)个⼈兴趣爱好:从性格和兴趣出发,测试⼯作需要测试⼈员具备良好的耐⼼、细⼼,接
触了测试内容后对测试⼯作产⽣浓厚兴趣
2)岗位性质:不管是测试还是测试开发都统称为测试⼈员,测试⼈员主要以保障项⽬测试
质量为主,通过开发⼀些测试效率⼯具(⽐如我们学的⾃动化就是效能⼯具,除此之外还
有我们课件上写的内存泄漏⼯具等等)来提⾼测试效率。⽽软件开发主要以业务编码为
主。
3)个⼈职业规划:⼤学期间就树⽴了⾛测试⽅向的⽬标,今后将继续提⾼测试和开发能
⼒,争取在测试领域做出⼀番有影响⼒的事务

2.软件测试基本概念

2.1 需求

    2.1.1用户需求

             用户需求是指用户在使用产品、服务或系统时所期望满足的各种需要和期望。一般用户需求就是没有经过评估就提出的要求

    2.1.2软件需求

        软件需求是指用户对软件系统在功能、性能、可靠性、易用性、安全性等方面的期望和要求,以及软件系统在运行环境、开发约束等方面的规定。它是软件开发的基础和依据,对整个软件开发过程起着关键的指导作用

举个例子:

⼥朋友饿了的例⼦
⽤⼾需求:
⼥朋友说, 我饿了, 这是⼀个⽤⼾需求. 很简略.
软件需求:
需要你和她反复的沟通了解更加详细具体的需求, 来制定解决⽅案.
⽐如你问她, "想吃啥?", 她说, "随便"
"吃⽶饭炒菜?", "不想吃"; "那你想吃啥?", "随便"
"吃油泼⾯?", "不想吃"; "那你想吃啥?", "随便"
...
最终理解清楚⽤⼾需求之后, 知道⼥朋友想吃的是你做的红烧⾁, 那么再去研究⾁怎么买, 怎么做等等的具体步骤, 是软件需求

2.2.开发模型

在介绍开发模型之前我们要先介绍下什么是软件开发流程

2.2.1 软件的生命周期

所谓的生命周期就是一个人的一生,从嘤嘤啼哭到寿终正寝,这中间的一生就是一个人的生命周期

而软件的生命周期包括

需求分析--->计划--->设计---->编码--->测试---->运行维护

下面我们用盖房子来举例,假设我是一个贼有钱的开发商

上面盖房子的流程也可以对应我们的软件生命周期,那么软件生命周期中每个对应的流程都做了什么事?

2.2.2 常见开发模型

软件开发模型是指软件开发全部过程、活动和任务的结构框架,它的作用主要体现在以下几个方面

提供清晰的流程指导,便于项目管理和监控,促进团队沟通与协作,降低开发风险,提高软件质量

2.2.2.1 瀑布模型

瀑布模型优缺点
优点缺点
强调开发的阶段性;
1.线性结构,每个阶段只执⾏ ⼀次
2.是其他模型的基础框架
1测试后置
1.1 前⾯各阶段遗留的⻛险推迟到测试阶段才被发现,导致项⽬⼤⾯积
返⼯,失去了及早修复的机会
1.2 必须留有⾜够的时间给测试活动,否则导致测试不充分,将缺陷直
接暴露给⽤⼾(产品质量差)
1.3 周期太⻓,产品很迟才能被看到和使⽤,可能会导致需求/功能过时

瀑布模型适用场景:需求固定的小项目


2.2.2.2 螺旋模型
⼀般在软件开发初期阶段需求不是很明确时,采⽤渐进式的开发模式。螺旋模型是渐进式开发模型的 代表之⼀。
这对于那些规模庞⼤、复杂度⾼、⻛险⼤的项⽬尤其适合。这种迭代开发的模式给软件测试带来了新 的要求,它不允许有⼀段独⽴的测试时间和阶段,测试必须跟随开发的迭代⽽迭代。因此,回归测试的重要性就不⾔⽽喻了。

螺旋模型也是基于瀑布模型,只是在每个阶段都加入了风险分析以及原型 

这里的原型是指:在软件开发过程中,针对每个阶段的目标和风险,快速构建的一个可以运行的软件版本或系统的部分模型.

  • 特点
    • 渐进性:随着软件开发过程的推进,原型会不断地被改进和完善,逐步趋近于最终的目标系统。每一次迭代都会在前一次的基础上增加新的功能或改进现有功能。
    • 阶段性:与螺旋模型的阶段划分相对应,在每个阶段都会根据该阶段的重点和风险来构建相应的原型。例如,在需求分析阶段,可能会构建一个简单的界面原型来帮助用户直观地感受系统的功能和操作流程,以便更好地明确需求。

增量模型
优点缺陷
优点
强调严格的全过程⻛险管理。
强调各开发阶段的质量。
增加⻛险分析和原型
项⽬中可能存在的⻛险性与⻛险管理⼈员的技能⽔平有直接关系
需求⼈员、资⾦、时间的增加和投⼊,可能会导致项⽬的成本太大

 适⽤场景:规模庞⼤、复杂度⾼、⻛险⼤的项⽬。


2.2.2.3 增量模型和迭代模型

增量模型:将一个大的需求分拆成多个小的需求,每个小需求独立开发上线,图上的增量就是一个个小需求.

优点

  • 早期可见性和反馈:能够在开发早期就向用户提供部分功能,使用户可以尽早看到软件的实际运行效果,及时提供反馈意见,有助于开发团队更好地理解用户需求,减少需求变更带来的风险。
  • 渐进式开发:将大型项目分解为多个较小的增量构件,降低了项目的整体复杂度,使开发过程更加可控。开发团队可以根据实际情况灵活调整开发计划和资源分配,逐步完善软件系统。

缺点

  • 整体架构设计要求高:需要在项目初期就对软件的整体架构进行较为完善的设计,以确保各个增量构件能够良好地集成在一起,并且不会因为后续增量的加入而导致架构的不稳定或不合理。如果架构设计不合理,可能会导致后期集成困难,甚至需要对整个架构进行重新设计。
  • 管理复杂度增加:由于涉及多个增量构件的开发、集成和协调,项目的管理复杂度相对较高。需要对各个增量的进度、质量、资源分配等进行有效的管理和监控,确保整个项目能够按照计划顺利进行。

迭代模型:和增量模型不同,迭代模式是指先发布一整个项目,只是这个项目只有一般的功能,后续再慢慢开发,发布新的功能.迭代模型将软件开发过程划分为多个迭代周期,每个迭代周期都包含从需求分析、设计、编码、测试到交付的完整过程。每次迭代都会产生一个可运行的软件版本,该版本在功能和质量上都比上一次迭代有所改进,通过不断迭代,软件逐渐趋近于最终的目标产品。

迭代模型和增量模型的区别:增量模型是从0开始,一点点部署每一个需求,而迭代模型是指先发布一个有基本功能的软件产品,对后续需求再进行补充.

增量模型是先画⼈的头部,再画⾝体,再画⼿脚……
迭代模型是先画整体轮廓,再勾勒出基本雏形,再细化、着⾊..

适用场景:大型项目,需求不明确 


2.2.2.4 敏捷模型
敏捷模型的四个特点:轻⽂档,轻流程,重⽬标,重产出。敏捷开发有很多
种⽅式,其中Scrum是⽐较流⾏的一种.
Scrum是敏捷模型的一种,他是迭代式增量软件开发模型
在Scrum中, 主要有三个角色和五个重要会议
三个⻆⾊
scrum由product owner(产品经理)、scrum master(项⽬经理)和team(研发团队)组成
其中product owner负责整理user story(⽤⼾故事),定义其商业价值,对其进⾏排序,制定发布
计划,对产品负责。
scrum master负责召开各种会议,协调项⽬,为研发团队服务。
研发团队则由不同技能的成员组成,通过紧密协同,完成每⼀次迭代的⽬标,交付产品。

 
五个重要会议:
产品负责⼈负责整理user story,形成左侧的product backlog。
发布计划会议:product owner负责讲解user story,对其进⾏估算和排序,发布计划会议的产出
就是制定出这⼀期迭代要完成的story列表,sprint backlog。
迭代计划会议:项⽬团队对每⼀个story进⾏任务分解,分解的标准是完成该story的所有任务,每
个任务都有明确的负责⼈,并完成⼯时的初估计。
每⽇例会:每天scrum master召集站⽴会议,团队成员回答昨天做了什么今天计划做什么,有什么
问题。
演⽰会议:迭代结束之后,召开演⽰会议,相关⼈员都受邀参加,团队负责向⼤家展⽰本次迭代取
得的成果。期间⼤家的反馈记录下来,由po整理,形成新的story。
回顾会议:项⽬团队对本期迭代进⾏总结,发现不⾜,制定改进计划,下⼀次迭代继续改进,以达
到持续改进的效果

3.测试模型

测试模型中有两个⾮常重要且具有标志性的测试模型:V模型和W模型

3.1 V模型

明确的标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程期间
各阶段的对应关系,有效提升测试的质量和效率。
V模型指出:
        单元和集成测试应检测程序的执⾏是否满⾜软件设计的要求;
        系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;
        验收测试确定软件的实现是否满⾜⽤⼾需要或合同的要求
缺点:仅仅把测试作为在编码之后的⼀个阶段,未在需求阶段就介⼊测试。缺点同瀑布模型。

3.2 M模型(双V模型)

 

W模型增加了软件各开发阶段中应同步进⾏的验证和确认活动。W模型由两个V字型模型组成,分别代 表测试与开发过程,图中明确表⽰出了测试与开发的并⾏关系。
特点:测试的对象不仅是程序,需求、设计等同样要测试,测试与开发是同步进⾏的
优点:
有利于尽早地全⾯的发现问题。例如,需求分析完成后,测试⼈员就应该参与到对需求的验证和确
认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项⽬难度和测试⻛险,
及早制定应对措施,显著减少总体测试时间,加快项⽬进度。
缺点:
        需求、设计、编码等活动被视为串⾏的;
        测试和开发活动也保持着⼀种线性的前后关系,上⼀阶段完全结束,才可正式开始下⼀个阶段⼯作。
        重流程,⽆法⽀持敏捷开发模式。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理⾯临着困惑

4. BUG

4.1 软件测试的生命周期

软件测试贯穿于软件的整个生命周期.

软件测试的生命周期:

每个阶段的具体内容:

需求分析

用户角度:软件需求是否合理

技术角度:技术上是否可行,是否还有优化空间

测试角度:是否存在业务逻辑错误,冗余,冲突问题

测试计划制定测试计划:什么时候开始测试,.什么时候结束测试,.耗时多久
测试设计与开发参考需求文档,技术文档等编写测试用例,写测试文档要明确标注使用的测试方法以及测试工具测试形式等
测试执行
充分利⽤测试⽤例和测试⼯具对项⽬尽可能做到全⽅⾯的测试覆盖
测试评估测试是否通过,本次测试是否有遗留的BUG,最终测试⼈员需要产
出⼀个测试报告
上线
项⽬测试结束后,将项⽬发布到线上环境,测试⼈员需求跟踪上线并测试线上环境下软件运⾏是否正确
运⾏维护
测试⼈员需要参与项⽬的实施⼯作。测试⼈员对项⽬产品的业务和操作⾮常了解,加上测试⼈员的 沟通表达能⼒⼀般都⽐较强,所以测试⼈员可以参与⽤⼾使⽤软件的培训,在试运⾏项⽬时收集问题并及时反馈给相关负责⼈

4.2 BUG

定义: ⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault),这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误
准确的来说:
1. 当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能,判断标准以最终⽤⼾为准:当程序没有实现其最终⽤⼾合理
预期的功能要求时,就是软件错误。

4.2.1 描述bug的基本因素

描述bug的基本要素:问题出现的版本,问题出现的环境,问题出现的步骤,预期结果,实际结果

比如:

问题出现的版本: ⾕歌浏览器版本 123.0.6312.123(正式版本) (64 位)

问题出现的环境:Windows系统 家庭版(也可以加上出现问题的浏览器版本)

问题出现的步骤:1.打开谷歌浏览器 输入网址www.101eduyun.com

预期结果: 二维码模块不会被登录框阻挡,可以正常扫描

实际结果:二维码被登录框遮挡,不可以正常扫描


4.2.2 bug的级别

通过定义bug的级别,能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配优先级来处理bug,除此之外,通过bug级别也能够体现出开发⼈员的开发质量
bug的级别:崩溃,严重,一般,次要

                      

4.2.3 bug的生命周期

测试⼈员在执⾏测试的过程中如有发现bug,需要在对应的bug管理平台来创建bug(bug⽣命起
源),创建好的bug需要被开发⼈员修复,以及测试⼈员的持续跟踪和测试。

 

测试人员发现新的BUG就设置为new ,未经评审决定是否指派给某个开发人员修改

开发人员确认是bug(open),并且认为必须修改.修改完成之后,将bug状态设置为Fixed(修改后)

如果当前时间比较紧迫,bug级别也不是很严重的情况下,可以Delay(推迟)修改,后续发布其他版本的 时候再进行修改

测试人员再次进行测试,测试通过就关闭bug(close),然后结束.但是如果没通过,测试人员会重新将bug状态设置为(Reopen)重新打开bug,开发人员重新修改. 


与开发人员发生争执怎么办(面试题)

1.先检查自身,是否bug描述不清楚,并且多次测试bug

2.站在用户角度考虑并抛出问题

3.定义bug级别要有理有据,不可乱扣帽子

4.提升自己水平,不仅可以发现bug,也要建议性的给出方案

5.实在不行就找bug评审


上述内容就介绍到这里

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值