彩票网站开发技术,邢台市教育局官网,dedecms 做微网站,做外贸需要关注国外哪些网站Bug剖析
• 所有的Bug报告有以下的基本要求#xff1a; • 标题。要简略。 • 指派。谁来处理这个问题。 • 重现步骤。问题再次出现的相关步骤。 • 优先级别。问题的紧迫性与重要性。 • 严重程度。问题所产生的后果。 • 解决方案。怎么解决问题。 其他很多方面对修复问题…Bug剖析
• 所有的Bug报告有以下的基本要求 • 标题。要简略。 • 指派。谁来处理这个问题。 • 重现步骤。问题再次出现的相关步骤。 • 优先级别。问题的紧迫性与重要性。 • 严重程度。问题所产生的后果。 • 解决方案。怎么解决问题。 其他很多方面对修复问题及明白其深层次原因也很有帮助但以上基本准则简练得多。下面我们来对每条准则逐一展开讨论消除这些疑惑。
标题及指派
标题应该简明扼要一句话就详尽说明问题的唯一性使Bug报告的检索及标识变得简单。“点击取消按钮屏幕就清空了”是个差劲的标题。“关闭编辑框清空屏幕”就是个很好的标题。后者简短得多而且对问题的出处及发生时间提供了具体的信息。 当你要创建一份新的Bug报告时你必须指定具体人选来解决其中问题。但是即使你这个团队的每个人都很了解你也不应该将一个Bug指定给其中某一位除非你是开发团队的一员。相反你应该将此任务交给这整个团队。通常的做法是在Bug报告中指定责任方或团队作为默认选择。默认的选择通常是“主导”或“会诊”团队。不会再有更好的了。要相信这些团队他们会知道问题由谁来解决。 作者注有些团队希望将所有Bug都指派给团队中的某些个人这样可保证没有Bug被遗漏。但是他们还是必须确认将Bug指派给“主导”或“会诊”团队以确保Bug未被遗漏。毕竟团队外部人员并不知道软件还有其他什么功能。 作为惯例所有Bug必须指派给能对其进行经常性检查的个人或团队。因为大多数优先团队会每天开例会我还是偏好将Bug指定给“主导”或“会诊”团队为默认选择。
重现步骤
没什么比一份Bug报告没有清晰的重现步骤更让人郁闷了。就像你的亲友对你说“你知道该怎么办”没有给你更多解释。这让我很茫然不知道怎么办。悲催了。 Bug重现步骤应是言简意赅——一言中的。同时要包含软件创建编号通常是单独列出的你的工作环境操作系统版本、所用浏览器及其他相关的细节以及一些先备条件像先注册个Xboxcom金牌账号等。 有时你不能确定Bug是怎么发生的因为它有时是间歇性的或跟某种特定的状态相关。这种情况下列出创建编号、运行环境及配置等信息接着描述下当时的情况以说明具体的Bug重现步骤无法确定。
注我们有些内部工具如Watson与Autobug它们可以自动生成Bug报告。诚然用这些工具生成Bug重现步骤有其局限性但是它们通常仍可以提供些堆栈跟踪信息、创建编号、环境及其他相关的信息且它们对隔离问题有帮助。
在简洁的Bug重现描述后你必须指出什么是你希望发生的“期望”及事实发生了什么“事实”。所有的重现步骤包括这三方面——配置、期望结果及实际结果。这样当别人在看这份Bug报告时就知道到底哪里出错了及怎么重现它。 通常一张图、一段视频顶上千句文字有很多工具可以对屏幕进行图片及视频抓取。将这些文件附到Bug报告中这些文件就是一份能妥善修复Bug的报告与含糊不清的报告之间的区别。 作者注如果一个问题可以用4个步骤讲清楚而你在Bug报告里却用了15个步骤这是让人相当恼火的。不仅仅是因为4步很简单容易理解而且这样可以使开发者及测试者快速找到Bug。重现Bug用的时间越少在确认Bug的原因上所花时间也越少可能出现Bug的步骤少了同样在确认Bug已被修复上所用的时间也越少。
优先级别
对于优先级别意义的讨论一直没完没了这种级别的范围值通常为03。说实在的你可以把时间更好地用到其他地方去。这里还是说些简单的准则以此为基础阐明优先级别。 • 优先级别一旦设定则不宜再改除非Bug本身角色变换了。如果级别1意味着“在目前的冲刺阶段或里程碑期间修复”级别2意味着“到下一个冲刺阶段或里程碑期间再修复”那么在每个冲刺结束时你必须更新Bug的优先级别这样不仅很浪费时间而且改变了Bug的“最后一次变更时间”这会丧失很多重要信息。 • 优先级别必须容易指定并区分。你不会想让你的团队花大量的时间争论每一个Bug的优先级别吧。它必须是显而易见的不管是在写Bug报告或读Bug报告的时候。 • 优先级别必须易记且易操作。人们不需要问“下一个Pri 2是什么”人们也不需要问哪种级别需要做什么。 基于以上三条准则一般普遍接受以下优先级别的定义。 Pri 0 一个需引起严重关注的致命错误。不存在变通办法是一个不可逾越的Bug 只有解决了这个问题或找到了变通办法你才能安心 Pri 1 一个需引起严重关注的致命错误 必须在当前的冲刺阶段或里程碑期间解决 Pri 2 一个严重的错误 必须在产品发布前解决 Pri 3 一般性错误或建议 最好在产品发布前解决 Pri 0通常有碍测试、部署或其他对时间敏感的工作。你必须给开发者或团队发邮件并电话告知他们或者直接过去跟他们谈直到有人解决这个问题。如果有变通办法Pri 0就必须改成Pri 1。 注确实有开发团队对优先级别有非常多的定义。有的从Pri 1开始而不是Pri 0有的不遵从我在本章开始时列出的准则或者在一个单独的区域提示Bug信息。 如果你查看另一个团队的工作项目数据库确定你使用的是他们的定义。这些定义通常显示在工具提示上或帮助窗口中。
严重程度
严重程度比优先级别简单得多但是它还是经常被搞混。严重程度指的是问题所产生的影响范围不关乎“有多么严重”这样的问题。其定义是
• 严重程度1。某问题引起系统崩溃或客户数据丢失。 • 严重程度2。某问题引起的故障阻断了后续操作。 • 严重程度3。某问题引起操作不便或界面显示不完整。 注意严重程度与优先级别是相互独立的——换句话说严重程度与优先级别毫无关系。优先级别1的Bug比级别2的Bug更重要不管其严重程度如何。显示一些不合适的内容就是严重程度3但也可能是优先级别1系统崩溃后用户强行重启就是严重程度1同时也可能是优先级别3。工程师声称一个未致系统崩溃的Bug的严重程度是1因为严重程度很高。你完全没必要成为他戏弄的笑料。如果你这样就白痴了。
解决方案
Bug报告中最重要且经常被混淆的部分是“解决方案”——说明如何解决问题。解决了一个Bug意味着你不再关心这个问题。当Bug的发现者确认这个方案能修复这个Bug时你也不打算再作更多的处理。 在你发布产品前如果对一个问题需要做更多的处理即使这不是你的团队的责任那这个Bug还是要引起关注并指定你团队里的一个人继续跟踪相关事宜。
以下是解决方案部分可能包含的内容
• 意图。Bug报告描述了所需处理的细节按预先意图进行。 • 重复。这个Bug与报告中先前指出的Bug有相同的起因及非常相似的用户体验。不要像分析一个旧Bug一样分析新Bug——不管这个新的Bug报告看起来会多精美除非你想与Bug发现人为敌并丧失“首先发现Bug”的机会。 • 外部性。一个Bug是由你控制能力之外的原因引起的则你可以在Bug未修复之前发布产品。如果你团队之外的人没有修复这个问题使你的产品发布不了那么保持对这个Bug的关注并指定你团队里的某人进行跟踪找到其他团队中存在的问题。 • 已修复。Bug修复了。这是我最喜爱的解决方案。 • 不再发生。你不能让Bug在之前说过的创建版本及环境中再次发生。声称“在我的机子上运行没什么问题”并不代表Bug解除了——随时与Bug发现人保持沟通。 • 延期。你不想在这个版本中修复Bug。延期是偷懒者的借口他们总说明天我会写个测试单元。真正的工程师会时刻关注这个Bug并会在Bug报告里留出一个“等待修复”专区来指出下一个改进版本只要他们真的想修复这个问题。 • 不修复。你不再修复Bug。这是我第二种得意的解决方法——这说明你有丰富的经验判知哪些Bug不需要修复。通常是因为修复本身会带来比Bug更多的问题。 当你在解决一个Bug时你必须在解决方案中有段描述。这段描述是很重要的。这样可使解决方案少些争论Bug重现时就更易理解使你与你的公司免于因为这个问题成了公众热议的话题。这在我之前的一个团队中曾发生过——我们使这个公司免于千夫所指因为我们的解决方案中对一个出现不合适内容的Bug作了描述以说明我们并非蓄意而为。
当一个Bug被解决它将被自行指派给发现它的人。如果这个人不是开发团队的人员那这个Bug必须指定给另一个团队中的人这个人可以跟Bug发现者核实解决方案。但你不能总是指望团队外部的人能及时周到地确认解决方案。当然如果这个解决方案不怎么令人满意那么这个Bug应被重新激活。
过犹不及
Bug报告中还有很多其他区域。我说过用“创建”及“环境”两个区域记录Bug相关信息以及用“等待修复”区域来说明什么时候处理Bug。还有一些区域用来跟踪记录底层原因这个Bug是怎么被发现的Bug是在产品或服务的哪个方面发生的潜在的安全威胁以及其他信息。
设定好Bug报告的必要条件少则缺多则无益。要求太多人们会怨声四起而拒绝完成Bug报告——两种极端都会对你及你的客户不利。
Bug报告要易写且易读这样会促使他们在发现问题的时候制定清晰的Bug报告。使用一些Bug模板对于一些内容的编写是很有帮助的。对于我们在乎的工程师及客户来说规范的Bug报告使一个问题在用户发现前消灭于萌芽状态没有比这更好的礼物了。
