发动态

没有新消息

更多内容

曾同学 湖南/大连大学
#技术牛人储备库#一、BUG本地“再现” (1)确定问题发生的环境,比如哪个浏览器的哪个版本发生的此现象。 (2)使用导致问题出现的数据。 (3)按照之前的操作步骤进行操作,使BUG再次出现 分析本地复现BUG需要的环境、数据、步骤,找出根本原因 (1)查看其他浏览器在相同数据,同样操作步骤的情况下是否仍旧会使该BUG出现。明确是否是特定浏览器,还是在其他浏览器都会出现。 (2)是否是数据的特殊性造成的问题?是单个数据?还是相似的一类数据?还是所有的数据? (3)剖析操作步骤,尽量找到最短路径。 a.分解操作步骤 b.分析每一步骤的前提条件、期望结果。找到导致BUG产生的可能的必要操作步骤。如果期望结果与实际结果不同,猜测造成的原因,这时,可以通过抓包等一些工具来帮助分析其中的原因。 c.思考产生问题的可能原因和相关的操作步骤,明确一下产生的步骤,进行尝试,验证自己的想法是否正确。 3.如何在其他环境复现BUG 为了进一步明确问题的普遍性,确定自己环境的没有特殊的设置,需要在其他电脑上按照总结出来的产生bug的三要素,来重现BUG。对于通过上述步骤没有出现BUG的机器,要进一步追踪原因,查看为什么没有发生问题。 二、版本:6.0.8 系统HydrogenOS 系统版本 11.0.7.10.KB05 三、bug情况:网络良好的情况下,有些页面加载不出

772阅读

0赞

评论

0 条评论

北京/天津财经大学
这是什么神仙炫技评论!职Q校园助教官pick你!我们收到了你的建议,感谢你的火眼金睛和机智的小脑袋瓜~我们会及时反馈给技术人员进行优化。希望我们一路同行,感谢有你。
21-03-23
赞0
回复

推荐阅读

你认为是Bug,而开发不认同时怎么办 大家出去面试的时候,应该是经常会被问到就是如果开发人员认为你提交的 bug 不是一个 bug,这时候你怎么办? 其实这个问题面试官想要考察的就是大家对于 Bug 有没有自己的判断,还有就是在工作当中的一些软实力,比如说处理问题的思路。 那遇到这个问题可以用什么思路去回答呢? 回答思路 首先可以先来分析一下什么样的 Bug 会让开发认为不是 bug 测试人员描述不清晰 工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂,开发人员按照步骤复现 Bug 不知所云,搞错了问题所在。 看我们怎么判定我们发现的问题是一个 Bug 呢?其实是有一定的判断标准的: 1). 软件未达到客户需求文档的功能和性能 2). 软件出现客户需求不能容忍的错误 3). 软件的使用未能符合客户的习惯和工作环境 4). 软件超出需求文档的范围 只要是符合了这几个标准其中的一条,就可以断定它是一个 bug。 描述不清晰的解决方法: 修改 Bug 操作步骤:清晰描述、无歧义、无冗余步骤,要达到即使给一个不懂的人去重现这个 Bug,也能按照你的操作步骤复现。 有图有真相:带有清晰说明的截图比一大推描述来得直观,易懂。注意对问题区域以强调色标识,并配以文字说明 难以复现的 Bug 不是所有的问题都能用同样的操作步骤来复现的,有的 Bug 概率出现甚至偶现,或者是只在测试环境里出现。 难以复现的解决办法: 针对难以复现的 Bug,需要保存截图或者记录 log 保留证据 对于只在测试环境下才会出现的,找研发在测试环境进行确认 总之,这类 Bug 要慎重对待,重点要规避风险。 有争议的 Bug 有争议的 Bug 多发生于建议类型的 Bug,比如易用性、美观性等类型的 Bug。 有争议的解决办法: 开会讨论:这种问题是否要修改需要根据公司的项目类型进行讨论。在时间允许的情况下,可以在项目测试接近收尾时开一个 bug 清除会议,对于剩余 bug 是否修复做明确处理 功能性 Bug 这类 Bug 就是与需求不符、或者与原型设计不符。因为有时候开发对需求没有深入了解可能会忽略或者搞错个别功能。 功能性问题解决办法: 拿证据:提 Bug 时,把需求、设计截图带上,可以省去了大多争议 开会讨论:如果开发确实觉得设计有问题,需要重新进行讨论设计 总结 所以如果大家出去面试被问到这个问题,大家最重要的是展现自己解决问题的思路。 测试人员描述不清晰:提高自己的业务水平 难以复现的 Bug:留好截图和 log,保留证据,做好记录 有争议的 Bug:建议类问题开会讨论 功能性 Bug:需求理解不一致时,提 Bug 时提供证据,需求,设计方案,省去争议

316阅读
2赞
0评论

软件测试 | 软件缺陷等级划分 软件缺陷常常又被称为Bug。所谓软件缺陷就是指计算机软件或者程序中存在的某种破坏正常运行能力的问题、错误或者隐藏的功能缺陷。 Bug的存在会导致软件产品在某种程度上不能满足用户的需要。 (1)从产品内部看,是指软件产品开发或维护过程中存在的错误、毛病等问题。 (2)从产品外部看,是指系统所需要实现的某种功能的失效或违背。 1.缺陷种类 缺陷可以分为不同的种类 (1)遗漏:指规定或预期的需求未体现在产品中。 (2)错误:指需求是明确的,在实现阶段未将需求的功能正确实现。 (3)冗余:只需求说明文档中未涉及的需求被实现了 (4)不满意:除了上面3种情况外,用户对产品的实现不满意也称为缺陷。 2.缺陷的等级划分 不同的企业对软件缺陷等级的划分大同小异,大致可分为5个等级。 (1)知名:指造成系统或应用程序死机、崩溃、非法退出等问题,会导致用户数据丢失或被破坏,功能设计与需求严重不符。 (2)严重:指功能和特性没有实现,导致模块功能失效或异常退出,还有程序接口错误或者数据流错误等问题。 (3)一般:指主要功能丧失,提示信息不太正确,用户界面设计太差以及删除未提示等问题。 (4)提示:指对功能几乎没有影响,产品及属性仍可使用的问题。 (5)建议:测试人员提出的建议、质疑等问题。 3.缺陷报告 缺陷报告是测试执行完成后最重要的输出成果之一,一份好的缺陷报告也是提高软件质量的重要保障。 不同的公司因为缺陷管理的流程不一样,可能有不同的缺陷报告模板。但是一个完整的缺陷报告通常应该包含以下内容。 (1)编号:用数字进行唯一标识缺陷,通常是,在缺陷管理工具中新建Bug时会自动生成。 (2)状态:通常描述当前缺陷的状态,如修复、延期等。 (3)标题:通常用一句比较简洁的话来概括Bug,通过描述可以初步推测Bug形成的原因,帮助开发人员提高处理Bug的效率。 (4)类型:主要为了进一步描述缺陷产生的原因,如功能错误、接口错误、数据库错误等。 (5)所属版本:描述当前Bug所在的测试版本,便于后期回归测试时注意测试版本。 (6)所属模块:描述Bug所在的业务模块,便于后期统计缺陷的分布情况,利于回归测试的方法及测试策略的改进。 (7)严重级别:指Bug的严重程度,通常不同的Bug严重程序给软件带来的后果、风险都不一样,开发人员处理的优先级也不同。 (8)处理优先级:开发人员根据Bug的严重级别来确定处理的优先级。 (9)发现人:Bug的提交者 (10)发现日期:一般在提交Bug时,由Bug管理工具自动生成,便于后续进行缺陷的跟踪。 (11)复现概率:指Bug重现的概率,便于开发人员定位Bug并分析。一般包括必现、偶现等。 (12)指定处理人员:根据Bug的类型指定处理人,通常指定位的开发人员,如果是需求错误则需要指定产品经理或需求分析人员,便于后期跟踪Bug. (13)详细描述:详细描述缺陷引发的原因以及复现步骤,需要包含测试环境、前提条件、测试数据、复现步骤、预期结果、实际结果等内容。 (14)附件:为了详细描述Bug,我们可以在描述Bug时添加一些附件信息,如截图、录屏、错误的日志信息等。

264阅读
3赞
0评论

1、负责电视机软件的测试; 2、提交测试的结果; 3、分析测试过程中BUG,分析BUG出现的原因。工资偏低,工作比较简单

679阅读
0赞
0评论

1、负责电视机软件的测试; 2、提交测试的结果; 3、分析测试过程中BUG,分析BUG出现的原因。工资偏低,工作简单,没有技术含量

633阅读
0赞
0评论

#技术牛人储备库#【七大岗位精选练习题——技术】 找bug和处理bug是每个技术人员必须具备的基本工作,为了更好地锻炼大家的能力,本周我们为大家精选了一道技术练习题,一起来看看吧。 【精选练习题】 本周技术作业:智联App职Q模块功能公测,测试要求如下: 1、详细描述bug复现路径和方式; 2、标明app版本、系统、系统版本; 3、收集界面截图,甚至是bug复现的视频。 【活动激励制度】 1、认真完成官方作业,可得5个积分(在3月16日-3月23日之间参与活动可得); 2、在“技术牛人储备库”话题下发布的作业,被官方打上“职Q优选”的标识后,将额外收获20个积分(在3月16日-3月23日之间参与活动可得); 请大家认真思考,在本话题下留下你的答案,跟大家一起分享吧~

831阅读
0赞
0评论

#你好哇#找bug,找bug,找bug

475阅读
1赞
0评论