软件测试基础知识

  前言👀~

上一章我们介绍了jvm相关的知识点,接下来我们进入新的篇章软件测试篇,今天先讲解软件测试的一些基础知识和概念相关的知识可能比较枯燥

 什么是软件测试?

软件测试点可以穷举吗?

测试和调试有什么区别?

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

优秀的测试人员需要具备哪些素质?

测试概念

什么是需求?

测试人员眼里的需求是啥样的?

什么是测试用例?

为什么有测试用例?

什么是bug?

软件的生命周期

开发模型

瀑布模型

螺旋模型

增量开发

迭代开发

敏捷开发

测试模型

V模型

​编辑

W模型(双V模型)


如果各位对文章的内容感兴趣的话,请点点小赞,关注一手不迷路,讲解的内容我会搭配我的理解用我自己的话去解释如果有什么问题的话,欢迎各位评论纠正 🤞🤞🤞

12b46cd836b7495695ce3560ea45749c.jpeg

个人主页:N_0050-CSDN博客

相关专栏:java SE_N_0050的博客-CSDN博客  java数据结构_N_0050的博客-CSDN博客  java EE_N_0050的博客-CSDN博客


 什么是软件测试?

最直接的理解就是找bug发现程序的缺陷,例如我们出现买衣服需要试穿看看尺码大小和外观等。专业点说就是验证软件的功能是否满足用户的需求并且验证软件功能执行的正确性

例子:软件测试软件测试顾名思义了就是对软件进行测试,测试人员通过测试的方式发现软件中的问题,就类似我们去外面买衣服的时候就是一个软件测试的过程我们根据需求去挑选衣服,在不断试衣服对比的过程中到最终选出一件符合我们需求的衣服,在不断试衣服的过程我们可以理解为软件测试,我们在试衣服的过程会看尺码合不合适、颜色符合不符合我们的肤色等等信息去判断这件衣服符不符合我们的需求。软件测试具有不可穷举性,还是拿衣服举例我们的需求就是能穿能遮挡一些地方并且要好看,然后价格就根据每个人的需求去选择,然后总不可能有人选衣服的时候会去研究它的衣服成分中的原子啊分子啊怎么组成的吧,总不可能测试它是人工的还是机器做的之类的吧。

软件测试点可以穷举吗?

软件测试只是一个样本试验没有办法穷举,没有办法进行一个完整的测试,软件测试人员保证主要功能和核心流程的正确性即可。简单点说就是要想把所有的方方面面都测试到是无法完成的,因为能列出无数个

测试和调试有什么区别?

1.参与角色

调式:开发人员

测试:测试人员+开发人员执行(通常情况下,黑盒测试由测试人员执行,部分白盒、系统测试由开发人员执行)


2.执行阶段

调式:开发的时候才调试,因为得有代码才能调试

测试:贯穿于软件的整个生命周期!!!(测试介入的时间比调试早)

3.目的

调式:为了发现软件中的问题并且解决

测试:为了发现软件中的问题,提供解决方案

4.手段:

调式:debug、分析代码逻辑

测试:等价类划分法、边界值法

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


1.工作内容:

软件开发:通过使用框架编写代码进行软件系统的开发

软件测试:写测试用例、执行测试用例、发送测试报告、编写自动化测试用例、开发相关的测试工具

2.技能区别:

软件测试:技能广度的掌握(要对产品进行全方面的测试,web的UI自动化测试、app的UI自动化、后端接口进行测试、性能、安全...)

软件开发:技能深度的掌握(例如对于底层的理解,熟练并掌握并且保证代码不出错的情况下能写出高效代码)


软件测试工程师又分统软件测试和软件测试开发,但统称测试人员

软件测试:功能测试比较多、设计测试用例、执行测试用例,涉及开发工作内容较少

软件测试开发:在软件测试的工作内容上加入一些开发工作(开发测试用例、开发测试工具给测试人员用提高测试效率)

测试开发出来的软件和开发人员开发出来的软件有什么不一样?

开发人员开发出来的面向外部用户,测试开发出来的软件通常情况是面向司内部人员

优秀的测试人员需要具备哪些素质?

技能:

1.测试用例设计能力,测试必须要掌握的!

2.编程能力(编写测试工具、自动化测试用例)

3.技术快速学习的能力(各种编程语言)

4.业务快速学能力

非技能:

1.沟通与合作能力

2.文字表达能力(测试用例用文字写出来的、编写测试文档、BUG)

3.责任感和抗压能力


测试概念

什么是需求?

用户需求:就是用户提出的需求,也就是一句话

软件需求:产品经理把用户提出的需求写成一个文档(里面会详细描述用户需求),开发/测试人员照着软件需求进行开发/测试

总结:用户需求就是一句话,软件需求就是一个文档(里面详细描述用户需求如何实现),然后在日常工作中开发一个或测试一个产品,我们通常拿着软件需求进行开发或测试

测试人员眼里的需求是啥样的?

需求是测试人员开展软件测试工作的依据,在具体设计测试用例的时候,首先需要搞清楚每一个业务需求对应的多个软件功能需求点,然后分析出每个软件功能需求点对应的多个测试需求点,然后针对每个测试需求点设计测试用例

流程:业务需求—>软件功能需求点—>测试需求点—>测试用例,就是将一个个业务需求进行拆分成对应的多个测试需求点,例如一个登录模块分为注册、登录、后台管理等模块,其中我们测试人员又对登录模块进行拆分成功能、兼容性、性能、安全性设计测试需求点,然后针对测试需求点编写测试用例


什么是测试用例?

测试用例(test case):测试用例是为了实施测试而向被测试的系统提供的一组集合,包含测试环境、测试数据、预期结果、操作步骤等,注意测试用例没有执行结果都没有执行哪来的执行结果

例子:我们平时刷leetcode,测试环境就是我们在哪个操作系统哪个浏览器打开的leetcode,测试数据就是leetcode中有个自测输入我们可以自己写测试数据对代码进行测试也可以使用它的测试数据进行测试,操作步骤就是我们写代码然后提交,预期结果就是通过率100%

为什么有测试用例?

1.测试用例提高测试人员工作效率/降低测试人员工作的重复性问题

2.测试用例是建立自动化的基础,自动化就是让代码代替我们去执行测试

什么是bug?

1.当且仅当规格说明(软件需求)是存在的并且正确,程序与规格说明之间的不匹配才是错误(预期结果和执行结果),小到一个功能模块大到整个功能模块

2.当需求规格说明书没有提到的功能,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是软件错误。举个例子就比如写个登录没有加密展示这就不合理属于是一个bug

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 软件的生命周期可以分成6个阶段,即需求分析、计划、设计、编码、测试、运行维护

软件从我们的需求中诞生,首先会先进行需求分析分析这个需求是否合理、是否完整(例如一个登录首先要注册),计划就是谁开发谁测试开发多久测试多久等等,编码就是开发人员写代码,测试就是测试人员进行测试,然后发布测试报告然后上线软件,运行维护就是线上出现问题,测试人员协助开发定位问题解决问题


开发模型

瀑布模型

瀑布模型是所有其他模型的基础框架,瀑布模型的每一个阶段都只执行一次,因此是线性顺序进行的软件开发模型

流程:开始->需求分析->计划->设计->编码->测试->结束

从需求分析开始会产出一个需求文档(需求是否合理完整等),然后计划就是谁开发谁测试开发多久测试多久等等,然后就是设计会有两个文档一个技术文档(记录涉及哪些接口、库表等)一个UI视觉稿(就是将需求文档的内容转化为图片),编码就是开发人员写代码,测试就是测试人员执行测试用例记录bug最后验收

优点:每个阶段做什么,产出什么很明显,适用于小型项目

缺点:依赖于早期进行的唯一 一次需求调查,不能适应需求的变化。导致风险往往迟至后期的测试阶段才显露,因而失去及早纠正的机会,就比如如果在需求分析就出现问题到了到了测试这所剩时间不多了可能测试不够充分上线后软件缺陷会暴露给客户

螺旋模型

一般在软件开发初期阶段需求不是很明确时,采用渐进式的开发模式

优点:每个阶段都会进行风险分析,降低出现问题的概率同时也能尽量避免一些线上问题发生,适用于大型风险多的项目

缺点:需要不断风险分析,浪费时间和人力,并且分析不一定准确

增量开发

每个增量都是一个独立的、完整的功能模块,可以独立交付和运行。每个阶段的开发都是在原有系统的基础上新增功能,系统逐步扩展,直到完成全部功能。比如用户有一个需求功能包含A、B、C增量开发就是开发完A功能就上线给用户使用。

迭代开发

迭代开发是一种反复进行的开发方法,在每一个迭代周期中,对系统进行改进和完善。每个迭代周期都会进行计划、设计、实现和测试,然后根据反馈进行调整和改进,比如用户有一个需求功能包含A、B、C先开发一个基础版本包含ABC但是比较简陋。

增量开发和迭代的区别:增量开发在每个阶段原有的基础上会增加新的功能,迭代开发在每个阶段原有的基础上进行完善。可以这么理解增量开发其实就是我们游戏中每一个大版本都会新增一些角色或者关卡,迭代开发可以理解为就是对之前的角色或者关卡进行完善

敏捷开发

四句宣言想表达敏捷模型的一个特点:轻流程、轻文档、重交互、重产出

scrum:属于是敏捷开发的比较流行的一种

与瀑布不同,scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4 周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付

三大角色:product owner(产品经理)、scrum master(项目经理)和team(研发团队包含后端开发、前端开发、测试等)组成

Scrum流程:这个流程是我自己的理解和话术去阐述的可能有不正常的地方,就是阐述了一个软件开发的整个流程。首先第一个流程由产品经理整理用户需求成软件需求搞成一个文档,紧接着开个会议产品经理对需求进行排序和划分制定这一期迭代要完成的需求,计划项目什么时候开始什么时候结束由谁去做,然后项目团队对需求进行分解确定负责人开始执行,然后由项目经理组织每日会议汇报昨日任务的完成情况以及在这个过程中碰到了什么问题并且说出今日计划做什么,最后开发完成一个迭代后开一个演示会议对项目进行演示,这个期间将反馈记录下来,由产品经理进行整理,会议结束后项目团队进行总结制定改进计划然后下一次的迭代继续改进

敏捷开发模型流程图,这张更直观一些


测试模型

V模型


解释:首先产品经理将用户需求收集成软件需求,然后需求分析与系统设计阶段,这个阶段验证需求是否合理确认编程语言和框架,然后就是概要设计阶段就是项目结构如何设计,接着详细设计阶段就是每个接口涉及哪些库表涉及哪些任务。接着就是编码,编码之后来到单元测试阶段测试人员对单个功能模块进行测试,然后集成测试将方法集成到一起也就是模块和模块之间的交互进行测试,接着就是系统测试就是对整个项目进行测试,从头到尾测试所有功能是否都能正常工作,最后验收测试就是上线之前由运营或产品经理进行测试

单元测试通常由开发人员编写和执行,集成测试可能由开发人员或测试人员编写和执行,系统测试由专业测试团队执行,通常在测试环境中进行

优点:明确测试的类型,左边开发右边测试,类似瀑布模型

缺点:测试人员介入过晚,发现问题时间过晚的会把软件缺陷暴露给用户

W模型(双V模型)

解释:测试从用户需求开始阶段就介入了根据用户需求会写一个文档,后期验收的时候把这个文档交给产品经理或运营对照这个文档进行验收。然后需求分析与系统设也是写一个文档,接着后面的设计测试人员在对应阶段做出对应的测试准备

优点:测试人员介入的时机早

缺点:依赖于上一个阶段完成后下一个阶段才能开始,测试人员和开发人员一定程度上还是串行的,重文档重过程不能拥抱变化所以不支持敏捷模式,不能拥抱变化就是对于项目要求或技术变化的适应性不如敏捷开发 ,v和双v都不能拥抱变化,需求文档开始就确定了适应性就不如敏捷开发

以上便是本章软件测试的一些基础知识和概念相关的知识点,内容大多都是文本形式比较枯燥但也比较好理解,我们下一章讲解详细讲解测试用例相关的知识点💕

  • 27
    点赞
  • 33
    收藏
    觉得还不错? 一键收藏
  • 19
    评论
评论 19
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值