What is the bug life cycle.
What is the bug life cycle.This is very basic(based on tool used-)
The typical lifecycle of a bug is as follows:
1. Bug is identified in system and created in Bugs Online
2. Bug is assigned to a developer
3. Developer resolves bug or clarifies with user
4. Developer sets bug to "Completed" status and assigns back to original user
5. Original user verifies that bug has been resolved and if so sets bug to "Closed" status. Only the original user who created the bug has access to "Close" the bug. Once the bug is closed it may never be re-opened or have future activity.
6. If the bug was not resolved to the user's satisfaction they may assign it back to the developer with a description (by adding a new detail). If this occurs then the bug returns to step 2 above.
It is important to note that throughout the lifecycle of a bug, it should be assigned to someone. The system will allow for a bug to not be assigned but the usage of this feature should be minimal.
By insuring that a bug is always assigned to a user or a developer, system administrators will maintain a high level of accountability for all bugs submitted to the system.
Prepare bug report:
Bug ID Description Status Priority Assigned to Date
Status: open/re-open/cancel/new/pending/fixed
Priority: high/low/medium/critical Bug life cycles are similar to software development life cycles. At any time during the software development life cycle errors can be made during the gathering of requirements, requirements analysis, functional design, internal design, documentation planning, document preparation, coding, unit testing, test planning, integration, testing, maintenance, updates, re-testing and phase-out. Bug life cycle begins when a programmer, software developer, or architect makes a mistake, creates an unintentional software defect, i.e. a bug, and ends when the bug is fixed, and the bug is no longer in existence. What should be done after a bug is found? When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it. 什么是bug生命周期。
这是非常基础的（基于工具的使用）
bug的典型生命周期如下所述：
1.在系统中找出bug并创建bug在线管理
2.将bug分配给开发者
3.开发者为使用者解决bug或者解释bug
4.开发者将已经解决的bug的状态改为“完成”并且返回给最原始的使用者
5.最原始的使用者检验被解决的bug，如果证实确实解决将状态改为“关闭”。只有创建该bug的最原始的使用者才有权力“关闭”这个bug。一旦这个bug被关闭，它可能不会再被打开或者有更进一步的行动。
6.如果被解决的bug没有满足用户，它们将会带着描述（添加一个新的详细信息）再次分配给开发者。如果走到这一步那么这个bug返回到上面第2步。
记录一个bug的生命周期的始终是很重要的，这应该指定给一些人去做。系统将会考虑到一个错误没被分配，但是这一个功能的用法应该是最小的。
为了确保bug总是会分配给一个使用者或是一个开发者，系统管理员应该对所有提交到系统的的bug保持有高度的责任感。
准备bug报告：
Bug ID，描述，状态，严重程度，分配日期
状态：打开/重新打开/取消/新建/未解决/已解决
严重程度：高/低/中/严重 bug生命周期与软件开发生命周期类似。在软件开发生命周期的任何时候，错误能在需求，需求分析，功能设计，内部设计，文件编写规划，文件准备，编码, 单元测试，测试计划，集成，测试，维护，更新, 回归测试和逐步完成中产生。bug生命周期以一个程序设计者，软件开发者,或设计者犯了一个错误，产生一个无心的软件缺陷,也就是一个bug开始, 以bug被修改并且这个bug不再出现而结束。当一个bug被找到后应该做些什么？当一个bug被找到的时候,需要通知和分配给能修改它的开发者。在问题解决之后,被修改的bug应该被再测试。 另外，要有做需求，软件，硬件，安全冲击等等的决心,要有回归测试去检查没有因为修改而在其他地方产生的错误。多种商业的,追踪问题的软件管理工具是可以使用的。这些工具,与软件测试工程师的详细输入信息, 将会给团队全部的信息以便开发者能理解bug, 知道它的严重性, 再现它而且解决它。 有不对的地方请指正！谢谢！ 翻译的不错，加分鼓励了！ 谢谢了！！！！ 不错～ 我也跟着翻了一遍
很多专业术语和E文我都对不上，这下可好了呢～ 版主写的是最基本的ＢＵＧ的周期，各个公司还会有细微的差别，不过大体就是这样的了 感谢! 强！！ 根据我们现在所使用的BUG工具，能翻译对得上一点 ‘By insuring that a bug is always assigned to a user or a develope‘
’为了确保bug总是会分配给一个使用者或是一个开发者‘
这句感觉翻译得不太对啊，应该是 BY应该翻成“通过”， 不然原文就会用 “ TO INSURE” 厉害
我的E文菜的很
只能联盟带猜
页:
[1]
