测开入门(附常考面试题)

目录

一、什么是软件测试?

二、软件测试的基础概念 

1、需求

2、测试用例

3、BUG

三、生命周期

🍑软件的生命周期

🍑软件测试的生命周期

四、软件工程中的几种常见的开发模型

🏀瀑布模型

🏀螺旋模型

🏀增量模型和迭代模型

🏀敏捷模型

五、软件工程中的测试模型

V模型

W模型


一、什么是软件测试?

 

验证软件产品特性(功能、界面、安全性、兼容性、性能)是否符合用户需求

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

软件测试不仅要测试软件系统是否做了其该做的,还要测试系统是否未做其该做的

面试题:

软件测试和软件开发的区别?

软件测试:主要是保障产品质量

软件开发:主要是编写业务代码

软件测试和软件测试开发的区别?

首先软件测试和软件测试开发的主要工作内容都是保障产品质量,不同的是软件测试开发还额外需要开发一些测试效能工具——来提升测试效率

软件测试和开发测试(软件调试)的区别?

目的不同

软件调试:开发人员验证软件是否实现了他想让软件实现的功能

软件测试:测试人员验证软件是否实现了用户的需求

角色不同

软件调试:开发人员来做

软件测试:开发人员和测试人员,一起来做这件事!(在软件测试中,开发人员主要是做  白盒测试的——与代码相关的)

阶段不同

软件调试:开发阶段

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

你为什么要选择软件测试开发的工作?

回答自己的核心竞争力体现在哪里——自己的优势

自己有着优秀的测试人员需要具备的素质

综合能力:

1)沟通能力

2)快速学习能力

3)开发能力

4)文字能力

优秀的测试用例设计的能力

掌握自动化测试技术

探索性思维、兴趣、有责任感

我看你的简历上有较多的开发技能?你为啥要选择测试工作呢?你的优势在哪里?

有开发技能可以帮助我们更好的编写测试用例(不要抨击别人、抨击学校,这时面试的大忌)

二、软件测试的基础概念 

1、需求

用户需求是五花八门的,描述是简略的。并且用户需求不一定是正确的、合理的,需要进一步的对用户需求进行提取和分析,所以用户需求不可以作为测试/开发工作的依据!!

软件需求才是进行测试/开发工作的的基本依据(产品经理写的软件需求文档)

2、测试用例

测试用例(Test Case) 是为了实际测试而向被测试的系统提供的一组集合,这组集合包括:测试环境、操作步骤、测试数据、预期结果

测试人员在执行测试之前需要编写测试用例,测试用例的好坏与产品测试质量有很大的关联关系。

我们在测试的时候,光凭头脑风暴来进行随机的测试肯定是不行的,所以我们就需要根据提前编写好的测试用例来进行更完善的测试

 大家乍一看,可能就会觉得,这个测试用例很正常。
唯一缺点:就是不够详细。
是的,没有错!
测试用例,就如同 上图给标题一样“正确的用户名密码可以成功登录邮箱”,它是一个非常模糊 和 片面的说法。
而我们通过将其划分成 4 个部分,来将这个测试用例进行初步的划分,
而且,划分出的这几个部分,其实也是可以进行细分的!
划分成一个个测试点

————————————————
在这里插入图片描述

3、BUG

BUG也叫做软件缺陷和软件错误

准确的说:当且仅当规格说明(软件需求文档)是存在并且是正确的时候,程序与规格说明之间的不匹配才是错误BUG。

这个BUG可以来自前端、也可以是后端,甚至是来自产品经理写的需求文档。


三、生命周期

🍑软件的生命周期

需求分析--》计划--》设计--》编码--》测试--》运营维护

需求分析:进行市场分析,这个需求量大不大?投入与盈利的占比?技术上 能否实现或者说实现的难度?

计划:什么时候开始?什么时候结束?过程耗时多少?

设计:将需求细化为一个一个的任务,进行计算设计(要用到哪些接口?采用什么框架?

编码:开发人员参考需求文档和技术文档进行功能代码的编写

测试:测试人员要参考测试用例来执行测试(注意测试用例是在测试前就编好的,要明白我们的测试是贯穿软件的整个生命周期的)

运行维护:修复性的维护(对项目中未发现的问题进行修复)完善性维护(对功能进行完善)预防性维护(居安思危,为了避免产品在线上出现一些意想不到的问题,进行一些预防的手段)

🍑软件测试的生命周期

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

需求分析——》测试计划——》测试设计与开发——》执行测试——》测试评估

测试计划:测试人员也需要编写测试计划文档——有多少测试人员,什么时候开始测试?

测试设计与开发:测试人员需求借助需求文档和技术文档来编写测试用例。


 

四、软件工程中的几种常见的开发模型

🏀瀑布模型

 

需求分析——》计划——》设计——》编码——》测试——》运行维护

特点:

  • 不太重视测试,软件开发完成前不会进行测试(更看重前面的需求分析、计划、设计)
  • 线性结构、一个阶段完成后才会进行下一步、效率不高
  • 项目中的问题不能尽早的发现,很可能会错失解决问题的最佳时机。
  • 需要保留足够的时间给测试、测试后置(瀑布模型的缺陷)
  • 测试时间不够——》测试不充分——》暴露风险给用户
  • 一个周期把所有的功能给完成——》一个可以运行的产品很晚才会给用户呈现


使用场景:因为不能够很好的迎接变化,使用与需求固定的小型项目

后面的模型都是在瀑布模型上进行了优化 
 

🏀螺旋模型

 

螺旋模型:在瀑布模型的基础上进行 风险分析
在每个阶段都有风险分析这一步——》耗时耗力(成本好,团队需要风险分析方面的人才)

优点:
1、强调严格的全过程风险管理。
2、强调各开发阶段的质量。
3、提供机会检讨项目是否有价值继续下去。

缺点:
1、引入非常严格的风险识别、风险分析和风险控制,这对风险管理的技能水平提出了很高
的要求。这需要人员、资金和时间的投入。


使用场景:大项目

瀑布模型 和螺旋模型对变化的项目不太友好,不容易都项目进行及时更改


 

🏀增量模型和迭代模型

增量模型:
将项目进行模块化,使其每个模块都能进行独立的编码测试和上线
优势:产品能够加载较短时间内尽快的交付给用户去使用

迭代模型:
一期一期的进行迭代
假如一个产品包含五个功能A、B、C、D、E
增量模型要一个一个的开发这五个不同的模块,但迭代模型会先完成这5个功能的基础版本,会再经历一期一期的迭代优化(在迭代的过程还可接收用户的使用建议)使其功能越来越优秀。

🏀敏捷模型

敏捷模型——2001年,以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird,决定把“敏捷”(Agile)作为新的过程家族的名称。
在会议上,他们提出了《敏捷宣言》http://agilemanifesto.org/: 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍,我们形成了如下价值观

1、个体与交互重于过程和工具
强调团队内部人员进可能的进行高效的沟通
2、可用的软件重于完备的文档
敏捷模型最终的标准就是:可交付的软件
3、客户协作重于合同谈判
4、响应变化重于遵循计划


(在每对对比中,后者并非全无价值,但我们更看重前者)

敏捷宣言的特点:轻流程、轻文档、重目标、重产出

敏捷开发有很多种方式,其中 scrum(敏捷开发) 是比较流行的一种

scrum中三个重要的角色

  • 产品经理(收集用户需求,转变软件需求:开发时就是依赖软件需求来开发的,对产品负责)
  • 项目经理(推进项目的推进,为研发团队服务)
  • 研发团队:不同技能的成员组成

 

 

敏捷模型是一版一版进行迭代的
每个迭代模型为1---4周

 

每日会议结束后的产物:可交付的软件
演示会议的产物:用户新的需求——》放到需求池中,下一次产品迭代再实现。


五、软件工程中的测试模型

V模型


特点:明确了测试有不同的类型,并且每个类型和前期的开发工作之间有相对应的关系。
缺点测试后置

 

 

W模型

 

W 模型,也称作双V模型。

看图说话:就是两个 V 模型 组成的。

特点:

开发一个V,软件测试一个V【双卡双待】
换个说法:软件开发 和 软件测试 是 同步进行的。
这样做,就解决了 V 模型的缺陷:W模型能够及时发现,并处理前期出现的问题。

缺点:

它仍然是 串行执行的过程,它是不支持 需求的变化。
也就是说:W模型是不支持敏捷开发的。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

是小鱼儿哈

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值