二、概念篇

测试概念

测试的概念:验证软件的特性是否满足用户的需求

软件需求文档类似于下面的表述:

软件需求规格说明书

一、用户需求: 平台支持邮箱注册

二、软件需求:

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.2.1 基本事件流

1、用户选择注册:

2、系统展现用户协议界面,并请用户确认是否同意用户协议

若用户不同意协议,系统禁止用户注册。

若用户同意协议,用户进行注册信息填写。

3、用户填写注册信息。

注册个人,填写:姓名,电子邮箱,密码,确认密码,验证码。

4、用户提交注册信息;

5、系统提示用户并向用户注册的电子邮箱地址发送一封含有激活信息的电子邮件。系统并提示用户,若未收到激活邮件,可使用注册的邮箱和密码登录系统后再次发送激活邮件

6、用户可执行激活操作,直接跳转至注册邮箱门户页面

7、用户通过接收到的电子邮箱中的激活信息激活账号,用户注册完成,流程结束。

1.1.1.1.5.2 扩展事件流

用户注册并激活成功后,第一次登录平台时,提示用户完善信息;

1.1.1.1.5.3 异常事件流

若用户未收到激活邮件,可在登录界面录入电子邮件及密码后,再次发送邮件。

每次发送的激活邮件,仅在发送邮件后起24小时后需重新发送激活邮件。

1.1.1.1.6 输出

用户注册成功

1.1.1.1.7 后置条件

该模块为用户登录前的前置模块

注意:用户的需求不能直接作为开发和测试的依据。针对用户的需求,产品经理需要进行需求分析(技术可行性、市场可行性、成本投入和收益占比等)后才可转变成软件需求。

2.开发模型

规范的流程是在时代的演变下逐渐成型,并不是一开始就是规范的流程。

步骤总结映射软件流程
为什么要建房子?商品房还是普通住宅?建造100层技术上是否可行?明确合理的建房目标需求分析
什么时候开发建房子?计划竣工时间?多久可以交房?计划好时间计划
建房前明确流程:先打地基,做基础框架,砌墙、粉刷、水电工程…设计好具体的建房流程设计
按照前面的流程和时间实施建房中…施工中编码
房屋建筑完成,开发商验收成果、买家验收房子品质(房子是否牢固,是否漏水及其他偷工减料的地方,是否按照规定来建造的)检查房屋建造结果测试
检查结束开始逐步入住,使用中出现了各种情况如房屋漏水、墙面掉皮、下水道堵塞等问题,一边使用一边找物业修理使用并及时维护运行维护

开发:设计开发文档(用什么技术、用什么框架等等)

测试:明确需求,设计测试用例、测试计划(明确本次测试设计用到的工具、设计到的测试类型…)

软件开发生命周期:

需求分析-计划-设计-编码-测试-运行维护

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

2.3常见开发模型

软件开发流程(软件的生命周期)

2.3.1 瀑布模型

同软件的生命周期基础流程

特点:

每个流程只能执行一次,线程的开发流程

瀑布模型的一个最大缺陷在于,可以运行的产品很迟才能被看到。(时间周期长)


使用瀑布模型的例子:

2024年 2026年

直播软件 上线

                  一年两年时间。。。             直播板块直接不火了            没有收益哦

瀑布模型优缺点总结:

优点/特点缺点
1.强调开发的阶段性
2.线性结构,每个阶段只执行一次
3.是其他模型的基础框架
1.测试后置: 前面各阶段遗留的风险推迟到测试阶段才被发现,导致项目大面积返工,失去了及早修复的机会
必须留有足够的时间给测试活动,否则导致测试不充分,将缺陷直接暴露给用户(产品质量差)
2.周期太长,产品很迟才能被看到和使用,可能会导致需求/功能过时

瀑布模型的适用场景:需求固定的小项目

企业中存在许多规模庞大、复杂度高、风险大的项目,这些需要那种模型

2.3.2 螺旋模型 适合规模庞大、复杂度高、风险大的项目

螺旋模型中各个阶段都引入了风险分析+原型

螺旋模型中各个阶段都引入了风险分析+原型

需要引进风险分析人员

优点缺点
1.强调严格的全过程风险管理
2.强调个开发阶段的质量。
3.增加风险分析和原型
1.项目中可能存在的风险性与风险管理人员的技能水平有直接关系
2.需求人员、资金、时间的增加和投入,可能会导致项目的成本太高

2.3.3增量模型、迭代模型

把需求分成需求1,需求2,需求3… 拆分成增量1,增量2,增量3…

将大需求拆分成小需求,每个小需求独立

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值