目录：

软件测试生命周期与软件开发生命周期

开发模型
2.1 瀑布模型
2.2 螺旋模型
2.3 增量 和 迭代
2.4 敏捷

测试模型
3.1 V模型
3.2 W模型

1. 软件开发生命周期与软件测试生命周期

• 软件的生命周期是指从软件产品的设想开始，到软件不再使用结束的时间。

阶段软件开发生命周期软件测试生命周期

（1）	需求阶段	需求阶段
（2）	计划阶段	测试计划
（3）	设计阶段	测试设计
（4）	编码阶段	测试执行
（5）	测试阶段	测试评估
（6）	运行维护

注：开发阶段 与 测试阶段 的前三个阶段完全一致。

2. 开发模型

2.1 瀑布模型

• 瀑布模型的每一个阶段只执行依此，因此是线性顺序进行的软件开发模式。
• 优点

强调开发的阶段性；

强调早期计划及需求调查；

强调产品测试。

• 缺点

依赖于早期进行的唯一一次需求调查，不能适应需求变化；

由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；

风险往往直到测试阶段才显露，失去纠正的机会 。

2.2 螺旋模型

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

• 螺旋模型尤其适用于那些规模庞大，复杂度高，风险大的项目。
  这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。

• 优点

• 强调严格的全过程风险管理；

• 强调各开发阶段的质量；

• 提供机会检讨项目是否有价值继续下去。

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

2.3 增量 和 迭代

• 增量：强调的是逐块建造。可以理解为在画人物画像的时候，先画头，再画躯干，四肢。
• 迭代：强调的是反复求精的概念。可以理解为在画人物画像的时候，先画出人物的轮廓，再勾勒出雏形，再细化，上色。

2.4 敏捷

• 《敏捷宣言》中提出：我们通过身体力行和帮助他人来揭示更好的软件开发方式。

• 敏捷宣言（四个宣言）：
  

• 个体与交互重于过程和工具；—强调沟通
  

• 可用的软件重于完备的文档；—轻文档
  

• 客户协作重于合同谈判；—客户全程参与
  

• 响应变化重于遵循计划。—拥抱变化
  
  在每对对比中，后者并不是全无价值，但是我们更看重前者。

• scrum
  scrum是敏捷开发中比较流行的一种方式。
  组成：
  （1）product owner(产品经理)—整理需求，发布计划（权限最大）
  （2）scrum master(项目经理)—服务，协调团队
  （3）team(研发团队)—由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

• 迭代开发
  scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

• scrum流程（六个步骤）
  

• 产品负责人负责整理user story，形成product backlog；
  

• 发布计划会议：po负责讲解user story，对其进行估算和排序，制定出这一期迭代要完成的user story—sprint backlog
  

• 迭代计划会议：项目团队对每一个story进行分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计；
  

• 每日例会：每天scrum master召集站立会议，每个成员回答自己干了什么，要干什么，有什么问题；
  

• 演示会议：迭代结束之后，召开演示会议，团队负责向大家展示本次迭代取得的成绩。把大家的反馈记录下来，由po整理，形成新的story；
  

• 回顾会议：项目团队对本次迭代进行总结，发现不足，制定改进计划，下一次迭代持续改进，以达到持续改进的效果。
  

• 敏捷中的测试：

• 测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。

• 测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试

• 敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug出现的原因。

3. 测试模型

3.1 测试中的V模型

• 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了各测试过程与开发过程期间各阶段的对应关系。
• V模型中测试人员参与二点阶段 与 该阶段测试人员所完成的任务

开发阶段测试阶段

用户需求/需求分析与系统	了解需求，学习项目的范围，目的
概要设计	进行测试计划的编写
编码设计	进行测试用例的编写
系统测试	环境搭建，准备数据，测试执行，缺陷管理，编写测试报告
验收测试	协助用户进行验收

注：单元测试，集成测试，普通测试人员不参与，研发人员与白盒测试工程师完成。

• V模型指出
  单元和集成测试应检测程序的执行是否满足软件设计的要求；
  系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
  验收测试确定软件的实现是否满足用户需要或合同的要求。
• V模型的优点：
  强调测试。
• V模型的缺点
  和瀑布模型一样，测试时间晚。

3.2 测试中的W模型（双V模型）

• 为了解决V模型的缺陷，引入W模型（双V模型）
  

• W模型中增加了开发过程中各阶段对应的验证与确认活动。
  一个V是研发线，一个V是测试线。
  （两条线并行）
  

• W模型的特点：
  测试与开发是同步进行的。

• W模型的优点:
  有利于尽早，全面的发现问题

• W模型的缺点
  不支持敏捷模式。