CN115587041A - Mobile application delivery task processing method and device, electronic equipment and storage medium - Google Patents
Mobile application delivery task processing method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN115587041A CN115587041A CN202211317008.1A CN202211317008A CN115587041A CN 115587041 A CN115587041 A CN 115587041A CN 202211317008 A CN202211317008 A CN 202211317008A CN 115587041 A CN115587041 A CN 115587041A
- Authority
- CN
- China
- Prior art keywords
- target
- subtask
- acquiring
- processing
- task flow
- 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
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/3688—Test management for test execution, e.g. scheduling of test suites
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application provides a mobile application delivery task processing method and device, an electronic device and a storage medium, wherein the method comprises the following steps: acquiring a delivery processing request uploaded by a user; acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at a time point to obtain a target processing result; under the condition that the target processing result meets the preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow; and acquiring a second processing strategy of the next subtask until the target task flow is completed, and acquiring the processing result of the mobile application at each task stage in the delivery process. Through the method and the device, the problem that processes except mobile terminal development cannot be found in the related technology is solved.
Description
Technical Field
The present application relates to the field of mobile development, and in particular, to a mobile application delivery task processing method and apparatus, an electronic device, and a storage medium.
Background
Delivery quality and delivery efficiency are issues which cannot be avoided in software development, and many companies perform delivery management of themselves and aim to improve quality and efficiency in the development process. The premise of promotion is that the current situation can be measured, such as the load, the lead cycle, the bug number and the like of development resources can be measured, and the problem can be solved in a targeted manner by using the data.
In the field of mobile development, data of a mobile terminal can be measured only, for example, a mobile terminal delivery management system can only manage a process from creation of a mobile terminal development branch to online, and a man-hour system is matched to count the human load state and the work content of each person. But this is one-sided because if a problem occurs, its source may not be the mobile end itself.
Therefore, the related art cannot find a flow problem other than the mobile terminal development.
Disclosure of Invention
The application provides a mobile application delivery task processing method and device, electronic equipment and a storage medium, which are used for at least solving the problem that processes except mobile terminal development cannot be found in the related technology.
According to an aspect of an embodiment of the present application, there is provided a mobile application delivery task processing method, including:
acquiring a delivery processing request uploaded by a user, wherein the delivery processing request carries a target subtask to be delivered and applied, a time point for executing the target subtask and a target key element to be processed of the target subtask;
acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at the time point to obtain a target processing result;
under the condition that the target processing result meets the preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow;
and acquiring a second processing strategy of the next subtask until the target task flow is completed, and acquiring a processing result of the mobile application at each task stage in the delivery process.
According to another aspect of the embodiments of the present application, there is also provided a mobile application delivery task processing apparatus, including:
the delivery processing method comprises the steps that an obtaining module is used for obtaining a delivery processing request uploaded by a user, wherein the delivery processing request carries a target subtask of an application to be delivered, a time point for executing the target subtask and a target key element to be processed of the target subtask;
the processing module is used for acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at the time point to obtain a target processing result;
the determining module is used for determining a target task flow corresponding to the target subtask under the condition that the target processing result meets a preset requirement corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow;
and the obtaining module is used for obtaining a second processing strategy of the next subtask until the target task flow is completed, and obtaining a processing result of the mobile application at each task stage in the delivery process.
Optionally, when the target subtask is a product requirement, the target key element is requirement information to be evaluated, the target processing result is a quality evaluation result after the requirement information to be evaluated is evaluated, and the processing module includes:
the first obtaining unit is used for obtaining a judgment rule set, wherein the judgment rule set is the preset requirement;
a second obtaining unit, configured to obtain the target task process in which the product demand is currently located when the quality assessment result does not fall into the evaluation rule set;
and the third acquisition unit is used for acquiring a next subtask of the product requirement from the target task flow as a next object to be executed.
Optionally, when the target subtask is server development, the target key element is a development interface, the target processing result is interface feedback information determined by the development interface, and the processing module includes:
a fourth obtaining unit, configured to obtain an original association parameter of the current development interface, where the original association parameter is the preset requirement;
a fifth obtaining unit, configured to obtain the target task process in which the server develops the current target task process when the interface feedback information is consistent with the original association parameter;
and a sixth obtaining unit, configured to obtain, from the target task flow, a next subtask developed by the server as a next object to be executed.
Optionally, when the target subtask is web page design, the target key element is diagram information, the target processing result is a current diagram identified from the diagram information, and the processing module includes:
a seventh obtaining unit, configured to obtain a target effect graph and a target cutting graph, where the target effect graph and the target cutting graph are the preset requirements;
an eighth obtaining unit, configured to obtain the target task flow in which the webpage design is currently located when similarities among the current diagram, the target effect diagram, and the target tangent diagram are greater than a similarity threshold;
and the ninth acquiring unit is used for acquiring the next subtask of the webpage design from the target task flow as a next object to be executed.
Optionally, when the target subtask is development testing, the target key element is a test case, the target processing result is a test result obtained by processing the test case, and the processing module includes:
a tenth obtaining unit, configured to obtain a first preset threshold and a second preset threshold, where the first preset threshold is a numerical value that can be completely covered by the test case, and the second preset threshold is a maximum value of a number of the test cases that are allowed to fail;
an eleventh obtaining unit, configured to take the first preset threshold and the second preset threshold as the preset requirements, and obtain the target task process where the development test is currently located when the number of the test results is greater than or equal to the first preset threshold and the number of the test results representing faults is less than or equal to the second preset threshold;
and a twelfth obtaining unit, configured to obtain, from the target task flow, a next subtask of the development test as a next object to be executed.
Optionally, when the target subtask is demand verification, the target key element is demand value data after being online, the target processing result is an estimation result after quantifying the demand value data, and the processing module includes:
a thirteenth obtaining unit, configured to obtain an expected value to be reached, where the expected value to be reached is the preset requirement;
a fourteenth obtaining unit, configured to obtain the target task process where the requirement verification is currently located when a difference between the estimated result and the expected value to be reached is smaller than a preset threshold;
and a fifteenth obtaining unit, configured to obtain, from the target task flow, a next subtask of the requirement verification as a next object to be executed.
Optionally, the apparatus further comprises:
the monitoring module is used for monitoring the task processing progress of each subtask in the target task flow according to a preset frequency;
the judging module is used for judging whether each subtask has task processing delay or not by combining the reference progress in the target system;
and the sending module is used for sending prompt information under the condition that the task processing delay of any subtask is determined.
According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein the memory is used for storing the computer program; a processor for performing the method steps in any of the above embodiments by running the computer program stored on the memory.
According to a further aspect of the embodiments of the present application, there is also provided a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to perform the method steps of any of the above embodiments when the computer program is executed.
In the embodiment of the application, a delivery processing request uploaded by a user is obtained, wherein the delivery processing request carries a target subtask to be delivered and applied, a time point for executing the target subtask, and a target key element forming the target subtask; acquiring a first processing strategy corresponding to a target subtask, and processing a target key element by using the first processing strategy at a time point to obtain a target processing result; under the condition that the target processing result meets the preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow; and acquiring a second processing strategy of the next subtask until the target task flow is completed, and acquiring the processing result of the mobile application at each task stage in the delivery process. According to the method and the system, due to the fact that serial management is conducted on all subtasks related to mobile development work, the development process of the whole team is standardized, problems possibly encountered in the mobile development can be measured in a fine-grained mode, and the overall appearance of the requirement process and the team work quality can be described in detail. The serial mode means blocking mode, each task has a precondition, and problems can be found and intervened as soon as possible, so that the problem except for development of the mobile terminal can be found by an auxiliary manager in the whole delivery process of the mobile terminal, and the delivery quality and efficiency can be improved by taking measures.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.
Fig. 1 is a schematic flowchart of an alternative mobile application delivery task processing method according to an embodiment of the present application;
FIG. 2 is a schematic diagram of an alternative pre-development phase scheduling flow according to an embodiment of the present application;
fig. 3 is a schematic diagram of an alternative management flow for starting mobile development to demand shutdown according to an embodiment of the present application;
FIG. 4 is a schematic flow chart diagram illustrating an alternative deferred risk notification according to an embodiment of the present application;
fig. 5 is a block diagram of an alternative mobile application delivery task processing device according to an embodiment of the present application;
fig. 6 is a block diagram of an alternative electronic device according to an embodiment of the present application.
Detailed Description
In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only partial embodiments of the present application, but not all 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 application.
It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It should be understood that the data so used may be interchanged under appropriate circumstances such that embodiments of the application described herein may be implemented in sequences other than those illustrated or described herein. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
In the field of mobile development, only the mobile side's data is typically measured, but this is one-sided, since the source of the problem may not be the mobile side itself. General mobile terminal requirements relate to 5 large stages of product demand, server development, UI design, mobile terminal development, test on-line and the like, any one stage has problems and affects the delivery result of the mobile terminal, flow problems except for the mobile terminal development cannot be found and taken as early as possible, and the delivery process of the whole link from demand lifting to on-line cannot be fully digitalized.
The existing mobile terminal delivery management system can only manage the process from creating a mobile terminal development branch to getting on-line, and can count the human load state and the work content of each person by matching with a working hour system. But the problems of requirement stability, interface development quality, UI design rationality, test case coverage and the like can not be reflected. The following problems are caused in the current prior art: (1) The pay line flow of each end is split, and the whole required delivery process cannot be presented in a full link; (2) The problems of product requirements, service end, UI design, test, and the like can only be measured; (3) The risk cannot be predicted, and the process problems except mobile terminal development can only be communicated offline, so that the efficiency is low. In order to solve the above problem, an embodiment of the present application proposes a mobile application delivery task processing method, which can be applied to a mobile terminal delivery system as shown in fig. 1, and includes:
step S101, a delivery processing request uploaded by a user is obtained, wherein the delivery processing request carries a target subtask of an application to be delivered, a time point for executing the target subtask, and a target key element to be processed by the target subtask.
Optionally, as shown in fig. 2, a plurality of target subtasks are shown in fig. 2, such as a server development subtask, a web page design subtask, and the like, before each subtask is executed, a scheduling period (i.e., a time point) is set for each subtask, and after a certain scheduling period is reached, the corresponding subtask is executed.
In addition, the mobile terminal delivery system comprises two subsystems, namely a process management system and a working hour system, after all the subtasks are scheduled, a Gantt chart can be checked in the process management system, and the starting time and the ending time of each subtask can be clear at a glance.
Further, the mobile terminal delivery system may obtain a delivery processing request uploaded by a user, where the delivery processing request may carry target subtasks to be currently delivered, such as a server development subtask, a web page design subtask, a development test subtask, and the like, obtain a time point (i.e., a scheduling) for executing the target subtask, and obtain target key elements that the target subtask needs to process.
Step S102, a first processing strategy corresponding to the target subtask is obtained, and the target key element is processed by the first processing strategy at a time point, so that a target processing result is obtained.
Optionally, after the target subtask of the application to be currently delivered is obtained, a corresponding first processing policy needs to be generated, and then after the current time reaches the scheduling time point of the target subtask, the target key element is processed by using the first processing policy, so that a target processing result is obtained.
Step S103, under the condition that the target processing result meets the preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring the next subtask of the target subtask from the target task flow.
Optionally, as shown in fig. 2, a main line of a product requirement schedule, a server development schedule, a web page design schedule, a development test schedule, a mobile terminal development schedule, an online schedule, and a requirement verification schedule in fig. 2 is used as a target task flow, after a current target processing result meets a preset requirement corresponding to a target subtask, a position of the current target subtask in the target task flow is checked, and then a next subtask of the target subtask is obtained from the position. For example, when the target subtask is product demand scheduling, the next subtask is server development scheduling.
And step S104, acquiring a second processing strategy of the next subtask until the target task flow is completed, and obtaining the processing result of the mobile application at each task stage in the delivery process.
Optionally, after the next subtask is determined, the second processing policy corresponding to the next subtask is obtained, and then the second processing policy continues to process the next subtask until all subtasks in the target task flow are completed, so that a processing result of the mobile application at each task stage in the whole delivery process can be obtained.
It can be understood that the processing procedures of the subtasks are serial, so that once an error occurs in a certain link, the error is reported immediately or the task cannot be executed later; only if all links pass smoothly, the whole delivery process is completed, so that the problem can be found as early as possible and intervention is facilitated.
In the embodiment of the application, a delivery processing request uploaded by a user is obtained, wherein the delivery processing request carries a target subtask to be delivered to an application, a time point for executing the target subtask, and a target key element forming the target subtask; acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at a time point to obtain a target processing result; under the condition that the target processing result meets the preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow; and acquiring a second processing strategy of the next subtask until the target task flow is completed, and acquiring the processing result of the mobile application at each task stage in the delivery process. According to the method and the system, due to the fact that serial management is carried out on all subtasks related to mobile development work, the development flow of the whole team is standardized, problems possibly encountered in the mobile development can be measured in a fine-grained mode, and the overall appearance of the requirement process and the team work quality can be described in detail. The serial mode means blocking mode, each task has a precondition, and problems can be found and intervened as soon as possible, so that the problem except for development of the mobile terminal can be found by an auxiliary manager in the whole delivery process of the mobile terminal, and further the delivery quality and efficiency are improved by taking measures.
Based on the content of the foregoing embodiments, as an optional embodiment, as shown in fig. 2, in the embodiment of the present application, after the product requirement scheduling, the server development scheduling, the web page design scheduling, and the development test scheduling are all completed, the mobile terminal development scheduling, the online scheduling, and the requirement verification scheduling are performed. Therefore, before the mobile terminal starts development, as shown in fig. 3, it is checked again whether each role (product requirement, server development, web page design, development test) is scheduled to be completed, if not, related personnel is notified to schedule as soon as possible, and if so, the mobile terminal enters a development stage.
When the mobile terminal enters a development stage, problems and risks in the delivery process of the mobile terminal are recorded, for example, when a target subtask of the application to be delivered is a product requirement, a target key element is requirement information to be evaluated created by a product manager (filling requirement description, expected value of the requirement (for example, how many users can be added, and how much cost can be reduced).
After the evaluation, a homonymous service requirement is automatically created in the man-hour system and is associated with the homonymous service requirement), various kinds of engineering, such as developers and testers, evaluate the information of the requirement to be evaluated to obtain a quality evaluation result, then the quality evaluation result is compared with preset requirements (namely, an evaluation rule set, which contains problems of flow loss, logic unclear and the like) set in advance, whether the problems appearing in the quality evaluation result fall into the evaluation rule set is checked, and if the problems do not fall into the evaluation rule set, the next subtask of the product requirement is obtained from the target task flow and is used as the next object to be executed; and if the information falls into the evaluation rule set, recording the problems and risks, such as recording the problems of requirement change, flow loss and the like.
For example, when the target subtask is server development, the target key element is a development interface, and interface feedback information is obtained after the development interface is determined, where the interface feedback information may be some parameter information of the current development interface, whether the interface can access information, and whether the interface has modification information.
Acquiring original associated parameters of a current development interface as preset requirements corresponding to the development of a server, comparing whether interface feedback information is consistent with the original associated parameters or not, if not, determining that the problems of inconsistent interface documents and interface parameters, inaccessible interfaces, unauthorized interface modification and the like occur, and recording the problems; and if the target task flow is consistent with the target task flow, acquiring the next subtask developed by the server as the next object to be executed.
For example, when the target subtask is a web page design, the target key element is some currently acquired graphic information, the graphic information is processed and identified, the obtained graphic is used as a current graphic, and then the current graphic is compared with preset requirements (namely a target effect graph and a target cutting graph) set in advance in the web page design, and when the similarity between the current graphic and the target effect graph and the similarity between the current graphic and the target cutting graph are greater than a similarity threshold (for example, 95%), the current graphic is consistent with the requirement effect graph, and no cutting omission occurs, at this time, the next subtask of the web page design is acquired from the target task flow and is used as a next object to be executed; otherwise, recording the problem that the effect graph and the cut graph are not in accordance with the actual requirement.
For example, when the target subtask is development test, the target key element is a test case, and a test result is obtained after the test case is tested. It needs to be explained that the test result can reflect the number of the test cases and also can represent the number of the test cases with faults, so the embodiment of the application can set a value that the test cases can cover the integrity as a first preset threshold value in advance in the development test, and allow the maximum value of the number of the test cases with faults as a second preset threshold value, under the condition that the number of the test results is greater than or equal to the first preset threshold value and the number of the test result representing faults is less than or equal to the second preset threshold value, it is indicated that the current test case covers the integrity and is an excellent test case, and at this time, the next subtask of the development test is obtained from the target task flow and is used as a next object to be executed; otherwise, recording the number of faults.
The test case self-test is a link which must be executed in mobile terminal development, and aims to ensure research and development quality, and if the self-test is not carried out, the test cannot be carried out. In addition, the tester performs the test and records the number of faults in the case, which is also an index for checking the self-test degree of the developer.
And for example, when the target subtask is demand verification, the target key element is demand value data after being on-line, the demand value data is quantized to obtain an estimated result, the estimated result is compared with an expected value to be reached set in a product demand creating stage, if the difference between the estimated result and the expected value to be reached is smaller than a preset threshold (for example, 10%), the expected purpose is achieved, resource waste is avoided, and the next subtask of the demand verification is obtained from the target task flow and is used as a next object to be executed.
It should be noted that, in the embodiment of the present application, after the project is on-line for a period of time, the product manager needs to verify whether the demand of the product manager reaches the expected value, and at this time, data capable of quantifying the demand value needs to be provided, and then the mobile terminal delivery system will compare the expected value when the demand is created at that time, and then send notification information to related personnel to notify the on-line effect of the demand. So far the demand is closed, there is no next subtask, so the next subtask is no longer executed.
In addition, as shown in fig. 3, after the project is on-line, key data in the demand delivery process, such as whether to delay, delay for several days, change the demand several times, and whether the joint debugging phase interface is available, may be generated at the mobile terminal delivery system by one key. If the problem is serious, the related personnel can be organized to copy the disk and record the post improvement measures in the mobile terminal delivery system.
In the embodiment of the application, all roles and tasks related to mobile development work are managed in series, and the development process of the whole team is standardized; meanwhile, statistics on the stability of the requirements are added, which is a problem that management items in the industry are often ignored, and the change times and change degree of the requirements directly influence the delivery quality and delivery timeliness of the software; in addition, the embodiment of the application adds a link of verifying the value of the required business, and after the requirement is on line, the required party needs to provide the energy-based data to be compared with the expected data during demand, so that the related personnel are known, and the method is helpful for promoting the required party to deeply think during demand and preventing the generation of pseudo demand.
Based on the content of the foregoing embodiments, as an optional embodiment, the method further includes:
monitoring the task processing progress of each subtask in the target task flow according to a preset frequency;
judging whether each subtask has a task processing delay or not by combining the reference progress in the target system;
and sending prompt information under the condition that any subtask is determined to have task processing delay.
Alternatively, each subtask in fig. 2 updates the task status in the target system (i.e., the man-hour system) every day, and as shown in fig. 4, the process management system of the mobile terminal delivery system checks the task processing progress of each subtask at a preset frequency, for example, whether the task processing progress is a completed state after the end time of each schedule is reached. If the task is not finished, judging whether the current progress possibly has delay or not by combining the existing reference progress in the target system, and automatically sending prompt risk information as long as any subtask has task processing delay; meanwhile, the delay degree is different, and the risk prompt strategy is also different, for example, the department can be notified about the delay for 3 days or more.
It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.
Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (e.g., a ROM (Read-Only Memory)/RAM (Random Access Memory), a magnetic disk, an optical disk) and includes several instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the methods of the embodiments of the present application.
According to another aspect of the embodiment of the present application, there is also provided a mobile application delivery task processing apparatus for implementing the above mobile application delivery task processing method. Fig. 5 is a block diagram of an alternative mobile application delivery task processing device according to an embodiment of the present application, and as shown in fig. 5, the device may include:
the obtaining module 501 is configured to obtain a delivery processing request uploaded by a user, where the delivery processing request carries a target subtask of an application to be delivered, a time point for executing the target subtask, and a target key element to be processed by the target subtask;
the processing module 502 is configured to obtain a first processing policy corresponding to the target subtask, and process the target key element at a time point by using the first processing policy to obtain a target processing result;
the determining module 503 is configured to determine a target task flow corresponding to the target subtask when the target processing result meets a preset requirement corresponding to the target subtask, and obtain a next subtask of the target subtask from the target task flow;
the obtaining module 504 is configured to obtain a second processing policy of the next sub-task until the target task flow is completed, and obtain a processing result of the mobile application at each task stage in the delivery process.
It should be noted that the obtaining module 501 in this embodiment may be configured to execute the step S101, the processing module 502 in this embodiment may be configured to execute the step S102, the determining module 503 in this embodiment may be configured to execute the step S103, and the obtaining module 504 in this embodiment may be configured to execute the step S104.
Through the module, each subtask related to the mobile development work is subjected to serial management, the development flow of the whole team is standardized, problems possibly encountered in the mobile development can be measured in a fine-grained manner, and the overall appearance of the requirement process and the team work quality can be described in detail. The serial mode means blocking mode, each task has a precondition, and problems can be found and intervened as soon as possible, so that the problem except for development of the mobile terminal can be found by an auxiliary manager in the whole delivery process of the mobile terminal, and further the delivery quality and efficiency are improved by taking measures.
As an optional embodiment, when the target subtask is a product requirement, the target key element is requirement information to be evaluated, the target processing result is a quality evaluation result after the requirement information to be evaluated is evaluated, and the processing module includes:
the first acquisition unit is used for acquiring an evaluation rule set, wherein the evaluation rule set is a preset requirement;
the second acquisition unit is used for acquiring a target task flow where the product demand is currently located under the condition that the quality evaluation result does not fall into the judgment rule set;
and the third acquisition unit is used for acquiring a next subtask of the product requirement from the target task flow as a next object to be executed.
As an optional embodiment, when the target subtask is server development, the target key element is a development interface, and the target processing result is information feedback on the interface after the development interface is determined, the processing module includes:
the fourth acquisition unit is used for acquiring the original associated parameters of the current development interface, wherein the original associated parameters are preset requirements;
the fifth acquiring unit is used for acquiring a target task flow where the server side develops under the condition that the interface feedback information is consistent with the original associated parameters;
and the sixth acquiring unit is used for acquiring the next subtask developed by the server from the target task flow as the next object to be executed.
As an alternative embodiment, in the case that the target subtask is a web page design, the target key element is diagram information, the target processing result is a current diagram identified from the diagram information, and the processing module includes:
a seventh obtaining unit, configured to obtain a target effect graph and a target cutting graph, where the target effect graph and the target cutting graph are preset requirements;
the eighth acquiring unit is used for acquiring a target task flow in which the webpage design is currently located under the condition that the similarity between the current graph and the target effect graph and the similarity between the current graph and the target tangent graph are both greater than the similarity threshold;
and the ninth acquisition unit is used for acquiring the next subtask of the webpage design from the target task flow as the next object to be executed.
As an alternative embodiment, in the case that the target subtask is development test, the target key element is a test case, the target processing result is a test result after processing the test case, and the processing module includes:
a tenth obtaining unit, configured to obtain a first preset threshold and a second preset threshold, where the first preset threshold is a numerical value that can be completely covered by the test case, and the second preset threshold is a maximum value of the number of test cases that are allowed to fail;
an eleventh acquiring unit, configured to acquire a target task process where the development test is currently located, where the number of test results is greater than or equal to the first preset threshold and the number of test result characterization faults is less than or equal to the second preset threshold, where the first preset threshold and the second preset threshold are used as preset requirements;
and the twelfth acquiring unit is used for acquiring the next subtask of the development test from the target task flow as the next object to be executed.
As an optional embodiment, when the target subtask is demand verification, the target key element is demand value data after being online, the target processing result is an estimation result after quantizing the demand value data, and the processing module includes:
a thirteenth acquiring unit, configured to acquire an expected value to be reached, where the expected value to be reached is a preset requirement;
the fourteenth acquiring unit is used for acquiring a target task process where the requirement verification is currently located under the condition that the difference value between the estimation result and the expected value to be reached is smaller than a preset threshold value;
and the fifteenth acquisition unit is used for acquiring the next subtask requiring verification from the target task flow as the next object to be executed.
As an alternative embodiment, the apparatus further comprises:
the monitoring module is used for monitoring the task processing progress of each subtask in the target task flow according to a preset frequency;
the judging module is used for judging whether each subtask has task processing delay or not by combining the reference progress in the target system;
and the sending module is used for sending the prompt information under the condition that any subtask is determined to have task processing delay.
According to still another aspect of the embodiments of the present application, there is also provided an electronic device for implementing the above mobile application delivery task processing method, where the electronic device may be a server, a terminal, or a combination thereof.
Fig. 6 is a block diagram of an alternative electronic device according to an embodiment of the present application, as shown in fig. 6, including a processor 601, a communication interface 602, a memory 603, and a communication bus 604, where the processor 601, the communication interface 602, and the memory 603 complete communications with each other through the communication bus 604, where,
a memory 603 for storing a computer program;
the processor 601, when executing the computer program stored in the memory 603, implements the following steps:
acquiring a delivery processing request uploaded by a user, wherein the delivery processing request carries a target subtask to be delivered to an application, a time point for executing the target subtask and a target key element to be processed by the target subtask;
acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at a time point to obtain a target processing result;
under the condition that the target processing result meets the preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow;
and acquiring a second processing strategy of the next subtask until the target task flow is completed, and acquiring the processing result of the mobile application at each task stage in the delivery process.
Alternatively, in this embodiment, the communication bus may be a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 6, but this is not intended to represent only one bus or type of bus.
The communication interface is used for communication between the electronic equipment and other equipment.
The memory may include RAM, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory. Alternatively, the memory may be at least one memory device located remotely from the aforementioned processor.
As an example, as shown in fig. 6, the memory 603 may include, but is not limited to, an obtaining module 501, a processing module 502, a determining module 503, and an obtaining module 504 of the mobile application delivery task processing apparatus. In addition, the mobile application delivery task processing apparatus may further include, but is not limited to, other module units in the mobile application delivery task processing apparatus, which are not described in detail in this example.
The processor may be a general-purpose processor, and may include but is not limited to: a CPU (Central Processing Unit), an NP (Network Processor), and the like; but also DSPs (Digital Signal Processing), ASICs (Application Specific Integrated circuits), FPGAs (Field-Programmable Gate arrays) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.
In addition, the electronic device further includes: and the display is used for displaying the mobile application delivery task processing result.
Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment is not described herein again.
It should be understood by those skilled in the art that the structure shown in fig. 6 is only an illustration, and the device implementing the above method for processing a Mobile application delivery task may be a terminal device, and the terminal device may be a terminal device such as a smart phone (e.g., an Android Mobile phone, an iOS Mobile phone, etc.), a tablet computer, a palm computer, a Mobile Internet Device (MID), a PAD, and the like. Fig. 6 is a diagram illustrating a structure of the electronic device. For example, the terminal device may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in FIG. 6, or have a different configuration than shown in FIG. 6.
Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program instructing hardware associated with the terminal device, where the program may be stored in a computer-readable storage medium, and the storage medium may include: flash disk, ROM, RAM, magnetic or optical disk, and the like.
According to still another aspect of an embodiment of the present application, there is also provided a storage medium. Alternatively, in this embodiment, the storage medium may be a program code for executing the mobile application delivery task processing method.
Optionally, in this embodiment, the storage medium may be located on at least one of a plurality of network devices in a network shown in the above embodiment.
Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps:
acquiring a delivery processing request uploaded by a user, wherein the delivery processing request carries a target subtask to be delivered to an application, a time point for executing the target subtask and a target key element to be processed by the target subtask;
acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at a time point to obtain a target processing result;
under the condition that the target processing result meets the preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow;
and acquiring a second processing strategy of the next subtask until the target task flow is completed, and acquiring processing results of the mobile application at each task stage in the delivery process.
Optionally, the specific example in this embodiment may refer to the example described in the above embodiment, which is not described again in this embodiment.
Optionally, in this embodiment, the storage medium may include, but is not limited to: various media capable of storing program codes, such as a U disk, a ROM, a RAM, a removable hard disk, a magnetic disk, or an optical disk.
According to yet another aspect of an embodiment of the present application, there is also provided a computer program product or a computer program comprising computer instructions stored in a computer readable storage medium; the processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the steps of the mobile application delivery task processing method in any of the above embodiments.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
The integrated unit in the above embodiments, if implemented in the form of a software functional unit and sold or used as a separate product, may be stored in the above computer-readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing one or more computer devices (which may be personal computers, servers, network devices, or the like) to execute all or part of the steps of the mobile application delivery task processing method according to the embodiments of the present application.
In the above embodiments of the present application, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
In the several embodiments provided in the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is only a logical division, and in actual implementation, there may be another division, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, and may also be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution provided in the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.
Claims (10)
1. A mobile application delivery task processing method, characterized in that the method comprises:
acquiring a delivery processing request uploaded by a user, wherein the delivery processing request carries a target subtask to be delivered and applied, a time point for executing the target subtask and a target key element to be processed of the target subtask;
acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at the time point to obtain a target processing result;
under the condition that the target processing result meets a preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow;
and acquiring a second processing strategy of the next subtask until the target task flow is completed, and acquiring a processing result of the mobile application at each task stage in the delivery process.
2. The method according to claim 1, wherein when the target subtask is a product requirement, the target key element is requirement information to be evaluated, the target processing result is a quality evaluation result after the requirement information to be evaluated is evaluated, and when the target processing result meets a preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow comprises:
acquiring a judgment rule set, wherein the judgment rule set is the preset requirement;
under the condition that the quality evaluation result does not fall into the judgment rule set, acquiring the target task process where the product demand is located at present;
and acquiring the next subtask of the product requirement from the target task flow as a next object to be executed.
3. The method according to claim 1, wherein when the target subtask is server development, the target key element is a development interface, the target processing result is interface feedback information after the development interface is determined, and when the target processing result meets a preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow includes:
acquiring original associated parameters of a current development interface, wherein the original associated parameters are the preset requirements;
under the condition that the interface feedback information is consistent with the original correlation parameters, acquiring the target task process where the server side is currently developed;
and acquiring a next subtask developed by the server side from the target task flow as a next object to be executed.
4. The method according to claim 1, wherein when the target subtask is a web page design, the target key element is diagram information, the target processing result is a current diagram identified from the diagram information, and when the target processing result meets a preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow includes:
acquiring a target effect graph and a target cutting graph, wherein the target effect graph and the target cutting graph are the preset requirements;
under the condition that the similarity among the current graph, the target effect graph and the target tangent graph is larger than a similarity threshold value, acquiring the target task flow where the webpage design is currently located;
and acquiring the next subtask of the webpage design from the target task flow as a next object to be executed.
5. The method according to claim 1, wherein when the target subtask is a development test, the target key element is a test case, the target processing result is a test result obtained by processing the test case, and when the target processing result meets a preset requirement corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and obtaining a next subtask of the target subtask from the target task flow includes:
acquiring a first preset threshold and a second preset threshold, wherein the first preset threshold is a numerical value which can be completely covered by the test case, and the second preset threshold is the maximum value of the number of the test cases which are allowed to have faults;
taking the first preset threshold and the second preset threshold as the preset requirements, and acquiring the target task process where the development test is currently located under the condition that the number of the test results is greater than or equal to the first preset threshold and the number of the test results representing faults is less than or equal to the second preset threshold;
and acquiring the next subtask of the development test from the target task flow as a next object to be executed.
6. The method according to claim 1, wherein when the target subtask is demand verification, the target key element is demand value data after being online, the target processing result is an estimated result after quantizing the demand value data, and when the target processing result meets a preset demand corresponding to the target subtask, determining a target task flow corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow comprises:
acquiring an expected value to be reached, wherein the expected value to be reached is the preset requirement;
under the condition that the difference value between the estimated result and the expected value to be reached is smaller than a preset threshold value, acquiring the target task process where the requirement verification is currently located;
and acquiring the next subtask with the requirement verification from the target task flow as a next object to be executed.
7. The method of any of claims 1 to 6, further comprising:
monitoring the task processing progress of each subtask in the target task flow according to a preset frequency;
judging whether each subtask has task processing delay or not by combining the reference progress in the target system;
and sending prompt information under the condition that any subtask is determined to have task processing delay.
8. A mobile application delivery task processing apparatus, characterized in that the apparatus comprises:
the delivery processing method comprises the steps that an obtaining module is used for obtaining a delivery processing request uploaded by a user, wherein the delivery processing request carries a target subtask of an application to be delivered, a time point for executing the target subtask and a target key element to be processed of the target subtask;
the processing module is used for acquiring a first processing strategy corresponding to the target subtask, and processing the target key element by using the first processing strategy at the time point to obtain a target processing result;
the determining module is used for determining a target task flow corresponding to the target subtask under the condition that the target processing result meets a preset requirement corresponding to the target subtask, and acquiring a next subtask of the target subtask from the target task flow;
and the obtaining module is used for obtaining a second processing strategy of the next subtask until the target task flow is completed, and obtaining a processing result of the mobile application at each task stage in the delivery process.
9. An electronic device comprising a processor, a communication interface, a memory and a communication bus, wherein said processor, said communication interface and said memory communicate with each other via said communication bus,
the memory for storing a computer program;
the processor for performing the method steps of any one of claims 1 to 7 by running the computer program stored on the memory.
10. A computer-readable storage medium, in which a computer program is stored, wherein the computer program realizes the method steps of any one of claims 1 to 7 when executed by a processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211317008.1A CN115587041A (en) | 2022-10-26 | 2022-10-26 | Mobile application delivery task processing method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211317008.1A CN115587041A (en) | 2022-10-26 | 2022-10-26 | Mobile application delivery task processing method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115587041A true CN115587041A (en) | 2023-01-10 |
Family
ID=84781490
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211317008.1A Pending CN115587041A (en) | 2022-10-26 | 2022-10-26 | Mobile application delivery task processing method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115587041A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117472478A (en) * | 2023-12-22 | 2024-01-30 | 科大讯飞股份有限公司 | Automatic flow generation method, related device and system, equipment and storage medium |
-
2022
- 2022-10-26 CN CN202211317008.1A patent/CN115587041A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117472478A (en) * | 2023-12-22 | 2024-01-30 | 科大讯飞股份有限公司 | Automatic flow generation method, related device and system, equipment and storage medium |
| CN117472478B (en) * | 2023-12-22 | 2024-04-26 | 科大讯飞股份有限公司 | Automatic flow generation method, related device and system, equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108984418B (en) | Software test management method and device, electronic equipment and storage medium | |
| US6601017B1 (en) | Process and system for quality assurance for software | |
| US9170821B1 (en) | Automating workflow validation | |
| US20130339933A1 (en) | Systems and methods for quality assurance automation | |
| CN112101803A (en) | Business process monitoring method, device, system, equipment and medium | |
| US20220197770A1 (en) | Software upgrade stability recommendations | |
| CN103186463B (en) | Determine the method and system of the test specification of software | |
| CA3034830A1 (en) | Validation of test results in network testing | |
| CN113238930A (en) | Software system testing method and device, terminal equipment and storage medium | |
| CN115587041A (en) | Mobile application delivery task processing method and device, electronic equipment and storage medium | |
| Amland et al. | Risk based testing and metrics | |
| CN111858354A (en) | Method and device for automatically generating test report, storage medium and electronic equipment | |
| CN116089220A (en) | Index inspection method and device based on operating system and electronic equipment | |
| CN113505895B (en) | Machine learning engine service system, model training method and configuration method | |
| CN101719091A (en) | Method and monitoring system for the rule-based monitoring of a service-oriented architecture | |
| CN113094251B (en) | Method and device for testing embedded system, computer equipment and storage medium | |
| CN117495544A (en) | Sandbox-based wind control evaluation method, sandbox-based wind control evaluation system, sandbox-based wind control evaluation terminal and storage medium | |
| CN112162908A (en) | Program call link monitoring implementation method and device based on bytecode injection technology | |
| CN111222942A (en) | Data processing method and device, readable medium and electronic equipment | |
| CN116599881A (en) | Cloud platform tenant modeling test method, device, equipment and storage medium | |
| CN110990249A (en) | Code scanning result processing method and device, computer equipment and storage medium | |
| CN109669829A (en) | A kind of diagnosis adjustment method, device and server based on BMC | |
| CN114862517A (en) | Automobile leasing method and device based on block chain | |
| CN114969175A (en) | Method for butting insurance platform and external system and related equipment | |
| CN114185798A (en) | Interface test case detection method and device, computer equipment and storage medium |
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 |