软件测试 | 概念（1）

目录

前言

需求的概念

开发模型

软件的生命周期

常见开发模型

瀑布模型

螺旋模型

增量模型，迭代模型

敏捷模型

Scrum模型

测试模型 

V模型

W模型（双V模型）

---

前言

测试：验证软件的特性是否满足用户的需求。 用户的需求指 提升用户使用的满意度。

软件测试领域：软件测试工程师 和 软件测试开发工程师。

详情点击软件测试 - 认识-CSDN博客

虽然软件测试人员主要的工作职责是保障产品的测试质量，但是！软件的质量并不只由测试人员赖保障！！项目组（产品经理，前端开发，后端开发，测试，交互，设计...）所有成员都需要为产品质量负责。

开发和测试出现冲突怎么办？

1. 反思自己是否是bug描述的不清楚，或者由于自己的疏忽导致误判。
2. 站在用户的角度反问开发人员：如果你是用户你能接受这样的情况吗？
3. 不仅能提出问题，最好也能给出解决方案。

自动化测试是中大型企业中要掌握的一项必不可少的技术事务；对于测试人员来说，设计测试用例也是工作中必不可少的一环。 

需求的概念

在企业中，经常听到两个词：用户需求 和 软件需求。

• 用户需求：没有经过合理的评估，通常就是一句话。
• 软件需求：是开发人员和测试人员执行工作的依据。

用户的需求不能直接作为开发和测试的依据。针对用户的需求，产品经理需要进行需求分析（技术可行性，市场可行性，成本投入和收益占比等）后才可以转变为软件需求。

软件测试初学者，推荐《软件测试的艺术》一书。

开发模型

规范的流程是在时代的演变下逐渐成型，并不是一开始就是规范的流程。认识具体的开发模型之前先了解软件的生命周期。

软件的生命周期

就像人的生命周期一样，生命的开始，经历幼儿，儿童，青少年，青年，中年，中老年，老年，直到生命的结束...软件也具有生命周期。

案例：假设要建造一套房子（用户需求），房子的生命周期（流程）是什么样的？

步骤	总结	映射软件流程
为什么要建房子？商品房还是普通住宅？建造100层技术上是否可行？	明确合理的建房目标	需求分析（软件需求）
什么时候开发建房子？计划竣工时间？多久可以交房？	计划好时间	计划
建房前明确流程：先打地基，做基础框架，砌墙，粉刷，水电工程...	设计好具体的建房流程	设计（不同的角色涉及到的工作是不同的）
按照前面流程和时间实施建房中...	施工中	编码
房屋建造完成，开发商验收成果，买家验收房子品质（是否牢固，是否按照规定来建造的...）	检查房屋建造结果	测试
检查结束开始逐步入住，使用中出现的各种情况如房屋漏水，墙面掉皮，下水道堵塞等问题，一边使用一边找物业修理	使用并及时维护	运行维护

 解析：

设计阶段（不同的角色涉及到的工作是不同的）：

• 开发：设计开发文档（用什么技术，用什么框架等）。开发是统称（包括前端开发，1后端开发，客户端开发）
• 测试：明确需求，设计测试用例，测试计划，（明确本次测试涉及到的工具，测试类型...）

运行维护阶段：

• 软件上线后，在线上环境使用下可能会出现一些意想不到的情况。所以项目测试结束之后，项目需要进行上线并对产品进行线上的维护。
• 线上维护主要分为三个方面：修复性维护（对项目中未发现的问题进行修复），完善性维护（对功能进行完善），预防性维护（居安思危，为了避免产品在线上出现一些其他不可预测的问题，进行一些防护的手段）。
• 正常使用没有问题，但是在极端的情况下会出现问题（性能问题）

因此，我们就得到了软件开发的生命周期：

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

⭐软件的生命周期实际就是软件的开发模型。

常见开发模型

瀑布模型

• 特点：

每个流程只执行一次线性的开发流程。 （同软件的生命周期基础流程）

• 缺点：

测试后置。

        前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修          复的机会；必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给          用户（产品质量差）。

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

• 使用场景：

需求固定的小项目。

螺旋模型

•  特点：

螺旋模型中各阶段都引入了风险分析 + 原型。

引入的目的是减少各阶段遗留的风险问题，避免把问题留到后面的阶段。

• 优点

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

强调各开发阶段的质量；

增加风险分析和原型。

• 缺点

在螺旋模型中需要额外招聘专业的风险分析人才~（各阶段是否遗留问题完全取决于风险分析人员，这跟风险分析人员的技术完全挂钩。）

需求人员，资金，时间的增加和投入，可能会导致项目的成本太高。

• 适用场景

规模庞大，复杂度高，风险大的项目。

增量模型，迭代模型

p1增量模型，p2迭代模型

增量模型：将大需求拆分成小需求，每个小需求独立开发上线~

迭代模型：简单来说，就是先上线一个基础版本，再出优化版本1，优化版本2...

• 区别：

 增量是逐块建造的概念，迭代是反复求精的概念。

• 适用场景：

大型项目，需求不明确。

        迭代模型和增量模型在现在已经不会单独去使用，而是配合着去使用。

敏捷模型

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

实际工作中，一款产品的功能是不断在变化的~

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

强调高效的沟通；

强调轻文档，文档不应该作为工作验收的标准；

主动及时了解当下的需求；

能够主动迎接变化。

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

Scrum模型

Scrum是敏捷模型中的⼀种，⼜称为迭代式增量软件开发模型。

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

三个角色： 

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

• 其中product owner负责整理user story(用户需求)，定义其商业价值，对其进⾏排序，制定发布计划，对产品负责。（产品经理收集需求，产出软件需求文档）

• scrum master负责召开各种会议，协调项目，为研发团队服务。

• 研发团队则由不同技能的成员组成，通过紧密协同，完成每⼀次迭代的目标，交付产品。（由很多角色组成，开发人员（前端后端），测试，交互，设计...） 

 五个重要会议：

 scrum的基本流程如上图所示：

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

特点：轻文档 和 快速迭代。

文档指测试用例，测试计划文档，测试报告等。

测试模型 

两个⾮常重要且具有标志性的测试模型：V模型和W模型

V模型

• 优点：明确的标注了测试过程中存在的不同类型的测试。
• 缺点：仅把测试作为在编码后的一个阶段 未在需求阶段就介入测试。缺点同瀑布模型。

W模型（双V模型）

V模型中未将测试前置的问题在W模型中得以解决。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

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

开发V模型并不是单单指编码阶段，而是为产品开发流程而实施的各个阶段。

• 优点：

有利于尽早地全⾯的发现问题。

• 缺点：

需求、设计、编码等活动被视为串行的；

• 测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。

• 重流程，无法支持敏捷开发模式（轻文档轻流程）。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

---