开发模型、测试模型

• 在谈论开发模型和测试模型之前，我们先来了解一下软件的生命周期
  

  软件生命周期是指，从软件产品的设想开始到软件不在使用而结束的时间。
  软件的生命周期分为六个阶段：需求分析、计划、设计、编码、测试、运行维护。

一、开发模型

1.瀑布模型（Waterfall Model）

• 适用场景：适合需求变化少的项目、是串行的。

• 优点：
  （1）强调开发的阶段性；
  （2）强调早期计划及需求调查；
  （3）强调产品测试。

• 缺点：
  （1）依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
  （2）流程单一，开发中的经验教训不能反馈应用于本产品的过程；
  （3）风险性延迟至后期的测试阶段才显露，失去了早纠正的机会。

2.螺旋模型（Spiral Model）

• 适用场景：强点风险分析，适合规模大的、复杂度高的项目。

• 优点：
  （1）强调严格的过程风险管理；
  （2）强调各开发阶段的质量；
  （3）提供机会检讨项目是否有价值继续下去。

• 缺点：引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

3.增量、迭代

• 增量是指一块一块来进行测试、而迭代是指先整体再细化。
  举个例子：比如画一个人物肖像，用增量，就是先画头，再画胳膊，再画腿；而用迭代就是先描绘出来一个整体的轮廓，然后再将每一个部分细化。

• 增量通常和迭代混为一块，可以降低风险，和螺旋结构相似。

4.敏捷

（1）《敏捷宣言》
- 个体与交互重于过程和工具（强调“人与人的沟通”）
- 可用的软件重于完备的文档（强调“轻文档”，对文档的依赖性不高）
- 客户协作重于合同谈判（强调“客户参与”）
- 响应变化重于遵循计划（强调“拥抱变化”）

敏捷开发有很多方式，其中scrum是比较流行的一种。

（2）敏捷中的角色
scrum有product owner（类似于“产品经理”），scrum master（类似于“项目经理”），team（研发团队）组成。

• product owner负责整理user story（用户故事），定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• scrum master负责召开各种会议，协调项目，为研发团队服务。
• 研发团队由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
  （3）敏捷中的测试
• 挑战1：轻文档（即：对文档的依赖性比较少）
• 挑战2：快速迭代（即：最长不超过一句话，一般是两周）
  通过以上学习，敏捷这份工作的有趣之处还有很多，有兴趣的老铁们可以自己上网查一查

二、测试模型

1.软件测试V模型（瀑布模型的变种）

• 优点：该模型明确标注了测试过程中存在的不同类型的测试，并且清楚地描述了这些测试阶段和开发过程期间各个阶段的对应关系。
• 缺点：本模型具有局限性（仅仅把测试作为编码之后的一个阶段，未在需求阶段就进入测试）。

2.软件测试的W模型（双“V”模型）

• 
  
• 优点：从图片中我们不难发现，在W模型下，测试和开发的并行的关系。这样有利于尽早的全面的发现问题。例如，在需求分析结束后，测试人员就应该尽早的参与到需求验证和确认活动中，以便于尽早的发现缺陷所在。
• 缺点：该模型还是有一定的局限性，虽然说开发和测试是并行的，但该模型整体还是串行的。无法支持敏捷开发模式。
  

配置管理器（Configuration Mangement）：是通过对在软件生命周期不同的时间点上的软件配置进行标识、并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可塑性的过程。