测试的基本概念和研发模型

目录

一. 三大基本概念

1. 需求

2. BUG(缺陷)

3. 测试用例

二. 软件测试的流程

三. 软件的生命周期

四. 研发模型(5个)

1. 瀑布模型 (Waterfall Model)

2. 螺旋模型(Spiral Model)

3. 增量、迭代

4. 敏捷

五. 传统开发模型与敏捷开发模型的区别(!!!重点)

---

首先, 介绍一下作为测试应掌握的三大概念~

一. 三大基本概念

1. 需求

表示" 符合正式文档规定的条件和权能, 分用户需求和软件需求"

• 用户需求: 比较粗略, 只是一个大概的功能说明
• 软件需求: (给研发人员看的)比较详细, 可以指导项目组成员进行下一步工作, 研发可以设计编码, 测试可以写测试用例. 我们要能把用户需求转化为软件需求

2. BUG(缺陷)

表示"与需求规格说明书或用户期望不匹配"

需求规格说明书: 一定要确保它的正确性;

用户的期望: 一定要是合理期望.

3. 测试用例

表示"向被测试的程序输入的一组集合, 这个集合要满足的要素有: 测试环境, 测试数据, 测试步骤, 预期结果, 备注, 测试版本, 前提条件等等".

重点: 它是一组集合, "测试环境, 测试数据, 测试步骤, 预期结果", 四项元素缺一不可. 其他的可以扩展

---

二. 软件测试的流程

1. 测试需求分析阶段

         阅读需求, 理解需求, 主要就是对业务的学习, 分析需求点, 参与需求评审会议.

2. 测试计划阶段

         主要任务就是编写测试计划, 参考软件需求规格说明书, 项目总体计划, 内容包括测试范围(来自需求文档), 进度安排, 人力物力的分配, 整体测试策略的制定. 风险评估与规避措施有一个制定.

3. 测试设计阶段

         主要是编写测试用例, 会参考需求文档(原型图), 概要设计, 详细设计等文档, 用例编写完成之后会进行评审.

4. 测试执行阶段

         搭建环境, 执行冒烟测试(预测试), 然后进入正式测试, bug管理直到测试结束.

5. 测试评估阶段

         出测试报告, 确认是否可以上线

三. 软件的生命周期

6个阶段: 需求--计划--设计--编码--测试--运行维护

后面的模型都是在软件的生命周期基础上来实现的

四. 研发模型(5个)

1. 瀑布模型 (Waterfall Model)

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

瀑布模型和软件的生命周期基本上是一样的, 只比软件的生命周期少一个 "运行维护" 阶段

特点: 是 "串型"的

适合的项目: 需求相对稳定的项目(或者说 需求变更比较少的项目), 已有类似的项目或产品

优点: 每个阶段划分的很明确

缺点:

      (1)发现缺陷的时机比较晚, 修改缺陷的成本高

      (2)过程中积累的经验(不管是成功或者失败的经验), 不能及时分享给其他项目组

      (3)测试是最后一个环节, 会被误认为测试不重要

2. 螺旋模型(Spiral Model)

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

特点: 是 "渐进式"的, 强调的是 "风险". 每一个环里面都有风险分析这一阶段, 每一环的工作都比前一环要多, 是为了减少项目风险

适合的项目: 复杂度高, 风险大, 规模庞大

优点: 强调项目的风险. 即强调严格的全过程风险管理; 强调各开发阶段的质量; 提供机会检讨项目是否有价值继续下去。

缺点:

    (1). 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。

    (2). 风险分析需要时间, 增加成本, 因而会造成项目进度缓慢

3. 增量、迭代

目的: 减少项目的风险

适用项目: 大型项目.(增量迭代很适合 需要做半年, 一年, 几年的项目)

增量迭代这两个模型很容易混淆, 下来分别介绍一下这两个模型的概念

增量: 第一次发布10个功能, 第二次发布10个功能, 第二次发布的功能对第一次发布的功能对第一次功能没有任何影响, 不需要修改

迭代: 第二次发布的功能对第一次发布的功能有影响, 必须修改第一次发布中的一些功能. 如果不修改, 第一次的功能就出bug, 第二次发布的功能是无效的

4. 敏捷

敏捷的宣言有12个, 核心有4个宣言:

1.  轻文档 对文档的依赖度比较低
2. 客户参与
3. 拥抱变化 需求变更的拥抱
4. 人与人之间的沟通 (最重要)

目前比较流行的敏捷开发模型: scrum

scrum 的三大核心角色:

• PO(product owner)    产品负责人
• SM(scrum master)     敏捷教练
• TEAM    研发团队所有人, 包括PO, SM. 只是PO, SM特殊一些, 权力大一些

敏捷开发的特点:

     (1). (研发+测试)人员要求5-10人; 但有些公司的项目组人可能多一点

     (2). 每天要开站会, 站会时间不超过15分钟; 每人要说一下昨天做了什么事情, 遇到了什么问题, 今天要做什么事情

     (3). 迭代周期1-4周, 一般不超过4周(即不超过一个月)

敏捷开发的流程:(!!!重点)

mysql的默认端口: 3306

• 1. po整理user story(即需求)
• 2. 发布计划会议. 确定项目进行几次迭代
• 3. 进行迭代会议. 分配任务, 确认时间. 当user story时间超过一周, 说明user story太大了, 会进行二次拆分
• 4. 研发中
• 5. 研发完成
• 6. 测试中. 测试发现的bug要进行缺陷管理, bug要进行跟踪, 最后还要关闭
• 7. 测试完成
• 8. 待发布. 因为 user story比较多, 测试需要时间
• 9. 发布上线

传统开发模型不关注过程, 只关注结果;

敏捷开发不仅关注结果, 更要关注过程.

大多数企业都用的是敏捷开发模型, 一些传统企业一般用的是传统模型,

五. 传统开发模型与敏捷开发模型的区别(!!!重点)

1. 传统开发模型有: 瀑布模型, 螺旋模型, 增量迭代模型.

瀑布模型适合 "需求相对稳定或需求变更少"的项目

螺旋模型适合 "复杂度高, 风险大, 规模大"的项目

增量迭代模型适合 "大型项目即需要做很久的项目"

2. 敏捷开发模型 有4大宣言, 最能区别开传统模型(轻文档, 客户参与, 拥抱变化, 人与人的沟通)

3. 以下是对传统模型和敏捷开发模型区别的个人总结:

(1) 传统模型"重文档", 敏捷模型"轻文档"

传统模型更加依赖用户需求文档;

而敏捷模型对文档的依赖度比较低

(2) 传统模型"客户不参与", 敏捷模型"客户参与"

传统模型中, 客户提出自己的需求之后, 整个项目就不再参与了, 等项目交付的时候则容易出现客户不认可不满意的情况;

而敏捷模型中, 客户参与的比较多, 哪里不满意哪里有需求, 可以进行沟通, 加以修改

(3) 传统模型"需求变更不方便", 敏捷模型 "欢迎需求变更"

传统模型中由于项目时间周期长, 客户不参与, 不沟通, 需求细节不明确, 等项目做完交付的时候客户不认可, 这时候改变需求是非常麻烦的, 很可能要重做, 白忙活一场.

敏捷模型中由于客户参与了进来, 可以随时按照客户的需求变更进行修改; 并且敏捷模型项目的时间周期短, 最长一个月, 最短一个周.

(4) 传统模型"人与人之间的沟通少", 敏捷模型"人与人的沟通频繁"

传统模型中测试和开发人员都是孤立的工作, 开发干完活就不再管了, 出了bug才会找研发人员;

而敏捷模型中测试和研发会频繁交流, 有问题随时就能沟通, 测试和研发人员的关系越来越好,避免了矛盾的发生.

其实不仅仅是开发和测试人员的沟通频繁, 还有与客户等其他项目相关的人员也频繁了起来.