Programming auxiliary teaching interaction method and system based on large model and symbolic execution

Abstract

The invention discloses a programming auxiliary teaching interaction method and system based on a large language model and symbolic execution. A teacher end provides questions and correct codes; extracting function points and constraint rules by the large model, and performing static analysis on correct codes to obtain function interfaces, branch conditions and boundary values; generating an initial seed case, and forming an effective test case set after screening and post-processing verification; and converting the case set into a format which can be identified by a symbolic execution engine, and generating a new test input and a corresponding output thereof through a symbolic execution exploration path to obtain a final test case set. And after the student submits the code, performing symbolic execution on the code to generate a student test case set, verifying the correctness of the code through double paths, and comparing the teacher-student test case set to evaluate the code coverage integrity. According to the invention, the problems of difficulty in self-evaluation of students, feedback lagging and low learning efficiency in the programming teaching process can be effectively solved.

Description

Technical Field

[0001] This invention relates to the field of intelligent teaching technology, and in particular to a programming-assisted teaching interaction method and system based on large models and symbolic execution. Background Technology

[0002] Programming instruction, especially core courses in computer science education, has long been plagued by problems such as inefficiency and insufficient personalized feedback. Traditional methods of grading programming assignments rely heavily on manual work by teachers, which is not only inefficient and results in delayed feedback, but also makes it difficult to conduct in-depth and consistent assessments of the completeness and robustness of the code logic.

[0003] In recent years, with the development of educational technology, automated assessment systems have been applied in some online programming platforms. These systems typically determine the correctness of student programs based on predefined input / output test cases. However, such systems have significant limitations: First, their test cases are mostly written manually by teachers, resulting in limited quantity and quality, making it difficult to cover all possible execution paths, boundary conditions, and abnormal states, leading to insufficient assessment coverage. Second, these systems usually only provide binary results of "pass / fail," failing to provide in-depth feedback with pedagogical significance, such as "why the error occurred" or "where the logical deviation lies," when student code makes mistakes. This makes it difficult for students to effectively self-correct and learn based on limited information.

[0004] Furthermore, although static code analysis techniques and methods from the field of program verification (such as symbolic execution and abstract interpretation) have been studied for code defect detection, their application in educational settings still faces challenges. While symbolic execution can systematically explore program paths and generate high-coverage test cases, it suffers from path explosion, high constraint-solving complexity, and the need for specialized configuration, making it difficult for ordinary teachers to directly apply in teaching practice. On the other hand, although large language models demonstrate powerful capabilities in code generation and understanding, and can be used for preliminary code interpretation or example generation, their output is subject to uncertainty and illusion phenomena, and the generated test cases often lack reliable guarantees in terms of correctness, logical consistency, and boundary value.

[0005] Therefore, existing technologies lack a solution that can deeply integrate the semantic understanding and generation capabilities of large language models with the path analysis and logical rigor of symbolic execution technologies to automatically generate high-quality, high-coverage test cases, and on this basis, provide students with immediate, accurate, and pedagogically insightful multi-layered feedback. This invention aims to address the aforementioned technical bottlenecks and meet the urgent need for automated and intelligent auxiliary tools in programming education. Summary of the Invention

[0006] The purpose of this invention is to solve the problems in the prior art.

[0007] The technical solution adopted by this invention to solve its technical problem is as follows: The first invention provides a programming-assisted teaching interaction method based on large models and symbolic execution, comprising the following steps:

[0008] The teacher provides programming problems and corresponding correct code; extracts the functional points and constraint rules of the programming problems based on a large language model; and performs static analysis on the correct code using an abstract syntax tree analysis tool to obtain the static analysis results.

[0009] Based on the aforementioned functional points, constraint rules, and static analysis results, initial seed test cases are generated. After post-processing verification, a valid test case set is formed. The valid test case set is converted into a format adapted to the symbolic execution engine. Using the correct code as a benchmark, the code path is explored through symbolic execution to generate new test inputs and their corresponding outputs. After deduplication, classification, and supplementation, the final teacher test case set is output. The classification includes normal test cases, boundary test cases, and abnormal test cases. The supplementation involves generating test cases for missing scenarios through a large language model.

[0010] After a student submits code, the code undergoes syntax checking and compilation. Once compilation is successful, the symbolic execution engine is invoked to explore the path of the student's code and generate a set of student test cases.

[0011] The correctness of the student code is verified through a dual-path approach. On one hand, the correct code is executed with the input from the student test case set, and the output results are compared. On the other hand, the student code is executed with the input from the teacher test case set, the expected output is compared, and the path differences are analyzed through symbolic execution tree analysis to generate an error report containing the difference input, expected output, actual output, and path divergence points.

[0012] By comparing the teacher's test case set with the student's test case set, the coverage completeness of the student's code is evaluated from three dimensions: path, branch, and scenario, including path coverage, branch coverage, and scenario coverage.

[0013] Preferably, the abstract syntax tree analysis tool is a syntax parser adapted to the target programming language, including:

[0014] For Java, choose JavaParser; for C / C++, choose Clang AST; and for Python, choose its built-in AST module.

[0015] Preferably, the static analysis results include function interfaces, branch conditions, and boundary values; the branch conditions include the judgment logic of if, for, while, and switch statements in the code; and the boundary values ​​are derived based on the constraint rules and branch conditions, including the extreme values, length boundaries, and critical values ​​of the input parameters.

[0016] Preferably, the post-processing verification includes:

[0017] Syntax validation, based on the function interface, ensures that the test input conforms to the function call specification;

[0018] Function coverage check: Verify that the seed test cases cover all the functional points in the problem requirements by comparing them with the functional points. If there are any uncovered functional points, supplement them by generating corresponding seed test cases through the large language model.

[0019] Logical consistency verification filters out use cases that violate the constraints based on the aforementioned constraint rules;

[0020] Output accuracy verification: By running the correct code, verify the correctness of the expected output of each seed use case and eliminate use cases with inconsistent output.

[0021] Preferably, the symbolic execution engine is a path exploration tool capable of analyzing the target programming language and is adapted according to the target language, including: KLEE for C / C++, SymbolicPathFinder for Java, and CrossHair based on hybrid execution for Python.

[0022] Preferably, the step of analyzing path differences through symbolic execution trees to generate an error report containing the difference input, expected output, actual output, and path divergence points specifically involves:

[0023] The symbolic execution tree displays the program execution path in a tree structure. Nodes represent branch conditions or statements, and leaf nodes represent the path endpoints. By comparing the symbolic execution tree nodes of the teacher's code and the student's code, the path divergence points can be located.

[0024] Preferably, the step of evaluating the coverage completeness of the student code from three dimensions—path, branch, and scenario—by comparing the teacher's test case set with the student's test case set, including path coverage, branch coverage, and scenario coverage, specifically involves:

[0025] The path coverage is the ratio of the number of teacher test case set paths covered by the student test case set to the total number of teacher test case set paths. The branch coverage is the ratio of the number of teacher code branches covered by the student code to the total number of teacher code branches. The scenario coverage is the ratio of the number of teacher test case category scenarios covered by the student test case set to the total number of teacher test case category scenarios.

[0026] Preferably, the path difference analysis of the dual-path verification is achieved through symbolic execution tree visualization, and the coverage integrity is output as a coverage assessment report in text and chart form.

[0027] Secondly, the present invention provides a programming-assisted teaching interactive system based on large models and symbolic execution, comprising:

[0028] The standard code processing module provides programming questions and corresponding correct code to the teacher; it extracts the functional points and constraint rules of the programming questions based on a large language model; and it performs static analysis on the correct code using an abstract syntax tree analysis tool to obtain the static analysis results.

[0029] The test case generation module generates initial seed test cases based on the aforementioned functional points, constraint rules, and static analysis results. After post-processing verification, a valid test case set is formed. The valid test case set is converted into a format adapted to the symbolic execution engine. Using the correct code as a benchmark, the code path is explored through symbolic execution to generate new test inputs and their corresponding outputs. After deduplication, classification, and supplementation, the final teacher test case set is output. The classification includes normal test cases, boundary test cases, and abnormal test cases. The supplementation involves generating test cases for missing scenarios through a large language model.

[0030] The student code generation module performs syntax checks and compilation on the student code after the student submits the code. After successful compilation, it calls the symbolic execution engine to explore the path of the student code and generate a set of student test cases.

[0031] The dual-path verification module verifies the correctness of the student code through two paths: on the one hand, it executes the correct code with the input from the student test case set and compares the output results; on the other hand, it executes the student code with the input from the teacher test case set, compares the expected output, and analyzes the path differences through symbolic execution tree to generate an error report containing the difference input, expected output, actual output, and path divergence points.

[0032] The coverage assessment module evaluates the coverage completeness of the student code from three dimensions: path, branch, and scenario, by comparing the teacher test case set with the student test case set. This includes path coverage, branch coverage, and scenario coverage.

[0033] Thirdly, the present invention provides an electronic device, comprising:

[0034] One or more processors;

[0035] Storage device for storing one or more programs;

[0036] When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any of the first aspects.

[0037] The present invention has the following beneficial effects:

[0038] (1) The present invention solves the problems of syntax errors, incomplete functional coverage, constraint violation and expected output error in traditional initial use cases through a four-dimensional post-processing process of syntax verification, functional coverage check, logical consistency check and output accuracy verification, and provides high-quality seed use cases for subsequent symbolic execution path exploration;

[0039] (2) This invention combines the “test case generation efficiency” of the large model with the “path exploration depth” of symbolic execution, which reduces generation time compared with the traditional manual writing of test cases and covers more comprehensive scenarios (including normal, boundary and abnormal scenarios).

[0040] (3) The dual-path verification of the present invention not only compares the output results, but also analyzes the path differences through symbolic execution tree, accurately locates deep logic problems such as branch judgment errors and missing boundary processing, and solves the defect of traditional "input-output" comparison that cannot locate the cause of error;

[0041] (4) Based on the coverage index of three dimensions of path, branch and scenario, this invention clarifies the coverage gaps of students' code, guides students to improve the code in a targeted manner, helps teachers to grasp the students' understanding of the function of the question, and improves the effect of programming teaching.

[0042] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments, but the present invention is not limited to the embodiments. Attached Figure Description

[0043] Figure 1 This is a diagram illustrating the method steps of an embodiment of the present invention;

[0044] Figure 2 This is a flowchart illustrating an embodiment of the present invention;

[0045] Figure 3 This is a detailed flowchart of the feature extraction stage in an embodiment of the present invention;

[0046] Figure 4 This is a detailed flowchart of the initial use case generation and verification phase in an embodiment of the present invention;

[0047] Figure 5 This is a detailed flowchart of the teacher use case set enhancement and optimization phase in an embodiment of the present invention;

[0048] Figure 6 This is a detailed flowchart of the dual-path verification module according to an embodiment of the present invention;

[0049] Figure 7 This is a visual comparison chart of path differences for the "None" error in this embodiment of the invention;

[0050] Figure 8 This is a visual comparison chart of path differences for the "unprocessed negative number min_len" error in an embodiment of the present invention;

[0051] Figure 9 This is a system structure diagram of an embodiment of the present invention;

[0052] Figure 10 This is a schematic diagram of the electronic device structure according to an embodiment of the present invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0054] like Figure 1 As shown, the interactive programming-assisted teaching method based on a large language model and symbolic execution proposed in this application proceeds as follows:

[0055] In S101, the teacher provides programming problems and correct code, and extracts functional points, constraints and code structure features by combining large model semantic analysis and static code analysis (AST) to generate initial seed test cases. After verification, a valid set of seed test cases is obtained.

[0056] S102 takes the seed test case set as input, performs symbolic execution on the correct code to explore and capture more edge scenario test cases, and after deduplication and optimization by scenario classification such as "core function, boundary, exception", the final teacher test case set is obtained.

[0057] S103: After a student submits code, its syntax is checked, and all reachable paths are explored through symbolic execution to obtain a set of student test cases that reflect its true behavior.

[0058] S104 accurately locates errors in student code through two-way verification: on the one hand, it compares the consistency of the output of the teacher and student test case sets; on the other hand, it uses the teacher's test case set to drive the student code, and accurately locates the root cause of logical errors by comparing the differences in symbolic execution paths; finally, it generates a deep error report containing the difference input, expected output, actual output and path divergence points.

[0059] S105 compares the test case sets of teachers and students, evaluates the coverage completeness of student code from multiple dimensions such as path, branch, and "core / boundary / exception" scenarios, and generates an evaluation report containing missing scenario analysis and specific improvement suggestions to guide students in improving their code.

[0060] The following example demonstrates the implementation details of each step in the Python function `check_string(s: str, min_len: int) -> str`, which checks the validity of string `s`. The specific implementation method is as follows:

[0061] In step S101, the teacher uploads the programming problem, constraints, and correct code through the human-computer interaction interface of the teacher input module, and stores them in the storage module, as follows:

[0062]

[0063] like Figure 3 As shown, the system passes the question and correct code to the large model analysis module, which calls the large language model (such as GPT-4) and AST analysis tools to perform the following operations:

[0064] Input the programming problem description into GPT-4, and obtain the problem's functionalities and constraints based on preset hints:

[0065] Input prompt: "Extract the functional points (input, output, core logic) and constraint rules (parameter range, type) of the question";

[0066] GPT-4 Output:

[0067]

[0068] The system invokes Python-compatible AST analysis tools (such as the built-in ast library) to construct a code syntax tree, traversing nodes to deterministically extract structured features. Simultaneously, code can be input into GPT-4 for higher-dimensional semantic analysis and boundary value derivation.

[0069] Function interface: check_string(s: str, min_len: int) -> str;

[0070] Branching conditions: ① if s is None ② if s == "" ③ if min_len < 0 ④ if len(s) <min_len;

[0071] Boundary values: ① s is None, empty string, or non-empty string; ② min_len is 0, positive number, or negative number; ③ Relationship between the length of s and min_len: equal, less than, or greater than.

[0072] like Figure 4 As shown, the system calls the initial test case generation and verification module. Based on the features from step 2, it generates initial seed test cases using GPT-4. The test case format includes "input parameters + expected output".

[0073]

[0074] Post-processing verification will be performed on the test cases generated by GPT-4:

[0075] Syntax and Executability Check: Test Case 5 was found to contain the string "0" for min_len, which does not match the int type of the interface and was therefore removed. Remaining test cases: {1, 2, 3, 4, 6}.

[0076] Function coverage check: The case of missing min_len being a negative number is invalid, which does not cover all function points. Add test case 7("test", -1, "Error: Invalid min_len") and pass the previous syntax check.

[0077] Logical consistency check: Although the input of test case 7("test", -1) is a negative number, it is specifically used to test the "invalid min_len" exception handling branch, so it does not violate the test logic, but is intentional. The min_len values ​​of other test cases are all non-negative, so all test cases pass this check.

[0078] Output validity check: The code runs correctly, and the actual output of all test cases is consistent with the expected output. There are no invalid test cases.

[0079] Ultimately, the resulting set of valid seed use cases is: {use case 1, use case 2, use case 3, use case 4, use case 6, use case 7}.

[0080] like Figure 5 As shown, the system calls the symbolic execution path exploration module to enhance and optimize the seed test case set, resulting in the final teacher test case set. The specific implementation is as follows:

[0081] Path exploration: By invoking a symbolic execution or hybrid execution engine adapted for Python (such as CrossHair), targeting the teacher's correct code, and starting with effective seed use cases, explore and generate new test inputs that can cover edge scenarios:

[0082]

[0083] The test cases are then deduplicated, categorized, and supplemented for optimization, resulting in the final teacher test cases:

[0084] Deduplication: Test case 4("valid string", 5) and test case 6("another valid", 2) both test the "normal valid" scenario, and the logic is duplicated. Only test case 4("valid string", 5) needs to be kept.

[0085] Classification: Core functional use cases (use cases 3, 4), boundary use cases (use cases 1, 2, 8, 9, 10), and exception use cases (use case 7).

[0086] Additional information: The deduplicated and categorized test case set fully covers all known functionalities, branch conditions, and key boundary values, with no missing scenarios, so there is no need to add new test cases.

[0087] After optimization, the final set of teacher test cases is generated, renumbered, and stored in the storage module.

[0088]

[0089] Students submit their code through the user interface of the student input module, according to the requirements of the question. The code is as follows:

[0090]

[0091] The system calls the student code processing module, first performing a syntax check. If compilation succeeds, it calls the same symbolic execution engine (such as CrossHair) as in step 4 to explore the path of the student code and generate a set of student test cases containing "input parameters + student code output", as follows:

[0092]

[0093] like Figure 6 As shown, the system calls the dual-path verification module to perform two-way verification.

[0094] 1) Output Consistency Verification (Student Input → Teacher Code): First, extract all input parameters from the student test case set and check whether the number of input parameters in each group matches the number of input parameters in the teacher code. If the number does not match, it is judged as a semantic error and feedback is given; if the number matches, these parameters are sequentially input into the correct teacher code for execution to obtain the "actual output of the teacher code". Then, compare this output with the corresponding "student code output" in the student test cases. If a difference is found, it is marked as an "output inconsistency error", and the input parameter that caused the difference is recorded, as follows:

[0095] Extract the input (None, 5) of student use case D, execute the teacher code and get the output "Error: String isNone", which is inconsistent with the output TypeError of the student code, so mark "output inconsistency error";

[0096] 2) Logical Correctness Verification (Teacher Input → Student Code): Execute the student code, running each test input in the teacher's test case set one by one to obtain the corresponding "student output." Compare this output with the teacher's "expected output." If an inconsistency is found, the system will automatically initiate a path tracing mechanism: precisely analyze the execution path of the student code under this input and compare it with the correct path of the teacher's code to accurately locate the root cause of the error. Details are as follows:

[0097] When extracting the input (None, 5) from teacher use case 1 and executing the student code, a TypeError is triggered at the point where s == "" due to a missing check for s is None. This is inconsistent with the expected output "Error: String is None".

[0098] Path tracing: The teacher's code path hit the if s is None branch; the student's code crashed at the first if statement due to a type error, failing to enter any correct logic. The path branch point is the code entry point.

[0099] Extracting the input ("test", -1) from teacher test case 5, the expected output is "Error: Invalid min_len". Executing the student code returns the error "Valid: Meets requirements".

[0100] Path tracing: The teacher's code path hit the `if min_len < 0` branch; the student's code path skipped all `if` statements and reached the final `return` statement. The path divergence point was that the student's code was missing the `if min_len < 0` branch.

[0101] 3) Integrate the two-way verification results, perform path difference analysis based on the symbolic execution tree (which displays the program execution path in a tree structure, with nodes representing branch conditions or statements and leaf nodes representing the path endpoints), generate a deep error report containing the difference inputs, expected outputs, actual outputs, and path divergence points, and feed it back to the student.

[0102] Generate an error report:

[0103]

[0104] The system calls the coverage assessment module to compare the test case sets of teachers and students, calculates path coverage, branch coverage, and scenario coverage respectively, and generates a coverage assessment report, as follows:

[0105] Path coverage: 5 total paths for teachers, 3 paths for students (missing paths for "processing s is None" and "processing illegal min_len<0") → 3 / 5 = 60%;

[0106] Branch coverage: There are 4 branches for teachers and 2 branches for students (missing branches for "s is None" and "min_len < 0") → 2 / 4 = 50%;

[0107] Scenario coverage: Teachers' total scenario coverage is divided into 3 categories (normal, boundary, and abnormal), while students' coverage is divided into 2 categories (missing abnormal scenario where "min_len is an illegal value (negative number)") → 2 / 3≈66.7%;

[0108] Generate a coverage assessment report:

[0109]

[0110] Detailed analysis of missing scenarios:

[0111] Missing branch: if s is None (this leads to a fatal error)

[0112] Missing branch: if min_len < 0 (this leads to a logical error)

[0113] Missing scenario: Abnormal scenario. Your code completely fails to consider how to handle situations where min_len is an illegal value (negative number).

[0114] See Figure 9 The diagram shown is a structural schematic of a programming-assisted teaching interactive system based on large models and symbolic execution according to an embodiment of the present invention, comprising:

[0115] The standard code processing module 901 provides programming questions and corresponding correct code to the teacher; it extracts the functional points and constraint rules of the programming questions based on a large language model; and it performs static analysis on the correct code using an abstract syntax tree analysis tool to obtain static analysis results.

[0116] The test case generation module 902 generates initial seed test cases based on the functional points, constraint rules, and static analysis results. After post-processing verification, a valid test case set is formed. The valid test case set is converted into a format adapted to the symbolic execution engine. Using the correct code as a benchmark, the code path is explored through symbolic execution to generate new test inputs and their corresponding outputs. After deduplication, classification, and supplementation, the final teacher test case set is output. The classification includes normal test cases, boundary test cases, and abnormal test cases. The supplementation is to generate test cases for missing scenarios through a large language model.

[0117] The student code generation module 903 performs syntax checks and compilation on the student code after the student submits the code. After successful compilation, it calls the symbolic execution engine to explore the path of the student code and generate a set of student test cases.

[0118] The dual-path verification module 904 verifies the correctness of the student code through dual paths. On one hand, it executes the correct code with the input from the student test case set and compares the output results. On the other hand, it executes the student code with the input from the teacher test case set, compares the expected output, analyzes the path differences through symbolic execution tree, and generates an error report containing the difference input, expected output, actual output, and path divergence points.

[0119] The coverage evaluation module 905 evaluates the coverage completeness of the student code from three dimensions: path, branch, and scenario, by comparing the teacher test case set with the student test case set. The evaluation dimensions include path coverage, branch coverage, and scenario coverage.

[0120] See Figure 10 The diagram shows a hardware structure of an electronic device provided in an embodiment of the present invention, including a processor 1001 and a memory 1002; wherein the memory 1002 is used to store computer execution instructions; and the processor 1001 is used to execute the computer execution instructions stored in the memory to implement the various steps performed by the electronic device in the above embodiment. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0121] Alternatively, the memory 1002 can be either standalone or integrated with the processor 1001.

[0122] When the memory 1002 is set up independently, the electronic device also includes a bus 1003 for connecting the memory 1002 and the processor 1001.

[0123] In the embodiments provided by this invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0124] The modules described as separate components may or may not be physically separate. The components shown as modules 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 modules can be selected to implement the solution of this embodiment according to actual needs.

[0125] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0126] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0127] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0128] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0129] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0130] The aforementioned storage medium can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0131] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. Both the processor and the storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.

[0132] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A programming-assisted teaching interaction method based on a large model and symbolic execution, characterized in that, The method comprises the following steps: The teacher end provides programming questions and corresponding correct codes; Based on a large language model, the function points and constraint rules of the programming questions are extracted; combined with an abstract syntax tree analysis tool, the correct codes are statically analyzed to obtain static analysis results; Based on the function points, constraint rules and static analysis results, an initial seed case is generated, and after post-processing verification, an effective test case set is formed; the effective test case set is converted into a format suitable for a symbolic execution engine, and the correct codes are used as a benchmark to explore code paths through symbolic execution, generate new test inputs and their corresponding outputs, and after deduplication, classification and supplementation, output the final teacher test case set, the classification including normal cases, boundary cases and abnormal cases; the supplementation is to generate test cases for missing scenarios through a large language model; After the student submits the code, syntax checking and compilation are performed on the student code, and after compilation, a symbolic execution engine is called to explore the path of the student code and generate a student test case set; The correctness of the student code is verified through double-path verification; on the one hand, the input in the student test case set is used to execute the correct code, and the output results are compared; on the other hand, the input in the teacher test case set is used to execute the student code, the expected output is compared, and the path difference is analyzed through a symbolic execution tree to generate an error report containing the difference input, expected output, actual output and path divergence point; By comparing the teacher test case set and the student test case set, the coverage completeness of the student code is evaluated from the path, branch and scene dimensions, including path coverage, branch coverage and scene coverage.

2. The method of claim 1, wherein, The abstract syntax tree analysis tool is a syntax parser adapted to the target programming language, comprising: For Java language, JavaParser is selected, for C / C++ language, Clang AST can be selected, and for Python language, its built-in AST module is selected.

3. The method of claim 1, wherein, The static analysis results include function interfaces, branch conditions and boundary values; the branch conditions include the judgment logic of if, for, while and switch statements in the code, and the boundary values are derived based on the constraint rules and branch conditions, including the extreme value, length boundary and critical value of the input parameter.

4. The method of claim 3, wherein, The post-processing verification includes: Syntax checking, according to the function interfaces, to ensure that the test input conforms to the function call specification; Function coverage checking, comparing the function points to verify that the seed cases cover all function points in the question requirements, if there are uncovered function points, corresponding seed cases are generated by supplementing through a large language model; Logical consistency checking, based on the constraint rules, to filter cases that violate the constraints; Output accuracy verification: by running the correct codes, the correctness of the expected output of each seed case is confirmed, and the cases with inconsistent output are removed.

5. The method of claim 1, wherein, The symbolic execution engine is a path exploration tool capable of analyzing a target programming language, and is adapted according to the target language, including: for C / C++ language, KLEE is selected, for Java language, Symbolic PathFinder is selected, and for Python language, CrossHair based on hybrid execution is selected.

6. The method of claim 1, wherein, The path difference is analyzed through the symbolic execution tree, and an error report including a difference input, an expected output, an actual output and a path divergence point is generated. The symbolic execution tree displays the program execution path in a tree structure, a node represents a branch condition or a statement, and a leaf node represents a path end point.

7. The method of claim 1, wherein the method further comprises: The coverage integrity of the student code is evaluated from three dimensions of path, branch and scene, including path coverage, branch coverage and scene coverage. The path coverage is a ratio of a number of paths covered by the student test case set to a total number of paths of the teacher test case set, the branch coverage is a ratio of a number of branches covered by the student code to a total number of branches of the teacher code, and the scene coverage is a ratio of a number of classified scene covered by the student test case set to a total number of classified scenes of the teacher test case.

8. The method of claim 1, wherein, The path difference analysis of the double-path verification is realized through symbolic execution tree visualization, and the coverage integrity is output in a text and chart form.

9. A large model and symbolic execution based programming assisted teaching interaction system, characterized in that, It comprises: a standard code processing module, a teacher end provides a programming question and a corresponding correct code; a function point and a constraint rule of the programming question are extracted based on a large language model; a static analysis result is obtained by combining an abstract syntax tree analysis tool to perform static analysis on the correct code; a test case generation module generates an initial seed case based on the function point, the constraint rule and the static analysis result, and forms an effective test case set after post-processing verification; the effective test case set is converted into a format suitable for a symbolic execution engine, and a new test input and its corresponding output are generated by exploring a code path through the correct code as a benchmark; after deduplication, classification and supplement, an ultimate teacher test case set is output, the classification includes normal cases, boundary cases and abnormal cases; the supplement is to generate a test case of a missing scene through a large language model; a student code generation module, after a student submits a code, performs syntax checking and compiling on the student code, and after the compiling passes, a symbolic execution engine is called to explore a path of the student code, and a student test case set is generated; a double-path verification module verifies the correctness of the student code through double-path verification; on one hand, the correct code is executed with an input in the student test case set, and output results are compared; on the other hand, the student code is executed with an input in the teacher test case set, expected outputs are compared, and a path difference is analyzed through a symbolic execution tree, and an error report including a difference input, an expected output, an actual output and a path divergence point is generated. The coverage evaluation module evaluates the coverage completeness of the student code from three dimensions of path, branch and scenario by comparing the teacher test case set and the student test case set, including path coverage, branch coverage and scenario coverage.

10. An electronic device, comprising: comprising: one or more processors; a memory device for storing one or more programs; when the one or more programs are executed by the one or more processors, so that the one or more processors implement the method as claimed in any one of claims 1-8.

Images