开发和测试模型

瀑布模型

开发和测试模型_第1张图片

需求分析-计划-设计-编码-执行测试-运行维护

 

特点:


线性结构每个阶段只执行一次
其他模型的基础框架

缺点:

测试后置
前面的风险被推迟到测试阶段才被发现,项目大面积需要修改,工作量大

测试时间不够
没有充足的测试时间进行功能评估和需求功能比对,会将缺陷暴露给用户,影响用户体验

周期太长
产品上线时间周期长,影响生产效率

使用场景:
需求固定的小场景

螺旋模型

开发和测试模型_第2张图片

 

优点:


增加了风险分析和原型

缺点:

需要专门的风险分析人才,风险性和风险分析人员有关系

需要大量的时间,资本,人力投入

 

增量/迭代模型

增量模型把大的需求划分成一个个可以独立上线的功能

开发和测试模型_第3张图片

增量


可以先开发 1 2 ,再增加 3 4 5

迭代


可以先开发12345的基础版本
再迭代1 2 3 4 5 的进阶版本

敏捷模型

 开发和测试模型_第4张图片

个体交互重于过程和工具

可用软件重于完备的文档
客户协作重于合同谈判

响应变化重于遵循计划

敏捷模型(Agile Model)是一种迭代和增量的软件开发和项目管理方法,强调灵活性、协作和持续交付。

目标是通过频繁的迭代和持续反馈来快速响应需求变化并提供高质量的软件产品。

敏捷模型的核心原则包括:

  1. 个体和互动胜过流程和工具:注重团队成员之间的沟通和协作,强调人际关系和合作。

  2. 可工作的软件胜过详尽的文档:重视通过交付实际可运行的软件来验证和演示功能,而非过度依赖大量的文档。

  3. 客户合作胜过合同谈判:鼓励与客户密切合作,包括在项目过程中不断获取反馈和进行需求调整。

  4. 响应变化胜过遵循计划:接受需求变化的现实,并能够灵活地调整计划和优先级。

敏捷模型通常采用以下实践和方法:

  1. Scrum:Scrum 是一种广泛使用的敏捷框架,通过团队的迭代开发和时间框,将项目划分为一系列的短期开发周期(称为冲刺),以便快速交付软件,并持续获取反馈。

  2. 迭代开发:软件开发过程被划分为多个迭代周期,每个迭代周期内包含需求分析、设计、编码和测试等阶段,以便快速迭代开发和验证功能。

  3. 用户故事:以用户的需求和价值为中心,通过编写简短的用户故事来描述功能需求,以便开发团队理解和实现。

  4. 自组织团队:鼓励团队成员自组织、自我管理,促进更好的合作和决策。

  5. 持续集成和自动化测试:通过持续集成和自动化测试工具,确保团队能够频繁地集成和验证代码,减少错误和提高质量。

敏捷模型的好处包括更高的灵活性、更快的交付周期、更好的适应需求变化、更高的客户满意度和更好的团队协作。然而,敏捷模型也需要团队成员具备高度的沟通和协作能力,以及对变化的接受和适应能力。

scrum模型

主要三个角色

产品经理:需求管理,评断商业价值

项目经理:人力资源,召开项目,为研发团队服务

研发团队:在生产过程中使用技术创造/维护/测试/规范产品的人员

Scrum模型强调自组织和跨职能团队的合作,鼓励团队成员在项目中承担责任并共同完成任务。通过短周期的迭代和持续的反馈,Scrum模型能够快速适应变化和优化软件开发过程,提高项目的成功率和交付价值。

五个会议

根据需求池
发布计划会议
迭代计划会议
每日会议
演示会议
回顾会议

1. 发布计划会议(Release Planning Meeting):
      发布计划会议通常是在项目开始时或新迭代开始前召开的。这个会议的目标是为整个项目或产品的发布制定一个整体计划。

2. 迭代计划会议(Sprint Planning Meeting):
   迭代计划会议是在每个迭代周期开始前进行的。团队会明确要完成的任务和任务之间的依赖关系。

3. 每日会议(Daily Scrum):
   每日会议是每个迭代周期内的日常会议。在每日会议中,团队成员汇报前一天的工作进度,分享遇到的问题和障碍,并计划今天的工作。这有助于团队了解项目进展情况,并及时调整工作计划。

4. 演示会议(Sprint Review):
   演示会议是每个迭代周期结束后进行的。在这个会议上,团队展示已经完成的工作成果,并邀请利益相关者提供反馈和建议。演示会议有助于确保团队与利益相关者的沟通,确认项目进展和功能是否符合预期。

5. 回顾会议(Sprint Retrospective):
   回顾会议是每个迭代周期结束后进行的。在这个会议上,团队回顾过去迭代的工作过程,总结成功和改进的地方,并制定下个迭代的改进计划。回顾会议是持续改进的重要环节,助于团队优化开发过程和提高工作效率。

测试模型

V模型

开发和测试模型_第5张图片 

模型(V-Model): V模型以字母V的形状来表示软件开发和测试的生命周期。它强调测试活动与开发活动的紧密关联。在V模型中,每个开发阶段都有相应的测试阶段,测试阶段与开发阶段是一一对应的。V模型的各个阶段包括:

  • 需求分析阶段:在这个阶段,需求规格说明书被创建,其中包含了用户需求和系统功能的详细描述。
  • 系统设计阶段:在这个阶段,基于需求分析的结果,系统的整体架构和设计被定义。
  • 模块设计阶段:在这个阶段,系统被分解成模块,并进行详细的模块设计
     
  • 编码阶段:在这个阶段,根据模块设计,程序员开始编写代码。
     
  • 单元测试阶段:在这个阶段,对每个模块进行独立的单元测试,以验证其功能的正确性。
  • 集成测试阶段:在这个阶段,将已经通过单元测试的模块进行集成,并进行整体的功能测试。
  • 系统测试阶段:在这个阶段,对整个系统进行综合测试,以验证系统是否满足需求规格说明书中的功能和性能要求。
     
  • 验收测试阶段:在这个阶段,系统交付给用户,用户进行验收测试,以确定系统是否满足用户需求。

V模型的特点是测试活动与开发活动是一一对应的,测试活动发生在对应的开发活动之后。这种模型的优点是在早期就能够进行测试,缺点是较为刚性,变更和修复缺陷的成本较高。


W模型

重流程
测试开发双流程

开发和测试模型_第6张图片

W模型是在V模型的基础上扩展而来的一种模型。W模型将测试活动进一步细分,强调了多层次和多维度的测试。

  • 需求分析和收集阶段:收集和理解用户的需求,并将其转化为详细的需求规格说明。
  • 系统设计阶段:根据需求规格说明书,进行系统的整体架构设计、模块划分和接口设计。
  • 模块设计和开发阶段:根据系统设计,将系统划分为各个模块,然后进行详细的模块设计和开发。
  • 编码和单元测试阶段:根据模块设计,程序员编写代码,并进行针对每个模块的单元测试,验证其功能的正确性。
  • 集成测试阶段:将已经通过单元测试的模块进行集成,进行整体的功能测试,验证模块之间的接口和交互是否正常。
  • 系统测试阶段:对整个系统进行综合测试,验证系统是否满足需求规格说明书中的功能和性能要求。
  • 验收测试阶段:系统交付给用户,用户进行验收测试,以确定系统是否满足用户需求。


哈,谢谢各位同志的阅读,然后呢如果觉得本文对您有所帮助的话,还给个免费的赞捏

Thanks♪(・ω・)ノ

你可能感兴趣的:(测试工具,单元测试)