测试开发学习之旅--三

敏捷中的测试:
1.软件测试v模型
在这里插入图片描述
优点:左边开发的每一个阶段和右边的每一个阶段一一对应,是右边测试,每一个阶段的依据

缺点:测试介入晚,前期的错误和风险后期才发现,失去纠正的机会.

2.软件测试w模型:
优点:测试和开发在两个独立的v模型里边,测试介入比较早,在项目初期就介入,前期的风险可以及时被发现;

缺点:每一个阶段仍然是一个串行的过程,不能适应需求变化的项目,所以无法用到敏捷开发

3.软件测试的生命周期:
需求分析------测试计划-----测试设计/开发------测试执行----测试报告
1.需求分析:
()1.分析需求
(2).细化需求
(3).验证需求的正确性合理性

2.测试计划
(1)规划测试人员
(2)规划时间
(3)测试范围
(4)测试的目的

3.测试设计开发:
分析需求,从细化的的需求中提炼测试点,设计测试用例

4.执行测试用例,记录bug

5.测试报告
(1)测试的范围
(2)有多少测试用例
(3)执行了多少
(4)余留的多少测试用例
(5)发现了多少bug
(6)修改了多少bug
(7)遗留的bug以及解决方案

4.如何描述一个bug
(1)版本号(本机的代码的版本号)
(2)测试环境(平台)
不同的浏览器对同一个系统的同一个页面解析是不一样的
windows ios 浏览器版本号
App Android ios
(3)测试步骤和测试数据
(4)实际的结果
(5)预期的结果
(6)附件,错误的截图,错误日志等

描述某某登录页面的bug:
比如:输入邮箱输入了19个字符,输入正确的密码和手机号,点击勾选同意,点击立即注册,注册成功
提出bug:
标题:注册邮箱,邮箱地址输入19个字符,注册成功
测试版本:versionx12
测试环境:Windows10 Chrome + 浏览器的版本号
测试步骤和数据:
1.进入邮箱登录页面
2.邮箱地址输入19个字符:dhajdhajhdjada

3.输入符合要求的正确密码
4.输入符合要求的正确手机号
5.勾选同意条款
6.点击立即注册
实际结果:注册成功
预期结果:注册失败
3.bug级别的定义
1.崩溃
系统运行阻断,已经严重的影响了开发人员和测试人员的工作,需要立马修复;
线上出现崩溃级别的bug:回退到一个稳定的版本
2.严重:
系统还可以运行,但是已经不稳定了,如果在运行下去没可能会产生严重的错误;密码明文显示
3.一般级别的bug:
系统可以稳定的运行,但是一些次要功能没有实现,可能会影响用户的体验
4.次要(建议性)
没有严格体现在需求里边的
影响用户的视觉体验.界面的文字提示内容,展示,图片的排版,要不要改和产品经理商量;
4.bug的生命周期
Bug的生命周期
问题:测试人员提了一个bug,开发人员已经修改了,但是测试人员测试的时候,发现这个bug依然有效.
1.开发人员没修改好,开发人员没有把代码更新到测试环境.
2,测试人员忘记拉取最新的代码到测试环境进行发布
3.程序的运行有一定的随机性
4.程序所运行的环境不同

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 7
    评论
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值