Software product testing method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a software product testing method and device, computer equipment, a readable storage medium and a program product. The method comprises the following steps: in response to a trigger condition for starting to test target software, triggering an assembly line to obtain product construction information of the target software, starting to construct a to-be-tested current software product according to the product construction information, and adjusting the product state of the current software product to be a to-be-tested state, uploading the product attribute information of the current software product to a product library; under the condition that the product state of the current software product is a to-be-tested state, deploying the current software product to a test environment for verification, and adjusting the product state of the current software product to be an in-test state; and under the condition that the current software product cannot pass the verification of the test environment, returning to the step of triggering the assembly line to obtain the product construction information of the target software until the current software product passes the verification of the test environment. By adopting the method, the software product testing quality can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of software testing, and in particular to a software product testing apparatus, computer equipment, computer-readable storage medium and computer program product. Background Art

[0002] As the iteration speed of software development continues to increase, the complexity of software has increased significantly, and the work of software quality assurance has become extremely complicated, making it difficult to ensure the quality of software. Relevant technologies often lack a unified product management platform. During the software testing process, the development side often uses local packaging and manually transmits it to relevant personnel through instant messaging tools. This method often cannot trace the source and destination of the product, resulting in the inability to trace the source of software information, a low degree of automation, no process specification restrictions, and low quality of software product testing.

[0003] Therefore, there is a problem in the related art that the testing quality of software products is low. Summary of the invention

[0004] Based on this, it is necessary to provide a software product testing method, device, computer equipment, computer-readable storage medium and computer program product that can improve the testing quality of software products in response to the above technical problems.

[0005] In a first aspect, the present application provides a software product testing method, comprising:

[0006] In response to a trigger condition for starting the test of the target software, the pipeline is triggered to obtain the product building information of the target software, and start building the current software product to be tested according to the product building information;

[0007] When the software product is built, the product status of the current software product is adjusted to a state to be tested, and the product attribute information of the current software product is uploaded to the product library; the product status is used to determine the maturity level of the current software product;

[0008] When the product status of the current software product is in a to-be-tested state, deploying the current software product to a test environment for verification, and adjusting the product status of the current software product to a testing state;

[0009] In the case that the current software product cannot pass the verification of the test environment, return to the step of triggering the pipeline to obtain the product build information of the target software until the current software product passes the verification of the test environment.

[0010] In one embodiment, the artifact construction information includes a user story ID, and the triggering pipeline obtains the artifact construction information of the target software, including:

[0011] Obtaining the query start time; the query start time is the construction time of the most recent product status of the historical software product corresponding to the target software in the code repository being the delivery completion status;

[0012] Taking the current time as the query end time, query all code submission information within the target time period; the target time period is the time period from the query start time to the query end time;

[0013] Parse the code submission information to obtain the user story ID.

[0014] In one embodiment, the method further comprises:

[0015] In response to a trigger condition of first accessing the churn line and the artifact library, obtaining a software artifact attribute configuration for the target software;

[0016] According to the software product attribute configuration, start to build the initial software product;

[0017] When the initial software product is built, push the initial software product and adjust the product state of the initial software product to a state to be tested;

[0018] When the initial software product is pushed, the product attribute information of the initial software product is uploaded to the product library, and the product status of the initial software product is adjusted to a delivery completion status.

[0019] In one embodiment, the method further comprises:

[0020] In response to the current software product passing the acceptance of the online environment, adjusting the product status of the current software product to a delivery completion status;

[0021] When the product status of the current software product is a delivery completion status, it is determined that the maturity level of the current software product is higher than the maturity level associated with the acceptance pass status, and the merged image data request for the current software product is interrupted to prohibit overwriting and updating the current software product.

[0022] In one embodiment, the method further comprises:

[0023] In response to a product upload request initiated by an uploading user to upload a target software product to a target warehouse, obtaining user role information carried in the product upload request; the user role information is used to determine whether the uploading user has the upload permission to the target warehouse;

[0024] When the uploading user has the upload permission of the target warehouse and the target software product does not exist in the target warehouse, the target software product is determined to be a newly added software product, and the newly added software product is uploaded to the target warehouse in segments.

[0025] In one of the embodiments, the maturity level of the software product includes at least one of a first product level, a second product level, a third product level, a fourth product level and a fifth product level in order from a low maturity level to a high maturity level; the product status associated with the first product level includes at least one of a to-be-tested state, a testing state, a testing completed state or a testing failed state; the product status associated with the second product level includes at least one of a discarded state, an acceptance passed state or an acceptance failed state; the product status associated with the third product level includes a to-be-delivered state; the product status associated with the fourth product level includes a delivering state; and the product status associated with the fifth product level includes a delivery completed state.

[0026] In a second aspect, the present application also provides a software product testing device, comprising:

[0027] A construction module, configured to trigger the pipeline to obtain the product construction information of the target software in response to a trigger condition for starting the test of the target software, and start to build the current software product to be tested according to the product construction information;

[0028] An upload module, used to adjust the product status of the current software product to a state to be tested when the software product is built, and upload the product attribute information of the current software product to a product library; the product status is used to determine the maturity level of the current software product;

[0029] A deployment module, configured to deploy the current software product to a test environment for verification and adjust the product status of the current software product to a testing state when the product status of the current software product is in a to-be-tested state;

[0030] The test module is used to return to the step of triggering the pipeline to obtain the product building information of the target software when the current software product fails to pass the verification of the test environment, until the current software product passes the verification of the test environment.

[0031] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0032] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the above method when executed by a processor.

[0033] In a fifth aspect, the present application also provides a computer program product, including a computer program, which implements the steps of the above method when executed by a processor.

[0034] The software product testing method, apparatus, computer equipment, computer-readable storage medium and computer program product described above trigger the pipeline to obtain the product construction information of the target software in response to the trigger condition for starting the test of the target software, and start to build the current software product to be tested according to the product construction information; when the software product construction is completed, the product state of the current software product is adjusted to the state to be tested, and the product attribute information of the current software product is uploaded to the product library; the product state is used to determine the maturity level of the current software product; when the product state of the current software product is the state to be tested, the current software product is deployed to the test environment for verification, and the product state of the current software product is adjusted to the state under testing; when the current software product is in the state to be tested, the current software product is deployed to the test environment for verification, and the product state of the current software product is adjusted to the state under testing; When the product fails to pass the verification of the test environment, the step of triggering the pipeline to obtain the product build information of the target software is returned until the current software product passes the verification of the test environment. In this way, the product status of the software product is updated in real time in combination with the test stage in which the software product is located, and the maturity of the software product is identified by the product status, so as to effectively manage the maturity of the software product, and effectively make a software product from development to delivery as a product, reduce repeated construction, repeated testing and repeated storage, so that each product is guaranteed by testing, avoid developers sending products privately through instant messaging tools, effectively trace the life cycle of software products and the maturity process of software products, and improve the testing quality of software products. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0036] FIG1 is an application environment diagram of a software product testing method in one embodiment;

[0037] FIG2 is a system function diagram of a software product testing system according to an embodiment;

[0038] FIG3 is a schematic diagram of the architecture of a software product testing system in one embodiment;

[0039] FIG4 is a schematic diagram of the working process of a software product testing system in one embodiment;

[0040] FIG5 is a schematic diagram of a flow chart of a software product testing method in one embodiment;

[0041] FIG6 is a timing diagram of a software product testing method in one embodiment;

[0042] FIG7 is a schematic diagram of a software product level in one embodiment;

[0043] FIG8 is a structural diagram of a software product testing device in one embodiment;

[0044] FIG. 9 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0046] The software product testing method provided in the embodiment of the present application can be applied in the application environment shown in Figure 1. The terminal 102 communicates with the software product management system 104 through the network. The software product management system 104 can include a pipeline and a product library. In actual application, the user can initiate a request to start testing the target software through the terminal 102, and the software product management system 104 can obtain the request to start testing the target software, respond to the trigger condition of starting testing the target software, trigger the pipeline to obtain the product construction information of the target software, and start to build the current software product to be tested according to the product construction information; the software product management system 104 can adjust the product state of the current software product to the state to be tested when the software product is built, and upload the product attribute information of the current software product to the product library; the product state is used to determine the maturity level of the current software product; the software product management system 104 can deploy the current software product to the test environment for verification when the product state of the current software product is the state to be tested, and adjust the product state of the current software product to the state under testing; the software product management system 104 can return to the step of triggering the pipeline to obtain the product construction information of the target software when the current software product cannot pass the verification of the test environment, until the current software product passes the verification of the test environment. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, etc. The software product management system 104 can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. The system functions of the software product management system are shown in FIG2 , and the software product management system can be deployed using microservices, and the architecture diagram is shown in FIG3 ; in actual applications, the working process of the software product management system can be shown in FIG4 , and the working process of the software product management system will be described in detail below.

[0047] In an exemplary embodiment, as shown in FIG5 , a software product testing method is provided, which is described by taking the method applied to the software product management system 104 in FIG1 as an example, and includes the following steps S502 to S508 . Among them:

[0048] Step S502, in response to the triggering condition for starting the test of the target software, the pipeline is triggered to obtain the product building information of the target software, and starts to build the current software product to be tested according to the product building information.

[0049] The artifact construction information may include artifact metadata and artifact process data.

[0050] Among them, the product metadata may include the code repository name, code branch, code submission number (commit number), user story ID, etc.

[0051] Among them, product process data may include tester information, acceptance personnel information, acceptance environment information, etc.

[0052] In actual applications, product attributes can be divided into pipeline embedded attributes and custom attributes according to the adding method. The pipeline embedded attributes are automatically obtained and uploaded through the pipeline without user operation.

[0053] In the specific implementation, please refer to the "testing phase" in Figure 6. The software product management system responds to the trigger condition for the start of the target software testing and creates a branch related to the business branch management model; the software product management system triggers the pipeline to build the current software product to be tested.

[0054] Specifically, the software artifact management system can trigger the pipeline to obtain the artifact building information of the target software, and start building the current software artifact to be tested according to the artifact building information.

[0055] Optionally, the artifact build information includes a user story ID, triggering the pipeline to obtain the artifact build information of the target software, including: obtaining the query start time; using the current time as the query end time, querying all code submission information within the target time period; parsing the code submission information to obtain the user story ID.

[0056] The query start time is the build time of the most recent historical software product corresponding to the target software in the code repository when the product status is the delivery completion status.

[0057] The target time period is the time period from the query start time to the query end time.

[0058] In the specific implementation, in the process of triggering the pipeline to obtain the product build information of the target software, the pipeline can be triggered to obtain the user story ID; the logic for obtaining the user story ID is: the construction time of the most recent product status of the historical software product corresponding to the code repository is the delivery completion status as the start time, the current time is the end time, and all the commit information (code submission information) in this time period are parsed to obtain the user story ID. Specifically, the software product management system can obtain the query start time, use the current time as the query end time, query all the code submission information within the time period from the query start time to the query end time; parse the queried code submission information to obtain the user story ID.

[0059] Step S504, when the current software product is built, the product status of the current software product is adjusted to a waiting-for-testing status, and the product attribute information of the current software product is uploaded to the product library.

[0060] Among them, the product status is used to determine the maturity level of the current software product.

[0061] In the specific implementation, when the software product is built, the software product management system adjusts the product status of the current software product to the testing status, and uploads the product attribute information of the current software product to the product library, such as changing or adding the product attribute information of the current software product.

[0062] Step S506: when the product status of the current software product is in the waiting-for-testing state, the current software product is deployed to the test environment for verification, and the product status of the current software product is adjusted to the testing state.

[0063] In a specific implementation, when the product status of the current software product is in a waiting-for-testing state, the software product management system may deploy the current software product to a test environment for verification, and adjust the product status of the current software product to a testing state.

[0064] Step S508, when the current software product cannot pass the verification of the test environment, return to the step of triggering the pipeline to obtain the product build information of the target software until the current software product passes the verification of the test environment.

[0065] In a specific implementation, after the software product management system deploys the current software product to the test environment for verification, the software product management system can obtain the verification result of the test environment; when the verification result indicates that the current software product has passed the verification of the test environment, the software product management system adjusts the product status of the current software product to the acceptance status.

[0066] When the verification result indicates that the current software product cannot pass the verification of the test environment, the user can continue to modify the code, control the software product management system to return to step S502, and repeat steps S502, S504 and S506 until the current software product passes the verification of the test environment. The software product management system then adjusts the product status of the current software product to the acceptance status.

[0067] In an exemplary embodiment, before the target software testing begins, the method further includes: in response to the triggering conditions of the first access to the churn line and the artifact library, obtaining the software artifact attribute configuration for the target software; according to the software artifact attribute configuration, starting to build the initial software artifact; when the initial software artifact is built, pushing the initial software artifact, and adjusting the artifact status of the initial software artifact to a pending test state; when the initial software artifact is pushed, uploading the artifact attribute information of the initial software artifact to the artifact library, and adjusting the artifact status of the initial software artifact to a delivery completion state.

[0068] In the specific implementation, please refer to "First Access" in Figure 6. The software product management system can respond to the first access of the module component to the churn line and product library to obtain the software product attribute configuration for the target software; specifically, due to the lack of online version information, the software product management system can trigger the pipeline to obtain the first 500 commit information (code submission information) of the code repository, and then parse the code submission information according to the specification to obtain the user story ID. In addition, it is also necessary to configure the CI (continuous integration) process and product upload unit module in the pipeline, configure the software product attributes and their corresponding values, and the software product attributes include but are not limited to the code repository, branch, commit ID, unit test pass rate, number of medium-risk and above vulnerabilities, unit test coverage, and user story ID. The software product management system runs the pipeline so that the pipeline starts to build the initial software product according to the software product attribute configuration.

[0069] When the initial software product is built, the pipeline pushes the initial software product and adjusts the product status of the initial software product to the waiting-for-testing state. When the initial software product is pushed, the pipeline uploads the product attribute information of the initial software product to the product library and adjusts the product status of the initial software product to the delivery completion state. The product library can store the product snapshot information of the initial software product, which includes product information, product attributes, completion time, etc.

[0070] In the above-mentioned software product testing method, by responding to the trigger condition for starting the test of the target software, the pipeline is triggered to obtain the product construction information of the target software, and according to the product construction information, the current software product to be tested is started to be built; when the software product construction is completed, the product state of the current software product is adjusted to the state to be tested, and the product attribute information of the current software product is uploaded to the product library; the product state is used to determine the maturity level of the current software product; when the product state of the current software product is the state to be tested, the current software product is deployed to the test environment for verification, and the product state of the current software product is adjusted to the state under testing; when the current software product fails to pass the verification of the test environment In this case, return to the step of triggering the pipeline to obtain the product build information of the target software until the current software product passes the verification of the test environment. In this way, the product status of the software product is updated in real time in combination with the test stage in which the software product is located, and the maturity of the software product is identified by the product status, so as to effectively manage the maturity of the software product, effectively making a software product from development to delivery, all as one product, reducing repeated construction, repeated testing and repeated storage, so that each product is guaranteed by testing, avoiding developers from privately sending products through instant messaging tools, effectively tracing the life cycle of software products and the maturity process of software products, and improving the testing quality of software products.

[0071] In an exemplary embodiment, the method further includes: in response to a product upload request initiated by an uploading user to upload a target software product to a target warehouse, obtaining user role information carried in the product upload request; when the uploading user has upload authority to the target warehouse and the target software product does not exist in the target warehouse, determining that the target software product is a newly added software product, and uploading the newly added software product fragments to the target warehouse.

[0072] The user role information is used to determine whether the uploading user has the upload permission to the target warehouse.

[0073] In a specific implementation, the software product management system can respond to a product upload request initiated by an uploading user to upload a target software product to a target warehouse, and obtain the user role information carried in the product upload request; when the uploading user has upload permissions to the target warehouse, and the target software product does not exist in the target warehouse, the software product management system determines that the target software product is a newly added software product, and uploads the newly added software product segments to the target warehouse.

[0074] In actual applications, the software product management system uses the Role-Based Access Control (RBAC) access control permission model to implement the permission control of software products; a role defines a set of permission sets that can be granted to a specified user. The system provides a default role. If the role does not meet the requirements, the user can add a new permission role. The permission set can include:

[0075] 1) Creation and deletion of product warehouse;

[0076] 2) Creation, modification and deletion of product deliverables;

[0077] 3) Push, download, and delete products; add and modify product attributes;

[0078] 4) Member management permissions, application settings and other role management permissions.

[0079] Role Binding binds roles to users, specifying which users have a specific set of permissions. A role binding can associate multiple users with one role.

[0080] In the specific implementation, after creating a code repository, you can assign roles to personnel in the code repository, confirm which users have which role permissions, whether to enable repository coverage, and other configurations. If the default role provided by the system does not meet the requirements, users can create their own roles, combine permission sets, and then bind them to the repository and users.

[0081] In actual applications, users can upload target software products through the software product management system. Users can use the visual pipeline to configure the code source, compilation and packaging, vulnerability scanning, and security check of the target software product, and configure the software product attribute information of the target software product, so that the pipeline builds the target software product to be uploaded to the target warehouse; then, upload the target software product through the product upload unit module of the pipeline, including the product source, test and scanning metadata of the target software product, including but not limited to the code warehouse, branch, commit ID, unit test pass rate, number of medium-risk and above vulnerabilities, etc.

[0082] Then, in response to the product upload request initiated by the uploading user to upload the target software product to the target warehouse, the user role information carried in the product upload request needs to be determined by the access control authority model to determine whether the uploading user has the authority to upload to the target warehouse.

[0083] In the case where the uploading user has the upload permission of the target warehouse, the software product management system can determine whether there is already a software product consistent with the target software product in the target warehouse by calculating whether the md5 or sha256 is consistent. If there is already a software product consistent with the target software product in the target warehouse, it can be determined whether the software product is allowed to update files and attributes based on the product status of the software product, so as to implement status protection of the product status of the software product, as described below. If there is no software product consistent with the target software product in the target warehouse, the software product management system determines that the target software product is a newly added software product and uploads the newly added software product to the target warehouse in pieces.

[0084] Specifically, the software product management system is configured with a toolkit that can shard the data of newly added software products into multiple pieces of data, with each piece of data being 5M. The toolkit then requests the background, which returns corresponding multiple slice requests. The toolkit runs multiple threads according to each slice request to upload the slice information of the newly added software products to the repository. After the upload is completed, the background merges the slices and verifies whether the final md5 or sha256 is consistent with that when it was uploaded.

[0085] After the product file is persisted, the software product management system stores and processes the product metadata-attribute data pair. It first determines the product status of the software product and whether the current product status allows the addition or modification of attributes. If allowed, the attribute operation log is recorded while adding or modifying the attribute. By combining the attributes and operation logs, the attribute status of the product at different time points can be traced, reflecting the product life cycle management.

[0086] When the software product management system obtains a software product download request, the software product download request also first passes through the RBAC permission model module to determine whether the user has the permission to download the software product to be downloaded. If the user meets the permission to download the software product to be downloaded, the background returns the slice information of the software product to be downloaded, and then the toolkit runs multiple threads to download the product slice data of the software product to be downloaded, and finally merges all the slice data. After the merger, the toolkit verifies whether the final md5 or sha256 is consistent with that when uploading.

[0087] In an exemplary embodiment, the maturity level of the software product includes at least one of the first product level, the second product level, the third product level, the fourth product level and the fifth product level from the low maturity level to the high maturity level; the product status associated with the first product level includes at least one of the to-be-tested state, the testing state, the testing completed state or the testing failed state; the product status associated with the second product level includes at least one of the discarded state, the acceptance passed state or the acceptance failed state; the product status associated with the third product level includes the to-be-delivered state; the product status associated with the fourth product level includes the delivering state; and the product status associated with the fifth product level includes the delivery completed state.

[0088] In the specific implementation, the promotion strategy for software products has two important characteristics, product status and product attributes, and is applicable to software products in various warehouse types. The promotion strategy defines product levels and promotion rules to intuitively distinguish and display the maturity of product versions, improve product lifecycle management, and achieve high-quality software product delivery. The maturity of software products is shown in Figure 7. As shown in Figure 7, the maturity level of software products from low maturity level to high maturity level includes the first product level, the second product level, the third product level, the fourth product level, and the fifth product level. Among them, please refer to Table 1;

[0089] Table 1

[0090]

[0091] As shown in Table 1, the product status associated with the first product level includes the status of waiting for testing, testing, testing completed or testing failed; the product status associated with the second product level includes the status of discarded, acceptance passed or acceptance failed; the product status associated with the third product level includes the status of waiting for delivery; the product status associated with the fourth product level includes the status of being delivered; and the product status associated with the fifth product level includes the status of delivery completed.

[0092] In addition, when the status of the software product is a delivery-completed status, the software product can be set to a status protection mode to prohibit updating of the software product in the delivery-completed status to avoid affecting the normal production of the software product.

[0093] Secondly, the promotion rules between different product levels are defined: the flow of product status can only be promoted in sequence, and cannot skip levels or downgrade.

[0094] For example, a software product with an artifact status of "acceptance passed" cannot be downgraded to "under testing", and a software product with an artifact status of "test passed" cannot be promoted to "delivery completed".

[0095] Finally, the software products in the "delivery completed state" are protected, and updates to content and attributes are prohibited to complete closed-loop management.

[0096] The technical solution of this embodiment defines product levels and promotion rules for software products to intuitively distinguish and display the maturity of product versions, improve product lifecycle management, and achieve high-quality software product delivery.

[0097] In an exemplary embodiment, the method further includes: in response to the current software product passing the acceptance of the online environment, adjusting the product status of the current software product to a delivery completion status; when the product status of the current software product is the delivery completion status, determining that the maturity level of the current software product is higher than the maturity level associated with the acceptance pass status, interrupting the merged image data request for the current software product to prohibit overwriting and updating the current software product.

[0098] In the specific implementation, please refer to the "delivery stage" in Figure 6. After the current software product completes the online environment deployment acceptance, the user can modify the product status of the current software product to the delivery completion status manually or by calling the interface of a third-party platform. The software product management system can adjust the product status of the current software product to the delivery completion status in response to the current software product passing the acceptance of the online environment.

[0099] In addition, when the product status of the current software product is the delivery completion status, since the maturity level of the current software product is higher than the maturity level associated with the acceptance pass status, the software product management system will interrupt the merged image data request for the current software product to prohibit overwriting and updating the current software product.

[0100] Specifically, when the software product management system receives a docker push instruction for a docker image product, the docker push operation will first upload the image layer data packet and verify the SHA256 value of each image layer. When all image layer data is uploaded, the docker client will initiate an image layer merge request.

[0101] When the storage engine merges image data, the software product management system can intercept the merge image data request at the Nginx layer, and obtain the image name, image repository, and image version of the image from the intercepted merge image data request; then, based on the above information, it queries whether the product status of the image product has reached a product status above the acceptance completion status; when the product status of the image product is higher than the acceptance completion status, the software product management system interrupts the merge image data request for the current software product to prohibit the current software product from being merged with the image product to cause an overlay update.

[0102] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0103] Based on the same inventive concept, the embodiment of the present application also provides a software product testing device for implementing the software product testing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more software product testing device embodiments provided below can refer to the limitations of the software product testing method above, and will not be repeated here.

[0104] In an exemplary embodiment, as shown in FIG8 , a software product testing device is provided, including:

[0105] The construction module 810 is used to trigger the pipeline to obtain the product construction information of the target software in response to the trigger condition of starting the test of the target software, and start to build the current software product to be tested according to the product construction information;

[0106] The upload module 820 is used to adjust the product status of the current software product to a state to be tested when the software product is built, and upload the product attribute information of the current software product to the product library; the product status is used to determine the maturity level of the current software product;

[0107] A deployment module 830 is used to deploy the current software product to a test environment for verification and adjust the product status of the current software product to a testing state when the product status of the current software product is in a waiting-for-test state;

[0108] The test module 840 is used to return to the step of triggering the pipeline to obtain the product build information of the target software when the current software product fails to pass the verification of the test environment, until the current software product passes the verification of the test environment.

[0109] In one embodiment, the construction module 810 is specifically used to obtain the query start time; the query start time is the construction time when the most recent product status of the historical software product corresponding to the target software in the code repository is the delivery completion status; the current time is used as the query end time, and all code submission information within the target time period is queried; the target time period is the time period from the query start time to the query end time; the code submission information is parsed to obtain the user story ID.

[0110] In one of the embodiments, the device is further used to obtain a software product attribute configuration for the target software in response to a trigger condition of first access to the churn line and the product library; start building an initial software product according to the software product attribute configuration; when the initial software product is built, push the initial software product and adjust the product status of the initial software product to a pending test state; when the initial software product is pushed, upload the product attribute information of the initial software product to the product library and adjust the product status of the initial software product to a delivery completion state.

[0111] In one of the embodiments, the device is further used to adjust the product status of the current software product to a delivery completion status in response to the current software product passing the acceptance of the online environment; when the product status of the current software product is the delivery completion status, determine that the maturity level of the current software product is higher than the maturity level associated with the acceptance pass status, interrupt the merged image data request for the current software product to prohibit the overwriting update of the current software product.

[0112] In one of the embodiments, the device is further used to respond to a product upload request initiated by an uploading user to upload a target software product to a target warehouse, and obtain user role information carried in the product upload request; the user role information is used to determine whether the uploading user has the upload permission to the target warehouse; if the uploading user has the upload permission to the target warehouse and the target software product does not exist in the target warehouse, determine that the target software product is a newly added software product, and upload the newly added software product in pieces to the target warehouse.

[0113] In one of the embodiments, the maturity level of the software product includes at least one of a first product level, a second product level, a third product level, a fourth product level and a fifth product level in order from a low maturity level to a high maturity level; the product status associated with the first product level includes at least one of a to-be-tested state, a testing state, a testing completed state or a testing failed state; the product status associated with the second product level includes at least one of a discarded state, an acceptance passed state or an acceptance failed state; the product status associated with the third product level includes a to-be-delivered state; the product status associated with the fourth product level includes a delivering state; and the product status associated with the fifth product level includes a delivery completed state.

[0114] Each module in the above-mentioned software product testing device can be implemented in whole or in part by software, hardware or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0115] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in FIG9. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a software product testing method is implemented.

[0116] Those skilled in the art will understand that the structure shown in FIG. 9 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0117] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the software product testing method described above. The steps of the software product testing method described here may be the steps of the software product testing method described in each of the above embodiments.

[0118] In one embodiment, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the processor executes the steps of the software product testing method described above. The steps of the software product testing method described here may be the steps of the software product testing method described in each of the above embodiments.

[0119] In one embodiment, a computer program product is provided, including a computer program, which, when executed by a processor, causes the processor to execute the steps of the software product testing method described above. The steps of the software product testing method described here may be the steps of the software product testing method described in each of the above embodiments.

[0120] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0121] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magneto resistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0122] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0123] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A software product testing method, characterized in that: The method comprises: In response to a trigger condition for starting the test of the target software, the pipeline is triggered to obtain the product building information of the target software, and start building the current software product to be tested according to the product building information; When the current software product is built, the product status of the current software product is adjusted to a state to be tested, and the product attribute information of the current software product is uploaded to the product library; the product status is used to determine the maturity level of the current software product; When the product status of the current software product is in a to-be-tested state, deploying the current software product to a test environment for verification, and adjusting the product status of the current software product to a testing state; In the case that the current software product cannot pass the verification of the test environment, return to the step of triggering the pipeline to obtain the product build information of the target software until the current software product passes the verification of the test environment.

2. The method according to claim 1, characterized in that: The product construction information includes a user story ID, and the triggering pipeline obtains the product construction information of the target software, including: Obtaining the query start time; the query start time is the construction time of the most recent product status of the historical software product corresponding to the target software in the code repository being the delivery completion status; Taking the current time as the query end time, query all code submission information within the target time period; the target time period is the time period from the query start time to the query end time; Parse the code submission information to obtain the user story ID.

3. The method according to claim 1, characterized in that: The method further comprises: In response to a trigger condition of first accessing the churn line and the artifact library, obtaining a software artifact attribute configuration for the target software; According to the software product attribute configuration, start to build the initial software product; When the initial software product is built, push the initial software product and adjust the product state of the initial software product to a state to be tested; When the initial software product is pushed, the product attribute information of the initial software product is uploaded to the product library, and the product status of the initial software product is adjusted to a delivery completion status.

4. The method according to claim 1, characterized in that The method further comprises: In response to the current software product passing the acceptance of the online environment, adjusting the product status of the current software product to a delivery completion status; When the product status of the current software product is a delivery completion status, it is determined that the maturity level of the current software product is higher than the maturity level associated with the acceptance pass status, and the merged image data request for the current software product is interrupted to prohibit overwriting and updating the current software product.

5. The method according to claim 1, characterized in that The method further comprises: In response to a product upload request initiated by an uploading user to upload a target software product to a target warehouse, obtaining user role information carried in the product upload request; the user role information is used to determine whether the uploading user has the upload permission to the target warehouse; When the uploading user has the upload permission of the target warehouse and the target software product does not exist in the target warehouse, the target software product is determined to be a newly added software product, and the newly added software product is uploaded to the target warehouse in segments.

6. The method according to any one of claims 1 to 5, characterized in that: The maturity level of the software product includes at least one of a first product level, a second product level, a third product level, a fourth product level and a fifth product level in order from a low maturity level to a high maturity level; the product status associated with the first product level includes at least one of a waiting to be tested state, a testing state, a testing completed state or a testing failed state; the product status associated with the second product level includes at least one of a discarded state, an acceptance passed state or an acceptance failed state; the product status associated with the third product level includes a waiting to be delivered state; The product status associated with the fourth product level includes a delivery status; The artifact status associated with the fifth artifact level includes a delivery completion status.

7. A software product testing device, characterized in that: The device comprises: A construction module, configured to trigger the pipeline to obtain the product construction information of the target software in response to a trigger condition for starting the test of the target software, and start to build the current software product to be tested according to the product construction information; an upload module, used to adjust the product status of the current software product to a to-be-tested state when the current software product is built, and upload product attribute information of the current software product to a product library; the product status is used to determine the maturity level of the current software product; A deployment module, configured to deploy the current software product to a test environment for verification and adjust the product status of the current software product to a testing state when the product status of the current software product is in a to-be-tested state; The test module is used to return to the step of triggering the pipeline to obtain the product building information of the target software when the current software product fails to pass the verification of the test environment, until the current software product passes the verification of the test environment.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images