A FIFO-based software test task management system

Abstract

The application discloses a FIFO-based software test task management system, which is divided into a user interface layer, a business logic layer and a data-based persistence layer, the business logic layer maintains two aspects of queues, one is a software queue in process, which maintains all configuration item software in process in a software evaluation center, and the other is a task queue of each user. The application can make software test task allocation and development state more intuitive, greatly reduce the difficulty of project management of the software evaluation center, and make software test task allocation more scientific and reasonable.

Description

Technical Field

[0001] This invention relates to a software testing task management technology in the aviation field, and specifically to a FIFO-based software testing task management system. Background Technology

[0002] Over the past 30 years, driven by the development of avionics technology and demand, avionics systems have experienced rapid growth. As the most important system component in an aircraft, avionics systems play an increasingly vital role. With the development of avionics systems towards integration and modularity, the size of their software code has grown exponentially. Consequently, numerous flight quality problems have arisen due to software issues, making the safety and reliability of avionics systems crucial to aircraft safety. Therefore, thorough software testing of all components, subsystems, and configuration items within avionics systems is of paramount importance.

[0003] As a professional software testing organization, the number of software testing tasks received by the software testing center in recent years has increased exponentially in terms of both the number of configuration items and the size of the code. This has significantly increased the difficulty of project management for the software testing center. How to scientifically and rationally allocate testing tasks under limited human resources has become an urgent problem for the software testing center to solve. Currently, after receiving new testing tasks, the person in charge assigns them to the corresponding testing teams according to the software's functional type, and then assigns specific testers. Because there is no unified platform to manage these testing tasks, the person in charge lacks a clear understanding of the current task allocation and project progress when allocating tasks. This easily leads to uneven task allocation, task backlog, and even a decline in test quality due to rushing to meet deadlines. Testers also lack a unified standard for judging the priority of their assigned tasks, resulting in a high degree of arbitrariness. Summary of the Invention

[0004] The purpose of this invention is to provide a FIFO-based software test task management system that sorts software test tasks and can reorder them in special cases, thereby reducing the difficulty of software test task management and making the allocation of software test tasks more scientific and reasonable.

[0005] The objective of this invention is achieved through the following technical solution:

[0006] A FIFO-based software testing task management system is divided into a user interface layer, a business logic layer, and a data persistence layer. The business logic layer includes a queue management module, which maintains two types of queues: one is the in-process software queue, which maintains all the configuration software in progress in the software testing center, arranged in the order of execution of the enqueue operation; the other is the task queue for each user, which is sorted in descending order of the test priority of the tester to which the user belongs.

[0007] When a software testing task for a certain configuration item needs to be given higher testing priority, a "software skipping" request is made. Upon receiving the "software skipping instruction" and the software ID to be skipped from the user interface layer, the queue management module initiates a "software skipping" process instance through the integrated Activiti. After approval, the business logic layer executes the software skipping operation. First, it calls the persistence layer interface to retrieve all relevant users for the software based on the software ID. Then, it iterates through all relevant users, placing the configuration item software at the head of each user's "task queue." If a relevant user's "task queue" already contains a configuration item software that has already performed "software skipping," it is inserted after all configuration items that have performed "software skipping" and before all configuration items that haven't performed "software skipping." If the configuration item software itself has already performed "software skipping," it is directly inserted at the head of all relevant users' "task queues," and the task queues after skipping are saved to the database.

[0008] Preferably, when the configuration item software is initially created, it is in an unqueued state. When the test conditions are met, the "software enqueue" is triggered. After receiving the "enqueue operation instruction" and the software ID to be enqueued from the user interface layer, the queue management module determines whether the enqueue conditions are met. If not, it returns a prompt message and exits. If the enqueue conditions are met, it first obtains all relevant users of the configuration item software, then iterates through all users, obtains the user's "task queue" for each user, adds the configuration item software to the tail of each user's "task queue", and adds it to the tail of the "in-process software queue". Then, it calls the persistence layer interface to save it to the database, finally generates a unique software ID, modifies the software status, and saves the software information.

[0009] Preferably, the queue management module integrates a scheduled task created by Quartz. This scheduled task scans the status of all configuration item software during idle periods. If a configuration item software remains in a "waiting" state for more than a set period, a software dequeue operation is automatically triggered. First, all relevant users of the software are retrieved based on the software ID. Then, all users are iterated through. For each user, the persistent layer interface is called to retrieve the task queue for each user. The configuration item software is changed to an "invalid" state, removed from the in-progress software queue and task queue, and restored to its initial state until the "software enqueue" operation is performed again. If the configuration item software test is completed / aborted, the configuration item software is changed to a "completed" or "aborted" state, removed from the in-progress software queue and task queue. The in-progress software queue and task queue are saved to the database. Finally, the software ID is canceled and the configuration item software status is modified.

[0010] Preferably, the business logic layer also includes a status reporting module, which allows users to update the testing status and progress of the configuration items in their "task queue".

[0011] Preferably, the business logic layer also includes an information viewing module. The information viewing module has a comprehensive display area. It calls the persistence layer interface to obtain the data information and distribution information of the software queue in progress, and then returns it to the user interface layer for rendering and display. The real-time data of the task scale, task distribution, development trend and personnel allocation of the software testing center are displayed in the form of numbers and charts.

[0012] Preferably, the information viewing module has a software queue area. It calls the persistence layer interface to retrieve software list data according to the status, and then returns it to the user interface layer for rendering and display. The detailed data of the configuration item software in the "in queue", "pending to be enqueued", and "completed / aborted" statuses are displayed in list form. The "in queue" list has "software", "project" and "model" perspectives to meet the query needs of different roles.

[0013] Preferably, the information viewing module has a personnel list area, which calls the persistence layer interface to obtain the user list, then retrieves the task data of each user from the task queue, and returns it to the user interface layer for rendering and display. From the user's perspective, it centrally displays the current task status of all users under the organization of the software testing center and the test tasks they are focusing on.

[0014] Preferably, the business logic layer also includes a report generation module, which integrates Apache POI to generate Office documents and supports the generation of personal work reports, software progress reports, project progress reports, team work reports, and center work reports.

[0015] Preferably, the business logic layer also includes an organization management module. The organization management module calls the persistence layer interface to operate on the relevant information of users, organizations, and roles in the database based on the instructions related to users, organizations, and roles input by the user interface layer, and feeds back the execution structure to the user interface layer for display, thereby realizing user management, organization management, and role management.

[0016] Preferably, the business logic layer also includes a project management module, which is used to create, edit, delete, and view projects, and to control project operation permissions according to roles and whether the user is a project team member.

[0017] The beneficial effects of this invention are as follows:

[0018] This invention provides an effective software testing task management system that makes the allocation and implementation status of software testing tasks more intuitive, significantly reducing the difficulty of project management in software testing centers and making the allocation of software testing tasks more scientific and reasonable. Managers can use various formats such as graphs, text, tables, and reports to more intuitively understand the current operation of the software testing organization, including the distribution of software testing tasks, project progress, and project manpower distribution. This provides strong data support for decision-making, scientifically arranging testing tasks, optimizing manpower allocation, and assessing the development trend of task scale. Project members have a clearer understanding of their individual task queues and priorities, making their work more organized. This system has important guiding significance for their reasonable work planning and clear work objectives, enabling them to carry out their work more responsively, accurately, and efficiently, ultimately improving the quality of software testing. Attached Figure Description

[0019] Figure 1 The software hierarchical architecture diagram of this invention;

[0020] Figure 2 Functional block diagram of the present invention;

[0021] Figure 3 The system access process of this invention;

[0022] Figure 4 The Activiti workflow of this invention. Detailed Implementation

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0024] This embodiment illustrates a FIFO-based software testing task management system that adopts a B / S architecture with a front-end and back-end separation design. Based on principles of abstraction and encapsulation, the system architecture is divided into three layers according to front-end architecture and technology, functional modules and key technologies, and data storage: the user interface layer, the business logic layer, and the data persistence layer. Figure 1 As shown.

[0025] User Interface Layer: Located at the top layer, this layer directly interacts with the user. Users access the software testing task management system primarily through a browser by accessing HTML web pages. The user interface layer can send user input requests on the web page to the business logic layer for processing and can display the results of the business logic layer's processing to the user in a concise form through the web page.

[0026] Business Logic Layer: Receives requests from the user interface layer, processes them, and returns the results to the user interface layer for display. The business logic layer contains all functional modules, providing an interface to the data persistence layer below and a data interaction and communication interface with the user interface layer above; it acts as the nerve center of the system. The business logic layer adopts a modular design approach based on functional division. The modules are independent of each other, exhibiting low coupling and facilitating maintenance. See [link to detailed functional module division] for more information. Figure 2 It mainly includes functions such as organization management, project management, queue management, status reporting, information viewing, report generation, and system notification.

[0027] (1) Organization Management Module

[0028] The organization management module mainly calls the persistence layer interface to operate on user, organization, role and other related information in the database based on the instructions related to users, organizations and roles input by the user interface layer, and feeds back the execution structure to the user interface layer for display, thereby realizing user management, organization management and role management.

[0029] (1-1) User management mainly involves administrators creating, deleting, modifying, and resetting users' passwords.

[0030] User Creation: After the administrator enters user information on the webpage and clicks "Submit," the user interface layer sends the "Add User" command along with the entered user information to the organization management module in the business logic layer. Upon receiving the "Add User" command, the organization management module calls the persistence layer interface to add a user record to the database. The data persistence layer returns the operation result to the organization management module, which then returns the result information to the user interface layer for display.

[0031] Deleting a user: The administrator selects the user to be deleted on the webpage and clicks "Delete". The user interface layer sends the "Delete User" instruction and the ID of the user to be deleted to the organization management module of the business logic layer. After receiving the instruction, the business logic layer calls the persistence layer interface to delete the relevant user. The data persistence layer sends the operation result to the business logic layer. After receiving the result, the business logic layer feeds back the information to the user interface layer.

[0032] Modify User: After the administrator selects the user information, job information, role information, etc. of the user to be modified on the webpage, clicks "Submit". The user interface layer will send the "Modify User" instruction and related information to the organization management module of the business logic layer. After comprehensive judgment, the organization management module calls the corresponding persistence layer interface to perform the update operation. The execution result is sent by the persistence layer, forwarded by the business logic layer, and finally reaches the user interface layer.

[0033] Password Reset: The user interface layer sends the "Reset Password" command, the user ID to be modified, and the new password to the organization management module of the business logic layer. After receiving the command and data, the business logic layer encrypts the password, calls the persistence layer operation interface, modifies the password of the corresponding user, and reports the execution result.

[0034] (1-2) Organizational management mainly involves the administrator defining the organizational structure of the software testing center. They can add, modify, delete, and view organizational nodes, assign users and responsible persons to organizational nodes, manage positions within organizational nodes, and assign personnel to positions.

[0035] Adding an organization node: The administrator fills in the organization node information on the webpage and clicks "Submit". The user interface layer sends the "Add Organization Node" command along with the entered organization node information to the organization management module of the business logic layer. After receiving the command, the organization management module calls the persistence layer interface to add an organization node record to the database.

[0036] Modify organization nodes: The data to be modified in organization nodes includes organization node information, organization personnel, positions, roles, and other data.

[0037] Deleting an organization node: The administrator selects the organization node to be deleted on the webpage and submits. The user interface layer sends the "Delete organization node" command and the organization node ID to the organization management module of the business logic layer. After receiving the command and data, the organization management module calls the relevant persistence layer interface. By deleting the relationship data between the organization node and the system user, the relationship between the organization node and the user is severed. Then, the job relationship data, organization relationship data, role authorization relationship data, etc. are deleted in sequence to sever the relationship between the organization node and the job, organization parameters, and roles. Finally, the organization node information is deleted.

[0038] Organization Node Viewing: The user interface layer sends the organization node to be viewed and the ID of the organization node to be viewed to the organization management module of the business logic layer. The organization management module obtains the organization node information and the organizational personnel, positions, organizational parameters, roles, etc. associated with the organization node by calling the corresponding persistence layer interface, and sends the data to the user interface layer.

[0039] (1-3) Role management allows you to create, delete, and modify roles, as well as allocate role resources and assign role personnel.

[0040] Creating, deleting, and modifying roles is similar to creating, deleting, and modifying users; simply adjust the user's information to match the role's information. This process will not be repeated here.

[0041] Role resource allocation: On the webpage, the user selects the system resources that the role needs to access and clicks "OK". The user interface layer sends the "resource allocation instruction", the resource ID list and the role ID to the organization management module of the business logic layer. The organization management module calls the persistence layer interface to save the resource and role relationship data to the database.

[0042] Role and personnel assignment: When a user selects to add a user on the webpage and "submits", the user interface layer sends the "personnel assignment instruction", user ID list and role ID to the organization management module of the business logic layer. The organization management module calls the persistence layer interface to save the user and role relationship data to the database.

[0043] After a user successfully logs in to the system, the business logic layer calls the persistent data interface to first obtain the list of roles associated with the user, then obtain the complete set of resources associated with the roles, and return it to the user interface layer. The user interface layer then renders the returned resource list into a navigation bar on the page for the user to access.

[0044] (2) Project Management Module

[0045] The project management module primarily handles project creation, editing, deletion, and viewing. Operational permissions are controlled based on roles and whether the user is a project team member. Administrators, center directors, and team leaders have the authority to create projects; administrators and project members have the authority to edit projects; and administrators have the authority to delete projects. When creating a project, in addition to necessary project information, personnel assignments such as project leader, project team leader, and project members are required. After successful project creation, configuration software items (supporting multiple items) can be created within the project. Test activities can be modified within these configuration software items, and personnel can be assigned to both the configuration software items and test activities. The project supports conditional queries and advanced queries with custom combinations of conditions, and fixed query combinations can be saved for future retrieval.

[0046] The processes for creating, editing, deleting, and viewing projects in the project management module are consistent with those described in the organization management module. The system uses the currently logged-in user ID, and the project management module comprehensively determines whether the user has the necessary permissions to create, edit, delete, and view projects.

[0047] Project Query: The user interface layer provides query and advanced query interfaces. After the user enters the query conditions in the client and clicks query, the user interface layer sends the project query command and query conditions to the project management module. After receiving the query conditions, the project management module parses the query conditions and calls the persistence layer interface to obtain the data that meets the conditions. After receiving the returned result data, it forwards it to the user interface layer for display.

[0048] (3) Queue Management Module

[0049] The queue management module needs to maintain two types of queues: First, the "In-Process Software Queue," which maintains all ongoing configuration software in the software testing center, arranged in the order of their "enqueueing" operation. Second, each tester's "Task Queue," where tasks are sorted by the tester's priority from highest to lowest, initially also in the order of the configuration software's "enqueueing" operation. Queue management includes three operations: software enqueueing, software insertion, and software dequeueing. When a configuration software is initially created, it is in an un-enqueueed state. When the testing conditions are met, "software enqueueing" is triggered. The configuration software receives a unique identifier, enters the queue, and is added to the tail of the "In-Process Software Queue" and the tail of each relevant tester's "Task Queue." When a software testing task for a specific configuration item is urgent and requires higher testing priority, a "software skipping" request can be submitted. After approval, the software configuration item will be moved to the head of each tester's "task queue." If a tester's "task queue" already contains a software configuration item that has already undergone a "skipping" operation, that software configuration item will be placed after all software configuration items that have undergone "skipping" and before all software configuration items that have not undergone "skipping." If the software configuration item itself has already undergone a "skipping" operation, it will be directly inserted at the head of all relevant testers' "task queues." If a software configuration item remains in a "waiting" state for more than one month, a "software dequeue" operation will be automatically triggered. The software configuration item's "identity" will be invalidated, and it will be removed from the "In-Process Software Queue" and "Task Queue," returning to its initial state until a "software enqueue" operation is performed again. If the testing of a software configuration item is completed or terminated, the software configuration item will change to a "completed" or "terminated" state and be removed from the "In-Process Software Queue" and "Task Queue." The system will mark the configuration items of software that have performed "software queue jumping" or "software dequeuing" caused by waiting with different identifiers.

[0050] Enqueue Operation: After a user performs an enqueue operation, the user interface layer sends the "enqueue operation instruction" and the software ID to be enqueued to the business logic layer. The business logic layer first determines whether the enqueue conditions are met. If not, it returns a prompt message and exits. If the enqueue conditions are met, it first obtains all relevant users of the software, then iterates through all users, obtains the user's task queue for each user, adds the software to the tail of the task queue, then calls the persistence layer interface to save it to the database, finally generates a unique software ID, modifies the software status, and saves the software information.

[0051] Software queue skipping: Users initiate queue skipping requests through the user interface layer. The user interface layer sends the "software queue skipping instruction" and the ID of the software to be skipped to the business logic layer. After receiving the instruction and the software ID, the business logic layer initiates a "software queue skipping" process instance through the integrated Activiti. After approval, the business logic layer executes the software queue skipping operation. First, it retrieves all relevant users of the software based on the software ID. Then, it iterates through all users, and for each user, it calls the persistence layer interface to obtain the task queue, calculates the task queue after skipping, and saves it to the database.

[0052] Software Dequeue: The system integrates Quartz to create a scheduled task. This scheduled task scans all software states when idle. When the dequeue conditions are met, the business logic layer automatically triggers the software dequeue operation. First, it retrieves all relevant users of the software based on the software ID. Then, it iterates through all users and, for each user, calls the persistence layer interface to retrieve the task queue, dequeues the software, and saves it to the database. Finally, it cancels the unique identifier, modifies the software state, and saves it to the database.

[0053] (4) Status reporting module

[0054] Testers can update the testing status and progress of configuration software items in their "Task Queue" daily. When submitting a status report, testers should first switch the focus on the configuration software item to be reported on the webpage (if the focus is already on the configuration software item, switching is not necessary), then create a new report record, fill in the content, and submit. In the status report module, users can create, delete, and modify report records, and can view their own status report records by date. When a configuration software item cannot be tested for some reason, the status report will change it to a waiting state. If the waiting period exceeds one month, the configuration software item will automatically be removed from the "In-Process Software Queue" and "Task Queue," returning to its initial state. If the testing of a configuration software item is completed or suspended, the status report will change it to a completed or suspended state, and the configuration software item will automatically be removed from the "In-Process Software Queue" and "Task Queue."

[0055] Creating a new data entry record: Users select the data entry software on the webpage, click "Create New", fill in the status information, and click "Submit". The user interface layer will send the "Create New Data Entry Record Instruction", the software ID, and the data entry data to the status entry module of the business logic layer. After receiving the instruction and data, the status entry module first modifies the task status in the software by calling the persistence layer interface, then synchronizes the software status, and finally records the data entry log.

[0056] Modifying data entry records: When a user selects a data entry record on the webpage, clicks "Edit," modifies the data, and then clicks "Submit," the user interface layer sends the "Modify Data Entry Record Instruction," the software ID, and the data to the status entry module in the business logic layer. After receiving the instruction and data, the status entry module first modifies the task status in the software by calling the persistence layer interface, then synchronizes the software status, and finally modifies the data entry log.

[0057] Deleting a data entry record: When a user selects a data entry record to be deleted on the webpage and clicks "Delete", the user interface layer sends the "Delete Data Entry Record Instruction" and the data entry record ID to the status entry module in the business logic layer. After receiving the instruction and data, the status entry module first calls the persistence layer interface to obtain the data entry record data, then obtains the data entry record logs of the relevant software and tasks, compares them to determine whether the status needs to be restored. If restoration is required, the persistence layer interface is called to restore the software status and task status to their original state, and finally the record is entered.

[0058] (5) Information Viewing Module

[0059] The information viewing module has three display areas: a comprehensive display area, a software queue area, and a personnel list area.

[0060] Comprehensive Display Area: The user interface layer sends data request commands to the information viewing module. After receiving the command, the information viewing module calls the persistence layer interface to obtain ongoing software data information (such as the total number of software programs, the number of models, etc.) and distribution information (model distribution, test category distribution, etc.). Then, it returns the data to the user interface layer for rendering and display, presenting real-time data on the software testing center's task scale, task distribution, development trends, and personnel allocation in the form of numbers and charts.

[0061] Software Queue Area: The user interface layer sends data request commands to the business logic layer. After receiving the command, the business logic layer calls the persistence layer interface to retrieve the software list data according to the status (in queue, pending registration, completed), and then returns it to the user interface layer for rendering and display. The detailed data of the configuration items software in the "in queue", "pending registration", and "complete / aborted" statuses are displayed in list form. The "in queue" list has perspectives such as "software", "project", and "model" to meet the query needs of different roles.

[0062] Personnel List Area: The user interface layer sends a data request command to the business logic layer. After receiving the command, the business logic layer calls the persistence layer interface to obtain the personnel list, then obtains the task data of each person, and returns it to the user interface layer for rendering and display. From the perspective of the personnel, it centrally displays the current task status of all members under the organization of the software testing center and the test tasks they are focusing on.

[0063] (6) Report generation module

[0064] The report generation module supports generating work reports of various dimensions, including individual work reports, software progress reports, project progress reports, team work reports, and center work reports, to meet the export needs of different roles. After the user sets the conditions, triggering the generation operation, the system will automatically generate a Word format report document and download it to the local computer for the user to view and use. The report generation module controls the generation permissions of each work report based on job roles. The center director has the authority to generate all types of work reports, the team leader has the authority to generate individual work reports, software progress reports, project progress reports, and team work reports within their team, and team members can generate their own work reports and related software progress reports and project progress reports. The system supports exporting project information lists in Excel format. When exporting, users can customize the content to be exported from the project information fields.

[0065] Personal work report generation: Users click "User Details" on the webpage, then click "Export Report," select the report period, and click "Export." The user interface layer sends the "User Report Export Instruction," user ID, and time range to the report generation module. Upon receiving the instruction and data, the business logic layer calls the persistence layer interface to retrieve the user's work data for that time range, then combines it with a predefined report template to generate a report document, which is then returned to the user interface layer for download. Other types of work follow the same process as generating personal work reports and will not be described further.

[0066] (7) System Notification Module

[0067] In the system notification module, when there are new unread messages, the user is notified that there are unread messages; the notification disappears after the user reads all unread messages; for "dequeueing" operations caused by "waiting" reasons, the system sends a reminder to relevant personnel one week before the "dequeueing" operation is executed, and after successful execution, the system sends a system notification to relevant personnel to inform them that the configuration item software has been "dequeued"; after the "software queue jumping" is completed, the system should send a system notification to the relevant personnel of the configuration item software that was queued.

[0068] "System Notification": After receiving a system notification command, the system notification module in the business logic layer, based on the notification content and the target user, calls the persistence layer interface to add system notification data. When a relevant user logs into the system, the business logic layer retrieves the relevant system notifications and sends them to the user interface layer for the user to view.

[0069] The software testing task management system utilizes several key technologies to meet business needs. Firstly, it integrates the Activiti workflow engine, compliant with BPMN specifications, enabling the management of user-defined process activities and automating business workflow transitions. This system applies Activiti to the "Software Queue Jump" function within the queue management module, managing customized "Software Queue Jump" processes. For details, please refer to [link to relevant documentation]. Figure 4 Second, the system integrates Apache POI to generate Office documents. Apache POI is an open-source project based on the Office Open XML standard (OOXML) and Microsoft's Compound Document Format (OLE2) to process various file formats. It can be used to read and write MS Excel, MS Word, and MS PowerPoint documents, and can generate rich report documents. This system uses this technology in the "Report Generation" module, combining system data to export various work reports and project data in Word / Excel document format. Third, the system integrates Quartz for task scheduling. Quartz is an open-source job scheduling framework that provides a simple yet powerful mechanism for job scheduling in Java applications, allowing developers to schedule jobs based on time intervals. This system uses Quartz in the "Queue Management" section to implement automatic dequeue functionality.

[0070] Data persistence layer: Persistently stores data from different business modules using a reasonable data structure. It uses a MySQL relational database to store data, enabling data to be stored once and used multiple times, and providing data for the business logic layer.

[0071] The process of the system completing a complete access request is as follows: Figure 3 As shown:

[0072] First, the user enters and sends a request to the server through the browser on the client side. After receiving the request, the user interface layer forwards it to the corresponding business function module in the business logic layer. The specific business function module accesses and retrieves the data from the database, processes it, and returns the processing result to the user interface layer. The user interface layer returns an HTML page or data to the user, who can then view the returned result through the browser.

[0073] It is understood that those skilled in the art can make equivalent substitutions or modifications to the technical solution and inventive concept of the present invention, and all such substitutions or modifications should fall within the protection scope of the appended claims.

Claims

1. A FIFO-based software test task management system, divided into a user interface layer, a business logic layer and a data-based persistence layer, characterized in that The business logic layer includes a queue management module, which maintains two types of queues: one is the ongoing software queue, which maintains all software configuration items currently in progress in the software testing center, arranged according to the order in which they were enqueued; the other is the task queue for each user, where tasks are sorted from highest to lowest according to the user's test priority. Queue management includes three operations: software enqueueing, software insertion, and software dequeueing. Software Queue Jumping: When a software testing task for a certain configuration item needs to be given higher testing priority, a "software queue jumping" request is made. After receiving the "software queue jumping instruction" and the software ID to be jumped from the user interface layer, the queue management module initiates a "software queue jumping" process instance through the integrated Activiti. After approval, the business logic layer executes the software queue jumping operation. First, it calls the persistence layer interface to obtain all relevant users of the software based on the software ID. Then, it iterates through all relevant users. For each user, the configuration item software is moved to the head of each user's "task queue". If a configuration item software that has already performed "software queue jumping" already exists in a relevant user's "task queue", then the configuration item software is inserted after all configuration item software that has performed "software queue jumping" in that user's "task queue" and before all configuration item software that has not performed "software queue jumping". If the configuration item software itself has already performed "software queue jumping", then it is directly inserted to the head of all relevant users' "task queues" and the task queue after the jump is saved to the database. Software Enqueueing: When a configuration item software is initially created, it is in an unqueued state. When the test conditions are met, "Software Enqueueing" is triggered. The queue management module receives the "Enqueueing Operation Instruction" and the software ID to be enqueued from the user interface layer. It then determines whether the enqueueing conditions are met. If not, it returns a prompt message and exits. If the enqueueing conditions are met, it first obtains all relevant users of the configuration item software, then iterates through all users, obtains the user's "Task Queue" for each user, adds the configuration item software to the tail of each user's "Task Queue", and adds it to the tail of the "In Progress Software Queue". Then, it calls the persistence layer interface to save it to the database, finally generates a unique software ID, modifies the software status, and saves the software information. Software Dequeue: The queue management module integrates a scheduled task created by Quartz. This scheduled task scans the status of all configuration item software during idle periods. If a configuration item software remains in the "waiting" state for more than a set period, a software dequeue operation is automatically triggered. First, all relevant users of the software are retrieved based on the software ID. Then, all users are iterated through. For each user, the persistent layer interface is called to retrieve the task queue for each user. The configuration item software is changed to the "invalid" state, removed from the in-progress software queue and task queue, and restored to its initial state until the "software enqueue" operation is performed again. If the configuration item software test is completed / aborted, the configuration item software is changed to the "completed" or "aborted" state and removed from the in-progress software queue and task queue. The in-progress software queue and task queue are saved to the database. Finally, the software ID is canceled and the configuration item software status is modified.

2. The FIFO-based software test task management system of claim 1, wherein The business logic layer also includes a status reporting module, which allows users to update the testing status and progress of the software configuration items in their "task queue".

3. The FIFO-based software test task management system of claim 1, wherein The business logic layer also includes an information viewing module, which has a comprehensive display area. It calls the persistence layer interface to obtain data and distribution information of the software queue in progress, and then returns it to the user interface layer for rendering and display. The real-time data of the task scale, task distribution, development trend and personnel allocation of the software testing center are displayed in the form of numbers and charts.

4. The FIFO-based software test task management system of claim 1, wherein The business logic layer also includes an information viewing module. The information viewing module has a software queue area. It calls the persistence layer interface to retrieve software list data according to the status, and then returns it to the user interface layer for rendering and display. It displays detailed data of configuration item software in the form of a list, which are in the "in queue", "pending to join", and "complete / aborted" statuses. The "in queue" list has "software", "project" and "model" perspectives to meet the query needs of different roles.

5. The FIFO-based software test task management system of claim 1, wherein The business logic layer also includes an information viewing module. The information viewing module has a personnel list area. It calls the persistence layer interface to obtain the user list, then retrieves the task data of each user from the task queue, and returns it to the user interface layer for rendering and display. From the user's perspective, it centrally displays the current task status of all users under the organization of the software testing center and the test tasks they are focusing on.

6. The FIFO-based software test task management system of claim 1, wherein The business logic layer also includes a report generation module, which integrates Apache POI to generate Office documents and supports the generation of personal work reports, software progress reports, project progress reports, team work reports, and center work reports.

7. The FIFO-based software test task management system of claim 1, wherein The business logic layer also includes an organization management module. Based on the user interface layer's input of instructions related to users, organizations, and roles, the organization management module calls the persistence layer interface to operate on the relevant information of users, organizations, and roles in the database, and feeds back the execution structure to the user interface layer for display, thus realizing user management, organization management, and role management.

8. The FIFO-based software test task management system of claim 1, wherein The business logic layer also includes a project management module, which is used to create, edit, delete, and view projects, and controls project operation permissions according to roles and whether the user is a project team member.

Images