【测试】-开发模型和测试模型

本篇我们学习开发模型和测试模型的特点以及适用场景

---

在了解开发模型和测试模型之前，我们首先需要了解一个软件的生命周期以及各阶段的概述

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成7个阶段，即需求分析、计划、设计、编码、测试、上线、运行维护。

软件的生命周期的各阶段概述

需求分析：分析需求是否合理，需求是否完整，软件需要做成什么样子。
计划：确认开发时间、测试时间，对应的开发人员、测试人员、产品经理等。
编码：通过软件特征实现软件特征
测试：测试人员测试软件是否有缺陷，产出对应的测试报告
上线：将项目推上线上环境，供用户使用
运行维护：如果出现线上问题，此时测试人员需要协助开发定位问题+解决问题，对项目不断的优化

开发模型和测试模型

 了解就软件的生命周期，接下来进行开发模型和测试模型的学习

软件开发模型

瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。
优点： 强调开发的阶段性； 强调早期计划及需求调查； 强调产品测试。
缺点： 依赖于早期进行的唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； –风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。
特点：线性的，测试参与时机太靠后，不能尽早发现问题
适用于：
小型的项目，迭代周期非常短

螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
优点： 强调严格的全过程风险管理。 –强调各开发阶段的质量。 –提供机会检讨项目是否有价值继续下去。
缺点：引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。
特点：每个阶段开始之前都有一个风险分析，可以避免一定的风险，但是风险分析需要一定的投入，如果分析错了，会造成一定的损失，同时不断的迭代，有可能造成项目延期
适用项目：适应比较大的项目，风险较多的项目

增量模型和迭代模型

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
特点：
增量模型，一个模块开发完毕，在开发下一个模块；
迭代模型：所有模块一起开发，先开发大的框架，再开发细节。

敏捷开发模式

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，上提出的《敏捷宣言》。
他们提出：我们通过身体力行和帮助他人来揭示更好的软件开发方式，从而形成了以下的价值观

 个体与交互重于过程和工具
 可用的软件重于完备的文档
 客户协作重于合同谈判
 响应变化重于遵循计划
 在每对比对中，后者并非全无价值，但我们更看重前者。

拥抱变化，轻流程，重交付，轻文档，重交互

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

scrum开发模式分为角色和会议两个方面

scrum里面的角色

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
产品经理（PO）：收集需求，来自客户的反馈，对其进行排序，制定发布计划，对产品负责；
项目经理（SM）： 负责召开各种会议，对需求优先级进行确定，项目计划确定
研发团队（team）：则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

scrum里面的会议

产品经理（PO）负责整理user story，形成左侧的product backlog。
• 发布计划会议：产品经理（PO）负责讲解user story，项目经理（SM）对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
• 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
• 每日例会：每天项目经理（SM）召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
• 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由PO整理，形成新的story。
• 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

敏捷中的测试

在敏捷开发中，测试人员面两两个挑战轻文档和快速迭代

1. 测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。
2. 测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试
3. 敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug出现的原因。

软件测试测试模型

软件测试v模型

特点：左边是开发，右边是测试，类似于瀑布模型，
优点：测试被划分为许多类型，
缺点：测试人员介入太晚，发现实际太晚，问题修复代价较大

软件测试双v模型（w模型）

特点：开发一个v，测试一个v
优点：测试人员尽早介入了需求
缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能适用于敏捷开发