高端设计网站建设,torrent种子搜索引擎,做自媒体哪家网站好,做不好的网站违法吗软件测试基础篇 一 . 如何合理的创建一个 Bug二 . Bug 等级2.1 崩溃2.2 严重2.3 一般2.4 次要 三 . Bug 的生命周期四 . 跟开发产生争执应该怎么解决 Hello , 大家好 , 又给大家带来新的专栏喽 ~ 这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足… 软件测试基础篇 一 . 如何合理的创建一个 Bug二 . Bug 等级2.1 崩溃2.2 严重2.3 一般2.4 次要 三 . Bug 的生命周期四 . 跟开发产生争执应该怎么解决 Hello , 大家好 , 又给大家带来新的专栏喽 ~ 这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 . 那也欢迎大家订阅此专栏 : https://blog.csdn.net/m0_53117341/category_12427509.html 希望大家都能够拿到好的 Offer 本篇文章重点 :
如何合理的认识 BugBug 级别Bug 的生命周期跟开发产生冲突怎么办
一 . 如何合理的创建一个 Bug
创建 Bug 的目标就是为了能够让其他人可以尝试复现 创建 Bug 的要素 :
问题的版本发现问题的环境发现问题的步骤预期结果实际结果Bug 等级Bug 类型等等
假如存在这样的一个场景 : 下拉框选项有 100 个 , 用户找到想要的标签非常困难 , 针对这样的 Bug , 我们怎么创建
问题的版本 : 谷歌浏览器 94.0.4606.61正式版本64 位即以后发现问题的环境 : Windows10家庭版发现问题的步骤 : 省略…预期结果 : 用户可以通过输入框快速定位到想要的标签实际结果 : 没有可用的输入框 , 用户只能一个一个查找 , 对于用户来说体验感不好Bug 等级 : 优化建议Bug 类型 : 需求问题
二 . Bug 等级
一般分为四个等级崩溃、严重、一般、次要 举个例子 次要 男朋友多看了一眼别的女孩子 一般 男朋友加了别的女孩子 严重 男朋友私下跟别的女孩子吃饭 崩溃 男朋友脚踏两只船
2.1 崩溃
阻碍开发或测试工作的问题造成系统崩溃、死机、死循环导致数据库数据丢失与数据库连接错误主要功能丧失基本模块缺失等问题。如代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等该问题在测试中较少出现一旦出现应立即中止当前版本测试
2.2 严重
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符模块无法启动或调用程序重启、自动退出关联程序间调用冲突安全问题、稳定性等。如软件中数据保存后数据库中显示错误用户所要求的功能缺失程序接口错误数值计算统计错误等该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试
2.3 一般
功能没有完全实现但是不影响使用功能菜单存在缺陷但不会影响系统稳定性。如操作时间长、查询时间长、格式错误、边界条件错误删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多
2.4 次要
界面、性能缺陷建议类问题不影响操作功能的执行可以优化性能的方案等。如错别字、界面格式不规范页面显示重叠、不该显示的要隐藏描述不清楚提示语丢失文字排列不整齐光标位置不正确用户体验感受不好可以优化性能的方案等此类问题在测试初期较多优先程度较低在测试后期出现较少应及时处理 那么为什么要提 Bug 等级呢 ?
Bug 的等级跟优先级有关 : 崩溃以及严重的 Bug 一定要优先解决出现线上问题需要进行问题定级 : 定级会涉及到对应的惩罚范围 线上问题复盘会议 (批斗大会) 能避免就要避免 !!! 三 . Bug 的生命周期 ● New : 新发现的Bug未经评审决定是否指派给开发人员进行修改。 ● Open : 确认是Bug并且认为需要进行修改指派给相应的开发人员。 ● Rejected : 如果认为不是Bug则拒绝修改。 ● Fixed : 开发人员进行修改后标识成修改状态有待测试人员的回归测试验证。 ● Delay : 如果认为暂时不需要修改或暂时不能修改则延后修改。 ● Closed : 修改状态的Bug经测试人员的回归测斌验证通过则关闭Bug。 ● Reopen : 如果经验证Bug仍然存在则需要重新打开Bug开发人员重新修改。 无效的bugopen-closed open-rejected-closed 举个栗子 , 来帮助大家记住这七种状态 那么通过这个例子 , 我们要得到 Bug 真正的生命周期是怎样的
四 . 跟开发产生争执应该怎么解决
先检查自身 , 是否 Bug 描述不清楚 , 是否确实提出了一个错误的 Bug站在用户的角度去考虑问题 , 可以反问 : 如果你是用户 , 你可以接受这种实现吗 ?Bug 定级要有理有据 Bug 等级其实也是跟程序员水平有关的 , Bug 等级越严重 , 说明程序员在实现的产品问题比较严重 , 就有可能上升到态度问题、水平问题 不光要提出 Bug , 最好也要能提出解决方案 要注意 : 工作中不能喧宾夺主 , 你不能命令人家怎样做怎样处理 , 只需要给开发人员提建议即可 组织 Bug 评审 ( 终极大招 : 工作中并不常用 , 实在没招了才能去召开 ) 邀请代表参加 : 产品经理代表、开发人员代表、测试人员代表等Bug 评审会议里要解决以下问题 : 如何修改 Bug如何避免类似的问题再发生 一般来说不会造成不愉快秘诀就是对事不对人
