1.什么是需求
(1) 需求的来源 用户需求,业务人员提出的需求-统称为用户需求 盈利:商业app(淘宝,美团,拼多多) 甲方:(ERP办公软件之类) 提高工作效率(公司内部的系统,比如物流公司,为了提高分拣货物,仓储货物的效率,开发一些相应的系统提高员工的工作效率)
(2)软件开发的流程 需求——计划——设计——开发/编码——测试——运行维护 用户需求:(系统的使用者提出的需求)系统要满足用户的期望,所需要的条件或者权限。 软件需求:用户需求经过验证和分析之后转换成合理的需求,一般以文档的形式演示。软件需求是用户需求的细化,细节的进一步具体实现文档。满足规范,标准,合同等文档所需要的条件和权能。软件需求是软件测试人员测试的依据。 案例:
2. 软件需求规格说明书
一、用户需求:平台支持邮箱注册 二、软件需求: 注册账号 功能概述:用户可以通过填写邮箱信息在平台注册个人用户。 用户角色 : 匿名用户 前置条件:无 输入
处理: 基本事件流 1、 用户选择注册 2、 系统展现用户协议界面,并请用户确认是否同意用户协议 若用户不同意协议,系统禁止用户注册。 若用户同意协议,用户进行注册信息填写。 3、 用户填写注册信息。 注册个人,填写:姓名,电子邮箱,密码,确认密码,验证码。 4、 用户提交注册信息; 5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户,若未收到激活邮 件,可使用注册的邮箱和密码登录系统后再次发送激活邮件。 6、 用户可执行激活操作,直接跳转至注册邮箱门户页面。 7、 用户通过接收到的电子邮件中的激活信息激活账号,用户注册完成,流程结束。 扩展事件流 用户注册并激活成功后,第一次登录平台时,提示用户完善信息; 异常事件流 若用户未收到激活邮件,可在登录界面录入电子邮件及密码后,再次发送激活邮件。 2. 每次发送的激活邮件,仅在发送邮件后起24小时之内有效,超过24小时后需重新发送激活邮件。 输出: 用户注册成功 后置条件:该模块为用户登陆等的前置模块。
3.从测试人员角度看需求
用户需求——软件需求——提炼出测试需求点——设计测试用例 (验证分析)
4.测试人员如何才能深入了解需求?
熟悉系统的所有业务,从需求一开始(用户提出需求开始)就介入,不断地和用户或者项目组人员讨论参与。把自己当用户。
5.测试用例
测试用例的概念:测试用例就是向被测试系统的某一个功能点发起的一组集合,包括测试环境,测试数据,测试步骤,预期结果(标题,测试功能,测试方式,方法,重要性,优先级…) 测试用例解决了两个问题。1.测什么?2.怎么测?同时,测试用例还包含了几个重要的要素:测试环境,测试数据,测试步骤和预期结果,如果符合预期结果,那么就说明功能点是正确的。
测试用例: 标题:输入符合规范的邮箱,密码,手机号注册 测试环境:Firefox 94.0.2 (64 位) windows10 MS-BGSKSXNHABTT(同一个软件在不同的浏览器里,不同的操作系统,具体表现不一样) 测试数据:(具体的数据) 邮箱:1728059190@163.com 密码:xiangshang123456 手机号:13672893094 测试步骤: 1.在浏览器中打开网易邮箱注册页面 2.输入测试数据 3.点击同意勾选框 4.点击立即注册 预期结果:注册成功
6.什么是BUG?
如果需求规格说明书(软件需求)存在并且合理,不符合需求规格说明的就是软件错误(BUG) 如果需求规格说明书(软件需求)不存在,用户的需求存在并且合理,不符合用户需求的就是软件错误(BUG) 不符合用户合理的需求的功能或者没有达到预期结果
7.软件开发的5个模型
软件开发的生命周期(软件开发的流程):需求——计划——设计——编码——测试——运行维护
7.1.瀑布模型
瀑布模型在软件工程中占有重要地位,是所有其他模型的基础框架,瀑布模型的每一个阶段都只执行一次,因此是先行顺序进行的软件开发模式。 优点: 强调开发的阶段性 强调早期计划及需求调查 强调产品测试 测试是产品质量的最后一道把关,如果有问题,问题会直接显示给用户 缺点: 串行,有去无回 测试介入晚,导致项目前期的问题到后面才发现,失去了错误及时修正的机会 不支持频繁的变动项目
7.2.螺旋模型
优点: 一个项目,分了很多层小迭代 适合风险比较大并且整个项目都比较大 每一个迭代分析,讨论项目是否有价值继续 缺点: 风险分析要求很高,需要投入专业的人员,导致时间,项目支出费用会比较高 风险分析对测试人员和开发人员呢要求比较高
7.3.迭代,增量模型
4周开发时间开发系统的A模块,B模块,C模块,D模块的功能 增量:第一周完成A模块,第二周完成B模块,第三周完成C模块,第四周完成D模块. 迭代:第一周完成ABCD四个模块的基础框架部分,第二周完成基础功能的开发和测试,第三周进一步开发复杂的功能,第四周完善细节。
7.4.敏捷开发模型
特点:重目标,重产出,轻文档,轻流程,拥抱变化,客户可以在开发过程中改变需求 注重和客户的沟通,整个研发团队有效沟通,注重产品的质量,注重产品的交付日期 敏捷开发周期很短(1周到4周不等),研发团队人员少(5到9人) scrum scrum里面的角色 PO:product owner(产品经理) ,负责整理用户需求,形成userstory SM;scrum master(项目经理),负责保证真个敏捷开发流程的顺利实施,开发和各种协调等 ST:scrum team(研发团队),负责整个项目的研发,各种技能的人组成,测试,开发,UI设计师等 具体怎么做: 1.发布计划会:产品经理负责整理user story(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责。决定本期迭代要开发的userstory 2.迭代会议计划:研发团队确认迭代任务,分解userstory,将userstory分解成一个个的任务,确定任务完成的时间,具体的人员等。 3.每日站会:三个问题:昨天完成了什么,遇到什么问题,今天的计划。 (不需要花费很多时间,重点在于总结和解决出现的问题,以及了解整个研发的过程) 4.产品演示会议:给客户和boss演示产品研发的成果,客户会提出改进意见,PO整理后形成新的userstory,放到下一次迭代中改进。 5.项目总结:总结这次迭代的优缺点,不足的改进,优化这个敏捷开发流程
8.软件测试模型
8.1软件测试V模型
缺点:串行的过程,测试在编码后有的,测试的介入比较晚,导致前期的错误后期才能发现,后期发现错误时,已经失去了错误及时纠正的最好时机
8.2软件测试W模型
特点: 测试人员在项目需求时就开始介入,前期的问题就可以及时发现 测试和开发是并行的,一个V是开发阶段,一个V是测试阶段 缺点: 串行,阶段性强,不适合频繁变更项目 不支持敏捷开发
|