需求 bug 研发模型

目录
一. 三大基本概念

1. 需求
2. BUG(缺陷)
3. 测试用例
   二. 软件测试的流程
   三. 软件的生命周期
   四. 研发模型(5个)
4. 瀑布模型 (Waterfall Model)
5. 螺旋模型(Spiral Model)
6. 增量、迭代
7. 敏捷
   五. 传统开发模型与敏捷开发模型的区别(!!!重点)

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

1. 需求（就是需求说明书规定的功能）
   表示" 符合正式文档规定的条件和权能, 分用户需求和软件需求"

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

2. BUG(缺陷)
   表示"与需求规格说明书或用户期望不匹配"
   需求规格说明书: 一定要确保它的正确性;
   用户的期望: 一定要是合理期望.

3. 测试用例
   表示"向被测试的程序输入的一组集合, 这个集合要满足的要素有: 测试环境, 测试数据, 测试步骤, 预期结果, 备注, 测试版本, 前提条件等等".
   一定要记得它是一组集合, "测试环境, 测试数据, 测试步骤, 预期结果"这四项不能缺. 其他的可以扩展
   二. 软件测试的流程

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

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

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

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

8. 测试评估阶段
   出测试报告, 确认是否可以上线
   三. 软件的生命周期
   6个阶段: 需求–计划–设计–编码–测试–运行维护
   后面的模型都是在软件的生命周期基础上来实现的
   四. 研发模型(5个)

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

瀑布模型和软件的生命周期基本上是一样的, 只比软件的生命周期少一个 “运行维护” 阶段
特点: 是 "串型"的, 适合的项目: 需求相对稳定的项目(或者说 需求变更比较少的项目)、已有类似的项目或产品
优点: 每个阶段划分的很明确
缺点:
(1)发现缺陷的时机比较晚, 修改缺陷的成本高
(2)过程中积累的经验(不管是成功或者失败的经验), 不能及时分享给其他项目组
(3)测试是最后一个环节, 会被误认为测试不重要

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

特点: 是 "渐进式"的, 强调的是 “风险”. 每一个环里面都有风险分析这一阶段, 每一环的工作都比前一环要多, 是为了减少项目风险
适合的项目: 复杂度高, 风险大, 规模庞大
优点:
强调项目的风险. 即强调严格的全过程风险管理;
强调各开发阶段的质量;
提供机会检讨项目是否有价值继续下去。
缺点:
(1). 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。
(2). 风险分析需要时间, 增加成本, 因而会造成项目进度缓慢

3. 增量、迭代
   目的: 减少项目的风险
   适用项目: 大型项目.(增量迭代很适合 需要做半年, 一年, 几年的项目)
   增量迭代这两个模型很容易混淆, 下来分别介绍一下这两个模型的概念
   增量: 第一次发布一个功能, 第二次发布一个功能, 第二次发布的功能对第一次发布的功能对第一次功能没有任何影响, 不需要修改
   优点：

• 在较短的时间内为用户提交一些有用的工作产品，能解决用户的急需功能
• 每次只提交部分功能，因此用户有充分的时间学习和适应新功能
• 对系统的可维护性是一个极大的提高
  缺点：
  功能之间很难做到互相不影响
  迭代: 第二次发布的功能对第一次发布的功能有影响, 必须修改第一次发布中的一些功能. 如果不修改, 第一次的功能就出bug, 第二次发布的功能是无效的
  优点：
  降低了在一个增量上的开支风险。
  更适应需求的变化
  开发早期就确定风险，能尽快解决风险
  加快了整个开发工程的进度
  缺点：
  对管理者项目人员要求极高
  增量和迭代的概念: 假设现在要开发A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能; 而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成. 很容易理解吧。现实中我们常常是把这二种模型整合一起使用，即增量迭代，所以才会忽略它们单独的存在。

接下来是对增量和迭代优缺点的详细描述哦
增量优点：
1) 由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。
2）由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。
3）对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统。
缺点：
1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
迭代模型的优点 ：
传统的瀑布模型相比较，迭代过程具有以下优点：
1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
迭代模型缺点：
在项目早期开发可能有所变化 ，需有一个高素质的项目管理者和一个高技术水平的开发团队。

4. 敏捷
   敏捷的宣言有12个, 核心有4个宣言:
5. 轻文档 对文档的依赖度比较低
6. 客户参与
7. 拥抱变化 (需求变更的拥抱)能适应需求变更
8. 人与人之间的沟通 (最重要)
   目前比较流行的敏捷开发模型: scrum模型
   scrum 的三大核心角色:

• PO(product owner) 产品负责人
• SM(scrum master) 敏捷教练（流程管理员）
• TEAM 研发团队所有人, 包括PO, SM. 只是PO, SM特殊一些, 权力大一些
  优点：
  （1）高适应性（拥抱变更）
  （2） 注重人的因素，用户参与，强调与用户实时沟通
  （3）测试驱动，代替文档驱动（轻文档，用户全程参与，周期短）
  缺点：
  忽略文档的重要性，需要经验强的人员带领团队
  特点:
  (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才会找研发人员;
   而敏捷模型中测试和研发会频繁交流, 有问题随时就能沟通, 测试和研发人员的关系越来越好,避免了矛盾的发生.
   其实不仅仅是开发和测试人员的沟通频繁, 还有与客户等其他项目相关的人员也频繁了起来.