Source: http://nckiki.cnblogs.com/articles/242821.html
This is a function.! ---OriginalDanny R. faught《But it's a feature!"--- KikiTranslated on2005/6/2
- A precise expected result should be recommended for the bug report.
- If you cannot change software behavior at the beginning, you can use the document as a way to make the bug report effective and possibly change developers' mood.
- Focus on the words and documents that describe error messages. Inconsistencies may provide clues about incorrect ideas.
"When I click File À Open , Application Program Crashed, cleared my hard drive, and kicked my cat ." This is a convincing bug report. You may not need to refer to the user manual to interpret the document. à open the feature creates a feature that harasses your pet. This feature is not a software design feature. However, the common and Low-severity errors that we often handle every day are not so clear, and the measures taken by the Organization are also unclear.
Become
Bug
Supporter When you submit a bug report, you become a supporter of the bug-Follow up the bug to see if the bug is located. This is your job. Your report writing method affects whether the software's behavior will be changed, whether the document will be changed to match the actual behavior, or whether errors will be ignored. Many bug reports that do not advocate precise operation are also easily overlooked. Think about this short bug report:
"When I use a command line without any parameters to start the software, I get an error of" incorrect file name "and the application is suspended ". Do testers who write this report want to have a specific default behavior for the command line without specifying parameters? Or the tester wants the document to better explain why at least one command line parameter is required? Or does she just want a better error message? Maybe she doesn't care what to fix, but wants a result that the user knows and the behavior matches the document? Let's take a look at four ways to improve the chance to modify the above bug report.
Change Behavior . "When I started the software with a command line without any parameters, I got an error with an" incorrect file name "and the application was terminated. On page 1 of the user manual, the system will use the default file 'foo. bat', so I expect that commands without parameters can be successfully executed ."
Change the document. "When I started the software with a command line without any parameters, I got an error with the" Wrong file name "and the application was interrupted. The user manual does not clearly explain that parameters for file names must be provided in the command line ."
Change the error message. "When I started the software with a command line without any parameters, I got an error with an" incorrect file name "and the application was terminated. We hope to add an error message that can better interpret the current situation, for example, 'no filename specified '."
Change the behavior and document. "When I started the software with a command line without any parameters, I got an error with an" incorrect file name "and the application was terminated. This scenario is not mentioned in the user manual, because it can hit users ."
Leverage document Imagine what will happen if they choose to ignore the mistakes you think need to be modified? I have a trick-I mean to make sure that developers can rethink the wrong method. The solution is to focus on documents and error messages. For example, I recently submitted an error message describing two different tools being tested in one operating system: PS and sweep (for more information, see "getting your fix" in Table 1 ). This error does not seem to indicate any faults that may affect system operations. Although it can cause confusion between internal and third-party developers who are using the system, it does not affect mainstream system users who cannot access the wrong program. Since I did not have a chance to give the document a role when reporting this issue for the first time (but it will work later), I just submitted it as a very low-severity error. A developer who serves outsourcing suppliers elsewhere asks me to explain why I saw an error as a response and ends with "We don't think it is an error. I don't want to know the cause of this error message-I just want it to be fixed! Therefore, I use one of my most proud bug support methods. In this way, I replied to the developer, "Please record this as the behavior that PS and sweep expected in the document ". Two days later, the response from the developer was not a document change and was made to remove the error. Code Change. Victory! Maybe the developer doesn't want to record this weird behavior in the document.
What happened just now? Of course, I don't really want to change the document. If the developer accepts my fear and modifies the document instead of the code, I mark the error as fixed because it is undeniable that it has been improved. Then I will submit another report about the bug that affects system availability due to spoofing errors. Maybe I will report a requirement for improvement. At this point, I only hope that the error can be fixed in a short time, but I know that I have at least tried my best. It should be mentioned that this method does not work if you do not have a good end user document. I used to spend a lot of time testing the detailed application system programming interfaces (APIS) specially compiled by developers ). Developers who work with me want to use this API document to replace the function description, so this extra motivation can make it accurate. If you do not have an end user's document, you still need to find other documents that may mention this behavior-maybe design documents or error messages.
Let them think For example, I reported a bug #3639 in abiword, a tool for open-source word processors (for more information, see the main description of the "triggering change" error in Table 1 ). In an earlier bug report (#3619), I have complained that abiword cannot import various types of HTML documents. Abiword only expects to import XHTML files, so it cannot import HTML files. Unless other plug-ins are installed, this error is disabled as an invalid error. Should I be happy with this result as a supporter of a bug? Of course not! I aimed at error messages that are easy to misunderstand. As a user who does not know how to import the HTML plug-in, I found the error message that caused confusion:
Abiword
Cannot open
D: \ foo.html
File. It is a false or invalid file. Because of this extra, I submitted the #3639 error, in which I suggest modifying the error message to (just adding a word ):
Abiword
Cannot open
D: \ foo.html
File. It is a false or invalid
XHTML
File. The first person who replied to the #3639 error said, "This may be a problem regarding whether the HTML or XHTML import tool is used to load files ." Aha! This is what I want. When considering this misleading error message, some people also realize that the software is not very correct. I raised a discussion about wording beyond the error information. Alas, but the final result of this error is closed because it is repeated with another error-#1406. I am not convinced that this is a correct decision, so I am a bug supporter-I want to keep sticking to #1406 error being disabled, because I need to verify and fix the #1406 error and solve my problem.
Advocate defense When writing a bug report, stop and think about whether there are some documents that you can use to compare the current performance. Read the error message carefully. Think about what the user will see and how the application system will execute. If you have good suggestions, let developers know the type of solution you want. In this way, your bug report can be more efficient. If you get a reply that you don't like from a developer (for example, "This is a feature of it !") And check whether the behavior is consistent with the existing prompts. You may use another method to describe the error and improve its chances of being repaired.
| Getting your fix |
Triggering change |
| when submitting a bug report, try to leverage the document and use the error information to fix the error. I submitted the "thread exited" error (some details have been processed ). Developers do not consider low-severity errors as problems. When I asked the developer to warn the user in the document that an error may pop up, he chose to fix the error-this is exactly what I want. summary : after killing a process, PS and sweep encounter the "thread exit" error. severity : low description : when trying to reproduce the #385 error, I found several such errors in PS: read on 51844: thread exited. I noticed that in a discussion about errors related to stress testing a few months ago, developers wanted to discover it, but we could not reproduce it. Now it is very easy to reproduce. 1. Start the foo program and load the data file appended to this bug report. 2. Click "log in". 3. A few seconds later, the foo program process will be cleared. 4. Run ps or sweep and you will see the "thread exited" error. This is complaining about the "foosry" process. The following is a snapshot before such a process disappears from the PS output and becomes an error. 51844 58143 testuser release 26 K foosrv the error stops after a while, generally less than one minute. The same error does not occur when the taskview program refreshes the process list. This error does not seem to have any harmful results. |
I submitted the following bug report about abiword HTML import. The developer replied that this is not an error because a plug-in is required to import HTML files. I changed the requirements based on an error message. This requirement caused a discussion of audit defects among developers-this is a step forward towards the right!Summary: When you try to open an HTML file, the error message is easy to misunderstand.ID3639Severity: LowDescription: This is because the Error #3619 is disabled. When I try to use the common filepopen mechanism to open a file with the extension of HTML (not XHTML), I get an error:Abiword cannot open D: \ foo.html. It appears to be a bogus or invalid document.I was told that abiword only expects XHTML, but the error message does not. In fact, it is a valid HTML document. A small change to the error message is a major improvement:Abiword cannot open D: \ foo.html. It appears to be a bogus or invalid XHTML document. |
Table 1
