CN111090590A - Game program test BUG detection method - Google Patents
Game program test BUG detection method Download PDFInfo
- Publication number
- CN111090590A CN111090590A CN201911323615.7A CN201911323615A CN111090590A CN 111090590 A CN111090590 A CN 111090590A CN 201911323615 A CN201911323615 A CN 201911323615A CN 111090590 A CN111090590 A CN 111090590A
- Authority
- CN
- China
- Prior art keywords
- bug
- developer
- tester
- game program
- detection method
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 23
- 238000012360 testing method Methods 0.000 claims abstract description 27
- 238000000034 method Methods 0.000 claims abstract description 20
- 230000007547 defect Effects 0.000 claims description 7
- 230000008569 process Effects 0.000 claims description 7
- 238000012790 confirmation Methods 0.000 claims description 3
- 238000012545 processing Methods 0.000 claims description 3
- 230000008439 repair process Effects 0.000 claims description 3
- 238000012827 research and development Methods 0.000 claims description 3
- 238000012937 correction Methods 0.000 abstract description 5
- 238000011161 development Methods 0.000 abstract description 4
- 230000018109 developmental process Effects 0.000 abstract description 4
- 238000013461 design Methods 0.000 abstract description 2
- 230000033772 system development Effects 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/60—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/60—Methods for processing data by generating or executing the game program
- A63F2300/6009—Methods for processing data by generating or executing the game program for importing or creating game content, e.g. authoring tools during game development, adapting content to different platforms, use of a scripting language to create content
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a game program test BUG detection method in the technical field of computers, which comprises the following steps of S1: submitting the BUG; s2: distributing BUG; s3: solving the BUG; s4: verifying the BUG; the method for detecting the BUG for testing the game program is reasonable in structural design, the development of the game is tested by adopting secondary detection, the primary detection is used for developing and detecting a system at the primary stage of the game development, so that the existence of the BUG can be found as soon as possible, the secondary detection is used for running and detecting on a real machine after the system development is completed, so that whether the missing BUG is not repaired is determined, the mutual matching of the primary detection and the secondary detection can greatly improve the speed of finding the BUG, and the correction cost of the BUG is reduced under the condition of ensuring the running safety of the game system.
Description
Technical Field
The invention relates to the technical field of computers, in particular to a BUG detection method for a game program test.
Background
The game test is part of the software test, and has the following common characteristics: the purpose of the test is to discover defects present in the software. Tests are all performed by a tester according to a product behavior description. The product behavior description may be a written specification, a requirement document, a product file, or a user manual, source code, or executable program for work. The existing program test BUG detection has a serious problem that the BUG speed is found to be low when the program test BUG is used, so that the running of a game system is influenced, and the correction cost of the BUG is increased.
Disclosure of Invention
The invention aims to provide a method for detecting a program test BUG (BUG test), which aims to solve the problems that the program test BUG provided by the background technology is low in speed when the BUG is detected in use, so that the operation of a game system is influenced and the correction cost of the BUG is increased.
In order to achieve the purpose, the invention provides the following technical scheme:
s1: submitting the BUG;
s2: distributing BUG;
s3: solving the BUG;
s4: and verifying the BUG.
Preferably, the submitting BUG: firstly, testing a program: when a tester submits the BUG, the description of the BUG information is detailed, comprehensive, clear and definite; 1. the use environment needs to be described, and the specific operation is carried out before the BUG appears; 2. capturing a JPG full-screen image, and uploading the image to a BUG library by using a BMP format; 3. packet capturing, wherein the packet capturing file needs to be uploaded to a BUG library; and (4) resubmission: BUG was submitted via meditation with post-submission BUG status of activated.
Preferably, the distribution of the BUG: when a tester submits the BUG, three columns of an important level, an appearance frequency and a priority level are filled; the developer processes the BUG, changes the state to 'return', or 'assigns' to the product department, and changes to 'confirmed' after the processing is completed, and the developer needs to perform necessary description and explanation, and when the state is changed, the developer needs to specify a specific receiver.
Preferably, the solving of the BUG: the developer describes the time of solving the BUG in the annotation, and if the specific version number is to be clarified, relevant confirmation information is added into the modified BUG annotation; if the BUG is in the 'off' state, the tester needs to be turned back again in the later test, the state of the BUG after being turned back is 'pull back', and the tester needs to perform one more operation, namely 'assign' to a specific research and development personnel.
Preferably, the verification of the BUG: regression BUG is very important to the tester, with three entrances and two exits, confirming non-defect problems: the submitted defect is that the developer is not in question or can not reproduce, and the developer is handed to the tester for regression; the tester confirms again, if the developer says, the problem is closed; if the non-developers say, the problems are reproduced due to fuzzy problem description or other reasons, the reasons are re-noted and transferred to the developers; confirming the repair problem: confirming the problem repaired by the developer again, and if the problem is confirmed to be repaired, closing the problem; if the problem is not passed, the problem is opened again and transferred to the developer; the BUG passing the acceptance check is in a closed state; the BUG state which is not passed by acceptance check is activated.
Compared with the prior art, the invention has the beneficial effects that: the method for detecting the BUG for testing the game program is reasonable in structural design, the development of the game is tested by adopting secondary detection, the primary detection is used for developing and detecting a system at the primary stage of the game development, so that the existence of the BUG can be found as soon as possible, the secondary detection is used for running and detecting on a real machine after the system development is completed, so that whether the missing BUG is not repaired is determined, the mutual matching of the primary detection and the secondary detection can greatly improve the speed of finding the BUG, and the correction cost of the BUG is reduced under the condition of ensuring the running safety of the game system.
Drawings
FIG. 1 is a block diagram of a first level detection architecture of the present invention;
FIG. 2 is a block diagram of a two-stage detection architecture of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The invention provides a BUG detection method for a game program test, which comprises the following steps:
s1: submitting the BUG;
s2: distributing BUG;
s3: solving the BUG;
s4: and verifying the BUG.
Submitting BUG: firstly, testing a program: when a tester submits the BUG, the description of the BUG information is detailed, comprehensive, clear and definite; 1. the use environment needs to be described, and the specific operation is carried out before the BUG appears; 2. capturing a JPG full-screen image, and uploading the image to a BUG library by using a BMP format; 3. packet capturing, wherein the packet capturing file needs to be uploaded to a BUG library; and (4) resubmission: BUG was submitted via meditation with post-submission BUG status of activated.
And (3) distributing BUG: when a tester submits the BUG, three columns of an important level, an appearance frequency and a priority level are filled; the developer processes the BUG, changes the state to 'return', or 'assigns' to the product department, and changes to 'confirmed' after the processing is completed, and the developer needs to perform necessary description and explanation, and when the state is changed, the developer needs to specify a specific receiver.
Solving the problem of BUG: the developer describes the time of solving the BUG in the annotation, and if the specific version number is to be clarified, relevant confirmation information is added into the modified BUG annotation; if the BUG is in the 'off' state, the tester needs to be turned back again in the later test, the state of the BUG after being turned back is 'pull back', and the tester needs to perform one more operation, namely 'assign' to a specific research and development personnel.
And (4) verifying the BUG: regression BUG is very important to the tester, with three entrances and two exits, confirming non-defect problems: the submitted defect is that the developer is not in question or can not reproduce, and the developer is handed to the tester for regression; the tester confirms again, if the developer says, the problem is closed; if the non-developers say, the problems are reproduced due to fuzzy problem description or other reasons, the reasons are re-noted and transferred to the developers; confirming the repair problem: confirming the problem repaired by the developer again, and if the problem is confirmed to be repaired, closing the problem; if the problem is not passed, the problem is opened again and transferred to the developer; the BUG passing the acceptance check is in a closed state; the BUG state which is not passed by acceptance check is activated.
The working principle is as follows: firstly planning a game direction, sending a task to a developer to write codes after the planning is finished, submitting a test to perform a first-level test after the codes are written to form a program, directly releasing a version if the tester does not find BUG in the test process, submitting the BUG to the developer through a Buddhist channel if the tester finds BUG in the test, correcting the BUG by the developer, verifying the corrected BUG, closing the BUG to release the version if the verification is passed, reactivating the BUG if the verification is not passed, submitting the BUG to the developer again to correct the BUG, releasing the version if the revision is passed, marking a serious grade if the revision is not passed, and then repeatedly submitting the BUG until the BUG is corrected; transferring the first-level test BUG to a real machine for testing after the first-level test BUG passes, and directly finishing the test if all the test BUG runs normally when a tester tests on the real machine to prove that no BUG exists; if the BUG is found, submitting the BUG again through the meditation channel, sending the BUG to developers, correcting the newly generated BUG by the developers, verifying the BUG after the correction is finished, directly ending the test if the BUG passes the verification, and repeatedly correcting after marking the serious grade if the BUG does not pass the verification until the BUG is corrected.
In the several embodiments provided by the embodiments of the present invention, it should be understood that the disclosed systems and methods may be implemented in other ways and that the system and method embodiments described above are merely illustrative, for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, the functional modules in the embodiments of the present invention may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part. It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.
The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (5)
1. A game program test BUG detection method is characterized in that:
s1: submitting the BUG;
s2: distributing BUG;
s3: solving the BUG;
s4: and verifying the BUG.
2. The method of claim 1, wherein the BUG detection method for testing the game program comprises: submitting BUG: firstly, testing a program: when a tester submits the BUG, the description of the BUG information is detailed, comprehensive, clear and definite; 1. the use environment needs to be described, and the specific operation is carried out before the BUG appears; 2. capturing a JPG full-screen image, and uploading the image to a BUG library by using a BMP format; 3. packet capturing, wherein the packet capturing file needs to be uploaded to a BUG library; and (4) resubmission: BUG was submitted via meditation with post-submission BUG status of activated.
3. The method of claim 1, wherein the BUG detection method for testing the game program comprises: and (3) distributing BUG: when a tester submits the BUG, three columns of an important level, an appearance frequency and a priority level are filled; the developer processes the BUG, changes the state to 'return', or 'assigns' to the product department, and changes to 'confirmed' after the processing is completed, and the developer needs to perform necessary description and explanation, and when the state is changed, the developer needs to specify a specific receiver.
4. The method of claim 1, wherein the BUG detection method for testing the game program comprises: solving the problem of BUG: the developer describes the time of solving the BUG in the annotation, and if the specific version number is to be clarified, relevant confirmation information is added into the modified BUG annotation; if the BUG is in the 'off' state, the tester needs to be turned back again in the later test, the state of the BUG after being turned back is 'pull back', and the tester needs to perform one more operation, namely 'assign' to a specific research and development personnel.
5. The method of claim 1, wherein the BUG detection method for testing the game program comprises: and (4) verifying the BUG: regression BUG is very important to the tester, with three entrances and two exits, confirming non-defect problems: the submitted defect is that the developer is not in question or can not reproduce, and the developer is handed to the tester for regression; the tester confirms again, if the developer says, the problem is closed; if the non-developers say, the problems are reproduced due to fuzzy problem description or other reasons, the reasons are re-noted and transferred to the developers; confirming the repair problem: confirming the problem repaired by the developer again, and if the problem is confirmed to be repaired, closing the problem; if the problem is not passed, the problem is opened again and transferred to the developer; the BUG passing the acceptance check is in a closed state; the BUG state which is not passed by acceptance check is activated.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911323615.7A CN111090590A (en) | 2019-12-20 | 2019-12-20 | Game program test BUG detection method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911323615.7A CN111090590A (en) | 2019-12-20 | 2019-12-20 | Game program test BUG detection method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111090590A true CN111090590A (en) | 2020-05-01 |
Family
ID=70395132
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911323615.7A Pending CN111090590A (en) | 2019-12-20 | 2019-12-20 | Game program test BUG detection method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111090590A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112416791A (en) * | 2020-11-30 | 2021-02-26 | 泰康保险集团股份有限公司 | System and method for processing defect information of test object |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080178154A1 (en) * | 2007-01-23 | 2008-07-24 | International Business Machines Corporation | Developing software components and capability testing procedures for testing coded software component |
| CN103150252A (en) * | 2013-03-04 | 2013-06-12 | 浪潮电子信息产业股份有限公司 | Method for improving system performance modification and verification efficiency |
-
2019
- 2019-12-20 CN CN201911323615.7A patent/CN111090590A/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080178154A1 (en) * | 2007-01-23 | 2008-07-24 | International Business Machines Corporation | Developing software components and capability testing procedures for testing coded software component |
| CN103150252A (en) * | 2013-03-04 | 2013-06-12 | 浪潮电子信息产业股份有限公司 | Method for improving system performance modification and verification efficiency |
Non-Patent Citations (1)
| Title |
|---|
| 王钧: "基于CMMI项目管理体系结合敏捷开发的研究与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112416791A (en) * | 2020-11-30 | 2021-02-26 | 泰康保险集团股份有限公司 | System and method for processing defect information of test object |
| CN112416791B (en) * | 2020-11-30 | 2023-10-31 | 泰康保险集团股份有限公司 | Defect information processing system and method for test object |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109271326B (en) | Cloud database testing method and device, equipment and storage medium thereof | |
| US8464222B2 (en) | Method, apparatus or software for identifying dependencies between components for a given build of a componentised product | |
| CN106446691A (en) | Method and device for detecting integrated or customized open source project bugs in software | |
| CN108614777A (en) | A kind of financial transaction test system and test method based on actual services | |
| EP1170667A1 (en) | Software package verification | |
| US11599453B2 (en) | Vehicle function test apparatus and method of controlling the same | |
| CN103019722B (en) | A kind of method and device extracting Java network application AKU | |
| US20100031237A1 (en) | Methods for Detecting Inter-Module Dependencies | |
| Fourneret et al. | Selective test generation method for evolving critical systems | |
| CN111090590A (en) | Game program test BUG detection method | |
| CN110780904A (en) | Application updating method and device | |
| CN111249743B (en) | Method and device for checking and submitting art resources | |
| CN110928782A (en) | Application security management method and device, electronic equipment and storage medium | |
| CN105653445A (en) | Implementation method capable of meeting DO-178C test result | |
| JP2005276040A (en) | Degrade confirming examining method and system, and program for the same | |
| CN115167896A (en) | Method and device for updating software version, storage medium and electronic equipment | |
| CN113577775A (en) | Method and device for checking art resource file, electronic device and storage medium | |
| CN113515452A (en) | Automatic test method and system for application, electronic equipment and storage medium | |
| Nicholas et al. | Fault detection model for software correctness and reliability | |
| JP6072547B2 (en) | Application test system | |
| JP2006092475A (en) | Source code inspection system | |
| US20220108020A1 (en) | Software code vulnerability remediation | |
| KR20200000684A (en) | Test unified administration system and Controlling Method for the Same | |
| CN109240737A (en) | A kind of method and system of the packing and issuing in big data platform | |
| CN106598857A (en) | Method and device for testing electronic equipment based on automatic testing tool |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20200501 |