敏捷中的测试:
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.程序所运行的环境不同
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91280 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！