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