测试——基本概念

文章详细阐述了测试与调试的不同,测试人员的工作职责,以及软件开发的各个阶段,包括需求分析、设计、编码、测试和维护。同时,介绍了瀑布模型、螺旋模型、迭代模型、增量模型、敏捷模型和Scrum方法等开发模型。此外,还讨论了测试模型如V模型和W模型,以及bug的生命周期和测试用例设计的各种方法,如等价类、边界值、判定表等。
摘要由CSDN通过智能技术生成

概念

测试和调试有以下几点区别:

  • 测试是测试人员进行的工作,调试是开发人员
  • 调试是发现并解决问题,测试只是发现问题
  • 测试贯穿于整个项目的生命周期,而调试主要在编码阶段

测试人员一般有如下的工作:
需求分析,设计测试计划,测试用例,执行测试,撰写测试报告

需求

一般分为下面两种

  • 用户需求:也就是甲方要求需要完成的任务
  • 软件需求:必须要实现的软件功能

测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合
其中包括:

  • 测试环境(软件加硬件环境)
  • 操作步骤
  • 测试数据
  • 结果预期

例如,写一个关于登录博客系统的测试用例
在这里插入图片描述

bug

bug是当规格说明是正确的时,程序与规格说明之间不匹配
或者,程序没有实现用户合理预期的功能要求

开发流程

一个软件的开发分为下面几步:

  1. 需求分析:好比建房子前需要对工地,技术进行考量,设计软件也需要对用户的需求量和技术能否达标,投入和收益的占比进行分析
  2. 计划:好比建房子需要计划什么时候开始建房,停工,软件也需要计划好开发所需要的时间
  3. 设计:好比建房子需要设计楼间距,格局,设计软件需要将需求分解成一个个框架和接口,并且规定实现所采用的技术
  4. 编码:好比开始按照计划建房子的过程,也就是软件的开发人员开始按照技术文档和需求文档编写代码的过程
  5. 测试:好比验收房子是否达到标准,是否需要返工,也就是测试人员按照测试用例对软件进行测试
  6. 运行维护:也就是住房人需要对房子漏水等问题进行后续的处理,软件上线后也需要进行修复性维护,对功能进行完善性修复,对bug进行预防性维护

开发模型

软件的开发有多种模型,下面一一进行介绍

瀑布模型

在这里插入图片描述
即按照上面的软件开发流程进行开发,每个阶段只进行一次,如果出现了错误就返回上一个状态

使用场景:

  • 需求固定的小项目
    缺点:
  • 前面阶段的风险,可能会遗留到最后的阶段
  • 周期太长,导致需求过时
  • 测试不充分会将缺陷暴露给用户

螺旋模型

在这里插入图片描述
在每个开发流程中加上风险分析和原型
缺点:

  • 项目中的风险和风险管理人员的水平有直接关系
  • 需要投入的人力,时间,资金更多

使用场景:
规模庞大,复杂,风险大的开发场景

迭代模型

在这里插入图片描述
如果项目中有a,b,c,d,e五个功能,迭代模型会先把这些功能的基础版本开发出来,然后在对基础功能进行不断的更新完善

增量模型

在这里插入图片描述
如果项目中有a,b,c,d,e五个功能,会先开发a,b,c功能,然后再开发d,e功能,也就是一个一个功能进行开发

敏捷模型

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中,后者并非全无价值,但我们更看重前者

简单来说,敏捷模型就是对流程,文档没有那么重视,而是注重产出的软件

scrum模型

三个角色:

  • 产品经理
  • 项目经理
  • 研发团队

五个重要会议:

  • 发布计划会议:确定要完成的需求
  • 迭代计划会议:确定责任人与相关任务
  • 每日会议:了解当前项目进度
  • 演示会议:产出用户需求
  • 回顾会议:总结当前迭代的经验与不足

其中,整个开发模型就是,先从整个需求池中取出需求,然后发布计划会议,迭代计划会议,每日会议,演示会议,然后再从需求池中取出需求

测试模型

与开发一样,测试也有不同的模型

V模型

在这里插入图片描述
其中单元测试对应开发中的详细设计,集成测试对应概要设计,系统设计对应需求与系统,验收测试对应用户需求

特点:

  • 含有不同类型的测试
  • 测试参考的标准和开发的阶段对应

缺点:

  • 测试后置,暴露问题时间较晚

W模型

在这里插入图片描述
也就是在开发进行时,就对每一个阶段进行测试
特点:

  • W模型重流程,无法迎接变化
  • W模型不使用敏捷模型

BUG

创建bug

对于一个bug,应当说明其出现的版本,环境,步骤,预期结果和实际结果,bug等级
例如:
在这里插入图片描述
其中,bug等级包括:次要,一般,严重,崩溃

bug的生命周期

  • New: 测试人员创建了一个bug
  • Open:开发人员确认是bug
  • Rejected:开发人员确认不是bug
  • Fixed:开发人员将bug修复完成
  • Delay:bug等级低,且开发人员不能立即修复bug
  • Closed:bug确认修改后,测试人员将状态改为Closed
  • Reopen:bug确认未修改完成,测试人员将状态改为Reopen

测试用例的创建

测试用例不仅要考虑应该实现的功能,也要考虑未实现,不应该实现的功能
通常从下面几方面进行测试用例的设计:

  • 功能测试
  • 性能测试
  • 界面测试
  • 兼容性测试
  • 易用性测试
  • 安全测试

例如:
在这里插入图片描述
在这里插入图片描述

等价类

依据需求,将不同的输入分成若干个等价类,然后从不同的类中选出一个测试用例,若这个测试通过,则代表整个类通过
其中一般分为有效等价类和无效等价类

边界值

边界值分为有效边界和无效边界
例如,大于等于60分及格,那么60是有效边界,59是无效边界

判定表

和真值表类似,将所有的输入按照不同的组合写入表中,然后根据输入和输出的关系,确定输出,画出判定表,根据判定表编写测试用例

场景设计法

根据基本时间流和备选时间流,设计不同的测试用例
例如:去肯德基买汉堡包,基本时间流就是按照菜单点餐,交钱,取汉堡,吃饭
备选时间流有:遇到疯狂星期四打折,没带钱,吃饭噎死了

正交法

正交实验法是从大量的实验中找出有代表性的点,然后依据正交表来设计测试用例

其中正交表有如下特性:

  • 每一列中不同的数字出现的次数相同
  • 任意两列中数字的排列方式齐全且均衡

测试分类

  • 可靠性测试 :系统的可靠性 = 正常运行时间 / (正常运行+非正常运行时间) * 100%
  • 容错性测试 :指软件发生的错误并从错误中恢复的能力,
  • 安装卸载测试
  • 内存泄漏测试:可借助人工或软件静态扫描代码
  • 弱网测试:网不好会造成客户端频繁的发送请求
  • 冒烟测试:评估软件是否具备可测试条件
  • 回归测试:对历史版本的功能进行测试

按照是否查看代码划分

  • 黑盒测试:功能测试(系统测试)
  • 白盒测试:关注程序的内部实现(单元测试)
  • 灰盒测试:介于黑盒测试和白盒测试之间(集成测试)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值