测试的概念

需求的概念

用户需求与软件需求

什么是用户需求

用户需求可以简单理解为甲方提出的需求。该需求一般比较简略，通常是一句话。比如：实现一个声控灯，实现一个软件的登录功能

什么是软件需求

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

用户需求和软件需求有什么不同呢？

举俩例子：
例1：用户需求：女朋友想吃红烧肉

软件需求

1. 买什么样的肉？
2. 放什么作料？
3. 煮多长时间？

例2：用户需求：平台支持邮箱注册

软件需求：

1.1.1.1 注册账号
1.1.1.1.1 功能概述
用户可以通过填写邮箱信息在平台注册个人用户。
1.1.1.1.2 用户角色
匿名用户。
1.1.1.1.3 前置条件
无。
1.1.1.1.4 输入

序号	栏位名称	栏位说明	长度	类型	备注
1	姓名	必填，录入个人姓名	6~15位	字符型
2	电子邮箱	必填，录入电子邮箱		字符型
3	密码	必填，输入的密码隐藏*号显示	6~15位	字符型
4	确认密码	必填，输入的密码隐藏*号显示	6~15位	字符型
5	验证码	必填，录入验证码		字符型
6	注册	注册操作		操作型

1.1.1.1.5 处理
1.1.1.1.5.1 基本事件流
1. 用户选择注册；
2. 系统展现用户协议界面，并请用户确认是否同意用户协议若用户不同意协议，系统禁止用户注册。若用户同意协议，用户进行注册信息填写。
3. 用户填写注册信息。注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。
4. 用户提交注册信息；
5. 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6. 用户可执行激活操作，直接跳转至注册邮箱门户页面。
7. 用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。1.1.1.1.5.2 扩展事件流
用户注册并激活成功后，第一次登录平台时，提示用户完善信息；
1.1.1.1.5.3 异常事件流
若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。
1.1.1.1.6 输出
用户注册成功
1.1.1.1.7 后置条件
该模块为用户登陆等的前置模块。

用户的需求能不能直接作为开发和测试的依据？

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

开发模型

学习开发模型之前，我们必须先了解软件的生命周期

软件的生命周期

软件的生命周期分为下面几个阶段

1. 需求分析
   • 根据用户需求，得出软件需求
2. 计划
   • 确定好项目各阶段的完成时间点
3. 设计
   • 开发：设计开发文档（用什么技术、用什么框架等等）
   • 测试：明确需求，设计测试用例、测试计划（明确本次测试设计到的工具、设计到的测试类型……）
4. 编码
   • 开发人员写代码
5. 测试
   • 测试人员测试代码
6. 运行维护
   • 修复性维护
   • 完善性维护
   • 预防性维护

对于软件的生命周期中，每个阶段都在做什么呢？

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

线上的维护主要分为三个方面

• 修复性维护：对项目中未发现的问题进行修复。
• 完善性维护：对功能进行完善。
• 预防性维护：居安思危，为了避免产品在线上出现一些其他
• 不可预料的问题：进行一些防护的手段

常见开发模型

瀑布模型

瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。

这也会给项目带来很大的风险，因为在瀑布模型中，测试阶段是非常靠后的，这就会有下面的问题

1. 如果在需求引入阶段的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工
2. 由于测试阶段很靠后，所以测试很可能时间不够，测试不充分就会导致bug非常多，用户体验非常差

瀑布模型适合怎样的项目呢？适合比较小的项目

螺旋模型

可以看下下面这张图

是不是感觉非常迷？其实我们把这条曲线掰直了，就长下面这样

螺旋模型的架构，其实就是在瀑布模型的基础上，中间加了几道风险分析。为啥要这么做呢？多分析，主要是为了尽量减少在软件需求设计上的缺陷。

我们前面讲了，需求设计上的缺陷如果在测试阶段才发现，就会导致前面的工作大面积返工，多分析的最终目的，就是为了尽量避免大面积返工

当然，这样的螺旋模型依然是存在问题的

1. 首先就是多次排查导致时间成本以及金钱成本都要增加
2. 风险分析的效果，与风险管理人员的技能水平有直接关系，这个人要是个二把刀，你分析一万回，效果也就那样，该返工害得返工

螺旋模型适合什么样的项目呢？适合比较复杂的项目

增量模型、迭代模型

所谓的增量模型很好理解，就是化整为零，目标拆解，逐个击破

至于递归模型，我们可以结合下面的图来理解

增量模型就是你负责画这个人物的头，我负责画这个人物的身体，他负责画这个人物的胳膊，以此类推。

而迭代模型就是第一遍首先画出架构。第二遍第三遍在第一遍架构的基础上逐渐完善细节。

举个迭代模型的例子，就比如说你要做一个电商平台，你第一轮基础版本做的就是浏览商品加下单的功能。第二轮优化版本新增了购物车功能，可以先将商品放到购物车中，然后最后一起下单。第三轮优化了产品的界面…

敏捷模型

敏捷模型的“敏捷”体现在什么地方？

（1）需求响应敏捷

• 灵活变更：传统开发模式中，需求一旦确定就难以更改，后期修改成本巨大。而敏捷模型拥抱变化，允许在项目开发过程中根据客户反馈、市场变化等对需求进行调整 。以Scrum为例，产品负责人（Product Owner）会整理用户故事（User Story）形成产品待办事项列表（Product Backlog），在每个迭代（Sprint）开始前，还可以根据优先级对列表进行调整，从而快速响应需求的变更。
• 快速验证：通过短周期的迭代开发，每次迭代都会交付一个可运行的产品增量。这使得客户或利益相关者能够尽早看到成果，并及时提出反馈意见，开发团队可以迅速根据这些反馈验证需求实现的正确性，调整后续开发方向，避免在错误的方向上投入过多资源。

（2）开发流程敏捷

• 迭代式开发：敏捷模型摒弃了传统的一次性交付模式，采用迭代式开发。将整个项目分解为多个短周期（通常为1 - 4周）的迭代，每个迭代都包含从需求分析、设计、开发到测试的完整过程，能够快速产出可工作的软件部分，不断增加产品的功能和价值 。
• 轻量级流程：相比传统开发模型复杂、繁琐的流程，敏捷模型简化了不必要的流程和文档工作。例如，在敏捷开发中，更注重面对面的沟通和交流，减少了对详尽书面文档的依赖。Scrum 模型中，主要依靠每日站会、迭代计划会议等几种简洁高效的会议形式来协调团队工作，提高沟通效率，快速推进项目。

（3）团队协作敏捷

• 跨职能团队：敏捷开发强调组建跨职能团队，团队成员涵盖了不同专业技能，如开发、测试、设计等。他们紧密协作，共同负责项目的推进和交付。在迭代过程中，成员之间可以快速沟通和协作，避免了传统开发中因职能部门壁垒导致的沟通不畅和效率低下问题。
• 自组织管理：敏捷团队具有较高的自主性和自组织性。团队成员可以自主决定如何完成任务，自行分配工作。Scrum Master 主要起到协调和服务的作用，帮助团队排除障碍，而不是像传统项目经理那样进行严格的指令性管理，这使得团队能够根据实际情况快速做出决策，提高工作效率。

（4）项目交付敏捷

• 持续交付：敏捷模型追求持续交付有价值的软件。通过频繁的迭代和自动化测试等手段，确保每次交付的软件都是经过验证、可工作的。这样可以及时向客户交付价值，获得客户的反馈和认可，也便于快速响应市场变化。
• 渐进式明确目标：项目初期不需要对所有细节进行精确规划，随着迭代的推进，目标和产品功能逐渐清晰和完善。这种渐进式的目标明确方式，使得项目能够根据实际情况灵活调整，快速适应内外部环境的变化，最终交付符合用户需求的产品。

scrum模型

Scrum是敏捷模型中的一种，又称为迭代式增量软件开发模型。你听这个名字就能感觉出，敏捷模型实际上就是迭代模型+增量模型

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

三个角色

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

• 其中product owner（产品经理）负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
  • 产品经理干的最重要的事儿，就是将用户需求转化为软件需求，向项目组输出软件需求文档
• scrum master（项目经理）负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

一个研发团队，也不仅仅有后端开发人员，具体来说包括：

• 开发人员（前端、后端）
• 测试、交互、设计…

五个重要会议

scrum的流程

• 产品负责人整理user story（用户需求）
• 发布计划会议：分析需求合理性，把不能实现的需求给剔除，
• 迭代计划会议：进行任务拆解，明确完成任务时间点
• 每日例会： 每天产品经理召集会议，团队成员回答昨天做了什么、今天计划做什么，有什么问题。
• 演示会议：一轮迭代结束之后，召开一次演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来
• 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果。

测试模型

测试模型它其实也是开发模型，但是由于这个模型里面测试的占比比较多，所以叫测试模型

V模型

V模型是瀑布模型的变种，它将测试模块进一步细分为了四块：

1. 单元测试
2. 集成测试
3. 系统测试
4. 验收测试

为啥要将一个线性模型掰成一个V字型呢？主要是为了突出水平方向的对应关系，比如：

用户需求对应的就是验收测试
需求分析对应的就是系统测试
概要设计对应的就是集成测试
详细设计对应的就是单元测试

V模型的缺点：和瀑布模型一样，线性模型中测试阶段排在编码的后面

1. 测试时间很可能不够用，导致测试不充分
2. 万一在测试的时候发现了需求分析的缺陷，需要大面积返工

W模型（双V模型）

双V模型其实就是两条线，一条对应开发流程，一条对应测试流程。既然如此，为啥还要掰成W的形状呢？

主要还是为了突出水平方向上各模块的对应关系。比如同一水平线上，用户需求——验收测试准备——交付——验收测试，他们都是围绕着用户来的

需求分析与系统设计——系统测试准备——实施——系统测试，他们都是围绕着系统来的

详细设计——单元测试准备——编码——单元测试，他们都是围绕着某一个单元来的

双V模型的最大特点就是开发测试两条线，同步进行，解决了V模型中测试模块后置带来的问题

但是它也有自己的问题，具体来说就是，如果开发线上系统设计完毕，但是测试线上系统测试没准备好，开发线就不能直接进入下一阶段，需要阻塞等待，直到测试那边也好了，再一起进入集成设计与测试阶段