Automated testing method, apparatus, storage medium, and electronic device

Abstract

This specification describes embodiments applicable to application testing in the financial field, specifically disclosing an automated testing method, apparatus, storage medium, and electronic device. The method is applied to an automated testing platform, which integrates test case components. Each test case component is configured with at least program scheduling parameter data and program scheduling code for a specified batch of program tests. The program scheduling parameter data is generated based on the program scheduling method configured in the job scheduling table for the specified batch of program tests. The method includes: receiving a test instruction for the specified batch of program tests, the test instruction including a test case identifier; sending a trigger instruction to the test case component corresponding to the test case identifier; and the test case component responding to the trigger instruction, based on the pre-configured program scheduling parameter data and program scheduling code, retrieving the tested program involved in the specified batch of program tests and executing the test, thereby improving the simplicity and efficiency of the test.

Description

Technical Field

[0001] This specification relates to an automated testing method, apparatus, storage medium, and electronic device, which can be used for application testing in the financial field, as well as for application testing in any field other than finance. This specification does not limit the application areas of the automated testing method, apparatus, storage medium, and electronic device. Background Technology

[0002] For large-scale application systems, it's often necessary to automate testing across all programs, including smoke tests and regular tests. Periodically performing smoke tests is crucial for ensuring the quality of application version deliverables. However, as a simple coverage test, smoke testing faces challenges due to the diverse and inconsistent input and output parameters of programs. It's difficult to automate the generation of test code using a uniform template, and writing a dedicated test case for each program would result in a significant workload. Therefore, a simpler and more efficient automated testing method is urgently needed. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to provide an automated testing method, apparatus, storage medium, and electronic device that can improve the simplicity and efficiency of program testing.

[0004] This specification provides an automated testing method, apparatus, storage medium, and electronic device, which are implemented in the following ways:

[0005] An automated testing method is disclosed, applied to an automated testing platform integrating test case components. The test case components are configured with at least program scheduling parameter data and program scheduling code for a specified batch of program tests. The program scheduling parameter data is generated based on the program scheduling mode configured in the job scheduling table for the specified batch of program tests. The method includes: receiving a test instruction for the specified batch of program tests, the test instruction including a test case identifier; wherein the test case identifier is information identifying a test case component; sending a trigger instruction to the test case component corresponding to the test case identifier; and the test case component, in response to the trigger instruction, retrieving the program under test involved in the specified batch of program tests and executing the test based on the pre-configured program scheduling parameter data and program scheduling code.

[0006] On the other hand, embodiments of this specification also provide an automated testing apparatus, which is applied to an automated testing platform, the automated testing platform integrating a test case component; the test case component is configured with at least program scheduling parameter data and program scheduling code for a specified batch of program tests; wherein, the program scheduling parameter data is generated based on the program scheduling method configured in the job scheduling table for the specified batch of program tests; the apparatus includes: an instruction receiving module, used to receive test instructions for the specified batch of program tests, the test instructions including a test case identifier; wherein, the test case identifier refers to information identifying the test case component; a test triggering module, used to send a triggering instruction to the test case component corresponding to the test case identifier; the test case component is used to respond to the triggering instruction, based on the pre-configured program scheduling parameter data and program scheduling code, to retrieve the program under test involved in the specified batch of program tests and execute the test.

[0007] On the other hand, embodiments of this specification also provide a computer-readable storage medium having computer instructions stored thereon, which, when executed, implement the steps of the methods described in any one or more of the above embodiments.

[0008] On the other hand, embodiments of this specification also provide an electronic device, which includes at least one processor and a memory for storing processor-executable instructions, which, when executed by the processor, implement the steps of any one or more of the methods described in the above embodiments.

[0009] The automated testing methods, apparatus, storage media, and electronic devices provided in one or more embodiments of this specification cleverly utilize a test case framework and job scheduling system to transform a testing tool that runs a single program under test into a batch program testing device based on program scheduling. Ordered testing of the entire batch of programs can be achieved through a single piece of program scheduling code, and test information configuration is also simpler and more convenient. It eliminates the need to configure test information and run tests separately for each program under test, achieving unified configuration of test information for all programs under test and unified scheduling of tests for all programs under test, significantly improving the ease of test information configuration and testing efficiency. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0011] Figure 1 This is a schematic diagram illustrating the implementation steps of the test case components provided in this manual;

[0012] Figure 2 This is a schematic diagram illustrating the implementation steps of the runtime portion of the test case components provided in this manual.

[0013] Figure 3 This is a schematic diagram illustrating the implementation steps of the automated testing platform provided in this manual.

[0014] Figure 4 This is a flowchart illustrating the automated testing method provided in this manual.

[0015] Figure 5 This is a schematic diagram of the modular structure of the automated testing device provided in this manual;

[0016] Figure 6 This is a schematic diagram of the module structure of the electronic device provided in this manual. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments in this specification, and not all of them. All other embodiments obtained by those skilled in the art based on one or more embodiments of this specification without creative effort should fall within the scope of protection of the embodiments in this specification.

[0018] For large-scale application systems, it is often necessary to perform automated testing to cover as much of the program as possible, including smoke testing and regular testing. Periodically performing smoke testing is crucial for ensuring the quality of application version delivery. As a simple coverage test, smoke testing is difficult to automate due to the wide variety and inconsistency of program input and output parameters. It is challenging to use a uniform template to automatically generate test code for automated execution. Instead, writing a dedicated test case for each program would result in a significant amount of test case writing.

[0019] For example, currently, testing tools are typically used to test programs under test. Testers first need to configure a result table in the testing tool to store the execution results of a single program under test, and an expected result table to store the expected execution results of that program under test. Then, the program function of the program under test is invoked to execute the test and obtain the execution results. Afterward, the execution results of the program under test are compared with the expected execution results to obtain the test result of the program under test. It is evident that, based on the current testing method, data table configuration, program invocation, and result comparison need to be performed separately for each program under test; that is, a separate set of test cases needs to be configured for each program under test. This makes the writing of test cases for batch testing complex, cumbersome, and inefficient.

[0020] Currently, in Oracle systems or other similar database systems, system parameter tables are used to store the names, input / output parameter names, and parameter types of all programs under test. However, due to the varying parameter types across different programs under test, it is difficult to pre-define specific test values ​​for each parameter type (which may be hundreds or thousands of parameters). Furthermore, there may be calling relationships between multiple programs under test involved in batch testing, and the test values ​​for some programs can only be obtained after the execution of other programs. This makes configuring test values ​​based on system parameter tables difficult to implement. Moreover, the data stored in the program execution parameter tables within the application system is quite large. During the testing process for each program under test, the testing tool needs to traverse the application system's program execution parameter tables based on the program's identifier, extract the program's input parameters, output parameters, and corresponding test values, and generate the execution result data table and expected result data table, as well as input parameter values ​​required for the program under test to run, thus impacting testing efficiency.

[0021] Accordingly, embodiments of this specification provide an automated testing method. This method can be combined with the scheduling strategy of a job scheduling system to execute batch program tests using program scheduling. Using the method provided in these embodiments, unified configuration of test information for each program under test and unified scheduling of tests for each program under test can be achieved, significantly improving the simplicity of test information configuration and testing efficiency.

[0022] In one scenario example of this specification, the automated testing method can be applied to a pre-built automated testing platform. Preferably, the automated testing platform can be built based on the Jenkins continuous integration framework. Of course, it can also be built based on other continuous integration frameworks. The automated testing platform can integrate test case components. The test case components can be used to execute batch tests based on program scheduling.

[0023] like Figure 1 As shown, the test case component may include parts such as data backup, data import, test execution, assertion execution, and data recovery. The test case component can be built based on a testing framework. For example, it can be built based on the UTF-8 SQL test framework. Of course, other types of testing frameworks can also be used to build the test case component.

[0024] The test case components can be configured as follows.

[0025] 1. Backup data

[0026] A test log table can be configured in the test case component. This test log table stores the test results of the program under test. The test log table can be divided into a program test log table and a job test log table. The program test log table may include fields such as the program identifier (e.g., program name or stored procedure name), execution date, execution result, and corresponding program owner. The job test log table may include fields such as job identifier, execution date, execution result, and corresponding job owner. A job can refer to a task that a user in a batch processing system requires the computer to complete; it is a collection of tasks required by the computer. A job is typically completed by at least one program under test. In some cases, the overall completion status of the job can be compared to determine whether the individual programs under test within the job are running correctly. In this case, the job test log table can record the execution results of each program under test within the job, and the job expectation log table can store the expected requirements of the job for the execution results of the programs under test involved.

[0027] 2. Import data

[0028] Expected log tables can be configured or imported within the test case component. Accordingly, expected log tables can be divided into program expected log tables and job expected log tables. The program expected log table may include fields such as the program identifier (e.g., program name or stored procedure name), execution date, successful execution result, and the corresponding program administrator. The job expected log table may include fields such as job identifier, execution date, number of tested programs with correct execution results / total number of tested programs, and the corresponding job administrator.

[0029] 3. Perform the test

[0030] Program scheduling code can be pre-configured in the test case component. This program scheduling code can be pre-configured code that executes the scheduling of the program under test. The test case component can dynamically generate input parameter data to be passed to the program scheduling code for a specified batch of program tests, thereby obtaining a test scheduler for that specified batch of program tests, and then dynamically calling each program under test in the specified batch of program tests to execute the tests.

[0031] In this scenario example, the test case component can dynamically generate input parameter data to be sent to the program scheduling code based on the program scheduling parameter data for a specified batch of program tests, and then invoke each program under test in the specified batch of program tests to execute the test. The program scheduling parameter data refers to parameter data for dynamically scheduling the programs under test involved in the specified batch of program tests. The program scheduling parameter data may include, for example, the time of invoking the program test, the test method, etc. Correspondingly, the input parameter data may include the program identifier of the program under test at the corresponding test time, the program input value, the data source information accessed by the test, etc.

[0032] Preferably, the program scheduling parameter data can be generated by combining the job scheduling table in the job scheduling system. The job scheduling table can be configured with the program scheduling methods of each program under test involved in the specified batch program test. For batch systems, the job scheduling system covers most of the direct and nested calls of programs and has a unified scheduling configuration method. Therefore, combining the job scheduling table in the job scheduling system to uniformly and dynamically generate the program scheduling parameter data for batch program testing can make program scheduling more accurate and orderly.

[0033] The program scheduling methods may include time-based scheduling, concurrency-based scheduling, etc. Preferably, the programs under test involved in the specified batch program testing can be categorized first, so that the scheduling method in the job scheduling table can be configured uniformly according to program type. Program types may include SQL programs, shell programs, etc. Different types of programs may involve significant differences in scheduling methods; configuring the scheduling method based on program type can make the scheduling of the programs under test more accurate. Of course, the scheduling methods may also include other types depending on the testing requirements.

[0034] Based on time scheduling, each program under test can be assigned to different test times for execution. Correspondingly, each program under test executes tests in an orderly manner according to its designated test time. For example, test allocation rules can be pre-configured in the test case component, and the test times for each program under test involved in a batch of program tests can be dynamically generated based on these rules. Of course, if the number of programs under test is small and can be completed within a day, testers can also directly configure the test times for each program under test in the test case component. During testing, the test case component can then retrieve and execute the test program under test at any given test time.

[0035] The test allocation rule can be based on allocating test time for each test program according to a test cycle. For example, the test cycle can be pre-configured according to the number of programs under test targeted by the specified batch program test. For instance, if the number of programs under test is small, one hour can be used as a test cycle. If the number of programs under test is large, one day or one week can be used as a test cycle. After configuring the test cycle, the programs under test running within each test cycle can be allocated. For example, the programs under test can be directly and evenly distributed across the test cycles. Alternatively, the allocation can be further combined with the calling relationships or job dependencies between the programs under test. Through these methods, each program under test will be evenly and orderly allocated to any test cycle for testing. Of course, other methods can also be used for the test allocation rule.

[0036] Based on concurrent scheduling, tests can be performed on each program under test concurrently. For example, testers can configure the concurrent parameter data for each program under test as regions D and E in the test case component, and then perform concurrent tests on each program under test based on the business data of regions D and E. During testing, the test case component can retrieve the program under test for any test cycle and perform concurrent tests on it based on the corresponding concurrent parameter data (such as regions D and E). The concurrent parameter data can also be different business types, etc. Alternatively, test concurrency rules can be pre-configured in the test case component, and the concurrent parameter data for each program under test involved in a specified batch of program tests can be dynamically generated based on these rules.

[0037] In this scenario example, the calling relationships between the tested programs can be further analyzed. For instance, the output of tested program A may be the data required for another tested program B to run. That is, tested program B needs to call the output of tested program A to run, thus establishing a calling relationship between them. This calling relationship can be analyzed to extract the root and leaf tested programs in the specified batch program test. The root tested program can be a program not called by other tested programs, and the leaf tested programs can be programs called by the root tested program during its execution.

[0038] For example, if, after analysis, only program A and program B have a calling relationship, then program B is the root program under test, and program A is a leaf program under test of the root program B. If, after analysis, programs A, B, and C have a calling relationship, and the execution results of programs A and B are the data required for the execution of another program C, then program C is the root program under test, and programs A and B are leaf programs under test. This process continues, and the calling relationships between each program under test can be analyzed sequentially to find the root program under test and the leaf programs involved by the root program under test. For a program under test that has no calling relationship with other programs under test, that program under test itself can be considered the root program under test.

[0039] Accordingly, after sorting out the call relationships between the tested programs in a specified batch of program tests, a series of root tested programs and their corresponding leaf tested programs can be obtained. The extracted root tested programs and their corresponding leaf tested programs can be stored. For example, the root tested programs can be used as root nodes, and the leaf tested programs as leaf nodes, using a tree structure to store each root tested program and its corresponding leaf tested program. Alternatively, the root tested programs can be used as first-type nodes, and the leaf tested programs as second-type nodes, with connections established between the first-type and second-type nodes, labeled as call relationships, using a knowledge graph structure to store each root tested program and its corresponding leaf tested program. Of course, other methods can also be used to store the sorted information. Correspondingly, during the generation of program scheduling parameter data, only the program scheduling parameter data corresponding to the root tested programs can be generated, reducing the complexity of program scheduling parameter data generation.

[0040] Accordingly, when the program scheduling method includes time-based scheduling, the test case component can pre-configure multiple test cycles corresponding to the specified batch program tests. The configuration method of the test cycles can refer to the above-described implementation method. Then, the test cycles corresponding to each root program under test can be allocated at least according to the number of the root program under test and the number of leaf programs under test involved in the root program under test, so that the programs under test are distributed as evenly as possible across the test cycles. The test cycles corresponding to each root program under test are then used as the program scheduling parameter data for the specified batch program tests.

[0041] Furthermore, when the scheduling method includes concurrent scheduling, the concurrent parameter data corresponding to each root program under test can be configured in the test case component, and the configured concurrent parameter data corresponding to each root program under test can also be used as the program scheduling parameter data for the specified batch program test.

[0042] During testing, for any given test period, the test case component can extract the root program under test (DUT) for that test period. Since the extracted root DUT can automatically call the leaf DUTs it needs during its execution, the test case component can simply transmit the program identifier of the extracted root DUT as input parameter data to the pre-configured program scheduling code. This allows the extracted root DUT and the corresponding leaf DUTs called by the root DUT to be invoked in an orderly manner, and the tests executed within the specified test period. Therefore, using the solution of this embodiment, only the program identifier of the root DUT needs to be transmitted to complete the testing of a series of DUTs in an orderly manner, further improving the simplicity of the testing process.

[0043] Alternatively, the test case component can further use the concurrency parameter data of the root test program as the program scheduling parameter data of the program scheduling code. Accordingly, the root test program and the corresponding leaf test programs can be invoked to perform concurrent tests during the specified test cycle.

[0044] Using the above implementation method, the test case component dynamically generates or configures program scheduling parameter data based on the root program under test, making the generation or configuration of program scheduling parameter data simpler and more convenient. Furthermore, executing tests based on this method also makes batch program testing more accurate and orderly.

[0045] In other implementations, the program input parameters, program output parameters, and test values ​​of the root program under test can be configured in the job scheduling table, while the test values ​​of the leaf programs under test can be dynamically generated during program testing. The test values ​​can include program input values ​​corresponding to the program input parameters and expected program output values ​​corresponding to the program output parameters. For example, program input parameters and program output parameters can be configured based on the root program under test, and the types of program input / output parameters involved in the root program under test can be identified, allowing for categorized configuration of test values ​​and improving the ease of test value configuration. Compared to configuring program input / output parameters and test values ​​in the application system, this implementation only requires configuring program input / output parameters and test values ​​for the root program under test in the job scheduling table, further improving the ease of test parameter and test value configuration.

[0046] Correspondingly, such as Figure 2 As shown, the test execution section may include at least preprocessing, test scheduling, and log generation sections.

[0047] 3.1 Pretreatment

[0048] First, the programs in the job scheduling configuration table can be categorized, and the program scheduling methods in the job scheduling table can be configured uniformly according to program type. Then, based on the program scheduling methods configured in the job scheduling table, the calling relationships between the programs under test, etc., the program scheduling parameter data, program input parameters, program output parameters, and test values ​​for a specified batch of program tests can be dynamically generated. For specific implementation methods, please refer to the above description, which will not be repeated here.

[0049] 3.2 Test Scheduling

[0050] The identification information and input values ​​of the program under test can be extracted based on the program scheduling parameter data and used as input parameter data for the program scheduling code to sequentially call the program under test for testing. For specific implementation details, please refer to the description above; further elaboration will not be repeated here.

[0051] 3.3 Log Generation

[0052] The results of the program under test can be statistically analyzed one by one (the statistical data in the corresponding program test log table is: program name or stored procedure name of the program under test, run date, run result, and corresponding program person in charge) and each job can be statistically analyzed (the structure of the corresponding job test log table is: job identifier, run date, number of correct run results / total number of programs, and corresponding job person in charge) and written to the program test log table or job test log table.

[0053] 4. Execute assertions

[0054] The system can determine the differences between the program test log table / job test log table and the program expectation log table / job expectation log table. For example, it can determine whether the execution result of a program under test meets the corresponding expected output value (a successful result). If so, the program under test runs successfully. Alternatively, it can determine whether the number of correct results / total number of programs under a certain job identifier matches the corresponding expected data (number of correct results / total number of programs). If they match, the program under that job identifier runs successfully. By using log tables for unified recording and comparison of programs under test, test assertions become simpler and more efficient.

[0055] 5. Recover data

[0056] After the test is completed, the data in the log table can be cleaned up to restore the log table to its original state before executing subsequent tests.

[0057] Once the test case components are configured, they can be integrated into the Jeckin testing framework to create an automated testing platform. Correspondingly, such as... Figure 3As shown, the automated testing platform may include code scanning, test case execution, assertion capture, report display, and other components.

[0058] A. Code Scanning

[0059] Once the test case components described above are configured, they can be uploaded to a custom directory path on the Jeckin server. Upon receiving a test request, the automated testing platform can trigger a code scan to retrieve the test case components from the corresponding path. This code scan can be triggered via a scheduled task or manually.

[0060] B. Case Execution

[0061] After obtaining the test case components, the platform can run them. Test case components can be run automatically according to scheduled tasks. Of course, they can also be run manually.

[0062] C. Assertion Capture

[0063] The platform can also capture the assertion execution results of test case components, categorize and statistically analyze them, and generate execution result statistical reports and related links.

[0064] D. Report Presentation

[0065] The platform can also analyze the test case components based on the assertion execution results, generate corresponding reports and detailed links, and send relevant error reports to the pre-configured development and testing personnel in a timely manner via the email address of the person in charge of the corresponding test program.

[0066] The automated testing method provided in the above scenario example cleverly utilizes a test case framework and job scheduling system, transforming the testing tool that runs a single program under test into a batch program testing device based on program scheduling. A single piece of program scheduling code enables the orderly scheduling and testing of the entire batch of programs, and the configuration of test information is much simpler and more convenient. It eliminates the need for separate test information configuration and test execution for each program under test, achieving unified configuration of test information for all programs under test and unified scheduling testing, significantly improving the ease of test information configuration and testing efficiency. Simultaneously, by combining the calling relationships between programs under test, the root program under test and leaf programs under test are effectively identified. This allows for accurate and orderly testing of all programs under test by generating only the program scheduling parameter data for the root program under test, greatly improving the simplicity and accuracy of program scheduling parameter data generation. Furthermore, the job scheduling parameter table allows for unified configuration of input / output parameters and corresponding test values ​​based on the root program under test, significantly reducing the preparation work for input / output parameters.

[0067] like Figure 4 As shown, based on the above scenario example, this embodiment of the specification also provides an automatic testing method applied to the automated testing platform, which integrates a test case component; the test case component is configured with at least program scheduling parameter data and program scheduling code for a specified batch of program tests; wherein, the program scheduling parameter data is generated based on the program scheduling method configured in the job scheduling table for the specified batch of program tests; the method may include the following steps:

[0068] S40: Receive a test instruction for the specified batch program test, the test instruction including a test case identifier; wherein, the test case identifier refers to information that identifies the test case component;

[0069] The configuration method for the test case components can be referenced from the scenario example above, and will not be repeated here. After the test case components are configured, they can be stored in a specified path on the testing platform. The test instructions can be triggered manually by the tester or based on a timed mechanism. The test instructions can at least include a test case identifier. The test case identifier refers to information that identifies the test case component. After receiving the test instruction, the testing platform can trigger the test case component corresponding to the test case identifier.

[0070] S42: Send a trigger command to the test case component corresponding to the test case identifier.

[0071] The testing platform can scan test case components stored in a custom path and trigger the execution of those test case components based on a pre-configured triggering mechanism. This triggering mechanism can be automatic based on a timer or manual triggering by the tester.

[0072] S44: In response to the trigger command, the test case component calls the program under test involved in the specified batch program test to perform the test based on the pre-configured program scheduling parameter data and program scheduling code.

[0073] The test case component can respond to the trigger command and, based on pre-configured program scheduling parameter data and program scheduling code, invoke the program under test involved in the specified batch program test to execute the test. The implementation method for the test case component to invoke the program test can be referred to the scenario example above, and will not be elaborated here.

[0074] The above testing method enables thousands of tests for thousands of programs to be implemented accurately and orderly through the program scheduling method and a unified test case component written in conjunction with the test case framework. This greatly improves the simplicity of testing, reduces the cost of manual input, and improves testing efficiency.

[0075] In other embodiments, the program scheduling parameter data can be generated based on the root program under test involved in the specified batch program test: wherein, the root program under test refers to the program under test extracted from each program under test involved in the specified batch program test that is not called by other programs under test. Identifying the root program under test among the programs under test based on the calling relationships between them, and generating program scheduling parameter data based on the root program under test, can make the generation of program scheduling parameter data more accurate and efficient.

[0076] In other embodiments, when the program scheduling method includes time-based scheduling, the program scheduling parameter data can be generated in the following manner: at least according to the number of root programs under test and the number of leaf programs under test involved by the root programs under test, a test cycle corresponding to the root program under test is allocated; wherein, the leaf programs under test refer to the programs under test called by the root programs under test during runtime; and the test cycle corresponding to each root program under test is used as the program scheduling parameter data for the specified batch program test.

[0077] In other embodiments, the platform may also extract the root program under test for a specified test period; use the program identifier of the extracted root program under test as the input parameter data of the program scheduling code, and perform program testing on the extracted root program under test and the leaf programs under test called by the corresponding root program under test during the specified test period.

[0078] In other embodiments, when the scheduling method includes concurrent scheduling, the program scheduling parameter data can be generated in the following manner: configure the concurrent parameter data corresponding to each root program under test, and use the configured concurrent parameter data corresponding to each root program under test as the program scheduling parameter data for the specified batch program test.

[0079] In other embodiments, the test case component is further configured with a test log table for storing batch program test results and an expected log table for storing expected batch program test results. The method further includes: storing the execution results of the retrieved program under test in the test log table; comparing the execution results in the test log table with the corresponding expected results in the expected log table to obtain the test results of the program under test. By storing the execution results and expected results of batch program tests in a log table, and then comparing the execution results based on the log table, the unified execution of test assertions for batch program tests can be achieved, further reducing the complexity of the overall batch program testing process.

[0080] In other embodiments, the program scheduling method in the job scheduling table is at least based on the program type configuration of the program under test involved in the specified batch program test, so that the program scheduling method configuration is more in line with the test application scenario and improves the test accuracy.

[0081] In other embodiments, the automated testing platform can be built based on the Jeckins testing framework. Deploying testing devices through the Jeckins platform enables fully automated test execution, generates test reports, and distributes these reports to relevant development and testing personnel according to program or task leaders. This allows testers and developers to regularly check test case reports and be aware of the impact of code version iterations and modifications on the overall application in a timely manner.

[0082] In other embodiments, the test case components can be built based on the utplsql testing framework. utplsql is an Oracle PL / SQL and SQL unit testing framework that supports batch operation testing of various types, including packages, functions, and procedures. Building test case components based on the utplsql testing framework simplifies and facilitates the construction of test case components.

[0083] Of course, those skilled in the art may make other modifications and implementations based on the technical essence of the embodiments in this specification, but as long as the functions and effects they achieve are the same or similar, they should all be covered within the scope of protection of this specification.

[0084] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. For details, please refer to the foregoing descriptions of the relevant processing embodiments; they will not be repeated here.

[0085] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0086] like Figure 5 As shown, based on the above-described automated testing method, this embodiment of the specification also provides an automated testing device. The device is applied to an automated testing platform, which integrates a test case component. The test case component is configured with at least program scheduling parameter data and program scheduling code for a specified batch of program tests. The program scheduling parameter data is generated based on the program scheduling method configured in the job scheduling table for the specified batch of program tests. The device includes: an instruction receiving module 50, used to receive test instructions for the specified batch of program tests, the test instructions including a test case identifier; wherein the test case identifier refers to information identifying the test case component; and a test triggering module 52, used to send a trigger instruction to the test case component corresponding to the test case identifier. The test case component, in response to the trigger instruction, invokes the program under test involved in the specified batch of program tests to perform tests based on the pre-configured program scheduling parameter data and program scheduling code.

[0087] It should be noted that the apparatus described above, based on the method embodiments and scenario examples, may also include other implementation methods. Specific implementation methods can be found in the descriptions of the relevant method embodiments, and will not be elaborated upon here.

[0088] like Figure 6As shown, based on the above-described automated testing method, this specification also provides an electronic device. The electronic device includes at least one processor and a memory for storing processor-executable instructions. When executed by the processor, the instructions implement the steps of any one or more of the methods described in the above embodiments. The processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, etc. The memory includes, but is not limited to, random access memory (RAM), read-only memory (ROM), cache, hard disk drive (HDD), or memory card. The electronic device may be a server, etc., as described in the above embodiments. Of course, the electronic device may also include input devices, transmission modules, and other modular structures. In this embodiment, the specific functions and effects implemented by the electronic device can be explained in comparison with other embodiments, and will not be repeated here.

[0089] Furthermore, embodiments of this specification also provide a computer-readable storage medium storing computer instructions thereon, which, when executed, implement the steps of the methods described in any one or more of the above embodiments. The storage medium may include a physical device for storing information, typically digitizing the information and then storing it using a medium employing electrical, magnetic, or optical methods. The storage medium may include: devices for storing information using electrical energy, such as various types of memory, such as RAM and ROM; devices for storing information using magnetic energy, such as hard disks, floppy disks, magnetic tapes, magnetic core memory, bubble memory, and USB flash drives; and devices for storing information using optical methods, such as CDs or DVDs. Of course, there are other types of readable storage media, such as quantum memories, graphene memories, etc.

[0090] It should be noted that the embodiments in this specification are not limited to conforming to the standard data model / template or the situations described in the embodiments of this specification. Slightly modified implementation schemes based on certain industry standards or custom methods or embodiments can also achieve the same, equivalent, or similar, or predictable implementation effects after modification, as described above. Embodiments that utilize these modified or modified methods for data acquisition, storage, judgment, and processing still fall within the scope of optional implementation schemes in this specification.

[0091] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0092] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. An automated testing method, characterized by, The method is applied to an automated testing platform, which integrates a test case component. The test case component is configured with at least program scheduling parameter data and program scheduling code for a specified batch of program tests. The program scheduling parameter data is generated based on the program scheduling method configured in the job scheduling table for the specified batch of program tests. The program scheduling method in the job scheduling table is configured at least based on the program type of the tested program involved in the specified batch of program tests, and the program scheduling method includes at least: time-based scheduling and concurrency-based scheduling. The method includes: Receive a test instruction for testing the specified batch of programs, the test instruction including a test case identifier; wherein, the test case identifier refers to information that identifies the test case component; Send a trigger command to the test case component corresponding to the test case identifier; In response to the trigger command, the test case component calls the tested programs involved in the specified batch program test based on the pre-configured program scheduling parameter data and program scheduling code. Specifically, based on the program scheduling parameter data, the identification information and program input value of the root tested program are extracted, and the identification information and program input value are determined as the input parameter data of the program scheduling code. Based on the input parameter data, the tested programs are called sequentially to execute the test. The program scheduling parameter data is generated based on the root program under test involved in the specified batch program test: wherein, the root program under test refers to the program under test extracted from each program under test involved in the specified batch program test that is not called by other programs under test. When the program scheduling method includes time-based scheduling, the program scheduling parameter data is generated in the following manner: at least according to the number of root programs under test and the number of leaf programs under test involved in the root programs under test, the corresponding test cycles for the root programs under test are allocated; wherein, the leaf programs under test refer to the programs under test called by the root programs under test during their execution; the test cycles corresponding to each root program under test are used as the program scheduling parameter data for the specified batch program test.

2. The method of claim 1, wherein, The step of retrieving the tested programs involved in the specified batch program testing based on pre-configured program scheduling parameter data and program scheduling code includes: Extract the root program under test for a specified test period; The program identifier of the extracted root program under test is used as the input parameter data of the program scheduling code, and program testing is performed on the extracted root program under test and the leaf programs under test called by the corresponding root program under test during the specified test period.

3. The method of claim 2, wherein, When the scheduling method includes concurrent scheduling, the program scheduling parameter data is generated in the following manner: configure the concurrent parameter data corresponding to each root program under test, and use the configured concurrent parameter data corresponding to each root program under test as the program scheduling parameter data for the specified batch program test.

4. The method of claim 1, wherein, The test case component is also configured with a test log table for storing batch program test results and an expected log table for storing expected batch program test results; the method further includes: The execution results of the program under test are stored in the test log table; The test results of the program under test are obtained by comparing the running results in the test log table with the corresponding expected results in the expected log table.

5. The method of claim 1, wherein, The automated testing platform is built on the Jenkins continuous integration framework, and the test case components are built on the Utplsql testing framework.

6. An automated test device characterized by, The device is applied to an automated testing platform, which integrates a test case component. The test case component is configured with at least program scheduling parameter data and program scheduling code for a specified batch of program tests. The program scheduling parameter data is generated based on the program scheduling method configured in the job scheduling table for the specified batch of program tests. The program scheduling method in the job scheduling table is configured at least based on the program type of the tested program involved in the specified batch of program tests, and the program scheduling method includes at least: time-based scheduling and concurrency-based scheduling. The device includes: The instruction receiving module is used to receive test instructions for the specified batch program test, wherein the test instructions include test case identifiers; wherein, the test case identifiers refer to information that identifies test case components; The test triggering module is used to send a triggering command to the test case component corresponding to the test case identifier; The test case component is used to respond to the trigger command and, based on pre-configured program scheduling parameter data and program scheduling code, call the tested programs involved in the specified batch program test to perform tests. Specifically, based on the program scheduling parameter data, the identification information and program input values ​​of the root tested program are extracted, and the identification information and program input values ​​are determined as the input parameter data for the program scheduling code. The tested programs are then called sequentially according to the input parameter data. The program scheduling parameter data is generated based on the root tested program involved in the specified batch program test: the root tested program refers to the tested program extracted from each tested program involved in the specified batch program test that has not been called by other tested programs. When the program scheduling method includes time-based scheduling, the program scheduling parameter data is generated in the following manner: at least according to the number of root programs under test and the number of leaf programs under test involved in the root programs under test, the corresponding test cycles for the root programs under test are allocated; wherein, the leaf programs under test refer to the programs under test called by the root programs under test during their execution; the test cycles corresponding to each root program under test are used as the program scheduling parameter data for the specified batch program test.

7. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the instruction is executed, it performs the steps of the method according to any one of claims 1-5.

8. An electronic device, characterized in that, The electronic device includes at least one processor and a memory for storing processor-executable instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 5.

Images