请教bug描述的问题。
1。 bug描述一般要用过去时态,有没有这样的说法?理论依据是什么?2。 bug描述一般以主语开始,不用祈使句。有没有这样的说法?理论依据是什么? 本帖最后由 andyyoung 于 2010-11-22 15:22 编辑
我想对Bug的描述倒没有那么复杂的约定,抓住“准确、清晰”的原则就可以了。如果一定要要求过去时态,那一定是Bug的重现跟时间或者别的什么因素相关,这些因素没找出来,用什么时态描述都是白搭。
如果一定要要求主语开始,那一定是开发人员看不清Bug描述的人机交互过程,如果不把交互过程搞清楚,什么状语后置、宾语前置都没用。
看问题是要看本质的,不要局限于表面。
仅供参考。呵呵。 没有lz的那种说法吧?
我倒知道有5C的规范
清晰,完整,准确,一致,简洁
其实只要你能描述清楚你复现的整个过程就可以了
再加上你觉得对开发定位有用的信息 我也同意以上两位朋友的看法,但老板提出这样的要求,我百思不得其解!他也找不到依据。可能是他们以前的习惯。谢谢各位了…… 其实我们提bug的时候不知道有这两点说法,但是回头看看bug差不多这样的。对于第一条,什么出现了什么错误,这个应该是过去的吧,因为是在提交这个bug之前发生的;第二条以主语开始,我们描述的时候一般会说:什么模块的什么页面中发生怎样的错误,我想这个什么模块什么页面应该是主语吧。这只是我的一点理解,说得不好请见谅 图文并茂
最好清楚易懂 有summary和comments还有重现的步骤。。一般都是这三个吧。。
summary一般都是比较简洁的。。比如说: An error message pops up when click *** link on $$$ window.
一般现在时就好吧。。 过去式,祈使句,真专业啊……呵呵 :) :) 图文并茂
清楚易懂 这个有关系吗?描述清楚了就好了啊 图文并茂! you有人能解释一下什么是祈使句吗,偶文盲了:lol 定位准确,语句简洁,易懂无歧义! 我觉得忠实的记录BUG,让开发能够重现BUG,图文并茂,最好能帮助定位BUG最好 描述出处 是什么情况 实际结果是什么预期是什么结果就好了.想的太复杂了吧 清晰,完整,准确,一致,简洁 简洁的复现BUG bug重现最重要,要求一定要简洁清楚 我觉得很容易理解啊,没什么问题。过去式很正确啊,祈使句也很正确,没问题啊。
页:
[1]
2