网站推广模式,网络seo外包,找附近工作招聘信息,网站怎样查是哪家做的目录
一、软件测试的生命周期(5个步骤)
①需求分析(两个角度)
用户角度#xff1a;
开发人员的角度#xff1a;
②测试计划
③测试设计、测试开发
④执行测试
⑤测试评估
二、软件测试贯穿项目的整个生命周期的体现
需求分析阶段
计划阶段
设计阶段
编码阶段
…目录
一、软件测试的生命周期(5个步骤)
①需求分析(两个角度)
用户角度
开发人员的角度
②测试计划
③测试设计、测试开发
④执行测试
⑤测试评估
二、软件测试贯穿项目的整个生命周期的体现
需求分析阶段
计划阶段
设计阶段
编码阶段
测试阶段
运行维护阶段
三、关于bug
如何描述一个bug(5个内容)
标题
发现bug的版本
发现bug的环境
发现bug的具体步骤
期望结果实际结果
bug的级别是什么 NO.1崩溃(非常严重并且比较少见) NO.2严重(主要的功能与预期存在严重不符) NO.3一般(很常见) NO.4次要(很常见)
bug的生命周期
发现bug
收到bug
修复bug
bug回归验证
如果测试人员认为是bug开发人员不认为是Bug怎么处理
一、反思自己
二、提bug一定要有理有据
三、合理友好地沟通
四、提出问题最好可以提出解决方法(优秀)
五、提出评审(一定是最后的最后才作出这样的决定) 一、软件测试的生命周期(5个步骤)
①需求分析(两个角度)
需求分析需要站在两个角度进行分析
用户角度
检查需求的逻辑是否正确是否符合用户的需求和习惯等 开发人员的角度
思考需求是否可以实现/实现的难度大小。 ②测试计划 针对一个项目具体的测试计划例如测试的工时、人力的安排等等 ③测试设计、测试开发 测试设计阶段设计测试用例。 测试用例就是测试人员向待测试的软件提供的一组测试数据包括以下的内容 测试环境、 测试数据、 测试步骤、 预期结果 每一个步骤是干什么的已经在这一篇文章当中提到了。 【测试开发篇2】软件测试常用概念_革凡成圣211的博客-CSDN博客https://blog.csdn.net/weixin_56738054/article/details/129493584?spm1001.2014.3001.5502 在这两个阶段经验丰富的白盒测试人员就可以开始进行单元测试了关于什么是白盒测试、什么是黑盒测试已经在这一篇文章当中提到了 ④执行测试
参考测试用例来执行测试。计划好了测试的计划那么在这一个步骤就需要来具体地执行测试了。 ⑤测试评估
测试人员需要记录测试、做好缺陷管理例如记录bug、评估风险 二、软件测试贯穿项目的整个生命周期的体现 之前我们提到了软件测试是贯穿整个软件的生命周期的。那么下面我们来回顾一下软件的生命周期是什么。 需求阶段产品经历根据用户需求转化为软件需求 计划阶段进行软件开发的计划包括项目的开发工时、人力等产出计划文档 设计阶段设计具体的开发步骤产出设计文档 编码阶段开发人员根据需求文档和设计文档来进行软件开发 测试阶段测试人员对于软件进行测试 运行维护阶段发现项目当中旧的问题、对于当前项目的维护、以及预防可能发生的问题。 下面我们具体来聊一下在每一个阶段软件测试人员需要做什么事情。 需求分析阶段 在这个阶段测试人员也需要了解用户的需求、软件的需求等等。分析需求是否合理站在开发人员的角度思考技术如何实现针对技术难度来合理调整需求。 计划阶段 在测试人员了解到具体的需求之后就需要进入到计划阶段了。根据需求来编写测试计划、测试方案。 设计阶段
根据项目的设计细节搭建测试框架并且根据项目的计划编写一部分的测试用例。 编码阶段 测试人员一般不需要编码的。 在这个阶段白盒测试人员就可以参与进来进行测试了。同时在这个阶段也需要完善、细化测试用例以及调整测试计划和方案 测试阶段
测试人员根据测试用例来进行测试在执行的过程当中记录并且管理缺陷。
并且还需要在这一个阶段进行
总结 运行维护阶段 在这一个阶段 ①测试人员可以参与用户使用软件的培训 ②收集运行时候项目的问题并且反馈给相关的负责人。 三、关于bug
关于什么是bug,也已经在前面的文章当中提到了
当软件需求正确的时候软件的实际运行效果和软件需求不一致的时候那么这就是bug。 如何描述一个bug(5个内容)
标题
对于一个bug的简单描述一般是bug的现象是什么。 发现bug的版本
对于用户使用的版本我们称之为线上包或者正式包。
那么测试使用的版本就是测试包。因此需要描述好是哪一个测试的版本发现的bug。 发现bug的环境
例如是在什么操作系统下面发现的bug是移动端还是微信端还是pc端等等。 发现bug的具体步骤
指的是测试人员具体操作了哪些步骤才发现了bug。
例如是 用户登录之后退出到首页的情况发现了bug 还是打开浏览器进入首页的情况发现了bug 期望结果实际结果
例如期望的结果是什么但是实际的结果又是什么以及具体的描述。
bug类型前端问题,bug等级...
(最好配有截图) bug的级别是什么 关于bug的级别不同的公司有不同的规定在定义级别之前首先需要查看公司的规范。一般分为以下几个级别 NO.1崩溃(非常严重并且比较少见) 这种bug可以说是会直接导致系统崩溃的。例如 死循环、死机、数据库内容丢失等等在测试的环节非常少遇见 NO.2严重(主要的功能与预期存在严重不符) 例如在一个博客系统当中用户点击了保存草稿但是还是没办法保存成功一样。 或者用户点击了登录账号密码都输入正确了但是还是没办法正常登录。 NO.3一般(很常见) 功能没有完全实现但是不影响使用。 主要功能存在缺陷但是不影响系统的稳定性。 NO.4次要(很常见) 一些建议优化的措施。(例如调整前端页面的字段大小等等) bug的生命周期
发现bug
测试人员发现了新的Bug同时测试人员要新建一个bug这个bug的状态就是new。 收到bug 开发人员收到了bug查看测试人员提出的bug是否是bug。如果是bug就把这个bug的状态设置为open。 如果开发人员认为这不是一个bug那么开发人员就把这个bug修改为rejected(拒绝)然后就直接进入closed状态。 修复bug
开发人员认定了bug之后就需要采取修复的工作。
但是就算是修复也有两种措施 delay现在暂时不需要修复于是采取的措施是延迟修复。 fixed立刻进行bug修复。 bug回归验证
把这一个bug的状态修改为reopen重新交给开发人员。 画个图总结一下bug的生命周期流程图(圆圈为bug的状态) 如果测试人员认为是bug开发人员不认为是Bug怎么处理
一、反思自己
具备批判性的思维先考虑一下自己是不是对于bug描述地不清楚。
这个bug是不是无效的bug 二、提bug一定要有理有据 不单止对于bug的描述还需要有明确的依据包括是在什么样的环境下面发现的bug测试的版本、运行的截图等等 并且要严格规定bug的等级不可以过低或者过高。 三、合理友好地沟通 如果开发人员并不太认可可以站在用户的角度进行沟通。如果你是用户那么可以接收这样处理嘛 四、提出问题最好可以提出解决方法(优秀)
如果bug太多的话最好可以提出解决方案帮助开发人员快速进行修正。 五、提出评审(一定是最后的最后才作出这样的决定)
邀请产品代表、开发代表、测试代表一起对这个bug进行评估。
包括以下的内容 (1)如何解决bug (2)如何预防类似的bug。
