CN116204446A

CN116204446A - Automatic test flow management method and device based on JIRA platform

Info

Publication number: CN116204446A
Application number: CN202310501803.4A
Authority: CN
Inventors: 苑书荣
Original assignee: Accumulus Technologies Tianjin Co Ltd
Current assignee: Accumulus Technologies Tianjin Co Ltd
Priority date: 2023-05-06
Filing date: 2023-05-06
Publication date: 2023-06-02
Anticipated expiration: 2043-05-06
Also published as: CN116204446B

Abstract

The invention provides a testing flow automatic management method and device based on a JIRA platform, wherein the method comprises the following steps: monitoring a JIRA platform to acquire task information of newly-added demand tasks; determining whether a test task corresponding to the required task exists in the test platform according to the task number; if not, creating a test task; configuring and executing a test task; performing the test tasks includes: operating a first case manually written by a tester; running a second use case associated therewith; receiving and storing bug information input by a tester, synchronizing the bug information to a JIRA platform, and associating with a demand task; judging whether bug information under a demand task is closed or not; if yes, determining that the test task is finished. Therefore, by coupling the JIRA with the test platform and automatically executing each test node, the problem that a tester needs to manually switch between the JIRA platform and the test platform frequently in the test process can be avoided, and the test efficiency and the test accuracy are improved.

Description

Automatic test flow management method and device based on JIRA platform

Technical Field

The embodiment of the invention relates to the technical field of databases, in particular to a method and a device for automatically managing a test flow based on a JIRA platform.

Background

In the project management process, test flow management is an indispensable link. The test flow typically includes numerous test nodes for use case writing, use case review, use case execution, bug submission, bug regression, etc. Currently, the test flow may be managed by JIRA management project flow. However, this approach has certain drawbacks: in the test links, the state change of each step is required to be modified manually, an automatic means is absent, and whether each link is processed in time in the test process cannot be perceived, so that the whole test flow is time-consuming, poor in experience and easy to make mistakes.

Disclosure of Invention

The embodiment of the invention provides a JIRA platform-based automatic test flow management method and a JIRA platform-based automatic test flow management device, which are used for solving the technical problems that in the related art, in test links, the state change of each step needs to be modified manually, an automatic means is absent, and whether each link is processed in time or not in the test process is not perceived, so that the whole test flow is time-consuming, poor in experience and easy to make mistakes.

In order to solve the technical problems, the embodiment of the invention is realized as follows:

in a first aspect, an embodiment of the present invention provides a method for automatically managing a test flow based on a JIRA platform, where the method includes:

Monitoring a JIRA platform to acquire task information of newly-added demand tasks; the task information of the demand task comprises: task numbering;

determining whether a test task corresponding to the required task exists in the test platform according to the task number;

if not, creating a test task corresponding to the required task according to the task information;

configuring the test task; after the test task is configured, executing the test task;

wherein performing the test task comprises:

operating a first case manually written by a tester;

running a second use case associated with the first use case; the second use case is an automation use case corresponding to each scene under a field of the associated automation scene ID in the task information of the test task;

receiving and storing bug information input by the tester, synchronizing the bug information to the JIRA platform, and associating the bug information with the requirement task; the bug information is determined by the tester according to the operation results of the first use case and the second use case;

judging whether all bug information under the demand task is closed or not;

If yes, determining that the test task is executed.

Preferably, configuring the test task comprises the steps of:

the writing step of the use case: receiving a use case writing instruction of the tester, and generating the first use case according to the use case writing instruction;

use case association step: associating the first instance with the second instance;

use case review step:

sending the first case to a case reviewer;

obtaining a final review result;

and if the final review result is that the review is not passed, the first user is sent to a user review person again, and the final review result is obtained until the final review result is that the review is passed.

Preferably, the task information of the demand task further includes: a test scheme link field, a status field; after performing the use case writing step, the method further includes:

receiving a use case synchronization instruction of the tester;

according to the use case synchronization instruction, the URL address of the first case is synchronized to the test scheme link field in the task information of the required task in the JIRA platform;

and modifying the status field in the task information of the demand task into a case writing completion.

Preferably, the task information of the test task includes: the function module is associated with an automation scene ID; the use case association step comprises the following steps:

inquiring the IDs of all associated modules associated with the function module in a module configuration table according to the ID of the function module;

according to the IDs of all the association modules, determining a first test scene ID of the P0 level corresponding to each association module;

determining a second test scene ID of the P0 level and a third test scene ID of the P1 level corresponding to the belonging functional module according to the ID of the belonging functional module;

determining a field value of the associated automation scene ID as: and the character strings spliced by the first test scene ID, the second test scene ID and the third test scene ID are used for realizing the association of the first case and the second case.

Preferably, the final review results include at least one of: pass and fail the review;

wherein the review failed includes at least one of:

the review rate is less than 100%, wherein the review rate=number of records/number of people to be reviewed;

the evaluation rate reaches 100%, but the evaluation passing rate does not reach 100%;

The evaluation rate and the evaluation passing rate reach 100%, but the evaluation duration of at least one evaluation record does not reach the standard duration;

the evaluation passes include: the evaluation rate and the evaluation passing rate reach 100%, and the evaluation duration of each evaluation record reaches the standard duration.

Preferably, the task information of the test task includes: the status of the device is reviewed in order to,

and under the condition that the final review result is that the review passes, changing the field value of the review state in the task information of the test task into a preset value.

Preferably, the task information of the test task includes: the bug state, after judging whether all bug information under the demand task is closed, the method further comprises:

if yes, changing the field value of the bug state in the task information of the test task into a preset value.

Preferably, the method further comprises:

checking the required tasks of the online version number in a preset time period on the JIRA platform at regular time;

determining whether a test scheme link field in task information of each required task in a preset time period has a value of the online version number;

if the test scheme link field has a no-value requirement task, a prompt message is sent to the tester; the prompt message is used for prompting the testers, and the test scheme link field is not directed to the no-value demand task writing use case.

In a second aspect, an embodiment of the present invention provides a JIRA platform-based automatic test flow management apparatus, where the apparatus includes:

the monitoring module is used for monitoring the JIRA platform to acquire task information of the newly-added demand task; the task information of the demand task comprises: task numbering;

the determining module is used for determining whether a test task corresponding to the required task exists in the test platform according to the task number;

the creating module is used for creating a test task corresponding to the required task according to the task information if the test task does not exist;

the configuration module is used for configuring the test task;

the execution module is used for executing the test task after the test task is configured;

the execution module is also used for running a first user manually written by a tester;

Judging whether all bug information under the demand task is closed or not;

if yes, determining that the test task is executed.

Preferably, the configuration module is configured to receive a case writing instruction of the tester, and generate the first case according to the case writing instruction; associating the first instance with the second instance; sending the first case to a case reviewer; obtaining a final review result; and if the final review result is that the review is not passed, the first user is sent to a user review person again, and the final review result is obtained until the final review result is that the review is passed.

Preferably, the task information of the demand task further includes: a test scheme link field, a status field;

the apparatus further comprises: the receiving module is used for receiving the use case synchronization instruction of the tester after the use case writing step is executed;

the synchronization module is used for synchronizing the URL address of the first user into the test scheme link field in the task information of the required task in the JIRA platform according to the use case synchronization instruction;

and the modification module is used for modifying the status field in the task information of the demand task into the case writing completion.

Preferably, the task information of the test task includes: the function module is associated with an automation scene ID; the configuration module is used for inquiring the IDs of all associated modules associated with the affiliated functional module in a module configuration table according to the IDs of the affiliated functional module;

wherein the review failed includes at least one of:

Preferably, the task information of the test task includes: review status, the apparatus further comprising:

and the first changing module is used for changing the field value of the review state in the task information of the test task into a preset value under the condition that the final review result is that the review passes.

Preferably, the task information of the test task includes: the status of the bug is that,

the apparatus further comprises:

and the second changing module is used for changing the field value of the bug state in the task information of the test task into a preset value after all bug information under the demand task is closed.

Preferably, the monitoring module is further configured to check, at regular time, a demand task of an online version number on the JIRA platform within a preset time period;

the determining module is further configured to determine whether a test scheme link field in task information of each required task of the online version number in a preset time period has a value;

The apparatus further comprises:

the prompt module is used for sending prompt information to the tester if a test scheme link field has no-valued demand task; the prompt message is used for prompting the testers, and the test scheme link field is not directed to the no-value demand task writing use case.

In a third aspect, an embodiment of the present invention provides an electronic device, including: a processor, a memory, and a program stored on the memory and executable on the processor, which when executed by the processor, performs the steps of a JIRA platform-based method of test flow automatic management as described in the first aspect.

In a fourth aspect, an embodiment of the present invention provides a computer readable storage medium having a computer program stored thereon, where the computer program when executed by a processor implements the steps of a method for automatic management of a test flow based on a JIRA platform according to the first aspect.

Therefore, after the newly added demand task on the JIRA platform is monitored, the corresponding test task is automatically created on the test platform, the test task is configured, the test task is executed, and when the test task is executed, not only the use case written manually but also the associated automatic use case can be executed automatically, so that the omission of the use case can be avoided, and the test is more comprehensive. The bug information can be automatically synchronized to the JIRA platform, and the completion of the test task is determined under the condition that all bug information under the demand task is closed. By coupling the JIRA with the test platform and automatically executing each test node, the need of frequent manual switching between the JIRA platform and the test platform by a tester in the test process can be avoided, the dependence on manpower can be reduced, the test efficiency can be improved, and the test accuracy can be improved.

Drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to designate like parts throughout the figures. In the drawings:

fig. 1 is a flowchart of a test flow automatic management method based on a JIRA platform according to an embodiment of the present invention;

fig. 2 is a flowchart of a JIRA platform-based test flow automatic management method according to an embodiment of the present invention;

FIG. 3 is a flowchart of a method for automatically managing a testing process based on a JIRA platform according to an embodiment of the present invention;

fig. 4 is a flowchart of a JIRA platform-based test flow automatic management method according to an embodiment of the present invention;

fig. 5 is a flowchart of a JIRA platform-based test flow automatic management method according to an embodiment of the present invention;

fig. 6 is a block diagram of a JIRA platform-based automatic management device for testing process according to an embodiment of the present invention;

fig. 7 is a block diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Fig. 1 shows a JIRA platform-based test flow automatic management method according to an embodiment of the invention, where the method includes:

step S101, monitoring a JIRA platform to acquire task information of a newly added demand task; the task information of the demand task comprises: task numbering;

step S102, determining whether a test task corresponding to a demand task exists in the test platform according to the task number;

step S103, if the task information does not exist, a test task corresponding to the required task is created according to the task information;

step S104, configuring a test task;

step S105, after the test task is configured, executing the test task;

it should be noted that, in the embodiment of the present invention, the front end uses the reaction, the back end uses the java language, the database adopts the relational database mysql, the visual icon adopts the Echart, the message notification can dock the enterprise WeChat, the timing task adopts the spring boot @ schedule, and the front end and the back end communicate in a mode of combining websocket and http. But are merely exemplary and are not to be construed as limiting embodiments of the present invention.

In step S101 to step S103, first, a product responsible person takes charge of creating a demand task on the JIRA, and configuring demand basic information includes: task name, belonging function module, product responsible person, development responsible person, test responsible person, on-line version number (date format can be adopted, such as 20230216), test scheme link field (initial value is null), after creation is completed, JIRA will automatically generate 1 task number. It is understood that in step S101, the task information of the demand task may include the task number and the configured demand basic information. Then, task management service needs to be tested in the test platform, preferably, task information of tasks newly added daily (which can be also configured to be obtained in real time) can be obtained at regular time, whether corresponding test tasks exist in the test platform or not is queried according to task numbers, and if the corresponding test tasks do not exist, the corresponding test tasks are automatically created on the test platform. Therefore, the newly created demand task is acquired by monitoring JIRA, the corresponding test task can be automatically created to the test platform, and the manual creation of a tester is not needed.

Wherein, as shown in table 1, the test task contains the fields: task number (task_id, task number consistent with the task number of the demand task in JIRA), name (name, task name consistent with the demand task in JIRA), function module (module, function module consistent with the demand task in JIRA), content (task_context, default to null), test responsible person (test responsible person consistent with the demand task in JIRA), review status (review_status, default to 0, i.e., representative of "not review"), bug status (bug_status, default to 0, i.e., representative of "not closed"), associated automation scene ids (default to null), and after creation, the test task table shown in table 1 may be saved to the database. The test task includes a field, i.e., task information of the test task described later.

TABLE 1

It should be noted that, the task information of the newly-added demand task may be obtained through a rest pi interface of the interfacing JIRA, and the timing task (task information of the newly-added demand task is obtained at a timing) may be obtained through @ Scheduled of java.

In one possible implementation manner, the step S104, configuring the test task includes the following steps:

the writing step of the use case: receiving a use case writing instruction of a tester, and generating a first use case according to the use case writing instruction;

use case review step: the first case is sent to a case reviewer; obtaining a final review result; if the final review result is that the review is not passed, the first user is sent to the user review personnel again, and the final review result is obtained until the final review result is that the review is passed. The case writing step, the case associating step and the case review step are sequentially executed.

In the case writing step, a tester can manually write the case under the corresponding test task of the test platform (for example, the case writing can be performed in the form of a thinking guide diagram), or upload the case of the local brain diagram to the test platform. And the use case content is updated in json form into the task_context field of the test task table.

It should be noted that, after the online use case is written and changed from the integrated jsmind in the related technology to the integrated hundred-degree brain graph KityMinder, the pictures uploaded by the local xmind use case are imported into the test platform, the analysis can be successfully performed, and the use experience of the user is improved.

In one possible implementation, the front end of the test platform adopts a reaction framework, and the on-line management of the thinking guide graph is realized through integrating the hundred-degree brain graph KityMinder. And the storage speed can be improved by adding front-end cache and websocket services. First, each modification of the mind map may be saved to the front-end cache store first, without having to call the HTTP interface to submit the modification to the back-end each time, which may reduce the interface request frequency and thus reduce network traffic. And when the connection disconnection is monitored, the storage interface of websocket can be automatically called, and the content stored in the front-end cache store is submitted to the rear end by calling the interface for 1 time, so that the storage speed is improved.

In one possible implementation manner, the task information of the demand task further includes, in one possible implementation manner: test scenario link field, status field as shown in fig. 2, after performing the use case writing step, the method further includes:

Step S201, receiving a use case synchronization instruction of a tester;

step S202, according to a use case synchronization instruction, the URL address of a first use case is synchronized to a test scheme link field in task information of a demand task in a JIRA platform;

step S203, the state field in the task information of the demand task is modified into a case writing completion.

In an exemplary application scenario, after a tester writes a use case (first use case), the tester may click on a "write complete" button on the test platform, and after clicking, the test platform automatically updates the URL address of the current use case into the "test plan link" field under the JIRA requirements task. In addition, the state of JIRA can be automatically modified into 'use case writing completion'; and send the use case review links to each reviewer (other than the person responsible for the test); after the review link is sent, the JIRA state can be modified into 'test case review', and the test case review can be automatically completed without manual operation, so that the operation efficiency and the operation accuracy are improved.

It should be noted that, the use case management service may encapsulate and send the message notification method by interfacing with the enterprise WeChat API or the interfaces of the rest of the message notification tools, so as to achieve the purpose of timely informing the test progress and status to the test related personnel.

It should be noted that, in a specific implementation, the front end of the test platform may add an onclick event to the "write complete" button, where the onclick is used to specify a script executed during event triggering, and when the event triggering is performed, the use case management service modifies the task field and the state of the JIRA through the update interface of the rest api of the encapsulated JIRA, and may invoke the encapsulated enterprise WeChat sending message notification interface to implement sending a message notification to a designated person, where a review link is attached to the message notification.

In the case association step, in one possible implementation manner, the task information of the test task includes: the function module is associated with an automation scene ID; as shown in fig. 3, the use case association step includes:

step S301, according to the ID of the function module, inquiring the IDs of all the associated modules associated with the function module in a module configuration table;

step S302, determining a first test scene ID of the P0 level corresponding to each association module according to the IDs of all the association modules;

step S303, determining a second test scene ID of the P0 level and a third test scene ID of the P1 level corresponding to the belonging function module according to the ID of the belonging function module;

Step S304, determining a field value of the associated automation scene ID as: the character strings spliced by the first test scene ID, the second test scene ID and the third test scene ID are used for realizing the association of the first use case and the second use case.

After the test platform automatically creates the test task, the IDs of all the associated modules can be queried according to the module configuration table (the module configuration table can maintain the association relation among the functional modules) shown in the table 2, then all the P0-level test scene IDs of all the associated modules are queried, then the P0-level test scene IDs and the P1-level test scene IDs corresponding to the current 'functional module' ID are queried, all the scene IDs are spliced into character strings by comma separation, and the character strings are updated into an 'auto_scene_ids' field of the corresponding test task, so that the association of manual test and automatic use cases is realized.

TABLE 2

It should be noted that, in the test platform, each test scenario needs to be configured with "belonging function module" and "level". Wherein, P0 is a module core service, and P1 is an important service. The automatic use case selection rule is as follows: the related module only selects the core function (P0 level) and the function module to which the current test task belongs, and simultaneously selects the core function and the important function (P0 and P1 level), so as to ensure that the change of the current test task does not influence all functions of the current module and the main flow of the related module.

In the use case review step, the final review results include at least one of: pass and fail the review; wherein review failed includes at least one of: the review rate does not reach 100%, where the review rate=number of records/number of people to be reviewed; the evaluation rate reaches 100%, but the evaluation passing rate does not reach 100%; the evaluation rate and the evaluation passing rate reach 100%, but the evaluation duration of at least one evaluation record does not reach the standard duration; the review includes: the evaluation rate and the evaluation passing rate reach 100%, and the evaluation duration of each evaluation record reaches the standard duration.

The review process will now be described in detail. After receiving the message notification, the panelist clicks the panelist link address and can jump to a panelist page of the test platform, the panelist can input the name and the comment of the panelist on the panelist page, and after whether the comment passes or not, the panelist can click a submit button and store the comment in the database. Review record table as shown in table 3, a review record may include 5 fields: task number (task_id, through which field is associated with the test task), reviewer (reviewer), reviewer identity tag (identity_flag, exemplary: product 1, front 2, back 3), review opinion (context), review status (status, exemplary: reviewer checks "pass", then the value is 1, checks "no pass", then the value is 0), and review duration (from the record of the front end of the reaction). And one scenario is considered less only as an exemplary illustration and not as a limitation on the review of the present application.

TABLE 3 Table 3

It should be noted that, in one possible implementation manner, the user may automatically enter the review page by clicking the review link address, after entering the review page, the front end reaction may automatically record the current time as begin_time, when the reviewer clicks the "submit" button, the front end reaction may automatically record the current time as end_time, calculate the difference between end_time and begin_time, convert the difference into a second assignment, submit the second assignment to the duration to the rear end use case management service, and save the second assignment to the duration field of the review record, so as to automatically record the review duration.

It should be noted that, in one possible implementation manner, corresponding to the possible situations of the final review result, the online version number may be queried for the review record corresponding to each test task within the current week date range through the timing task @ Scheduled, and the following four cases are processed:

1. judging whether the current test task has a review record or not, if not, sending a 'non-review' message notice to all reviewers;

2. if the current test task has a review record, the review rate is calculated by using the review record number/the review number, and if the review rate is less than 75% (or a preset threshold value), a message notification of 'no review' is sent to the review persons which do not participate in the review.

3. If the number of the panelists of the current test task reaches the standard, further judging the pass rate of the panelists: that is, whether the states of all the review records are 1 is judged, if the states are 1, all the reviews are considered to pass, the review passing rate=100%, if the records with the review states of 2 exist in table 3, the reviews are considered to fail, a message notification of 'review fail' is sent to the tester, and review comments of the failed review records are attached.

4. If the number of the current test task is up to standard and the evaluation passing rate=100%, further judging whether the evaluation time length of each evaluation record is more than or equal to 120s (or a preset threshold value), if so, considering that the evaluation is passed and effective, and automatically modifying the JIRA state to 'use case evaluation passing' by modifying the review_status of the test task to 1 (evaluation passing) and calling the RESTAPI interface of the JIRA.

It should be noted that, in table 3, the group search is performed through sql according to the identity tag identity_flag of the panelist, if the number of each group is greater than 1, it means that at least 1 person participates in the panelist, and the panelist is considered to reach the standard, and if one or more flag group search results are zero, the panelist is considered to not reach the standard.

It should be noted that the review time period can be set according to daily experience, and at least 2 minutes are required according to daily test experience from when a reviewer opens a page to when all test points are browsed, and the middle thinking time. Therefore, the monitoring time length can be set to 120s, and the setting of the monitoring time length can further ensure that the reviewer carefully views and reviews the use cases, and ensure the accuracy of the use cases.

In one possible implementation, the task information of the test task further includes: and a review state, wherein when the final review result is that the review passes, the field value of the review state in the task information of the test task can be changed to a preset value (e.g. in the fourth case, the review_status field of the test task can be changed to 1).

It should be noted that, after the test task is configured, the test task may be executed. In one possible implementation, as shown in fig. 4, step S105, performing a test task includes:

step S401, operating a first case manually written by a tester;

step S402, running a second use case associated with the first use case;

the second use case is an automation use case corresponding to each scene under a field of the associated automation scene ID in task information of the test task;

Step S403, receiving and storing bug information input by a tester, synchronizing the bug information to a JIRA platform, and associating the bug information with a demand task;

the bug information is determined by a tester according to the operation results of the first use case and the second use case;

step S404, judging whether all bug information under the demand task is closed;

and step S405, if the bug information under the demand task is closed, determining that the test task is finished.

A further description of a possible implementation is shown in fig. 4. After entering the test execution stage, the tester executes a manual test case (first case), if a problem is found, the tester can input bug information in the pop-up window by clicking a bug input button, the bug grade is selected, the bug information and the bug grade can be automatically saved in a database (shown in a bug information table in table 4), and the bug information and the bug grade can be synchronized under a JIRA corresponding requirement task at regular time. The bug information table shown in table 4 includes: task number (task_id, consistent with test task), content (text, content entered for tester), level, sync status (default to 0, i.e. "not synchronized").

TABLE 4 Table 4

In one possible implementation, automatically synchronizing bug information to the JIRA platform may be accomplished by: the bug content is obtained by checking regularly "unsynchronized" bugs under the current test task @ Scheduled, then creating a defect issue under the JIRA corresponding demand task by calling the JIRA's rest pi interface (corresponding to the above: synchronizing bug information to the JIRA platform, then associating with demand task), and then modifying the synchronization status syncStatus in table 4 to 1, which represents "synchronized".

In one possible implementation, the task information of the test task includes: the bug state, after judging whether all bug information under the demand task is closed, the method further comprises: if yes, changing the field value of the bug state in the task information of the test task into a preset value. That is, the bug_status in table 1 is modified from the default value of 0 to 1. In a specific implementation, all demand tasks with the line version numbers in the current week range on JIRA can be queried through a timing task @ schedule, whether the bug under the demand task is closed or not is judged, if yes, the bug state (bug_status) of the test platform corresponding to the test task is modified to be 1, namely, bug closing is represented.

It should be noted that, in one possible implementation manner, the test task on line in the week (or within a preset period) of the test platform may be queried through a timing task @ schedule, whether the test task review status (review_status) in table 1 is first judged, if yes, whether the bug status (bug_status) in table 1 is further judged, if yes, the test is considered to be completed, a test report may be generated, where the test report generates a summary chart through a compact integrated Echart, and the test report link is sent to related personnel through enterprise WeChats (or other communication tools), and the test report may include: task name, number of cases, number of failed cases fail details, and then the rest pi interface of JIRA is tuned to set the JIRA status to "test complete".

In one possible implementation, after the manual use case is executed, the tester may click on the "execute complete" button, obtain "associated automation scene ids" under the current test task, and then automatically execute the test use cases (second use case) under these test scenes, and if there is a failed use case in the execution process, call the rest pi interface of JIRA to automatically create a corresponding defect under the JIRA's requirement task, and mark as "automation use case discovery" so as to distinguish the defect from the manually written use case.

When the method is specifically implemented, a front-end reaction adds an onclick click event to an execution completion button, and when the event is triggered, a rear-end use case management service obtains the values of auto_scene_ids (each id is separated by an English comma) under a current test task from a database through a query interface, then stores the values into an array according to the test scene ids separated by the English comma, traverses the array, and invokes an execution engine of a test platform to execute all use cases in a test scene in sequence. In the process of executing the use cases, the execution result of each use case can be observed in real time, if the result is failure, a RESTAPI interface of the JIRA is called to create defects under the requirement tasks corresponding to the JIRA, and the defects are marked as 'automatic use case discovery', so as to distinguish the defects of the use cases written manually.

In one possible implementation, as shown in fig. 5, the method further includes:

step S501, checking the required tasks of the online version number in a preset time period on a JIRA platform at fixed time;

step S502, determining whether a test scheme link field in task information of each required task in a preset time period has a value or not;

step S503, if there is a demand task with no value in the test scheme link field, a prompt message is sent to a tester;

The prompt message is used for prompting a tester, and the use case is not written for the demand task with no value in the test scheme link field.

In an exemplary application scenario, the task @ Scheduled may be timed, for example: every week, starting from nine am on Wednesday, once every hour, (assuming that the four days of the week are on the line, that is, the day before the line is on), checking whether all the on-line version numbers on JIRA are the required tasks within the current week date range, checking whether the 'test scheme link' field has a value, if not, sending a message notification of 'not-written use case' to 'test responsible person', and reminding the test responsible person to write the use case in time so as to avoid delaying the test.

It should be noted that a timing automatic compensation mechanism can be added to re-execute the missing or failed test task, so as to prevent omission.

In an embodiment of the invention, the test service checks the creation of JIRA demand tasks through the listening service; the test platform can be linked with mysql to persist the corresponding test task into the database; the use case storage speed is improved through caching and websocket; the message center can send message notification through enterprise WeChat; the monitoring service can be responsible for verifying the validity of each test node, calling a message center to timely send a message to relevant personnel for illegal nodes and nodes which are not timely processed, avoiding influencing the operation progress of a team due to personal factors, and ensuring the timely completion of the test. The test service can modify the JIRA task by interfacing with the RESTAPI interface of JIRA; the front end can realize data visualization by inquiring the result of the database.

The embodiment of the invention can realize automatic creation of the test task, automatic synchronization of the use cases and automatic transmission of the review links; the association between the manual use cases and the automatic use cases can be realized by setting the module configuration table, and the associated automatic use cases can be automatically executed after the manual use cases are executed; on-line review of use cases can be realized, automatic modification of JIRA state can be realized, manual defects can be automatically synchronized to JIRA, and automatic use case related defects can be automatically created; the validity of the evaluation can be automatically calculated through the participation of the evaluation people, the evaluation result and the evaluation time, whether the test is ended or not is automatically judged through the evaluation state and the bug state (whether the bug is closed or not), whether the JIRA state is modified to be the test completion or not can be determined according to the judgment result, so that seamless connection between the JIRA and a test platform in the whole test process is realized, the automation of the whole test process is realized, the manual JIRA operation of a tester is reduced, and the operation efficiency and the operation accuracy are improved.

The embodiment of the present invention further provides a JIRA platform-based automatic test flow management device 60, as shown in fig. 6, where the device 60 includes:

the monitoring module 601 is configured to monitor a JIRA platform to obtain task information of a newly added demand task; the task information of the demand task comprises: task numbering;

The determining module 602 is configured to determine, according to the task number, whether a test task corresponding to the required task exists in the test platform;

a creating module 603, configured to create a test task corresponding to the required task according to the task information if the test task does not exist;

a configuration module 604 for configuring test tasks;

the execution module 605 executes the test task after configuring the test task;

the execution module 605 is further configured to run a first case manually written by a tester;

running a second use case associated with the first use case; the second use case is an automation use case corresponding to each scene under a field of the associated automation scene ID in task information of the test task;

receiving and storing bug information input by a tester, synchronizing the bug information to a JIRA platform, and associating the bug information with a demand task; the bug information is determined by a tester according to the operation results of the first use case and the second use case;

judging whether all bug information under the demand task is closed or not;

if yes, determining that the test task is finished.

In one possible implementation manner, the configuration module 604 is configured to receive a use case writing instruction of a tester, and generate a first use case according to the use case writing instruction; associating the first instance with the second instance; the first case is sent to a case reviewer; obtaining a final review result; if the final review result is that the review is not passed, the first user is sent to the user review personnel again, and the final review result is obtained until the final review result is that the review is passed.

In one possible implementation, the task information of the demand task further includes: a test scheme link field, a status field;

the apparatus 60 further comprises: the receiving module is used for receiving the use case synchronization instruction of the tester after the use case writing step is executed;

the synchronization module is used for synchronizing the URL address of the first case to a test scheme link field in task information of a demand task in the JIRA platform according to the case synchronization instruction;

In one possible implementation, the task information of the test task includes: the function module is associated with an automation scene ID; a configuration module 604, configured to query, in a module configuration table, IDs of all associated modules associated with the associated function module according to the ID of the associated function module;

according to the ID of the function module, determining a second test scene ID of the P0 level and a third test scene ID of the P1 level corresponding to the function module;

determining a field value of the associated automation scene ID as: the character strings spliced by the first test scene ID, the second test scene ID and the third test scene ID are used for realizing the association of the first use case and the second use case.

In one possible implementation, the final review results include at least one of the following: pass and fail the review;

wherein review failed includes at least one of:

the review rate does not reach 100%, where the review rate=number of records/number of people to be reviewed;

the review includes: the evaluation rate and the evaluation passing rate reach 100%, and the evaluation duration of each evaluation record reaches the standard duration.

In one possible implementation, the task information of the test task includes: review status, the apparatus 60 further includes:

In one possible implementation, the task information of the test task includes: the status of the bug is that,

the apparatus 60 further comprises:

In a possible implementation manner, the monitoring module 601 is further configured to periodically check a requirement task of the online version number on the JIRA platform within a preset period of time;

the determining module 602 is further configured to determine whether a test scheme link field in the task information of each required task in the online version number in a preset period of time has a value;

the apparatus 60 further comprises: the prompt module is used for sending prompt information to a tester if a test scheme link field has a no-value requirement task; the prompt message is used for prompting a tester, and the use case is not written for the demand task with no value in the test scheme link field.

The embodiment of the present invention further provides an electronic device 70, as shown in fig. 7, including: the processor 701, the memory 702, and the program stored in the memory 702 and executable on the processor 701 implement the steps of a JIRA platform-based test flow automatic management method as shown in the above embodiments when the program is executed by the processor.

The embodiment of the present invention further provides a computer readable storage medium, where a computer program is stored, where the computer program when executed by a processor implements each process of the method embodiment shown in fig. 1 and achieves the same technical effects, and is not repeated herein. Wherein the computer readable storage medium is selected from Read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or optical disk.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) comprising instructions for causing a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method according to the embodiments of the present invention.

The embodiments of the present invention have been described above with reference to the accompanying drawings, but the present invention is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those having ordinary skill in the art without departing from the spirit of the present invention and the scope of the claims, which are to be protected by the present invention.

Claims

1. The automatic test flow management method based on the JIRA platform is characterized by comprising the following steps:

wherein performing the test task comprises:

operating a first case manually written by a tester;

Judging whether all bug information under the demand task is closed or not;

if yes, determining that the test task is executed.

2. The method of claim 1, wherein configuring the test task comprises the steps of:

use case review step:

sending the first case to a case reviewer;

obtaining a final review result;

3. The method of claim 2, wherein the task information of the demand task further comprises: a test scheme link field, a status field; after performing the use case writing step, the method further includes:

receiving a use case synchronization instruction of the tester;

4. The method of claim 2, wherein the task information of the test task comprises: the function module is associated with an automation scene ID; the use case association step comprises the following steps:

5. The method of claim 2, wherein the final review results comprise at least one of: pass and fail the review;

Wherein the review failed includes at least one of:

6. The method of claim 2, wherein the task information of the test task comprises: the method further comprises the steps of:

7. The method of claim 1, wherein the task information of the test task comprises: the bug state, after judging whether all bug information under the demand task is closed, the method further comprises:

8. The method according to claim 1, wherein the method further comprises:

9. A JIRA platform-based test flow automatic management apparatus, the apparatus comprising:

The configuration module is used for configuring the test task;

judging whether all bug information under the demand task is closed or not;

if yes, determining that the test task is executed.

10. An electronic device, comprising: a processor, a memory, and a program stored on the memory and executable on the processor, which when executed by the processor, implements the steps of the JIRA platform-based test flow automatic management method of any one of claims 1 to 8.

11. A computer readable storage medium, wherein a computer program is stored on the computer readable storage medium, which when executed by a processor, implements the steps of the JIRA platform-based method of test flow automatic management according to any one of claims 1 to 8.