【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型

【测试开发】概念篇

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第1张图片

文章目录

  • 【测试开发】概念篇
    • 1. 什么是需求
      • 1.1 需求的定义
      • 1.2 为什么有需求
      • 1.3 测试人员眼里的需求
      • 1.4 如何深入了解需求
    • 2. 什么是测试用例
      • 2.1 为什么有测试用例
      • 2.2 练习=>手机打电话
    • 3. 什么是bug
    • 4. 开发模型和测试模型
      • 4.1 软件生命周期
      • 4.2 开发模型
      • 4.3 测试模型
        • 4.3.1 敏捷中的测试
        • 4.3.2 V模型
        • 4.3.3 W模型(双V模型)
        • 4.3.4 H模型

【测试开发】概念篇

1. 什么是需求

“想睡觉”,“不想上课”,“想吃饭”,这就是需求

而在互联网行业,什么是需求呢?

1.1 需求的定义

  1. 用户/甲方需求
    • 例如QQ截图,用户想要长截图
  2. 软件/功能需求
    • 对于刚才的用户需求,则需要(产品经理)写成细致的功能描述文档,例如长截图如何触发,如何操作(滚动),限制(大小/长度)

再例如一个软件需要有注册功能,注册这个笼统的就是用户需求,而其具体功能(输入姓名,邮箱,密码,确认密码,邮箱验证码,点击注册,是否同意协议,不同意会怎么样,输入不规范会怎么样…)这个详细的就是软件需求

我们开发一个产品,或者测试一个产品,要拿着这个软件需求进行测试/开发!

1.2 为什么有需求

没有需求拿来目标,怎么实现目标?

1.3 测试人员眼里的需求

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第2张图片

而测试人员要将软件需求书里的每一个点,转化为一个个的测试点:

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第3张图片

小练习:qq登录

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第4张图片

  1. 账号
    1. 功能
      1. 账号密码正确,登录成功
    2. 兼容
    3. 性能
    4. 安全
  2. 密码
  3. 登录按钮

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第5张图片

对测试点分类是必须要的!

1.4 如何深入了解需求

在项目的需求评审会议上了解:

  1. 有什么需求
  2. 为什么做这样的一个需求
  3. 收益达到什么标准
  4. 软件要做成啥样
  5. 测试要何时开始,期限为多少天
  6. 开发要何时开始,期限为多少天

但在开始做项目时,我们可以查阅文档(会议记录/笔记、软件需求文档、技术文档)

沟通一下,找产品经理了解软件功能,找开发了解软件的实现

2. 什么是测试用例

测试用例是一组集合,包含测试环境,测试数据,预期结果,操作步骤

  1. 测试环境
    • 例如OJ刷题系统,提供给学生一个测试环境(浏览器的一个页面)
  2. 测试数据
    • 例如OJ刷题系统,自己输入测试数据、这道题检验是否通过的一组测试数据
  3. 预期结果
    • 例如OJ刷题系统,通过率为100%
  4. 操作步骤
    • 例如OJ刷题系统,写代码,提交
  5. 测试序号
    • 例如OJ刷题系统,第1,2,3…
  6. 测试标题
    • 例如OJ刷题系统,达到预期后,展现一个动画效果
    • 也就是对这一组测试用例的简单描述

在工作中,常常将测试用例称为 CASE

2.1 为什么有测试用例

  1. 测试用例可以提高的是人员的工作效率

  2. 测试用例可以降低测试人员工作的重复性问题

    如果没有事先列举出测试用例,假设现在有两个人去测试一个功能:

    1. 大马自己去测试功能,质疑对方的能力,就把能测的都测了执行了,大概100条吧
    2. 小马也是,就把自己想到的都测了一遍,大概90条吧

    这样就会出现,花费时间过长,并且两人测试重复性高的问题

    所以,他们的领导要求他们写成测试用例,统计起来再去执行,大概一百条,一半给大马,一半给小马~

  3. 测试用例是建立自动化的基础,甚至是开发测试工具的基础

    自动化就是把测试人员的双手解放,让代码代替人员执行测试,既然如此我们就要有测试用例的集合,让代码以这些测试用例进行测试

2.2 练习=>手机打电话

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第6张图片

3. 什么是bug

不严谨的说法:程序和规格说明书之间不匹配

准确的来说:当且仅当规格说明书存在的并且正确,程序与规格说明书之间的不匹配才是bug

  • 规格说明书 => 软件需求文档

当需求规格说明书没有提到的功能和没有考虑到的点,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是bug

4. 开发模型和测试模型

4.1 软件生命周期

人的生命周期是:呱呱坠地 到 死亡

而软件的生命周期是:

  1. 需求分析(诞生)

    • 分析需求是否合理,遵纪守法…
    • 比如,有登录没注册就不合理
  2. 计划

    • 谁开发,谁测试,开发多久,测试多久…
    • 就是那五个W…
  3. 设计

  4. 编码

    • coding
  5. 测试

    • 测试报告

    【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第7张图片

  6. 运行维护

    • 如果有线上问题,此时测试人员需要协助开发定位问题 + 解决问题,之后重新上线
  7. 停服(死亡)

4.2 开发模型

  1. 瀑布模型

    无非就是把刚才的生命周期串在一起:

    【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第8张图片

特定:线性的

优点:每个阶段做什么,产出什么非常清晰

缺点:风险往往迟至后期的测试阶段才显露,因此失去及时纠正的机会!

  • 例如,需求分析出现问题,却在测试才被发现,一步步回溯到需求分析才发现问题,这样花费的时间、人力、精力也很大

适用的项目:

  • 小型项目适用于此模型
  1. 螺旋模型

    无非就是把刚才的生命周期反复几次:

    【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第9张图片

特性:迭代的

优点:

  • 每个阶段都会进行风险分析,避免一些线上问题发生

缺点:

  • 可能迭代次数太多,项目迟迟无法上线
  • 风险分析可能会分析错,请专家则人力和财力的投入

适用项目:

  • 适用于比较大,风险比较多的项目

对于以下模块,略讲,以一个上课软件为例(登录,创建课程,上课)

  • 主要是区分模型是“增量型”还是“迭代型”
  1. 增量模型

    • 登录功能开发完毕 -> 创建课程功能开发完毕 -> 上课功能开发完毕

    【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第10张图片

  2. 迭代模型

    • 登录功能开发一部分 -> 创建课程功能开发一部分 -> 上课功能发一部分

    【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第11张图片

  3. 敏捷开发

    • 个体之间的高效交互

敏捷宣言:

个体与交互重于过程和工具

  • 个体之间面对面沟通

可用的软件重于完备的文档

  • 开发文档,需求文档,更 关注最终的软件符不符合用户需求

客户协作重于合同谈判

  • 一份合同必然无法涵盖每个需求,所以要多与客户合作沟通,也就是客户协作

响应变化重于遵循计划

  • 变化是特别常见的,而不是一昧追求计划,而是拥抱变化!

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

  • 以上的对比,后者并不能摈弃,后者也很重要,而是更看重前者
  1. 敏捷开发中的 scrum模型

三个角色:

  • scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成

其中:

  1. product owner负责整理user story(用户故事),定义其商业价值,对其进行排序,制定发布
    计划,对产品负责。
  2. scrum master 负责召开各种会议,协调项目,为研发团队服务。
  3. team 研发团队则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品
    • 后端开发,前端开发,UI设计师,测试工程师…

流程:

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第12张图片

4.3 测试模型

4.3.1 敏捷中的测试

挑战1:轻文档

挑战2:快速迭代

  1. 测试工作的核心内客是没有变的,就是不断地找Bug,只是要调整好自己的心态,一切以敏捷的原则为主
  2. 测试人员不能依赖文档,测试用例作用减弱,更多的采用思维导图、探索性测试(强调自由度,设 计和执行同时执行,根据测试结果不断调整测试计划)、自动化测试
  3. 敏捷讲求合作,在敏捷项目组中,测试人员应该更主动点,多向开发人员了解需求、讨论设计、一 起研究Bug出现的原因。

4.3.2 V模型

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第13张图片

特点:左边是开发,右边是测试,类似于瀑布模型(折了一下)

优点:测试被划分为许多类型

缺点:测试人员介入太晚,发现问题的时机太晚,故不适用于敏捷

4.3.3 W模型(双V模型)

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第14张图片

特点:开发一个V,测试一个V

优点:测试人员在较早地介入了需求

缺点:

  1. 测试人员和开发人员一定长度上还是串行的(相关的准备都依赖于其左侧的开发模块,例如集成设计测试依赖概要设计、单元测试设计依赖详细设计)
  2. 这个测试模型不能拥抱变化,在验收测试发现问题,依旧要在测试V上不断回溯找到问题,故也不适用于敏捷

4.3.4 H模型

【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_第15张图片

优点:

  • H模型中的测试活动是一个独立的流程,只要满足了测试就绪条件,就可以开始测试活动
  • 这种灵活的组织方式,使得H模型完全具备了前两个模型的优点——测试既可以与所有的开发活动紧密结合,又足够灵活满足敏捷和迭代的开发模型

缺点:

  • H模型的灵活也造就它难以驾驭的特点
  • 如果管理者没有足够的经验就实施H模型,可能会事倍功半,测试活动的成本收益比会比较低

总之,测试模型有三种,优缺点各不相同==建议一般的软件开发过程采用W模型,实施敏捷和迭代开发的可以考虑采用H模型。==


文章到此结束!谢谢观看
可以叫我 小马,我可能写的不好或者有错误,但是一起加油鸭!’

希望枯燥的概念没有让你丧失对测试的兴趣!


你可能感兴趣的:(测试,测试)