目的:掌握测试相关基础概念
掌握常见的开发模型,测试模型
什么是需求
什么是bug
什么是测试用例
开发模型和测试模型
一.什么是需求
例如:想干什么,不想干什么了
想要做什么事情
1.什么是需求
用户需求:简单了解为甲方提出的需求
软件需求:又叫功能需求,该需求描述开发人员必须实现的软件功能
问题:
1.软件需求谁写的?PM产品经理
2.开发一个产品,或者测试一个产品,需要拿着软件需求进行测试/开发,还是用户需求?软件需求
总体来说:用户需求就是一句话 软件需求是一个文档(详细描述了用户需求如何如何实现)
日常工作中,通常用的是软件需求进行开发和测试
2.为什么有需求
有需求才有目标
3.测试人员眼里的需求
业务需求 -->注册从而达到登录
功能需求-->软件用户注册/登录/账号后台管理
例:用户登录测试需求点-->登录功能/登录的安全性/登录的兼容性/登陆的性能......
用户登录测试用例-->功能测试用例/安全测试用例/兼容性测试用例/性能测试用例......
一个简单的测试用例
账号 可以划分为
功能 | 账号正确,登陆成功 密码正确,登录成功... |
兼容 | |
安全 | |
性能 |
密码
登录按钮
4.如何深入了解需求
1.参加需求评审会议
2.查阅文档
3.沟通
需求评审会议
为什么做这样一个需求
满足用户的需求(收益达到什么标准,例如订单量达到什么标准,如果没达到就是产出小于投入)
软件要做成什么样......
查阅文档
关于评审的一些小问题,今天评审了,测试人员今天就要测试吗,开发人员今天就要开发吗
看优先级
今天评审的项目,过了三天才有时间做这个项目,忘记了软件需求的细节
查阅(需求文档,技术文档{开发写的})
沟通
沟通的能力:找产品了解软件功能,找开发了解软件的实现
二.测试用例
1.什么是测试用例
测试用例是一组集合,包含测试环境,测试数据,预期结果, 操作步骤...
测试环境:leetcode提供给了我们同学一个测试环境(Chrome浏览器)
测试数据:自己去输入测试数据,80%
预期结果:通过率100%
操作步骤:写代码,提交
序号:1,2,3....
测试用例的标题:全部通过,此时展示一个动画效果
2.为什么要有测试用例
1.测试用例提高测试人员的工作效率/降低测试人员的工作重复性问题
2.测试用例是建立自动化测试用例的基础
自动化就是把测试人员的双手解放,让代码去代替人员执行测试
3.练习
手机打电话
打电话之前
功能相关的测试点:手机号码正确性(测试环境 测试数据 预期结果) 黑名单电话 不同地区的电话号码
性能相关的测试点:拨通速度 信号
打电话过程中
打电话挂机后
三.BUG
当且仅当规格说明是存在的并且正确(软件需求,规格说明书),程序与规格说明之间的不匹配(预期结果 != 执行结果)才是错误
概念:当程序没有实现其用户合理的预期功能要求,称为软件错误
总结:当存在正确的软件需求时,程序的预期结果和实际结果不相等,称为BUG
四.软件生命周期
1.生命周期
人的生命周期是什么?出生-死亡
软件的生命周期?
需求分析 - 计划 - 设计 - 编码 - 测试 - 运行维护
需求分析:实现手机主题根据手机壳颜色的改变而改变、
分析需求是否合理,需求是否完整
计划:谁开发,谁测试,开发多久,测试多久
编码:写代码 coding
测试:测试人员测试 写测试报告
测试报告 |
项目名称:登录重构 开发:xxx 测试:xxx 产品经理:xxx BUG 测试周期:3天(4.4-4.6) 开发周期:9天(x.x-x,x) 风险:无 |
运行维护:如果有线上问题,此时测试人员需要协助开发定位问题,解决问题,重新上线
停服更新
五.开发模型
1.瀑布模型
Start -> 需求分析 - > 计划 -> 设计 -> 编码 - 测试 -> End
需求文档 合理的 完整的
计划 开始 结束
设计 技术文档(涉及哪些接口,库表,mq,定时任务)
UI视觉稿
编码 写代码
测试 执行测试用例,提交BUG,验收
特点:线性的
优点:每个阶段做什么,产出什么非常清晰
缺点:风险往往到了最后面才显现,因而失去纠正的机会
适用的项目:小型项目适用于这种模型
2.螺旋模型
四个象限
第一象限:制定计划 决定目标 方案和限制
第二象限:风险分析 评价方案 识别风险 消除风险
第三象限:实施工程 开发,验证产品
第四象限:客户评估
需求计划-风险分析-软件需求(需求文档)-需求确认 - 开发计划 - 风险分析 - 设计 - 确定计划 - 组装和测试 - 风险分析 - 详细设计
反复的分析
优点:每个阶段都会进行风险分析,避免一些线上问题发生
缺点:风险分析可能会出现问题,分析错,人力财力物力付出比较多,软件生命周期长
适用什么样的项目:适用于比较大的项目,其次风险比较多