需求

需求分为两部分:

1. 用户需求: 可以简单归为甲方提出的要求,或者终端用户使用产品时必须要完成的任务

2. 软件需求: 功能需求,会详细描述开发人员必须实现的软件功能,是测试人员进行测试工作的基本依据

开发模型

当软件工作的范围逐步扩展到了整个软件生命周期,例如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护,直到软件被更新和替换新的版本

模型例子:

软件的生命周期

生命周期指的是从生命的开始到生命结束的一段时间,比如人的生命周期就是从生命孕育为开始,经过幼年,童年,少年,青年,壮年,老年,最终死亡

所以软件的生命周期就是: 需求分析 --> 计划 --> 设计 --> 编码 --> 测试 --> 运行维护 

以下我将具体解释每一个阶段

阶段	具体内容	产出
需求分析	分析用户需求是否合理,从市场需求、技术等方面进行具体分析	需求文档
计划	对成立的需求执行需求执行计划,多长时间内完成该需求,每段时间具体完成哪些功能	计划文档
设计	将需求细化成一个个具体的任务,然后进行设计	技术文档
编码	开发人员参考需求文档、设计文档、交互图等文件进行代码的编写	代码文件等
测试	测试人员需要介入到软件的测试中来,参考测试用例对软件进行测试	测试用例、测试设计与计划、测试报告等文档
运行维护	项目测试结束之后,项目需要进行上线,并对产品进行线上的维护.线上的维护主要分为三个方面,分别为修复性维护、完善性维护和预防性维护

常见的开发模型

瀑布模型

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

优点

• 强调开发的阶段性

• 线性结构,每个阶段只执行一次

• 是其他模型的基础框架

缺点

• 测试后置

  • 前面各阶段遗留的风险推迟到测试阶段才被发现,导致项目大面积返工,失去了及早修复的机会

  • 必须留有足够多的时间进行测试活动,否则会导致测试不充分,将缺陷直接暴露给用户,也就是产品质量差

• 周期太长,产品很迟才能被看到和使用,可能会导致需求/功能过时

使用场景

需求固定的小项目

螺旋模型

当软件在开发初期阶段时需求如果不是很明确,就会采用渐进式的开发模式,而螺旋模式就是其中的一种

他采用了多次迭代来实现软件的生命周期,为软件测试带来了新的要求,不允许有一段独立的测试时间和阶段,测试也要跟随开发的迭代而迭代

优点

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

• 强调各开发阶段的质量

• 增加风险分析和原型

缺点

• 项目中可能存在的风险性与风险管理人员的技能水平有直接关系

• 需求人员、资金、时间的增加和投入,可能会导致项目的成本较高

使用场景

规模大、复杂度高、风险高的项目

增量模型、迭代模型

增量开发能显著降低项目风险,结合软件持续构建机制,构成了软件工程最佳实践之一,在这种开发模式下,每一次的迭代都意味着需求有可能要改变、构建出新的可执行软件版本,此时测试就要频繁进行

同时还有一个迭代开发,它与增量开发有一点点不同,增量开发时逐步建造的过程,而迭代开发是指一开始就构造出完整框架,然后不断进行完善

使用场景

大项目并需求不明确

敏捷模型

主要是为了帮助项目快速适应变更请求,目的就是促进项目的快速完成.同时敏捷性就是通过让过程适应项目,删除对待定项目可能不是必须的活动来实现,还可以避免时间和精力的浪费

敏捷模型中,需求被分解成许多可以增量开发的小部分.敏捷模型采用迭代开发,每个增量部分都是在迭代中开发的

敏捷模型中有一个非常重要的《敏捷宣言》,可以概括出四个特点: 轻文档、轻流程、重目标、重产出 ,敏捷开发有很多种方式,scrum就是比较流行的一种

scrum模型中,主要有三个角色和五个重要会议

三个角色

由产品经理、项目经理和研发团队组成

1. 产品经理:负责整理user story,并定义商业价值,然后进行排序,发布计划,同时要对产品负责

2. 项目经理负责召开各种会议,并协调项目,为研发团队服务

3. 研发团队由不同技能的成员组成,通过紧密合作,完成每一次的迭代目标,最后交付产品

五个重要会议

产品负责人负责整理user story,形成product backlog

1. 发布计划会议:产品经理负责讲解user story,进行评估和排序,发布计划会议的产出,制定出本次迭代要完成的story列表

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

3. 每日例会:每天由项目经理召集站立集会,团队人员要回答昨天做了什么以及当天的计划,同时在完成任务的过程中有什么问题

4. 演示例会:迭代结束之后,召开演示会议,相关人员都要参加,团队向大家展示本次迭代取得的成果,将大家的反馈记录下来,由产品经理进行整理,制定成新的story

5. 回顾会议:项目团队对本次迭代进行总结,发现不足,制定改进计划,下一次迭代继续完成,达到持续改进的效果

测试模型

V模型

目的是改进软件开发的效率和效果,是瀑布模型的变种

优点

• 明确的标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程期间各个阶段的对应关系,有效提升测试的质量和效率

• 单元和集成测试应检测程序的执行是否满足软件设计的要求

• 系统测试应监测系统功能、性能的质量特性是否达到系统要求的指标

• 验收测试确定软件的实现是否满足用户或合同的需要

缺点

只是将测试作为在一个编码之后的一个阶段,没有在需求阶段就参与测试,和瀑布模型的缺点是一样的

W模型

解决了V模型中的问题: 没有将测试前置 

增加了软件开发阶段中应同步进行的验证和确认活动,由两个V模型组成,分别代表测试和开发过程

特点:测试的对象不仅仅是程序,需求、设计等同样要测试1,测试与开发是同步进行的(此时就是软件测试贯穿了整个软件的生命周期)

优点

有利于尽早全面发现问题

缺点

• 需求、设计、编码等活动可能串行

• 测试和开发的活动保持一种线性的前后关系,只有一个阶段完全结束才能开始进行下一阶段