In late April 2004, the post-project staff entered the development site and participated in the finishing work of the software project. From the parties to cooperation, it is necessary to meet customer satisfaction, this is a must. For project staff is a rare opportunity, but it is also a hard test. (100 words omitted.) The B vot is a document recorded, both as a process document, and as a result document. It is technically said that it is a basis for the amendment process; from management, it is the basis for calculating the working hours. Of course, B votes are not the only reference, but it is very important. One month, in addition to the rest day, put in the working day 25 days, including 5, modified 29 B votes, and the code line is about 2500. Because bugs are randomly, it is not easy to master the daily work range. It is more tired. It will get up at 12 o'clock in the day, but it is good, customers are more satisfied with the quality of programming, and to remember to remember Several bugs. In the case of not choosing, listed several numbers and make basic analysis. BUG NO.1: Introduction: An editing screen of a data sheet information, users can fill in data in several input boxes, or you can make some existing data from existing data from the existing data to make some existing data, buttons There is a drop-down frame next to it to select the source data name to copy. Error: When the text in the drop-down box contains a single quotation mark, click the button to display a system error. Process: First, this error will be reproduced, discovering that it is not single quota, but there will be an error when there is accidental. This problem has been plagued two or three hours, and finally found an error as long as the buttons of the continuous point. Analysis: This error is worth a summary that the purpose of the test is not to prove the procedure correct, and we find errors, and we focus on the former, do not do too much strict testing for your own procedures, or unwilling to destructive testing. From the coded, the comment is not enough, but the logic is clear, the layout is neat, and the written main key for DB is written (the picture is not migrated, using the last ID), causing the BUG, only reflecting the insufficient experience So similar errors can be completely avoided in future items. Bug No.2: Error: The HTML picture should be 2 lines 2 columns, the result is that the first line is 3 columns, and the second line is 2 columns. Analysis: Such bugs are very provincial things for modifications, but thinking about it is also avoidable, as long as the programmer knows what the last result should be, and you can avoid it on the browser. BUG No.3: Introduction: Screen 1 corresponds to a record of a data table, on the upper button, and opens a plurality of records associated with this record. A record of the latest update date with the associated record has a preceding date, requiring it to compare and prompt, respectively. Error: The encoding missed this content. Analysis: It may take an hour during the encoding period, but it used to use 5.5 hours, the result is a modification file 3, code 23 line. This problem needs to be checked out when browsing the code. Bug No.4: Introduction: The function of the design book is missing. Analysis: This bug test code is maintainable, read the source code, because the notes are not enough, spend a lot of time DEBUG and analyze the source code. Because the large-scale development phase has passed, only a few people stay in later maintenance, and they must be exposed to the code completed by others. The source annotation is not enough, so it is more clear at the level, and the part needed to increase is in one way, so that it can be clearly manifested.
When this part of the function is added, several small methods are written, and then add two or three lines at the call. This shows that the method of writing is conducive to the program maintenance. However, pay attention to defining a constant and specification annotation, which is beneficial to the revision. So you have to write a maintenanceable code. The above BUG reflects only a small portion and the encoding information. From the actual situation, it can be avoided by 10%, and there is a large increase in space during the encoding. How to treat bugs? The simplest idea is to find the problem, check the impact range, and the modifications are completed. But how is the project treated? If this problem is very common, investigate all services with the same features, enumerate it. Then control one by one, uniformly. This problem is actually noted, but whether these work should be done, first, you must see that this bug has not been eliminated, ensuring the progress of the task, followed by the list of relevant commonality, without a one-glance A summary table, this is probably a place worthy of humility.
