伯通老师的软件测试笔记_01测试理论01_软件开发过程模型 ...

罗比尼奥

软件的组成部分(理解)

软件 = 程序 + 数据 + 文档   
文档 =  交付文档 + 中间过程文档   
软件研发过程中的不同角色以及中间文档(理解)

部门	角色(职位)	相关文档
产品部	产品经理	《需求规格说明书》,《原型文档》
开发部	软件开发工程师	《概要设计方案》，《详细设计方案》，《接口文档》
测试部	软件测试工程师	《测试计划》，《测试方案》，《测试用例》，《缺陷报告》，《测试报告》

软件工程的定义(了解)

把系统化的，规范化的，可度量的途径应用到软件开发，运行和维护的过程，也就是把工程化应用于项目当中。   
软件开发的过程模型(掌握)

瀑布模型(掌握)





把软件开发的过程分为了三个阶段：定义阶段，开发阶段，维护阶段  
瀑布模型当中，每个阶段的输出都是下个阶段的输入   
瀑布模型当中，当在一个阶段发生问题的时候可以返回上一个阶段进行调整  
特点

• 线性化的模型结构
  
• 各个阶段具有里程碑的特征
  
• 基于文档的驱动
  
• 严格的阶段评审机制
  

优点

• 提供了软件开发的基本框架
  
• 有利于大型软件开发过程的人员的组织和管理
  
• 提高了软件的质量和效率
  

缺点

• 不适应需求的变更
  
• 要到项目的结束阶段才能看到项目的效果
  

需求稳定的项目才适合使用瀑布模型   
自己研发，自己运营的产品不适合使用瀑布模型         
V模型(掌握)





和瀑布模型相比：
1. 设计阶段分为了详细设计和概要设计   
2. 测试阶段分为了单元测试，集成测试，系统测试，验收测试
优点：  
1. 强调了软件项目开发中需要经历的若干测试阶段
2. 每个测试阶段的依据都和相应的开发设计阶段对应   
缺点：  
V模式是瀑布模型的缺点，所有瀑布模型的缺点在V模型单中依然存在  
W模型(掌握)





用户需求阶段： 参与用户需求评审，编写验收测试用例  
需求分析阶段： 参与《需求规格说明书》，《原型文档》的评审，确保产品，开发，测试三方对需求理解的一致性；提出可测性需求；编写系统测试用例
概要设计阶段： 参与《概要设计方案》评审，编写集成测试方案和集成测试用例。   
详细设计阶段： 参与《详细设计方案》评审，编写单元测试方案和单元测试用例   
优点

• 测试的活动与软件开发同步
  
• 测试的对象不仅仅是程序，还包括，需求和设计
  
• 尽早的发现缺陷可以降低软件开发的成本
  

缺点

瀑布模型的缺点在W模型当中也存在  
模型完美，要求苛刻，落地困难   
敏捷模型(重点掌握)

敏捷模型的4个价值观

• 个体和交互胜过过程和工具  -- 强调的是以人为主，以沟通为主
  
• 可以工作的软件胜过面面俱到的文档  --  强调了简单
  
• 客户合作胜过合同谈判  -- 强调的是客户的反馈
  
• 响应变化胜过遵循计划  -- 强调的是拥抱变化
  

敏捷是一种价值观，或者是一种方法论， 是一个抽象的概念。
对敏捷的具体实现通常有两种:
1. Scrum
2. XP-极限编程      
Scrum

Scrum流程中的三大角色

• 产品负责人（Product Owner)
  确定产品的功能以及要达到的标准，指定软件的发布日期和交付的内容，同时有权利接受或者拒绝开发团队的工作成果。
  
• 流程管理员（Scrum Master）
  负责整个Scrum流程在项目中的顺利实施和进行，消除挡在客户和开发工作之间的沟通障碍，使得客户能够直接驱动开发。
  
• 开发团队(Scrum Team)
  负责软件产品在Scrum流程下进行开发工作，人数控制在5-10；每个技术人员负责不同的技术层面，但是要求每个成员要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何的工作方式，只要能够达到迭代（Sprint）目标。
  

Sprint?

指的是一次迭代，也叫做冲刺      
Scrum开发模型

• 确定Product Backlog(按优先级顺序排列的一个产品需求列表)，由产品负责人（Product Owner）负责；
  
• 开发团队（Scrum Team）会根据Product Backlog，做工作量的预估和安排；
  
• 有了Product Backlog，需要在Sprint Planning Meeting(Sprint计划会议)从中挑选一个Story（用户故事）作为本次迭代完成的目标，这个目标时间周期一般是1-4周，然后对Story进行细化，形成Sprint Backlog。
  
• Sprint Backlog是由开发团队（Scrum Team）去完成，每个成员根据Sprint Backlog再细化成更小的任务（工作量在2天内完成）
  
• 进行Daily Scrum Meeting(每日站立会议)，每个人必须发言；更新Sprint burn down(燃尽图)
  
• 做到每日集成，每天都要有一个可成功编译，并且可以演示的版本
  
• 当一个Sprint Backlog被完成，也就代表了一次迭代完成，这时候要进行Sprint Review Meeting(演示会议，评审会议)，产品负责人和客户都需要参加。
  
• 最后有一个回顾会议或者总结会议。
  

XP 极限编程（掌握）

XP 提倡的方法

• 开发过程当中至少有一名客户代表
  
• 快速交付（1-2周一个迭代）
  
• 结对编程
  
• 测试驱动开发（TDD）
  
• 代码集体公有
  
• 不加班-为了保证生产力，XP规定每周不超过40H
  
• 开放的工作空间
  
• 及时调整计划（允许在迭代周期内对当前迭代做修改）
  
• 重构-优化
  

XP和Scrum的区别

• 迭代的周期不同
  

• XP：1-2周
  
• Scrum: 1-4周
  

2. 迭代过程中是否允许修改需求

• XP：XP可以考虑修改需求，原则是需求的实现时间一致
  
• Scrum:一点迭代开工，不允许修改
  

3. 迭代中的需求是否严格按照优先级来实现

• XP: 必须遵循优先级级别
  
• Scrum可以不遵循优先级级别
  

软件开发的流程 （重点）