File testing method and device, electronic equipment and computer readable storage medium

Abstract

The invention discloses a file testing method and device, electronic equipment and a computer readable storage medium. The method comprises the steps that in response to a test instruction for target file attributes, a file warehouse used for storing preset test files is obtained, and the test instruction carries the target file attributes; based on the target file attribute, querying a target test file matched with the target file attribute from the preset test files in the file warehouse to obtain a query result; and in response to the query result, indicating that a target test file matched with the target file attribute exists in the file warehouse, and based on the target test file, executing a test task for the target file attribute to obtain a test result.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a file testing method, device, electronic device and computer-readable storage medium. Background Art

[0002] Object storage is an important direction for the development of cloud computing, and it is also the foundation of cloud computing development. It refers to a system in which a large number of different types of storage devices in the network, such as cluster applications, network technologies or distributed file systems, are brought together through application software to work together to provide data storage and business access functions to the outside world, ensuring data security and consistency. Object storage is divided into functional and performance testing. Functional testing is mainly to verify whether the general functions of object storage are normal, such as file upload, file download, file deletion, etc. Performance testing mainly verifies various performance indicators of object storage through certain stress simulation and testing, mainly including concurrent read and write, IOPS, throughput, latency, stability and other indicators, which can help users discover and locate performance problems in object storage and provide favorable support for performance optimization.

[0003] In the related art, testing of target file attributes usually requires real-time generation of a test file of the target file attributes, so as to perform a test task for the target file attributes based on the test file. Since the test file of the target file attributes is generated in real time, the real-time generation process will take up a lot of test time, resulting in a significant increase in the task time for executing the test task, thereby causing low efficiency in file testing. Summary of the invention

[0004] In order to solve the technical problems existing in the related art, the embodiments of the present application provide a file testing method, device, electronic device and computer-readable storage medium.

[0005] To achieve the above purpose, the technical solution of the embodiment of the present application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a file testing method, which is applied to an electronic device, and the method includes:

[0007] In response to a test instruction for a target file attribute, obtaining a file repository for storing a preset test file, wherein the test instruction carries the target file attribute;

[0008] Based on the target file attribute, querying the preset test files in the file warehouse for a target test file that matches the target file attribute to obtain a query result;

[0009] In response to the query result indicating that there is a target test file matching the target file attribute in the file repository, a test task for the target file attribute is executed based on the target test file to obtain a test result.

[0010] In a second aspect, an embodiment of the present application provides a file testing device, which is applied to an electronic device, including:

[0011] An acquisition module, configured to acquire a file repository for storing a preset test file in response to a test instruction for a target file attribute, wherein the test instruction carries the target file attribute;

[0012] A query module, configured to query a target test file matching the target file attribute from the preset test files in the file repository based on the target file attribute, and obtain a query result;

[0013] The execution module is used for executing a test task for the target file attribute based on the target test file in response to the query result indicating that there is a target test file matching the target file attribute in the file repository to obtain a test result.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a first memory for storing a computer program that can be run on the processor;

[0015] Wherein, when the processor is used to run the computer program, it executes the steps of the file testing method on the electronic device side described in the embodiment of the present application.

[0016] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the file testing method provided by the embodiment of the present application is implemented.

[0017] The file testing method, device, electronic device and computer-readable storage medium provided by the embodiment of the present application obtain a file warehouse for storing preset test files in response to a test instruction for the target file attribute, query the target test file matching the target file attribute from the preset test files in the file warehouse based on the target file attribute, obtain the query result, and in response to the query result indicating that there is a target test file matching the target file attribute in the file warehouse, execute the test task for the target file attribute based on the target test file to obtain the test result. In this way, since the preset test files stored in the file warehouse are pre-generated, rather than generating the test files in real time during the test, the pre-generated test files are stored in a file warehouse that is well organized and convenient for rapid retrieval and matching. When it is necessary to test a target file with specific attributes, the file warehouse will be queried to find the pre-generated test file matching the target file attribute. Since the test file already exists and does not need to be generated during the test, the test task can be executed immediately without waiting for the file generation process, which reduces the time required for real-time file generation, so that test resources can be used more for executing test tasks rather than file generation, thereby effectively shortening the test cycle and effectively improving the efficiency of file testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 Schematic diagram of the process of the file testing method provided in the embodiment of the present application Figure 1 ;

[0019] Figure 2 Schematic diagram of the process of the file testing method provided in the embodiment of the present application Figure 2 ;

[0020] Figure 3 Schematic diagram of the process of the file testing method provided in the embodiment of the present application Figure 3 ;

[0021] Figure 4 Schematic diagram of the process of the file testing method provided in the embodiment of the present application Figure 4 ;

[0022] Figure 5 A schematic diagram of the principle of the file testing method provided in the embodiment of the present application;

[0023] Figure 6 A schematic diagram of the structure of a file testing device according to an embodiment of the present application;

[0024] Figure 7 A schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0027] Object storage is an important direction and foundation of cloud computing development. It refers to a system that uses cluster applications, network technology or distributed file systems to bring together a large number of different types of storage devices in the network through application software to work together to provide data storage and business access functions to the outside world, ensuring data security and consistency.

[0028] Object storage is divided into functional and performance testing. Functional testing is mainly to verify whether the general functions of object storage are normal, such as file upload, file download, file deletion, etc. Performance testing mainly verifies various performance indicators of object storage through certain stress simulation and testing, mainly including concurrent reading and writing, IOPS, throughput, latency, stability and other indicators, which can help users discover and locate performance problems in object storage and provide favorable support for performance optimization.

[0029] Usually, the traditional test method of object storage is to conduct the corresponding IO test for the file size, such as 4KB, 128KB, 1MB, 4MB, etc. The size is for the IO model. The test of different file types is ignored. In the actual use environment, customers store real files of different types in the object storage cluster. In this case, the test cannot reflect the customer's real use scenario, and there is a deviation between the test results and the actual use scenario.

[0030] In the related art, a test tool is used to specify a file size for testing. Among the test files generated by the test tool, only the file size meets the requirements, and the file type cannot be generated according to the requirements. Moreover, the generated files are all simulated files, not real files (such as real picture files, video files, etc.), and cannot cover the customer's actual usage scenarios.

[0031] In the related art, manual testing requires downloading files of specified types and sizes to the test machine each time. If the file type and size requirements change, the test files need to be downloaded to the test machine multiple times. In addition, the correspondence between the file type and size and the file name needs to be clearly understood for each test. Once a mistake is made, the entire test result will be wrong. This method is extremely inflexible and inefficient, and it is impossible to perform performance stress testing.

[0032] In the related art, it is impossible to test the object storage cluster according to the file type and file size, so the testing method has the following disadvantages:

[0033] The first one is that when you use the test tool to specify the file size for testing, the test tool generates a test file with only the file size that meets the requirements. The file type cannot be generated according to the requirements, and the generated files are all simulated files, not real files (such as real image files, video files, etc.). As a result, the test is different from the actual application, and different types of files and object storage have poor compatibility issues.

[0034] The second method is manual testing. Each time, you need to download a file of a specified type and size to the test machine. If the file type and size requirements change, you need to download the test file to the test machine multiple times. It is impossible to automatically generate a suitable test file. In addition, each test requires the clear correspondence between the file type, size and file name. Once a mistake is made, the entire test result will be wrong. This method is extremely inflexible and inefficient, and it is impossible to perform performance stress testing.

[0035] Therefore, it is necessary to introduce new technologies and testing methods to improve test efficiency and test coverage and enhance flexibility. The embodiment of the present application solves the problem that the existing technical solution uses virtual files in the test, resulting in different test scenarios from actual application scenarios, and poor compatibility between different types of files and object storage, by creating a real file warehouse technology, thereby improving the coverage of file compatibility testing; the file warehouse solves the problem of inefficiency in frequently adding test files manually by automatically generating new real files, thereby improving test efficiency.

[0036] Based on this, an embodiment of the present application provides a file testing method, which is applied to electronic equipment. Figure 1 The process diagram of the file testing method of the embodiment of the present application is as follows Figure 1 ;like Figure 1 As shown, the file testing method provided in the embodiment of the present application can be Figure 1 Steps 101 to 103 are shown to be implemented.

[0037] In step 101, in response to a test instruction for a target file attribute, a file repository for storing a preset test file is obtained.

[0038] In some embodiments, the test instruction carries the target file attribute.

[0039] In some embodiments, in the field of software testing, in response to a test instruction for a target file attribute, a file repository for storing preset test files is obtained, and a tester or an automated test script issues a test instruction, which contains some specific attributes about the target file. These attributes may include the file name, file type, file size, file modification time, file path, etc. The target file attributes are explicitly specified in the test instruction and are used to identify and filter the files to be tested. For example, the test instruction may specify to find all files of type .txt and test whether their contents meet expectations.

[0040] In some embodiments, a file warehouse refers to a system or directory dedicated to storing, managing and providing file resources required in the testing process. In the software testing process, in response to the test instructions for the target file attributes, the file warehouse is a key component, which contains a set of predefined and configured test files, which are used to verify and test the functions, performance and compatibility of the software application.

[0041] In some embodiments, before obtaining the file warehouse for storing preset test files, the following processing can also be performed: obtaining an initial file warehouse, the number of preset test files in the initial file warehouse is less than the number of preset test files in the file warehouse; calling a file prediction model, based on each of the preset test files in the initial file warehouse, predicting the updated test files in the initial file warehouse to obtain predicted test files; adding the predicted test files to the initial file warehouse to obtain the file warehouse.

[0042] In some embodiments, the purpose of obtaining an initial file warehouse is to obtain an initial file warehouse containing a certain number of preset test files. This warehouse may be manually created by a tester or generated by an automated script. The number of preset test files in the initial file warehouse is less than the number of preset test files in the file warehouse, indicating that the number of test files in the initial file warehouse is insufficient. Compared with the final file warehouse, it requires more test files to meet the test requirements. The file prediction model can predict or generate new test files based on the existing test file data. This file prediction model can be based on a machine learning algorithm to infer possible file content or structure by analyzing the characteristics and patterns of existing files. The file prediction model uses the file data in the initial file warehouse to learn the characteristics of the file. These characteristics may include the content, format, structure, metadata, etc. of the file. After being processed by the prediction model, a set of new test files will be generated. These files are predicted and may be used to simulate different test scenarios or use cases. The generated predicted test files are added to the initial file warehouse to expand the number of test files in the warehouse. The number of test files in the initial file warehouse is supplemented, thereby forming a more complete final file warehouse that better meets the test requirements.

[0043] In some embodiments, the file prediction model can predict and generate new file instances based on existing file data by analyzing and learning the intrinsic features and patterns of the files. The purpose of the file test model is to expand or enhance the file collection in the test file warehouse to meet specific testing needs, especially when the number of files in the initial warehouse is not enough to cover all expected test scenarios. The file test model receives preset test files in the initial file warehouse as input data. These files contain specific features and attributes required for testing. The file test model learns the intrinsic connections and laws between these files by analyzing the common features, structure, content and metadata of these files. Based on the learned features and patterns, the file test model predicts and generates new test files that simulate the situations that may be encountered in actual testing. The file prediction model is called to generate additional test files, which are then added to the initial file warehouse, thereby building a more complete and diverse file warehouse for software testing. The file prediction model is very important in software testing, especially when a large number of diverse test files are required. It can improve the automation of testing, reduce the burden of manually creating files, and help improve the efficiency and effectiveness of testing.

[0044] As an example, suppose we are developing a file management software that needs to support the processing and conversion of multiple file formats. During the testing phase, we need to test files of different formats to ensure that the software can handle these files correctly. We start with a basic file repository that contains some common file formats, such as .txt, .docx, .pdf, etc., but the number of files is limited, with only a few test files in each format. In order to fully test the file management software, we need more test files, covering more file formats and different file attributes (such as size, content complexity, etc.). However, it is impractical to manually create a large number of test files. Through the file prediction model, it can analyze the files in the initial file repository and learn their characteristics. This model may use natural language processing (NLP) to generate text files, use templates to create documents in different formats, or use pattern recognition to generate image files, etc. The file prediction model analyzes existing .txt files and learns their structure and common content types (such as novels, news articles, code examples, etc.). Then, based on these features, the file prediction model predicts the generation of new .txt files, including texts of different lengths, different contents, and different styles. The file prediction model generates a series of new .txt files that are designed to be similar in content and format to the existing test files, but provide more samples and test scenarios. The newly generated prediction test files are added to the initial file repository, which significantly increases the number and diversity of files in the repository. By adding the prediction test files, a richer and more comprehensive file repository is obtained. This repository now contains enough files to test the performance and stability of the software in various file processing scenarios.

[0045] Continuing with the above example, the file prediction model may generate 100 new .txt files containing texts of different lengths and styles, ranging from short sentences to long stories. In this way, the performance of the software in processing text files of different sizes and its correctness in processing texts containing special formats or encodings can be tested. In this way, the comprehensiveness of the test is ensured and the test efficiency is greatly improved.

[0046] In this way, the test team can quickly expand the test file warehouse and effectively solve the problem of insufficient initial test files, thereby improving the coverage and accuracy of the test. The file prediction model can automatically generate test files that meet the actual application scenarios, which not only reduces the workload of testers, but also shortens the test preparation time. It helps to discover potential defects in the software when processing different types and feature files, and enhances the quality and stability of the software. This optimizes the test process, improves test efficiency, and ensures the reliability and performance of the software under a wide range of use conditions.

[0047] In step 102, based on the target file attribute, a target test file matching the target file attribute is searched from the preset test files in the file repository to obtain a search result.

[0048] In some embodiments, the file repository includes a mapping relationship for recording file attributes of the predictive test file, and the mapping relationship includes index entries corresponding to the preset test files one by one.

[0049] In some embodiments, the target file attribute is the key basis for the query, which defines the specific characteristics of the file that the user wants to retrieve. These attributes may include file name, file type, file size, creation date, content keywords, etc. The user can improve the accuracy of the query by specifying these attributes, avoid returning irrelevant files, and save time and resources. A large number of preset test files are stored in the file warehouse, which are prepared in advance for testing purposes. The goal of the query operation is to filter out files that match the target file attributes from these preset test files. The query result refers to a set of test files that match the target file attributes. It can be used for test automation scripts, test case creation, or file preparation in manual testing. In addition to storing the files themselves, the file warehouse also includes a mapping relationship system that records the file attributes of the predicted test files. The mapping relationship system is usually an index database that can quickly retrieve files associated with specific attributes. Each preset test file has an index entry in the mapping relationship, which contains all relevant attributes of the file.

[0050] In some embodiments, see Figure 2 , Figure 2 This is a flowchart of the file testing method provided in the embodiment of the present application. Figure 2 , the above step 102 can be Figure 2 Steps 1021 to 1023 are implemented as shown.

[0051] In step 1021, each of the index entries in the mapping relationship is matched with the target file attribute to obtain a matching result of each of the index entries.

[0052] In some embodiments, the index entry records the file attributes of the corresponding preset test file, the file attributes of the preset test file include multiple sub-file attributes, and the target file attributes include target sub-file attributes that correspond one-to-one to the sub-file attributes.

[0053] In some embodiments, the file repository uses a mapping relationship system to record and manage the attributes of the test files. Each preset test file has a corresponding index entry in this system. The index entry contains various file attributes corresponding to the preset test file, which are used for query and matching operations. When it is necessary to find a test file that matches a specific test requirement, the index entry in the mapping relationship is used to match the target file attributes. The matching process involves comparing the file attributes in the index entry with the target file attributes specified in the test instruction. The matching result of each index entry indicates whether the entry is consistent with the target file attributes. If it matches, the corresponding preset test file may be used for testing. The matching result can be a Boolean value (match or not match) or a more detailed scoring system indicating the closeness of the match. The preset test file attributes recorded by the index entry usually include multiple sub-attributes, such as file size, file type, file modification time, file content summary, etc. These sub-attributes provide a more fine-grained file description, which helps a more accurate matching process. The target file attributes are specified in the test instruction, and they correspond to the sub-file attributes of the preset test file. For example, if the target file attributes include file type and file size, the file attributes of the preset test file should also include corresponding sub-attributes to match them.

[0054] In some embodiments, by matching the target file attributes with the sub-file attributes in the index entries, the system can accurately find the test files that meet the test requirements. Since the file attributes of the preset test files include multiple sub-attributes, this provides flexibility for testing, allowing testers to select different attribute combinations according to different test scenarios. If the test requirements change, or new file attributes need to be added, the structure of the mapping relationship and index entries can be easily expanded to adapt to these changes. The use of mapping relationships and index entries makes the file matching process more efficient.

[0055] In some embodiments, the above-mentioned step 1021 can be implemented in the following manner: performing the following processing for each of the index entries respectively: comparing each of the sub-file attributes in the index entry with the corresponding target sub-file attributes in the target file attributes respectively, and obtaining comparison results of each of the sub-file attributes; when there is the comparison result indicating that the sub-file attribute is the same as the corresponding target sub-file attribute in the target file attributes, determining the matching result of the index entry as a match between the index entry and the target file attribute; when there is no comparison result indicating that the sub-file attribute is the same as the corresponding target sub-file attribute in the target file attributes, determining the matching result of the index entry as a mismatch between the index entry and the target file attribute.

[0056] In some embodiments, for each index entry in the file repository, the system will perform a series of comparison operations. These index entries represent preset test files in the repository, and each entry contains multiple sub-file attributes. For each sub-file attribute in the index entry, the system will compare it with the corresponding sub-file attribute in the target file attribute. The target file attributes are extracted from the test instructions, and they have a one-to-one correspondence with the sub-file attributes of the index entry. The comparison operation will produce a result indicating whether the sub-file attribute matches the target sub-file attribute. The comparison result of each sub-file attribute is independent, and they may or may not match. If the comparison results of all sub-file attributes indicate a match (i.e., each sub-file attribute matches the target sub-file attribute), the matching result of the index entry will be determined as a match. If the comparison result of any sub-file attribute indicates a mismatch (i.e., at least one sub-file attribute does not match the target sub-file attribute), the matching result of the index entry will be determined as a mismatch. The matching result will determine which preset test files can be used for subsequent testing activities. Only those preset test files corresponding to index entries that completely match the target file attributes will be selected.

[0057] As an example, we are writing test cases for a file processing software that can read and convert documents in different formats. To test the software, we have a test file repository containing multiple file formats. Item 1: File name = "test1.docx", File type = "Word document", Modified date = "2023-04-01", Content summary = "Contains financial data". Item 2: File name = "sample.txt", File type = "Plain text file", Modified date = "2023-04-02", Content summary = "Simple log information". Item 3: File name = "project.pdf", File type = "PDF document", Modified date = "2023-04-03", Content summary = "Contains complex charts and formulas".

[0058] Continuing with the above example, the target file attributes in the test instruction are: target file type = "Word document", target modification date range = "2023-04-01" to "2023-04-03". For entry 1, compare: file type = "Word document" (matches the target file type). Modification date = "2023-04-01" (matches the target modification date range). For entry 2, compare: file type = "plain text file" (does not match the target file type). Modification date = "2023-04-02" (partially matches the target modification date range). For entry 3, compare: file type = "PDF document" (does not match the target file type), modification date = "2023-04-03" (matches the target modification date range).

[0059] Continuing with the above example, determine the matching results: Item 1: All sub-file attributes match the target sub-file attributes, so the matching result is a match. Item 2: The file type does not match, so the matching result is a mismatch. Item 3: The file type does not match, but the modification date does match, so the matching result is a mismatch. Only Item 1 is determined to match the target file attributes, so it will be used to test the software's ability to process Word documents. Items 2 and 3 will not be used in this test because at least one of their sub-file attributes does not match.

[0060] In this way, by comparing the sub-file attributes with the target sub-file attributes for each index entry and determining the matching results, efficient and accurate file retrieval can be achieved. This attribute-based matching method can ensure that the test file is closely related to the test requirements, improving the pertinence and accuracy of the test. At the same time, this automated processing flow reduces the tedious work of manual file screening, saves testing time and reduces the risk of human error. Through this precise matching mechanism, the test team can quickly locate files that meet specific test scenarios, thereby improving test efficiency and ensuring the stability and reliability of the software when processing various file types.

[0061] In step 1022, when the matching result indicates that the index entry matches the target file attribute, the query result is determined as the first query result.

[0062] In some embodiments, the first query result is used to indicate that there is a target test file matching the target file attribute in the file repository.

[0063] In some embodiments, when the comparison result indicates that the index entry matches the target file attributes, this means that the preset test file corresponding to the index entry meets all the file attributes specified in the test instruction. The index entry is considered a valid match and will be added to the first query result. The first query result is a set that contains all index entries that completely match the target file attributes. This set can be used to indicate that there is a target test file in the file repository that matches the target file attributes. The existence of the first query result indicates that there are files in the file repository that meet the file attribute requirements in the test instruction.

[0064] In step 1023, when there is no matching result indicating that the index entry matches the target file attribute, the query result is determined as a second query result.

[0065] In some embodiments, the second query result is used to indicate that there is no target test file matching the target file attribute in the file repository.

[0066] In some embodiments, when the comparison result indicates that no index entry matches the target file attribute, that is, no sub-file attribute of the preset test file completely meets the requirements of the target file attribute, then the query result will be determined as the second query result. The second query result is usually an empty set or a special indicator indicating that no matching files are found. The second query result is used to indicate that there are no files in the file repository that match the target file attribute.

[0067] In some embodiments, based on the target file attributes, the target test file that matches the target file attributes is queried from the preset test files in the file repository. After obtaining the query result, the following processing can also be performed: in response to the query result indicating that there is no target test file that matches the target file attributes in the file repository, an updated test file that matches the target file attributes is created; based on the updated test file, a test task for the target file attributes is executed to obtain the test result.

[0068] In some embodiments, the test system first searches for a preset test file from the file warehouse according to the set target file attributes (such as file type, size, content, creation date, etc.). The target file attributes are pre-defined by the tester according to the test requirements and expected test scenarios. The query result is a set of files retrieved from the file warehouse according to the target file attributes. If the query result contains at least one test file that matches the target file attributes, the file can be used for subsequent test tasks. If the query result is empty, that is, no test file matching the target file attributes is found, the test system needs to perform the following processing steps: Create an updated test file that matches the target file attributes. This can be achieved in the following ways: Automatic generation: Use a test tool or script to automatically generate a new file that matches the target attributes. Manual creation: The tester manually creates a new file according to the target attributes. Template use: Use a pre-defined template and fill data to automatically create a new file. Use the newly created updated test file to perform test tasks for the target file attributes. Run an automated test script. Manually execute test cases. Tests performed using simulated data or synthetic data.

[0069] In some embodiments, after the test task is completed, the test system collects and records the test results, which can be used to analyze whether the behavior of the tested system meets expectations. When there is no ready-made test file in the file repository, it can respond and automatically create a new test file, which improves the adaptability of the test system. By automatically handling the situation where there are no matching results, testers can save time because there is no need to manually create test files. The completeness of the test case is ensured because all expected test scenarios are considered, whether by querying existing files or creating new files.

[0070] In some embodiments, the test system queries the preset test files from the file warehouse based on the target file attributes (such as file type, size, content, etc.). If the query result indicates that no files matching the target file attributes are found, this means that the existing preset test files cannot meet the current test requirements. In this case, the test system can automatically respond and create new test files that will meet the requirements of the target file attributes. The newly created test files can be automatically generated by the test system or manually created by the tester based on the target file attributes. Once the updated test files are created, the test system can perform corresponding test tasks based on these files. The test tasks can be automated test scripts, manual test steps, or other types of test activities. After the test tasks are executed, the test system will collect the test results, which can be used to evaluate the performance, stability, or security of the system being tested.

[0071] In some embodiments, the target file attributes include multiple target sub-file attributes, and the creation of an update test file that matches the target file attributes can be achieved in the following manner: performing feature extraction on each of the target sub-file attributes to obtain attribute features of each of the target sub-file attributes; calling a file prediction model to perform file prediction on the target file attributes based on the attribute features of each of the target sub-file attributes to obtain the update test file.

[0072] In some embodiments, the target file attribute is decomposed into multiple target sub-file attributes, each of which contains specific information. Feature extraction is to extract information of each target sub-file attribute to facilitate subsequent prediction and generation operations. For example, if the target sub-file attributes include file type and file size, feature extraction may extract the category label of the file type and the numerical value of the file size. The file prediction model is a pre-trained model that can predict the corresponding file content based on the input feature data. After the feature extraction is completed, these attribute features are used as input to the file prediction model. The file prediction model uses the input attribute features to predict and generate a new test file, which should meet the requirements of all target sub-file attributes. The prediction model may use machine learning algorithms, such as neural networks, decision trees, etc., to predict the content and structure of the file. The file generated by the file prediction model is the update test file, which will match the target file attributes. The update test file can be used for subsequent test tasks, such as functional testing, performance testing, security testing, etc.

[0073] In some embodiments, the calling of feature extraction and file prediction models realizes the automation of test file generation, reducing the possibility of manual intervention and errors. The file prediction model can quickly generate test files that meet specific attributes, improving the efficiency and accuracy of test preparation. The feature extraction and file prediction models can be configured according to different target file attributes to make them suitable for a variety of test scenarios. As new test requirements emerge, the file prediction model can continue to learn and generate new test files, enhancing the scalability of the test process.

[0074] In some embodiments, after the update test file matching the target file attribute is created, the following processing may be performed: based on the update test file, the file repository is updated to obtain an update file repository.

[0075] In some embodiments, the previous process has created an updated test file that matches the target file attributes. The newly created updated test file is uploaded to the file warehouse. If the file warehouse stores file metadata (such as file descriptions, tags, attributes, etc.), update these metadata to reflect the information of the new file. Due to the addition of new files, the file index may need to be rebuilt to ensure search and retrieval efficiency. Ensure that the new file is consistent with the format and standard of other files in the file warehouse. If there is a version control system, the new file will be added to the version history to track file changes. The file warehouse contains all existing files as well as the newly added updated test files. The updated file warehouse now contains a more comprehensive collection of test files that can meet a wider range of testing needs. Updating the file warehouse can ensure that testers have access to all necessary test files, thereby improving the comprehensiveness and quality of testing. The addition of new files makes the test files richer and more diverse, and testers can more easily find files suitable for specific test scenarios.

[0076] In step 103, in response to the query result indicating that there is a target test file matching the target file attribute in the file repository, a test task for the target file attribute is executed based on the target test file to obtain a test result.

[0077] In some embodiments, the file attributes of the preset test file include a plurality of sub-file attributes, and the target file attributes include target sub-file attributes corresponding one-to-one to the sub-file attributes.

[0078] In some embodiments, when the query result indicates that there is a target test file in the file warehouse that matches the target file attributes, this means that a specific file that meets the test requirements has been found. The selected test file will serve as a benchmark for executing the test task. A test task refers to a test activity performed on the target file attributes according to a test plan, which is intended to verify the functionality, performance, security, etc. of the system. After the test task is executed, the test results will be collected, which are used to evaluate whether the behavior of the tested system meets expectations. The file attributes of the preset test file include multiple sub-file attributes, which may correspond one-to-one to the corresponding sub-file attributes in the target file attributes. The one-to-one correspondence ensures the accuracy and pertinence of the test task because the test task is designed based on specific target file attributes.

[0079] In some embodiments, see Figure 3 , Figure 3 This is a flowchart of the file testing method provided in the embodiment of the present application. Figure 3 , the above step 103 can be Figure 3 Steps 1031 to 1032 are implemented as shown.

[0080] In step 1031, in response to the query result indicating that there is a target test file matching the target file attribute in the file repository, comparison information of the attributes of each sub-file in the target test file is obtained.

[0081] In some embodiments, the comparison information is used to indicate whether each of the sub-file attributes of the target test file is the same as the corresponding target sub-file attribute in the target file attribute.

[0082] In some embodiments, when the query result indicates that there are target test files matching the target file attributes in the file warehouse, the test system will obtain these files for further processing. The test system will extract the attributes of each sub-file in the target test file. These sub-file attributes will be compared with the target sub-file attributes in their corresponding target file attributes. The comparison information is used to verify whether the sub-file attributes of the target test file are exactly the same as the corresponding target sub-file attributes in the target file attributes. If the comparison results of all sub-file attributes are shown to be the same, then it can be considered that the target test file fully meets the requirements of the target file attributes. The comparison of sub-file attributes may include multiple aspects, such as file type, size, creation date, version number, content, etc. This comparison may be performed automatically by an algorithm to ensure accuracy and consistency.

[0083] In some embodiments, by comparing sub-file attributes, it is possible to verify whether the target test file meets the test requirements and ensure the accuracy of the test. The comparison process is usually performed automatically, reducing the possibility of human error and improving processing efficiency. If the comparison results show that the target test file meets the requirements, the test task can be prepared immediately without further processing. A consistent file attribute comparison process helps ensure the repeatability and reliability of the test. Automated comparison reduces the workload of testers and optimizes the use of test resources.

[0084] In step 1032, based on the comparison information and the target test file, a test task for the target file attribute is executed to obtain the test result.

[0085] In some embodiments, the above-mentioned step 1032 can be implemented in the following manner: in response to the comparison information indicating that each of the sub-file attributes of the target test file is the same as the corresponding target sub-file attributes in the target file attributes, based on the target test file, executing the test task for the target file attributes to obtain the test result; in response to the comparison information indicating that some of the sub-file attributes of the target test file are different from the corresponding target sub-file attributes in the target file attributes, determining the different sub-file attributes as sub-file attributes to be adjusted; adjusting each of the sub-file attributes to be adjusted in the target test file to the corresponding target sub-file attributes to obtain a reference test file; based on the reference test file, executing the test task for the target file attributes to obtain the test result.

[0086] In some embodiments, if the comparison information shows that each sub-file attribute of the target test file is exactly the same as the corresponding target sub-file attribute in the target file attribute, this means that the test file has met the test requirements. In this case, the test system can directly use the target test file to perform the test task for the target file attribute. The test task may be an automated test, a performance test, a security test, etc., which is intended to verify whether the behavior of the system meets expectations. If the comparison information shows that some sub-file attributes of the target test file are not exactly the same as the corresponding target sub-file attributes in the target file attribute, this means that the test file needs to be adjusted to meet the test requirements. These incomplete sub-file attributes are determined as sub-file attributes to be adjusted, and they need to be adjusted to match the target sub-file attributes. The sub-file attributes to be adjusted in the target test file are adjusted to the corresponding target sub-file attributes respectively. This adjustment may be achieved by modifying the file content, changing the file structure, updating the file metadata, etc.

[0087] As an example, a file management software is being developed, and this software needs to ensure that the attributes of the target file and its sub-files are consistent. The target file here refers to a main file, which contains multiple sub-files. In response to the comparison information indicating that the attributes of each sub-file of the target test file are the same as the corresponding target sub-file attributes in the target file attributes, suppose we have a target test file Parent.zip, which contains two sub-files Child1.txt and Child2.txt. A property comparison is performed, and the result shows that the attributes of Child1.txt and Child2.txt in Parent.zip (such as permissions, size, creation date, etc.) are completely consistent with the corresponding sub-file attributes in the target file. Based on this target test file, a test task for the target file attributes is performed, such as checking whether the decompression function of the compressed file is normal. The test results are recorded and used to verify the correctness of the software. In response to the comparison information indicating that the attributes of each sub-file of the target test file are partially different from the corresponding target sub-file attributes in the target file attributes, it is assumed that the comparison result shows that the attributes of Child1.txt in Parent.zip are inconsistent with the corresponding sub-file attributes in the target file, such as different permission settings. Determine the different sub-file attributes as the sub-file attributes to be adjusted: Determine the permission settings of Child1.txt as the attributes to be adjusted. Adjust the permission settings of Child1.txt in Parent.zip to be consistent with the corresponding sub-file attributes in the target file. Based on the reference test file, execute the test task for the target file attribute to obtain the test result, and execute the test task again based on the adjusted reference test file `Parent.zip`, such as testing the decompression function, and compare the results of this test with the results of the first test to verify whether the attribute adjustment has achieved the expected effect.

[0088] In this way, by comparing the matching degree between the target test file and the target file attributes, the problem of inconsistent attributes can be quickly identified and located in the early stage of testing, avoiding errors caused by attribute mismatches in subsequent tests. After accurately adjusting the attributes of the mismatched sub-files, the generated reference test file ensures the accuracy of the test environment, making the test results for the target file attributes more reliable. This not only optimizes the test process, but also reduces the risk of software release and improves the end-user experience.

[0089] In some embodiments, the above-mentioned execution of the test task for the target file attribute based on the target test file to obtain the test result can be achieved in the following manner: performing feature extraction on the file attribute of each of the preset test files in the file warehouse to obtain the file attribute feature of each of the preset test files; calling the file prediction model to perform a recommended evaluation on each of the preset test files in the file warehouse based on the file attribute feature of each of the preset test files to obtain the evaluation score of each of the preset test files; determining the preset test file with the largest evaluation score in the file warehouse as the recommended test file in the file warehouse; and executing the test task for the target file attribute based on the target test file and the recommended test file to obtain the test result.

[0090] In some embodiments, a preset test file set is selected from a file repository. Feature extraction is performed on the attributes of these test files, which may include features such as file type, size, creation time, modification time, access rights, file content summary (such as hash value), and file internal structure. The purpose of feature extraction is to obtain a vector or set that can represent the file attributes, and these feature vectors will be used for subsequent recommendation evaluation. Using the trained file prediction model, the attribute feature vectors of each preset test file are input. The model may be based on a machine learning algorithm, such as a decision tree, a random forest, a neural network, etc., which is used to predict its performance or applicability in a specific test task based on the file attributes. The model outputs the evaluation score of each preset test file, which reflects the expected performance of the file in the test task. Among all the evaluation scores, the preset test file with the highest score is selected and determined as the recommended test file. This process assumes that the higher the evaluation score, the better the file performs in the test task, so it is the most suitable file for testing. Based on the target test file and the recommended test file, a targeted test task is performed. The test task may include functional testing, performance testing, security testing, etc., depending on the test requirements of the target file attributes. Document test results that will be used to evaluate the performance and reliability of the file management software or system.

[0091] In some embodiments, a file prediction model refers to a computer algorithm or system that predicts the performance or suitability of a file in a specific operation or test by analyzing the input file attribute characteristics. A file prediction model is a model constructed using machine learning, data mining or statistical methods. It accepts file attribute characteristics (such as file size, modification time, file type, content structure, etc.) as input and evaluates the expected effect of the file when performing a specific test task based on these characteristics. This file prediction model is usually trained with historical data, where the historical data contains the actual attributes and test results of previously tested files. The file prediction model learns this data so that it can predict new test files and give an evaluation score indicating the potential performance of the file in the test.

[0092] As an example, a file synchronization software is being tested, which needs to ensure that file attributes (such as size, modification time, permissions, etc.) remain consistent when synchronizing files between multiple devices. There is a file warehouse containing multiple preset test files, such as `File1.zip, File2.zip, File3.zip, etc. Attribute feature extraction is performed on each test file, which may include features such as file size, modification time, compression ratio, and number of files inside the file. For example, the following feature vectors are obtained: File1.zip: (size: 50MB, modification time: 2023-04-01 10:00, number of files: 10, compression ratio: 0.8), File2.zip: (size: 70MB, modification time: 2023-04-01 12:00, number of files: 15, compression ratio: 0.75); File3.zip: (size: 60MB, modification time: 2023-04-02 09:00, number of files: 20, compression ratio: 0.85).

[0093] In this way, the pertinence and efficiency of the test can be significantly improved. Through feature extraction and model evaluation, the most representative test files can be quickly screened out, thereby reducing resource consumption and time costs. In addition, this method can ensure the effectiveness of the test results, because it is based on high-quality test files recommended by the predictive model, which helps to more accurately discover and solve potential software problems, and ultimately improve software quality and user experience. At the same time, this process is also conducive to the optimal configuration of test resources and improves the overall efficiency of testing work.

[0094] Thus, in an automated testing environment, in response to the query results, if a target test file matching the target file attributes is found in the file repository, the sub-file attributes of these files can be obtained for comparison. By comparing the sub-file attributes, it is possible to verify whether the target test file meets the test requirements. Based on the verification results and the target test file, the corresponding test tasks are performed to obtain the test results. This process automation reduces the possibility of human error and improves processing efficiency. At the same time, this comparison process helps to ensure the accuracy of the test, optimize the use of test resources, and improve the efficiency of test preparation.

[0095] In this way, by responding to the test instruction for the target file attribute, a file warehouse for storing preset test files is obtained, and based on the target file attribute, a target test file matching the target file attribute is queried from the preset test files in the file warehouse to obtain a query result. In response to the query result indicating that there is a target test file matching the target file attribute in the file warehouse, a test task for the target file attribute is executed based on the target test file to obtain a test result. In this way, since the preset test files stored in the file warehouse are pre-generated, rather than generating test files in real time during testing, the pre-generated test files are stored in a file warehouse that is well organized and convenient for rapid retrieval and matching. When it is necessary to test a target file with specific attributes, the file warehouse will be queried to find a pre-generated test file matching the target file attribute. Since the test file already exists and does not need to be generated during testing, the test task can be executed immediately without waiting for the file generation process, which reduces the time required for real-time file generation, so that test resources can be used more for executing test tasks rather than file generation, thereby effectively shortening the test cycle and effectively improving the efficiency of file testing.

[0096] The present application is described below in conjunction with application examples.

[0097] In some embodiments, the file testing method provided in the embodiments of the present application can be implemented in the following manner: create a file warehouse, the file warehouse includes a real file collection and a file attribute database, the real file collection includes real files of different types, formats and sizes such as pictures, videos, text files, and the file attribute database records the file attributes, storage location, access times and other information of the real files; obtain the attributes of the file to be tested, and call the files in the file warehouse for testing; use machine learning methods to perform model training on the files in the file warehouse to generate new file samples.

[0098] According to the embodiments of the present disclosure, the technology of creating a real file warehouse is used to solve the problem that virtual files are used in the testing of existing technical solutions, resulting in test scenarios that are different from actual application scenarios, and poor compatibility between different types of files and object storage, thereby improving the coverage of file compatibility testing; the file warehouse solves the problem of inefficiency in frequent manual addition of test files by automatically generating new real files, thereby improving testing efficiency.

[0099] In some embodiments, a file repository is created; the repository includes a collection of real files and a file attribute database.

[0100] In some embodiments, a real file set is created. The real file set contains multiple real files, each real file has a specific type, format and size, and the real files have different type reference values. The file types include videos, pictures, text files, etc. The types and sizes of these files are derived from the files used in real scenarios in the current network operation environment. Different types of files also include different file formats, for example, picture formats include png, jpg, jpeg, etc., video formats include AVI, MP4, MOV, etc., and text file formats include txt, doc, csv, etc.; files of different formats have different file size reference values, for example, png, jpg, jpeg picture format sizes are 4MB, 16MB, 32MB, etc., AVI, MP4, MOV video format sizes are 128MB, 1GB, 5GB, etc., txt, doc, csv text file format sizes are 4KB, 128KB, 2MB, etc.

[0101] In some embodiments, a file attribute database is created. The file attribute database is created, and the file attribute database scans all real files in the real file set, and the file name, file type, file format, file size, file storage path, file access time, and file access count attributes of each file are written to a table in the file database, and the records in the file attribute database are used to quickly retrieve the real file to be tested.

[0102] In some embodiments, the file database includes the following multiple tables: a general table of picture files, recording the name, file type, file format, file size, file storage path, file access time, and file access count attributes of all real picture files; a general table of video files, recording the name, file type, file format, file size, file storage path, file access time, and file access count attributes of all real video files; a general table of text files, recording the name, file type, file format, file size, file storage path, file access time, and file access count attributes of all real text files; a general table of untyped files, recording the name, file size, file storage path, file access time, and file access count attributes of all untyped files; untyped files are automatically generated by calling the interface, and only the file name and file size need to be recorded, and the file type and format attributes are empty. A file high-frequency table, recording the name, file type, file format, file size, file storage path, file access time, and file access count attributes of high-frequency real files; wherein the high-frequency real files have a threshold reference value, which defaults to 10; the file records in the file high-frequency table are used for high-priority testing. The hot file table records the real file name, file type, file format, file size, file storage path, file access time, and file access count attributes of the hot file; the hot file has a threshold reference value, which defaults to 3 days; the file records in the hot file table are used for regression testing.

[0103] In some embodiments, the file repository may be configured on a public server or on a local storage of the test machine.

[0104] In some embodiments, see Figure 5 , Figure 5 A schematic diagram of the principles of the file testing method provided in an embodiment of the present application. In a scenario where multiple test machines are testing simultaneously, it is necessary to configure the file warehouse on a public server or local storage, for example, on a public cloud server. The test machine is connected to the elastic public network address of the public cloud server, and connected to the file warehouse configured on the cloud server through an interface, and the interface is called to use the real files in the file warehouse for testing. When testing on a single test machine, the file warehouse can be optionally configured on the local storage of the test machine, and the file warehouse on the local machine can be directly connected through a local interface, and the interface can be called to use the real files in the file warehouse for testing.

[0105] In some embodiments, a file repository is called.

[0106] In some embodiments, the attributes of the file to be tested are obtained, and the attributes of the file to be tested include the type of the file to be tested, the file format, and the file size.

[0107] Scheduler.getFile(): Gets the properties of the file to be tested; the function returns expected_size as the size of the file to be tested; expected_type as the type of file to be tested, and expected_formart as the format of the file.

[0108] In some embodiments, a file attributes database is searched.

[0109] In some embodiments, see Figure 5 , find the database table of the corresponding file type through the file type attribute, and then search the file attribute database for the file that is consistent with the attributes of the file to be tested through the file format and file size attributes. Finally, query the specified file through the file storage path recorded in the database table and test the file.

[0110] Scheduler.checkFile(table="", expected_size="", expected_type="", expected_formart=""): Retrieve files with the same attributes as the file to be tested from the file attribute database, where table is the file attribute database table, expected_size is the size of the file to be tested; expected_type is the file type to be tested, and expected_formart is the format of the file, which can be png, jpg, jpeg, AVI, MP4, MOV, etc. The default is empty, that is, the file type is not specified. If a file with the same attributes as the file to be tested can be found in the file common table, the file is returned as the file to be tested; if a file with the same type as the file to be tested can be found in the file common table, the file is returned as the source file to generate the file to be tested; otherwise the return value is empty.

[0111] In some embodiments, no file consistent with the attributes of the file to be tested can be retrieved in the file attribute database. A file consistent with the type and format of the file to be tested is retrieved in the file attribute database, and the file is used as the source file, and the interface is called to automatically expand and crop the source file to generate a file consistent with the attributes of the file to be tested; for example, if it is a picture file, the interface is called to adjust the resolution of the source file according to the size attribute of the file to be tested to generate a picture file consistent with the attributes of the file to be tested; if it is a video file, the interface is called to use video cropping and merging technology on the source file according to the size attribute of the file to be tested to generate a video file consistent with the attributes of the file to be tested.

[0112] Scheduler.createTestFile_sameformart(src="", expected_type="", expected_size="", expected_formart=""): creates a test file, where src is a file that already exists in the file repository; expected_type is the type of file to be tested, expected_size is the size of the file to be tested, and expected_formart is the format of the file to be tested.

[0113] In some embodiments, only files that are consistent with the file type to be tested can be retrieved in the file attribute database, and the file formats and sizes are different. The file that is consistent with the file type to be tested is selected as the source file, and an interface is called to automatically convert the format of the source file, convert the file format of the source file into the same format as the file to be tested, and then adjust the size of the source file to generate a file that is consistent with the attributes of the file to be tested.

[0114] Scheduler.createTestFile_sametype(src="", expected_size="", expected_type="", expected_formart=""): creates a test file, where src is a file that already exists in the file repository; expected_size is the size of the file to be tested, expected_type is the type of the file to be tested, and expected_formart is the format of the file to be tested.

[0115] In some embodiments, if the file in the file attribute database is inconsistent with all attributes of the file to be tested, the random number interface is directly called to generate a file consistent with the attributes of the file to be tested. The random number interface is similar to the Linux command: dd if= / dev / urandom of=testfile bs=1Mcount=1 to generate a file.

[0116] Scheduler.createTestFile_notype(expected_size="", expected_formart=""): creates a test file, where expected_size is the size of the file to be tested, and expected_formart is the format of the file to be tested.

[0117] To facilitate a better understanding of this solution, the following provides a specific implementation example of this solution, taking the file to be tested as a video, in AVI format, and 2GB in size as an example:

[0118] Get the properties of the file to be tested, call Scheduler.getFile(), and return the properties of the file to be tested, file type: Video, file format: AVI, file size: 2GB;

[0119] Search the file attribute database, find the video file general table by the video file type, call Scheduler.checkFile(table = "all_video", expected_size = "2GB", expected_type = "Video", expected_formart = "AVI") by the file format AVI and the file size 2GB, and return the file in the video file general table that has the same attributes as the file to be tested as the file to be tested;

[0120] Optionally, if only files of the same type as the file to be tested can be found in the video file common table, Scheduler.createTestFile_sametype(src="src_file", expected_type="Video", expected_size="2GB", expected_formart="AVI") is called to generate a new file with the same attributes as the file to be tested, and the return value is the new file.

[0121] In some embodiments, the file attributes database record is updated.

[0122] In some embodiments, the file access time and file access count attribute records of the file in the general table are updated, the file access time attribute record is updated to the current call time of the file, and the file access count attribute record is increased by 1. For example, the file called this time is from the picture file general table, the file access time attribute record of the picture file in the picture file general table is updated to the current call time, and the file access count attribute record of the picture file is changed from 0 to 1.

[0123] Scheduler.updateDB(table,file,access_time,access_num): table is a general table, file is the file to be tested, access_time is the time the file is accessed, access_num is the number of times the file is accessed, access_num+1.

[0124] In some embodiments, the hot file table is updated, and the name, file type, file format, file size, file storage path, file access time, and file access count attribute records of the locally called file are updated to the hot file table.

[0125] Scheduler.updateDB(table,file,access_time,access_num): table is the hot file table, file is the file to be tested, access_time is the time the file is accessed, access_num is the number of times the file is accessed, access_num+1.

[0126] In some embodiments, when a new file is generated by executing the step, a record is added to the corresponding general table to record the name, file type, file format, file size, file storage path, file access time, and file access count attributes of the calling file. For example, when a new picture file is generated, a record is added to the picture general table to record the name, file type, file format, file size, file storage path, file access time, and file access count attributes of the picture file.

[0127] In some embodiments, see Figure 4 , Figure 4 Schematic diagram of the process of the file testing method provided in the embodiment of the present application Figure 4 , the file testing method provided in the embodiment of the present application can be Figure 4 Steps 201 to 206 are shown to be implemented.

[0128] In step 201, the attributes of the file to be tested are obtained.

[0129] In step 202, it is determined whether the file to be tested exists in the file repository.

[0130] In some embodiments, when the file to be tested is in the file warehouse, step 204 is executed, and when the file to be tested is not in the file warehouse, step 203 is executed.

[0131] In some embodiments, the test scenario has a higher priority than the acquired attributes of the file to be tested. If the attributes of the file to be tested and the test scenario are acquired at the same time, the test scenario overwrites the acquired attributes of the file to be tested, and the test is performed according to the test scenario.

[0132] In some embodiments, see Figure 5 , using machine learning methods to automatically update the file warehouse.

[0133] In step 203, a file is generated.

[0134] In some embodiments, during the test, new files are constantly generated, and existing files are constantly called. The general table of picture files, general table of video files, general table of text files, general table of picture files, general table of untyped files, high-frequency table of files, and hot file table in the file attribute database are always updated. The linear regression algorithm in machine learning is used to train the model for file classification of all attributes in the file warehouse. The evolution of file sizes of different file types is predicted, and new real files and file attribute databases are automatically generated in the file warehouse.

[0135] In step 204, the policy is tested.

[0136] In some embodiments, the reference values ​​of the test strategy include sequence, random, and cycle, and the default is sequence. The sequence strategy will sequentially execute a test for all files that are consistent with the attributes of the file to be tested; the random strategy will randomly execute a test for all files that are consistent with the attributes of the file to be tested, and all files that are consistent with the attributes of the file to be tested will be tested once; the cycle strategy will execute the test for all files that are consistent with the attributes of the file to be tested in a loop until the test task is stopped. Scheduler.getTestSet(strategy="sequence"): where strategy is the test strategy, the optional methods are sequence, random, and cycle, and the default is sequence.

[0137] In step 205, a test scene is obtained.

[0138] The reference values ​​of the test scenario include high-frequency scenario, hot file scenario, and general scenario. The default is the general scenario. The test scenario calls all files in one of the high-frequency file table, hot file table, and general file table in the file attribute database for testing. In the general scenario, all files in the general table of image files, the general table of video files, the general table of text files, the general table of image files, and the general table of untyped files are called for testing; in the high-frequency scenario, all files in the high-frequency table are called for testing, and all files in the high-frequency table are tested once; in the hot file scenario, all files in the hot file table are called for testing, and all files in the high-frequency table are tested once.

[0139] In some embodiments, Scheduler.getTestField(strategy="",type="ALL"): obtains the test scenario; strategy is the test scenario, and the optional scenarios are Universal, High-frequency, and Hot; type is the file type, and the optional scenarios are ALL, Image, and Video. The default is ALL, which means all types of files.

[0140] In step 206, a test is performed.

[0141] In some embodiments, data is pre-processed.

[0142] In some embodiments, file type and file size data in a file repository is collected and converted into a format suitable for machine learning model training.

[0143] data = Scheduler.readTestFile (conn_DB, file_table): reads the file data in the file attribute database; conn_DB is the file attribute database, and file_table is the table in the file attribute database;

[0144] data['key'] = Scheduler.Preprocessing('key'): preprocesses the file data in the file attribute database and converts it into a format suitable for machine learning model training; where key can select the file type file_type and file size file_size.

[0145] In some embodiments, feature selection.

[0146] Select the file type and file size characteristics from the file properties in the file repository.

[0147] X_train_selected = Scheduler.Select(data['key']): where key can select file type file_type and file size file_size.

[0148] In some embodiments, a linear regression algorithm is used for modeling and training.

[0149] According to the complexity and attribute characteristics of the files in the file warehouse, a linear regression machine learning algorithm is selected for modeling and training.

[0150] model = Scheduler.fit(X_train_selected_filetype, data['filesize']): X_train_selected_filetype is the feature of the file type, and data['filesize'] is the file size.

[0151] In some embodiments, a model is utilized to predict file size.

[0152] Deploy the trained model to the test environment and make predictions on new files in the file warehouse.

[0153] newfile = model.predict_file_size(file_type): select the file type to predict the new file in the file warehouse; file_type is the file type, and newfile is the new file generated by the prediction.

[0154] In some embodiments, the real file set and the file attribute database in the file repository are updated, Scheduler.update(newfile): wherein newfile is a newly generated file.

[0155] In order to implement the file testing method on the electronic device side of the embodiment of the present application, the embodiment of the present application also provides a file testing device, Figure 6 Schematic diagram of the structure of the file testing device according to the embodiment of the present application. Figure 6 As shown, the file testing device includes: an acquisition module 61, which is used to obtain a file repository for storing preset test files in response to a test instruction for a target file attribute, wherein the test instruction carries the target file attribute; a query module 62, which is used to query a target test file that matches the target file attribute from the preset test files in the file repository based on the target file attribute, and obtain a query result; an execution module 63, which is used to execute a test task for the target file attribute based on the target test file in response to an indication from the query result that there is a target test file that matches the target file attribute in the file repository, and obtain a test result.

[0156] In some embodiments, the file repository includes a mapping relationship for recording the file attributes of the predicted test file, and the mapping relationship includes index entries corresponding to the preset test files one by one; the query module 62 is further used to match each of the index entries in the mapping relationship with the target file attributes to obtain matching results of each of the index entries;

[0157] When the matching result indicates that the index entry matches the target file attribute, determining the query result as the first query result;

[0158] When there is no matching result indicating that the index entry matches the target file attribute, determining the query result as a second query result;

[0159] Among them, the first query result is used to indicate that there is a target test file matching the target file attribute in the file warehouse, and the second query result is used to indicate that there is no target test file matching the target file attribute in the file warehouse.

[0160] In some embodiments, the index entry records the file attributes of the corresponding preset test file, the file attributes of the preset test file include multiple sub-file attributes, and the target file attributes include target sub-file attributes that correspond one-to-one to the sub-file attributes; the above-mentioned query module 62 is also used to perform the following processing for each of the index entries: compare each of the sub-file attributes in the index entry with the corresponding target sub-file attribute in the target file attributes, and obtain a comparison result of each sub-file attribute; when there is a comparison result indicating that the sub-file attribute is the same as the corresponding target sub-file attribute in the target file attributes, determine the matching result of the index entry as that the index entry matches the target file attribute; when there is no comparison result indicating that the sub-file attribute is the same as the corresponding target sub-file attribute in the target file attributes, determine the matching result of the index entry as that the index entry does not match the target file attribute.

[0161] In some embodiments, the file attributes of the preset test file include multiple sub-file attributes, and the target file attributes include target sub-file attributes that correspond one-to-one to the sub-file attributes; the above-mentioned execution module 63 is also used to obtain comparison information of each sub-file attribute in the target test file in response to the query result indicating that there is a target test file matching the target file attribute in the file repository; the comparison information is used to indicate whether each sub-file attribute of the target test file is the same as the corresponding target sub-file attribute in the target file attribute; based on the comparison information and the target test file, execute the test task for the target file attribute to obtain the test result.

[0162] In some embodiments, the execution module 63 is further configured to, in response to the comparison information indicating that each of the sub-file attributes of the target test file is the same as the corresponding target sub-file attribute in the target file attribute, execute the test task for the target file attribute based on the target test file to obtain the test result;

[0163] In response to the comparison information indicating that some of the sub-file attributes of the target test file are different from the corresponding target sub-file attributes in the target file attributes, determining the different sub-file attributes as sub-file attributes to be adjusted;

[0164] Adjusting the attributes of each sub-file to be adjusted in the target test file to the corresponding target sub-file attributes to obtain a reference test file;

[0165] Based on the reference test file, a test task for the target file attribute is executed to obtain the test result.

[0166] In some embodiments, the execution module 63 is further configured to create an update test file matching the target file attribute in response to the query result indicating that there is no target test file matching the target file attribute in the file repository;

[0167] Based on the updated test file, a test task for the target file attribute is executed to obtain the test result.

[0168] In some embodiments, the execution module 63 is further used to extract features of the attributes of each target sub-file to obtain attribute features of the attributes of each target sub-file;

[0169] The file prediction model is called to perform file prediction on the target file attributes based on the attribute characteristics of each target sub-file attribute to obtain the updated test file.

[0170] Based on the update test file, the file repository is updated to obtain an updated file repository.

[0171] In some embodiments, the execution module 63 is further used to extract features of the file attributes of each of the preset test files in the file repository to obtain file attribute features of each of the preset test files;

[0172] Calling the file prediction model, based on the file attribute characteristics of each of the preset test files, recommending and evaluating each of the preset test files in the file warehouse, and obtaining an evaluation score for each of the preset test files;

[0173] Determine the preset test file with the largest evaluation score in the file warehouse as the recommended test file in the file warehouse;

[0174] Based on the target test file and the recommended test file, a test task for the target file attribute is executed to obtain the test result.

[0175] In some embodiments, the execution module 63 is further used to obtain an initial file warehouse, wherein the number of the preset test files in the initial file warehouse is less than the number of the preset test files in the file warehouse;

[0176] Calling a file prediction model to predict the updated test file in the initial file warehouse based on each of the preset test files in the initial file warehouse to obtain a predicted test file;

[0177] The predicted test file is added to the initial file warehouse to obtain the file warehouse.

[0178] In actual application, the acquisition unit 61 and the execution unit 63 can be implemented by a processor in the file testing device; and the query unit 62 can be implemented by a communication interface in the file testing device.

[0179] It should be noted that: when the file testing device provided in the above embodiment performs file testing, only the division of the above program modules is used as an example. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device is divided into different program modules to complete all or part of the processing described above. In addition, the file testing device provided in the above embodiment and the file testing method embodiment on the electronic device side belong to the same concept. The specific implementation process is detailed in the file testing method embodiment on the electronic device side, which will not be repeated here.

[0180] Based on the hardware implementation of the above program modules, and in order to implement the file testing method on the electronic device side of the embodiment of the present application, the embodiment of the present application also provides an electronic device, Figure 7 Schematic diagram of the hardware structure of the electronic device of the embodiment of the present application. Figure 7 As shown, the electronic device 80 includes:

[0181] The first communication interface 81 is capable of exchanging information with other devices (such as the second client);

[0182] The processor 82 is connected to the first communication interface 81 to implement information interaction with other devices (such as the second client) and is used to execute the file testing method on the electronic device side provided above when running a computer program, and the computer program is stored in the first memory 83.

[0183] Specifically, the processor 82 is used to obtain a file repository for storing a preset test file in response to a test instruction for a target file attribute, wherein the test instruction carries the target file attribute;

[0184] The first communication interface 81 is used to query the target test file matching the target file attribute from the preset test files in the file warehouse based on the target file attribute to obtain a query result;

[0185] The processor 82 is further configured to, in response to the query result indicating that there is a target test file matching the target file attribute in the file repository, execute a test task for the target file attribute based on the target test file to obtain a test result.

[0186] In one embodiment, the first communication interface 81 is also used to use the server in the processor 82 to match each of the index entries in the mapping relationship with the target file attributes respectively to obtain matching results for each of the index entries; when the matching result exists indicating that the index entry matches the target file attribute, the query result is determined as the first query result; when the matching result does not exist indicating that the index entry matches the target file attribute, the query result is determined as the second query result; wherein the first query result is used to indicate that there is a target test file matching the target file attribute in the file warehouse, and the second query result is used to indicate that there is no target test file matching the target file attribute in the file warehouse.

[0187] In one embodiment, the first communication interface 81 is specifically used for:

[0188] The following processing is performed for each of the index entries:

[0189] Comparing each of the sub-file attributes in the index entry with the corresponding target sub-file attributes in the target file attributes to obtain a comparison result of each of the sub-file attributes;

[0190] When the comparison result indicates that the sub-file attribute is the same as the target sub-file attribute corresponding to the target file attribute, determining the matching result of the index entry as a match between the index entry and the target file attribute;

[0191] When there is no comparison result indicating that the sub-file attribute is the same as the corresponding target sub-file attribute in the target file attribute, the matching result of the index entry is determined as that the index entry does not match the target file attribute.

[0192] In one embodiment, the processor 82 is further configured to:

[0193] In response to the query result indicating that there is a target test file matching the target file attribute in the file repository, obtaining comparison information of the attributes of each sub-file in the target test file;

[0194] The comparison information is used to indicate whether each of the sub-file attributes of the target test file is the same as the corresponding target sub-file attribute in the target file attribute;

[0195] Based on the comparison information and the target test file, a test task for the target file attribute is executed to obtain the test result.

[0196] In one embodiment, the processor 82 is further configured to:

[0197] In response to the comparison information indicating that each of the sub-file attributes of the target test file is the same as the corresponding target sub-file attribute in the target file attribute, based on the target test file, executing a test task for the target file attribute to obtain the test result;

[0198] In response to the comparison information indicating that some of the sub-file attributes of the target test file are different from the corresponding target sub-file attributes in the target file attributes, determining the different sub-file attributes as sub-file attributes to be adjusted;

[0199] Adjusting the attributes of each sub-file to be adjusted in the target test file to the corresponding target sub-file attributes to obtain a reference test file;

[0200] Based on the reference test file, a test task for the target file attribute is executed to obtain the test result.

[0201] In one embodiment, the processor 82 is further configured to:

[0202] In response to the query result indicating that there is no target test file matching the target file attribute in the file repository, creating an updated test file matching the target file attribute;

[0203] Based on the updated test file, a test task for the target file attribute is executed to obtain the test result.

[0204] In one embodiment, the processor 82 is further configured to:

[0205] Extracting features of the attributes of each target sub-file to obtain attribute features of the attributes of each target sub-file;

[0206] The file prediction model is called to perform file prediction on the target file attributes based on the attribute characteristics of each target sub-file attribute to obtain the updated test file.

[0207] In one embodiment, the processor 82 is further configured to:

[0208] Based on the update test file, the file repository is updated to obtain an updated file repository.

[0209] In one embodiment, the processor 82 is further configured to:

[0210] Extracting features of the file attributes of each of the preset test files in the file repository to obtain file attribute features of each of the preset test files;

[0211] Calling the file prediction model, based on the file attribute characteristics of each of the preset test files, recommending and evaluating each of the preset test files in the file warehouse, and obtaining an evaluation score for each of the preset test files;

[0212] Determine the preset test file with the largest evaluation score in the file warehouse as the recommended test file in the file warehouse;

[0213] Based on the target test file and the recommended test file, a test task for the target file attribute is executed to obtain the test result.

[0214] In one embodiment, the processor 82 is further configured to:

[0215] Acquire an initial file warehouse, wherein the number of the preset test files in the initial file warehouse is less than the number of the preset test files in the file warehouse;

[0216] Calling a file prediction model to predict the updated test file in the initial file warehouse based on each of the preset test files in the initial file warehouse to obtain a predicted test file;

[0217] The predicted test file is added to the initial file warehouse to obtain the file warehouse.

[0218] It should be noted that the specific processing process of the first communication interface 81 and the processor 82 can be understood by referring to the file testing method on the electronic device side.

[0219] Of course, in actual application, the various components in the electronic device 80 are coupled together through the first bus system 84. It is understandable that the first bus system 84 is used to realize the connection and communication between these components. In addition to the data bus, the first bus system 84 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 7 In the figure, various buses are labeled as a first bus system 84 .

[0220] The first memory 83 in the embodiment of the present application is used to store various types of data to support the operation of the electronic device 80. Examples of such data include: any computer program used to operate on the electronic device 80.

[0221] The file testing method on the electronic device side disclosed in the above embodiment of the present application can be applied to the processor 82, or implemented by the processor 82. The processor 82 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the file testing method on the electronic device side can be completed by the hardware integrated logic circuit or software instructions in the processor 82. The above-mentioned processor 82 may be a general processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 82 can implement or execute the file testing methods, steps and logic block diagrams on the electronic device side disclosed in the embodiment of the present application. A general processor may be a microprocessor or any conventional processor, etc. In combination with the steps of the file testing method on the electronic device side disclosed in the embodiment of the present application, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in the first memory 83. The processor 82 reads the information in the first memory 83 and completes the steps of the file testing method on the electronic device side in combination with its hardware.

[0222] In an exemplary embodiment, the electronic device 80 can be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD), field programmable gate array (FPGA), general processor, controller, microcontroller (MCU), microprocessor, or other electronic components to execute the file testing method on the aforementioned electronic device side.

[0223] It can be understood that the memory (including the first memory 83) of the embodiment of the present application can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM, SyncLink Dynamic Random Access Memory), and direct RAMbus random access memory (DRRAM, Direct Rambus Random Access Memory).The memories (including the first memory 83) described in the embodiments of the present application are intended to include but are not limited to these and any other suitable types of memories.

[0224] In an exemplary embodiment, the present application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, for example, including a first memory 83 storing a computer program, and the above-mentioned computer program can be executed by a processor 82 in an electronic device 80 to complete the steps of the file testing method on the electronic device side described in the above-mentioned embodiment of the present application. Among them, the computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, FlashMemory, magnetic surface storage, optical disk, or CD-ROM.

[0225] It should be noted that: "first", "second", "third", etc. are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0226] In addition, the technical solutions described in the embodiments of the present application can be combined arbitrarily without conflict.

[0227] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A file testing method, characterized in that: The method comprises: In response to a test instruction for a target file attribute, obtaining a file repository for storing a preset test file, wherein the test instruction carries the target file attribute; Based on the target file attribute, querying the preset test files in the file warehouse for a target test file that matches the target file attribute to obtain a query result; In response to the query result indicating that there is a target test file matching the target file attribute in the file repository, a test task for the target file attribute is executed based on the target test file to obtain a test result.

2. The method according to claim 1, characterized in that The file repository includes a mapping relationship for recording file attributes of the prediction test file, wherein the mapping relationship includes index entries corresponding to the preset test files one by one; The step of searching, based on the target file attribute, the preset test files in the data warehouse for a target test file that matches the target file attribute, and obtaining a query result includes: Matching each of the index entries in the mapping relationship with the target file attribute to obtain a matching result for each of the index entries; When the matching result indicates that the index entry matches the target file attribute, determining the query result as the first query result; When there is no matching result indicating that the index entry matches the target file attribute, determining the query result as a second query result; Among them, the first query result is used to indicate that there is a target test file matching the target file attribute in the file warehouse, and the second query result is used to indicate that there is no target test file matching the target file attribute in the file warehouse.

3. The method according to claim 2, characterized in that The index entry records the file attributes of the corresponding preset test file, the file attributes of the preset test file include multiple sub-file attributes, and the target file attributes include target sub-file attributes corresponding to the sub-file attributes one by one; The step of matching each of the index entries in the mapping relationship with the target file attribute to obtain a matching result of each of the index entries includes: The following processing is performed for each of the index entries: Comparing each of the sub-file attributes in the index entry with the corresponding target sub-file attributes in the target file attributes to obtain a comparison result of each of the sub-file attributes; When the comparison result indicates that the sub-file attribute is the same as the target sub-file attribute corresponding to the target file attribute, determining the matching result of the index entry as a match between the index entry and the target file attribute; When there is no comparison result indicating that the sub-file attribute is the same as the corresponding target sub-file attribute in the target file attribute, the matching result of the index entry is determined as that the index entry does not match the target file attribute.

4. The method according to claim 1, characterized in that The file attributes of the preset test file include a plurality of sub-file attributes, and the target file attributes include target sub-file attributes corresponding one-to-one to the sub-file attributes; In response to the query result indicating that there is a target test file matching the target file attribute in the file repository, based on the target test file, executing a test task for the target file attribute to obtain a test result, including: In response to the query result indicating that there is a target test file matching the target file attribute in the file repository, obtaining comparison information of the attributes of each sub-file in the target test file; The comparison information is used to indicate whether each of the sub-file attributes of the target test file is the same as the corresponding target sub-file attribute in the target file attribute; Based on the comparison information and the target test file, a test task for the target file attribute is executed to obtain the test result.

5. The method according to claim 4, characterized in that The performing of the test task for the target file attribute based on the comparison information and the target test file to obtain the test result includes: In response to the comparison information indicating that each of the sub-file attributes of the target test file is the same as the corresponding target sub-file attribute in the target file attribute, based on the target test file, executing a test task for the target file attribute to obtain the test result; In response to the comparison information indicating that some of the sub-file attributes of the target test file are different from the corresponding target sub-file attributes in the target file attributes, determining the different sub-file attributes as sub-file attributes to be adjusted; Adjusting the attributes of each sub-file to be adjusted in the target test file to the corresponding target sub-file attributes to obtain a reference test file; Based on the reference test file, a test task for the target file attribute is executed to obtain the test result.

6. The method according to claim 1, characterized in that After the target file attribute is searched for a target test file matching the target file attribute from the preset test files in the file repository based on the target file attribute, and a query result is obtained, the method further includes: In response to the query result indicating that there is no target test file matching the target file attribute in the file repository, creating an updated test file matching the target file attribute; Based on the updated test file, a test task for the target file attribute is executed to obtain the test result.

7. The method according to claim 6, characterized in that The target file attribute includes a plurality of target sub-file attributes, and the step of creating an update test file matching the target file attribute includes: Extracting features of the attributes of each target sub-file to obtain attribute features of the attributes of each target sub-file; The file prediction model is called to perform file prediction on the target file attributes based on the attribute characteristics of each target sub-file attribute to obtain the updated test file.

8. The method according to claim 6, characterized in that After creating the update test file matching the target file attribute, the method further includes: Based on the update test file, the file repository is updated to obtain an updated file repository.

9. The method according to claim 1, characterized in that: The step of executing a test task for the target file attribute based on the target test file to obtain a test result includes: Extracting features of the file attributes of each of the preset test files in the file repository to obtain file attribute features of each of the preset test files; Calling the file prediction model, based on the file attribute characteristics of each of the preset test files, recommending and evaluating each of the preset test files in the file warehouse, and obtaining an evaluation score for each of the preset test files; Determine the preset test file with the largest evaluation score in the file warehouse as the recommended test file in the file warehouse; Based on the target test file and the recommended test file, a test task for the target file attribute is executed to obtain the test result.

10. The method according to claim 1, characterized in that Before obtaining the file repository for storing the preset test file, the method further includes: Acquire an initial file warehouse, wherein the number of the preset test files in the initial file warehouse is less than the number of the preset test files in the file warehouse; Calling a file prediction model to predict the updated test file in the initial file warehouse based on each of the preset test files in the initial file warehouse to obtain a predicted test file; The predicted test file is added to the initial file warehouse to obtain the file warehouse.

11. A file testing device, characterized in that: include: An acquisition module, configured to acquire a file repository for storing a preset test file in response to a test instruction for a target file attribute, wherein the test instruction carries the target file attribute; A query module, configured to query a target test file matching the target file attribute from the preset test files in the file repository based on the target file attribute, and obtain a query result; The execution module is used for executing a test task for the target file attribute based on the target test file in response to the query result indicating that there is a target test file matching the target file attribute in the file repository to obtain a test result.

12. An electronic device, characterized in that: include: a processor and a first memory for storing a computer program executable on said processor; Wherein, when the processor is used to run the computer program, it executes the steps of the method described in any one of claims 1 to 10.

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

Images