Test method for automatically generating virtual number call records in batches and testing performance

Abstract

The invention belongs to the technical field of virtual number call record performance testing, and discloses a testing method for automatically generating virtual number call records in batches and testing the performance of the virtual number call records in batches, and the method comprises the following steps: S1, designing testing data, and generating a testing party; s2, defining a data source and an interface; s3, calling and parameterizing a JMeter interface; and S4, executing the data construction test set. According to the method, test data construction automation is realized, so that tests are greatly reduced, and the parameter design quality and efficiency are improved; the constructed data scene is more real, the consistency with the existing business data is high, the integrating degree is high, the trueness of the subsequent test effect is better guaranteed, and the index has higher reference value; according to the method, a test data simplification step for saving data construction cost is skipped, full coverage is implemented, compromise trade-off of scene data occurrence probability and possibility is not needed any more, high-density comprehensive test coverage is directly performed, and the test quality is better guaranteed.

Description

Technical Field

[0001] The present invention belongs to the technical field of virtual number call record performance testing, and specifically is a testing method for automatically batch generating virtual number call records and performance testing. Background Art

[0002] In current software testing practice, test data preparation is a crucial link for both functional testing and performance testing. For functional testing, test scenario data is traditionally prepared manually, which usually involves complex operational processes, such as generating data through upstream system functions or directly running database SQL scripts. However, these methods have many shortcomings: long pre-processes, complex operations, high requirements for data link characteristics, prone to errors, low efficiency and high costs. These problems are particularly prominent when dealing with large-scale test data or interrelated multi-table data. In addition, data inserted directly through database scripts may have the risk of data errors or omissions because they have not been verified by system functions, affecting the authenticity and effectiveness of the test scenarios.

[0003] For performance testing, existing technologies mainly use fixed interface input or parameterize the input and enter it into a CSV file to simulate data processing in different concurrent scenarios. Although parameterized input can improve the limitations of fixed input and make the test scenario closer to the real situation, manually designing parameterized solutions is not only labor-intensive and inefficient, but also difficult to ensure the precision and rationality of data design, especially when processing large-scale data or complex test scenarios. In addition, fixed input may not accurately reflect the actual performance of the system due to reasons such as data caching. Although parameterized input can improve this problem, the flexibility and efficiency of the design still need to be improved.

[0004] In summary, existing test data preparation methods face many challenges and limitations when facing complex test scenarios and large-scale data processing, and there is an urgent need for a more efficient, flexible and reliable test data preparation solution. Summary of the invention

[0005] The purpose of the present invention is to provide a test method for automatically generating call records of virtual numbers in batches and performing performance tests, so as to solve the problems raised in the above-mentioned background technology.

[0006] In order to achieve the above-mentioned purpose, the present invention provides the following technical solutions: a test method for automatically generating call records of virtual numbers in batches and performing performance tests,

[0007] The steps of this method are:

[0008] S1: Design test data, generate test methods, design test data plans based on required test scenarios, and generate test plan files;

[0009] S2: Clarify the data source and interface, confirm the data source method, and clarify the business interface or basic interface required for data entry;

[0010] S3: JMeter interface call and parameterization, implement the call to the interface in JMeter, and perform parameterization and other pre-processing and post-processing on the interface call to form a JMeter test set;

[0011] S4: Execute data to build a test set. Use JMeter to execute data construction, implement interface calls and parameterized processing, and add necessary preprocessing and post-processing steps to finally form a complete test set.

[0012] Preferably, the steps in S1 are:

[0013] A1: Customize test data to match functional features. When testing different functional features, the virtual number call record processing system has different requirements for the data characteristics of call records. Therefore, it is necessary to design different test data plans based on the current required test functions, specifying different data such as call record service type, call record-related service order, call type, call time point, call waiting and connection time, and call result.

[0014] A2: Generate a CSV data table for test calls. After determining the data field characteristics, output a CSV file in the form of a two-dimensional table for the test tool platform to call.

[0015] Preferably, the steps in S2 are:

[0016] B1: Determine the required data and create an interface. Determine that the required data is the virtual number call record. The interface is the business interface for the virtual number call record on the B side.

[0017] B2: Calibrate the data plan. Through the interface document, confirm the interface input parameter fields corresponding to the test data plan, adjust the test data plan document formed in the previous step, and prepare for the subsequent parameterization of the interface.

[0018] Preferably, the steps in S3 are:

[0019] C1: Build CSV, build JMeter HTTP Request Sampler and CSV DataSet Config for the interface under test;

[0020] C2: Get basic information, access the XB binding relationship table of the business database through the associated business order order id specified by the CSV parameter template, and automatically obtain the basic information required by the interface.

[0021] C3: Build information. Combine the information in the temporary table built in the previous step with the information specified in the CSV template file to automatically calculate and build other field information.

[0022] C4: Configuration components, configure the number of concurrent threads, thread concurrency properties, collection points, and system resource monitor components.

[0023] Preferably, the steps in S4 are:

[0024] D1: Reference CSV files. Different CSV files are referenced according to different test scenarios.

[0025] D2: Adjust the switch, adjust the post-processing component switch according to needs;

[0026] D3: Performance testing, executing test sets, building test data or performing performance testing.

[0027] Preferably, virtual number: a mobile phone number provided by a virtual number operator, referred to as X number, which acts as an intermediate number in the middle of the process of calling user A making a call and called user B receiving a call. The calling user uses A number to dial X number and transfers to B number to complete the call process.

[0028] Preferably, the virtual number call record: after the call is completed, the virtual number operator will call the call record interface to pass the time attributes, number attributes, recording and other information of the call process to the user. The user forms a call record according to the interface call content and records it into the database, and processes it at the same time to implement the relevant product function logic.

[0029] Preferably, the call types in A1 are call forwarding by the calling party and call back by the called party, and the call bill service types are divided into C1, C2, and rush purchase pool.

[0030] The beneficial effects of the present invention are as follows:

[0031] The present invention realizes the automation of test data construction, greatly reduces the time of testing, retesting and regression testing, and improves the test work efficiency; some core parameter data are derived from real data in the business database, which effectively avoids the irrationality and error-proneness of manual parameter assignment, reduces the time of manual query of business data, and improves the quality and efficiency of parameter design; the constructed data scenario is more realistic, has strong consistency and high fit with existing business data, the authenticity of subsequent test results is more guaranteed, and the indicators are more valuable for reference; the test data streamlining step for saving the cost of building data is skipped, and full coverage is implemented. There is no need to compromise and weigh the probability and possibility of scenario data occurrence, and high-density comprehensive test coverage is directly performed, which better guarantees the test quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a schematic diagram of the process of the present invention;

[0033] Figure 2 It is a schematic diagram of the process in S1 of the present invention;

[0034] Figure 3 It is a schematic diagram of the process in S2 of the present invention;

[0035] Figure 4 It is a schematic diagram of the process in S3 of the present invention;

[0036] Figure 5 It is a schematic diagram of the process in S4 of the present invention;

[0037] Figure 6 Construct a code graph for the inventive data. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0039] like Figures 1 to 6 As shown, the embodiment of the present invention provides 1. a test method for automatically generating call records of virtual numbers in batches and performing performance tests,

[0040] The steps of this method are:

[0041] S1: Design test data, generate test methods, design test data plans based on required test scenarios, and generate test plan files;

[0042] S2: Clarify the data source and interface, confirm the data source method, and clarify the business interface or basic interface required for data entry;

[0043] S3: JMeter interface call and parameterization, implement the call to the interface in JMeter, and perform parameterization and other pre-processing and post-processing on the interface call to form a JMeter test set;

[0044] S4: Execute data to build a test set. Use JMeter to execute data construction, implement interface calls and parameterized processing, and add necessary preprocessing and post-processing steps to finally form a complete test set.

[0045] Due to the automation of test data construction, the time for testing, retesting and regression testing has been greatly reduced, and the test work efficiency has been improved; some core parameter data are derived from real data in the business database, which effectively avoids the irrationality and error-proneness of manual parameter assignment, reduces the time for manual query of business data, and improves the quality and efficiency of parameter design; the constructed data scenarios are more realistic, with strong consistency and high fit with existing business data, the authenticity of subsequent test results is more guaranteed, and the indicators are more valuable for reference; the test data streamlining steps to save the cost of building data are skipped, and full coverage is implemented. There is no need to compromise on the probability and possibility of scenario data occurrence, and high-density comprehensive test coverage is directly performed to better ensure the test quality.

[0046] The steps in S1 are:

[0047] A1: Customize test data to match functional features. When testing different functional features, the virtual number call record processing system has different requirements for the data characteristics of call records. Therefore, it is necessary to design different test data plans based on the current required test functions, specifying different data such as call record service type, call record-related service order, call type, call time point, call waiting and connection time, and call result.

[0048] A2: Generate a CSV data table for test calls. After determining the data field characteristics, output a CSV file in the form of a two-dimensional table for the test tool platform to call.

[0049] Through A1's customized test data strategy, we significantly enhanced the pertinence of the test, ensuring that each test is precisely focused on specific functional features, avoiding resource waste and ambiguous results. At the same time, the comprehensive test data design covers a variety of features such as call service type, call type, time point, waiting and connection time, etc., which improves the comprehensiveness of the test scenario and enhances the ability to discover potential problems and boundary conditions. In addition, customized test data effectively reduces test failures and false positives caused by data that does not match or meet requirements, thereby improving test efficiency and accuracy. A2's CSV data table generation further simplifies the data management process, making it easier to view, modify and process test data. As a data carrier, the seamless integration of CSV files with the automated testing tool platform greatly promotes the automated execution of tests, improves test efficiency and reduces the risk of human errors. More importantly, the reusability and clear data records of CSV files not only ensure the repeatability of test scenarios in different stages and environments, but also provide strong support for problem tracking and cause analysis, significantly enhancing the traceability of tests.

[0050] Among them, the steps in S2 are:

[0051] B1: Determine the required data and create an interface. Determine that the required data is the virtual number call record. The interface is the business interface for the virtual number call record on the B side.

[0052] B2: Calibrate the data plan. Through the interface document, confirm the interface input parameter fields corresponding to the test data plan, adjust the test data plan document formed in the previous step, and prepare for the subsequent parameterization of the interface.

[0053] By clarifying the test requirements, that is, determining that the required data is the virtual number call record, and creating the corresponding B-side virtual number call record creation business interface, this step ensures that the test work objectives are clear and specific, laying a solid foundation for subsequent operations. Then, in step B2, we deeply calibrated the data plan. By carefully reading the interface documents, we accurately identified the interface input parameter fields that the test data plan needs to match. This meticulous calibration process not only ensures the accuracy of the test data, but also promotes the close connection between the test data plan and the actual needs of the interface. Subsequently, we made necessary adjustments to the test data plan document and made full preparations for the subsequent interface parameterization processing.

[0054] The steps in S3 are:

[0055] C1: Build CSV, build JMeter HTTP Request Sampler and CSV DataSet Config for the interface under test;

[0056] C2: Get basic information, access the XB binding relationship table of the business database through the associated business order order id specified by the CSV parameter template, and automatically obtain the basic information required by the interface.

[0057] C3: Build information. Combine the information in the temporary table built in the previous step with the information specified in the CSV template file to automatically calculate and build other field information.

[0058] C4: Configuration components, configure the number of concurrent threads, thread concurrency properties, collection points, and system resource monitor components.

[0059] By building an efficient and systematic performance testing environment, C1 realizes the automatic management and calling of test data through CSV and JMeter configuration, ensuring the authenticity and flexibility of data interaction. The C2 stage uses the order id in CSV to automatically obtain basic information from the database, significantly improving data accuracy and testing efficiency. The C3 stage is further automated, combining database information with CSV templates to build complete interface data, reducing human intervention and ensuring data integrity and accuracy. Finally, the comprehensive configuration of the C4 stage, including concurrent threads, collection points and system resource monitoring, provides solid support for performance testing to simulate real user behavior and evaluate the high concurrent performance of the system. This series of steps not only optimizes the test process, but also significantly improves the comprehensiveness and accuracy of the test.

[0060] Among them, the steps in S4 are:

[0061] D1: Reference CSV files. Different CSV files are referenced according to different test scenarios.

[0062] D2: Adjust the switch, adjust the post-processing component switch according to needs;

[0063] D3: Performance testing, executing test sets, building test data or performing performance testing.

[0064] From D1 to D3, the performance testing process was deeply optimized. D1 achieved rapid adaptation of test data and full coverage of scenarios through flexible switching of CSV files, improving test efficiency and result diversity. In D2, fine-tuning of the post-processing component switches ensured the flexibility of the test process and efficient use of resources, further enhancing the effectiveness and pertinence of the test. In D3, the core performance test execution phase, the system performance was comprehensively and deeply evaluated by building precise test data and simulating real user behavior, providing solid data support for subsequent performance tuning and system optimization. This series of steps not only ensured the accuracy and efficiency of performance testing, but also laid a solid foundation for the long-term stable operation and continuous optimization of the system.

[0065] Among them, virtual number: a mobile phone number provided by a virtual number operator, referred to as X number, which acts as an intermediate number in the middle of the process of calling user A making a call and called user B receiving a call. The calling user uses A number to dial X number and transfers to B number to complete the call process.

[0066] As an innovative service provided by operators, virtual numbers (X numbers for short) play an important role in the communications field. As an intermediate number, it is cleverly embedded in the call process between calling user A and called user B, realizing number transfer and privacy protection. When calling user A dials X number, the system automatically transfers his call to the real number of called user B, thus completing the call without directly exposing the real mobile phone numbers of both parties. This process not only simplifies the call process, but also effectively protects the user's personal privacy and prevents the abuse and harassment of phone numbers. In addition, the flexibility of virtual numbers also provides convenience for temporary communications, business exchanges and other scenarios, meeting the diversified needs of modern communications.

[0067] Among them, virtual number call records: after the call is completed, the virtual number operator will call the call record interface to pass the time attributes, number attributes, recording and other information of the call process to the user. The user will form a call record based on the interface call content and record it into the database, and process it at the same time to implement the relevant product function logic.

[0068] Virtual number call records are a key link in communication services. After the call, the virtual number operator will actively call the call record interface to transmit detailed call data in real time, including timestamp, number information, recording files, etc., to provide users with comprehensive and accurate call records. After receiving this data, the user can not only store it in the database for subsequent query and management, but also further process and analyze it, such as counting call duration, identifying high-frequency contacts, etc., thereby supporting the core functional logic of related products. This process not only enhances the user experience, such as providing call playback, call record query and other functions, but also provides valuable data support for corporate operations, helping to optimize service quality and product strategies.

[0069] Among them, the call types in A1 are call forwarding by the calling party and call back by the called party, and the call bill service types are divided into C1, C2, and rush purchase pool.

[0070] In A1, we distinguished call types and bill service types in detail, providing a clear framework for the customization of test data and the execution of test activities. Call types include caller transfer and called call back. These two types cover the common active call and response call scenarios during the call process, ensuring the comprehensiveness of the test. The bill service types are subdivided into C1, C2, rush purchase pool and other types. This classification method not only reflects the call needs under different business scenarios, but also provides a basis for the customization of test data. By clarifying these classifications, we can design test plans more accurately and ensure that test activities can cover various business scenarios and call types, thereby improving the pertinence and effectiveness of the test.

[0071] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0072] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A test method for automatically generating call records of virtual numbers in batches and performing performance tests, characterized in that: The steps of this test method are: S1: Design test data, generate test plan, design test data plan according to required test scenario, and generate test plan file; S2: Clarify the data source and interface, confirm the data source method, and clarify the business interface or basic interface required for data entry; S3: JMeter interface call and parameterization, implement the call to the interface in JMeter, and perform parameterization and other pre-processing and post-processing on the interface call to form a JMeter test set; S4: Execute data to build a test set. Use JMeter to execute data construction, implement interface calls and parameterized processing, and add necessary preprocessing and post-processing steps to finally form a complete test set.

2. The method for automatically generating call records of virtual numbers in batches and performing performance tests according to claim 1 is characterized in that: The steps in S1 are: A1: Customize test data to match functional features. When testing different functional features, the virtual number call record processing system has different requirements for the data characteristics of call records. Different test data solutions need to be designed according to the current required test functions, specifying different data such as call record service type, call record-related service order, call type, call time point, call waiting and connection time, and call result. A2: Generate a CSV data table for test calls. After determining the data field characteristics, output a CSV file in the form of a two-dimensional table for the test tool platform to call.

3. The method for automatically generating call records of virtual numbers in batches and performing performance tests according to claim 1 is characterized in that: The steps in S2 are: B1: Determine the required data and create an interface. Determine that the required data is the virtual number call record. The interface is the business interface for the virtual number call record on the B side. B2: Calibrate the data plan. Through the interface document, confirm the interface input parameter fields corresponding to the test data plan, adjust the test data plan document formed in the previous step, and prepare for the subsequent parameterization of the interface.

4. The method for automatically generating call records of virtual numbers in batches and performing performance tests according to claim 1 is characterized in that: The steps in S3 are: C1: Build CSV, build JMeter HTTP Request Sampler and CSV Data SetConfig for the interface under test; C2: Get basic information, access the XB binding relationship table of the business database through the associated business order orderid specified by the CSV parameter template, and automatically obtain the basic information required by the interface. C3: Build information. Combine the information in the temporary table built in the previous step with the information specified in the CSV template file to automatically calculate and build other field information. C4: Configuration components, configure the number of concurrent threads, thread concurrency properties, collection points, and system resource monitor components.

5. The method for automatically generating call records of virtual numbers in batches and performing performance tests according to claim 1 is characterized in that: The steps in S4 are: D1: Reference CSV files. Different CSV files are referenced according to different test scenarios. D2: Adjust the switch, adjust the post-processing component switch according to needs; D3: Performance testing, executing test sets, building test data or performing performance testing.

6. The method for automatically generating call records of virtual numbers in batches and performing performance tests according to claim 1 is characterized in that: Virtual number: A mobile phone number provided by a virtual number operator, referred to as X number. It acts as an intermediate number in the process of calling user A making a call and called user B receiving a call. The calling user uses A number to dial X number and transfers the call to B number to complete the call process.

7. The method for automatically generating call records of virtual numbers in batches and performing performance tests according to claim 2 is characterized in that: The virtual number call record: After the call is completed, the virtual number operator will call the call record interface to pass the time attributes, number attributes, and recording information of the call process to the user. The user will form a call record based on the interface call content and record it into the database, and process it at the same time to implement the relevant product function logic.

8. The method for automatically generating call records of virtual numbers in batches and performing performance tests according to claim 2 is characterized in that: The call types in A1 are call forwarding by the calling party and call back by the called party, and the call bill service types are divided into C1, C2, and rush purchase pool.

Images