学习笔记之软件测试1：什么是软件测试？

本章节重点：1.测试用例书写2.缺陷报告书写3.禅道的了解以及使用！
有任何问题可以评论或者私信我哦，一起学期共同进步！！！

软件测试由来

 

软件测试的目的

---

产品的风险识别，提高产品成功的几率。

---

一、本质
站在用户的角度来检验一个软件是否满足客户的功能需求，并且能够及时准确的发现其中用户可能察觉不到的软件的缺陷。
二、立场
为了证明程序有错误！
三、成本
及时的发现漏洞或者逻辑缺陷，能够避免产品在未来投入生产后可能产生异常所造成的公司成本资源的浪费。

软件测试的概述

一、定义
对某个软件系统运行过程进行检验其是否满足需求(或者说实际运行结果是否符合预期)

二、原则

• 1.方向
  • 一切测试都要以用户需求为中心
  • 测试的用例是设计出来的，不是写出来的(按需设计)
• 2.执行
  • 测试贯穿整个产品的声明周期
  • 提前测试+不断测试
  • 不要妄想穷举所有的可能测试用例
• 3.错误
  • 二八原则：80%的错误,发生在20%的模块中
  • 对发现错误较多的程序段，应进行更深入的测试
  • 错误的优先级排序->先解决影响产品基础功能的问题

软件测试的发展以及过程产物

发展过程

一、软件证明阶段

• 1960年代—> 测试即debug程序

二、软件检测阶段

• 1960-1978年代—>证明软件是正确的
• 1979-1982年代—>测试思想初成(为了返现软件错误：破坏性测试)
• 黑盒测试的概念诞生：把程序看做一个黑盒子，不考虑内部结构，只是在外部测试程序的功能是否能够按照规范说明准确无误的运行。

三、软件预防阶段

• 1983年 测试行业的标准IEEE829的诞生—>标志着软件预防阶段的开始
• 白盒测试的概念诞生：把程序看做一个白盒子，能够清楚的看减盒子内程序的逻辑和相关信息，观察程序运行内部是否按照规格设计说明书设定的运行，以及每个独立的模块结构是否正常有效。

四、软件全面质量管控阶段

• 21世纪至今—>以用户为中心，降低产品风险，全流程把控产品的质量。
• 灰盒测试概念诞生—>当今产品的开发速度过快的环境下衍生的一种测试模式，根据需求高效的来进行产品测试，即包含了黑盒的纯用户行为的测试 又可以根据测试需求查看具体某一个功能代码的内部逻辑。

过程产物

一、软件开发模型

• 1.瀑布型（20世纪70年代）
  

  • 概念：
    将开发流程划分6个阶段—>制定计划、产品需求、设计功能、编码、测试、运维 各个阶段严格按照线性执行, 逐级操作, 从上到下固定次序
  • 优点：
    • 6个阶段 划分明确, 清晰
    • 只需要关注后续阶段
    • 迭代功能期间, 复用性高
    • 提供了一个开发模板 从分析->设计->开发测试->上线
  • 缺点：
    • 不灵活, 固化, 每个阶段产生大量文档(产品需求文档, 接口文档, 原型图, 设计报告, 测试报告, 测试设计, 运维报告, 上线文档)
    • 用户参与度比较低, 产品风险较高
    • 突出缺点是不适应用户需求的变化
    • 用户需要足够的耐心
  • 适用场景：
    • 需求非常明确, 变化极少的项目
    • 客户要求相对较低, 参与度低

• 2.快速开发模型
  

  • 概念：
    借助原型辅助工具根据用户的需求构建一个产品原型, 让用户参与使用, 反复进行：确认需求>需求敲定>运行查看>总结改进
  • 优点：
    适应用户需求的变化, 用户参与度比较高, 满意度比较高, 节约成本
  • 缺点：
    • 前提必须有 产品原型, 限制开发的思路
    • 开发技术和工具 不一定符合最新技术
    • 频繁修改
  • 适用场景：
    • 中小型的项目, 不适用大型项目
    • 对所开发的领域比较熟悉

• 3.增量模型（常用）
  

  • 概念：
    按照需求 将项目拆分模块化,开发一个模块,测试一个模块, 用户参与体验模块, 及时响应用户的需求
  • 优点：
    • 降低开发风险, 提高用户参与度
    • 模块顺序可以随时调整, 比较灵活
  • 缺点：需求变化 尽可能控制变化少
  • 适用场景：迭代更新、新产品开发

• 4.螺旋模型（20世纪90年代）
  

  • 概念：以风险分析驱动开发, 将瀑布型和快速原型模型结合.
  • 优点：
    • 设计灵活, 在整个阶段可以灵活调整变更
    • 风险更低
  • 缺点：
    • 风险评估的专家 要求特别高, 评估结果需要科学准确
    • 如果风险评估干扰了项目的营收, 整个风评可以不做
  • 适用场景：大型项目