【软件测试】软件测试概念

软件测试的目的和原则

目的:1.验证是否有bug    2.验证符合用户需求
原则:以客户为中心,遵循软件测试的规范、标准、流程和要求

什么是需求?

需求:满足用户的合理期望
软件需求:也叫功能需求,该需求会详细描述开发人员必须实现的软件功能。把用户需求
     可以转换为指导开发人员写代码,测试人员测试的文档。
用户需求:比较简单,用户的一个想法想要实现的一个功能软件需求规格说明书
需求用例:声控灯软件需求
具备的功能:

  1. 声音控制灯的开关
  2. 声音的分贝大小
  3. 储备电池
  4. 灯亮的时长
  5. 声音识别(声音的种类)
  6. 灯的亮度(使用灯的电流大小)
  7. 灯亮的稳定性
  8. 灯的形状
  9. 灯对光的敏感度

什么是bug?

bug概念:1)当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才
      是错误
     2)当没有需求规格说明书时,判断标准以最终用户为准;当程序没有实现
       其最终用户合理预期的功能要求时,就是软件错误。
bug分类:1.代码bug      2.功能(使用)bug
要点:(1)需求规格说明书必须正确(评审环节确保说明书正确性)
   (2)程序与需求规格说明书匹配
   (3)程序实现用户合理预期功能要求

软件的生命周期

六大阶段:需求分析、计划、设计、编码、测试、运行维护

开发模型

瀑布模型:适合稳定的用户需求的项目
在这里插入图片描述
优点:–强调开发的阶段性; –强调早期计划及需求调查; –强调产品测试
缺点:–依赖于早期进行的唯一一次需求调查,不能适应需求的变化,风险大

螺旋模型:适合复杂高、规模大、风险大的项目   强调严格的全过程风险管理
在这里插入图片描述
增量、迭代
增量:先构建模块、模块之间的功能是互相独立的
迭代:先构建轮廓、模块之间的功能互相影响

敏捷
与传统模型的区别:
《敏捷宣言》

  1. 人与人之间的沟通(个体与交互重于过程和工具)
  2. `轻文档(可用的软件重于完备的文档)
  3. 客户参与(客户协作重于合同谈判)
  4. 拥抱变化(响应变化重于遵循计划)

开发流程:
Po整理UserStory-----确定每次迭代完成的user story----任务的认领、时间评估—开发中—开发完成-----测试中—测试完成—发布上线

scrum:敏捷开发方式的一种
角色:
产品负责人(Po) 敏捷教练(Sm) 研发团队(team)
迭代开发

  1. 与瀑布不同,scrum将产品的开发分解为若干个小sprint(迭代);
  2. 其周期从1周到4周不等,但不会超过4周。
  3. 参与的团队成员一般是5到9人。

软件测试模型(V、W、H、X)

软件测试V模型在这里插入图片描述

左边:开发线      右边:测试线
优缺点与瀑布模型一致;
用户需求: user Story
系统测试(核心)
五项工作:

  1. 搭建测试环境
  2. 数据准备
  3. 测试执行
  4. 缺陷管理
  5. 测试报告的编写

单元测试(白盒测试)、集成测试(白盒和黑盒测试)

软件测试W模型(测试人员所有阶段都参与)

在这里插入图片描述
模块并行

  1. 用户需求:验收测试准备、了解用户需求
  2. 需求分析与系统设计:系统测试准备
  3. 概要设计: 集成测试准备
  4. 详细设计:单元测试准备,搭建测试用例框架
  5. 编码:编写测试用例、单元测试

研发测试分成两个并行的V 模式
缺点:不适合敏捷开模型
优点:有利于今早全面发现问题,减少总体测试时间,加快项目进度
了解X、H模型是否适合敏捷开发模型

配置管理

1.什么是配置管理
类似于图书管理员
配置管理是通过对在软件生命周期不同的时间点上的软件配置进行标识,并对这些被标识的软件配置项的更改进行系统控制,从而达到保证软件产品的完整性和可溯性的过程。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值