【测试】提交BUG的标准规范 Bertha 。 2022-06-04 03:07 358阅读 0赞 我们在软件测试过程中,发现了BUG后,如何提交一个高质量的BUG, 其实我们可以总结一下规范的,文章主要从以下几方面讨论: ### Bug有效性 ### 提交的Bug必须是有效的,就要求我们在提交Bug时,确认: 1、交付过程中测试者需按照设定好的模块,对Bug进行归类提交; 2、Bug的类型默认为UI问题、功能问题、崩溃问题,提交Bug时不能弄错; 3、需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性; 4、避免提交设计如此、操作错误、重复的、已知的Bug; 5、尽量少花时间在边界值、页面显示问题上,多提业务逻辑功能、交互测试方面的问题。 ### Bug标题 ### Bug标题要求简明扼要的阐述问题本质,使查看人员能快速了解Bug内容。需要写明在哪个页面执行什么操作出现什么现象。 可以看一下下面的例子: 正确示例: 【在我的设置页面不填写任何内容点击保存后,客户端崩溃】 错误示例: 【设置页面保存问题(过于概括)】 【设置页面崩溃(缺少导致现象的关键步骤)】 【客户端崩溃(只有现象而无法定位问题位置)】 特别提醒: 1.标题中标点符号不能超过1个 2.标题中不能含有测试流程步骤和模块信息 ### 测试设备 ### 提交Bug要表明测试使用的设备、设备操作系统版本、测试环境、网络类型等等。 ### 前提条件 ### 明确指出所提交的Bug是在怎么样的情况下出现的,当所发现Bug前提条件为空时,需要填【无】。 正确示例: 【1.WIFI网络正常 2.账户登录正常】 【1.已登录 2.关注有发布视频的用户 3.开启4G数据 4.WiFi关闭且不可用】 ### 测试步骤 ### 要简明清晰分步骤描述如何复现Bug问题,步骤用序号编排。 要按照自己的操作的实际步骤写清楚每一步是怎么操作的,最后操作到哪个页面或者点击哪个按键。 如在特定情况下发生的问题,还需明确提供以下信息: 1.准确写出连续点击次数,点击时长与上下滑动屏幕时长。 2.对于特定数据产生的问题,提供具体数据。 3.精准描述bug产生的路径后,再描述现象。 正确示例: 【1.打开客户端进行首页->点击“我的”页面->点击用户头像进入个人资料页】 【2.个人资料页点击头像选择拍照->拍照后点击保存头像】 【3.从个人资料页返回 “我的”页面,查看头像是否更新】 错误示例: 【左上角菜单栏->登录->新用户注册->输入手机号->输入昵称->输入密码->点击“获取验证码”】 特别提醒:测试步骤中的点击要用【->】符号连接 ### 期望结果 ### 按照测试步骤应当得到的正确结果,按照产品需求的期望清晰准确的填写预期结果。而且结果必须是肯定无疑义,可判定性的结果。 正确示例:我们以一个取消点赞功能为例 【同步显示已经取消点赞】 特别提醒:期望结果不要包含测试步骤,要是简单的一个结果 ### 实际结果 ### 按照测试步骤实际出现的错误结果,避免使用“不正常”,“有误”等模糊词汇,需要直接描述实际现象。 正确示例:还是以上一个点赞功能为例,出现bug后我就可以写 【还显示已点赞】 特别提醒:期望结果和实际结果要相互对应 ### 复现步骤描述及概率 ### 描述复现步骤中的页面切换为避免出现描述不清晰或者有歧义,需用“->”符号连接 正确示例: 【首页->我的->我的订单->未支付,点击一个未支付订单,进入订单详情页】 关于复现概率一定要在多次测试的基础之上填写,若必定复现则填写100%,若偶现,请执行多次后统计概率填写。 ### 截图和附件 ### UI类型:Bug需要上传截图,并且增加相应的红框标识; 功能类型:问题必须上传视频文件,上传格式MP4为主; 崩溃类型:bug则需要上传视频和log并且log不得超过10分钟。 特别提醒: 1.附件命名需与标题相呼应 2.log日志抓取不能超过10分钟 3.文件名称不能出现怪异冗长 这些就是我们提交Bug时注意的提交标准,当然不同公司,不同项目可能标准有点不同,但大体这些考虑到了,基本算是一个高质量的bug了。
还没有评论,来说两句吧...