51Testing软件测试论坛
标题: bug life cycle [打印本页]
作者: addvalue 时间: 2006-5-12 22:07
标题: bug life cycle
What happens to a bug from start to finish.
While attending testing seminars, I noticed that there was a gap in what was being taught. There’s a lot of theory presented, a lot of ‘why test’ classes and a lot of classes on specific techniques but nothing on a couple of practices that will go a long way towards improving the testing process in a company, specifically setting up a defect tracking system and enforcing policies and procedures to resolve those defects. Setting up these two things, more than anything else, will put a company on the road to organizing its testing and QA effort. To fill that gap, I’ve come up with the ‘Bug Life Cycle’ presentation. While I can’t claim it as my own, it is what I’ve learned over the years as a tester; many of you will find it familiar.
What is a bug?
In computer technology, a bug is a coding error in a computer program. Myers defined it by saying that “A software error is present when the program does not do what its end user reasonably expects it to do.” (Myers, 1976.). I tell my testers if you don’t like it, it’s a bug.
Over the years, my colleagues and I have decided that there are as many definitions for the term “bug” as there are testers. “There can never be an absolute definition for bugs, nor an absolute determination of their existence. The extent to which a program has bugs is measured by the extent to which it fails to be useful. This is a fundamentally human measure.” (Beizer, 1984.). For a more definitive list of many types of bugs refer to Software Testing by Cem Kaner, et. al., pages 363-432.
Who can report a bug?
Anyone who can figure out that the software isn’t working properly can report a bug. The more people who critique a product, the better it’s going to be. However, here’s a short list of people expected to report bugs:
Testers / QA personnel
Developers
Technical Support
Beta sites
End users
Sales and marketing staff (especially when interacting with customers).
When do you report a bug?
When you find it! When in doubt, write it up. Waiting means that you’ll forget to write it altogether or important details about the bug will be forgotten. Writing it now also gives you a ‘scratch pad’ to make notes on as you do more investigation and work on the bug.
Also, writing the bug when you find it makes that information instantly available to everyone. You don’t have to run around the building telling everyone about the bug; a simple phone call or email will alert everyone that the bug exists. Additionally, the information about the bug doesn’t change or get forgotten with every telling of the story.
Bugs are tracked in a database
The easiest way to keep track of defect reports is in a database. Paper is an ok way to record defect reports on but pieces of paper can get lost or destroyed; a database is more reliable and can be backed up on a regular basis.
You can purchase many commercially available defect tracking databases or you can build your own. It’s up to you. I’ve always built my own with something small like Microsoft Access or SQL Server. The decision then was that it was cheaper to build and maintain it on site than it was to purchase it. You’ll have to run the numbers for your situation when you make that decision.
The rule of thumb is one and only one defect per report (or record) when writing a bug report. If more than one defect is put into a report, the human tendency is to deal with the first problem and forget the rest of them. Also, defects are not always fixed at the same time. With one defect per report, as the defects get fixed, they will be tested individually instead of in a group where the chance that a defect is overlooked or forgotten is greater.
You may hear the term “bugfile” used by people when referring to a defect database. The name bugfile is a slang term from the old WordPerfect Corporation. “Bugs” were first logged into a flat file database called DataPerfect; a file of bugs, hence the word “bugfile”.
A good bug reports include the following items:
Put the Reporter’s Name on the bug. If there are questions we need to know who originated this report.
Specify the Build or Version number of the code being worked on. Is this the shipping version or a build done in-house for testing and development? Some bugs may only occur in the shipping version; if this is the case, the version number is a crucial piece of information.
Specify the Feature or Specification or part of the code. This facilitates assigning the bug to a developer assigned to that part of the product.
Include a Brief Description of what the problem is. For example, “Fatal error when printing landscape.” is a good description; short and to the point.
List Details including how to duplicate the bug and any other relevant data or clues about the bug. Start with how the computer and software is setup. List each and every step (don’t leave any out) to produce the bug. Sometimes a minor detail can make all the difference in duplicating or not duplicating a bug. For example, using the keyboard versus using the mouse may product very different results when duplicating a bug.
If the status isn’t ‘Submitted’ by default, change it to Submitted. This is a flag to the bug verifier that a new bug has been created and needs to be verified and assigned.
Things to remember…
Keep the text of the bug impersonal. Bug reports will be read by a variety of people including those outside the department and even the company. Please don’t insult people’s ancestors or the company they work for or the state they live in or make any other impulsive or insensitive comment. Be careful with humorous remarks; one person’s humor is another person’s insult. Keep the writing professional.
Be as specific as possible in describing the current state of the bug along with the steps to get into that state. Don’t make assumptions that the reader of the bug will be in the same frame of mind as you are. Please don’t make people guess where you are or how you got into that situation. Not everyone is thinking along the same lines as you are.
Rating Bugs
While it is important to know how many bugs are in a product, it is even more useful to know how many of those bugs are severe, ship stopping bugs compared to the number of inconvenient bugs. To aid in assessing the state of the product and to prioritize bug fixes, bugs are ranked. The easiest way to rank or rate bugs is to assign each bug a severity rating and a likelihood rating. This assignment is done by the bug reporter when the bug is created. The bug’s rating is a combination of the severity and likelihood ratings.
Severity
The severity tells the reader of the bug how bad the problem is. Or in other words, say what the results of the bug are. Here’s a common list for judging the severity of bugs. There is sometimes disagreement about how bad a bug is. This list takes the guess work out of assigning a severity to bugs.
Rating Value
Blue screen 1
Loss without a work around 2
Loss with a work around 3
Inconvenient 4
Enhancement 5
Likelihood
Put yourself in the average user’s place. How likely is a user to encounter this bug? While the tester may encounter this bug every day with every build, if the user isn’t likely to see it, how bad can the bug be?
Rating Value
Always 1
Usually 2
Sometimes 3
Rarely 4
Never 5
Severity * Likelihood = Rating
Computing the rating of a bug is done by multiplying the numeric value given to the severity and likelihood status’. Do the math by hand or let your defect tracker do it for you.
The trick is to remember that the lower the number, the more severe the bug is. The highest rating is a 25 (5 X 5), the lowest is 1 (1 X 1). The bug with a 1 rating should be fixed first while the bug with a 25 rating may never get fixed.
Looking at a list of these bugs ordered by rating means the most important ones will be at the top of the list to be dealt with first. Sorting bugs this way also lets management know whether the product is ready to ship or not. If the number of severe (1) bugs is zero, the product can ship. If there are any severe bugs, then bug fixing must continue.
Other useful information
Who’s the bug Assigned to; who’s going to be responsible for the bug and do the work on the bug?
What Platform was the bug found on – Windows, Linux, etc. Is the bug specific to one platform or does it occur on all platforms?
What Product was the bug found in? If your company is doing multiple products this is a good way to track those products.
What Company would be concerned about this bug? If your company is working with multiple companies either as an OEM or as customer this is a good way to track that information.
Whatever else you want or need to keep track of. Some of these fields will also have value to marketing and sales. It’s a useful way to track information about companies and clients.
An example of a bug report:
Figure 1 The status tells us the state of the bug. The severity tells us how bad the bug is. The likelihood tells us how often the average user will see the bug. The Assigned To field tells us who is responsible for resolving the bug. The Feature tells us what part of the product the bug is in. The Problem Description gives a brief (very brief) summation of the problem. This description is used when compiling reports or lists of bugs. The details tell us the current setup or situation, the steps to duplicate the problem and any other essential information that will allow someone else to duplicate the bug. Once the bug is submitted, this field cannot be changed. Any additional information will go in the notes field. The notes field contains any discussions about the bug. For example, when and why the status was changed and by whom; additional information about how to duplicate the bug that will aid in resolving the bug; and opinions about the bug. This is a “free-forum” area where people should feel free to express their opinions without censure or criticism. Once comments are placed on a bug, they cannot be changed or deleted by anyone else or even the author. The comments, like the details, stand. Anyone reading the bug after the fact should be able to understand not only what the bug was and how bad a bug it was but also how it was resolved and why it was resolved that way.
Examples of poorly written bugs:
Please keep in mind that I didn’t make any of these up!
“My computer crashed.” We are sorry for your loss, can you give us more information?
“It’s kinda “sucky”.” This one violates all sorts of rules. What’s kind of “sucky”. For that matter, define “sucky.”. Better yet, don’t use the work “sucky” it’s not in the dictionary and most certainly not in good taste.
“It don’t.” This bug doesn’t provide enough information. What don’t? Don’t what?
“Product needs a “speel” checker.” It goes without saying that “spelling counts”!
Now we have a bug…
The first step is Verification. A bug verifier searches the database looking for all ‘Submitted’ bugs assigned to him. He then duplicates the bug by following the steps listed in the details section of the bug. If the bug is reproduced and has all the proper information, the assigned to field is changed to the appropriate person who will be fixing the bug. If the bug is not written clearly, is missing some steps or can’t be reproduced, it will be sent back to the bug reporter for additional work.
The Assigned To field contains the name of the person responsible for that area of the product or code. It is important to note that from this point onward, the developer’s name stays on the bug. Why? There are usually more developers than there are testers. Developers have a set of features to work on. Developers look at bugs from a stand point of “what is assigned to me?”. Testers have multiple sets of features to test. Testers look at bugs from a stand point of “what needs to be tested?”; testers may also change what features they are assigned to test. Because of the different way testers and developers work, developers sort bugs by the Assigned To field and testers sort bugs by the Status field. Leaving the developer’s name on the bug also makes it easier to send the bug back to the developer for more work. The tester simply changes the status field to Verified and it automatically goes back to the developer.
The Developer works on the bug…
The first thing the developer does is give the bug a ‘In Progress’ status indicating that he has seen the bug and is aware that it his responsibility to resolve. The developer works on the bug and based on his conclusions assigns a status to the bug indicating what the next step should be.
Remember, the developer does NOT change the Assigned To field. His name stays on the bug so if the bug has to go back to him, it will make back onto his list. This procedure ensures that bugs don’t fall between the cracks.
The following is a list of status’ that a developer can assign to a bug.
Fixed
The Fixed status indicates that a change was made to the code and will be available in the next build. Testers search the database on a daily basis looking for all Fixed status bugs. Then the bug reporter or tester assigned to the feature retests the bug duplicating the original circumstances. If the bug is fixed and it is now working properly, another test with slightly different circumstances is performed to confirm the fix. If the bug passes both tests, it gets a Tested status.
If the bug doesn’t pass the test, the bug is given a Verified status and sent back to the developer. Notice here that since the bug’s Assigned To field has retained the developer’s name, it’s an easy process for the tester to send the bug back by simply changing the status to Submitted.
Duplicate
The Duplicate status bug is the same as a previously reported bug. Sometimes only the developer or person looking at the code can tell that the bug is a duplicate. It’s not always obvious from the surface. A note indicating the previous bug number is placed on the duplicate bug. A note is also placed on the original bug indicating that a duplicate bug exists. When the original bug is fixed and tested, the duplicate bug will be tested also. If the bug really is a duplicate of previous bug then the when the previous bug is fixed, the duplicate bug will also be fixed. If this the case then both bugs get a Tested status.
If the duplicate is still a bug, while the original bug is working properly, the duplicate bug is no longer has a duplicate status. It gets a Submitted status and is sent back to the developer. This is a “fail-safe” built into the bug life cycle. It’s a check and balance that prevents legitimate bugs from being swept under the carpet or falling between the cracks.
A note of warning. Writing lots of duplicate bugs will get a tester a reputation for being an “airhead”. It pays to set time aside daily to read all the new bugs written the previous day.
Resolved
Resolved means that the problem has been taken care of but no code has been changed. For example, bugs can be resolved by getting new device drivers or third party software. Resolved bugs are tested to make sure that the problem really has been resolved with the new situation. If the problem no longer occurs, the bug gets a Tested status. If the Resolved bug still occurs, it is sent back to the developer with a Submitted status.
Need More Information
Need More Information or “NMI” indicates that the bug verifier or developer does not have enough information to duplicate or fix the bug; for example, the steps to duplicate the bug may be unclear or incomplete. The developer changes the status to ‘Need More Information’ and includes a question or comments to the reporter of the bug. This status is a flag to the bug reporter to supply the necessary information or a demonstration of the problem. After updating the bug information (in the Notes field), the status is put back to Verified so the developer can continue working on the bug. If the bug reporter can not duplicate the bug, it is given a Can’t Duplicate status along with a note indicating the circumstances.
The only person who can put “Can’t Duplicate” on a bug is the person who reported it (or the person testing it). The developer can NOT use this status, he must put Need More Information on it to give the bug reporter a chance to work on the bug.
This is another example of a “fail-safe” built into the database. It is vital at this stage that the bug be given a second chance. The developer should never give a bug a ‘Can’t Duplicate’ status. The bug reporter needs an opportunity to clarify or add information to the bug or to retire it.
Working as Designed
The developer has examined the bug, the product requirements and the design documents and determined that the bug is not a bug, it is Working as Designed. What the product or code is doing is intentional as per the design. Or as someone more aptly pointed out it’s “working as coded”! It’s doing exactly what the code said to do.
This bug can go several directions after being assigned this status. If the tester agrees with the status, then the status stands and the bug is finished. The bug may be sent to documentation for inclusion in help files and the manual. If the tester disagrees with the status then the bug can be appealed by putting a Submitted status on it to send the bug back through the process again. The tester should include in the notes a reason why, although it is Working as Designed, it should be changed now. The bug may also be sent back to the design committee so that the design can be improved.
This is a dangerous status. It’s an easy way to sweep bugs under the carpet by giving them this status. It’s up to the bug reporter to make sure the bug doesn’t get forgotten in this manner. Product managers may also review lists of bugs recently assigned Working as Designed.
Enhancement
Enhancement means that while the suggested change is great idea because of technical reasons, time constraints or other factors, it won’t be incorporated into the code until the next version of the product.
This status may also be appealed by changing the status to Submitted and adding a note specifying why it should be fixed now.
Defer
Defer is almost the same status as Enhancement. This status implies that the cost of fixing the bug is too great given the benefits that it would produce. If the fix is a one liner to one file that doesn’t influence other files, it might be ok to fix the bug. On the other hand, if the fix will force the rebuild of many files which would force the re-testing of the product and there’s no time left to test the fix before shipping the product, then the fix would be unacceptable and the bug would get a Defer status. To appeal the status, send it back through the process again by putting a Submitted status on it and add a note saying why it should be fixed now.
Not to be Fixed
You may see the Not to be Fixed status although I don’t recommend making this status available for use. There may be extenuating circumstances where a bug will not be fixed because of technology, time constraints, a risk of destabilizing the code or other factors. A better status to use is Not to be Fixed. To appeal the status, send it back through the process again by putting a Submitted status on it and add a note saying why it should be fixed now.
This is similar to the Working as Designed status in that its use can be dangerous. Be on the watch for this one. Sometimes developers call this status “You can’t make me”.
Tested
The Tested status is used only by testers on Fixed, Resolved and Duplicate bugs. This status is a “end of the road” status indicating that the bug has reached the end of its life cycle.
Pending
The Pending status is used only by testers on Fixed bugs when a bug cannot be immediately tested. The tester may be waiting on hardware, device drivers, a build or additional information necessary to test the bug. When the necessary items have been obtained, the bug status is changed back to Fixed and then it is tested. Make sure the testing part isn’t skipped.
Can’t Duplicate
This status is used only by the bug reporter; developers or managers cannot use this status. If a bug isn’t reproducible by the assigned developer or bug verifier the bug reporter needs a chance to clarify or add to the bug. There may be a hardware setup or situation or particular way of producing a bug that is peculiar to only this computer or bug reporter and he needs a chance to explain what the circumstances are. Limiting this status to bug reporters only prevents bugs from slipping between the cracks and not getting fixed.
The product has shipped, what happens next?
First of all, to ship a product the number of bugs rated 5 or less, bugs with a Fixed, Resolved, Pending or Need More Information status must be zero. We’ll assume that the product has shipped and all these bugs have been taken care of. This means the bugfile is full of bugs that have reached the end of their life cycle. Proper database maintenance takes place at this point. Archiving or hiding all these bugs will make the database easier to use and read.
All bugs with a Tested or Can’t Duplicate bugs are archived. This means that the records are either removed and placed in an archive database or flagged to be hidden from the current view of the database. Never delete any bug records; it may be necessary to do some historical research in the bugfile (‘What did we ship when?’ or ‘Why did we ship with this bug?’).
Enhancement and Defer bugs are either moved to the new bugfile or retained in the current bugfile. The status of these bugs is then changed back to Verified.
Advanced defect database techniques
There are things you can do with your database to make it more than just a to-do list for developers and testers. The bugfile is basically raw data, sorting and filtering it makes the data information that is useful in the decision making process done by management. A couple of these things to do with the data is to create Reports and Customized views.
Reports
The data in the defect database is not very useful until it is sorted and presented in a organized fashion, then it becomes information. For example, sorting by developer, the information becomes a ‘to do’ list sorted by rating. Sorting by status lets the reader know how many bugs are submitted or in progress; i.e. how many bugs are currently being worked on? By feature – how many open bugs are there for a particular feature? What feature needs more work and what feature is stable? Sorting by product is useful when more than one product is being worked on simultaneously.
Be aware that there are certain metrics or reports that should not be used. If you use these reports you will destroy the credibility of your bug file and it will be reduced to a “laundry-list” for developers. One of these reports is “how many bugs did a tester report” and the other is “how many bugs did a developer fix”. Neither one of these has any useful purpose except to beat up people uselessly. See Software Testing by Cem Kaner, et. al.
Examples of Reports
The Product Manager wants to see a list of bugs to be fixed before shipping that is sorted by rating to determine how ready the product is for shipping. He needs to know what work is left to be done so that an appropriate schedule can be set. The Test Lead needs a list of bugs to be tested before shipping, sorted by tester to make sure all the bugs get tested in the allotted amount of time. The Development Lead has a list of bugs to be resolved before shipping, sorted by developer so that adjustments in work load can be made to ensure that everything is taken care of by the deadline. Technical Support likes a list of bugs that were fixed and not fixed in the product before shipping so they can adequately prepare to support the product. Technical support can resolve customer problems faster by knowing what has been fixed in a product release (the new release or upgrade will fix that problem) and what bugs are still in the product.
A defect database that has all these fields built into it is able to sort defect data and make it useful information.
Customized views of the database
If your defect tracking database supports it, you can limit the information seen based on who the person logging in is. For example, the database that I built with SQL Server 7 was web browser based. Each person was assigned a job category such as ‘Tester’, ‘Developer’ or ‘Manager’. The web page that displayed was then the web page designed for that job category. The Developer would see Submitted and In Progress bugs assigned to him while Testers would see all Fixed, NMI, Pending, Resolved, and Duplicate bugs regardless of who is assigned to the bug. The Product Manager view sees all bugs assigned to him, all newly reported bugs, and newly updated bugs.
The reason for this customized view is that each job views the defect database in a different way based on their needs and the work that has to be accomplished. Testers don’t care who the bug is assigned to, just what the status is. Testers want to see all the bugs, not just bugs written by them, with a ‘Fixed’ status so the bugs can be tested with the latest build. Developers only care about what current and active bugs are assigned to them; developers aren’t concerned about any other person’s bugs. Product managers are concerned that bugs don’t get ‘swept under the carpet’ with Enhancement or Defer status’ so managers want to see all bugs with that particular status.
References
Software Testing by Cem Kaner, et.al.
Software Testing in the Real World by Edward Kit
Software Test Documentation (IEEE 829-1983)
The Complete Guide to Software Testing by Bill Hetzel
The Art of Software Testing by Glenford J. Myers
Software Testing and Quality Assurance by Boris Beizer
Software Quality: Analysis and Guidelines for Success by Capers Jones
Software Testing Techniques by Boris Beizer
Software Testing by Ron Patton (2000, Sams, ISBN 0672319837). See chapters 18 and 19.
“Organize Your Problem Tracking System Cleaning up your bug database can be as easy as organizing your sock drawer” By Barry Mirrer.
作者: brilliantking 时间: 2006-5-13 21:52
标题: bug生命周期
What happens to a bug from start to finished
Bug从产生到消亡，期间到底发生了什么
While attending testing seminars, I noticed that there was a gap in what was being taught. There’s a lot of theory presented, a lot of ‘why test’ classes and a lot of classes on specific techniques but nothing on a couple of practices that will go a long way towards improving the testing process in a company, specifically setting up a defect tracking system and enforcing policies and procedures to resolve those defects. Setting up these two things, more than anything else, will put a company on the road to organizing its testing and QA effort. To fill that gap, I’ve come up with the ‘Bug Life Cycle’ presentation. While I can’t claim it as my own, it is what I’ve learned over the years as a tester; many of you will find it familiar.
[ 本帖最后由 brilliantking 于 2010-3-1 20:59 编辑 ]
作者: brilliantking 时间: 2006-5-13 21:54
标题: What is a bug?
什么是bug？
In computer technology, a bug is a coding error in a computer program. Myers defined it by saying that “A software error is present when the program does not do what its end user reasonably expects it to do.” (Myers, 1976.). I tell my testers if you don’t like it, it’s a bug.
在计算机技术里，bug是计算机程序里的代码错误。Myers是这么定义一个bug的“当应用程序没有完成终端用户的合理要求时，一个软件缺陷就产生了”（Myers, 1976.）我告诉我的测试人员，如果你不喜欢软件的某个表现，它就是一个bug。
Over the years, my colleagues and I have decided that there are as many definitions for the term “bug” as there are testers. “There can never be an absolute definition for bugs, nor an absolute determination of their existence. The extent to which a program has bugs is measured by the extent to which it fails to be useful. This is a fundamentally human measure.” (Beizer, 1984.). For a more definitive list of many types of bugs refer to Software Testing by Cem Kaner, et. al., pages 363-432.
多年来，我和我的同事们认为关于“bug”的定义和测试人员一样多。“从来没有一个对bug的绝对定义，也没有对bug存在的绝对的确定。一个程序在多大程度上存在bug，要看它在多大程度上没有做到应做的事。这在根本上就是人为决定的。”（ Beizer, 1984.）。若要查看各种类型bug的明确定义，请参考Software Testing by Cem Kaner, et. al., pages 363-432。
谁能报告一个bug？
Anyone who can figure out that the software isn’t working properly can report a bug. The more people who critique a product, the better it’s going to be. However, here’s a short list of people expected to report bugs:
任何能指出软件运行不正常的人都可以报一个bug。越多人对一个产品发表评论，这个产品就会变得越好。尽管如此，这儿还是列出了可以报bug的人员清单：
Testers / QA personnel
测试人员/QA人员
Developers
开发人员
Technical Support
技术支持人员
Beta sites
Beta站点人员
End users
终端用户
Sales and marketing staff (especially when interacting with customers).
市场营销人员（特别是与客户进行交流的时候）
When do you report a bug?
什么时候可以报bug？
When you find it! When in doubt, write it up. Waiting means that you’ll forget to write it altogether or important details about the bug will be forgotten. Writing it now also gives you a ‘scratch pad’ to make notes on as you do more investigation and work on the bug.
Also, writing the bug when you find it makes that information instantly available to everyone. You don’t have to run around the building telling everyone about the bug; a simple phone call or email will alert everyone that the bug exists. Additionally, the information about the bug doesn’t change or get forgotten with every telling of the story.
此外，当你发现一个bug就写下来可以让每个人立刻获取bug信息。你不必跑遍整座大楼去告诉每个人关于这个bug的信息；一个简单的电话或者邮件就可以使大家注意到这个bug的存在。另外，bug的信息在每次传述中不会发生变化。
[ 本帖最后由 brilliantking 于 2010-3-1 21:02 编辑 ]
作者: brilliantking 时间: 2006-5-13 21:58
标题: Bugs are tracked in a database
Bugs are tracked in a database
在数据库中跟踪bug
The easiest way to keep track of defect reports is in a database. Paper is an ok way to record defect reports on but pieces of paper can get lost or destroyed; a database is more reliable and can be backed up on a regular basis.
保持对缺陷报告的跟踪的最从容的方法是应用数据库。纸张可以很好地记录缺陷报告，但是，大量的纸张会丢失或损坏；数据库则比较可靠，而且它可以定期备份。
You can purchase many commercially available defect tracking databases or you can build your own. It’s up to you. I’ve always built my own with something small like Microsoft Access or SQL Server. The decision then was that it was cheaper to build and maintain it on site than it was to purchase it. You’ll have to run the numbers for your situation when you make that decision.
你可以购买许多商用的缺陷跟踪数据库或者你可以自己建立一个数据库。这由你自己决定。我总是用像Microsoft Access 或 SQL Server这样的小型软件来构建自己的数据库。这种做法对于在站点上构建和维护数据库来说比购买的要便宜。当你做出决定时，你必须充分考虑自己的情况。
The rule of thumb is one and only one defect per report (or record) when writing a bug report. If more than one defect is put into a report, the human tendency is to deal with the first problem and forget the rest of them. Also, defects are not always fixed at the same time. With one defect per report, as the defects get fixed, they will be tested individually instead of in a group where the chance that a defect is overlooked or forgotten is greater.
You may hear the term “bugfile” used by people when referring to a defect database. The name bugfile is a slang term from the old WordPerfect Corporation. “Bugs” were first logged into a flat file database called DataPerfect; a file of bugs, hence the word “bugfile”.
当提到缺陷数据库时，你也许听说过人们使用的一个术语“bugfile”。Bugfile这个词来源于老牌的WordPerfect公司的行业术语。“Bugs”首次进入的文件数据库叫DataPerfect；排成一列的bug，“bugfile”这个词由此而来。
[ 本帖最后由 brilliantking 于 2010-3-1 21:14 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:11
标题: A good bug reports include the following items
A good bug reports include the following items:
一个好的缺陷报告包括以下几个方面：
Put the Reporter’s Name on the bug. If there are questions we need to know who originated this report.
把bug报告人的名字写入报告。如果出现一些问题我们需要知道是谁写的这份报告。
Specify the Build or Version number of the code being worked on. Is this the shipping version or a build done in-house for testing and development? Some bugs may only occur in the shipping version; if this is the case, the version number is a crucial piece of information.
指明程序运行的代码的版本号。这是一个发布版本还是一个用于测试和开发的内部版本？一些bug可能只在发布版本中出现；如果是这种情况，版本号就是一个至关重要的信息了。
Specify the Feature or Specification or part of the code. This facilitates assigning the bug to a developer assigned to that part of the product.
指明软件的功能或规格或部分代码。这便于把bug指定给负责产品这一部分的开发人员。
Include a Brief Description of what the problem is. For example, “Fatal error when printing landscape.” is a good description; short and to the point.
包括对问题的简洁描述。例如，“打印风景照时出现致命错误。”就是一个好的描述；简短而中肯。
List Details including how to duplicate the bug and any other relevant data or clues about the bug. Start with how the computer and software is setup. List each and every step (don’t leave any out) to produce the bug. Sometimes a minor detail can make all the difference in duplicating or not duplicating a bug. For example, using the keyboard versus using the mouse may product very different results when duplicating a bug.
列出如何重现bug和任何其他有关这个bug的数据和线索的详细信息。首先指出计算机和软件是如何配置安装的。然后列出重现这个bug的每一个步骤（不要省略任何一个步骤）。有时候一个较小的细节也能导致这个bug是否重现。例如，使用键盘和使用鼠标在重现一个bug时候可能产生完全不同的结果。
If the status isn’t ‘Submitted’ by default, change it to Submitted. This is a flag to the bug verifier that a new bug has been created and needs to be verified and assigned.
如果bug的状态不是默认的“已提交”状态，要把它置为“已提交”。这对bug核实人员是一个重要标志，表明一个新bug被创建，这个bug需要核实和分配给特定的开发人员。
Things to remember…
需要记住的一些事
Keep the text of the bug impersonal. Bug reports will be read by a variety of people including those outside the department and even the company. Please don’t insult people’s ancestors or the company they work for or the state they live in or make any other impulsive or insensitive comment. Be careful with humorous remarks; one person’s humor is another person’s insult. Keep the writing professional.
Be as specific as possible in describing the current state of the bug along with the steps to get into that state. Don’t make assumptions that the reader of the bug will be in the same frame of mind as you are. Please don’t make people guess where you are or how you got into that situation. Not everyone is thinking along the same lines as you are.
尽可能详尽地描述bug当前的状况以及进入这种状况的步骤。不要以为看这个bug的人有和你一样的心境。请不要让别人来猜你是在哪或者如何进入这种情况的。不是每个人都和你的思维方式一样。
[ 本帖最后由 brilliantking 于 2010-3-1 21:16 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:21
标题: Rating Bugs
Bug分级
While it is important to know how many bugs are in a product, it is even more useful to know how many of those bugs are severe, ship stopping bugs compared to the number of inconvenient bugs. To aid in assessing the state of the product and to prioritize bug fixes, bugs are ranked. The easiest way to rank or rate bugs is to assign each bug a severity rating and a likelihood rating. This assignment is done by the bug reporter when the bug is created. The bug’s rating is a combination of the severity and likelihood ratings.
虽然知道一个产品里面有多少bug是重要的，但是把导致发布中止的bug与扰人的bug数量比起来，知道这些bug当中有多少严重的bug是更加有用的。为了评定产品的状态和对bug修复划分优先级，我们将bug进行分级。对bug进行分级最简单的办法是给每个bug指定一个严重级别和一个可能性级别。指定是在bug被创建的时候由bug报告人完成的。Bug的级别是由严重性和可能性级别组合而成的。
Severity
严重性
The severity tells the reader of the bug how bad the problem is. Or in other words, say what the results of the bug are. Here’s a common list for judging the severity of bugs. There is sometimes disagreement about how bad a bug is. This list takes the guess work out of assigning a severity to bugs.
严重性告知bug的读者这个问题有多坏。或者换句话说，这个bug的后果是怎样的。这里有一个用来判断bug严重性的常用列表。有时对bug的严重程度人们存在分歧。这个列表可以防止人们主观猜测bug的严重级别。
Rating Value
蓝屏
Loss without a work around 2
任务未完成程序就失败
Loss with a work around 3
可能性
Put yourself in the average user’s place. How likely is a user to encounter this bug? While the tester may encounter this bug every day with every build, if the user isn’t likely to see it, how bad can the bug be?
把自己置于一般用户的位置。想想用户有多大的可能性遇到这个bug？尽管测试人员每天每个版本都会遇到这个bug，但是如果用户不太可能发现这个bug，那么这个bug有多坏呢？
Rating Value
从不
Severity * Likelihood = Rating
严重性×可能性=级别
Computing the rating of a bug is done by multiplying the numeric value given to the severity and likelihood status’. Do the math by hand or let your defect tracker do it for you.
把严重性和可能性的数值相乘就可以计算出一个bug的级别。你可以亲自计算或者让缺陷跟踪人员帮你计算。
The trick is to remember that the lower the number, the more severe the bug is. The highest rating is a 25 (5 X 5), the lowest is 1 (1 X 1). The bug with a 1 rating should be fixed first while the bug with a 25 rating may never get fixed.
关键是要记住级别数越小，bug严重性越高。最高级别是25 (5 X 5)，最低是1 (1 X 1)。Bug级别为1的应该首先修复，而bug级别为25的可能再也得不到修复。
Looking at a list of these bugs ordered by rating means the most important ones will be at the top of the list to be dealt with first. Sorting bugs this way also lets management know whether the product is ready to ship or not. If the number of severe (1) bugs is zero, the product can ship. If there are any severe bugs, then bug fixing must continue.
[ 本帖最后由 brilliantking 于 2010-3-1 21:17 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:24
标题: Other useful information
报告里其他有用的信息
Who’s the bug Assigned to; who’s going to be responsible for the bug and do the work on the bug?
Bug应指派给谁；谁将负责这个bug并处理此bug？
What Platform was the bug found on – Windows, Linux, etc. Is the bug specific to one platform or does it occur on all platforms?
这个bug是在什么平台上发现的——Windows、Linux等等。这个bug只是在特定平台上出现，还是在所有平台上都出现。
What Product was the bug found in? If your company is doing multiple products this is a good way to track those products.
Bug是在哪个产品上发现的？如果你的公司做多个产品的测试，在这些产品上跟踪这个bug将会是一个不错的方法。
What Company would be concerned about this bug? If your company is working with multiple companies either as an OEM or as customer this is a good way to track that information.
哪个公司会关注这个bug？如果你的公司与多家公司一起合作，以OEM或者以客户的身份，那么这将是一个好方法来跟踪bug信息。
Whatever else you want or need to keep track of. Some of these fields will also have value to marketing and sales. It’s a useful way to track information about companies and clients.
[ 本帖最后由 brilliantking 于 2010-3-1 21:18 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:28
标题: An example of a bug report:
An example of a bug report:
Bug报告样例
Figure 1
The status tells us the state of the bug. The severity tells us how bad the bug is. The likelihood tells us how often the average user will see the bug. The Assigned To field tells us who is responsible for resolving the bug. The Feature tells us what part of the product the bug is in. The Problem Description gives a brief (very brief) summation of the problem. This description is used when compiling reports or lists of bugs. The details tell us the current setup or situation, the steps to duplicate the problem and any other essential information that will allow someone else to duplicate the bug. Once the bug is submitted, this field cannot be changed. Any additional information will go in the notes field. The notes field contains any discussions about the bug. For example, when and why the status was changed and by whom; additional information about how to duplicate the bug that will aid in resolving the bug; and opinions about the bug. This is a “free-forum” area where people should feel free to express their opinions without censure or criticism. Once comments are placed on a bug, they cannot be changed or deleted by anyone else or even the author. The comments, like the details, stand. Anyone reading the bug after the fact should be able to understand not only what the bug was and how bad a bug it was but also how it was resolved and why it was resolved that way.
状态栏告诉我们bug当前的状态。严重性告诉我们这个bug有多坏。可能性告诉我们普通用户能看见这个bug的频率。指派栏告诉我们谁会负责解决这个bug。特征栏告诉我们bug是在产品的哪一部分被发现的。问题描述栏对问题进行了简短（非常简短）的概括。这个描述在编制报告或bug列表时用到。详细信息栏告诉我们当前配置或测试环境、重现问题的步骤以及任何其他能让别人复现这个bug的重要信息。一旦bug被提交了，这个栏的信息就不能改变了。任何附加的信息将填在注释栏里。注释栏包括任何有关这个bug的讨论。例如，bug状态在什么时候、什么原因被改变了以及被谁改变了；复现这个bug的附加信息，而这个信息有助于解决这个bug；关于这个bug的一些看法等等。这是一个“自由论坛”，人们可以在这个论坛里自由发表意见而不必担心遭到指责或批评。一旦给一个bug添加了注释，注释就不能被任何人修改或删除，甚至是作者自己。这些注释，和详细信息一样，一直维持不变。任何读过这个bug的人可以理解这个bug是什么以及这个bug有多坏，不仅这些，他们还可以了解bug是如何解决的，以及为什么要这么解决。
Examples of poorly written bugs:
糟糕的bug报告样例
Please keep in mind that I didn’t make any of these up!
请记住我没有对这个bug进行任何编造！
“My computer crashed.” We are sorry for your loss, can you give us more information?
“我的电脑崩溃了。”我们对你的损失感到遗憾，你可以提供给我们更多的信息吗？
“It’s kinda “sucky”.” This one violates all sorts of rules. What’s kind of “sucky”. For that matter, define “sucky.”. Better yet, don’t use the work “sucky” it’s not in the dictionary and most certainly not in good taste.
“它有点“sucky””这句话简直违背了所有规则。什么叫“sucky”。为了说明问题，请先解释一下“sucky”。不过最好别用“sucky”这个词，词典里没有这个词，而且很可能不是一个好词。
“It don’t.” This bug doesn’t provide enough information. What don’t? Don’t what?
“它不干了。”这个bug没有提供足够的信息。什么不干了？不干什么了？
“Product needs a “speel” checker.” It goes without saying that “spelling counts”!
[ 本帖最后由 brilliantking 于 2010-3-1 21:19 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:30
标题: Now we have a bug…
Bug报上去之后……
The first step is Verification. A bug verifier searches the database looking for all ‘Submitted’ bugs assigned to him. He then duplicates the bug by following the steps listed in the details section of the bug. If the bug is reproduced and has all the proper information, the assigned to field is changed to the appropriate person who will be fixing the bug. If the bug is not written clearly, is missing some steps or can’t be reproduced, it will be sent back to the bug reporter for additional work.
The Assigned To field contains the name of the person responsible for that area of the product or code. It is important to note that from this point onward, the developer’s name stays on the bug. Why? There are usually more developers than there are testers. Developers have a set of features to work on. Developers look at bugs from a stand point of “what is assigned to me?”. Testers have multiple sets of features to test. Testers look at bugs from a stand point of “what needs to be tested?”; testers may also change what features they are assigned to test. Because of the different way testers and developers work, developers sort bugs by the Assigned To field and testers sort bugs by the Status field. Leaving the developer’s name on the bug also makes it easier to send the bug back to the developer for more work. The tester simply changes the status field to Verified and it automatically goes back to the developer.
指派给这一栏包含负责产品或代码的人的名字。重要的是要注意从这个时候开始，开发人员的名字就一直保留在bug报告里。为什么？通常开发人员数量比测试人员多。开发人员要开发一整套的功能。开发人员以不变的视角“什么bug被指派给我了？”来查看所有bug。测试人员要测试许多种功能。测试人员以不变的视角“什么是需要测试的？”来查看所有bug；测试人员也可能改变指派给他们测试的功能。由于测试人员与开发人员不同的工作方式，开发人员依据指派给一栏来排列bug,测试人员依据状态栏排列bug。把开发人员的名字留在报告里可以更容易地把bug返回给开发人员去做更多的工作。测试人员只需简单地把状态栏改成“已验证”，bug就自动地返回到开发人员那。
[ 本帖最后由 brilliantking 于 2010-3-1 21:21 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:42
标题: The Developer works on the bug…
The Developer works on the bug…
开发人员处理这个bug……
The first thing the developer does is give the bug a ‘In Progress’ status indicating that he has seen the bug and is aware that it his responsibility to resolve. The developer works on the bug and based on his conclusions assigns a status to the bug indicating what the next step should be.
开发人员首先要做的是把bug置为“处理中”的状态，以表明他已经看了这个bug报告，并且意识到有责任去解决这个bug。开发人员处理这个bug，并根据他的结论给bug指定一个状态来表明下一步的处理将是什么。
Remember, the developer does NOT change the Assigned To field. His name stays on the bug so if the bug has to go back to him, it will make back onto his list. This procedure ensures that bugs don’t fall between the cracks.
记住，开发人员不会改变指派给栏的值。他的名字保留在那一栏，所以如果bug需要返还给他，就会回到他的bug列表里。这个做法可以确保bug不被遗漏。
The following is a list of status’ that a developer can assign to a bug.
以下列出了一个开发人员可以赋予一个bug的所有状态：
Fixed
已修复
The Fixed status indicates that a change was made to the code and will be available in the next build. Testers search the database on a daily basis looking for all Fixed status bugs. Then the bug reporter or tester assigned to the feature retests the bug duplicating the original circumstances. If the bug is fixed and it is now working properly, another test with slightly different circumstances is performed to confirm the fix. If the bug passes both tests, it gets a Tested status.
“已修复”状态表明代码进行了改动并会用在下一个版本。测试人员按照日常的基本工作搜索数据库里所有“已修复”状态的bug。然后特征栏所指派的bug报告人或测试人员对bug重新测试来复现原有的现象。如果bug已经修复，现在运行良好了，另一种测试，略带不同的测试环境，将用来进一步确认bug是否已修复。如果两种测试都通过，bug就会被赋予“已测试”状态。
If the bug doesn’t pass the test, the bug is given a Verified status and sent back to the developer. Notice here that since the bug’s Assigned To field has retained the developer’s name, it’s an easy process for the tester to send the bug back by simply changing the status to Submitted.
如果bug没有通过测试，bug就会被赋予“已验证”状态并返回给开发人员。请注意由于指派给一栏保留了开发人员的名字，所以测试人员返回bug是一个简单的过程，只要简单地把状态栏改为“已提交”。
Duplicate
重复的
The Duplicate status bug is the same as a previously reported bug. Sometimes only the developer or person looking at the code can tell that the bug is a duplicate. It’s not always obvious from the surface. A note indicating the previous bug number is placed on the duplicate bug. A note is also placed on the original bug indicating that a duplicate bug exists. When the original bug is fixed and tested, the duplicate bug will be tested also. If the bug really is a duplicate of previous bug then the when the previous bug is fixed, the duplicate bug will also be fixed. If this is the case then both bugs get a Tested status.
被赋予“重复的”状态的bug与之前报的一个bug是一样的。有时只有开发人员或者查看代码的人才能分辨bug是重复的。从表面看并不总是明显的。表明前一个bug编号的注释被写在重复的bug报告里。同样地，最初的bug报告里也会加一个注释表明存在一个重复的bug。当最初的bug被修复了并测试了，重复的bug也会被测试。如果这个bug真是前一个bug的重复，那么当前一个bug修复了，重复的bug也将被修复。如果是这样的，两个bug都会被赋予“已测试”状态。
If the duplicate is still a bug, while the original bug is working properly, the duplicate bug is no longer has a duplicate status. It gets a Submitted status and is sent back to the developer. This is a “fail-safe” built into the bug life cycle. It’s a check and balance that prevents legitimate bugs from being swept under the carpet or falling between the cracks.
如果重复的依旧是一个bug，而最初的bug已经运行正常了，那么重复的bug不再是“重复的”状态。它被赋予“已提交”状态并返回给开发人员。这是用于bug生命周期里的安全防范措施。这是一种检查和弥补方法，防止合理的bug被忽略或被遗漏。
A note of warning. Writing lots of duplicate bugs will get a tester a reputation for being an “airhead”. It pays to set time aside daily to read all the new bugs written the previous day.
重要警告。写了太多重复的bug就会给测试人员一个“白痴”的坏名声。因此，每天留出一些时间来阅读前一天报的所有新的bug是值得的。
Resolved
已解决
Resolved means that the problem has been taken care of but no code has been changed. For example, bugs can be resolved by getting new device drivers or third ** software. Resolved bugs are tested to make sure that the problem really has been resolved with the new situation. If the problem no longer occurs, the bug gets a Tested status. If the Resolved bug still occurs, it is sent back to the developer with a Submitted status.
“已解决”意味着问题已经处理但代码没有修改。例如，bug可以通过安装新的设备驱动或第三方软件来得以解决。已解决的bug需要通过测试来确保问题确实在新的情况下解决了。如果问题不发生了，bug就会被赋予“已测试”状态。如果“已解决”的bug仍发生，它将以“已提交”状态返还给开发人员。
[ 本帖最后由 brilliantking 于 2010-3-1 21:24 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:46
标题: Need More Information
需要更多信息
Need More Information or “NMI” indicates that the bug verifier or developer does not have enough information to duplicate or fix the bug; for example, the steps to duplicate the bug may be unclear or incomplete. The developer changes the status to ‘Need More Information’ and includes a question or comments to the reporter of the bug. This status is a flag to the bug reporter to supply the necessary information or a demonstration of the problem. After updating the bug information (in the Notes field), the status is put back to Verified so the developer can continue working on the bug. If the bug reporter can not duplicate the bug, it is given a Can’t Duplicate status along with a note indicating the circumstances.
需要更多信息或“NMI”表明bug核实人员或开发人员缺乏足够的信息来复现或者修复这个bug。例如，重现bug的步骤可能不清楚或不完整。开发人员把状态改成“需要更多信息”并在bug报告里留下一个问题或注释。这个状态对bug报告人来说是一个重要标志，提醒他提供问题的必要信息或是一个说明。更新完bug信息（在注释栏）以后，bug状态重新置为“已核实”，这样开发人员可以继续处理这个bug。如果bug报告人员不能复现这个bug，这个bug将被赋予“不能重现”状态并留下一条注释来表明这个状况。
The only person who can put “Can’t Duplicate” on a bug is the person who reported it (or the person testing it). The developer can NOT use this status, he must put Need More Information on it to give the bug reporter a chance to work on the bug.
只有报告这个bug的人（或者测试这个bug的人）才可以将这个bug置为“不能复现”。开发人员不能使用这个状态，他必须把bug置为“需要更多信息”来给bug报告人处理这个bug的机会。
This is another example of a “fail-safe” built into the database. It is vital at this stage that the bug be given a second chance. The developer should never give a bug a ‘Can’t Duplicate’ status. The bug reporter needs an opportunity to clarify or add information to the bug or to retire it.
这是用于bug数据库的安全防范措施的另一个例子。在这个阶段给bug第二次机会是至关重要的。开发人员绝不可以把bug置为“不能重现”状态。Bug报告人需要一次机会来阐明或添加bug信息或者取消这个bug。
Working as Designed
符合设计
The developer has examined the bug, the product requirements and the design documents and determined that the bug is not a bug, it is Working as Designed. What the product or code is doing is intentional as per the design. Or as someone more aptly pointed out it’s “working as coded”! It’s doing exactly what the code said to do.
开发人员仔细检查了bug、产品需求和设计文档，确定这个bug不是一个bug，它是“符合设计”的。产品或者代码的功能是依据设计事先设定好的。或者像一些人更恰当地指出“与代码相符合”！Bug准确地按照代码来运行。
This bug can go several directions after being assigned this status. If the tester agrees with the status, then the status stands and the bug is finished. The bug may be sent to documentation for inclusion in help files and the manual. If the tester disagrees with the status then the bug can be appealed by putting a Submitted status on it to send the bug back through the process again. The tester should include in the notes a reason why, although it is Working as Designed, it should be changed now. The bug may also be sent back to the design committee so that the design can be improved.
这个bug在被置成这种状态后可以有几种去向。如果测试人员同意这个状态，那么状态保持不变，bug被结束了。这个bug可能被记录在帮助和手册的文档里。如果测试人员不同意这个状态，那么可以请求将这个bug置为“已提交”状态，并再次返回给开发人员。测试人员应该在注释中写明原因，虽然是“符合设计”的，但是现在应该有所改变。这个bug也可能被送至设计委员会，以便设计可以得到改善。
This is a dangerous status. It’s an easy way to sweep bugs under the carpet by giving them this status. It’s up to the bug reporter to make sure the bug doesn’t get forgotten in this manner. Product managers may also review lists of bugs recently assigned Working as Designed.
这是一个危险的状态。赋予bug这种状态很容易使bug被忽略。Bug报告人必须确保bug在这种方式下不会被忽略。产品经理也会查看近期被置为“符合设计”的bug清单。
Enhancement
增进
Enhancement means that while the suggested change is great idea because of technical reasons, time constraints or other factors, it won’t be incorporated into the code until the next version of the product.
This status may also be appealed by changing the status to Submitted and adding a note specifying why it should be fixed now.
“增进”状态意味着尽管建议改变是一个很好的想法，但是由于技术原因、时间限制或其他因素，只有等到产品的下一个版本出来，这种改变才会融入在代码里。这个状态可以通过将状态改为“已提交”来重新得到关注，并加上一条注释说明为什么bug需要现在修改。
Defer
推迟
Defer is almost the same status as Enhancement. This status implies that the cost of fixing the bug is too great given the benefits that it would produce. If the fix is a one liner to one file that doesn’t influence other files, it might be ok to fix the bug. On the other hand, if the fix will force the rebuild of many files which would force the re-testing of the product and there’s no time left to test the fix before shipping the product, then the fix would be unacceptable and the bug would get a Defer status. To appeal the status, send it back through the process again by putting a Submitted status on it and add a note saying why it should be fixed now.
[ 本帖最后由 brilliantking 于 2010-3-1 21:28 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:48
标题: Not to be Fixed
不予修复
You may see the Not to be Fixed status although I don’t recommend making this status available for use. There may be extenuating circumstances where a bug will not be fixed because of technology, time constraints, a risk of destabilizing the code or other factors. A better status to use is Not to be Fixed. To appeal the status, send it back through the process again by putting a Submitted status on it and add a note saying why it should be fixed now.
虽然我不建议采用这种状态，但是你仍可以看见“不予修复”这种状态。可能在一些情况下，因为技术、时间限制、代码的稳定性或其他因素，某个bug不会得到修复。在这种情况下，赋予这个bug“不予修复”的状态是更好的选择。为了使这个bug能得到关注，将bug状态置为“已提交”并再次返回开发处理，并添加一条注释说明为什么bug需要现在修改。
This is similar to the Working as Designed status in that its use can be dangerous. Be on the watch for this one. Sometimes developers call this status “You can’t make me”.
这种状态与“符合设计”状态类似，也是危险的状态。一定要注意这一状态。有时开发人员戏称此状态为“你拿我没办法”。
Tested
已测试
The Tested status is used only by testers on Fixed, Resolved and Duplicate bugs. This status is a “end of the road” status indicating that the bug has reached the end of its life cycle.
“已测试”状态只能由测试人员用于已修复、已解决和重复的bug。此状态是一个最终状态，表明bug已经到了其生命周期的终点。
挂起
The Pending status is used only by testers on Fixed bugs when a bug cannot be immediately tested. The tester may be waiting on hardware, device drivers, a build or additional information necessary to test the bug. When the necessary items have been obtained, the bug status is changed back to Fixed and then it is tested. Make sure the testing part isn’t skipped.
“挂起”状态是在bug不能得到立即测试的时候，只由测试人员用于“已修复”的bug。测试人员需要等待硬件、设备驱动、一个版本或附加的信息来测试这个bug。当这些需要的事项都可以获取了，bug状态就会被改回“已修复”状态，然后测试这个bug。必须确保测试环节没有被忽略。
不能重现
This status is used only by the bug reporter; developers or managers cannot use this status. If a bug isn’t reproducible by the assigned developer or bug verifier the bug reporter needs a chance to clarify or add to the bug. There may be a hardware setup or situation or particular way of producing a bug that is peculiar to only this computer or bug reporter and he needs a chance to explain what the circumstances are. Limiting this status to bug reporters only prevents bugs from slipping between the cracks and not getting fixed.
[ 本帖最后由 brilliantking 于 2010-3-1 21:29 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:50
标题: The product has shipped
The product has shipped, what happens next?
产品已经发布了，接下来会发生什么？
First of all, to ship a product the number of bugs rated 5 or less, bugs with a Fixed, Resolved, Pending or Need More Information status must be zero. We’ll assume that the product has shipped and all these bugs have been taken care of. This means the bugfile is full of bugs that have reached the end of their life cycle. Proper database maintenance takes place at this point. Archiving or hiding all these bugs will make the database easier to use and read.
首先，要发布一个产品，等级数小于等于5的，已修复、已解决、挂起以及需要更多信息等状态的bug的数量必须为零。我们假定产品已经发布，并且所有bug都得到妥善处理。这意味着bug数据库里充满了生命周期到达终点的bug。适当的数据库维护从这个时候开始了。归档或隐藏这些bug使数据库的使用和读取更加容易。
All bugs with a Tested or Can’t Duplicate bugs are archived. This means that the records are either removed and placed in an archive database or flagged to be hidden from the current view of the database. Never delete any bug records; it may be necessary to do some historical research in the bugfile (‘What did we ship when?’ or ‘Why did we ship with this bug?’).
所有“已测试”和“不能复现”的bug都进行了归档。这意味着这些bug的记录被转移至一个档案数据库或者被做上标记从当前的数据库界面隐藏了。绝不要删除任何bug记录。在bug档案里进行一些历史性的研究有时是必要的。（“那时我们发布了什么产品？”或者“我们为什么要发布带这个bug的产品？”）
Enhancement and Defer bugs are either moved to the new bugfile or retained in the current bugfile. The status of these bugs is then changed back to Verified.
增进和推迟状态的bug被转移至新的bug档案库或者保留在当前档案库里。这些bug的状态之后被改成“已核实”。
Advanced defect database techniques
高级的缺陷数据库技术
There are things you can do with your database to make it more than just a to-do list for developers and testers. The bugfile is basically raw data, sorting and filtering it makes the data information that is useful in the decision making process done by management. A couple of these things to do with the data is to create Reports and Customized views.
[ 本帖最后由 brilliantking 于 2010-3-1 21:30 编辑 ]
作者: brilliantking 时间: 2006-5-13 22:51
标题: Reports
报表
The data in the defect database is not very useful until it is sorted and presented in a organized fashion, then it becomes information. For example, sorting by developer, the information becomes a ‘to do’ list sorted by rating. Sorting by status lets the reader know how many bugs are submitted or in progress; i.e. how many bugs are currently being worked on? By feature – how many open bugs are there for a particular feature? What feature needs more work and what feature is stable? Sorting by product is useful when more than one product is being worked on simultaneously.
缺陷数据库里的数据只有经过排序，并有组织地显示出来，才能变得有用，才会变成信息。例如，按开发人员进行排序，信息就会变成按级别排序的“待办事项”列表。按状态排序可以让人了解有多少bug是“已提交”和“处理中”的状态。例如，眼下有多少bug正在处理？按功能——对于一个特定的功能有多少打开的bug？什么功能还需要更多处理而什么功能是稳定的？当同时处理多个产品时，按产品排序就很有用了。
Be aware that there are certain metrics or reports that should not be used. If you use these reports you will destroy the credibility of your bug file and it will be reduced to a “laundry-list” for developers. One of these reports is “how many bugs did a tester report” and the other is “how many bugs did a developer fix”. Neither one of these has any useful purpose except to beat up people uselessly. See Software Testing by Cem Kaner, et. al.
请注意某些报告形式或报表是不应该采用的。如果你使用这些报表，你将破坏你的bug档案的可信性，它会褪变成开发人员索然无味的细目清单。这些报表其中之一是“一个测试人员报了多少bug”，另一个是“一个开发人员修复了多少bug”
。这两者除了打击人们的积极性之外没有任何益处。请参考 Cem Kaner等写的《软件测试》一书。
报表样例
The Product Manager wants to see a list of bugs to be fixed before shipping that is sorted by rating to determine how ready the product is for shipping. He needs to know what work is left to be done so that an appropriate schedule can be set. The Test Lead needs a list of bugs to be tested before shipping, sorted by tester to make sure all the bugs get tested in the allotted amount of time. The Development Lead has a list of bugs to be resolved before shipping, sorted by developer so that adjustments in work load can be made to ensure that everything is taken care of by the deadline. Technical Support likes a list of bugs that were fixed and not fixed in the product before shipping so they can adequately prepare to support the product. Technical support can resolve customer problems faster by knowing what has been fixed in a product release (the new release or upgrade will fix that problem) and what bugs are still in the product.
产品经理在产品发布之前需要一个按等级排列的已修复的bug列表来确定产品是否为上市做好了充足准备。他必须知道剩下的要完成的任务以便制定合适的工作计划。测试组长在产品发布之前需要一个按测试工程师名字排列的bug列表来确保所有bug在分配的一定时间里都已经测试过了。开发组长在产品发布之前需要一个按开发人员名字排序的待解决的bug列表，以便于开发人员调整工作量，以确保每一件事在最后期限到来之前都已经妥善处理。技术支持人员在产品发布之前需要一个已修复和未修复的bug列表以便他们可以对产品做出充分的技术支持。技术支持人员通过了解已发布产品里哪些bug已经修复（新的版本或版本升级后问题将会得以修复）和产品里仍存在哪些bug，来更快地解决客户的问题。
A defect database that has all these fields built into it is able to sort defect data and make it useful information.
如果一个数据库包含这所有字段，那么它就能对缺陷数据进行排序，使之变成有用的信息。
Customized views of the database
自定义数据库视图
If your defect tracking database supports it, you can limit the information seen based on who the person logging in is. For example, the database that I built with SQL Server 7 was web browser based. Each person was assigned a job category such as ‘Tester’, ‘Developer’ or ‘Manager’. The web page that displayed was then the web page designed for that job category. The Developer would see Submitted and In Progress bugs assigned to him while Testers would see all Fixed, NMI, Pending, Resolved, and Duplicate bugs regardless of who is assigned to the bug. The Product Manager view sees all bugs assigned to him, all newly reported bugs, and newly updated bugs.
如果你的缺陷跟踪数据库支持这一功能，你就可以依据是谁登录这个系统来限制信息的显示。比如，我用SQL Server 7构建的基于网页浏览器的数据库。每个人都被赋予了一个职务类别，如“测试人员”、“开发人员”和“经理”。网页显示的内容是依据职务类别来设计的。开发人员会看见指派给自己的已提交和处理中的bug，而测试人员会看见所有已修复、需要更多信息、挂起、已解决和重复的bug，不管bug是不是指派给自己的。产品经理会看见所有指派给他的bug，所有最近上报的和更新的bug。
The reason for this customized view is that each job views the defect database in a different way based on their needs and the work that has to be accomplished. Testers don’t care who the bug is assigned to, just what the status is. Testers want to see all the bugs, not just bugs written by them, with a ‘Fixed’ status so the bugs can be tested with the latest build. Developers only care about what current and active bugs are assigned to them; developers aren’t concerned about any other person’s bugs. Product managers are concerned that bugs don’t get ‘swept under the carpet’ with Enhancement or Defer status’ so managers want to see all bugs with that particular status.
建立自定义视图的原因是不同职务类别的人根据他们的需要和要完成的工作，以不同的方式浏览缺陷数据库。测试人员不会关心bug指派给了谁，而只在乎它的状态。测试人员想要看所有“已修复”的bug，而不只是他们自己写的bug，以便他们可以用最新版本测试这个bug。开发人员只关心当前指派给他们的有效的bug，他们并不关心别人的bug。产品经理会关注“增进”和“推迟”状态的bug是否被遗漏，因此他们需要浏览所有特殊状态的bug。
参考书目
Software Testing by Cem Kaner, et.al.
Software Testing in the Real World by Edward Kit
Software Test Documentation (IEEE 829-1983)
The Complete Guide to Software Testing by Bill Hetzel
The Art of Software Testing by Glenford J. Myers
Software Testing and Quality Assurance by Boris Beizer
Software Quality: Analysis and Guidelines for Success by Capers Jones
Software Testing Techniques by Boris Beizer
Software Testing by Ron Patton (2000, Sams, ISBN 0672319837). See chapters 18 and 19.
“Organize Your Problem Tracking System Cleaning up your bug database can be as easy as organizing your sock drawer” By Barry Mirrer.
[ 本帖最后由 brilliantking 于 2010-3-1 21:31 编辑 ]
作者: skinapi 时间: 2006-5-16 11:31
这篇文章老长的，多加点分鼓励一下。
作者: Erica 时间: 2006-5-16 13:12
鼓励
作者: brilliantking 时间: 2006-5-17 13:41
谢谢斑竹的鼓励！
本人已发九九八十一帖，因此暂告一段落，呵呵。
休息，休息一下！
作者: harold_zou 时间: 2006-5-17 18:37
精神可嘉
作者: donghuanzi 时间: 2006-5-18 15:27
标题: brilliantking太帅了。谢谢
分享知识是一种快乐。谢谢。永远支持你。。
作者: Erica 时间: 2006-5-18 16:52
用了两天时间终于看完了，非常棒的一篇文章，把处理一个bug所经过的过程写的很详细，收获很大，值得多次翻看。同时brilliantking 也翻译的相当准确。支持版主，支持brilliantking 。呵呵。
作者: 李逍遥 时间: 2006-6-16 16:17
都快崇拜了!
作者: tanbin2002 时间: 2008-2-12 17:19
这个文章很有用哦，谢谢楼主啊
作者: mujjk 时间: 2008-2-15 18:49
好文章！翻译的很不错！
感谢分享
作者: lovsnow 时间: 2008-2-19 16:52
这么长一篇文章翻下来确实不容易，而且质量很高，怎么说也要顶一下。
里面很多理论很实际，可以尝试使用下。
作者: zh4ang 时间: 2008-2-24 10:36
brilliantking太帅了
作者: yuanxun99 时间: 2008-6-7 13:45
楼主太崇拜你了！
作者: huoluo 时间: 2008-6-13 17:45
中英文对照着看真不错，楼主辛苦了!
作者: lx_yykl 时间: 2008-6-14 23:11
thank you
作者: lilianripe 时间: 2008-8-7 17:55
好长的文章，谢谢分享咯！
作者: tulongqing 时间: 2008-8-12 13:03
很好的东西
作者: barcelona 时间: 2008-8-16 15:22
in my compony the bug database is clairfy
作者: bluesmile1 时间: 2008-8-18 17:40
Good
作者: shiker2003 时间: 2008-8-26 11:27
标题: 感谢brilliantking ，谢谢你的无私奉献！
感谢brilliantking ，谢谢你的无私奉献！
作者: joy_liao 时间: 2008-10-22 23:00
标题: 辛苦啦
真的很不错,谢谢分享,辛苦!
作者: zhanghonglan 时间: 2008-11-19 13:38
强人啊！楼主！
太羡慕了，我什么时候才能达到这种境界啊！
作者: benmoon 时间: 2008-11-21 15:49
brilliantking，多谢你分享知识
作者: wanzhengqing 时间: 2008-11-24 13:52
顶了！
作者: weifei1031 时间: 2008-11-27 10:35
very goog,very strong!
作者: lilyhui 时间: 2009-9-17 10:23
标题: 很不错的文章
今天才有幸看到这么好的文章，也谢谢brilliantking的共享
作者: 木佳 时间: 2009-10-29 13:46
LZ辛苦了！
作者: 糖糖默 时间: 2009-11-3 11:33
lz真好
作者: ghj 时间: 2009-11-10 15:56
非常感谢！
作者: mentgmery 时间: 2009-11-10 16:13
我空间里有微软bug life cycle流程图,值得参考,大家去看看吧
作者: eeyiyu 时间: 2009-12-6 22:57
good article.
作者: annt7 时间: 2010-3-18 17:03
相当不错啊！辛苦了
作者: qixiannvhai 时间: 2010-4-26 16:43
支持brilliantking
作者: 静静1982 时间: 2010-4-28 13:37
还没看，一定拜读~~辛苦啦
作者: jingpeng1982 时间: 2010-4-30 10:37
谢谢分享
作者: xiaoxin36 时间: 2010-5-12 17:28
专家专家~~~~学习了~~~~
作者: Rita杨 时间: 2012-6-7 20:28
very good. Thanks.
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) |
Powered by Discuz! X3.2 |