Teaching experiment step verification method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a teaching experiment step verification method and device, electronic equipment and a storage medium. Obtaining the edited experiment steps and the execution sequence of the experiment steps in all the experiment steps of the teaching experiment document; according to the execution sequence, determining a target environment state of the edited experiment step from a historical environment state set; the historical environment state set comprises environment states which are respectively stored when each experiment step in the teaching experiment document is executed; and switching the current experimental environment to a target environment state, executing the edited experimental steps in the target environment state, and outputting a verification result of the edited experimental steps. Thus, verification is carried out by accurately returning to the corresponding historical environment state according to the execution sequence of the edited experiment steps, the whole experiment process is prevented from being executed from the beginning, and the verification efficiency of the teaching experiment document is improved.

Description

Verification methods, apparatus, electronic devices and storage media for teaching experimental procedures Technical Field

[0001] This invention relates to the field of computer technology, and in particular to methods, apparatus, electronic devices, and storage media for verifying teaching experimental procedures. Background Technology

[0002] With the development of online and experimental teaching, more and more courses require supporting and feasible experimental environments. In the current process of creating teaching experimental courses, teachers usually need to first write a complete teaching experimental document, and then execute the experimental steps in the experimental environment according to the document order to verify the feasibility of the experimental process.

[0003] In traditional verification methods, experimental steps rely on manual execution, requiring teachers to follow the entire experimental procedure from beginning to end to complete verification. When teachers modify specific steps in the experimental documentation, the entire experimental procedure still needs to be re-executed, and verification cannot be synchronized after the documentation is updated, resulting in low verification efficiency for teaching experimental documentation. Summary of the Invention

[0004] In view of this, the embodiments of this application at least provide a method, apparatus, electronic device and storage medium for verifying teaching experiment steps. By accurately reverting to the corresponding historical environment state according to the execution order of the edited experiment steps, the verification is performed, avoiding the need to execute the entire experiment process from the beginning and improving the verification efficiency of teaching experiment documents.

[0005] This application mainly includes the following aspects: Firstly, embodiments of this application provide a method for verifying teaching experimental steps. The method includes: in response to an editing operation on experimental steps in a teaching experimental document, obtaining the edited experimental steps and the execution order of the experimental steps in all experimental steps of the teaching experimental document; determining the target environment state of the edited experimental steps from a historical environment state set according to the execution order; the historical environment state set includes the environment states saved when each experimental step in the teaching experimental document is completed; switching the current experimental environment to the target environment state, executing the edited experimental steps in the target environment state, and outputting the verification result of the edited experimental steps.

[0006] Secondly, embodiments of this application also provide a verification device for teaching experimental steps. The verification device for teaching experimental steps includes: an editing determination module, used to, in response to an editing operation on experimental steps in a teaching experimental document, acquire the edited experimental steps and the execution order of the experimental steps in all experimental steps of the teaching experimental document; an environment selection module, used to, according to the execution order, determine the target environment state of the edited experimental steps from a historical environment state set; the historical environment state set includes the environment states saved when each experimental step in the teaching experimental document is completed; and a verification feedback module, used to switch the current experimental environment to the target environment state, execute the edited experimental steps in the target environment state, and output the verification result of the edited experimental steps.

[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory through the bus, and the machine-readable instructions are executed by the processor to perform the steps of the verification method of the teaching experiment steps as described above.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when run by a processor, performs the steps of the verification method for the teaching experiment steps described above.

[0009] The present application provides a method, apparatus, electronic device, and storage medium for verifying teaching experiment steps. The method includes: in response to an editing operation on an experiment step in a teaching experiment document, obtaining the edited experiment step and its execution order among all experiment steps in the teaching experiment document; determining the target environment state of the edited experiment step from a historical environment state set based on the execution order; the historical environment state set includes the environment states saved when each experiment step in the teaching experiment document is completed; switching the current experimental environment to the target environment state, executing the edited experiment step in the target environment state, and outputting the verification result of the edited experiment step. In this way, by accurately reverting to the corresponding historical environment state based on the execution order of the edited experiment step for verification, the entire experimental process is avoided from being executed from the beginning, thus improving the verification efficiency of teaching experiment documents.

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

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 shows a flowchart of a verification method for a teaching experiment step provided in an embodiment of this application; Figure 2 shows a schematic diagram of a verification system for a teaching experiment step provided in an embodiment of this application; Figure 3 shows one of the functional block diagrams of a verification device for a teaching experiment step provided in an embodiment of this application; Figure 4 shows another functional block diagram of a verification device for a teaching experiment step provided in an embodiment of this application; Figure 5 shows a structural schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0014] To facilitate understanding of this application, the technical solutions provided in this application will be described in detail below with reference to specific embodiments.

[0015] Please refer to Figure 1, which is a flowchart of a method for verifying teaching experiment steps provided in an embodiment of this application. As shown in Figure 1, the method for verifying teaching experiment steps provided in an embodiment of this application includes the following steps: S101, in response to an editing operation on the experiment steps in the teaching experiment document, obtaining the edited experiment steps and the execution order of the experiment steps in all experiment steps of the teaching experiment document.

[0016] Here, teaching experiment documents are course documents written by teachers on the teaching platform. They contain multiple experimental steps arranged in the order of teaching logic. For example, in a Linux command experiment course, the steps may include "creating a directory", "editing a file", "modifying permissions", "running a script", etc.

[0017] This application embodiment integrates a verification system for teaching experiment steps into a teaching platform. Specifically, please refer to Figure 2, which is a schematic diagram of the verification system for teaching experiment steps in this application embodiment. As shown in Figure 2, in order to capture the teacher's editing behavior in real time, the verification system includes a teaching platform editor. This editor is based on an open-source text editor and is developed in a secondary manner. It natively supports multiple formats such as Word, Markdown, and plain text, and natively supports the "text archiving" function, editing state rollback, Markdown syntax, and the OOXML protocol (Open-office-XML protocol, which is the text parsing protocol of office software).

[0018] During development, this application customized the archiving mechanism of the teaching platform editor: Native editors typically cache document content automatically at fixed intervals as an archived version, while this application modifies it to archive at the granularity of each line break or experimental operation instruction step edited by the teacher. Simultaneously, a series of calling interfaces were developed based on the native functionality, including encapsulated interfaces for direct calls to the aforementioned functions, as well as functional extensions according to the needs of the teaching platform. For example, the native function only allows continuous "undo" to revert each cached archived text, or "restore" to restore previously undone content, while the editor in this application has developed a function to record the archive index, so that when the teacher edits at different locations, they can receive backend instructions to switch between different archived versions; furthermore, when the editor switches between different archived states, instead of displaying the text content on the editing page, it obtains the context content of a certain archived state for analysis of the changed content during backend verification.

[0019] In this embodiment, the writing of a teaching experiment document for a Linux command experiment course is used as an example. Assume a teacher opens a Linux command experiment document in the teaching platform editor. The document contains four steps: Step 1 "mkdir test", Step 2 "cd test", Step 3 "cp file1 file2", and Step 4 "ls -l". Now, the teacher changes the command in Step 3 from "cp file1 file2" to "cp -i file1 file2" and presses a newline key. After detecting this editing completion, the teaching platform editor recognizes this as the end of an experiment step, immediately triggers a parsing signal, and simultaneously calls the text archiving function to save the document at the time of editing completion as a new archived version, recording the current archive index and the previous archive index. The editor sends the relevant information of this modification (including the current archive index and the previous archive index) along with the parsing signal to the document parsing module shown in Figure 2. Since each archive index records the differences compared to the previous archive, the document parsing module can obtain the specific content of the current change (including deleted, modified, or added parts) based on these two indexes.

[0020] The document parsing module is used to parse teaching experiment documents written by teachers in the teaching platform editor, identifying and extracting experimental step information, experimental environment specifications, and the location of the most recently edited experimental step. Specifically, after obtaining the changed content, the document parsing module calls the built-in lightweight text analysis engine for parsing. This analysis engine adopts an architecture of "Ollama + lightweight deepseek model (deepseek-coder:6.7b-q4_K_M)," capable of running offline to meet data security requirements, with a runtime resource requirement of approximately 4 cores and 8GB of memory. It requires no training and is ready to use out of the box. After receiving the changed content, the analysis engine is required to parse out the shell command and the operation elements executed in the test environment (where, what preconditions, what operation, the purpose of the operation, the expected result, etc.). If the corresponding content is parsed, it will be output in JSON format to the corresponding fields. For example, the analysis engine parses the command "cp -ifile1 file2" from the changed content and recognizes it as a file copy operation with interactive options. Successful parsing confirms that the change is a valid modification of the experimental step. If the parsing does not detect any changes at the experimental step level (e.g., changes to ordinary text content or explanatory text), the system ignores this change. Through this process, the system obtains the edited experimental step content "cp -i file1 file2" and its execution order (step 3) in all steps of the document.

[0021] S102, according to the execution order, determine the target environment state of the edited experimental step from the historical environment state set; the historical environment state set includes the environment states saved when each experimental step in the teaching experimental document is completed.

[0022] Here, the historical environment state set is a database gradually built during the document writing process, stored by the data module shown in Figure 2. The data module stores the experimental step content and sequence information, the historical editing status information of the teaching document in the editor, the container environment status identifier corresponding to each experimental step, and the experimental environment image version and build layer relationship information. Each historical environment state corresponds to a complete experimental environment snapshot when an experimental step is completed. These snapshots exist in the form of container build layers, recording information such as the file system content, environment variables, and current directory at the time of execution of a specific step. As shown in Figure 2, the experimental step verification strategy module is the core control module of this application, used to coordinate the experimental environment switching and step verification process under experimental step modification scenarios. Based on the location of the most recently modified experimental step identified by the document parsing module, it determines the corresponding experimental verification strategy, including whether to roll back the environment, to which state to roll back to, and which subsequent steps need to be re-verified.

[0023] Among them, the experimental steps verification strategy module needs to solve two core problems: the balance between the accuracy of verification results and the user experience, and how to achieve a one-to-one correspondence between document editing and container verification.

[0024] To balance accuracy and user experience, the experimental step verification strategy module needs to consider the following: If each verification only executes the modified step in the experimental environment, it will only be applicable in the scenario where "teachers add content at the end of the experimental report," because the execution environment state of the newly added step is consistent with the current experimental environment state, and the verification result is valid. However, in the scenario where "teachers modify content in the middle of the experimental report," the modified or added experimental step cannot be run directly, because the running state of this step must be "the state after the previous step has been executed," so the scheduling container needs to switch to that state. Furthermore, if the modification is in the "middle" rather than the "end," it is necessary to consider not only whether the modified content is valid, but also that the execution premise of subsequent steps in the text has changed after the modification, and the original verification result is no longer valid. It is necessary to run the verification again until the end to ensure that not only the modified step's result is satisfactory to the teacher, but the subsequent steps also meet expectations after the modification.

[0025] In this embodiment, the document parsing module passes the parsed edited step (e.g., step 3) and its execution order to the experimental step verification strategy module. The experimental step verification strategy module first determines the position of the step: it is neither the first step (step 1 is the first step) nor added at the end (the document already has 4 steps, step 4 is at the end, and step 3 is being modified), therefore it belongs to the "in-text modification" scenario. Based on the above principle, for in-text modifications, the experimental environment must be reverted to the state when the previous step was completed to accurately verify the modified step. Therefore, the strategy module queries the data module for the container building layer identifier corresponding to the step before step 3 (i.e., step 2). The data module maintains a mapping table that records the container building layer identifier saved when each step is completed; for example, step 1 corresponds to "layer_step1", step 2 corresponds to "layer_step2", step 3 corresponds to "layer_step3", and step 4 corresponds to "layer_step4". The strategy module finds the corresponding building layer identifier "layer_step2" based on step 2, which points to the environment state saved when step 2 was completed. The strategy module determines the target environment state as the state corresponding to the build layer and generates a switching instruction containing the build layer identifier "layer_step2", which is ready to be sent to the container scheduling module.

[0026] S103, switch the current experimental environment to the target environment state, execute the edited experimental steps in the target environment state, and output the verification results of the edited experimental steps.

[0027] Here, the current experimental environment refers to the container instance currently running on the system, managed by the container scheduling module. As shown in Figure 2, the container scheduling module manages the container environment according to the scheduling instructions issued by the experimental step verification strategy module, including: pulling or preparing the container image required for the experiment; executing the experimental steps issued by the experimental step verification strategy module in the corresponding container environment; saving the corresponding experimental environment state as an independent container build layer after each experimental step is completed; performing state rollback or state switching between different container build layers according to the instructions of the experimental step verification strategy module; feeding back the execution results and output information of the step instructions to the experimental step verification strategy module; and cleaning up intermediate temporary files such as container build layers generated during the course writing process after the course document has been finalized. The container engine natively provides a version management mechanism, that is, building a new image version from a base image version, or creating a container environment from an image version, and submitting the current container environment as a new version of an image. The two images have relatively independent image version management, while the same image version, during the build process, is divided into build layers according to the build command executed and the source of the initial image. Each build layer stores the file system difference information between the build layers of two adjacent versions. In this way, a container or image iterates from a base image version by continuously adding multiple build layers to reach the current image state. This allows for customized development of the container engine, ensuring that each build layer commit represents the execution result of a step, and each image version save represents the result of a continuous editing process. This enables jumping to any build layer state within a container or different versions of the same image, corresponding to the state of any experimental step's execution result.

[0028] In this embodiment, it is assumed that the experimental step verification strategy module sends a switching instruction containing "layer_step2" to the container scheduling module. The container scheduling module calls the container interface to create a new container instance based on the image corresponding to the build layer identifier "layer_step2", thereby accurately restoring the current experimental environment to the state immediately after step 2 is executed. For example, step 2 is "cd test", so the current directory in the restored environment is " / test", and the "test" directory created in step 1 and other possible files exist. Next, the container scheduling module executes the edited step 3 command "cp -i file1 file2" in the container instance. During execution, the container scheduling module captures the standard output, error output, and return code of the command, using this information as the verification result. For example, if the standard output is empty, the error output is empty, and the return code is 0 after execution, it indicates successful execution. The scheduling module returns these results to the experimental step verification strategy module, which then forwards them to the result presentation module. As shown in Figure 2, the results presentation module is responsible for providing real-time feedback of the execution results of each experimental step to the document editing interface of the teaching platform editor, for teachers to refer to when writing experimental documents. In this embodiment, the results presentation module pops up a prompt box next to step 3 in the editor, displaying "Verification successful (return code 0)" and highlighting the step with a green background, while also displaying the output information below. Teachers can immediately see that the modified commands have been executed correctly, without needing to manually set up the environment or run the entire experiment from scratch.

[0029] Furthermore, the historical environment state set is generated in the following way: Step a1, during the writing of the teaching experiment document, whenever an experiment step is completed, the current experiment environment after the completion of the experiment step is saved as a container construction layer, and a correspondence between the container construction layer and the experiment step is established; wherein, the container construction layer records the data changes between the environment state when the previous experiment step was completed and the environment state when the current experiment step was completed.

[0030] Here, data changes refer to all changes in the environment between two adjacent steps, including the addition, modification, and deletion of files, changes to environment variables, and changes to the current directory. The container build layer stores these changes incrementally, allowing multiple build layers to be stacked to form a complete image history. After each step is executed, the container scheduling module automatically submits the current container as a new build layer and records the correspondence between that layer and the step; the data module is responsible for persisting this information. This allows for customized development of the container engine, ensuring that each build layer submission represents the execution result of a step, and each image version save represents the result of a continuous editing process. Since saving in a text editor clears the cache and archived information, we need to save the archived information, organized by experimental step, to the database and record the index. We then store the index of the build layer representing the execution result of that step within the container together, so that other modules can easily query and schedule it. Therefore, taking the business perspective of experimental procedure verification as the main thread, one end customizes the document editing logic to obtain the teacher's modifications to the experimental procedures, whether to save the cache, undo, and restore, etc., and the other end, based on the modification scenario, issues a strategy to the container scheduling module to jump the experimental environment to the version state of the corresponding container build layer, as well as whether to verify and save the build layer as a separate image version. In this way, the archiving mechanism of the text editor and the version control mechanism of the container engine are integrated with the implementation logic of the teacher's editing and verification of experimental procedures.

[0031] In this embodiment, the system has already gradually built a set of historical environment states while the teacher is writing documentation and verifying steps. For example, after the teacher writes step 1 "mkdir test" and executes it successfully in the verification environment, the container scheduling module submits the completed environment as a new container build layer, saves it as "layer_step1", and records the corresponding "layer_step1" for step 1. This build layer records the data changes from the initial environment to the step 1 state, such as the addition of the "test" directory. Subsequently, the teacher writes and verifies step 2 "cd test". After successful execution, the scheduling module submits the current environment as "layer_step2" and records the corresponding "layer_step2" for step 2. The build layer for step 2 records the changes from the step 1 state to the step 2 state, such as the current directory changing from the root directory to " / test". This continues, saving "layer_step3" after step 3 verification and "layer_step4" after step 4 verification. Each build layer records the data changes from the previous state to the current state, and each build layer is associated with the corresponding experimental step. The data module organizes and stores these building layers in the order of execution, forming a complete set of historical environment states.

[0032] Step a2: Store the container construction layer corresponding to each experimental step according to the execution order of the experimental steps in the teaching experimental document to obtain the historical environment state set.

[0033] Here, storage not only preserves the build layers themselves but also maintains an index table that associates the step order with build layer identifiers for fast retrieval. The data module uses a relational database or object storage to manage this data. This sequential storage method corresponds to the archiving mechanism of a text editor (each edit corresponds to an archive index), achieving a one-to-one correspondence between document editing and container verification. When it is necessary to revert to the state of a certain step, the strategy module only needs to look up the corresponding build layer identifier in the table according to the step order.

[0034] In this embodiment of the application, a mapping table is maintained in the data module, for example: Step 1 → layer_step1; Step 2 → layer_step2; Step 3 → layer_step3; Step 4 → layer_step4.

[0035] When it is necessary to roll back to the second step state, the strategy module only needs to look up "layer_step2" in the table based on step 2. This sequential storage method allows the system to quickly locate the environment state corresponding to any step according to the execution order, providing a data foundation for subsequent rapid rollback.

[0036] Further, determining the target environment state of the edited experimental step from the historical environment state set according to the execution order includes: step b1, if the execution order is the first experimental step, then the preset initial environment state is determined as the target environment state.

[0037] Here, the first experimental step refers to the first experimental step in the document. There are no other steps preceding the first step, so there is no "previous state" to roll back from. The initial environment state is a pre-prepared basic experimental environment image, such as an empty container containing a basic operating system and tools, typically existing as a base image.

[0038] In this embodiment, assume the teacher modifies step 1 of the document, changing "mkdir test" to "mkdirmydir". Since step 1 is the first step, the policy module directly determines the preset initial environment state (such as the "ubuntu:20.04" base image) as the target environment state. Subsequent execution will start from this initial environment to ensure the accuracy of the verification. This rule also applies if the teacher adds a new step as the first step.

[0039] Step b2: If the execution order is not the first experimental step and is not a newly added experimental step at the end of the teaching experimental document, then the historical environment state corresponding to the experimental step that precedes the edited experimental step in the execution order is determined as the target environment state.

[0040] Here, editing operations that are neither the first nor the last added include two cases: modifying an existing intermediate step in the document, or inserting a new step in the middle of the document. Both cases require reverting to the previous state because the new or modified step must be executed based on the preceding steps. For example, if step 3 is modified, you need to revert to step 2; if a new step is added between steps 2 and 3, that new step also needs to be executed after step 2.

[0041] In this embodiment, if the teacher modifies step 3 (the document already has 5 steps), the strategy module determines "layer_step2" corresponding to step 2 as the target environment state. If the teacher adds a step between steps 2 and 3, the system will renumber the steps; the original step 3 becomes step 4, and the added step becomes the new step 3. In this case, the strategy module will also use the state corresponding to step 2 as the target environment state, because the added step needs to be executed after step 2. This rule ensures that any edits that are not at the end can be verified on the correct environment basis.

[0042] Step b3: If the editing operation is to add a new experimental step at the end of the teaching experiment document, then the current experimental environment is determined as the target environment state.

[0043] Adding a new step at the end is the simplest scenario because the current experimental environment is the state after the previous step has been completed, making it perfect for executing the last new step without needing to roll back. For example, if the document originally had 5 steps, and the current environment is the state after step 5 has been completed, adding a 6th step can be done directly in the current environment.

[0044] In this embodiment, if the teacher adds a sixth step at the end of the document (e.g., the original document has 5 steps), the current experimental environment is the state after the fifth step has been completed. The strategy module directly determines this current environment as the target environment state, and the container scheduling module does not need to switch and immediately executes the newly added sixth step. This is both fast and accurate, avoiding unnecessary environment switching overhead.

[0045] Furthermore, the method also includes: step c1, after the edited experimental step is completed, outputting the verification result of the edited experimental step, and providing the option to verify subsequent experimental steps.

[0046] Here, for text modifications, after the modification step itself passes verification, it's necessary to consider the impact of the modification on subsequent steps. If the modification is in the "middle" rather than the "end," it's not only necessary to consider whether the modified content is effective, but also that the execution premise of subsequent steps in the text has changed after the modification, and the original verification result is no longer valid. It's necessary to run the process again until the end to ensure that not only is the result of the modified step satisfactory to the teacher, but the subsequent steps also meet expectations. However, to avoid disrupting the teacher's editing rhythm and to prevent waiting caused by automatically executing a large number of subsequent steps with each modification, the system does not automatically execute all subsequent steps. Instead, an interactive option allows the teacher to decide whether to immediately verify the subsequent impact. This design balances verification accuracy and user experience. The ideal scenario of "verifying only one step to quickly provide user feedback" is very limited, and while the verification of subsequent steps is not a full-text step verification, the time consumed increases with the number of remaining steps after the modification. To address this, we added an "Add to Text" button to the "In-Text Editing" scenario. This allows teachers to click the button after modifying the steps and receiving real-time verification results for those steps. This then triggers a check of subsequent steps in the original text based on that modified step. The purpose of this button is to preserve the user experience of "real-time step verification" and to separate the impact of modifications on the overall experiment into a separate process.

[0047] In this embodiment, after the teacher modifies step 3 and receives successful verification, the result presentation module displays the verification result of step 3 in the editor interface, and a prompt box pops up: "Step 3 verification successful. Do you want to verify the impact of subsequent steps (steps 4-5)?" Below are "Yes" and "No" buttons. The teacher can choose as needed. If the teacher clicks "Yes," the system will execute the verification of subsequent steps; if the teacher clicks "No," verification will not be performed temporarily, and the teacher can continue editing other steps.

[0048] Step c2, in response to the user's selection to verify subsequent experimental steps, retrieve the experimental steps whose execution order is after the edited experimental step and which have not been edited in the current experimental environment.

[0049] Here, after the user selects "Yes," the system needs to collect all subsequent steps that require verification. These steps are those in the document that follow the edited step and have not yet been edited (i.e., the content has not changed). If any subsequent steps are being edited but not yet completed, they may need to be excluded or handled specially, but in the basic scenario, the steps are usually stable.

[0050] In this embodiment, when the teacher clicks "Yes," the system responds by retrieving all steps in the document with an execution order greater than 3 from the data module, namely steps 4 and 5. Simultaneously, it checks whether these steps have been edited but not yet saved (e.g., whether they are in continuous editing mode). It confirms that steps 4 and 5 have not been edited; therefore, the list of steps to be verified is: steps 4 and 5.

[0051] Step c3: In the current experimental environment, execute each experimental step in the order of execution and output the verification result of each experimental step.

[0052] Here, the verification of subsequent steps is carried out continuously in the same environment after the modification steps are completed. This ensures that the impact of the modifications on subsequent steps is accurately reflected. Verification results are output immediately after each step, allowing teachers to see the real-time effect of the modifications on subsequent steps.

[0053] In this embodiment, the container scheduling module executes steps 4 and 5 sequentially in the environment after step 3 is completed. Step 4 was originally "ls -l", which outputs a list of files; step 5 was originally "cat file2", which outputs the file content. After each step, the result presentation module displays the result in real-time at the corresponding location in the document. For example, step 4 outputs "-rw-r--r-- 1 user user 0 Feb 28 10:00 file2", and step 5 outputs nothing (because file2 is empty). Teachers can see that after modifying step 3, subsequent steps still succeed, thus reassuring them to confirm the changes. If a step fails, the teacher can immediately see the failure information and adjust the content accordingly.

[0054] Furthermore, the method also includes: step d1, when multiple consecutive editing operations on experimental steps are detected, and the user is not triggered to select and verify subsequent experimental steps after each editing, and there are no unedited experimental steps between the experimental steps targeted by two adjacent editing operations, the experimental steps that have been edited multiple times are temporarily stored as an editing batch.

[0055] Here, considering that teachers may need to modify the steps of a section of the original text as a whole and verify them as a test unit, this scenario involves modifying not "one step" but "several consecutive steps." If triggering the verification of a single step only allows users to choose whether to verify subsequent steps, it wouldn't be suitable for this scenario. A modification strategy—continuous step modification—needs to be introduced. That is, when the user doesn't click the "verify subsequent steps" button but continues editing, the step verification strategy module detects that: 1. The preceding steps lack complete verification in the following text; 2. The parsing module has new steps that need verification; 3. The two modified sections do not contain any unmodified old steps from the text. If these three conditions are met, the module will enter continuous step modification mode. At this point, the module never executes the modification that "affects verification from subsequent steps," continuously verifying the modified steps and providing feedback. Although it's no longer a single-step verification, the performance overhead remains relatively small. This consideration balances the completeness of the experimental step logic with the principle of minimizing verification steps. It can be viewed as a single-step modification verification, representing the minimum scenario for continuous step modification. After deeply considering the scenario of "continuous modification" in the "in-text modification" section, a new scenario arises: a series of "continuous in-text modification" steps. Even after clicking the verification button for the next step, the result may not be satisfactory, requiring further modification until it is complete before confidently saving the changes to the experimental document for further editing elsewhere. In this case, we provide a "Confirm Modification" button. The purpose of this button is to confirm and save the content of this series of modifications to the document, marking the end of one "continuous in-text modification" process. It also informs the verification module that this content will be used as new "original text content" for the verification steps.

[0056] In this embodiment, the teacher intends to make consecutive overall modifications to steps 5, 6, and 7. First, the teacher modifies step 5, changing the command from "echo hello>file5" to "echo world>file5", but does not click the subsequent verification button after the modification. Next, the teacher modifies step 6, changing the command from "cat file5" to "cat file5 file6", again without clicking the subsequent verification button. Then, the teacher modifies step 7, changing the command from "wc -l file5" to "wc -l file6". The system detects that: the three editing operations occur consecutively; after each edit, the user does not trigger the operation to select and verify subsequent experimental steps; and there are no unedited experimental steps between the experimental steps targeted by adjacent editing operations (steps 5 and 6, and steps 6 and 7) (e.g., step 6 was not skipped). After these three conditions are met, the system determines that it has entered the continuous step modification mode, temporarily storing the modifications to steps 5, 6, and 7 as an editing batch in the cache, without writing them to the official document. At this point, the document still displays the version before modification (step 5 "echo hello>file5", etc.), but the modified content is saved in the cache.

[0057] Step d2: In the current experimental environment, execute each experimental step in the editing batch in sequence, output the verification result of each experimental step, and provide the option to write the editing batch into the teaching experimental document.

[0058] Here, after the batch is temporarily saved, the system first verifies the steps within that batch, allowing teachers to see the overall effect of the changes. Then, the teachers decide whether to officially apply the changes. This way, teachers can decide to write the changes into the document only after confirming they are satisfied with the overall effect.

[0059] In this embodiment, after step 7 is completed, the system automatically executes steps 5, 6, and 7 of the batch sequentially in the current experimental environment (note that the modified content is executed). Execution results: Step 5 succeeds (creating file5 containing "world"), Step 6 succeeds (outputting "world" and the content of file6, but file6 may not exist, causing partial failure), Step 7 fails (because file6 does not exist, the wc command reports an error). The results presentation module displays the results of the three steps on the interface: Step 5 is green for success, Step 6 is yellow for warning, and Step 7 is red for failure. A prompt box pops up: "Batch verification complete: 1 success, 1 warning, 1 failure. Write the continuously modified steps to the document?" and provides "Confirm Modification" and "Continue Editing" buttons. If the teacher sees that Step 7 failed, they can choose to continue editing Step 7, modifying it to "wc -l file5" or other commands. The system will continue processing the new edits in continuous modification mode.

[0060] Step d3: In response to the user's selection to write the edit batch to the teaching experiment document, the edit batch is written to the teaching experiment document.

[0061] Here, after the user clicks "Confirm Changes," the system officially writes the cached batch content into the document, updating the document content. This "Confirm Changes" button design clearly lets users know when the changes will be finalized.

[0062] In this embodiment, after the teacher modifies step 7 to "wc -l file5", the batch verification is performed again, and this time all three steps succeed. The teacher clicks the "Confirm Modification" button, and the system responds by writing the cached content of steps 5, 6, and 7 into the teaching experiment document, updating the document content to the modified version. Simultaneously, the archive indexes corresponding to these steps in the data module are also updated accordingly, and the modifications to these steps officially take effect.

[0063] Step d4: Starting from the edited batch, execute the subsequent unedited experimental steps in the order of execution, and output the verification results of each experimental step.

[0064] Here, after the batch is officially written, the system needs to verify the impact of this batch of changes on subsequent steps. Therefore, subsequent steps are executed starting from the batch. This ensures that the impact of the changes on the entire experimental process is fully evaluated.

[0065] In this embodiment, after the batch write, the original step 8 and subsequent steps in the document remain unchanged (assuming the document has a total of 10 steps). Starting from step 8, the system sequentially executes all subsequent steps (steps 8, 9, and 10) in the current experimental environment and outputs the verification result of each step. For example, if step 8 succeeds, step 9 succeeds, and step 10 fails, the teacher can see that the failure of step 10 may be related to the batch modification (e.g., the batch modification changed the file content, causing changes in the data that step 10 depends on), and thus make further adjustments.

[0066] Furthermore, the method also includes: step e1, comparing the verification result of the edited experimental step with the preset expected verification result.

[0067] Here, for experimental courses, the correctness of each experimental step depends on the teacher's course arrangement. Sometimes, it's necessary to set up an incorrect execution process to demonstrate the course content to students. Therefore, it's necessary to simultaneously verify the execution results of experimental steps when writing the course and provide feedback to the teacher to determine if the step meets the teacher's expectations. This expected execution result is the sole criterion for judging whether the experimental step's result is normal. The data module pre-stores the expected verification results for each experimental step, including expected return codes, expected outputs, and other information. These expected results can be saved by the teacher when the verification is successful, or updated after the teacher accepts unexpected results.

[0068] In this embodiment, for step 3 "cp -i file1 file2", the expected verification result stored in the data module is "return code: 0, output: none". After actual execution, the return code is 0 and the output is empty, therefore the comparison results are consistent. If the actual return code is 1, the comparison will be inconsistent.

[0069] Step e2: If the comparison is inconsistent, a mark is added when outputting the verification result of the edited experimental step, and an option to accept the verification result is provided.

[0070] Here, when discrepancies are found, the system does not directly classify it as an error. Instead, it highlights the error (e.g., in red) to alert the teacher, allowing them to decide whether to accept the result—because some experimental steps are designed to demonstrate errors. For these anomalies, the teacher is prompted to confirm whether to accept the result. If "accept" is clicked, it means the result of this step is what the teacher expected. When the result is normal, or has already been "accepted," the system does not prompt the teacher for confirmation, thus improving the teacher's editing experience.

[0071] In this embodiment, it is assumed that the actual return code of step 3 is 1, which is inconsistent with the expected 0. When outputting the verification result, the result presentation module displays the word "failure" in red and shows the error message "cp: target 'file2' is not a directory". At the same time, an "Accept this result" button appears next to the result. If the teacher's intention is to show this error scenario to students (for example, the teaching purpose is to demonstrate error handling), the teacher can click "Accept".

[0072] Step e3: In response to the user's choice to accept the verification result, update the verification result to the expected verification result of the edited experimental step.

[0073] Here, upon acceptance, the system stores the current actual result as the new expectation for that step, and subsequent comparisons will be based on this new expectation. Thus, when an experimental step has been saved from the document editing cache, the database records not only the document archive index and the verification container version index corresponding to that experimental step, but also the commands executed and their execution status. This execution status will be verified during the teacher's editing process, checking its impact on subsequent steps and the final full-text verification of the saved course. The verification standard is whether the execution command result of a particular experimental step matches the previously saved execution result when all experimental steps are executed.

[0074] In this embodiment, when the teacher clicks "Accept this result," the system responds and updates the expected verification result of step 3 to "Return code: 1, Error message: cp: target 'file2' is not a directory." Subsequently, in subsequent verification steps or final version verification, the expected result of step 3 becomes this failure. If subsequent verification finds that step 3 was executed successfully (return code 0), an inconsistency will be indicated because the expectation has already failed.

[0075] Furthermore, the method also includes: step f1, in response to the finalization operation of the teaching experiment document, obtaining the initial environmental state of the teaching experiment document and all experimental steps of the teaching experiment document.

[0076] Here, the finalization operation is triggered when the teacher has completed all edits and is ready to publish the document as a formal course. The system needs to perform a complete final verification to ensure that the entire experimental process can be executed correctly from beginning to end. When the teacher completes the finalization of the course steps, the overall course steps are finally verified, and the course document and the initial verification environment are arranged into a course and submitted to the teaching platform. All temporary data, temporary build layers, or container images generated during editing are also cleaned up.

[0077] In this embodiment, after completing all editing, the teacher clicks the "Final" button on the teaching platform editor. In response, the system retrieves the document's initial environment state identifier (e.g., the base image ID "ubuntu:20.04") and a list of all experimental steps in the document from the data module, arranged in execution order: step 1 to step N.

[0078] Step f2: Starting from the initial environment state, execute all the experimental steps in the order of execution to obtain the verification result of each step, and compare the verification result of each step with the corresponding expected verification result.

[0079] Here, the final verification involves executing all steps completely from the initial environment, comparing the actual result of each step with the stored expected result. Simultaneously, the system starts a process monitoring tool to listen to the return code and output of each command's child processes, ensuring consistency with expectations. The specific detection steps include: the container uses a process management tool, monitoring the current shell environment process as the root node, and continuously executing the experimental steps starting from the initial verification environment state. The process management tool can detect each executed command in the current shell process (the return status code and ID of the child process); after executing each experimental step command, it checks whether the process's return value matches the return value written during verification (because 0 is the default normal return value in Linux systems, but some experimental steps may be intentionally constructed by the instructor to cause execution failures, which have been confirmed in the written feedback results); otherwise, execution stops and the return information is recorded. The output and error information for each experimental step are printed in the feedback information bar and the log file. After the last step is completed, if there are continuously running processes, the executable program names and process IDs of all continuously running processes are summarized and printed in the feedback information. The above detection steps only use whether the return value of a certain step is consistent with the return value when the verification was written (i.e., whether the expected result of the execution of this step is consistent with the expectation that the teacher verified and passed when the document was written) as the condition to stop the verification process. If the experimental steps can be successfully executed to the end, the feedback information will be displayed to the user before the container is built, and the process will continue after confirmation.

[0080] In this embodiment, the container scheduling module creates a container from the initial environment (such as a base Ubuntu image) and then executes steps 1 through N sequentially. At each step, the return code and output are recorded and compared with the expected verification result for that step in the data module. For example, step 1 might have an expected return code of 0, but the actual return code is 0; step 2 might have an expected return code of 0, but the actual return code is 0; step 3 might have an expected return code of 1 (because a previous failure was accepted), but the actual return code is 1; step 4 might have an expected return code of 0, but the actual return code is 0. If the return code of a step does not match the expectation, for example, step 5 might have an expected return code of 0, but the actual return code is 1, the system immediately stops and displays "Step 5 verification failed: expected return code 0, actual return code 1" in the feedback information bar, along with an error message. Teachers can revise the document based on the prompts and finalize it again.

[0081] Step f3: If all comparisons are consistent, then the teaching experiment document is associated with the initial environment state and stored as an experiment course, and all temporary environment states generated during the verification process are deleted.

[0082] Here, after all comparisons confirm consistency, the system packages the documents and initial environment into the official course and cleans up temporary build layers, temporary images, etc., generated during the editing process, releasing resources. The cleanup includes all intermediate temporary files, images, build layers, etc., generated during the editing and verification of this course.

[0083] In this embodiment, after all steps are verified, the system associates the teaching experiment documents with the initial environment state ID "ubuntu:20.04", generates an experiment course package, and submits it to the course library of the teaching platform. Subsequently, the system calls the cleanup interface to delete all previously saved temporary container build layers (such as layer_step1 to layer_stepN) corresponding to the steps, as well as any intermediate image files that may have been generated. Finally, the course is successfully published without any redundant data residue.

[0084] This application provides a method for verifying teaching experiment steps, comprising: in response to an editing operation on an experiment step in a teaching experiment document, obtaining the edited experiment step and the execution order of the experiment step among all experiment steps in the teaching experiment document; determining the target environment state of the edited experiment step from a historical environment state set according to the execution order; the historical environment state set includes the environment states saved when each experiment step in the teaching experiment document is completed; switching the current experimental environment to the target environment state, executing the edited experiment step in the target environment state, and outputting the verification result of the edited experiment step. In this way, by accurately reverting to the corresponding historical environment state according to the execution order of the edited experiment step for verification, the entire experimental process is avoided from being executed from the beginning, thus improving the verification efficiency of teaching experiment documents.

[0085] Based on the same application concept, this application also provides a verification device for teaching experiment steps corresponding to the verification method for teaching experiment steps provided in the above embodiments. Since the principle of the device in this application for solving the problem is similar to the verification method for teaching experiment steps in the above embodiments of this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0086] Please refer to Figure 3, which is one of the functional block diagrams of a verification device for teaching experiment steps provided in an embodiment of this application. As shown in Figure 3, the verification device 300 for teaching experiment steps includes: an editing determination module 310, used to obtain the edited experimental steps and the execution order of the experimental steps in all experimental steps of the teaching experiment document in response to an editing operation on the experimental steps in the teaching experiment document.

[0087] The environment selection module 320 is used to determine the target environment state of the edited experimental step from the historical environment state set according to the execution order; the historical environment state set includes the environment states saved when each experimental step in the teaching experimental document is completed.

[0088] The verification feedback module 330 is used to switch the current experimental environment to the target environment state, execute the edited experimental steps in the target environment state, and output the verification results of the edited experimental steps.

[0089] Furthermore, the environment selection module 320 is also used to generate the historical environment state set in the following manner: during the writing process of the teaching experiment document, whenever an experimental step is completed, the current experimental environment after the completion of the experimental step is saved as a container construction layer, and a correspondence between the container construction layer and the experimental step is established; wherein, the container construction layer records the data changes from the environment state when the previous experimental step was completed to the environment state when the current experimental step was completed; according to the execution order of the experimental steps in the teaching experiment document, the container construction layers corresponding to each experimental step are stored to obtain the historical environment state set.

[0090] Furthermore, when the environment selection module 320 determines the target environment state of the edited experimental step from the historical environment state set according to the execution order, the environment selection module 320 is specifically used as follows: if the execution order is the first experimental step, then the preset initial environment state is determined as the target environment state; if the execution order is not the first experimental step and is not a newly added experimental step at the end of the teaching experimental document, then the historical environment state corresponding to the experimental step preceding the edited experimental step in the execution order is determined as the target environment state; if the editing operation is a newly added experimental step at the end of the teaching experimental document, then the current experimental environment is determined as the target environment state.

[0091] Furthermore, the verification feedback module 330 is also configured to: after the edited experimental step is completed, output the verification result of the edited experimental step and provide an option to verify subsequent experimental steps; in response to the user's option to verify subsequent experimental steps, obtain each experimental step whose execution order is after the edited experimental step and which has not been edited in the current experimental environment; in the current experimental environment, execute each experimental step in the order of execution and output the verification result of each experimental step.

[0092] Furthermore, the verification feedback module 330 is also configured to: when multiple consecutive editing operations on experimental steps are detected, and no user selection to verify subsequent experimental steps is triggered after each editing, and there are no unedited experimental steps between the experimental steps targeted by two adjacent editing operations, temporarily store the multiple consecutively edited experimental steps as an editing batch; execute each experimental step in the editing batch sequentially in the current experimental environment, output the verification result of each experimental step, and provide an option to write the editing batch into the teaching experimental document; in response to the user's selection to write the editing batch into the teaching experimental document, write the editing batch into the teaching experimental document; starting from the editing batch, execute the subsequent unedited experimental steps sequentially according to the execution order, and output the verification result of each experimental step.

[0093] Furthermore, the verification feedback module 330 is also used to: compare the verification result of the edited experimental step with the preset expected verification result; if the comparison is inconsistent, add a mark when outputting the verification result of the edited experimental step, and provide an option to accept the verification result; in response to the user's operation of accepting the verification result, update the verification result to the expected verification result of the edited experimental step.

[0094] Further, please refer to Figure 4, which is a second functional block diagram of a verification device for teaching experiment steps provided in an embodiment of this application. As shown in Figure 4, the verification of teaching experiment steps 300 further includes: a document finalization module 340, used to obtain the initial environmental state of the teaching experiment document and all the experimental steps of the teaching experiment document in response to the finalization operation of the teaching experiment document.

[0095] The comprehensive verification module 350 is used to execute all the experimental steps sequentially according to the execution order, starting from the initial environment state, to obtain the verification result of each step, and to compare the verification result of each step with the corresponding expected verification result.

[0096] The course generation module 360 ​​is used to associate and store the teaching experiment document with the initial environment state as an experiment course if all comparisons are consistent, and to delete all temporary environment states generated during the verification process.

[0097] This application provides a verification device for teaching experiment steps, comprising: an editing determination module, used to respond to editing operations on experimental steps in a teaching experiment document, and to obtain the edited experimental steps and the execution order of the experimental steps in all experimental steps of the teaching experiment document; an environment selection module, used to determine the target environment state of the edited experimental steps from a historical environment state set according to the execution order; the historical environment state set includes the environment states saved when each experimental step in the teaching experiment document is completed; and a verification feedback module, used to switch the current experimental environment to the target environment state, execute the edited experimental steps in the target environment state, and output the verification result of the edited experimental steps. In this way, by accurately reverting to the corresponding historical environment state according to the execution order of the edited experimental steps for verification, the entire experimental process is avoided from being executed from the beginning, thus improving the verification efficiency of teaching experiment documents.

[0098] Based on the same application concept, please refer to Figure 5, which is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. As shown in Figure 5, the electronic device 500 includes: a processor 510, a memory 520, and a bus 530.

[0099] The memory 520 stores machine-readable instructions executable by the processor 510. When the electronic device 500 is running, the processor 510 and the memory 520 communicate through the bus 530. When the machine-readable instructions are run by the processor 510, they execute the steps of the verification method of the teaching experiment steps provided in the above embodiment. For specific implementation, please refer to the method embodiment, which will not be repeated here.

[0100] Based on the same concept, this application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it executes the steps of the verification method for the teaching experiment steps provided in the above embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0101] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0102] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus 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. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0103] 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.

[0104] In addition, the functional units in the embodiments provided in 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.

[0105] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they 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 a portion 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0107] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application 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, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; 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 this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for verifying teaching experimental procedures, characterized in that, The method includes: in response to an editing operation on experimental steps in a teaching experiment document, obtaining the edited experimental steps and the execution order of the experimental steps in all experimental steps of the teaching experiment document; determining the target environment state of the edited experimental steps from a historical environment state set according to the execution order; the historical environment state set includes the environment states saved when each experimental step in the teaching experiment document is completed; switching the current experimental environment to the target environment state, executing the edited experimental steps in the target environment state, and outputting the verification result of the edited experimental steps.

2. The verification method for the teaching experiment steps according to claim 1, characterized in that, The historical environment state set is generated in the following way: during the writing of the teaching experiment document, whenever an experimental step is completed, the current experimental environment after the completion of the experimental step is saved as a container construction layer, and a correspondence between the container construction layer and the experimental step is established; wherein, the container construction layer records the data changes from the environment state when the previous experimental step was completed to the environment state when the current experimental step was completed; according to the execution order of the experimental steps in the teaching experiment document, the container construction layer corresponding to each experimental step is stored to obtain the historical environment state set.

3. The verification method for the teaching experiment steps according to claim 1, characterized in that, The step of determining the target environment state of the edited experimental step from the historical environment state set according to the execution order includes: if the execution order is the first experimental step, then the preset initial environment state is determined as the target environment state; if the execution order is not the first experimental step and is not a newly added experimental step at the end of the teaching experimental document, then the historical environment state corresponding to the experimental step preceding the edited experimental step in the execution order is determined as the target environment state; if the editing operation is a newly added experimental step at the end of the teaching experimental document, then the current experimental environment is determined as the target environment state.

4. The verification method for the teaching experiment steps according to claim 1, characterized in that, The method further includes: after the edited experimental step is completed, outputting the verification result of the edited experimental step and providing an option to verify subsequent experimental steps; in response to the user's option to verify subsequent experimental steps, obtaining each experimental step whose execution order is after the edited experimental step and which has not been edited in the current experimental environment; in the current experimental environment, executing each experimental step in the execution order and outputting the verification result of each experimental step.

5. The verification method for the teaching experiment steps according to claim 4, characterized in that, The method further includes: when multiple consecutive editing operations on experimental steps are detected, and no user selection to verify subsequent experimental steps is triggered after each editing, and there are no unedited experimental steps between the experimental steps targeted by two adjacent editing operations, the multiple consecutively edited experimental steps are temporarily stored as an editing batch; each experimental step in the editing batch is executed sequentially in the current experimental environment, the verification result of each experimental step is output, and an option to write the editing batch into the teaching experimental document is provided; in response to the user's selection to write the editing batch into the teaching experimental document, the editing batch is written into the teaching experimental document; starting from the editing batch, subsequent unedited experimental steps are executed sequentially according to the execution order, and the verification result of each experimental step is output.

6. The verification method for the teaching experiment steps according to claim 1, characterized in that, The method further includes: comparing the verification result of the edited experimental step with a preset expected verification result; if the comparison is inconsistent, adding a mark when outputting the verification result of the edited experimental step, and providing an option to accept the verification result; in response to the user's operation of accepting the verification result, updating the verification result to the expected verification result of the edited experimental step.

7. The verification method for the teaching experiment steps according to claim 6, characterized in that, The method further includes: in response to the finalization operation of the teaching experiment document, obtaining the initial environment state of the teaching experiment document and all experimental steps of the teaching experiment document; starting from the initial environment state, executing all experimental steps in the execution order to obtain the verification result of each step, and comparing the verification result of each step with the corresponding expected verification result; if all comparisons are consistent, then associating the teaching experiment document with the initial environment state and storing it as an experimental course, and deleting all temporary environment states generated during the verification process.

8. A verification device for teaching experimental procedures, characterized in that, The verification device for the teaching experiment steps includes: an editing determination module, used to respond to an editing operation on the experiment steps in the teaching experiment document, and to obtain the edited experiment steps and the execution order of the experiment steps in all experiment steps in the teaching experiment document; an environment selection module, used to determine the target environment state of the edited experiment steps from a set of historical environment states according to the execution order; the set of historical environment states includes the environment states saved when each experiment step in the teaching experiment document is completed; and a verification feedback module, used to switch the current experimental environment to the target environment state, execute the edited experiment steps in the target environment state, and output the verification result of the edited experiment steps.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the verification method for the teaching experiment steps as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the verification method for the teaching experiment steps as described in any one of claims 1 to 7.

Images