BIM component automatic test system based on polymorphic interface adaptation

Abstract

The invention discloses a BIM component automatic test system based on polymorphic interface adaptation. The system comprises a universal interface module and a test program module, the universal interface module is used for receiving a component instantiation request sent by the test program module, binding a corresponding component implementation class instance, adding processing logic and packaging the component implementation class instance into an agent class instance for subsequent calling; the test program module is used for realizing dynamic loading of a test unit through macro definition; before execution, the test unit sends a component instantiation request to the universal interface module, and acquires an agent instance; and during execution, the test unit uses a test scene provided by the use case loader to call a general interface method of the proxy instance and outputs an execution result. According to the BIM component automatic test system, the stability, the efficiency and the expandability of the test are improved by constructing the BIM component automatic test system capable of self-adapting to the platform difference and the version evolution.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of engineering digitization, and in particular, to a BIM component automatic testing system based on polymorphic interface adaptation. BACKGROUND

[0002] With the in-depth application of building information modeling (BIM) technology in the field of engineering design, mainstream BIM platforms have integrated core functional components (such as mesh processing, Boolean operation, ray intersection, etc.) facing geometric algorithms. However, the poor compatibility of components in cross-platform and cross-version calls and the high cost of testing and maintenance have become key bottlenecks restricting the engineering landing of BIM technology, which is specifically manifested as follows:

[0003] 1. Serious interface heterogeneity

[0004] In the BIM software ecosystem, the component interfaces (APIs) provided by different manufacturers (such as Autodesk Revit, Bentley Systems, or Guanglianda, etc.) have great differences in function naming, parameter structure, data access logic, etc., which makes it difficult to call uniformly. Traditional testing frameworks generally rely on static interface binding mechanisms, which are difficult to adapt to the dynamic evolution of component APIs (such as adding new interfaces, changing parameters, etc.), and the test scripts are prone to failure, resulting in a sharp increase in maintenance workload.

[0005] 2. Lack of unified exception handling mechanism

[0006] There is no effective exception fusion and isolation strategy in the current testing process, and the failure of the component in the call often leads to the interruption of the entire testing chain, lacks fault tolerance, and cannot guarantee the continuity of the testing task.

[0007] 3. Insufficient performance monitoring granularity

[0008] The existing performance monitoring means need to modify the component code invasively, which has large execution overhead and cannot realize cross-platform performance data alignment analysis, limiting the efficiency of cross-platform performance evaluation.

[0009] Therefore, it is urgent to build a BIM component automatic testing system that can adapt to platform differences and version evolution, thereby improving the stability, efficiency and scalability of testing. SUMMARY

[0010] The present disclosure provides a BIM component automatic testing system based on polymorphic interface adaptation, which builds a BIM component automatic testing system that can adapt to platform differences and version evolution, thereby improving the stability, efficiency and scalability of testing.

[0011] This disclosure provides an automated testing system for BIM components based on polymorphic interface adaptation, including: a general interface module (11) and a test program module (12);

[0012] The general interface module (11) includes:

[0013] The generic interface definition unit is used to build standardized generic interface classes, which abstract the common operations of BIM components with the same functions and shield the underlying differences between different platforms and component versions.

[0014] The component implementation class unit is used to encapsulate, adapt, or refactor the interfaces of BIM components for different BIM platforms and versions according to the requirements of the general interface design specification, and encapsulate the factory function to obtain the component implementation class, that is, the component implementation class implements the general interface method.

[0015] The dynamic interface proxy unit is used to load the corresponding component implementation class according to the component instantiation request; and to parse the parameter type conversion, the default value filling rules for missing parameters, and the exception circuit breaking strategy based on the component's metadata;

[0016] The factory management class unit is used to receive the component instantiation request sent by the test program module (12), call the dynamic interface proxy to load the corresponding component implementation class, and call the factory function of the component implementation class to create the component implementation class instance; the dynamic interface proxy will parse the component metadata, determine the parameter type conversion, the default value filling rules for missing parameters, and determine the exception circuit breaking strategy; finally, the factory management class binds the specified component implementation class instance, adds processing logic, and encapsulates it into a proxy class instance for subsequent calls.

[0017] In some embodiments, metadata information includes: parameter name, parameter type, whether the parameter is required, default value of the parameter, component version label, component platform identifier, and abnormal circuit breaker strategy.

[0018] In some embodiments, the test program module (12) is used to load global test configuration parameters during the test initialization phase; to implement dynamic loading of test units through macro definitions; before execution, the test unit sends a component instantiation request to the factory management class unit in the general interface module (11) and obtains a proxy class instance; when the test unit is executed, it uses the test scenario provided by the test case loader to construct the corresponding test call logic, calls the general interface method of the proxy class instance for each test case, and outputs the execution result.

[0019] In some embodiments, the system further comprises a test case management module (13) for inputting test parameter values based on case template library parameter rules according to test requirements and outputting a CSV file; during test running, parsing the test model path in the CSV file, obtaining the test model, reading the test parameter values in the CSV file, generating boundary covered parameter combinations according to orthogonal table algorithms by the parameter combination engine, inputting the test program module (12), and applying random disturbance to the input to trigger abnormal processing logic.

[0020] In some embodiments, the system further comprises a runtime resource monitoring module (14) with a built-in monitoring template function for monitoring the call running memory usage peak and running time consumption of the general interface method of the agent class instance.

[0021] In some embodiments, in the test program module (12), the test unit, when executed, uses the test scenario provided by the case loader to construct the corresponding test call logic, calls the general interface method of the agent class instance for each test case, and outputs the execution result, specifically including:

[0022] The test unit encapsulates the call of the general interface method of the agent class instance as a parameterized lambda function, and inputs the lambda function, each time a test case is executed, the monitoring template function provided by the runtime resource monitoring module (14) is called, and the monitoring template function is responsible for executing the call of the general interface method of the agent class instance, and simultaneously completes the performance data collection during running, and returns the function execution result and the performance result to the test program module (12).

[0023] In some embodiments, the system further comprises a multi-dimensional result analysis module (15) for predefining a unified algorithm running success template for each type of functional component for the test case result of the non-exception handling logic, and comparing the function verification results of different platform and different version components of the same type of functional component on a case-by-case basis.

[0024] In some embodiments, for the test case result of the non-exception handling logic, a multi-platform, multi-version, and multi-case aligned runtime performance data set is constructed for each type of functional component, and a performance baseline comparison mechanism is used to compare and analyze the performance of different platform and different version components of the same type of functional component on a case-by-case basis.

[0025] In some embodiments, for the test case result of the abnormal processing logic, a difference matrix is used to mark the divergence points of different platform and different version components of the same type of functional component in the abnormal processing logic on a case-by-case basis.

[0026] The beneficial effects of the present disclosure are that, compared with the prior art, the present disclosure has the following advantages:

[0027] This disclosure provides an automated testing system for BIM components based on polymorphic interface adaptation, which has the following advantages:

[0028] 1. Unified Invocation Framework: A unified algorithm-level interface invocation framework is built through a "general interface + dynamic proxy" mechanism, shielding differences across platforms and versions and achieving flexible decoupling across platforms and versions. The proxy layer supports parameter type conversion and default value filling, and dynamically adapts the interface structure based on metadata to ensure consistent invocation. Adding a new component version only requires updating the metadata; no modification to the interface or test code is needed to complete the adaptation, significantly reducing maintenance and development costs. The proxy mechanism has built-in exception handling, supports default returns and logging, ensuring uninterrupted testing processes.

[0029] 2. Intelligent Test Scheduling: Based on a pre-compiled macro mechanism, test units are automatically registered and unloaded, dynamically loaded on demand at runtime, effectively reducing resource consumption. A risk / criticality priority strategy is introduced to dynamically schedule high-risk or critical functional tests, improving testing efficiency and defect detection rate. A pre-built template library and intelligent parameter combination engine enable automatic generation and full lifecycle management of test cases.

[0030] 3. Lightweight Performance Monitoring: Supports memory monitoring of any proxy class instance method via a template mechanism, allowing for the general instrumentation of any proxy class instance method and avoiding repetitive coding. Employs a dual-channel isolation monitoring mechanism, ensuring that recording runtime and memory usage does not interfere with the main program, guaranteeing accurate monitoring data and system stability.

[0031] 4. Multi-dimensional quality assessment system: Construct a cross-platform, cross-version test and assessment toolchain, covering functional verification, performance analysis and exception handling, to support multi-dimensional, full-process assessment of component quality.

[0032] In summary, this system is suitable for development, debugging, and automated testing scenarios. It supports one-click test execution and generates functional result models and performance data, comprehensively improving the stability, efficiency, and scalability of testing. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0034] Figure 1 A schematic diagram of an automated testing system for BIM components based on polymorphic interface adaptation provided in this embodiment of the disclosure;

[0035] Figure 2 A schematic diagram of a general interface module provided in the embodiments of this disclosure;

[0036] Figure 3A factory management class unit code snippet diagram provided by the embodiment of the present disclosure is shown in the following figure.

[0037] Figure 4 A runtime resource monitoring code snippet diagram provided by the embodiment of the present disclosure is shown in the following figure.

[0038] Through the above figures, the explicit embodiments of the present disclosure have been shown, and will be described in more detail hereinafter. These figures and textual descriptions are not intended to limit the scope of the concept of the present disclosure in any way, but to illustrate the concept of the present disclosure to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0039] The present disclosure will be further described below in conjunction with the figures. The following embodiments are only used to more clearly illustrate the technical solutions of the present disclosure, and cannot limit the protection scope of the present disclosure.

[0040] Term explanation:

[0041] BIM component (or component): refers to an independent functional unit of geometric algorithm processing logic in a specific version of a specific BIM platform (such as Autodesk Revit, Bentley Systems, or Guanglianda, etc.), including but not limited to grid reading and writing, grid modeling, and core algorithm methods such as ray intersection, grid intersection, and Boolean operation for grid calculation;

[0042] Reflection mechanism: the ability of a program to dynamically obtain class structure information and operate the attributes and methods of the class during runtime.

[0043] Dynamic linking technology: refers to the technology of loading the required modules or libraries into the memory for linking during the runtime of a program, rather than the traditional static linking during compilation.

[0044] Lambda function: refers to a function without an explicit name, also known as an anonymous function, which is usually used to define one-time and temporary function logic concisely and can be passed as a parameter to other functions.

[0045] Figure 1 A schematic diagram of a BIM component automated testing system based on polymorphic interface adaptation according to the embodiment of the present disclosure is shown in the following figure.

[0046] As shown in the figure, Figure 1 The BIM component automated testing system 10 based on polymorphic interface adaptation at least includes a general interface module 11 and a test program module 12.

[0047] As shown in the figure, Figure 2 The general interface module 11 includes a general interface definition unit, a dynamic interface proxy unit, a component implementation class unit, and a factory management class unit.

[0048] The generic interface definition unit is used to build standardized generic interface classes, which abstract the common operations of BIM components with the same functions and shield the underlying differences between different platforms and component versions.

[0049] Specifically, functionally identical BIM components across different platforms (such as Autodesk Revit, Bentley Systems, and Glodon) and versions are abstracted into a common interface. This common interface defines all functional interface types involved in BIM component testing, including mesh reading and writing, mesh modeling, ray intersection, mesh intersection, Boolean operations, and so on.

[0050] The component implementation class unit is used to encapsulate, adapt, or refactor the interfaces of BIM components for different BIM platforms and versions according to the requirements of the general interface design specification, and encapsulate the factory function to obtain the component implementation class, that is, the component implementation class implements the general interface method.

[0051] Factory functions include creation functions and destruction functions.

[0052] The dynamic interface proxy unit is used to load the corresponding component implementation class according to the component instantiation request; and based on the reflection mechanism and the component's metadata, it parses the parameter type conversion, the default value filling rules for missing parameters, and the exception circuit breaker strategy.

[0053] Specifically, dynamic interface proxies are based on dynamic linking technology and load the corresponding component implementation class according to the component instantiation request.

[0054] The factory management class unit is used to receive component instantiation requests sent by the test program module 12, call the dynamic interface proxy to load the corresponding component implementation class, and call the factory function of the component implementation class to create an instance of the component implementation class. The dynamic interface proxy will parse the component metadata, determine the parameter type conversion, the default value filling rules for missing parameters, and determine the exception circuit breaking strategy. Finally, the factory management class binds the specified component implementation class instance, adds processing logic, and encapsulates it into a proxy class instance for subsequent calls.

[0055] The metadata information includes at least: parameter name, parameter type, whether the parameter is required, default value, component version, component platform identifier, and circuit breaker strategy. The circuit breaker strategy includes returning the default value and logging errors.

[0056] like Figure 3 The image shows a code snippet for the factory management class unit. It should be understood that during subsequent test execution, this proxy class instance acts as an intermediary layer for interface calls, responsible for forwarding the call request to the corresponding component implementation class instance.

[0057] This embodiment builds a set of BIM component unified calling framework that can adapt to platform differences and version evolution through general interface + dynamic proxy mechanism, with the following improvement effects:

[0058] 1. Cross-platform and cross-version decoupling:

[0059] A standardized interface system is built to shield the internal differences of different platforms (such as Autodesk Revit, Bentley Systems, and Guanglianda, etc.) and different component versions. The test program only needs to call the general interface to achieve complete decoupling with the component.

[0060] 2. Dynamic parameter conversion and default value filling:

[0061] The dynamic proxy layer uniformly embeds parameter type conversion and default value filling logic for missing parameters, and configures platform version identification, component version annotation, and parameter information in metadata. The system automatically loads and processes interface calls according to the metadata during runtime, dynamically adapts to changes in parameter structures between different platforms and different versions, and ensures the consistency of interface calls.

[0062] 3. Low maintenance cost for version evolution:

[0063] When a new component version goes online, only the platform identification, component version identification, and parameter information need to be registered in the metadata configuration. There is no need to modify the general interface definition or test code. The interface proxy automatically loads and completes the adaptation, thereby dynamically adapting to the version evolution of BIM components and significantly reducing the subsequent maintenance and secondary development cost.

[0064] 4. Exception fusing and process continuity guarantee:

[0065] The dynamic proxy mechanism integrates exception fusing processing logic. When a BIM component is missing, damaged, or fails to call, the proxy class captures the exception, returns a preset default result, and records the log. The subsequent interface call continues to execute, avoiding the impact of a single component failure on the overall test process.

[0066] 5. Centralized configuration of general logic, simplifying interface maintenance:

[0067] By integrating parameter type conversion, default value filling, and exception fusing, etc. in the dynamic interface proxy, "one configuration, global effect" is achieved. There is no need to repeatedly define in each functional interface, significantly improving the interface development and maintenance efficiency.

[0068] In summary, the system realizes the dual adaptive capability of different platforms and different versions of BIM components through the general interface + dynamic proxy mechanism, effectively improves the robustness and expansibility of multi-component collaborative testing. Whether it is development and debugging or automatic testing scenarios, the maintenance cost can be greatly reduced, and the continuity, stability and scalability of the testing process can be ensured.

[0069] The test program module 12 is connected with the general interface module 11, the test case management module 13 and the runtime resource monitoring module 14 respectively, and is used to drive the test process, execute specific test tasks and output test results.

[0070] The module 12 is used to load global test configuration parameters in the test initialization stage; the dynamic loading of test units is realized through macro definition; before execution, the test unit sends a component instantiation request to the factory management class unit in the module 11, and obtains the specified component proxy class instance; when executing, the test unit uses the test scenario provided by the test case loader to construct the corresponding test calling logic, calls the general interface method of the proxy class instance for each test case, and outputs the execution result.

[0071] It can be understood that during the entire execution process, the test unit only needs to call the general interface method, and all processing logic is completed by the proxy class instance independently without additional intervention.

[0072] In specific implementation, the module is used to divide the same BIM component function into independent test units in an atomized manner, and each test unit corresponds to an independent test header file, and the dynamic registration and on-demand loading of the test unit are realized through macro definition.

[0073] The global test configuration parameters include the number of concurrent threads, the performance baseline threshold, etc.

[0074] Further optionally, the module 12 is also used to dynamically schedule the test units according to the priority based on the risk or function criticality priority scheduling strategy.

[0075] The embodiment realizes the automatic registration and deregistration of test units through pre-compiled macros: when adding a test, only macro definition needs to be inserted, which can be automatically recognized and loaded by the framework, and deleting the macro definition can trigger the release of resources at the same time, without modifying the code throughout the process; dynamically loaded on demand at runtime, which can effectively avoid redundant resource occupation and significantly simplify the management and maintenance of the test framework. At the same time, a dynamic scheduling strategy based on risk or criticality is introduced, which preferentially executes the test units of high-risk or critical functions, and improves the overall test efficiency and defect discovery rate.

[0076] In an optional embodiment, the system further includes a test case management module 13, which is used to input test parameter values ​​and output a CSV file based on the test requirements and the parameter rules of the test case template library. During test execution, the test model path in the CSV file is parsed to obtain the test model, the test parameter values ​​in the CSV file are read, the parameter combination engine generates the parameter combination of boundary coverage according to the orthogonal array algorithm, inputs it into the test program module 12, and applies random perturbation to the input to trigger exception handling logic.

[0077] In its implementation, this module, based on the test requirements and the parameter rules defined in the test case template library, inputs specific test parameter values ​​and outputs a CSV file. The CSV file includes the test model path, test parameters, expected results, etc. During test execution, the test model path in the CSV file is parsed in real time, and the specified test model is read. The test parameter values ​​in the CSV file are read, and the parameter combination engine generates parameter combinations based on the orthogonal array algorithm, covering boundary conditions, and inputs them into the test program module 12. Random perturbations are applied to the input according to the functional test requirements, triggering exception handling logic.

[0078] For example, for the ray intersection mesh calculation function, the test parameters include ray origin coordinates, direction vector, spatial indexing method, etc.

[0079] The test case template library helps testers and developers quickly design, write, and manage test cases through preset standard structures and typical scenario templates. The template library has built-in fixed field information, including: the test unit (the functional module to be tested), preconditions (scenario conditions outside the test point), test scenario (test point), test parameters (data that constitutes the test scenario), expected results, and verification criteria (acceptance criteria for passing functional tests), etc.

[0080] This embodiment achieves automated management of the entire lifecycle of test cases by using a pre-built standardized test case template library and an intelligent parameter combination engine. Based on the template library, it quickly generates CSV files that conform to parameter rules, automatically constructs boundary coverage test parameter combinations using an orthogonal array algorithm, and triggers exception handling logic through a random perturbation mechanism. This not only improves test design efficiency but also significantly enhances the coverage of abnormal scenarios and the ability to discover defects in the system.

[0081] In an optional embodiment, the system further includes a runtime resource monitoring module 14, which has a built-in monitoring template function for monitoring the peak memory usage and runtime of the generic interface methods of the proxy class instance.

[0082] Correspondingly, in the test program module 12, the test unit, when executed, uses the test scenario provided by the use case loader to construct the corresponding test call logic, calls the general interface method of the proxy class instance for each test case, and outputs the execution result, specifically including:

[0083] The test unit encapsulates the call of the general interface method of the proxy class instance as a parameterized lambda function, and inputs the lambda function. When each test case is executed, the monitoring template function provided by the module 14 is called, and the monitoring template function is responsible for uniformly executing the call of the general interface method of the proxy class instance, and simultaneously completes the performance data collection during the running, and returns the function execution result and the performance result to the module 12.

[0084] As shown in Figure 4 , in an optional embodiment, the monitoring template function in the module 14 performs the following steps:

[0085] 1. Initialize the memory usage peak value variable of the atomic type;

[0086] 2. Record the starting timestamp before the lambda function call, and start an independent memory monitoring thread to start collecting memory usage data at a preset sampling interval;

[0087] 3. Execute the lambda function input by the module 12, that is, the call of the general interface method of the proxy class instance method;

[0088] 4. After the execution of the lambda function ends, record the end timestamp, and stop the memory monitoring thread;

[0089] 5. Read the memory usage peak recorded during the execution, and calculate the running time (running time = end timestamp - starting timestamp);

[0090] 6. Encapsulate the memory usage peak and the running time as a structured performance result, and return it to the module 12.

[0091] It can be understood that the monitoring template function will be called once when each test case is executed, that is, the memory usage peak and the performance result of the running time for each test case are collected respectively.

[0092] Since the general interface method of running the proxy class instance is called, the proxy mechanism automatically runs all preset processing logic, that is, the monitoring template function actually monitors the running of the proxy class instance method including parameter conversion, default value filling, exception fusing and actual component calling. This embodiment supports memory monitoring of any proxy class instance method calling through the template mechanism, and can universally plug in any proxy class instance method function, thereby saving repeated code writing; meanwhile, since the "memory and time consumption dual-mode isolated monitoring" is adopted, when recording the running time consumption (start and end time stamp dotting mode) and memory usage (equidistant sampling mode), the two monitoring channels completely run independently and have extremely low execution overhead (much lower than the algorithm itself time consumption), the running interference to the target algorithm can be ignored, thereby ensuring the objectivity of the monitoring data and the stability of the system running. In addition, the atomic type variable is used to record the memory peak value, thereby ensuring the atomicity of data updating in the multi-threaded environment and avoiding the race condition, and the efficiency and thread safety are considered.

[0093] In an optional embodiment, the system further comprises a multi-dimensional result analysis module 15, configured to, for the use case results of the non-exception handling logic, define a unified algorithm running success template for each type of functional component, and compare the function verification results of different platform and different version components of the same type of functional component on a use case by use case basis; for each type of functional component, construct a multi-platform, multi-version and multi-use case aligned runtime performance dataset, and compare and analyze the performance of different platform and different version components of the same type of functional component on a use case by use case basis by using a performance baseline comparison mechanism; for the test case results of the exception handling logic, mark the divergence points of different platform and different version components of the same type of functional component on the exception handling logic on a use case by use case basis through a difference matrix.

[0094] The multi-dimensional result analysis module 15 is connected with the test program module 12, and is configured to obtain the component function results and the runtime performance data.

[0095] Taking the Boolean operation type functional component as an example, the system checks the closedness, manifold, self-intersection and volume preservation of the output model; taking the ray intersection operation type functional component as an example, the system checks whether the intersection point number, intersection point geometric coordinates and the face equation where the intersection point is located meet the expected precision and logical consistency. The input of this step is the algorithm running results of each use case, and the output is a structured function verification result report.

[0096] Specifically, for each type of functional component, a multi-platform, multi-version and multi-use case aligned runtime performance dataset is constructed, and the performance of different platform and different version components of the same type of functional component is compared and analyzed on a use case by use case basis by using a performance baseline comparison mechanism, including:

[0097] S1, for the use case result of non-exception handling logic, obtain the key runtime performance indicators of the components in the execution algorithm process under different test cases;

[0098] S2, eliminate environmental noise through a unified data cleaning and timestamp alignment process, and construct a runtime performance dataset aligned in multiple platforms, multiple versions and multiple use cases;

[0099] S3, periodically collect the performance dataset of the component runtime, establish a historical performance database, obtain the performance data baseline of each component under different test cases through statistical modeling methods, evaluate the performance of the component in each test case through the baseline, and perform use case-by-use case comparison and analysis on the performance of different platform and version components of the same type of functional component based on the baseline.

[0100] The performance data includes memory usage peak, running time consumption, etc.

[0101] The statistical modeling method is a prior art, and methods such as sliding window average method and quantile regression can be used, which are not specifically limited in the present disclosure.

[0102] It can be understood that this step ensures the alignment of the execution process under the heterogeneous platform by stamping a unified timestamp on each collection result.

[0103] Specifically, for the test case result of the exception handling logic, the difference matrix is used to mark the divergence point of different platform and version components of the same type of functional component in the exception handling logic on a use case-by-use case basis, for example, the ray intersection operation component of the Revit platform returns an error code for a certain function, while the ray intersection operation component of the Guanglianda platform triggers an unhandled exception.

[0104] The embodiment constructs a comprehensive evaluation system across platforms and versions, covering algorithm function verification, performance analysis and comparison analysis of exception handling: 1) function verification level: special check rules are designed for different algorithm types, such as Boolean operation closure verification and ray intersection coordinate precision verification, and a structured verification report is output; 2) performance analysis level: a unified runtime performance dataset and baseline comparison mechanism is established to realize quantitative evaluation of performance differences across platforms and versions; 3) exception handling level: the difference matrix is used to mark the divergence point of each component in the exception handling logic. The above system provides a multi-dimensional, full-life-cycle analysis tool chain for cross-platform and cross-version component quality evaluation.

[0105] The device embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed to multiple network units. Part or all of the modules can be selected to achieve the purposes of the embodiments according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0106] Through the description of the above embodiments, those skilled in the art can clearly understand that the embodiments can be realized by means of software and necessary universal hardware platforms, and of course can also be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of software products, and the computer software products can be stored in a computer readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and include a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0107] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present disclosure, rather than limit them; although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.

Claims

1. An automated testing system for BIM components based on polymorphic interface adaptation, characterized in that, include: The general interface module (11) and the test program module (12) are included. The general interface module (11) includes: The generic interface definition unit is used to build standardized generic interface classes, which abstract the common operations of BIM components with the same functions and shield the underlying differences between different platforms and component versions. The component implementation class unit is used to encapsulate, adapt, or refactor the interfaces of BIM components for different BIM platforms and versions according to the requirements of the general interface design specification, and encapsulate the factory function to obtain the component implementation class, that is, the component implementation class implements the general interface method. The dynamic interface proxy unit is used to load the corresponding component implementation class according to the component instantiation request; and to parse the parameter type conversion, the default value filling rules for missing parameters, and the exception circuit breaking strategy based on the reflection mechanism and the component's metadata. The factory management class unit is used to receive the component instantiation request sent by the test program module (12), call the dynamic interface proxy to load the corresponding component implementation class, and call the factory function of the component implementation class to create the component implementation class instance; the dynamic interface proxy will parse the component metadata, determine the parameter type conversion, the default value filling rules for missing parameters, and determine the exception circuit breaking strategy; finally, the factory management class binds the specified component implementation class instance, adds processing logic, and encapsulates it into a proxy class instance for subsequent calls.

2. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 1, characterized in that, Metadata information includes: parameter name, parameter type, whether the parameter is required, default value of the parameter, component version label, component platform identifier, and abnormal circuit breaker policy.

3. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 1, characterized in that, The test program module (12) is used to load global test configuration parameters during the test initialization phase; dynamic loading of test units is achieved through macro definitions; before execution, the test unit sends a component instantiation request to the factory management class unit in the general interface module (11) and obtains a proxy class instance; when the test unit is executed, it uses the test scenario provided by the test case loader to construct the corresponding test call logic, calls the general interface method of the proxy class instance for each test case, and outputs the execution result.

4. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 1, characterized in that, The system also includes a test case management module (13), which is used to input test parameter values ​​and output CSV files based on the test requirements and the parameter rules of the test case template library. During test execution, the test model path in the CSV file is parsed, the test model is obtained, the test parameter values ​​in the CSV file are read, the parameter combination engine generates the parameter combination of boundary coverage according to the orthogonal array algorithm, inputs it into the test program module (12), and applies random perturbation to the input to trigger the exception handling logic.

5. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 3, characterized in that, The system also includes a runtime resource monitoring module (14), which has built-in monitoring template functions to monitor the peak memory usage and runtime of the calls to the general interface methods of the proxy class instance.

6. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 5, characterized in that, In the test program module (12), when the test unit is executed, it uses the test scenarios provided by the test case loader to construct the corresponding test call logic. For each test case, it calls the general interface method of the proxy class instance and outputs the execution result, specifically including: The test unit encapsulates the call to the general interface method of the proxy class instance into a parameterized lambda function and takes the lambda function as input. When each test case is executed, the monitoring template function provided by the runtime resource monitoring module (14) is called. The monitoring template function is responsible for executing the call to the general interface method of the proxy class instance, and at the same time, it completes the performance data collection during the runtime and returns the function execution result and performance result to the test program module (12).

7. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 6, characterized in that, The system also includes a multi-dimensional result analysis module (15), which is used for test case results of non-abnormal processing logic. For each type of functional component, a unified algorithm running success template is predefined, and the functional verification results of different platforms and different versions of the same type of functional components are compared test case by test case.

8. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 7, characterized in that, For test case results of non-exception handling logic, a runtime performance dataset with multiple platforms, multiple versions, and multiple test cases aligned is constructed for each type of functional component. A performance baseline comparison mechanism is then used to perform test case-by-test case comparison analysis of the performance of components of the same type on different platforms and different versions.

9. The automated testing system for BIM components based on polymorphic interface adaptation according to claim 7, characterized in that, For the test case results of exception handling logic, the difference matrix is ​​used to mark the divergence points in exception handling logic of different platforms and different versions of the same type of functional components.

Images