Defect report generation method and device, storage medium and product

Abstract

This disclosure relates to a method, apparatus, storage medium, and product for generating defect reports. The method includes: updating a change log table in response to a change in the value of a first field in target defect data; acquiring snapshot data of a second field in the target defect data and updating a snapshot archive table based on the snapshot data; updating a problem analysis record table when it is determined that the value of a third field in the target defect data has changed; and generating a defect report for the target defect data based on the change log table, snapshot archive table, and problem analysis record table. This method updates the change log table, snapshot archive table, and problem analysis record table corresponding to the target defect data based on changes in different fields, achieving data updates at the field level. This allows for more accurate recording of the details of each change in problem attributes, making the generation of defect reports more precise and traceable, and providing solid data support for quality improvement.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a method, apparatus, storage medium, and product for generating defect reports. Background Technology

[0002] In the fields of software engineering, product testing, and defect management, Defect Index (DI) is an important indicator for measuring software quality. It reflects the combined impact of the severity and quantity of defects in a system.

[0003] In related technologies, the generation of defect reports often relies heavily on manual operation and subjective judgment. Personnel need to manually export defect data and related data from multiple disparate systems, and then summarize, filter, and integrate them using spreadsheets. This process is not only cumbersome and time-consuming, making it difficult to meet the pace of rapid development iterations, but also prone to introducing data errors and inconsistencies in statistical methods due to excessive human intervention, significantly compromising the accuracy and reliability of the reports. Summary of the Invention

[0004] The purpose of this disclosure is to provide a method, apparatus, storage medium, and product for generating defect reports.

[0005] To achieve the above objectives, in a first aspect, this disclosure provides a method for generating defect reports, the method comprising: In response to a change in the value of the first field in the target defect data, update the change log table; Obtain snapshot data of the second field in the target defect data, and update the snapshot archive table based on the snapshot data; If it is determined that the value of the third field in the target defect data has changed, update the problem analysis record table; Based on the change log table, snapshot archive table, and problem analysis record table, a defect report of the target defect data is generated; Based on changes to different fields, the change log table, snapshot archive table, and problem analysis record corresponding to the target defect data are updated, realizing data updates at the field level. This allows for more accurate recording of the details of each change in problem attributes, making the generation of defect reports more accurate and traceable.

[0006] Optionally, updating the problem analysis record table when the value of the third field in the target defect data has changed includes: The field value of each third field in the target defect data is compared with the field value of the historical field stored in the database; If at least one third field changes, update the problem analysis record table; By comparing the current value of the third field with its historical value, data changes can be captured accurately and automatically, improving the efficiency of data change tracking and the accuracy of log recording. Moreover, the problem analysis record table is only updated when an actual change is detected, ensuring that the record table only reflects the real data changes.

[0007] Optionally, updating the problem analysis record table if at least one third field changes includes: If at least one third field changes, the corresponding quality analysis indicator is determined based on the field value of the third field. Update the problem analysis record table based on the changed field values ​​and the quality analysis indicators; By automatically triggering the calculation of associated quality analysis indicators upon detecting a change in the third field, the original data changes can be directly transformed into analytical information. The problem analysis record table is updated based on the changed field value and the quality indicators, recording not only "what changed" but also "the degree of impact of the change," thus providing data support for the generation of subsequent defect reports.

[0008] Optionally, updating the snapshot archive table based on the snapshot data includes: If historical snapshot data of the target defect data does not exist in the snapshot archive table, add snapshot data of the target defect data to the snapshot archive table. If historical snapshot data of the target defect data exists in the snapshot archive table, update the historical snapshot data in the snapshot archive table to the current snapshot data; This ensures that only the latest state of each defect is retained in the snapshot archive table, and also avoids the accumulation of redundant historical data, effectively saving storage space.

[0009] Optionally, updating the change log table in response to a change in the value of the first field in the target defect data includes: The field value of the first field in the target defect data is compared with the historical field value of the first field in the database; If at least one of the first fields changes, the change log table is updated based on the changed field value; By comparing the real-time value with the historical value of the first field, data change events can be captured accurately and automatically without manual intervention. When a change in field value is detected, the change log table will be updated immediately and selectively, recording only the fields that have actually changed. This improves the efficiency of data change tracking and the accuracy of log recording, avoiding full data scanning and redundant recording.

[0010] Optionally, the problem analysis record table includes a project identifier, and the method further includes: In response to a change in the project to which the target defect data belongs, a new problem analysis record table is constructed, and the analysis record data of the most recent historical project is recorded in the new problem analysis record table; Recording the project identifiers of historical projects in the new problem analysis table ensures that the attribution of historical data and the statistical scope remain consistent, effectively solving the problem of data distortion caused by cross-project operations.

[0011] Optionally, generating a defect report based on the change log table, snapshot archive table, and problem analysis record table for the target defect data includes: Based on the snapshot archive table, determine the periodic statistical report of the target defect; Based on the change log table, snapshot archive table, and problem analysis record table, determine the processing indicator report for the target defect; Based on the aforementioned periodic statistical report and processing indicator report, a defect report for the target defect data is determined; By generating periodic statistical reports from snapshot archives, the evolution patterns, recurrence rates, and repair efficiency of defects can be revealed over time. Combined with change logs and problem analysis records, processing indicator reports can be generated, which can quantitatively evaluate defect handling performance from dimensions such as repair time and response time.

[0012] Secondly, this disclosure provides an apparatus for generating defect reports, the apparatus comprising: The first update module is configured to update the change log table in response to a change in the value of the first field in the target defect data; The second update module is configured to obtain snapshot data of the second field in the target defect data and update the snapshot archive table according to the snapshot data; The third update module is configured to update the problem analysis record table when it is determined that the field value of the third field in the target defect data has changed; The report generation module is configured to generate a defect report of the target defect data based on the change log table, snapshot archive table, and problem analysis record table.

[0013] A third aspect of this disclosure provides an electronic device, comprising: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method described in the first aspect of this disclosure.

[0014] Thirdly, this disclosure provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in the first aspect.

[0015] The above technical solution updates the change log table, snapshot archive table, and problem analysis record corresponding to the target defect data based on changes in different fields. This achieves data updates at the field level, thereby more accurately recording the details of each change in problem attributes. As a result, the generation of defect reports is more accurate and traceable, providing solid data support for quality improvement.

[0016] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating a method for generating a defect report according to an exemplary embodiment.

[0018] Figure 2 This is a flowchart illustrating a method for generating a defect report according to another exemplary embodiment.

[0019] Figure 3 This is a block diagram illustrating a defect report generation apparatus according to an exemplary embodiment.

[0020] Figure 4 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0021] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0022] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0023] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0024] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0025] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0026] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0027] In view of this, this application discloses a method for generating defect reports. Figure 1 This is a flowchart illustrating a method for generating a defect report according to an exemplary embodiment, the method including the following steps.

[0028] In step S110, the change log table is updated in response to a change in the field value of the first field in the target defect data.

[0029] Defect data refers to the collection of data generated during the entire lifecycle of software or project development, including issues, bugs, requirement changes, and tasks discovered through testing. Defect data records the problems and their statuses found during testing through multiple different fields and their corresponding values. These fields include, but are not limited to, defect type, severity, priority, status, submitter, fixer, creation time, update time, associated module, and reproduction steps. The values ​​of each field change dynamically as the defect lifecycle evolves.

[0030] Furthermore, the change log table records detailed information about every field value change during defect data updates or storage. In other words, the first field is mutable, including but not limited to categories, status, priority, severity, and reproducibility. The change log table can include information such as defect data ID, change time, attribute name, operator, field value before change, field value after change, and project ID. This change log table provides structured data support for defect tracking, analysis, and quality backtracking.

[0031] For example, the contents recorded in the change log table can be shown in the following table:

[0032] Table 1 As shown in Table 1, the change log table can use the defect ID as a unique index to associate each change record, ensuring that every state transition, responsibility transfer or priority adjustment can be traced back to the specific operator and the precise timestamp.

[0033] In step S120, snapshot data of the second field in the target defect data is obtained, and the snapshot archive table is updated according to the snapshot data.

[0034] Snapshot data refers to a data copy formed by statically capturing the complete state of target defect data at a specific point in time, including but not limited to information such as classification, data format, status, severity, reproducibility, and timestamps. Snapshot data can include all target defect data or only the second field. Snapshot data can be archived periodically for all fields or only for fields that have been updated. In this embodiment, snapshot data is archived for fields that have been updated. That is, a snapshot is only archived for a field if it has been updated, thus reducing the memory overhead of snapshot data.

[0035] The snapshot archive table is used to persistently store this type of snapshot data. Within the snapshot archive table, you can query the distribution of issues for a specified date based on the date, or determine the distribution of the defect data in the daily defect data based on the defect ID. You can also generate daily, weekly, and monthly statistical reports based on the dates in the snapshot archive table. Furthermore, you can analyze the distribution of each defect based on the dates of the snapshot data in the snapshot archive table to determine the evolution trend and handling efficiency of each defect at different stages.

[0036] Furthermore, the second field includes, but is not limited to, multiple fields such as status, severity, priority, reproducibility, etc. In the snapshot archive table, it may also include one or more fields such as defect ID, time information, category, whether it is resolved, whether it is closed, project ID, etc.

[0037] For example, a snapshot archive table can be shown in the following table:

[0038] Table 2 In Table 2, the snapshot archive table is automatically collected and stored in the database through daily scheduled tasks, ensuring the timeliness and integrity of the data. Furthermore, the snapshot archive table uses the defect ID as a unique index, which allows for correlation analysis between the defect ID and the change log table to accurately locate the triggering conditions and impact scope of each status change.

[0039] In step S130, if it is determined that the field value of the third field in the target defect data has changed, the problem analysis record table is updated.

[0040] The problem analysis record table can include information such as defect ID, time from defect data creation to first comment, time from unconfirmed change to pending resolution, number of reopens, resolution time of the target defect data (including cases where the defect data is determined not to be resolved), time from defect data creation to closure, number of defect data transfers, time of the last comment, list of defect data participants, and list of defect data comment participants. The problem analysis record table can also perform preliminary analysis of defect data based on the recorded data to reduce subsequent repetitive analysis. For example, it can calculate the average resolution time, average closure time, and number of reopens for defects within the project to which the defect data belongs. It can also determine the average response time based on the first comment time and confirmation time. Interaction metrics can be determined based on the average number of participants, average number of transfers, and average number of comments.

[0041] The third field includes, but is not limited to, fields such as the status, comments, flow, and movement / deletion of the target defect data. It is understood that the first, second, and third fields can be the same or different.

[0042] For example, the contents recorded in the problem analysis record table are shown in the table below:

[0043] Table 3 Based on the defect ID in Table 3, it can be associated with the change log table and snapshot archive table, thereby tracing the key operation nodes and version snapshots throughout the defect's lifecycle to support analysis and quality backtracking.

[0044] In step S140, a defect report of the target defect data is generated based on the change log table, snapshot archive table, and problem analysis record table.

[0045] The defect report includes, but is not limited to, information such as a defect overview, change trajectory map, root cause analysis conclusions, impact scope assessment, remediation suggestions, and quality improvement suggestions.

[0046] In this embodiment, by integrating the change log table, snapshot archive table, and problem analysis record table, the entire lifecycle data of the target defect data can be comprehensively presented from three dimensions: change trajectory, status snapshot, and quality analysis. The defect report generated by this multi-source data fusion not only restores the complete evolution process of the defect, but also provides a quantitative quality impact assessment.

[0047] In this solution, the change log table, snapshot archive table, and problem analysis record corresponding to the target defect data are updated based on changes in different fields. This achieves data updates at the field level, which can more accurately record the details of each change in problem attributes. As a result, the generation of defect reports can be more accurate and traceable, providing solid data support for quality improvement.

[0048] Figure 2 This is a flowchart illustrating a method for generating a defect report according to another exemplary embodiment, which may include the following steps.

[0049] In step S201, the field value of the first field in the target defect data is compared with the historical field value of the first field in the database.

[0050] In step S202, if at least one of the first fields changes, the change log table is updated based on the changed field value.

[0051] In this embodiment, the value of the first field is compared with its historical values ​​to identify the first field in the target defect data whose value has changed, thereby triggering a real-time update of the change log table. By comparing the real-time value with the historical value of the first field, data change events can be captured accurately and automatically without manual intervention. When a change in field value is detected, the change log table is updated immediately and selectively, recording only the fields that have actually changed. This improves the efficiency of data change tracking and the accuracy of log recording, avoiding full data scanning and redundant recording.

[0052] In step S203, a snapshot of the second field in the target defect data is obtained.

[0053] For a detailed explanation of step S203, please refer to the detailed explanation of step S120 in the foregoing embodiments, which will not be repeated here.

[0054] In step S204, if there is no historical snapshot data of the target defect data in the snapshot archive table, a new snapshot data of the target defect data is added to the snapshot archive table.

[0055] In step S205, if historical snapshot data of the target defect data exists in the snapshot archive table, the historical snapshot data in the snapshot archive table is updated to the current snapshot data.

[0056] In this embodiment, when snapshot data of the target defect data is obtained, it is first determined whether a historical snapshot corresponding to the defect ID or the date already exists in the snapshot archive table. If it exists, the historical snapshot data is updated to the current snapshot data to ensure that the archive table always reflects the latest state. If it does not exist, snapshot data for the date or defect ID is added, thereby constructing a complete defect lifecycle snapshot chain. This not only ensures that the snapshot archive table always retains only the latest state of each defect, but also avoids the accumulation of redundant historical data, effectively saving storage space.

[0057] In step S206, the field value of each third field in the target defect data is compared with the field value of the historical field stored in the database.

[0058] In step S207, if at least one third field changes, the problem analysis record table is updated.

[0059] In this embodiment, the value of the third field is compared with its historical values ​​to identify the third field whose value has changed in the target defect data, thereby triggering an update to the problem analysis record table. By comparing the current value of the third field with its historical values, data changes can be captured accurately and automatically, improving the efficiency of data change tracking and the accuracy of log recording. Moreover, the problem analysis record table is only updated when an actual change is detected, ensuring that the record table only reflects real data changes.

[0060] In some implementations, updating the problem analysis record table if at least one third field changes includes: if at least one third field changes, determining the corresponding quality analysis indicator based on the field value of the third field; and updating the problem analysis record table according to the changed field value and the quality analysis indicator.

[0061] Among them, quality analysis indicators refer to quantitative parameters that measure dimensions such as defect severity, repair timeliness, and recurrence rate. When a change is detected in the third field, the target defect data will be initially analyzed based on the changed third field, thereby triggering dynamic updates of the corresponding quality analysis indicators. For example, if the third field is "Defect Status" and changes from "Pending" to "Repaired," it can trigger the automatic calculation of the repair timeliness indicator and determine the quality analysis indicators.

[0062] In this embodiment, by automatically triggering the calculation of associated quality analysis indicators after detecting a change in the third field, the original data change can be directly transformed into analytical information. The problem analysis record table is updated based on the changed field value and the quality indicators, recording not only "what changed" but also "the degree of impact of the change," thus providing data support for the generation of subsequent defect reports.

[0063] The problem analysis record table includes a project identifier. In other embodiments, the method further includes: in response to a change in the project to which the target defect data belongs, constructing a new problem analysis record table and recording the analysis record data of the most recent historical project identifier in the new problem analysis record table.

[0064] Among them, the project identifier is a unique code that identifies the life cycle of a project and is used to distinguish the data boundaries of different projects.

[0065] In this implementation, when the project to which the target defect data belongs changes, a new problem analysis record table is created for the new project to better record the defect data of the new project. Since the problem analysis record table is rebuilt due to the project change, the project identifier of the historical project is recorded in the new problem analysis table to better trace the historical analysis context, ensuring that the historical data attribution and statistical scope remain consistent, effectively solving the data distortion problem caused by cross-project operations.

[0066] For example, defect data 1 might belong to project A during the development and testing phase, with project ID A corresponding to defect data 1. During the acceptance phase, it might be transferred to project B. To better trace the historical analysis of defect data 1, the historical project ID can be recorded in the issue analysis table of project B. When analyzing defect data 1, the historical project ID can be accurately determined from the issue analysis table, and historical data can be identified based on this historical project ID. It is understood that the data in the historical project ID is stored separately and is not overwritten by data in the new project ID.

[0067] In step S208, the periodic statistical report of the target defect is determined according to the snapshot archive table.

[0068] The periodic statistical reports can be daily, weekly, monthly, or yearly, with the period determined based on actual needs. Daily reports can be grouped based on the time of each snapshot in the snapshot archive table to statistically analyze the distribution of daily defect data, the changing trends of values ​​in each field within each defect, or the distribution of the corresponding status of each defect. Weekly reports aggregate snapshot data from a week, integrating it based on time windows to determine key indicators such as defect evolution patterns, repair efficiency, and recurrence rates. Similarly, monthly and yearly reports aggregate monthly and yearly snapshot data, respectively, allowing for trend analysis based on the time information of the snapshot data to identify patterns in defect frequency, repair cycles, recurrence patterns, and the number of closed or resolved issues.

[0069] Understandably, both daily and weekly statistical reports are based on the snapshot acquisition time in the snapshot archive table.

[0070] In step S209, the processing index report for the target defect is determined based on the change log table, snapshot archive table, and problem analysis record table.

[0071] The processing metrics include, but are not limited to, defect repair time metrics, first response time metrics, and average processing metrics.

[0072] In this embodiment, by integrating data from the change log table, snapshot archive table, and issue analysis record table, the entire lifecycle trajectory of a defect, from its introduction to its resolution, can be presented comprehensively and in a coherent manner. The report generated by this multi-dimensional joint analysis not only shows the specific changes to fields and the current snapshot, but also reveals the quality impact behind these changes.

[0073] In step S210, based on the periodic statistical report and the processing index report, a defect report for the target defect data is determined.

[0074] In this embodiment, a comprehensive health score for the target defect can be determined based on periodic statistical reports and processing indicator reports, and a visual trend chart can be generated. This score integrates information such as periodic recurrence rate, repair timeliness, number of closed issues, and number of resolved issues. A defect early warning mechanism for the target defect can also be determined based on periodic statistical reports and processing indicator reports, automatically triggering multi-level warnings when the health score falls below a threshold. Furthermore, a defect report for the target defect data is determined based on the comprehensive health score and the defect early warning mechanism. Periodic statistical reports are generated through snapshot archive tables, revealing the evolution pattern, recurrence rate, and repair efficiency of defects over time. Combined with change logs and issue analysis record tables, processing indicator reports are generated, which can quantitatively evaluate defect handling performance from dimensions such as repair duration and response time.

[0075] In the specific implementation process, when a user submits comment data regarding the target defect data, the system calculates analysis data based on the submitted comment data and records this analysis data in the problem analysis record table. This facilitates subsequent analysis based on the problem analysis record table and the generation of defect reports. It is understood that the comment data includes, but is not limited to, the user's subjective evaluation of the defect data, repair suggestions, descriptions of reproduction steps, and priority feedback. Based on the comment data, the actual impact range of the defect data can be determined. When a user does not submit comment data based on the target defect data, to better objectively evaluate the target defect data, the system continuously monitors whether the project ID, the first field, the second field, and the third field in the target defect data have changed. If the project ID remains unchanged but the first field changes, the change log table is updated. If the second field changes, a snapshot of the changed second field is obtained and the snapshot archive table is updated. If the third field changes, the problem analysis record table is updated synchronously. A defect report for the target defect data is then generated based on the change log table, the snapshot archive table, and the problem analysis record. If the project ID changes, first create a new issue analysis record table based on the new project ID, and record the historical project ID in the new issue analysis record table. This facilitates cross-project tracing and impact chain analysis based on the historical project ID during subsequent analysis. Under the new project ID, confirm whether the first, second, and third fields have changed, and perform corresponding data update and archiving operations based on their changes, and generate corresponding defect reports to ensure that defect data maintains traceability, consistency, and integrity during project migration.

[0076] This solution achieves refined tracking of defect data throughout its entire lifecycle by constructing three core data tables: change log, snapshot archive, and problem analysis. It automatically detects field changes and triggers real-time updates to the corresponding data tables, ensuring that archived data always reflects the latest status while avoiding redundant records. Furthermore, it can not only generate periodic statistical reports based on the time dimension but also integrate multi-source data to output comprehensive processing indicator reports, ultimately forming a defect report that integrates health scoring and early warning mechanisms.

[0077] Based on the same inventive concept, this disclosure also provides a defect report generation apparatus. Figure 3 This is a block diagram illustrating a defect report generation apparatus according to an exemplary embodiment. Figure 3 As shown, the defect report generation device 300 may include a first update module 310, a second update module 320, a third update module 330, and a report generation module 340, wherein, The first update module 310 is configured to update the change log table in response to a change in the field value of the first field in the target defect data; The second update module 320 is configured to obtain snapshot data of the second field in the target defect data and update the snapshot archive table according to the snapshot data; The third update module 330 is configured to update the problem analysis record table when it is determined that the field value of the third field in the target defect data has changed; The report generation module 340 is configured to generate a defect report of the target defect data based on the change log table, snapshot archive table, and problem analysis record table.

[0078] In one possible implementation, the third update module 330 is further configured to compare the field value of each third field in the target defect data with the field value of a historical field stored in the database. If at least one third field changes, the problem analysis record table is updated.

[0079] In one specific implementation, the third update module 330 is further configured to determine the corresponding quality analysis index based on the field value of the third field if at least one third field changes. Update the problem analysis record table based on the changed field values ​​and the quality analysis indicators.

[0080] In one possible implementation, the second update module 320 is further configured to add snapshot data of the target defect data to the snapshot archive table if historical snapshot data of the target defect data does not exist in the snapshot archive table; If historical snapshot data of the target defect data exists in the snapshot archive table, the historical snapshot data in the snapshot archive table will be updated to the current snapshot data.

[0081] In one possible implementation, the first update module 310 is further configured to compare the field value of the first field in the target defect data with the historical field value of the first field in the database; If at least one of the first fields changes, the change log table is updated based on the changed field value.

[0082] In one possible implementation, the defect report generation device 300 further includes a project change module configured to, in response to a change in the project to which the target defect data belongs, construct a new problem analysis record table and record the analysis record data of the most recent historical project identifier in the new problem analysis record table.

[0083] In one possible implementation, the report generation module 340 is further configured to determine a periodic statistical report of the target defect based on the snapshot archive table; Based on the change log table, snapshot archive table, and problem analysis record table, determine the processing indicator report for the target defect; Based on the periodic statistical report and the processing indicator report, the defect report of the target defect data is determined.

[0084] Figure 4 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Figure 4 As shown, the electronic device 400 may include a processor 401 and a memory 402. The electronic device 400 may also include one or more of a multimedia component 403, an input / output (I / O) interface 404, and a communication component 405.

[0085] The processor 401 controls the overall operation of the electronic device 400 to complete all or part of the steps in the defect report generation method described above. The memory 402 stores various types of data to support the operation of the electronic device 400. This data may include, for example, instructions for any application or method operating on the electronic device 400, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 402 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 403 may include a screen and audio components. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 402 or transmitted via communication component 405. The audio component also includes at least one speaker for outputting audio signals. I / O interface 404 provides an interface between processor 401 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 405 is used for wired or wireless communication between the electronic device 400 and other devices. Wireless communication may include Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination thereof; therefore, the corresponding communication component 405 may include a Wi-Fi module, a Bluetooth module, or an NFC module.

[0086] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the defect report generation method described above.

[0087] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the defect report generation method described above. For example, the computer-readable storage medium may be the memory 402 including the program instructions described above, which may be executed by the processor 401 of the electronic device 400 to complete the defect report generation method described above.

[0088] In another exemplary embodiment, a computer program product is also provided, which includes a computer program executable by a processor, which, when executed by the processor, implements the steps of the defect report generation method described above.

[0089] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0090] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0091] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A method for generating a defect report, characterized in that, The method includes: In response to a change in the value of the first field in the target defect data, update the change log table; Obtain snapshot data of the second field in the target defect data, and update the snapshot archive table based on the snapshot data; If it is determined that the value of the third field in the target defect data has changed, update the problem analysis record table; Based on the change log table, snapshot archive table, and problem analysis record table, a defect report of the target defect data is generated.

2. The method for generating a defect report according to claim 1, characterized in that, The step of updating the problem analysis record table when the value of the third field in the target defect data has changed includes: The field value of each third field in the target defect data is compared with the field value of the historical field stored in the database; If at least one third field changes, the problem analysis record table is updated.

3. The method for generating a defect report according to claim 2, characterized in that, If at least one third field changes, the problem analysis record table is updated, including: If at least one third field changes, the corresponding quality analysis indicator is determined based on the field value of the third field. Update the problem analysis record table based on the changed field values ​​and the quality analysis indicators.

4. The method for generating a defect report according to claim 1, characterized in that, The step of updating the snapshot archive table based on the snapshot data includes: If historical snapshot data of the target defect data does not exist in the snapshot archive table, add snapshot data of the target defect data to the snapshot archive table. If historical snapshot data of the target defect data exists in the snapshot archive table, the historical snapshot data in the snapshot archive table will be updated to the current snapshot data.

5. The method for generating a defect report according to claim 1, characterized in that, The step of updating the change log table in response to a change in the value of the first field in the target defect data includes: Compare the field value of the first field in the target defect data with the historical field value of the first field in the database; If at least one of the first fields changes, the change log table is updated based on the changed field value.

6. The method for generating a defect report according to any one of claims 1-5, characterized in that, The problem analysis record table includes a project identifier, and the method further includes: In response to a change in the project to which the target defect data belongs, a new problem analysis record table is constructed, and the analysis record data of the most recent historical project is recorded in the new problem analysis record table.

7. The method for generating a defect report according to any one of claims 1-5, characterized in that, The defect report generated based on the change log table, snapshot archive table, and problem analysis record table, including: Based on the snapshot archive table, determine the periodic statistical report of the target defect; Based on the change log table, snapshot archive table, and problem analysis record table, determine the processing indicator report for the target defect; Based on the periodic statistical report and the processing indicator report, the defect report of the target defect data is determined.

8. A defect report generation apparatus, characterized in that, The device includes: The first update module is configured to update the change log table in response to a change in the value of the first field in the target defect data; The second update module is configured to obtain snapshot data of the second field in the target defect data and update the snapshot archive table according to the snapshot data; The third update module is configured to update the problem analysis record table when it is determined that the field value of the third field in the target defect data has changed; The report generation module is configured to generate a defect report of the target defect data based on the change log table, snapshot archive table, and problem analysis record table.

9. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory, wherein the processor, when executing, implements the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-7.

Images