Risk early warning method and platform

Abstract

This invention provides a risk warning method and platform. The method, applied to a risk warning platform, includes: acquiring source code and constructing a target runtime environment; performing static analysis on the source code using a static analysis rule base of a static analysis engine to obtain static analysis results; deploying the source code on the target runtime environment to obtain dynamic test results; associating the static analysis results and dynamic test results, updating the static analysis rule base based on the association results, and generating a risk assessment report. This approach can proactively identify mobile H5 compatibility risks early in the development phase and continuously optimize the rule base from online anomaly feedback through a self-learning mechanism. This shifts the timing of problem discovery from "online runtime" to "during coding development," achieving a transformation from passive remediation to proactive prevention, ultimately significantly reducing repair costs and improving application quality.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a risk warning method and platform. Background Technology

[0002] Currently, mobile H5 (HyperText Markup Language 5) development in browser environments faces severe compatibility challenges due to device fragmentation, browser kernel differences, and operating system version differentiation. Existing solutions mainly rely on manual testing, cloud testing platforms, or basic Lint tools (a static code analysis tool). These methods are all post-event detection methods with fixed and rigid rules, which cannot accurately predict risks in the early stages of development, nor do they have the ability to learn and optimize rules from real online user environments. This results in delayed problem discovery, high repair costs, and an inability to adapt to the rapidly evolving technology ecosystem. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a risk warning method and platform to proactively identify mobile H5 compatibility risks in the early stages of development, and to continuously optimize the rule base from online anomaly feedback through a self-learning mechanism, thereby advancing the timing of problem discovery from "online runtime" to "during coding development", realizing the transformation from passive remediation to proactive prevention, and ultimately significantly reducing repair costs and improving application quality.

[0004] In a first aspect, embodiments of the present invention provide a risk warning method applied to a risk warning platform. The method includes: acquiring source code and constructing a target operating environment; performing static analysis on the source code through a static analysis rule base of a static analysis engine to obtain static analysis results; deploying the source code on the target operating environment to obtain dynamic test results; associating the static analysis results and the dynamic test results, updating the static analysis rule base based on the association results, and generating a risk assessment report.

[0005] In an optional embodiment of this application, the steps of obtaining the source code and constructing the target runtime environment include: pulling the configuration file of the project to be tested and obtaining the source code of the configuration file; constructing a matrix including mobile device model, operating system version, browser component kernel version, and browser model, and using the matrix as the target runtime environment.

[0006] In an optional embodiment of this application, the static analysis engine is built based on an abstract syntax tree parsing tool; the step of performing static analysis on the source code using the static analysis rule base of the static analysis engine to obtain static analysis results includes: scanning the interfaces used in the source code; determining whether each interface has compatibility vulnerabilities using the static analysis rule base of the static analysis engine to obtain static analysis results; wherein, compatibility vulnerabilities include: the interface is not supported in the target runtime environment, or the cascading style sheet properties of the interface are not supported in the target runtime environment.

[0007] In optional embodiments of this application, the above method further includes: identifying a third-party library of the project to be tested and obtaining the open-source code of the third-party library; performing static analysis on the open-source code through the static analysis rule base of the static analysis engine to obtain static analysis results; and determining the final static analysis result based on the static analysis results of the source code and the static analysis results of the open-source code.

[0008] In an optional embodiment of this application, the step of deploying the source code on the target runtime environment to obtain dynamic test results includes: deploying the source code page on a real computer or simulator in the target runtime environment; capturing target events on the browser of the real computer or the browser of the simulator during runtime, and determining whether there are runtime errors based on the target events; obtaining the rendering effect of the source code page on multiple target runtime environments through a screenshot comparison tool, and determining whether there are rendering errors based on the rendering effect; and determining dynamic test results based on runtime errors and / or rendering errors.

[0009] In an optional embodiment of this application, the step of associating the static analysis results and the dynamic test results includes: associating runtime errors and / or rendering errors in the dynamic test results with compatibility vulnerabilities in the static analysis results.

[0010] In an optional embodiment of this application, the step of updating the static analysis rule base based on the association results includes: if a first compatibility vulnerability in the static analysis results is associated with any runtime error or rendering error in the dynamic test results, increasing the confidence of the rule corresponding to the first compatibility vulnerability; if a second compatibility vulnerability in the static analysis results is not associated with any runtime error or rendering error in the dynamic test results, deleting the rule corresponding to the second compatibility vulnerability from the static analysis rule base or reducing the confidence of the rule corresponding to the second compatibility vulnerability; if a target runtime error or target rendering error in the dynamic test results is not associated with any compatibility vulnerability in the static analysis results, generating a new rule based on the target runtime error or target rendering error, and adding the new rule to the static analysis rule base.

[0011] In an optional embodiment of this application, the step of generating a risk assessment report based on the association results includes: determining the risk level, scope of impact, code location, and remediation suggestions of the risk code based on the association results, and generating a risk assessment report based on the risk level, scope of impact, code location, and remediation suggestions of the risk code.

[0012] In an optional embodiment of this application, after the step of generating a risk assessment report based on the correlation results, the method further includes: pushing the risk assessment report to the terminal device of the developer or tester based on the risk level.

[0013] Secondly, embodiments of the present invention also provide a risk warning platform, which is used to execute the above-described risk warning method.

[0014] The embodiments of the present invention bring the following beneficial effects: This invention provides a risk warning method and platform. The method involves acquiring source code and constructing a target runtime environment; performing static analysis on the source code using a static analysis rule base of a static analysis engine to obtain static analysis results; deploying the source code on the target runtime environment to obtain dynamic test results; and correlating the static analysis results and dynamic test results to update the static analysis rule base and generate a risk assessment report. This approach proactively identifies mobile H5 compatibility risks early in the development phase and continuously optimizes the rule base based on online anomaly feedback through a self-learning mechanism. This shifts the timing of problem discovery from "online runtime" to "during coding development," transforming from passive remediation to proactive prevention, ultimately significantly reducing repair costs and improving application quality.

[0015] Other features and advantages of this disclosure will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

[0016] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 A flowchart of a risk warning method provided in an embodiment of the present invention; Figure 2 A flowchart of another risk warning method provided in an embodiment of the present invention; Figure 3 A schematic diagram illustrating a risk warning method provided in an embodiment of the present invention; Figure 4 A schematic diagram illustrating a specific example of a risk warning method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Currently, mobile H5 development in a browser environment faces severe compatibility challenges due to device fragmentation, differences in browser kernels, and differentiation in operating system versions. Existing solutions mainly rely on manual testing, cloud testing platforms, or basic Lint tools (a type of static code analysis tool). These methods are all post-event detection methods with fixed and rigid rules, which cannot accurately predict risks in the early stages of development, nor do they have the ability to learn and optimize rules from real online user environments. This results in delayed problem discovery, high repair costs, and an inability to adapt to the rapidly evolving technology ecosystem.

[0021] Based on this, the present invention provides a risk warning method and platform, specifically a mobile H5 compatibility risk warning method based on static analysis and self-learning mechanisms. This method performs multi-dimensional analysis of the source code through a static analysis layer, utilizes the intelligent risk model of the rule engine layer for compatibility risk identification and assessment, and innovatively introduces a self-learning feedback layer. By collecting and analyzing rendering anomaly data from real online users, it dynamically discovers new compatibility patterns and provides feedback to optimize the rule base. Finally, through an integration layer deeply integrated with the development process, it provides developers with accurate risk reports and remediation suggestions during the coding phase, thereby constructing a closed-loop system that can continuously evolve and prevent compatibility issues from the source.

[0022] To facilitate understanding of this embodiment, a risk warning method disclosed in this embodiment of the invention will first be described in detail.

[0023] Example 1: This invention provides a risk warning method applied to a risk warning platform. (See also...) Figure 1The flowchart shown illustrates a risk warning method, which includes the following steps: Step S102: Obtain the source code and build the target runtime environment.

[0024] In this embodiment, the source code of the project under test can be obtained, and the target runtime environment of the project under test can be constructed. The target runtime environment is used for subsequent dynamic testing. If only static analysis is performed, the target runtime environment of the project under test may not need to be constructed, thereby improving the efficiency of static analysis.

[0025] Step S104: Perform static analysis on the source code using the static analysis rule base of the static analysis engine to obtain the static analysis results.

[0026] In this embodiment, the static analysis rule base of the static analysis engine can be used to perform static analysis on the source code and obtain the static analysis results.

[0027] The static analysis rule base in this embodiment can perform self-learning feedback, thereby achieving continuous evolution.

[0028] Step S106: Deploy the source code on the target runtime environment to obtain dynamic test results.

[0029] In this embodiment, the source code can be deployed on the target runtime environment to perform dynamic testing and obtain dynamic test results.

[0030] Step S108: Associate the static analysis results and dynamic test results, update the static analysis rule base based on the association results, and generate a risk assessment report.

[0031] In this embodiment, static analysis results and dynamic test results can be automatically correlated, compared and verified, and the correlation results can be used to automatically optimize the static analysis rule base, thereby realizing a closed-loop method process of "combining static and dynamic results with self-learning".

[0032] The static analysis rule base in this embodiment can be automatically updated based on the correlation between static analysis results and dynamic test results. For example, rules in the static analysis rule base can be added or removed based on the differences between static analysis results and dynamic test results (e.g., correcting false alarms or discovering unknown risks). The static analysis rule base in this embodiment can not only manually import external data, but also achieve self-evolution and continuous evolution.

[0033] This invention provides a risk warning method that involves acquiring source code and constructing a target runtime environment; performing static analysis on the source code using a static analysis rule base of a static analysis engine to obtain static analysis results; deploying the source code on the target runtime environment to obtain dynamic test results; and correlating the static analysis results and dynamic test results to update the static analysis rule base and generate a risk assessment report. This method proactively identifies mobile H5 compatibility risks early in the development phase and continuously optimizes the rule base based on online anomaly feedback through a self-learning mechanism. This shifts the timing of problem discovery from "online runtime" to "during coding development," transforming from passive remediation to proactive prevention, ultimately significantly reducing repair costs and improving application quality.

[0034] Example 2: This embodiment provides another risk warning method, which is implemented based on the above embodiment. The focus is on describing the specific implementation of the risk warning method. (See [link]). Figure 2 The flowchart shown represents another risk warning method, which includes the following steps: Step S202: Obtain the source code and build the target runtime environment.

[0035] In some embodiments, the configuration file of the project under test can be retrieved to obtain the source code of the configuration file; a matrix including mobile device model, operating system version, browser component kernel version, and browser model can be constructed, and the matrix can be used as the target runtime environment.

[0036] See also Figure 3 The diagram illustrates a risk warning method. In the first stage, data input, this embodiment can obtain source code from a code repository and construct a runtime environment information pool that includes a list of cloud real devices and browsers.

[0037] This embodiment can integrate GitLab API (an interface that allows developers to programmatically access and manipulate resources on the platform), GitHub API (an interface that provides read and write permissions for resources such as repositories, users, organizations, issues, and pull requests), and npm registry (an interface that stores and distributes data packages and supports version control, permission management, and other functions), and automatically pull the source code, package.json (a type of metadata file), and other configuration files of the project to be tested.

[0038] In this embodiment, a matrix containing mobile device models, operating system versions, browser component (e.g., WebView) kernel versions, and browser models can be maintained through a cloud-based real device platform (such as Sauce Labs, BrowserStack, or a self-built cluster) and a device information database, serving as the target runtime environment for dynamic testing.

[0039] Step S204: Perform static analysis on the source code using the static analysis rule base of the static analysis engine to obtain the static analysis results.

[0040] In some embodiments, the static analysis engine is built based on an abstract syntax tree parsing tool; it can scan the interfaces used in the source code; and determine whether each interface has compatibility vulnerabilities through the static analysis rule base of the static analysis engine to obtain static analysis results; wherein, compatibility vulnerabilities include: the interface is not supported in the target runtime environment, or the cascading style sheet properties of the interface are not supported in the target runtime environment.

[0041] like Figure 3 As shown, in the second stage: core engine analysis, this embodiment can perform source code parsing and rule base matching through a static analysis engine.

[0042] In this embodiment, a self-developed analysis engine based on Abstract Syntax Tree (AST) parsing tools (such as @babel / parser, espree, and other JavaScript parsers) can be used as the static analysis engine.

[0043] The static analysis engine in this embodiment can perform syntax and API (interface) checks: scan the HTML5, CSS3, JavaScript and other APIs used in the code, and compare them with the built-in "static analysis rule library" (the initial data can come from Can IUse (a compatibility query website focused on front-end development)) to identify APIs (such as Array.prototype.flat) or CSS (Cascading Style Sheets) properties (such as gap) that may not be supported in the target runtime environment.

[0044] In some embodiments, third-party libraries of the project under test can be identified, and open-source code of the third-party libraries can be obtained; static analysis of the open-source code can be performed through the static analysis rule base of the static analysis engine to obtain static analysis results; and the final static analysis result can be determined based on the static analysis results of the source code and the static analysis results of the open-source code.

[0045] In this embodiment, the third-party library is a code repository created and released by external developers or organizations that are not part of the official or core development team. It is used to extend the functionality of programming languages ​​and help developers achieve specific tasks more efficiently.

[0046] In this embodiment, during the first stage (data input), the open-source code of third-party libraries in the project under test can be obtained, for example, by locking the versions of these libraries, providing a foundation for accurate analysis. In the second stage (core engine analysis), the third-party libraries introduced by the project and their versions can be analyzed, and known compatibility vulnerabilities or issues can be identified.

[0047] Step S206: Deploy the source code on the target runtime environment to obtain dynamic test results.

[0048] In some embodiments, the source code page can be deployed on a real computer or emulator in the target runtime environment; target events on the browser of the real computer or the browser of the emulator can be captured at runtime, and runtime errors can be determined based on the target events; the rendering effect of the source code page on multiple target runtime environments can be obtained through screenshot comparison tools, and rendering errors can be determined based on the rendering effect; dynamic test results can be determined based on runtime errors and / or rendering errors.

[0049] like Figure 3 As shown, in the second stage: core engine analysis, this embodiment can also perform dynamic sandbox testing by comparing error / style screenshots during cloud real machine matrix deployment and runtime monitoring.

[0050] This embodiment can use browser or application automation testing tools such as WebDriver, Puppeteer, or Appium for automated script control, including: (1) Real environment rendering: Automatically deploy H5 pages to real machines / emulators in the "Runtime Environment Information Pool" for execution; Runtime error capture: Collect runtime errors that cannot be found by static analysis by capturing browser events such as console.error and unhandledrejection.

[0051] (2) Visual difference comparison: Use screenshot comparison tools (such as pixelmatch) to compare the rendering effect of the page in different environments and identify problems such as style disorder and layout collapse.

[0052] Step S208: Associate the static analysis results and dynamic test results, update the static analysis rule base based on the association results, and generate a risk assessment report.

[0053] In some embodiments, runtime errors and / or rendering errors in dynamic test results can be correlated with compatibility vulnerabilities in static analysis results.

[0054] like Figure 3 As shown, in the second stage: core engine analysis, this embodiment can also correlate static analysis results and dynamic test results.

[0055] In this embodiment, a big data processing platform (such as Elasticsearch) can be used for log storage and retrieval to automatically associate and compare runtime errors and / or rendering errors captured in dynamic testing with compatibility vulnerabilities in static analysis reports.

[0056] In some embodiments, if a first compatibility vulnerability in the static analysis results is associated with any runtime error or rendering error in the dynamic test results, the confidence level of the rule corresponding to the first compatibility vulnerability is increased; if a second compatibility vulnerability in the static analysis results is not associated with any runtime error or rendering error in the dynamic test results, the rule corresponding to the second compatibility vulnerability is deleted from the static analysis rule base or the confidence level of the rule corresponding to the second compatibility vulnerability is reduced; if a target runtime error or target rendering error in the dynamic test results is not associated with any compatibility vulnerability in the static analysis results, a new rule is generated based on the target runtime error or target rendering error, and the new rule is added to the static analysis rule base.

[0057] like Figure 3 As shown, in the third stage: self-learning and optimization, this embodiment can update the static analysis rule base through a self-learning model.

[0058] In this embodiment, false positives can be corrected: if the second compatibility vulnerability in the static analysis results has never caused a problem in a large number of dynamic tests, the model will reduce the confidence of the rule or mark it as a "false positive".

[0059] This embodiment reveals new insights: analyzing error patterns (target runtime errors or target rendering errors) that occur frequently in dynamic testing but do not exist in the static rule base, and automatically generating new risk rules (e.g., "In WKWebView, using IntersectionObserver will cause a certain type of event listener to fail").

[0060] In this embodiment, the confidence level can also be improved: if the first compatibility vulnerability in the static analysis results appears in a large number of dynamic tests, the confidence level of the rule corresponding to the first compatibility vulnerability is increased.

[0061] In summary, this embodiment can update the knowledge base: newly learned rules and revised rules are automatically or after review and updated to the "compatibility rule base", making the next static analysis more accurate.

[0062] In some embodiments, the risk level, scope of impact, code location, and remediation recommendations of a risk code can be determined based on the association results, and a risk assessment report can be generated based on the risk level, scope of impact, code location, and remediation recommendations of the risk code.

[0063] like Figure 3 As shown, in the fourth stage: output and early warning, this embodiment can generate a risk assessment report.

[0064] In this embodiment, all data can be aggregated through data visualization libraries (such as ECharts) and report generation tools to generate a comprehensive risk assessment report that includes risk level (high risk, medium risk, low risk), scope of impact, specific code location, and remediation suggestions.

[0065] Step S210: Based on the risk level, push the risk assessment report to the terminal devices of developers or testers.

[0066] like Figure 3 As shown, in the fourth stage: output and early warning, this embodiment can also push a risk assessment report.

[0067] In this embodiment, message push services (such as integrating WeChat Work, DingTalk, or SMTP (Simple Mail Transfer Protocol) email services) can automatically push early warning information to the terminal devices of developers or testers based on the risk level. For example, in project team chat groups or the email addresses of relevant personnel, early detection and early warning of problems can be achieved.

[0068] Example 3: This embodiment provides another risk warning method, which is implemented based on the above embodiment. It focuses on describing specific examples of the risk warning method. (See [link to previous document]). Figure 4 A schematic diagram illustrating a specific example of a risk warning method is provided. This embodiment can implement the above-mentioned risk warning method through the following steps: Step 1: Code triggering and static quick screening.

[0069] Action: The developer submits code to Git, triggering a platform scan. The static analysis engine extracts the source code and performs rapid analysis using the current static analysis rule base.

[0070] Output: Generates a "Potential Risk List" of the first round of static analysis results, marking suspected problem areas. This result can be immediately fed back to the code review stage.

[0071] Step 2: Dynamic sandbox verification.

[0072] Action: The platform will automatically deploy the submitted code / application to the "cloud real device matrix" covering the target user group for automated dynamic testing (such as user interface rendering and core process operation).

[0073] Output: Capture real-world runtime errors, logs, performance data, and differences in UI screenshots to form a dynamic test result "evidence checklist".

[0074] Step 3: Comparison of dynamic and static results and self-learning.

[0075] Action: The self-learning module compares the "potential risk list" with the "empirical problem list": if a problem warned by static alerts is confirmed by dynamic testing, the confidence of the rule is enhanced; if a problem warned by static alerts does not occur, it is marked as a "false alarm sample" for subsequent rule optimization; if new problems not warned by static alerts are discovered dynamically, they are marked as "new knowledge samples".

[0076] Output: Generate rule base optimization instructions.

[0077] Step 4: The self-evolution of the rule base.

[0078] Action: Based on "false alarm samples" and "new knowledge samples", the system automatically or semi-automatically corrects existing rules, generates new rules, and updates the static analysis rule base.

[0079] Key results: The static analysis rule base will become smarter and more accurate in the next static analysis (the next code commit). False positive rate decreases, and coverage improves.

[0080] Step 5: Risk integration and early warning.

[0081] Action: The platform integrates the static and dynamic conclusions of this scan to generate a risk assessment report that includes risk level, scope of impact, code location, repair suggestions, and real device screenshot evidence.

[0082] Ultimately, this achieves early warning: Risk assessment reports are pushed to developers and testers via email, instant messaging tools (DingTalk / WeChat Work), or directly updated to the code merge request interface. Thus, issues that might have surfaced with online users are detected and warned of in advance during the coding, development, and testing phases.

[0083] In summary, the method provided by the embodiments of the present invention can proactively identify mobile H5 compatibility risks in the early stages of development, and can continuously optimize the rule base from online anomaly feedback through a self-learning mechanism. This advances the timing of problem discovery from "online runtime" to "during coding development," realizing a shift from passive remediation to proactive prevention, ultimately significantly reducing repair costs and improving application quality.

[0084] Example 4: Corresponding to the above method embodiments, this embodiment provides a risk warning platform, which is used to execute the risk warning method provided in the aforementioned embodiments.

[0085] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the risk warning platform described above can be referred to the corresponding process in the aforementioned embodiments of the risk warning method, and will not be repeated here.

[0086] Example 5: This invention also provides an electronic device for running the above-described risk warning method; see [link to previous document]. Figure 5 The diagram shows the structure of an electronic device, which includes a memory 100 and a processor 101. The memory 100 is used to store one or more computer instructions, which are executed by the processor 101 to implement the aforementioned risk warning method.

[0087] Furthermore, Figure 5 The electronic device shown also includes a bus 102 and a communication interface 103, with the processor 101, the communication interface 103 and the memory 100 connected via the bus 102.

[0088] The memory 100 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0089] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. Processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 100, and processor 101 reads information from memory 100 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0090] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the aforementioned risk warning method. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0091] The computer program product of the risk warning method and platform provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0092] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and / or device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0093] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0094] If a function 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 invention, or the part that contributes to the prior art, or a 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 invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0095] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0096] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A risk warning method, characterized in that, The method, applied to a risk warning platform, includes: Obtain the source code and build the target runtime environment; The source code is statically analyzed using the static analysis rule base of the static analysis engine to obtain static analysis results; The source code is deployed and run on the target runtime environment to obtain dynamic test results; The static analysis results and the dynamic test results are correlated, and the static analysis rule base is updated based on the correlation results to generate a risk assessment report.

2. The method according to claim 1, characterized in that, The steps to obtain the source code and build the target runtime environment include: Pull the configuration file of the project to be tested and obtain the source code of the configuration file; Construct a matrix that includes mobile device models, operating system versions, browser component kernel versions, and browser models, and use this matrix as the target runtime environment.

3. The method according to claim 1, characterized in that, The static analysis engine is built based on an abstract syntax tree parsing tool; the steps of performing static analysis on the source code using the static analysis rule base of the static analysis engine to obtain the static analysis results include: Scan the interfaces used in the source code; The static analysis engine uses its static analysis rule base to determine whether each interface has compatibility vulnerabilities, thus obtaining static analysis results. The compatibility vulnerabilities include: the interface is not supported in the target runtime environment, or the cascading style sheet properties of the interface are not supported in the target runtime environment.

4. The method according to claim 2, characterized in that, The method further includes: Identify the third-party libraries of the project to be tested and obtain the open-source code of the third-party libraries; The open-source code is statically analyzed using the static analysis rule base of the static analysis engine to obtain static analysis results; The final static analysis result is determined based on the static analysis results of the source code and the open-source code.

5. The method according to claim 1, characterized in that, The steps of deploying the source code to the target runtime environment and running it to obtain dynamic test results include: Deploy the pages of the source code to run on a real computer or simulator in the target runtime environment; At runtime, target events on the browser of the real computer or the browser of the emulator are captured, and the existence of runtime errors is determined based on the target events; The rendering effects of the source code page on multiple target runtime environments are obtained by using a screenshot comparison tool, and the existence of rendering errors is determined based on the rendering effects. The dynamic test results are determined based on the runtime errors and / or the rendering errors.

6. The method according to claim 1, characterized in that, The step of associating the static analysis results with the dynamic test results includes: The runtime errors and / or rendering errors in the dynamic test results are correlated with the compatibility vulnerabilities in the static analysis results.

7. The method according to claim 6, characterized in that, The steps for updating the static analysis rule base based on the association results include: If the first compatibility vulnerability in the static analysis results is associated with any runtime error or rendering error in the dynamic test results, the confidence level of the rule corresponding to the first compatibility vulnerability is increased. If the second compatibility vulnerability in the static analysis results is not associated with any runtime error or rendering error in the dynamic test results, delete the rule corresponding to the second compatibility vulnerability from the static analysis rule base or reduce the confidence of the rule corresponding to the second compatibility vulnerability. If the target runtime error or target rendering error in the dynamic test results is not associated with any compatibility vulnerability in the static analysis results, a new rule is generated based on the target runtime error or the target rendering error, and the new rule is added to the static analysis rule base.

8. The method according to claim 6, characterized in that, The steps for generating a risk assessment report based on the correlation results include: Based on the correlation results, the risk level, scope of impact, code location, and remediation suggestions of the risk code are determined, and a risk assessment report is generated based on the risk level, scope of impact, code location, and remediation suggestions of the risk code.

9. The method according to claim 8, characterized in that, Following the step of generating a risk assessment report based on the correlation results, the method further includes: Based on the risk level, the risk assessment report will be pushed to the terminal devices of developers or testers.

10. A risk early warning platform, characterized in that, The risk warning platform is used to execute the risk warning method according to any one of claims 1-9.

Images