The generation of current problems is mainly divided into iterations (function point problems account for the majority) and outer iterations (UI problems account for the vast majority): Inside the iteration: 1. After the requirement cross talk, the development suddenly needs to change the requirements in the development, and a temporary emergency modification is made, which leads to inconsistency with the test case of the test, resulting in a bill of lading. Later suggestion: During the development process, if there is a sudden business requirement error or change, you must only test and confirm the modification of the test case. 2. The developer misses the requirement point in the development, which leads to the inconsistency with the developed function when the test is executed according to the test case, so as to test the bill of lading. Later suggestion: This point needs to be checked by the developer himself in the development, executed according to the test use case, found inconsistencies, and changed in time. 3. Insufficient consideration of details or usage scenarios (such as: session failure, users can continue to operate and cause exceptions, unreasonable phenomena that users can still operate the document after the content is archived, user script injection, permission switching, Chinese and English environments) display, etc.); Later suggestions: For common usage scenarios, common UI problems, script injection problems, Chinese and English internationalization, and implementation where permissions need to be considered. Before development, strengthen the awareness of "style compatibility"\"script injection"\"use scenarios". 4. In the iterative process, there is less communication between different groups of development, resulting in no planning and extraction of common methods for similar functions, resulting in redundant code and low development efficiency; (for example: obtaining the current user User, obtaining the content of the html area, different import modules Wait) Later suggestions: people who are familiar with functional modules will refine the public method, and everyone will optimize it together, and the refiner will be responsible for maintenance.
Iterate SDV: 1. The later TVT test and UI test, these two stages are the high-incidence period of problem sheets, TVT is unavoidable, and the UI aspect needs to be improved. The UI is based on the previous high-fidelity pages, and the high-fidelity has almost no compatibility due to time or other reasons. In the later development, the development is often in a hurry, and the UI is not too concerned. Later suggestions: In the future, regardless of whether high fidelity is compatible with UI specifications such as compatibility. Development should try to deal with relevant aspects in the development process, and develop in strict accordance with UI specifications as time permits, so as to maximize the generation of UI problems in the later stage. degree of reduction. 2. Manually modify the introduction of the problem list. This is a problem that exists both inside and outside the iteration, but the probability of occurrence after the iteration is relatively high. At this time, the functions of each group have been integrated, and other modules will inevitably be moved during modification, which will inevitably be modified. other people's files. Later suggestions: (1) Think clearly about the modification plan before modifying, and don’t hold the mentality of thinking while modifying, so that it is easy to improve your own functions and bugs in other module functions. (2) Furthermore, after the modification, more verifications are required, and all related ones must be verified to ensure that no problems are introduced, so that the problem list can be modified in one step. This also reduces the regression failure rate. According to the distribution characteristics of problem types, we need to strengthen the skills in two aspects: One is: the skills of the front desk display (usually pay more attention to the content mentioned below). 1. CSS style compatibility; 2. Page layout optimization (the recommended layout uses DIV+CSS); 3. Page performance optimization; 4. JS exception handling; The second is: effective and timely communication skills Improve your own skills, write code with fewer bugs, strong compatibility, and high scalability to kill the problem in the cradle. On the road to becoming an excellent IT person... Looking forward to improving and improving in the next version
Lu: According to a level of analysis, there are two main types of current problems: 1. User Interface issues, involving: (1) Style problems (lack of style-related skills, mainly compatibility and style characteristics), a few are not done according to high fidelity. (2) Internationalization problem (in the previous development process, internationalization was not considered, and the English development environment was not displayed; at the same time, internationalization was not provided in time). There is also a lack of communication between test parties. (3) The performance of the page (without considering the DOM execution efficiency). What is the current understanding of DOM execution efficiency, and how to avoid the type of problems encountered later; (4) Some aspects of JS are lacking (script injection <frame processing and JS script processing>, understanding of asynchronous refresh,) What is the principle of frame processing for script injection? 2. The DSDP delivery quality entry standard does not meet the requirements (multiple integration dsdp has dysfunction)------->Improve integration pre-acceptance steps------>Add unit tests and acceptance tests
Depending on whether the above can prepare relevant training, topics can be: (1) Page styles, JS script injection, etc. (2) Optimization of page performance. (3) Robust and reasonable unit testing Zhang: According to the analysis provided by him, there are the following problems: 1. The code self-check is insufficient, the development time should be short, and there will be defects in the functional design, until the problem sheet is revised after comprehensive testing. 2. Code quality problems, repeated codes are not reused, and logically complex parts are not commented, which increases the difficulty of later modification. 2. The self-test coverage is not comprehensive, the page requirements are not strict, there are many page style and browser compatibility problems 3.junit implementation is not strict, fault tolerance is not high 4. The details of some requirements are not clear, and the programmer's own understanding is different from SE or testing, resulting in frequent changes later 5. The modification is not comprehensive, or there is no comprehensive test, which leads to the introduction of new problems Chang: Mentions development quality and development habits (involves how to improve code quality) 1. The development of demand points is omitted in the iterative development process; 2. Incomplete consideration of details or usage scenarios (unreasonable phenomena that users can still operate the document after the content is archived, user script injection, etc.); ------ > Noticing this reduces about 20DI.