【软件测试】基础知识第二篇

一. 开发模型

1. 瀑布模型

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

适用场景：需求固定的小项目

缺点：测试被后置

• 需要留足够的时间来测试，否则测试不充分，导致缺陷遗留给用户。
• 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

2. 螺旋模型

螺旋模型是在瀑布模型的基础之上引入全流程的风险分析，每次分析完成之后都会生成一个新的原型

适用场景：规模庞大、复杂度高、风险大的项目。

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

3. 增量和迭代模型

3.1 增量模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

3.2 迭代模型

迭代模型（stagewise model）（也被称作迭代增量式开发或迭代进化式开发），是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

教学中，对迭代和版本的区别，可理解如下： 迭代一般指某版本的生产过程，包括从需求分析到测试完成； 版本一般指某阶段软件开发的结果，一个可交付使用的产品。

与传统的瀑布模型相比较，迭代过程具有以下优点：

• 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
• 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
• 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
• 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。因此复用性更高

3.3 增量和迭代模型的区别

增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……

而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

举个实例：

4. 敏捷模型

敏捷软件开发 (Agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果，关注业务优先级，检查与调整。敏捷软件开发要注意项目规模，规模增长，团队交流成本就上去了，因此敏捷软件开发暂时适合不是特别大的团队开发，比较适合一个组的团队使用。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

4.1 敏捷宣言

• 个体与交互重于过程和工具（轻流程，强调人与人之间高效地沟通）
• 可用的软件重于完备的文档（轻文档，重产出）
• 客户协作重于合同谈判
• 响应变化重于遵循计划
• 在每对比对中，后者并非全无价值，但我们更看重前者

敏捷宣言整体想表达敏捷模型的一个特点：轻流程、轻文档、重目标、重产出。

4.2 scrum模型

scrum模型介绍

• scrum的规模是比较小的，通常都是小团队10人内的
• 很多公司可能实行的是scrum的变种（在流程、人员上稍作改变）
• 敏捷的英文叫Agile，scrum只是其中一种小团队的（一般10人以下），更大规模的叫SAFe（上百上千）
• 敏捷，常常会跟软件开发的瀑布模型（waterfall）来进行比较
  • waterfall是老式的开发周期比较长的
  • 敏捷一般是小量迭代的，适应快速的市场变化的

人员

• Product Owner（PO）：一般翻译为产品经理，直译是"产品所有人"，对product backlog负责的人
• Scrum Master（SM）：项目经理。管敏捷流程的人
• Development Team：简称Team，由开发、测试等人员组成

需求池

• backlog 待办事项，分为prodct backlog和sprint backlog
  • product backlog：待办事项
  • sprint backlog：某次sprint要做的待办事项，由product backlog挑选出来放入sprintt backlgo
• sprint：某次迭代周期要做的事情，如sprint 1 / sprint 2 …（一次sprint安排的量通常是 1-3周完成），一般命名比如 sprint 1 加数字

会议

• sprint planning：在这个会议中讨论并从product backlog挑出下次sprint要做的事情，输出有sprint goal和sprint backlog
• daily scrum：指的是每天的会，也有叫daily meeting/daily standup/standup meeting，总之是每日站会，会上每个人一般会说明昨天做了什么、今天做什么、遇到什么困难，有时明天计划做什么也会说，其实就是每日交流会。一般还会提到白板这个概念
  • 白板：一般指实体的白色黑板，上面贴上类型to do/doing/…等不同时期的便利贴以便跟进进度情况
• sprint review：这个容易误以为是回顾会、复盘会，其实是对交付内容（即产品增量）进行review，即审查结果 （针对产品）
• sprint retrospective：回顾会，会上讨论做得好的做得不好的，是一个总结类似复盘的会议。（针对人）

其它名词

• increment：是一次sprint完成后的产出，即 “产品增量”，是产品增加了什么、修改了什么
• user story：用户故事，一般是用 “作为…我需要…以便…” 描述用户的需求的，由产品经理负责收集
• story：可以理解为描述要做什么的，story可拆分为更加细的任务（task）

流程
sprint backlog中挑出若干，在sprint planning中进行分析和拆分，会议输出sprint goal（目标）和sprint backlog（这次sprint要做的事情），进行迭代开发，每天有daily scrum（daily meeting），此次sprint完成后输出increment，对increment对行review的是spint review的过程，同时有sprint retrospective会议去总结团队成员做得好的做得不足的。

整个流程是Scrum Master去组织和把控的，所以SM会被翻译为 “流程管理员” 或者项目经理。

二. 开发模型

V 模型

优点：

• 明确标注了测试的类型
• 明确标注了测试阶段和开发阶段之间的对应关系

缺点：测试后置

W 模型

优点：测试从需求阶段就开始介入了

缺点：

• 上一个阶段完成，下一个阶段才能开始
• 开发和测试流程保持着一种前后的线性关系.
• 重文档、重过程，不支持敏捷模式