Test method and device of function block, configuration device, storage medium

Abstract

This application discloses a method and apparatus for testing function blocks, a configuration device, and a storage medium. The method includes: running a test engine in the configuration device, the test engine being used to test function blocks edited in the configuration device; and testing the target function block using the test engine. This application solves the technical problem of the cumbersome testing operations for basic function blocks.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and more specifically, to a testing method and apparatus for functional blocks, a configuration device, and a storage medium. Background Technology

[0002] A basic function block is a fundamental unit of controller logic function encapsulation in IEC 61499 (a standard for function blocks of distributed industrial process measurement and control systems). A basic function block includes an Execution Control Chart (ECC, a state machine) executed by an ECC scheduling algorithm, written by the designer using a language such as Structured Text (ST, a standard programming language in IEC 61131-3).

[0003] When designers design basic functional blocks, they need to conduct tests to ensure that design constraints are met and functional requirements are satisfied. Traditional programming languages ​​(such as Java and C#) and their programming environments or devices provide methods for unit testing.

[0004] Currently, there is no similar method for rapid testing in function block-based graphical configuration systems; existing methods are limited to graphical single-step testing, such as... Figure 1 As shown, the configuration device sends the test request data of the function block test cases to the test equipment via a network connection. After the device under test completes the test, it returns the test execution data to the configuration device, which then processes the test data and provides the test results. Therefore, the configuration device's testing of the function block test cases depends on the test equipment.

[0005] In the industrial control field, test equipment typically includes a runtime (usually a binary executable file for efficiency) that executes the preceding tests. When a new function block (FB) is created on the configuration device, the runtime in the test equipment lacks information about that FB. In this case, the original runtime source code and the new FB's source code must be recompiled together to create a new runtime before testing that FB can be performed. If a function block has a defect, it needs to be revised, requiring another compilation process to update the runtime with the latest FB information before testing can continue. This entire process is cumbersome and inefficient, especially given its reliance on a specific test device. When the test device is unavailable or unusable, configuration design work may be hindered or even halted.

[0006] There is currently no effective solution to the technical problem of the cumbersome testing operations for the aforementioned basic functional blocks. Summary of the Invention

[0007] This application provides a testing method and apparatus, configuration device, and storage medium for functional blocks to solve the technical problem that the testing operation of basic functional blocks is relatively cumbersome.

[0008] To address the aforementioned technical problems, according to one aspect of the embodiments of this application, a method for testing a function block is provided, comprising: running a test engine in a configuration device, wherein the test engine is used to test a function block edited in the configuration device; and testing a target function block through the test engine.

[0009] Optionally, before testing the target functional block through the test engine, the method further includes: obtaining target test cases configured for the target functional block; testing the target functional block through the test engine includes: calling the target test cases through the test engine to test the target functional block.

[0010] Optionally, testing the target functional block by calling the target test case through the test engine includes: calling the target test case in the test engine to test the target functional block, obtaining test results, and obtaining the expected result of the target test case; if the test result is consistent with the expected result, determining that the target functional block has passed the test; if the test result is inconsistent with the expected result, determining that the target functional block has failed the test.

[0011] Optionally, the test engine calls the target test case to test the target functional block and obtain test results, including: converting the control logic code of the target functional block into dynamic language code through the test engine, and obtaining input data from the test case through the test engine; running the dynamic language code through the test engine to process the input data and obtain the test results.

[0012] Optionally, the control logic code of the target functional block is converted into dynamic language code through the test engine, including: obtaining the execution control graph (ECC) and algorithm included in the target functional block; converting the execution control graph (ECC) and algorithm included in the target functional block into classes of the target dynamic language; converting the input and output of the target functional block into attributes of the class respectively; and converting the events of the target functional block into event sequence attributes of the class.

[0013] Optionally, converting the Execution Control Chart (ECC) included in the target functional block into a class of the target dynamic language includes: obtaining code from the target functional block according to the algorithm names in the ECC; performing syntax analysis on the obtained code to obtain an Abstract Syntax Tree (AST); generating dynamic language code based on the AST; and encapsulating the corresponding dynamic language code into equivalent state machine code of the ECC according to the relationships between algorithms in the ECC, thereby obtaining a class of the target dynamic language.

[0014] Optionally, before running the test engine in the configuration device, the method includes: creating the test engine and installing the test engine in the configuration device.

[0015] According to another aspect of the embodiments of this application, a testing apparatus for a function block is also provided, comprising: a running unit for running a test engine in a configuration device, wherein the test engine is used to test a function block edited in the configuration device; and a testing unit for testing a target function block through the test engine.

[0016] Optionally, the testing unit is further configured to: obtain target test cases configured for the target functional block before testing the target functional block through the testing engine; and call the target test cases through the testing engine to test the target functional block.

[0017] Optionally, the testing unit is further configured to: invoke the target test case in the testing engine to test the target functional block, obtain test results, and acquire the expected results of the target test case; if the test results are consistent with the expected results, determine that the target functional block has passed the test; if the test results are inconsistent with the expected results, determine that the target functional block has failed the test.

[0018] Optionally, the testing unit is further configured to: convert the control logic code of the target function block into dynamic language code through the testing engine, and obtain input data from the test cases through the testing engine; run the dynamic language code through the testing engine to process the input data and obtain the test results.

[0019] Optionally, the testing unit is further configured to: acquire the execution control graph (ECC) and algorithm included in the target functional block; convert the execution control graph (ECC) and algorithm included in the target functional block into classes of the target dynamic language; convert the inputs and outputs of the target functional block into attributes of the classes respectively; and convert the events of the target functional block into event sequence attributes of the classes.

[0020] Optionally, the testing unit is further configured to: obtain code from the target function block according to the algorithm name in the execution control diagram (ECC); perform syntax analysis on the obtained code to obtain an abstract syntax tree (AST); generate dynamic language code based on the AST; and encapsulate the corresponding dynamic language code into equivalent state machine code of the ECC according to the relationship between the algorithms in the ECC, thereby obtaining the class of the target dynamic language.

[0021] Optionally, the running unit is also used to create the test engine and install the test engine in the configuration device before running the test engine in the configuration device.

[0022] According to another aspect of the embodiments of this application, a configuration device is also provided, which includes a testing device for the above-described functional blocks.

[0023] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the storage medium including a stored program that, when executed by a processor, implements the above-described method.

[0024] According to another aspect of the embodiments of this application, an electronic device is also provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the method described above.

[0025] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the embodiments of the methods described above.

[0026] By applying the technical solution of this application, a test engine is run in the configuration device to test the target function block. The test can be completed without recompiling the target function block or relying on a separate test device, which can solve the technical problem that the test operation of basic function blocks is relatively cumbersome. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of a test scheme for functional blocks in the industrial control field of related technologies;

[0028] Figure 2 This is a flowchart of a testing method for an optional functional block according to an embodiment of this application;

[0029] Figure 3This is a schematic diagram of an optional test engine according to an embodiment of this application;

[0030] Figure 4 This is a schematic diagram of an optional test case according to an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of an optional functional block test according to an embodiment of this application;

[0032] Figure 6 This is a schematic diagram of an optional functional block test according to an embodiment of this application;

[0033] Figure 7 This is a schematic diagram of an optional functional block testing scheme according to an embodiment of this application;

[0034] Figure 8 This is a schematic diagram of a test apparatus for an optional functional block according to an embodiment of this application;

[0035] Figure 9 This is a structural block diagram of a terminal according to an embodiment of this application. Detailed Implementation

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

[0037] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0038] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0039] It should be understood that although the terms first, second, third, etc., may be used to describe certain technical features in the embodiments of this application, these technical features should not be limited to these terms. These terms are only used to distinguish these technical features.

[0040] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0041] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0042] Example 1

[0043] The technical solution of this application eliminates the need for testing equipment, enabling independent execution of basic function block tests on a configuration device. By interpreting and executing the control logic code of the basic function blocks, the compilation process can be removed. According to one aspect of the embodiments of this application, an embodiment of a function block testing method is provided, such as... Figure 2 As shown, the method includes the following steps:

[0044] Step S1: Run the test engine in the configuration device. The test engine is used to test the function blocks edited in the configuration device.

[0045] Optionally, a test engine can be pre-created and installed in the configuration device as software, SDK, or other means.

[0046] Step S2: Test the target functional block using the test engine. Target test cases configured for the target functional block can be obtained in advance, and then the test engine can invoke these target test cases to test the target functional block.

[0047] Optionally, the target test case can be invoked in the test engine to test the target functional block and obtain the test results. For example, the control logic code of the target functional block can be converted into dynamic language code by the test engine, and input data can be obtained from the test case by the test engine. The dynamic language code can be run by the test engine to process the input data, thereby obtaining the test results and obtaining the expected results of the target test case. If the test results are consistent with the expected results, the target functional block is determined to have passed the test. If the test results are inconsistent with the expected results, the target functional block is determined to have failed the test.

[0048] In the above embodiments, the control logic code of the target function block is converted into dynamic language code by the test engine, including: obtaining the execution control graph (ECC) and algorithm included in the target function block, converting the execution control graph (ECC) and algorithm included in the target function block into classes of the target dynamic language, converting the input and output of the target function block into attributes of the class respectively, and converting the events of the target function block into event sequence attributes of the class.

[0049] Continuing from the previous example, the Execution Control Chart (ECC) included in the target function block is converted into a class of the target dynamic language. This includes: obtaining code from the target function block based on the algorithm names in the ECC; performing syntax analysis on the obtained code to obtain an Abstract Syntax Tree (AST); generating dynamic language code based on the AST; and encapsulating the corresponding dynamic language code into an equivalent state machine code of the ECC according to the order and association relationships between the algorithms in the ECC, thus obtaining a class of the target dynamic language.

[0050] By following the steps above, the test engine is run in the configuration device, and the target function block is tested through the test engine. The test can be completed without recompiling the target function block and without relying on a separate test device, which can solve the technical problem that the test operation of basic function blocks is relatively cumbersome.

[0051] Example 2

[0052] In the technical solution of this application, a simulation test engine can be built in the configuration device, enabling independent testing of functional blocks on the configuration device and removing the dependence on test equipment. By interpreting and executing the test cases of the functional block under test, the cost of testing is reduced, test results can be obtained faster, and the continuity and efficiency of design work are ensured as much as possible. As an optional embodiment, the technical solution of this application is further described in detail below with reference to specific implementation methods (it should be noted here that the basic functional block and functional block in the following text are equivalent concepts):

[0053] The test engine in this application is responsible for executing test cases (it is also a type of runtime, i.e., the runtime used for testing), and its structure can be found in [reference needed]. Figure 3 As shown, it can be functionally divided into the following parts:

[0054] M0 Test Case Information Access Module: Used to read test case information; see information items below. Figure 4 At the same time, based on the function block name in the test case, all information of the function block can be obtained.

[0055] The M1 test case control logic conversion module is used to convert basic functional blocks and their contained ECCs and algorithms into classes of the target dynamic language. Selectable target dynamic languages ​​include Python, VBS, JavaScript, etc. The inputs and outputs of the basic functional blocks are converted into attributes of the target class, and the events of the basic functional blocks can be converted into event sequence attributes of the target class. ECCs are converted into a method of the target class, which encapsulates a state machine equivalent to the ECC.

[0056] M2 Test Case Execution Module: Used to perform the instantiation of the target class, extract input data from the test cases, and use the input data to call the ECC method of the target class instance.

[0057] The M3 test case result determination module obtains the expected output data of the test case, collects the test data after ECC execution, and compares the two. If the test data matches the expectation, the test is determined to pass; otherwise, it fails.

[0058] The main testing process is as follows: Figure 5 As shown:

[0059] Step 1: Create a function block.

[0060] Step 2: Create functional block test cases.

[0061] Step 3: Execute the functional block test cases.

[0062] Step 3 is the core working step, and its specific steps can be broken down into steps 3.1-3.7:

[0063] Step 3.1: The test engine reads the test case information. See [link to test case data description] for details. Figure 4 The data for a complete functional block's test cases can include Figure 4 The data items in the file.

[0064] Step 3.2: The test engine obtains all information about the functional block under test based on the references to the functional block in the test case.

[0065] In steps 3.1 and 3.2, the functional block test case information and functional block information can be read through module M0.

[0066] Step 3.3: The test engine converts the control logic code of the function block into dynamic language code. This includes steps 3.3.1 to 3.3.4.

[0067] Step 3.3 can be completed by M1, which converts the ST language code of the function block into dynamically executable language code. ST language is a standard language defined in the industrial control field, and it is generally converted into C / C++ before compilation and execution. By converting it into a dynamic language, the compilation process is eliminated. Since this is a test, the efficiency loss of interpreted execution is acceptable compared to actual operation.

[0068] See the control logic conversion sub-process. Figure 6 This part describes the process of transforming basic functional blocks from a memory model into an executable target dynamic language. We can assume the target dynamic language is Python, but it is not limited to Python.

[0069] Step 3.3.1: Read the ECC information of the basic function block.

[0070] Step 3.3.2: Obtain the names of all called algorithms in ECC.

[0071] Step 3.3.3: Convert the basic functional blocks into classes of the target dynamic language.

[0072] The target dynamic language type may support classes, or it may be optional to choose one without class support. If it does not support classes, it can be converted to structures, global functions, etc. In this case, the target language needs to make corresponding type changes or use a different conversion method.

[0073] Step 3.3.4: Process each algorithm one by one, transforming it into a method of the target class. Step 3.3.4 includes steps 3.3.4.1 to 3.3.4.3.

[0074] Step 3.3.4.1: Obtain the code from the basic function block according to the algorithm name.

[0075] Step 3.3.4.2: Perform syntax analysis on the code to obtain the AST (Abstract Syntax Tree).

[0076] Step 3.3.4.3: Based on the AST, output the target dynamic language code of the algorithm.

[0077] Step 3.3.4: Encapsulate the ECC output of the target class's methods into an equivalent state machine code.

[0078] In the above scheme, an interpreter for the algorithm code language of the basic functional blocks can also be directly created, but this will be a lot of work; moreover, the algorithm code language can be other languages ​​besides ST language, and creating an interpreter for each one would be too costly and unnecessary; rather, using AST to convert into a unified target language is easier to extend and easier to operate.

[0079] Step 3.4: The test engine obtains the input data for the test cases.

[0080] Step 3.5: The test engine uses the input data to execute the dynamic language code and obtain the execution data.

[0081] Steps 3.4 and 3.5 involve executing the test cases. This section explains the execution of the dynamic language code in 3.3, a task that can be performed by M2.

[0082] Step 3.6: The test engine obtains the expected output data of the test cases from the test cases.

[0083] Step 3.7: The test engine compares the executed data with the expected output data to determine whether the test case passes.

[0084] Steps 3.6 and 3.7 involve processing the test case results, which can be done by M3.

[0085] See the flow of data within the system. Figure 7 The UI part interacts with the user, including providing an entry point to start the test (such as a menu), displaying test results, and pre-coding the standard data and function blocks required by IEC61499 and IEC61131-3 into a library, which is provided as a test runtime standard library.

[0086] The test results function may be placed in the test UI module or a similar module, rather than in the test engine. Test data is passed between the two through communication methods, and the test UI module makes the judgment.

[0087] In this example, the test engine is started on demand by the configuration device (started when the test is started); the test engine can also run independently, exchanging information and data between the test UI module and the engine through communication.

[0088] By adopting the technical solution of this application, the testing of functional blocks can be completed independently on the configuration device, eliminating the configuration device's dependence on the testing equipment and facilitating the configuration design work. In addition, by interpreting and executing the control logic of the functional block, it is no longer necessary to update the information about the tested FB in the test runtime before testing, further improving the efficiency of the configuration design work.

[0089] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0090] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0091] Example 3

[0092] According to another aspect of the embodiments of this application, a testing apparatus for a functional block for implementing the testing method of the above-described functional block is also provided. Figure 8 This is a schematic diagram of a test apparatus for an optional functional block according to an embodiment of this application, such as... Figure 8 As shown, the device may include:

[0093] The running unit 81 is used to run a test engine in the configuration device, wherein the test engine is used to test the function blocks edited in the configuration device; the test unit 83 is used to test the target function blocks through the test engine.

[0094] The above modules enable the test engine to run in the configuration device, allowing the target functional blocks to be tested without recompiling them or relying on separate test equipment. This solves the technical problem of cumbersome testing operations for basic functional blocks.

[0095] Optionally, the testing unit is further configured to: obtain target test cases configured for the target functional block before testing the target functional block through the testing engine; and call the target test cases through the testing engine to test the target functional block.

[0096] Optionally, the testing unit is further configured to: invoke the target test case in the testing engine to test the target functional block, obtain test results, and acquire the expected results of the target test case; if the test results are consistent with the expected results, determine that the target functional block has passed the test; if the test results are inconsistent with the expected results, determine that the target functional block has failed the test.

[0097] Optionally, the testing unit is further configured to: convert the control logic code of the target function block into dynamic language code through the testing engine, and obtain input data from the test cases through the testing engine; run the dynamic language code through the testing engine to process the input data and obtain the test results.

[0098] Optionally, the testing unit is further configured to: acquire the execution control graph (ECC) and algorithm included in the target functional block; convert the execution control graph (ECC) and algorithm included in the target functional block into classes of the target dynamic language; convert the inputs and outputs of the target functional block into attributes of the classes respectively; and convert the events of the target functional block into event sequence attributes of the classes.

[0099] Optionally, the testing unit is further configured to: obtain code from the target function block according to the algorithm name in the execution control diagram (ECC); perform syntax analysis on the obtained code to obtain an abstract syntax tree (AST); generate dynamic language code based on the AST; and encapsulate the corresponding dynamic language code into equivalent state machine code of the ECC according to the relationship between the algorithms in the ECC, thereby obtaining the class of the target dynamic language.

[0100] Optionally, the running unit is also used to create the test engine and install the test engine in the configuration device before running the test engine in the configuration device.

[0101] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run in a corresponding hardware environment, and can be implemented through software or hardware, wherein the hardware environment includes a network environment.

[0102] Example 4

[0103] This application provides a configuration device, including a testing apparatus for the aforementioned functional blocks, the specific operation of which is described in the above method embodiments.

[0104] Example 5

[0105] This embodiment provides an electronic device, which includes: a processor 201, a memory 202, and a transmission device 203, such as... Figure 9 As shown, the terminal may also include an input / output device 204; wherein:

[0106] The memory 202 can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor 201 executes various functional applications and data processing by running the software programs and modules stored in the memory 202, thereby implementing the methods described above. The memory 202 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 202 may further include memory remotely located relative to the processor 201, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0107] The aforementioned transmission device 203 is used to receive or send data via a network, and can also be used for data transfer between the processor and memory. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 203 includes a Network Interface Controller (NIC), which can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 203 is a radio frequency (RF) module, used for wireless communication with the Internet.

[0108] Specifically, memory 202 is used to store application programs.

[0109] The processor 201 can invoke the application stored in the memory 202 through the transmission device 203 to execute the steps in the above embodiments.

[0110] Example 6

[0111] This application provides software for executing the technical solutions described in the above embodiments and preferred embodiments.

[0112] This application provides a non-volatile computer storage medium storing computer-executable instructions that can execute the method for editing content in a document as described in any of the above method embodiments.

[0113] The aforementioned storage medium stores the aforementioned software, and the storage medium includes, but is not limited to, optical discs, floppy disks, hard disks, and rewritable memory.

[0114] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0115] The electronic devices described in this application exist in various forms, including but not limited to:

[0116] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and primarily aim to provide voice and data communication. These terminals include: smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones, etc.

[0117] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, possessing computing and processing capabilities, and generally also have mobile internet access features. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0118] (3) Portable entertainment devices: These devices can display and play multimedia content. This category includes: audio and video players (e.g., iPods), handheld game consoles, e-book readers, as well as smart toys and portable car navigation devices.

[0119] (4) Server: A device that provides computing services. The components of a server include a processor, hard disk, memory, device bus, etc. Servers are similar to general computer architectures, but because they need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0120] (5) Other electronic devices with data interaction functions, such as televisions and in-vehicle screens.

[0121] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0123] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 of the technical features. Such modifications 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.

Claims

1. A method for testing a functional block, characterized in that, The method includes: A test engine is run in the configuration device, wherein the test engine is used to test the functional blocks edited in the configuration device; The test engine is used to test the target functional block, including: converting the control logic code of the target functional block into dynamic language code using the test engine, and obtaining input data from test cases using the test engine; running the dynamic language code using the test engine to process the input data and obtain test results. The test engine converts the control logic code of the target function block into dynamic language code, including: obtaining the execution control graph (ECC) and algorithm included in the target function block; converting the ECC and algorithm included in the target function block into classes of the target dynamic language; converting the input and output of the target function block into attributes of the class; and converting the events of the target function block into event sequence attributes of the class. The process of converting the Execution Control Chart (ECC) and algorithms included in the target functional block into classes of the target dynamic language includes: obtaining code from the target functional block based on the algorithm names in the ECC; performing syntax analysis on the obtained code to obtain an Abstract Syntax Tree (AST); generating dynamic language code based on the AST; and encapsulating the corresponding dynamic language code into equivalent state machine code of the ECC based on the relationships between the algorithms in the ECC, thereby obtaining classes of the target dynamic language.

2. The method according to claim 1, characterized in that, Before testing the target functional block through the test engine, the method further includes: obtaining target test cases configured for the target functional block; Testing the target functional block using the test engine includes: calling the target test case through the test engine to test the target functional block.

3. The method according to claim 2, characterized in that, The target functional block is tested by calling the target test case through the test engine, including: The target test case is invoked in the test engine to test the target functional block, the test results are obtained, and the expected results of the target test case are acquired. If the test result is consistent with the expected result, the target functional block is determined to have passed the test; If the test results are inconsistent with the expected results, it is determined that the target functional block has failed the test.

4. The method according to any one of claims 1 to 3, characterized in that, Before running the test engine in the configuration device, the method includes: Create the test engine and install the test engine in the configuration device.

5. A testing device for functional blocks, characterized in that, The device includes: A running unit is used to run a test engine in a configuration device, wherein the test engine is used to test functional blocks edited in the configuration device; The testing unit is used to test the target functional block through the testing engine. Specifically, the testing unit is used to: convert the control logic code of the target functional block into dynamic language code through the testing engine, and obtain input data from test cases through the testing engine; run the dynamic language code through the testing engine to process the input data and obtain test results. The test engine converts the control logic code of the target function block into dynamic language code, including: obtaining the execution control graph (ECC) and algorithm included in the target function block; converting the ECC and algorithm included in the target function block into classes of the target dynamic language; converting the input and output of the target function block into attributes of the class; and converting the events of the target function block into event sequence attributes of the class. The process of converting the Execution Control Chart (ECC) and algorithms included in the target functional block into classes of the target dynamic language includes: obtaining code from the target functional block based on the algorithm names in the ECC; performing syntax analysis on the obtained code to obtain an Abstract Syntax Tree (AST); generating dynamic language code based on the AST; and encapsulating the corresponding dynamic language code into equivalent state machine code of the ECC based on the relationships between the algorithms in the ECC, thereby obtaining classes of the target dynamic language.

6. A configuration device, characterized in that, A test apparatus including the functional block of claim 5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 4.

8. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 4.

Images