Software gray correction acceptance method, device and equipment, storage medium and product

Abstract

The invention provides a software gray correction acceptance method, device and equipment, a storage medium and a product, and relates to the field of financial science and technology or other related fields. The method comprises the steps that a multi-dimensional acceptance data set of a software gray version and a monitoring data set of a current version on a corresponding dimension are obtained, and each dimension comprises at least one acceptance index; for each acceptance index, performing consistency comparison on an acceptance data subset corresponding to the acceptance index and a monitoring data subset corresponding to the acceptance index to obtain a consistency acceptance result of the gray version and the current version; performing stability comparison on the acceptance data subset of the acceptance index to obtain a stability acceptance result of the acceptance index; and checking and accepting the gray version of the software based on the consistency checking and accepting result and the stability checking and accepting result of the plurality of checking and accepting indexes. According to the method, standardized acceptance of the gray version of the software is realized.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to an acceptance method, apparatus, equipment, storage medium and product for software gray-scale conversion to official status. Background Technology

[0002] Against the backdrop of accelerated digital transformation, various industries have placed higher demands on software version releases. Currently, the industry adopts canary release technology, which involves building an independent canary environment, introducing a small number of users, and implementing a complete canary release process including canary deployment, canary ramp-up, canary-to-offline acceptance testing, and canary-to-offline deployment, minimizing risk exposure. The core of this process lies in the canary-to-offline acceptance testing stage, the purpose of which is to verify the consistency between the canary environment and the production environment in terms of business, performance, traffic, etc., through technical means, ensuring that the new version is ready for full deployment.

[0003] The existing gray-to-form acceptance technology mainly includes manual verification and automatic technical verification. Manual verification requires confirming the operation of key transactions and transformation transactions by operating specific transactions and checking logs. Automatic technical verification relies on an automatic verification platform, where each system writes automatic verification scripts according to its own situation.

[0004] However, manual verification relies on experience-based judgment, which is highly subjective and requires significant manpower, resulting in low efficiency and long cycles. While existing technologies use static values ​​for automated verification, these values ​​do not account for cyclical fluctuations in business operations, leading to normal fluctuations being misjudged as abnormal or real risks being overlooked. Furthermore, the acceptance methods lack standardization. Summary of the Invention

[0005] This application provides a method, apparatus, equipment, storage medium, and product for accepting gray-scale versions of software, in order to solve the technical problem of the lack of standardized means to accept gray-scale versions of software in the prior art.

[0006] Firstly, this application provides an acceptance method for software transitioning from gray-scale to full-scale deployment, including:

[0007] Obtain the multi-dimensional acceptance dataset of the software gray-scale version and the monitoring dataset of the current version in the corresponding dimensions, wherein each dimension includes at least one acceptance indicator;

[0008] For each of the aforementioned acceptance indicators, the consistency of the acceptance data subset corresponding to the acceptance indicator and the monitoring data subset corresponding to the acceptance indicator is compared to obtain the consistency acceptance result between the gray version and the current version.

[0009] The stability of the acceptance data subset of the acceptance indicators is compared to obtain the stability acceptance results of the acceptance indicators.

[0010] The grayscale version of the software is accepted based on the consistency and stability acceptance results of multiple acceptance indicators.

[0011] Secondly, this application provides an acceptance device for software grayscale conversion, comprising:

[0012] The acquisition module is used to acquire the multi-dimensional acceptance dataset of the software gray-scale version and the monitoring dataset of the current version in the corresponding dimension. Each dimension includes at least one acceptance indicator.

[0013] The comparison module is used to perform a consistency comparison between the acceptance data subset corresponding to each acceptance indicator and the monitoring data subset corresponding to the acceptance indicator for each acceptance indicator, so as to obtain the consistency acceptance result between the gray version and the current version.

[0014] The comparison module is also used to perform stability comparison on the acceptance data subset of the acceptance indicators to obtain the stability acceptance result of the acceptance indicators.

[0015] The acceptance module is used to accept the grayscale version of the software based on the consistency and stability acceptance results of multiple acceptance indicators.

[0016] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0017] The memory stores computer-executed instructions;

[0018] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0020] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0021] The software gray-scale conversion acceptance method, apparatus, equipment, storage medium, and product provided in this application acquire a multi-dimensional acceptance dataset of the software gray-scale version and a monitoring dataset of the current version in the corresponding dimensions. Each dimension includes at least one acceptance indicator. For any one of the multiple acceptance indicators, the consistency of the acceptance data subset corresponding to the acceptance indicator and the monitoring data subset corresponding to the acceptance indicator is compared to obtain the consistency acceptance result between the gray-scale version and the current version. A stability comparison is performed on the acceptance data subsets of the acceptance indicators to obtain the stability acceptance result of the acceptance indicators. Based on the consistency and stability acceptance results of multiple acceptance indicators, the gray-scale version of the software is accepted. Data is directly pulled from a specified monitoring platform via script, improving the reliability of the acceptance dataset and monitoring dataset. By comparing the consistency of the monitoring data subsets corresponding to each acceptance indicator and the acceptance data subset, the consistency between the gray-scale version and the current version in each acceptance indicator is ensured, avoiding misjudgments due to local deviations. Vertical fluctuation analysis is performed on the acceptance data subsets based on the acceptance indicators to adapt to cyclical business fluctuations, reducing the false alarm rate during acceptance. The standardized acceptance of the gray-scale version of the software was achieved through the consistency and stability acceptance results of multiple acceptance indicators. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] Figure 1 A schematic diagram illustrating a scenario for an acceptance method of software grayscale conversion provided in an embodiment of this application;

[0024] Figure 2 A flowchart illustrating a software grayscale conversion acceptance method provided in this application embodiment. Figure One ;

[0025] Figure 3 A flowchart illustrating a software grayscale conversion acceptance method provided in this application embodiment. Figure Two ;

[0026] Figure 4 A flowchart illustrating a software grayscale conversion acceptance method provided in this application embodiment. Figure Three ;

[0027] Figure 5 A schematic diagram of the structure of an acceptance device for software grayscale conversion provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0029] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0031] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0032] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0033] It should be noted that the software gray-scale conversion acceptance method, apparatus, equipment, storage medium and product provided in this application can be used in the fintech field, or in any field other than fintech. The application field of the software gray-scale conversion acceptance method, apparatus, equipment, storage medium and product in this application is not limited.

[0034] "Multiple" refers to two or more, and other quantifiers are similar. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following objects have an "or" relationship.

[0035] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, products, or apparatus.

[0036] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0037] With the accelerated pace of digital transformation, various industries have placed higher demands on software version releases. Figure 1 This application provides a schematic diagram of a software grayscale conversion acceptance method, as illustrated in the embodiments of this application. Figure 1 As shown, before releasing a new version of the software, the publisher uses a canary release technique. This involves setting up an independent canary environment to push a limited number of users to a canary release version of the software. The publisher implements a complete canary release process, including canary deployment, canary rollout, canary-to-offline acceptance testing, and canary-to-offline deployment. Meanwhile, other users continue to use the current version of the software.

[0038] The core of this process lies in the gray-scale to official acceptance phase. Before the gray-scale version is fully launched, the release party conducts acceptance testing on the gray-scale version based on test data from a small number of users using the gray-scale version, in order to ensure that the gray-scale version is consistent with the current version in terms of business, performance, traffic, and other dimensions.

[0039] Taking software iteration in the financial industry as an example, the scenario of gray-scale testing followed by official acceptance is particularly complex. For instance, a bank's trading software includes functions such as payment, clearing, and account management. During version iteration and upgrades, banks need to balance business continuity and risk control. Therefore, the gray-scale environment needs to cover high-frequency trading, low-frequency but core trading, and low-frequency trading, while also ensuring the stability of the trading software.

[0040] The existing gray-to-form acceptance technology mainly includes manual verification and automatic technical verification. Manual verification requires confirming the operation of key transactions and transformation transactions by operating specific transactions and checking logs. Automatic technical verification relies on an automatic verification platform, where each system writes automatic verification scripts according to its own situation.

[0041] However, manual verification relies on experience-based judgment, which is highly subjective and requires significant manpower, resulting in low efficiency and long cycles. While existing technologies use static thresholds for automated verification, these thresholds do not account for cyclical business fluctuations, leading to normal fluctuations being misjudged as abnormal or genuine risks being overlooked. Furthermore, the acceptance methods lack standardization.

[0042] The software gray-scale conversion acceptance method, apparatus, equipment, storage medium, and product provided in this application obtain the consistency acceptance result between the gray-scale version and the current version by comparing the consistency of the acceptance data subset corresponding to the acceptance index and the monitoring data subset corresponding to the acceptance index; and obtain the stability acceptance result of the gray-scale version of the acceptance index by comparing the stability of the acceptance data subset of the acceptance index, so as to accept the gray-scale version of the software, aiming to solve the above-mentioned technical problems of the prior art.

[0043] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0044] Figure 2 A flowchart illustrating a software grayscale conversion acceptance method provided in this application embodiment. Figure One ,like Figure 2 As shown, the method includes:

[0045] S201. Obtain the multi-dimensional acceptance dataset of the software grayscale version and the monitoring dataset of the current version in the corresponding dimensions, wherein each dimension includes at least one acceptance indicator.

[0046] In this context, "multi-dimensional" refers to multiple interrelated yet independent perspectives, including business, performance, and traffic dimensions. Each dimension includes at least one acceptance metric. Acceptance metrics are quantifiable data points within the corresponding dimension.

[0047] Acceptance metrics for the business dimension include: core transaction success rate, core transaction error code distribution, etc.; acceptance metrics for the performance dimension include: average response time, system resource saturation, etc.; and acceptance metrics for the traffic dimension include: canary traffic coverage, traffic ratio stability, etc.

[0048] Acceptance datasets refer to the data sets generated by users when using the grayscale version, while monitoring datasets refer to the data sets generated by users when using the current version.

[0049] Raw data in terms of business, performance, and traffic is extracted from both gray-scale and production environments. A unified, standardized script library can be established to directly pull data from a designated monitoring platform via scripts, prohibiting applications from customizing reporting interfaces or processing logic. This ensures consistency in acceptance logic, eliminates the risk of application-layer data tampering through strong data source control, and improves the credibility of acceptance and monitoring datasets. Designated monitoring platforms can be, for example, log systems, network probes, or Application Performance Management (APM) tools.

[0050] S202. For any one of the multiple acceptance indicators, compare the consistency of the acceptance data subset corresponding to the acceptance indicator and the monitoring data subset corresponding to the acceptance indicator to obtain the consistency acceptance result between the gray version and the current version.

[0051] The acceptance data subset refers to the set of data corresponding to the acceptance indicators in the acceptance dataset, while the monitoring data subset refers to the set of data corresponding to the acceptance indicators in the monitoring dataset. Consistency comparison refers to a horizontal comparison of the indicator data between the grayscale version and the current version.

[0052] In this step, for each acceptance metric, a subset of acceptance data and a subset of monitoring data are determined. These subsets are then compared horizontally to check the consistency of the same acceptance metric's performance between the gray-scale version and the current version. This consistency comparison can examine whether the data in the gray-scale version and the current version are identical, or whether the differences between the gray-scale version and the current version meet the allowable difference conditions for the corresponding metric. For example, comparing whether the difference in the core transaction success rate between the gray-scale version and the official version is within the allowable difference conditions.

[0053] In one possible implementation, a consistency comparison is performed between the subset of acceptance data corresponding to the acceptance indicators and the subset of monitoring data corresponding to the acceptance indicators to obtain the consistency acceptance results between the gray version and the current version. This is explained in detail, including:

[0054] Based on the monitoring data subset corresponding to the acceptance indicators, determine the allowable difference conditions for the acceptance indicators; determine whether each acceptance data in the acceptance data subset corresponding to the acceptance indicators meets the allowable difference conditions; if yes, determine the consistency acceptance result of the acceptance indicators as acceptance passed; if no, determine the consistency acceptance result of the acceptance indicators as acceptance failed.

[0055] Among them, the allowable difference condition refers to the pre-set acceptable difference range to determine whether the difference between the monitoring data subset and the acceptance data subset is within a reasonable range.

[0056] In this step, for the subset of monitoring data corresponding to the acceptance indicator, the allowable difference conditions for that acceptance indicator are determined. For each piece of acceptance data in the subset of acceptance data corresponding to the acceptance indicator, it is determined whether the acceptance data meets the allowable difference conditions. If the acceptance data meets the allowable difference conditions, the consistency acceptance result of the acceptance indicator is determined to be successful. If the acceptance data does not meet the allowable difference conditions, the consistency acceptance result of the acceptance indicator is determined to be unsuccessful. The allowable difference conditions can be, for example, a preset range, such as the allowable difference condition for the core transaction success rate being less than 1%. The allowable difference conditions can also be preset conditions, such as the consistency of the core transaction error code distribution.

[0057] For example, regarding the acceptance metric "core transaction success rate," the core transaction success rate of the grayscale version is 99.95%, and the allowable condition for the difference in core transaction success rate is that the difference value is less than 1%. For instance, if the core transaction success rate of the current version is 99.99%, and after comparison, the difference between the core transaction success rate of the grayscale version and the official version is 0.04%, then it means that the consistency acceptance result corresponding to the acceptance metric "core transaction success rate" of the grayscale version has passed the acceptance.

[0058] For example, for the acceptance metric "Distribution of Core Transaction Error Codes," the frequency of each core transaction error code in the current version can be determined based on the monitoring data subset and acceptance data subset of this metric, and the n target core transaction error codes with the highest frequencies can be identified. The frequency of each core transaction error code in the grayscale version can then be determined, and the n grayscale core transaction error codes with the highest frequencies can be identified. The types of the n grayscale core transaction error codes are compared with the types of the n target core transaction error codes. If the types match, the consistency acceptance result corresponding to the acceptance metric "Distribution of Core Transaction Error Codes" for this grayscale version is determined as passed.

[0059] By comparing the consistency of the monitoring data subset and the acceptance data subset corresponding to each acceptance indicator, we can ensure the consistency between the gray version and the current version in each acceptance indicator and avoid misjudgment due to local deviations.

[0060] S203. Perform stability comparison on the subset of acceptance data for the acceptance indicators to obtain the stability acceptance results of the acceptance indicators.

[0061] Among them, stability comparison refers to longitudinal fluctuation analysis based on a subset of acceptance data based on acceptance indicators, that is, judging whether the gray version is stable based on historical data.

[0062] By analyzing a subset of acceptance data for the acceptance indicators, the allowable fluctuation range of that subset can be determined. This allows for a stability assessment by determining whether each acceptance data point falls within this allowable range. Furthermore, trend analysis can be performed on the acceptance data subset over time, such as observing whether error codes are decreasing slowly, to compare the stability of the subset. Based on the results of the longitudinal fluctuation analysis of the acceptance data subset, the stability acceptance results of the grayscale version of the acceptance indicators can be obtained.

[0063] By conducting longitudinal fluctuation analysis on a subset of acceptance data based on acceptance indicators, we can adapt to cyclical fluctuations in business operations and reduce the false alarm rate in acceptance testing.

[0064] S204. Based on the consistency and stability acceptance results of multiple acceptance indicators, the grayscale version of the software is accepted.

[0065] Based on the consistency and stability acceptance results of multiple acceptance metrics, and according to preset acceptance rules, the gray-scale version of the software is tested. If the acceptance is successful, the gray-scale version is converted to official release and fully pushed out; if the acceptance fails, the gray-scale version continues to be tested. Acceptance rules can be, for example, that all consistency and stability acceptance results for multiple acceptance metrics pass, or that a small number of non-critical acceptance metrics fail consistency or stability acceptance results, while other acceptance metrics pass consistency and stability acceptance results.

[0066] The standardized acceptance of the gray-scale version of the software was achieved through the consistency and stability acceptance results of multiple acceptance indicators.

[0067] This embodiment provides a software gray-scale to official version acceptance method. It obtains a multi-dimensional acceptance dataset for the gray-scale version of the software and a monitoring dataset for the current version in the corresponding dimensions. Each dimension includes at least one acceptance indicator. For any one of the multiple acceptance indicators, the acceptance data subset corresponding to the indicator and the monitoring data subset corresponding to the indicator are compared for consistency to obtain a consistency acceptance result between the gray-scale version and the current version. A stability comparison is then performed on the acceptance data subsets of the acceptance indicators to obtain a stability acceptance result. Based on the consistency and stability acceptance results of multiple acceptance indicators, the gray-scale version of the software is accepted. Data is directly pulled from a specified monitoring platform using a script, improving the reliability of the acceptance and monitoring datasets. By comparing the consistency of the monitoring data subsets and acceptance data subsets corresponding to each acceptance indicator, consistency between the gray-scale version and the current version across all acceptance indicators is ensured, avoiding misjudgments due to local deviations. Vertical fluctuation analysis is performed on the acceptance data subsets based on the acceptance indicators to adapt to cyclical business fluctuations, reducing the false alarm rate. Through the consistency and stability acceptance results of multiple acceptance indicators, standardized acceptance of the software gray-scale version is achieved.

[0068] Figure 3 A flowchart illustrating a software grayscale conversion acceptance method provided in this application embodiment. Figure Two In this embodiment Figure 2 Based on the implementation examples, a stability comparison is performed on the subset of acceptance data corresponding to the grayscale versions of the acceptance indicators. The stability acceptance results of the grayscale versions of the acceptance indicators are then explained in detail, such as... Figure 3 As shown, the method includes:

[0069] S301. From the acceptance dataset, determine the target acceptance data subset for the acceptance indicators within the preset period;

[0070] The preset period can be, for example, one week or one month.

[0071] Because industries such as finance experience significant cyclical fluctuations, a preset period can be selected. Data generated within this preset period for a specific acceptance metric can be extracted from the acceptance dataset and used as the target acceptance data subset for that metric. This adapts to the cyclical patterns of business operations and avoids peak periods affecting the acceptance results of the software's gray-scale versions.

[0072] S302. Based on the acceptance data in each subset of the target acceptance data, determine the allowable fluctuation range corresponding to the acceptance indicators;

[0073] Based on the acceptance data in the target acceptance data subset, the allowable fluctuation range of the acceptance indicators can be determined by methods such as normal distribution method, interquartile range method, and median absolute deviation.

[0074] In one possible implementation, the allowable fluctuation range of the acceptance data subset can be determined in the following ways:

[0075] Calculate the mean and standard deviation of each acceptance data in the target acceptance data subset; based on the mean and standard deviation, determine the allowable fluctuation range of the acceptance indicators within the preset period.

[0076] The upper limit of the allowable fluctuation range is the sum of the mean and n times the standard deviation, and the upper limit of the allowable fluctuation range is the difference between the mean and n times the standard deviation.

[0077] Calculate each acceptance data in the target acceptance data subset average and standard deviation The allowable fluctuation range of the acceptance indicators within the preset period is: n can be, for example, 3, 5, etc. When n is 3, the ±3σ interval covers 99.7% of the acceptance data, adapting to the cyclical fluctuations of business.

[0078] By dynamically calculating the allowable fluctuation range, control over stability comparison was achieved.

[0079] S303. Based on the allowable fluctuation range corresponding to the acceptance indicators, perform stability comparison on each acceptance data in the target acceptance data subset to obtain the stability acceptance results of the acceptance indicators.

[0080] Based on the allowable fluctuation range corresponding to the acceptance indicator, the stability of each acceptance data in the target acceptance data subset is compared to determine whether all acceptance data in the target acceptance data subset are within the fluctuation range. If all are within the fluctuation range, the stability acceptance result of the acceptance indicator is determined to be passed; otherwise, the stability acceptance result of the acceptance indicator is determined to be failed.

[0081] This application provides an acceptance method for software gray-scale conversion. It involves determining a target subset of acceptance data for acceptance indicators within a preset period from the acceptance dataset. Based on each acceptance data point in the target subset, it determines the allowable fluctuation range corresponding to each acceptance indicator. Then, based on this allowable fluctuation range, it compares the stability of each acceptance data point in the target subset to obtain the stability acceptance result of the acceptance indicators. By performing longitudinal fluctuation analysis on the subset of acceptance data based on the acceptance indicators, it adapts to the cyclical fluctuations of business operations and reduces the false alarm rate during acceptance.

[0082] In existing technologies, applying the same acceptance rules to all software can lead to unreasonable resource allocation. For example, relying solely on automated acceptance for unstable software can result in a high false alarm rate and insufficient acceptance. Conversely, manually intervening in the acceptance process for low-risk software can also lead to unreasonable resource allocation.

[0083] Figure 4 A flowchart illustrating a software grayscale conversion acceptance method provided in this application embodiment. Figure Three In this embodiment Figure 2 or Figure 3 Based on the examples, this paper provides a detailed explanation of the acceptance process for the grayscale version, using the consistency and stability acceptance results based on multiple acceptance indicators. Figure 4 As shown, the method includes:

[0084] S401. Obtain the application level label of the software;

[0085] Among them, the application level label refers to the degree of impact of the software on business operations.

[0086] The application level labels of the software can be directly accessed, or they can be determined by using the application level evaluation data and methods such as weighted average and cluster analysis.

[0087] Optionally, the application level label of the software can be obtained in the following ways:

[0088] Obtain software rating data, which includes business impact, historical stability, and application importance; weight and integrate the business impact, historical stability, and application importance to determine the software's application rating label.

[0089] To obtain software's business impact, historical stability, and application importance, these factors can be weighted and integrated based on preset weighting coefficients to determine the software's application level label. Preset weighting coefficients could be, for example, 0.3, 0.3, and 0.4. Alternatively, the weighting coefficients for business impact, historical stability, and application importance can be dynamically determined based on the stability of the software's historical versions.

[0090] By using a weighted fusion method, application level labels were generated quantitatively, avoiding label bias caused by subjective judgment, which could affect the acceptance results of the software's gray-scale version.

[0091] S402. Based on the consistency acceptance results of multiple acceptance indicators, the stability acceptance results, and the acceptance rules corresponding to the application level labels, the grayscale version is accepted.

[0092] The grayscale version is accepted based on the application level labels of the software and the corresponding acceptance rules, as well as the consistency and stability acceptance results of multiple acceptance indicators.

[0093] For example, the acceptance rules could allow a small number of non-critical acceptance metrics to fail in consistency or stability testing for Level 1 software, while passing consistency and stability testing for other metrics. Level 2 software, on the other hand, would require passing consistency and stability testing for multiple metrics. Alternatively, the acceptance rules could state that Level 1 software requires passing consistency and stability testing for multiple metrics, while Level 2 software requires passing consistency and stability testing for multiple metrics, and also necessitates manual review to obtain the manual acceptance result.

[0094] In one possible implementation, the application level label includes: a first level and a second level, which provides a detailed explanation of the acceptance process for the grayscale version, based on the consistency and stability acceptance results according to multiple acceptance indicators, as well as the acceptance rules preset by the application level label of the software. This includes:

[0095] If the application level is Level 1, the grayscale version is considered to have passed acceptance when the consistency and stability acceptance results of multiple acceptance indicators are all passed.

[0096] If the application level is Level 2, obtain the manual acceptance results of the grayscale version. If the manual acceptance results, as well as the consistency acceptance results and stability acceptance results of multiple acceptance indicators, are all passed, the grayscale version is considered to have passed acceptance.

[0097] The first level refers to low-to-medium risk software that passes fully automated acceptance testing; examples include auxiliary software and non-core trading software. The second level is high-risk software that requires manual intervention for acceptance testing; examples include payment software and clearing software.

[0098] In this step, the software acceptance rules are determined by applying grade labels, and the gray version is accepted based on the software acceptance rules and the consistency and stability acceptance results of multiple acceptance indicators.

[0099] By matching application level labels with corresponding acceptance rules, graded acceptance of software can be achieved. This ensures that resource allocation matches the application level labels of the software, avoids wasting resources due to over-verification of low-risk software, and improves acceptance efficiency.

[0100] This embodiment provides a software gray-scale to official acceptance method. By acquiring the software's application level tags, and based on the consistency and stability acceptance results of multiple acceptance indicators, as well as the acceptance rules corresponding to the application level tags, the gray-scale version is accepted. By matching the application level tags with the corresponding acceptance rules, tiered software acceptance is achieved, ensuring that resource allocation matches the software's application level tags. This avoids insufficient acceptance of high-risk software and prevents resource waste due to over-verification of low-risk software.

[0101] Figure 5 This is a schematic diagram of the structure of an acceptance device for software grayscale conversion provided in an embodiment of this application, as shown below. Figure 5 As shown, the software grayscale conversion acceptance device 50 provided in this embodiment includes:

[0102] The acquisition module 501 is used to acquire the multi-dimensional acceptance dataset of the software gray version and the monitoring dataset of the current version in the corresponding dimension, wherein each dimension includes at least one acceptance indicator.

[0103] The comparison module 502 is used to perform a consistency comparison between the acceptance data subset corresponding to each acceptance indicator and the monitoring data subset corresponding to the acceptance indicator for each acceptance indicator, so as to obtain the consistency acceptance result between the gray version and the current version.

[0104] The comparison module 502 is also used to perform stability comparison on the subset of acceptance data of the acceptance indicators to obtain the stability acceptance results of the acceptance indicators.

[0105] Acceptance module 503 is used to accept the grayscale version of the software based on the consistency and stability acceptance results of multiple acceptance indicators.

[0106] In one possible implementation, the comparison module 502 is further configured to determine a target acceptance data subset of the acceptance indicators within a preset period from the acceptance dataset; determine the allowable fluctuation range corresponding to the acceptance indicators based on each acceptance data in the target acceptance data subset; and perform a stability comparison on each acceptance data in the target acceptance data subset based on the allowable fluctuation range corresponding to the acceptance indicators to obtain the stability acceptance result of the acceptance indicators.

[0107] In one possible implementation, the comparison module 502 is also used to calculate the average value and standard deviation of each acceptance data in the target acceptance data subset; based on the average value and standard deviation, the allowable fluctuation range of the acceptance indicators within a preset period is determined.

[0108] In one possible implementation, the comparison module 502 is further configured to determine the allowable difference conditions corresponding to the acceptance indicators based on the subset of monitoring data corresponding to the acceptance indicators; determine whether each acceptance data in the subset of acceptance data corresponding to the acceptance indicators meets the allowable difference conditions; if so, determine that the consistency acceptance result of the acceptance indicators is accepted; if not, determine that the consistency acceptance result of the acceptance indicators is accepted.

[0109] In one possible implementation, the acquisition module 501 is also used to acquire the application level label of the software; the acceptance module 503 is also used to accept the gray version based on the consistency acceptance results of multiple acceptance indicators, the stability acceptance results, and the acceptance rules corresponding to the application level label.

[0110] In one possible implementation, the acquisition module 501 is also used to acquire software rating data, which includes: business impact, historical stability, and application importance; and to perform weighted fusion of business impact, historical stability, and application importance to determine the application rating label of the software.

[0111] In one possible implementation, the application level label includes: first level and second level. If the application level is first level, the acceptance module 503 is also used to determine that the gray version has passed acceptance when the consistency acceptance result and stability acceptance result of multiple acceptance indicators are both passed.

[0112] If the application level is the second level, the acquisition module 501 is also used to acquire the manual acceptance results of the gray version, and the acceptance module 503 is also used to determine that the gray version has passed acceptance when the manual acceptance results, as well as the consistency acceptance results and stability acceptance results of multiple acceptance indicators are all passed.

[0113] This embodiment provides an acceptance device for software grayscale conversion, which can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0114] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus.

[0115] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0116] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0117] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0118] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0119] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0120] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0121] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0122] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0123] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0124] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0125] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0126] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0127] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0128] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0129] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0130] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for accepting software during gray-scale conversion to official use, characterized in that, include: Obtain the multi-dimensional acceptance dataset of the software gray-scale version and the monitoring dataset of the current version in the corresponding dimensions, wherein each dimension includes at least one acceptance indicator; For each of the aforementioned acceptance indicators, the consistency of the acceptance data subset corresponding to the acceptance indicator and the monitoring data subset corresponding to the acceptance indicator is compared to obtain the consistency acceptance result between the gray version and the current version. The stability of the acceptance data subset of the acceptance indicators is compared to obtain the stability acceptance results of the acceptance indicators. The grayscale version of the software is accepted based on the consistency and stability acceptance results of multiple acceptance indicators.

2. The method according to claim 1, characterized in that, The step of performing a stability comparison on the subset of acceptance data corresponding to the grayscale version of the acceptance indicator to obtain the stability acceptance result of the acceptance indicator includes: From the acceptance dataset, determine the target acceptance data subset for the acceptance indicators within a preset period; Based on the acceptance data in the target acceptance data subset, determine the allowable fluctuation range corresponding to the acceptance indicator; Based on the allowable fluctuation range corresponding to the acceptance index, the stability of each acceptance data in the target acceptance data subset is compared to obtain the stability acceptance result of the acceptance index.

3. The method according to claim 2, characterized in that, The step of determining the allowable fluctuation range corresponding to the acceptance indicator based on each acceptance data in the target acceptance data subset includes: Calculate the mean and standard deviation of each acceptance data point in the target acceptance data subset; Based on the average value and standard deviation, the allowable fluctuation range of the acceptance index within the preset period is determined.

4. The method according to claim 1, characterized in that, The step of comparing the consistency of the acceptance data subset corresponding to the acceptance indicator and the monitoring data subset corresponding to the acceptance indicator to obtain the consistency acceptance result between the gray version and the current version includes: Based on the subset of monitoring data corresponding to the acceptance indicators, determine the allowable conditions for the differences corresponding to the acceptance indicators. Determine whether each acceptance data in the subset of acceptance data corresponding to the acceptance indicator meets the difference allowance condition; If so, the consistency of the acceptance indicators is determined to be a pass for acceptance. If not, the consistency acceptance result of the aforementioned acceptance indicators is determined to be an acceptance failure.

5. The method according to any one of claims 1-4, characterized in that, The grayscale version is accepted based on the consistency and stability acceptance results of multiple acceptance indicators, including: Obtain the application level label of the software; The grayscale version is accepted based on the consistency and stability acceptance results of multiple acceptance indicators and the acceptance rules corresponding to the application level label.

6. The method according to claim 5, characterized in that, The process of obtaining the application level tag of the software includes: Obtain the software's rating data, which includes: business impact, historical stability, and application importance; The application level label of the software is determined by weighting and integrating the business impact, historical stability, and application importance.

7. The method according to claim 5, characterized in that, The application level labels include: a first level and a second level. The acceptance of the grayscale version is based on the consistency acceptance results and stability acceptance results of multiple acceptance indicators, as well as the acceptance rules corresponding to the application level labels, including: If the application level is Level 1, the grayscale version is deemed to have passed acceptance when the consistency and stability acceptance results of the multiple acceptance indicators are both passed. If the application level is Level 2, obtain the manual acceptance result of the grayscale version. When the manual acceptance result, as well as the consistency acceptance result and stability acceptance result of the multiple acceptance indicators, are all deemed to have passed the acceptance, the grayscale version is determined to have passed the acceptance.

8. An acceptance device for software grayscale conversion, characterized in that, include: The acquisition module is used to acquire the multi-dimensional acceptance dataset of the software gray-scale version and the monitoring dataset of the current version in the corresponding dimension. Each dimension includes at least one acceptance indicator. The comparison module is used to perform a consistency comparison between the acceptance data subset corresponding to each acceptance indicator and the monitoring data subset corresponding to the acceptance indicator for each acceptance indicator, so as to obtain the consistency acceptance result between the gray version and the current version. The comparison module is also used to perform stability comparison on the acceptance data subset of the acceptance indicators to obtain the stability acceptance result of the acceptance indicators. The acceptance module is used to accept the grayscale version of the software based on the consistency and stability acceptance results of multiple acceptance indicators.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images