目录

一、需求

什么是需求

用户需求(用户提出的)：

软件需求(开发人员实现的)：

为什么要把用户需求转化为软件需求:

需求和软件测试人员之间的关系

二、什么是bug

三、什么是测试用例 

测试环境：

操作步骤：

测试数据：

预期结果：

为什么要设计测试用例：

原因1：避免重复测试

四、开发模型和测试模型

软件开发的生命周期

需求分析

计划(产出计划文档)

设计(产出设计文档)

编码

测试

运行维护

瀑布模型(所有模型的基础) 

瀑布模型的缺陷

瀑布模型的适用场景

螺旋模型(每一步都多了一个"风险分析")

​编辑

螺旋模型的应用场景

螺旋模型的缺点

增量模型(拆解需求)

迭代模型(先画模板、然后具体)

敏捷模型

敏捷宣言

SCRUM(3角色、5会议)

5个会议如下：

一、需求

什么是需求

       满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

用户需求(用户提出的)：

       可以简单地理解为甲方提出的需求。如果没有甲方，那就是终端用户使用产品的时候必须要完成的任务。

软件需求(开发人员实现的)：

       或者叫功能需求，详细描述开发人员必须实现的软件功能，具体到设计哪些软件实现上的细节(例如设计什么接口、数据库等)。大部分公司在进行开发的时候，会把用户需求转化为软件需求。

为什么要把用户需求转化为软件需求:

市场可行性：市场占用的份额怎样，产品有没有市场？

技术可行性：能否在技术上实现用户提出的需求、技术上实现的难度？如果实现成本>>开发成本，那么这种需求就不要考虑了。例如"五彩斑斓的黑"这种需求肯定没办法实现。

举个例子：

用户需求为：平台实现邮箱注册。

软件需求为：

       前端需要提交用户的信息（例如用户的账号、密码、确认密码、邮箱、邮箱发送之后的验证码）

       后台需要的信息：与前端对接的接口名称是什么、如何执行发送验证码的逻辑、如何设计一个User类以及User类对应的持久化存储方式，如果注册成功/注册异常给的提示等等...

需求和软件测试人员之间的关系

       需求是测试人员开展软件测试工作的依据。

       从软件功能需求出发，无遗漏地识别出测试的需求是至关重要的，这将直接关系到测试用例的测试覆盖率。

       对于每一个测试的需求点，需要设计具体的测试用例。

二、什么是bug

       当且仅当规格说明是存在并且正确的情况下，程序与规格说明之间的不匹配就是bug。也就是说，当程序执行不符合预期的时候，那就说明产生了bug。

       在前面的多线程的文章当中，我们提到了，出现线程安全问题，其实也就是出现了bug。

三、什么是测试用例 

测试用例是为了实施测试而向被测试系统提供的一组集合。

这一组集合包含了以下的内容：

测试环境：

       例如测试的环境是PC端还是微信端还是安卓APP端、在哪一个浏览器上面打开、操作系统是什么、这是的操作系统等等步骤。

操作步骤：

       指的是具体怎样进行测试的步骤。例如我想测试一个邮箱注册的接口，那么就需要经过下面几个步骤。

步骤1：打开浏览器、输入网址；

步骤2：输入邮箱地址、密码、手机号等等的信息；

步骤3：点击注册。

测试数据：

       具体使用哪些数据进行测试。

       例如我想测试一个邮箱注册的接口，那么就需要针对输入的内容数据进行下面的几个测试。

预期结果：

         验证测试的结果与预期的结果是否一致。

         此处预期展现注册成功，并且可以使用注册的邮箱进行登录。

为什么要设计测试用例：

原因1：避免重复测试

       一个测试用例，如果用了之后就丢弃，那么很有可能在以后出现相同的测试用例不断重复出现的现象，这其实是一种冗余的现象。

四、开发模型和测试模型

软件开发的生命周期

需求分析

产品经理收集用户的需求，分析用户需求是否合理(市场分析、技术分析等)

计划(产出计划文档)

制定软件什么时候开始、什么时候结束。（制定需求的计划）

包括消耗多少人力，多少人员一起参与开发、测试等等。

设计(产出设计文档)

将需求细化为一个个的任务，进行技术设计（需要使用哪些技术，例如sql等。需要哪些接口）

编码

开发人员按照需求文档、设计文档来进行编码。

测试

测试人员参考测试用例来执行测试。

运行维护

项目上线之后对产品进行线上的维护。

修复性维护：对于未发现的问题进行修复、

完善性维护：对功能进行完善

预防性维护：为了避免产品在线上出现一些其他问题，进行一些预防的手段(例如预防用户访问量突然增多的情况)。

总结：

先拿到需求，然后计划项目开发的周期

有了计划，就需要细分怎样设计这个项目

然后，开发人员根据需求文档和设计文档进行编码。

同时、测试人员也需要根据测试用例对于项目进行测试。

最后，项目上线、需要三种维护。

瀑布模型(所有模型的基础) 

按照：

       开始->需求分析-->计划-->设计-->编码-->测试-->运行维护->结束这几个步骤进行开发的模型就是"瀑布模型"。瀑布模型比软件的生命周期多了"开始"和"结束"这两个步骤。

       呈现的是一种线性的模型。

瀑布模型的缺陷

缺陷1：

       每一步都是独立进行的，风险往往是推迟到最后期才发现（因为测试阶段放在了最后），因此失去了及早纠错的机会。

缺陷2：

       没有足够的时间留给测试活动，导致测试时间不充分，从而导致直接把问题遗留给用户。

瀑布模型的适用场景

适用于一些中小型的项目，并且需求基本是固定的，不"拥抱变化"。

螺旋模型(每一步都多了一个"风险分析")

       螺旋模型其实是基于"瀑布模型"的一种改良和升级。其中，升级的部分在于：在瀑布模型的基础上面：每走一步，都多了一步风险分析。然后，根据这一个风险生成一个原型。

总览一下：螺旋模型 

螺旋模型的应用场景

规模庞大、复杂度高、风险比较大的项目，因为需要不断地进行评估。

螺旋模型的缺点

时间拉长并且需要的人力、资金比较庞大。

增量模型(拆解需求)

假设根据产品经理提出的需求，功能包含A、B、C一共3个需求。

对于增量模型来说，它的特点就是对于每一个小的需求，分开进行编码和测试、分开上线。

迭代模型(先画模板、然后具体)

这一个模型和增量模型有一定的相似程度。

迭代模型，其实就是分为了以下两个独立的步骤：

步骤1：先依次开发出来一个A、B、C三个需求的简易模型

步骤2：在后续的开发当中，再并行对A、B、C进行迭代开发。

 这就好像画画，先画一个轮廓、然后再画具体的模型。依次迭代

敏捷模型

敏捷宣言

敏捷模型的描述，就需要看一下"敏捷宣言"。

• 个体和互动高于流程和工具（轻流程、重交流）

• 工作的软件高于详尽的文档（轻文档、重产出）

• 客户合作高于合同谈判（多和客户进行交流）

• 响应变化高于遵循计划（及时响应用户的需求）

总结一下，就是：

轻：流程、文档。

重：目标、产出。

敏捷模型当中，有一个非常重要的角色，就是：

SCRUM(3角色、5会议)

SCRUM当中有：3个角色、5场会议。

3个角色如下：

产品经理：编写需求文档、对产品负责的人。

项目经理：推动项目进行执行的人、监督项目的开发进程。

研发团队：开发人员、测试人员、UI人员等等

在了解5个会议之前，首先了解一下几个专业的名词。

需求代办列表(需求池)：专门存放没有实现的用户需求。

周期内需要实现的用户需求(story 列表)：

5个会议如下：

      发布计划会议：产品经理负责讲解用户需求，对于用户需求(user story)，发布这一期迭代要完成的story列表，其实就是发布项目整体的计划列表(sprint backlog)。

      迭代计划会议：对于每一个story进行拆解，明确负责人，完成工时的初步估计。

      每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么，有什么问题。及时僚机风险、规避风险。产出物：每日例会产出一个可交付的软件。

      演示会议：团队负责人向大家展示本次迭代取得的成果。产出物：新的user story。

      回顾会议：对于本次迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进。