测试开发基础——概念

一 、测试开发概念

1. 需求

1.1. 用户需求

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略，通常是一句话。

1.2. 软件需求

或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。

2. 开发模型

推荐文章：https://www.cnblogs.com/zifeiy/p/9843594.html

2.1. 瀑布模型

特点：每个流程只执行一次，线性的开发流程

优点：

• 强调开发的阶段性
• 强调早期计划及需求调查
• 强调产品测试

缺陷：

• 测试后置：前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会；必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）
• 周期太长，产品很迟才能被看到和使用，可能会导致需求/功能过时

适用场景：需求固定的产品

2.2. 螺旋模型

特点：螺旋模型中各个阶段都引入风险分析（减少各阶段遗留的风险问题，避免把问题遗留到后面的阶段）

优点：每个阶段都会进行风险缝隙，避免一些线上问题发生

• 强调严格的全过程风险管理
• 强调各开发阶段的质量
• 提供机会检讨项目是否有价值继续下去

缺点：开发周期长，风险分析可能会出错，需要人力财力的投入（比如聘请风险分析师）

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

适用场景：适用比较大的项目

2.3. 增量模型、迭代模型

增量模型将一个大的需求修改成多个功能，每个功能独立开发上线。

增量模型可看做瀑布模型地一个变体，具有瀑布模型的所有优点。

此外，它还具有以下优点：

• 第一个可交付版本所需要的成本和时间很少
• 开发由增量表示的小系统所承担的风险不大
• 由于很快发布了第一个版本，因此可以减少用户需求的变更
• 运行增量投资，即在项目开始时，可以仅对一个或两个增量投资

增量模型由一下不足之处：

• 如果没有对用户的变更要求进行规划，那么产生的初始增量可能会早场后来增量的不稳定
• 如果需求不想早期思考的那样稳定和完整，呢么一些增量就可能需要重新开发，重新分布
• 管理发生的成本、进度和配置的复杂性可能会超出组织的能力

迭代模型：一个功能开发一个部分，然后再去开发另一个功能的一部分，会先上线一个基础版本，但是基础版本所有的功能都有只不过功能比较简陋，后期再继续迭代优化上线

适用场景：大型项目，需求不明确

现在的企业很少会独立使用这两个模型，而是会配合着一起去使用

2.4. 敏捷模型

在早期，迭代瀑布模型非常流行来完成一个项目。但是现在开发人员在使用它开发软件时面临着各种各样的问题。主要困难包括在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间。为了克服瀑布模型的这些缺点，在1990年代中期提出了敏捷软件开发模型。

敏捷模型主要旨在帮助项目快速适应变更请求。因此，敏捷模型的主要目的是促进项目的快速完成。

要完成这项任务，需要敏捷。敏捷性是通过使过程适应项目，删除对特定项目可能不是必需的活动来实现的。此外，避免任何浪费时间和精力的事情。

在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在小而易于管理，并且只能在几周内完成。一次为客户计划、开发和部署一个迭代。没有制定长期计划。

敏捷模型中有一个非常重要的《敏捷宣言》，宣言内容：

个体与交互重于过程和工具 --- 强调高效的沟通

可用的软件重于完备的文档 --- 强调轻文档，文档不应该作为工作验收的标准

客户协作重于合同谈判 --- 能够主动迎接变价，主动及时了解当下的需求

响应变化重于遵循计划 ---

宣言中主要运用了对比的手法，然而，在每对比对中，后者并非全无价值，但我们更看重前者。

通过敏捷宣言可以总结出敏捷模型的四个特点：轻文档，轻流程，重目标，重产出。

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

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

三个角色：

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

• 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• scrum master：负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

迭代开发

与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

五个会议：

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

敏捷中的测试 轻文档和快速迭代

• 敏捷模型中强调轻文档，所以测试人员不应使用传统的Excel编写测试用例的方法，更多的是使用思维导图、探索性测试（强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划)、自动化测试等
• 敏捷讲求合作，在敏捷项目组中，测试人员应多主动跟开发人员了解需求、讨论设计、一起研究bug出现的原因。

3. 测试模型

3.1. V模型

优点：

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

1. 单元和集成测试应检测程序的执行是否满足软件设计的要求；
2. 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
3. 验收测试确定软件的实现是否满足用户需要或合同的要求

缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点同瀑布模型。

3.2. W模型（双V模型）

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

优点：

• 有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

缺点：

• 需求、设计、编码等活动被视为串行的；
• 测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
• 重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。