Application security test method and device and electronic equipment
By using a large language model developed through machine learning to extract features from application data and match requirement tags, the security testing process is automated, solving the problem of low testing efficiency in existing technologies and achieving efficient and accurate application security testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-25
- Publication Date
- 2026-04-17
AI Technical Summary
In existing technologies, testers need to design security test cases for different iterations of the application, which leads to low testing efficiency, repetitive work, and security risks.
The system employs a large language model based on machine learning to extract features from the application data of the target application, identify security testing requirements, intelligently match test cases based on requirement tags, and automate and customize the security testing process.
It improves the accuracy and efficiency of application security testing, reduces the workload of testers, avoids blind spots caused by the limitations of human experience, and enhances the security protection capabilities of applications.
Smart Images

Figure CN121880190A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of artificial intelligence or other related technical fields, and more specifically, to an application security testing method, apparatus, and electronic device. Background Technology
[0002] With the development of information technology, the widespread use of applications has facilitated people's lives and work. However, this has also brought new challenges. The diversification and concealment of application security threats require application testers to have keen risk perception capabilities and professional testing skills to ensure the safe operation of applications in various environments.
[0003] In the context of applications requiring frequent iterations and upgrades, testers in existing technologies often need to design security test cases from scratch when faced with new versions of applications to adapt to changes in application functionality and potential security risks. This process not only consumes a lot of time and energy, but also results in duplication of work and omissions of security vulnerability test points due to the lack of effective use of past test data, leading to low testing efficiency.
[0004] There is currently no effective solution to the above problems. Summary of the Invention
[0005] This application provides an application security testing method, apparatus, and electronic device to at least solve the technical problem of low testing efficiency caused by the need for testers to design security test cases for different iterative versions of the application in the prior art.
[0006] According to one aspect of this application, an application security testing method is provided, comprising: extracting features from application data of a target application to obtain L application features of the target application, where L is a positive integer; determining requirement tags for the target application based on the L application features, where the requirement tags are used to characterize the security testing requirements of the target application; determining N test cases corresponding to the target application based on the requirement tags of the target application, where N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results; and performing security testing on the target application based on the N test cases.
[0007] Optionally, before feature extraction of the application data of the target application, the application security testing method further includes: collecting the raw data of the target application, wherein the raw data includes at least one of the following: application version, used to characterize the development cycle of the target application; scenario data, used to characterize the application scenarios involved in the target application; project data, used to characterize the source code of the development project to which the target application belongs; and cleaning the raw data to obtain the application data of the target application.
[0008] Optionally, the step of determining N test cases corresponding to the target application based on the requirement tags of the target application includes: obtaining the case tag of each preset case among the N test cases, wherein the case tag is used to characterize the test scenario type of the preset case, and the case tag is one of the following: privilege escalation, bypass, plaintext, replay, injection attack, cross-site scripting attack; obtaining the similarity between the requirement tags of the target application and the case tags of each preset case; filtering the preset cases among the N test cases whose similarity is greater than or equal to the preset similarity to obtain P preset cases, wherein P is a positive integer greater than or equal to N; and determining the N test cases corresponding to the target application based on the P preset cases.
[0009] Optionally, the step of determining N test cases corresponding to the target application based on P preset cases includes: obtaining historical test cases and development requirement documents corresponding to the target application, wherein the historical test cases are the test plans used by the target application in the previous development cycle; determining a first case score for each preset case among the P preset cases based on the historical test cases, wherein the first case score is used to characterize the similarity between the test scenarios corresponding to the preset cases and the historical test cases; determining a second case score for each preset case among the P preset cases based on the development requirement documents, wherein the second case score is used to characterize the relevance between the test scenarios of the preset cases and the development requirement documents; performing a weighted sum of the first case score and the second case score for each preset case to obtain a case score for each preset case; and selecting preset cases among the P preset cases whose case scores are greater than or equal to the preset scores as test cases.
[0010] Optionally, the steps for performing security testing on the target application based on N test cases include: obtaining the waiting time of the i-th test case among the N test cases, where the waiting time is the time between the generation time of the i-th test case and the current time; if the waiting time of the i-th test case is greater than or equal to a preset time, obtaining the test tool corresponding to the i-th test case, where the test tool is used to execute the test steps of the i-th test case; and sending the test tool to the testers of the target application.
[0011] Optionally, after conducting security testing on the target application based on N test cases, the application security testing method further includes: obtaining a correlation score between online issues and each of the N test cases, wherein the correlation score is used to characterize the correlation between the online issues and the execution steps of the test cases, and the online issues are application defects reported by users after the target application is launched; if the maximum value among the N correlation scores corresponding to the N test cases is greater than or equal to a preset correlation score, the test case corresponding to the maximum value is taken as a common case; the common case and the specification document are sent to the designer of the common case, wherein the specification document is used to record the design rules of the preset case; if the maximum value among the N correlation scores is less than the preset correlation score, supplementary cases are generated based on the online issues, wherein the supplementary cases at least include the steps to reproduce the online issues.
[0012] Optionally, after designating the test case corresponding to the maximum value as a common case, the application security testing method further includes: obtaining historical test records of the common case, wherein the historical test records are used to record the test results obtained from the most recent execution of the common case; if the historical test records indicate that the common case test was successful, sending the test tool of the common case to the testers of the target application; if the historical test records indicate that the common case test failed, and there is no issue ticket corresponding to the common case in the ticket system, sending the specification document to the testers of the target application.
[0013] Optionally, based on the requirement tags of the target application, N test cases corresponding to the target application are determined through the target model. The target model is a large language model trained on historical requirement tags and historical test cases corresponding to M applications, where M is a positive integer. The training steps of the target model include: dividing the historical requirement tags and historical test cases corresponding to the M applications to obtain a test set and a training set; iteratively training the initial model using the historical requirement tags and historical test cases in the training set to obtain a training model; testing the training model using the historical requirement tags and historical test cases in the test set, and iteratively updating the training model based on the test results; and using the last updated training model as the target model.
[0014] According to another aspect of this application, an application security testing apparatus is also provided, comprising: a feature extraction unit, configured to extract features from application data of a target application to obtain L application features of the target application, wherein L is a positive integer; a first determination unit, configured to determine requirement tags of the target application based on the L application features, wherein the requirement tags are used to characterize the security testing requirements of the target application; a second determination unit, configured to determine N test cases corresponding to the target application based on the requirement tags of the target application, wherein N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results; and a security testing unit, configured to perform security testing on the target application based on the N test cases.
[0015] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein, when the computer program is running, it controls the computer program product to execute any of the above-mentioned application security testing methods.
[0016] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the application security testing method described above.
[0017] In this application, firstly, feature extraction is performed on the application data of the target application to obtain L application features of the target application, where L is a positive integer; then, based on the L application features, the application determines the requirement tags of the target application, where the requirement tags are used to characterize the security testing requirements of the target application; based on the requirement tags of the target application, N test cases corresponding to the target application are determined, where N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results; then, the application performs security testing on the target application based on the N test cases.
[0018] As can be seen from the above, this application uses machine learning to extract features from the application data of the target application through a pre-trained large language model, thereby achieving the goal of accurately identifying application security testing requirements (i.e., requirement tags). This enables the technical effect of intelligently matching test cases based on requirement tags, and solves the technical problem of low testing efficiency caused by testers having to design security test cases for different iterations of the application in the prior art.
[0019] In other words, this application automatically analyzes and extracts the key features (i.e., L application features) of the target application through a pre-trained large language model. Then, based on the key features, it intelligently determines the security testing requirement tags corresponding to the application. Subsequently, based on the requirement tags corresponding to the application, this application can quickly select the most relevant test cases (i.e., N test cases). Each test case contains the necessary test steps and expected results, which can be directly applied to the security testing of the target application. This process reduces the workload of testers, avoids test blind spots caused by the limitations of human experience, thereby improving the accuracy of application security testing and enhancing the application's security protection capabilities. Attached Figure Description
[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0021] Figure 1 This is a hardware structure block diagram of an optional computer terminal (or mobile device) for implementing an application security testing method according to an embodiment of this application;
[0022] Figure 2 This is a flowchart of an optional application security testing method according to an embodiment of this application;
[0023] Figure 3 This is a flowchart of an optional tester training method for online problem feedback according to an embodiment of this application;
[0024] Figure 4 This is a schematic diagram of an optional application security testing device according to an embodiment of this application;
[0025] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0028] It should also be noted that all information (including but not limited to information used for display and analysis) and data (including but not limited to collected application data) involved in this application are information and data authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining the relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving the consent information from the aforementioned user or organization.
[0029] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken. This application does not violate public order and good morals. In addition, this application provides a corresponding operation entry point for users to choose to agree to or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.
[0030] The present invention will now be described in detail with reference to various embodiments.
[0031] Example 1
[0032] According to an embodiment of this application, an embodiment of an application security testing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0033] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 This is a hardware structure block diagram of an optional computer terminal (or mobile device) for implementing an application security testing method according to an embodiment of this application. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0034] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).
[0035] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the application security testing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the application security testing method described above. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0036] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0037] The display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).
[0038] Under the aforementioned operating environment, this application provides an application security testing system (hereinafter referred to as the testing system) for executing the application security testing method described in this application. Figure 2 This is a flowchart of an optional application security testing method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:
[0039] Step S201: Extract features from the application data of the target application to obtain L application features of the target application, where L is a positive integer.
[0040] Optionally, the application data may include at least scenario data, project data, and application version obtained after data cleaning.
[0041] Optionally, the testing system extracts features from application data to obtain the application features corresponding to the target application. Compared with the method of testers manually analyzing application data, it can more objectively and comprehensively understand the security testing requirements of the application, reduce the interference of human factors, and improve the efficiency and accuracy of security testing requirements analysis in the early stage of testing.
[0042] Step S202: Based on L application features, determine the requirement tags of the target application, where the requirement tags are used to characterize the security testing requirements of the target application.
[0043] Optionally, the requirement tag is used to describe the security testing requirements of the target application. The requirement tag is used to characterize the potential threat information faced by the target application and the specific business functions that need to be tested.
[0044] Optionally, the determination of requirement tags enables the testing system to clearly identify which application security test points require special attention, thereby avoiding blind testing and improving the relevance and effectiveness of the subsequently determined test cases.
[0045] Step S203: Based on the requirement tags of the target application, determine N test cases corresponding to the target application, where N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results.
[0046] Optionally, the testing system can recommend N test cases suitable for the target application to testers by calling the target model and based on the requirement tags of the target application. The target model is a large language model trained based on the historical requirement tags and historical test cases corresponding to M applications.
[0047] Optionally, a test case refers to a specific test case designed to verify whether the target application meets security testing requirements. A test case includes at least a case label, test steps, and expected results. The case label is used to characterize the type of application security test points that the test case needs to test.
[0048] Optionally, the processing system can intelligently match the requirement tags with the test case tags to automatically filter out a series of test cases, avoiding the need for testers to manually design security test points for the target application and improving the testing efficiency of the target application.
[0049] Step S204: Perform security testing on the target application based on N test cases.
[0050] Optionally, after completing the above-mentioned test preparation work, the processing system can call the automated test programs corresponding to N test cases through interface calls, thereby realizing security testing of the target application. The execution results of the test cases not only verify the security of the application, but also provide the testing team with an evaluation basis for the preset cases, helping the testing team to modify the preset cases based on the test results, so as to improve the depth and breadth of security testing, and thus improve the security protection level of the target application.
[0051] In summary, the processing system achieves automation and customization of application security testing through steps such as feature extraction from a large model, intelligent matching of requirement tags, and test case execution, effectively improving the efficiency and accuracy of application security testing.
[0052] As can be seen from the above, this application uses machine learning to extract features from the application data of the target application through a pre-trained large language model, thereby achieving the goal of accurately identifying application security testing requirements (i.e., requirement tags). This enables the technical effect of intelligently matching test cases based on requirement tags, and solves the technical problem of low testing efficiency caused by testers having to design security test cases for different iterations of the application in the prior art.
[0053] In other words, this application automatically analyzes and extracts the key features (i.e., L application features) of the target application through a pre-trained large language model. Then, based on the key features, it intelligently determines the security testing requirement tags corresponding to the application. Subsequently, based on the requirement tags corresponding to the application, this application can quickly select the most relevant test cases (i.e., N test cases). Each test case contains the necessary test steps and expected results, which can be directly applied to the security testing of the target application. This process reduces the workload of testers, avoids test blind spots caused by the limitations of human experience, thereby improving the accuracy of application security testing and enhancing the application's security protection capabilities.
[0054] In one optional embodiment, before performing feature extraction on the application data of the target application, the testing system first collects the raw data of the target application, and then the testing system cleans the raw data to obtain the application data of the target application.
[0055] Optionally, the raw data includes at least one of the following:
[0056] Application version, used to characterize the development cycle of the target application;
[0057] Scene data is used to characterize the application scenarios involved in the target application;
[0058] Project data is used to characterize the source code of the development project to which the target application belongs.
[0059] Optionally, the application version is used to identify which development cycle or stage the application is in, which helps technical personnel quickly locate the time window and version range for security testing.
[0060] Optionally, scenario data is used to describe various scenarios that the application may encounter in actual deployment and use, including but not limited to user interaction, data processing, and network communication.
[0061] Optionally, project data provides the testing system with an intuitive view of the internal structure and development logic of the application's corresponding development project, which can intuitively reveal potential security vulnerabilities and hidden dangers at the code level.
[0062] Optionally, the testing system collects application version, scenario data, and project data of the target application to obtain a complete application profile, thereby guiding the target model to make more accurate requirements analysis and test planning based on the application data.
[0063] Optionally, by cleaning the raw data, the testing system can effectively remove noise, redundant information, and blank values from the raw data, thereby improving the data quality of the dataset for subsequent analysis and processing by the target model. This ensures the accuracy and reliability of subsequent steps. Through data cleaning, the application data is not only cleaner but also easier for large models to understand and process, which is conducive to extracting more accurate application features closely related to security testing, thus providing solid data support for security testing.
[0064] In one optional embodiment, in order to determine N test cases corresponding to the target application, the testing system first obtains the case label of each preset case among the N test cases. Then, the testing system obtains the similarity between the requirement label of the target application and the case label of each preset case. Then, the testing system filters the preset cases among the N test cases whose similarity is greater than or equal to the preset similarity to obtain P preset cases, where P is a positive integer greater than or equal to N. Subsequently, the testing system determines the N test cases corresponding to the target application based on the P preset cases.
[0065] Optionally, case labels are used to characterize the test scenario type of the preset cases, and case labels are one of the following:
[0066] Unauthorized access, bypass, plaintext, replay, injection attack, cross-site scripting attack.
[0067] Optionally, the use of case tags facilitates the processing system to quickly find and identify test cases applicable to specific applications or scenarios. By searching the case tags of preset cases, the testing system can intuitively understand the testing purpose and focus of each preset case.
[0068] Optionally, the processing system can quantitatively evaluate the applicability of each test case to the target application testing requirements by calculating the similarity between the requirement label and the case label of each preset case. This process avoids the uncertainty and bias of human subjective judgment, ensuring that the selection of test cases is more accurate and scientific, thereby enhancing the comprehensiveness and effectiveness of the test.
[0069] Optionally, the processing system refines the test case set by filtering preset cases with a similarity greater than or equal to a preset similarity among the N test cases. This ensures that the execution of each filtered test case can directly address the security requirements of the target application, avoiding the waste of resources caused by invalid testing.
[0070] In summary, the processing system achieves intelligent screening and matching of test cases through the use of case tags and similarity calculations, ensuring a high degree of professionalism and automation in security testing, effectively improving testing efficiency and accuracy, and reducing the resource costs of test execution.
[0071] In one optional embodiment, after obtaining P preset cases, the testing system first acquires the historical test cases and development requirement document corresponding to the target application. The historical test cases are the test plans used by the target application in the previous development cycle. Then, based on the historical test cases, the testing system determines a first case score for each of the P preset cases. The first case score is used to characterize the similarity between the test scenarios corresponding to the preset cases and the historical test cases. Then, based on the development requirement document, the testing system determines a second case score for each of the P preset cases. The second case score is used to characterize the relevance between the test scenarios of the preset cases and the development requirement document. Subsequently, the testing system performs a weighted sum of the first case score and the second case score for each preset case to obtain a case score for each preset case. Finally, the testing system uses the preset cases whose case scores are greater than or equal to the preset scores as test cases.
[0072] Optionally, the testing system can acquire multiple historical test cases. Based on the maximum similarity among the multiple historical test cases and multiple test scenarios corresponding to the preset cases, the testing system determines the first case score for each preset case.
[0073] Optionally, a development requirements document is used to describe the functional and performance requirements that the target application should achieve during this development cycle, including new or modified functionalities, performance indicators, and preset security requirements.
[0074] Optionally, by acquiring historical test cases and development requirement documents, the processing system can gain a comprehensive understanding of the target application's past testing experience and the application security requirements of the current version. This provides accurate basic information for subsequent case scoring and selection. Historical test cases help the processing system identify preset cases with comprehensive scenario coverage during historical testing, while development requirement documents ensure that test cases are closely related to the new version's functionalities and security objectives, avoiding blind and redundant testing and improving the relevance of testing.
[0075] Optionally, the first case score is a quantitative assessment of the similarity between the test scenarios corresponding to the preset cases and the historical test cases. The higher the score, the more the preset cases match the test points in the historical test cases, and the more they can cover the test points in the past test history. The calculation of the first case score enables the test system to quickly identify which preset cases are more critical for the test scenario coverage of the target application, thereby improving the completeness of the scenario coverage of security testing.
[0076] Optionally, the second case score is used to evaluate the matching degree between the preset cases and the functional and security requirements in the latest development requirements document. High-scoring cases can effectively test new features and changes during the development cycle, ensuring that security testing is synchronized with the development progress. The use of the second case score ensures that test cases can keep up with the latest changes in the target application, especially for new features or modified parts, which helps to discover and fix security vulnerabilities that may be introduced due to new development activities in a timely manner, ensuring the security and stability of the application in each development version.
[0077] Optionally, the processing system comprehensively considers the historical performance and adaptability to new requirements of the preset cases by weighted summing of the first and second case scores for each preset case. This ensures that the final selected test cases can both compensate for the deficiencies of historical tests and effectively cover the security verification of new functions, thus optimizing the selection of test cases and improving the scientificity and rationality of the overall testing process. Subsequently, by using the preset scores as the screening criteria, it can be ensured that the final adopted test cases can directly target the security weaknesses and new development requirements of the target application, ensuring test coverage and avoiding the waste of resources on inefficient or redundant tests, thereby improving the test effectiveness of security testing.
[0078] In one optional embodiment, during the security testing of the target application based on N test cases, the testing system first obtains the waiting time of the i-th test case among the N test cases, where the waiting time is the time between the generation time of the i-th test case and the current time. Then, if the waiting time of the i-th test case is greater than or equal to a preset time, the testing system obtains the testing tool corresponding to the i-th test case, where the testing tool is used to execute the test steps of the i-th test case. After that, the testing system sends the testing tool to the testers of the target application.
[0079] Optionally, the waiting time specifically refers to the length of time elapsed from the moment a certain test case (here, the i-th test case) is generated until the current moment, used to determine whether the test case may require additional attention or resource support due to long periods of inactivity.
[0080] Optionally, by tracking the waiting time of test cases, the testing system can identify those cases that may be overlooked or delayed for various reasons. This helps the testing team to allocate testing resources (such as testing tools) in a timely manner, avoiding long waiting times and omissions in testing, thereby improving testing efficiency.
[0081] Optionally, testing tools refer to specific software / hardware execution tools set up for the test steps involved in each test case, including but not limited to automated testing tools, penetration testing tools, and code review aids.
[0082] Optionally, when the testing system determines that a test case requires additional tool support, it will match appropriate tools to improve the feasibility and efficiency of the test. This will effectively provide targeted support for test cases that have not been executed for a long time. This mechanism not only solves the problem of test case execution delays, but also accelerates the testing process by providing appropriate tools, ensuring that even the most complex or easily overlooked test scenarios can be properly handled, thereby improving the comprehensiveness and professionalism of the test.
[0083] Optionally, the testing system simplifies the tool distribution process by sending testing tools to testers of the target application, reducing communication costs and time to obtain testing tools, and improving work efficiency in the test preparation phase.
[0084] In summary, by monitoring the waiting time of test cases, the testing system intelligently selects and provides necessary testing tools to testers, optimizes the allocation of testing resources, and ensures the timeliness of security testing. This mechanism not only accelerates the testing process but also improves the automation level of the testing process through the use of testing tools, thereby reducing the rate of human error during the testing process.
[0085] In one optional embodiment, after performing security testing on the target application based on N test cases, the testing system first obtains the correlation score between online issues and each of the N test cases. The correlation score is used to characterize the correlation between the online issues and the execution steps of the test cases. The online issues are application defects reported by users after the target application is launched.
[0086] Optionally, if the maximum value among the N associated scores corresponding to the N test cases is greater than or equal to the preset associated score, the test system will use the test case corresponding to the maximum value as a common case. Then, the test system will send the common case and the specification document to the designer of the common case. The specification document is used to record the design rules of the preset case.
[0087] Optionally, if the maximum value among the N associated scores is less than the preset associated score, the test system generates supplementary cases based on the online problem, wherein the supplementary cases include at least the steps to reproduce the online problem.
[0088] Optionally, online issues refer to functional defects or security problems that occur in the real world after the target application has been officially launched, as reported by users or detected by the system.
[0089] Optionally, correlation scoring measures the correlation between online issues and the execution steps of test cases. By calculating correlation scores, the testing system can quantitatively evaluate whether the designed test cases can effectively test the online issues. This mechanism provides an objective basis for the optimization of subsequent preset cases and helps to improve the quality of test cases.
[0090] Optionally, public cases are considered test cases that are generally applicable to most applications or scenarios. They have strong universality and representativeness and can serve as templates for subsequent case design or repair strategies.
[0091] Optionally, the testing system selects the highest-scoring case with the associated score reaching a preset value as a common case and sends the common case and specification documents to the designers of the common case. This enables the case designers to receive timely and direct feedback on how to improve and expand the common case, helping them to update the case based on the existing test cases, thereby reducing testing blind spots caused by design defects.
[0092] Optionally, if the maximum value among the N correlation scores is less than the preset correlation score, it indicates that there are no test cases designed for the online problem in the testing system, which means that the online problem is a testing blind spot. In this case, the testing system fills the gap in the existing test case library in a timely manner by designing new test cases (i.e., supplementary cases) to ensure that future tests can better cover such problems.
[0093] Optionally, during the generation of supplementary cases, the testing system promptly pushes the specification documents to the case designers, thereby helping them quickly understand the case design specifications and improving the design efficiency of supplementary cases.
[0094] Optionally, when existing test cases are insufficient to prevent online issues, generating supplementary test cases becomes necessary. The creation of supplementary test cases can not only respond immediately to current online issues, but also provide new test points for the prevention of similar issues in the future, which helps to gradually improve the test case library and improve the overall effectiveness of security testing.
[0095] In one optional embodiment, after designating the test case corresponding to the maximum value as a common case, the testing system first obtains the historical test records of the common case. The historical test records are used to record the test results obtained from the most recent execution of the common case. Then, if the historical test records indicate that the common case test was successful, the testing system sends the test tool of the common case to the testers of the target application. If the historical test records indicate that the common case test failed and there is no issue ticket corresponding to the common case in the ticket system, the testing system sends the specification document to the testers of the target application.
[0096] Optionally, historical test records for common cases are used to record the test results of the last time a specific common case was executed for the application. By accessing historical test records, the testing system can quickly understand the past performance of common cases on the target application or other similar applications, providing a direct basis for subsequent decisions. The testing system's feedback based on actual historical test data (historical test records for common cases) ensures that the delivery of testing tools or specification documents is more accurate and effective, directly responding to successes or failures in the test results.
[0097] Optionally, if historical test records indicate that a common case test was successful, the testing system sends the common case test tool to the testers of the target application. The testers can then execute the test steps in the common case based on the test tool, thereby enabling rapid reproduction of online issues and improving the efficiency of defect localization and defect repair speed.
[0098] Optionally, a work order system refers to a system used to track and manage issue reports, repair progress, and closure status, ensuring that every application defect discovered during each test is recorded, tracked, and resolved.
[0099] Optionally, if historical test records indicate that a common case test failed and there is no corresponding issue ticket for the common case in the ticket system, it proves that the execution steps of the common case can detect the online problem in a timely manner. However, due to the negligence of the testers or the defects of the ticket system, the application defects found by the common case may not be corrected in a timely manner.
[0100] Optionally, if historical test records indicate that a common case test failed, but the application defect was not recorded, the test system will send a specification document to the testers of the target application. This can promote testers' in-depth understanding of the failed cases and effective response. This mechanism provides targeted guidance for testers to learn how to avoid missing test issues, thereby improving the testers' testing skills and professional competence.
[0101] In one optional embodiment, the testing system determines N test cases corresponding to the target application based on the requirement tags of the target application using the target model. The target model is a large language model trained on historical requirement tags and historical test cases corresponding to M applications, where M is a positive integer. The training steps of the target model include: dividing the historical requirement tags and historical test cases corresponding to the M applications to obtain a test set and a training set; iteratively training the initial model using the historical requirement tags and historical test cases in the training set to obtain a training model; testing the training model using the historical requirement tags and historical test cases in the test set, and iteratively updating the training model based on the test results; and using the last updated training model as the target model.
[0102] Optionally, the testing system can ensure the scientific nature of model training and the fairness of testing by dividing the historical requirement tags and historical test cases corresponding to M applications into a test set and a training set. The training set is used to allow the model to learn and summarize the patterns of security testing, while the test set is used to verify the accuracy and robustness of the model. This division avoids overfitting and enables the trained target model to maintain good performance on unseen new data.
[0103] Optionally, the testing system iteratively trains the initial model using historical requirement labels and historical test cases in the training set, enabling the initial model to gradually grasp the correspondence between historical requirement labels and historical test cases. As the number of training iterations increases, the model's detection results on the degree of matching between historical requirement labels and historical test cases become more and more accurate, so that the final trained model can more accurately identify and evaluate the test cases required by the target application.
[0104] Optionally, the testing system tests the trained model using historical requirement tags and historical test cases in the test set, and updates the trained model iteratively based on the test results. The model can adjust its own model parameters according to the test results, overcome possible case recommendation errors or deficiencies during the training process, and ensure that it can make more accurate guidance suggestions when facing test case recommendation requirements for new target applications. This process enhances the generalization ability of the trained target model, enabling it to remain efficient and reliable in constantly changing application environments.
[0105] In summary, the processing system constructs a high-precision, high-generalization target model through dataset partitioning, model training, model testing, evaluation, and optimization. The entire model generation process not only follows the basic principles of machine learning but also fully considers the test case recommendation needs in the field of security testing, thus providing technical support for personalized security test plan development.
[0106] In an optional embodiment, the testing system can also implement the following management functions:
[0107] (1) Personnel Management: Used for basic information of management personnel, including employee number, name, department, position, etc.
[0108] (2) Application Management: Used for unified information registration of applications, recording basic application information, application classification (e.g., web page, client, backend), and inter-application relationships (e.g., group, upstream, downstream).
[0109] (3) Scene Management: Used to manage application-dimensional scenes in a unified manner. Subsequent projects, cases, and issues need to be bound to the scene to form a profile of the application scene dimension. Examples of scenes include: registration, login, password retrieval, logout, customer information query, user information modification, etc.
[0110] (4) Project Management: Unify the management of project information in the application dimension, bind the corresponding version, establish the corresponding transformation requirement description, and bind the involved scenarios.
[0111] (5) Version Management: The development cycle of the application is managed in a unified manner. The application development supports the monthly version development mode, that is, 12 versions should be established in a year. Version binding is carried out in subsequent project management. Different versions will have their own development cycle start and end time information, and the bound projects need to be scheduled according to this.
[0112] (6) Security Classification Management: Security boundaries are established based on industry or business scope. The scope of all test cases and test issues is derived from security classification. The classification includes, but is not limited to: privilege escalation, bypass, plaintext, replay, injection attack, and cross-site scripting attack.
[0113] (7) Security Public Case Management: Unified management of security public cases at the scenario level. Each case should include information such as security classification, testing steps, and test result judgment criteria. It supports binding cases by tagging projects with security requirements, and also supports supplementing and binding public cases to projects for testing in subsequent stages.
[0114] (8) Case binding management: Cases do not support writing them separately. They are all bound to projects through preset cases. The binding process requires maintaining the project information and scenario information of the case.
[0115] (9) Security test review management: By conducting security test reviews on applications bound to versions, projects, and scenarios, it is possible to check whether the application involves security test requirements. If it does not involve security test requirements, the reason for not involving security test requirements should be filled in. If it does involve security test requirements, a preset case should be bound to the application.
[0116] (10) Management of common security issues: Common issues are part of common case management, that is, they appear as a form of test result judgment. Test result judgment supports descriptions of correct or incorrect results, that is, at least one judgment method or both are provided. If the judgment basis is an incorrect result, it is necessary to classify in detail into various types of errors and the corresponding security category and security category sub-category to which the error belongs; if the judgment basis is a correct result, it is necessary to supplement the project description of the problem in the problem reference process.
[0117] (11) Test issue reference management: Test issues do not support writing them separately. They all need to be bound to test cases through preset issues. For common issues that are judged to be correct, a detailed issue description needs to be added during the binding process.
[0118] (12) Test case management: Used to manage information such as the execution status, execution results, and executor of test cases.
[0119] (13) Test issue management: Used to manage information such as the status of test issues, security tags, cases associated with the issues, the person who raised the issue, and the person who handled the issue.
[0120] (14) Online issue management: Used to manage information such as the status, security label, issue description, person who raised the issue, and person who handled it of online issues.
[0121] (15) Training Management: Test personnel training includes document training and video training. Each training material has a corresponding training tag, such as application category, scenario category, security category, and tool category. Each training material can correspond to multiple tags.
[0122] In an optional embodiment, a method for training test personnel based on a large model is also provided, the method comprising the following steps:
[0123] (1) Large model usage: For the field of security testing, text and semantic similarity calculations are performed on training tags, specifications, system design, test cases and test questions, and a similarity threshold 'a' is set for recommendation of training, public cases and specification content in subsequent stages.
[0124] (2) Test review stage: Set the version range X, where X is a positive integer. Organize and summarize the cases that the test designer was supplemented in the review stage within the last X versions, and push the cases with high relevance through big data calculation and training materials to the corresponding person a period of time before the test review.
[0125] (3) Case execution phase: If a test case executor has a case that has not been executed for a long time, provide him with the method of using a highly relevant test tool calculated by the large model; if a case fails to be executed and no questions are raised, provide him with the security specifications that are highly relevant by the large model as a basis for raising questions;
[0126] (4) Problem identification phase: After an online problem occurs, the existing project modification content will be compared with the large model to locate the project that caused the problem, assign responsibility to the person in charge, and push the corresponding training content to them. Figure 3 This is a flowchart of an optional training method for testers addressing online issue feedback, according to an embodiment of this application. The process involves determining whether corresponding case designs exist, whether the cases have passed testing, and whether testing questions have been raised. Based on the test results, specific training content is provided to the relevant technical personnel, such as... Figure 3 As shown, the method includes:
[0127] First, based on the problem description of the online issue, locate the application to which the online issue belongs, and check whether the testing system has designed corresponding test cases for the application to which the online issue belongs. If no corresponding test cases are found, check whether other applications execute or have similar common cases. If corresponding common cases are found, push the security specification document and common cases to the test case designers of the target application. If no corresponding common cases are found, generate supplementary cases based on the online issue, and push the generated supplementary cases and security specification document to all employees.
[0128] Optionally, if a test case corresponding to the application to which the online issue belongs is found, check whether the test case has been executed successfully. If it has been executed successfully, push the corresponding test tool to the test execution personnel. If it has not been executed successfully, check whether the test personnel have raised any test issues for the test case. If no test issues have been submitted, push the security specification document to the test execution personnel.
[0129] As can be seen from the above, this application uses machine learning to extract features from the application data of the target application through a pre-trained large language model, thereby achieving the goal of accurately identifying application security testing requirements (i.e., requirement tags). This enables the technical effect of intelligently matching test cases based on requirement tags, and solves the technical problem of low testing efficiency caused by testers having to design security test cases for different iterations of the application in the prior art.
[0130] In other words, this application automatically analyzes and extracts the key features (i.e., L application features) of the target application through a pre-trained large language model. Then, based on the key features, it intelligently determines the security testing requirement tags corresponding to the application. Subsequently, based on the requirement tags corresponding to the application, this application can quickly select the most relevant test cases (i.e., N test cases). Each test case contains the necessary test steps and expected results, which can be directly applied to the security testing of the target application. This process reduces the workload of testers, avoids test blind spots caused by the limitations of human experience, thereby improving the accuracy of application security testing and enhancing the application's security protection capabilities.
[0131] Example 2
[0132] This application embodiment can also provide an application security testing device. It should be noted that the application security testing device of this application embodiment can be used to execute the application security testing method provided in this application embodiment. The application security testing device provided in this application embodiment is described below.
[0133] According to an embodiment of this application, an apparatus for implementing the above-described application security testing method is also provided. Figure 4 This is a schematic diagram of an optional application security testing device according to an embodiment of this application, such as... Figure 4 As shown, the device includes: a feature extraction unit 401, a first determination unit 402, a second determination unit 403, and a security testing unit 404.
[0134] Optionally, the feature extraction unit 401 is used to extract features from the application data of the target application to obtain L application features of the target application, where L is a positive integer; the first determining unit 402 is used to determine the requirement tags of the target application based on the L application features, where the requirement tags are used to characterize the security testing requirements of the target application; the second determining unit 403 is used to determine N test cases corresponding to the target application based on the requirement tags of the target application, where N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results; and the security test case 404 is used to perform security testing on the target application based on the N test cases.
[0135] As can be seen from the above, the application security testing device uses machine learning to extract features from the application data of the target application through a pre-trained large language model. This achieves the goal of accurately identifying application security testing requirements (i.e., requirement tags), thereby realizing the technical effect of intelligently matching test cases based on requirement tags. This solves the technical problem of low testing efficiency caused by testers having to design security test cases for different iterations of the application in the existing technology.
[0136] In other words, the application security testing device automatically analyzes and extracts the key features (i.e., L application features) of the target application through a pre-trained large language model. Then, based on the key features, it intelligently determines the corresponding security testing requirement tags for the application. Subsequently, based on the requirement tags corresponding to the application, the device can quickly select the most relevant test cases (i.e., N test cases). Each test case contains the necessary test steps and expected results, which can be directly applied to the security testing of the target application. This process reduces the workload of testers, avoids test blind spots caused by the limitations of human experience, thereby improving the accuracy of application security testing and enhancing the application's security protection capabilities.
[0137] In one optional embodiment, the application security testing apparatus further includes a raw data acquisition unit and a data cleaning unit.
[0138] Optionally, the raw data acquisition unit is used to acquire raw data of the target application, wherein the raw data includes at least one of the following: application version, used to characterize the development cycle of the target application; scenario data, used to characterize the application scenarios involved in the target application; project data, used to characterize the source code of the development project to which the target application belongs; and the data cleaning unit is used to clean the raw data to obtain the application data of the target application.
[0139] In one optional embodiment, the second determining unit 403 includes: a first obtaining subunit, a second obtaining subunit, a first filtering subunit, and a first determining subunit.
[0140] Optionally, the first acquisition subunit is used to acquire the case tag of each preset case in N test cases, wherein the case tag is used to characterize the test scenario type of the preset case, and the case tag is one of the following: privilege escalation, bypass, plaintext, replay, injection attack, cross-site scripting attack; the second acquisition subunit is used to acquire the similarity between the requirement tag of the target application and the case tag of each preset case; the first filtering subunit is used to filter the preset cases in the N test cases whose similarity is greater than or equal to the preset similarity to obtain P preset cases, wherein P is a positive integer greater than or equal to N; the first determination subunit is used to determine the N test cases corresponding to the target application based on the P preset cases.
[0141] In one optional embodiment, the first determining subunit includes: an acquisition module, a first determining module, a second determining module, a summation module, and a case determining module.
[0142] Optionally, the acquisition module is used to acquire historical test cases and development requirement documents corresponding to the target application, wherein the historical test cases are the test plans used by the target application in the previous development cycle; the first determination module is used to determine the first case score of each of the P preset cases based on the historical test cases, wherein the first case score is used to characterize the similarity between the test scenarios corresponding to the preset cases and the historical test cases; the second determination module is used to determine the second case score of each of the P preset cases based on the development requirement documents, wherein the second case score is used to characterize the correlation between the test scenarios of the preset cases and the development requirement documents; the summation module is used to perform a weighted summation of the first case score and the second case score of each preset case to obtain the case score of each preset case; the case determination module is used to select the preset cases whose case scores are greater than or equal to the preset scores from the P preset cases as test cases.
[0143] In one optional embodiment, the security testing unit 404 includes a third acquisition subunit, a fourth acquisition subunit, and a sending subunit.
[0144] Optionally, the third acquisition subunit is used to acquire the waiting time of the i-th test case among N test cases, wherein the waiting time is the duration between the generation time of the i-th test case and the current time; the fourth acquisition subunit is used to acquire the test tool corresponding to the i-th test case if the waiting time of the i-th test case is greater than or equal to a preset duration, wherein the test tool is used to execute the test steps of the i-th test case; and the sending subunit is used to send the test tool to the testers of the target application.
[0145] In one optional embodiment, the application security testing device further includes: a first acquisition unit, a third determination unit, a first sending unit, and a supplementary generation unit.
[0146] Optionally, the first acquisition unit is used to acquire the correlation score between the online issue and each of the N test cases, wherein the correlation score is used to characterize the correlation between the online issue and the execution steps of the test case, and the online issue is the application defect reported by users after the target application is launched; the third determination unit is used to take the test case corresponding to the maximum value among the N correlation scores corresponding to the N test cases as a common case if the maximum value is greater than or equal to the preset correlation score; the first sending unit is used to send the common case and the specification document to the designer of the common case, wherein the specification document is used to record the design rules of the preset case; the supplementary generation unit is used to generate a supplementary case based on the online issue if the maximum value among the N correlation scores is less than the preset correlation score, wherein the supplementary case includes at least the reproduction steps of the online issue.
[0147] In one optional embodiment, the application security testing apparatus further includes: a second acquisition unit, a second transmission unit, and a third transmission unit.
[0148] Optionally, the second acquisition unit is used to acquire historical test records of common cases, wherein the historical test records are used to record the test results obtained from the most recent execution of the common cases; the second sending unit is used to send the test tools of the common cases to the testers of the target application when the historical test records indicate that the common cases were successfully tested; the third sending unit is used to send the specification document to the testers of the target application when the historical test records indicate that the common cases were unsuccessful tested and there is no problem ticket corresponding to the common cases in the work order system.
[0149] In one optional embodiment, the application security testing device determines N test cases corresponding to the target application based on the requirement tags of the target application using the target model. The target model is a large language model trained based on the historical requirement tags and historical test cases corresponding to M applications, where M is a positive integer. The application security testing device further includes a dataset partitioning unit, an iterative training unit, an iterative update unit, and a model determination unit.
[0150] Optionally, the dataset partitioning unit is used to partition the historical requirement labels and historical test cases corresponding to M applications to obtain a test set and a training set; the iterative training unit is used to iteratively train the initial model using the historical requirement labels and historical test cases in the training set to obtain a training model; the iterative update unit is used to test the training model using the historical requirement labels and historical test cases in the test set, and iteratively update the training model based on the test results; and the model determination unit is used to take the training model after the last update as the target model.
[0151] It should be noted that the feature extraction unit 401, the first determination unit 402, the second determination unit 403, and the security testing unit 404 mentioned above correspond to steps S201 to S204 in the method embodiment. The instances and application scenarios implemented by the above units and the corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware components or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and can run in the computer terminal 10 provided in the embodiment.
[0152] Example 3
[0153] Embodiments of this application can also provide an electronic device. Figure 5This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 5 As shown, the electronic device includes: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.
[0154] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the above-mentioned application security testing method.
[0155] The memory may include high-speed random access memory (RAM), and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.
[0156] The processor can access information and applications stored in memory via a transmission device to perform the following steps: extracting features from the application data of the target application to obtain L application features of the target application, where L is a positive integer; determining requirement tags for the target application based on the L application features, where the requirement tags characterize the security testing requirements of the target application; determining N test cases corresponding to the target application based on the requirement tags of the target application, where N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results; and performing security testing on the target application based on the N test cases.
[0157] This application provides an application security testing solution. It employs machine learning, using a pre-trained large language model to extract features from the application data of the target application. This achieves accurate identification of application security testing requirements (i.e., requirement tags), thereby realizing the technical effect of intelligently matching test cases based on requirement tags. This solves the technical problem in existing technologies where testers need to design security test cases for different iterations of the application, resulting in low testing efficiency.
[0158] In other words, this application automatically analyzes and extracts the key features (i.e., L application features) of the target application through a pre-trained large language model. Then, based on the key features, it intelligently determines the security testing requirement tags corresponding to the application. Subsequently, based on the requirement tags corresponding to the application, this application can quickly select the most relevant test cases (i.e., N test cases). Each test case contains the necessary test steps and expected results, which can be directly applied to the security testing of the target application. This process reduces the workload of testers, avoids test blind spots caused by the limitations of human experience, thereby improving the accuracy of application security testing and enhancing the application's security protection capabilities.
[0159] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, PDAs, mobile internet devices, PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.
[0160] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.
[0161] Example 4
[0162] Embodiments of this application may also provide a storage medium.
[0163] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the application security testing method provided in the above method embodiment.
[0164] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.
[0165] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing application security testing method steps.
[0166] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0167] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0168] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.
[0169] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0170] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0171] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0172] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. An application security testing method, characterized in that, include: Feature extraction is performed on the application data of the target application to obtain L application features of the target application, where L is a positive integer; Based on the L application characteristics, the requirement tags of the target application are determined, wherein the requirement tags are used to characterize the security testing requirements of the target application; Based on the requirement tags of the target application, N test cases corresponding to the target application are determined, where N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results; The target application is subjected to security testing based on the N test cases.
2. The application security testing method according to claim 1, characterized in that, Before performing feature extraction on the application data of the target application, the application security testing method further includes: Collect raw data from the target application, wherein the raw data includes at least one of the following: Application version, used to characterize the development cycle of the target application; Scene data, used to characterize the application scenarios involved in the target application; Project data, used to characterize the source code of the development project to which the target application belongs; The raw data is cleaned to obtain the application data of the target application.
3. The application security testing method according to claim 1, characterized in that, Based on the requirement tags of the target application, N test cases corresponding to the target application are determined, including: Obtain the case label for each preset case from the N test cases, wherein the case label is used to characterize the test scenario type of the preset case, and the case label is one of the following: Unauthorized access, bypass, plaintext, replay, injection attacks, cross-site scripting attacks; Obtain the similarity between the demand tags of the target application and the case tags of each preset case; Filter the N test cases whose similarity is greater than or equal to a preset similarity to obtain P preset cases, where P is a positive integer greater than or equal to N; Based on the P preset cases, N test cases corresponding to the target application are determined.
4. The application security testing method according to claim 3, characterized in that, Based on the P preset cases, N test cases corresponding to the target application are determined, including: Obtain the historical test cases and development requirement documents corresponding to the target application, wherein the historical test cases are the test cases used by the target application in the previous development cycle; Based on the historical test cases, a first case score is determined for each of the P preset cases, wherein the first case score is used to characterize the similarity between the test scenarios corresponding to the preset cases and the historical test cases. Based on the development requirements document, a second case score is determined for each of the P preset cases, wherein the second case score is used to characterize the correlation between the test scenario of the preset case and the development requirements document; The first case score and the second case score of each preset case are weighted and summed to obtain the case score of each preset case; The preset cases whose scores are greater than or equal to the preset scores among the P preset cases are used as test cases.
5. The application security testing method according to claim 1, characterized in that, The target application is subjected to security testing based on the N test cases, including: Obtain the waiting time of the i-th test case among the N test cases, where the waiting time is the time between the generation time of the i-th test case and the current time; If the waiting time of the i-th test case is greater than or equal to a preset time, the test tool corresponding to the i-th test case is obtained, wherein the test tool is used to execute the test steps of the i-th test case; The testing tool is sent to the testers of the target application.
6. The application security testing method according to claim 1, characterized in that, After performing security testing on the target application based on the N test cases, the application security testing method further includes: Obtain the correlation score between the online issue and each of the N test cases, wherein the correlation score is used to characterize the correlation between the online issue and the execution steps of the test case, and the online issue is the application defect reported by users after the target application is launched; If the maximum value among the N associated scores corresponding to the N test cases is greater than or equal to the preset associated score, the test case corresponding to the maximum value is taken as a common case. The common cases and specification documents are sent to the designers of the common cases, wherein the specification documents are used to record the design rules of the preset cases; If the maximum value among the N associated scores is less than the preset associated score, a supplementary case is generated based on the online problem, wherein the supplementary case includes at least the steps for reproducing the online problem.
7. The application security testing method according to claim 6, characterized in that, After using the test case corresponding to the maximum value as a common case, the application security testing method further includes: Obtain the historical test records of the public case, wherein the historical test records are used to record the test results obtained from the most recent execution of the public case; If the historical test record indicates that the common case test was successful, the test tool for the common case will be sent to the testers of the target application. If the historical test record indicates that the common case test failed, and there is no corresponding issue ticket for the common case in the ticket system, the specification document will be sent to the testers of the target application.
8. The application security testing method according to claim 1, characterized in that, Using the target model, based on the requirement tags of the target application, N test cases corresponding to the target application are determined. The target model is a large language model trained on historical requirement tags and historical test cases corresponding to M applications, where M is a positive integer. The training steps of the target model include: The historical requirement tags and historical test cases corresponding to the M applications are divided to obtain the test set and the training set; The initial model is iteratively trained using historical demand labels and historical test cases in the training set to obtain the trained model. The training model is tested using historical demand tags and historical test cases in the test set, and the training model is iteratively updated based on the test results. The training model updated last time is used as the target model.
9. An application safety testing device, characterized in that, include: The feature extraction unit is used to extract features from the application data of the target application to obtain L application features of the target application, where L is a positive integer; The first determining unit is configured to determine the requirement tags of the target application based on the L application features, wherein the requirement tags are used to characterize the security testing requirements of the target application; The second determining unit is used to determine N test cases corresponding to the target application based on the requirement tags of the target application, where N is a positive integer, and each test case includes at least a case tag, test steps, and expected test results; The security testing unit is used to perform security testing on the target application based on the N test cases.
10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the application security testing method according to any one of claims 1 to 8.