目录
一、需求
什么是需求
满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
用户需求(用户提出的)：
可以简单地理解为甲方提出的需求。如果没有甲方，那就是终端用户使用产品的时候必须要完成的任务。
软件需求(开发人员实现的)：
或者叫功能需求，详细描述开发人员必须实现的软件功能，具体到设计哪些软件实现上的细节(例如设计什么接口、数据库等)。大部分公司在进行开发的时候，会把用户需求转化为软件需求。
为什么要把用户需求转化为软件需求:
市场可行性：市场占用的份额怎样，产品有没有市场？
技术可行性：能否在技术上实现用户提出的需求、技术上实现的难度？如果实现成本>>开发成本，那么这种需求就不要考虑了。例如"五彩斑斓的黑"这种需求肯定没办法实现。
举个例子：
用户需求为：平台实现邮箱注册。
软件需求为：
前端需要提交用户的信息（例如用户的账号、密码、确认密码、邮箱、邮箱发送之后的验证码）
后台需要的信息：与前端对接的接口名称是什么、如何执行发送验证码的逻辑、如何设计一个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。
回顾会议：对于本次迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进。
