测试--概念篇-CSDN博客

用户需求和软件需求有什么不同呢？看看下⾯的案例

用户需求：

⼥朋友说, 我饿了, 这是⼀个⽤⼾需求. 很简略.

软件需求：

需要你和她反复的沟通了解更加详细具体的需求, 来制定解决⽅案.

比如你问她："想吃什么？" 她回答："随便"
"红烧肉怎么样？" "不想吃"
"那你想吃什么？" "随便"
"油泼面呢？" "不想吃"
"那你想吃什么？" "随便"

...

最终理解清楚用户需求之后, 知道女朋友想吃的是你做的火锅？！！, 那么再去研究⾁怎么买, 怎么做等等的具体步骤是软件需求.

一份 软件需求规格说明书（部分）--关于 “用户注册功能” 的详细描述片段

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

2.开发模型

2.1模型

随着软件⼯程学科的发展，⼈们对计算机软件的认识逐渐深⼊。软件⼯作的范围不仅仅局限在程序编写，⽽是扩展到了整个软件⽣命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装、部署、运⾏维护，直到软件被更新和替换新的版本。软件⼯程还包括很多技术性的管理⼯作，例如过程管理、产品管理、资源管理和质量管理，在这些⽅⾯也逐步地建⽴起了标准或规范。

2.1.1软件的生命周期

什么是 ⽣命周期 ？

⽣命周期指的是从⽣命的开始到⽣命结束的⼀段时间。以⼈为例，⼈类的⽣命周期是从⽣命孕育的开始，中间会经历幼年，童年，少年，⻘年，⽼年，最终直⾄死亡。

软件也有生命周期：

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

每个阶段做的内容也各不相同

阶段	具体内容	产出
需求分析	分析用户的需求是否合理，分别从市场需求、技术等方面进行分析。	该阶段会输出需求等文档
计划	对成立的需求执行需求执行计划，多长时间内完成该需求，每阶段时间具体完成哪些功能。	该阶段会输出计划等文档
设计	将需求细化成一个个小任务，团队人员各司其职领取分布的任务进行技术设计（如何进行架构设计，设计哪些接口等）。	该阶段会输出计划等文档
编码	开发人员参考需求文档、设计文档、交互图等文件进行代码编写。	代码文件等文档
测试	测试人员需要介入到软件的测试中来，参考测试用例对软件进行测试。	测试用例、测试设计与计划、测试报告等文档
运行维护	项⽬测试结束之后，项目需要进⾏上线，并对产品进行线上的维护。线上的维护主要分为三个方面。分别为修复性维护（计划中为发的问题进行修复）、完善性维护（对功能进行完善）和预防性维护（防护手段）。

产品经理：定需求，明确需求是否正常执行中

项目经理：为整个项目负责，人员调配等工作

交互：设计交互图

前端：设计前端内容（框架、技术、工具）

后端：设计后端内容（框架、技术、工具）

测试：测试用例、测试计划（测试类型、工具等）

...

2.2常见开发模型

2.2.1瀑布模型

瀑布模型是一种经典的软件开发方法论，采用线性、顺序化的设计流程，将项目划分为明确的阶段。每个阶段需完成后才能进入下一阶段，强调文档化和阶段性评审，适用于需求明确、变更较少的项目。

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

缺点：

测试后置

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

周期太长，产品很晚才能被看到，可达会导致需求/功能过时.

瀑布模型适用的场景：需求固定的小项目.

2.2.2螺旋模型

螺旋模型是一种结合了瀑布模型和原型开发的软件开发方法，由Barry Boehm于1986年提出。其核心思想是通过迭代循环逐步完善系统，每个循环包含风险分析、原型设计、开发与测试等阶段。

特点：螺旋模型中各个阶段都引入的 风险分析+原型

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

优点：

强调严格的全过程风险管理
强调各开发阶段的质量
增加风险分析和原型

缺点：

项目中可能存在风险性与风险管理人员的技能水平有直接关系
需求人员、资金、时间的增加和投入，可能会导致项目的成本太高

适用场景：大型复杂项目和高风险.

2.2.3增量模型、迭代模型

增量模型是一种软件开发方法，将系统划分为多个独立的模块或功能块，分批次交付。每个增量版本都包含一部分完整功能，用户可逐步使用新功能，同时开发团队继续构建后续增量。

迭代模型通过重复循环的开发过程逐步完善系统。每次迭代都包含完整的开发周期（需求、设计、实现、测试），逐步增加功能或优化现有功能。

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流⾏的软件⼯程最佳实践之⼀。增量开发模型，⿎励用户反馈，在每个迭代过程中，促使开发⼩组以⼀种循环的、可预测的⽅式驱动产品的开发。因此，在这种开发模式下，每⼀次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进⾏，测试⼈员需要与开发⼈员更加紧密地协作。

与此类似的有⼀个迭代开发，增量开发和迭代开发往往容易被⼈，但是其实两者是有区别的。增量是逐块建造的概念，迭代是反复求精的概念。

例如画画（AI生成的，手残见谅）

增量模型是先画⼈的头部，再画⾝体，再画⼿脚……

迭代模型是先画整体轮廓，再勾勒出基本雏形，再细化、着⾊...

适⽤场景： ⼤型项⽬，需求不明确

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

2.2.4敏捷模型

主要困难包括在项⽬开发期间处理来⾃客⼾的变更请求以及合并这些变更所需的 ⾼成本

和时间 。为了克服瀑布模型的这些缺点，在1990年代中期提出了敏捷软件开发模型。

敏捷模型中有⼀个⾮常重要的《敏捷宣⾔》，宣⾔内容：

个体与交互重于过程和⼯具
可⽤的软件重于完备的⽂档
客⼾协作重于合同谈判
响应变化重于遵循计划

捷模型的四个特点： 轻文档，轻流程，重目标，重产出 。敏捷开发有很多种⽅式，其中scrum是比较流行的一种。

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

三个角色：

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

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

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

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

敏捷中的测试：

轻⽂档和快速迭代

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

3.测试模型

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

3.1V模型

V模型最早是由Paul Rook在20世纪80年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种。

优点：

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

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

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

3.2W模型（双V模型）

V模型中未将测试前置的问题在W模型中得以解决

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

优点：

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

缺点：

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