A BIM component automatic test system based on polymorphic interface adaptation

Abstract

A BIM component automatic test system based on polymorphic interface adaptation, the system comprises: a general interface module and a test program module; the general 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, encapsulating into a proxy class instance, and being called subsequently; 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 general interface module and obtains a proxy class instance; when executing, the test unit uses a test scenario provided by a use case loader, calls a general interface method of the proxy class instance, and outputs an execution result. The disclosure improves the stability, efficiency and scalability of the test by constructing a set of BIM component automatic test system which can adapt to platform differences and version evolution.

Description

Technical Field

[0001] This disclosure relates to the field of engineering digitalization technology, and in particular to an automated testing system for BIM components based on polymorphic interface adaptation. Background Technology

[0002] With the deepening application of Building Information Modeling (BIM) technology in engineering design, mainstream BIM platforms have integrated core functional components oriented towards geometric algorithms (such as mesh processing, Boolean operations, and ray intersection). However, poor compatibility of these components across platforms and versions, along with high testing and maintenance costs, have become key bottlenecks restricting the engineering implementation of BIM technology. Specifically, these bottlenecks manifest as follows:

[0003] 1. Severe interface heterogeneity

[0004] In the BIM software ecosystem, the component interfaces (APIs) provided by different vendors (such as Autodesk Revit, Bentley Systems, or Glodon) vary significantly in terms of function naming, parameter structure, and data access logic, making unified invocation difficult. Traditional testing frameworks generally rely on static interface binding mechanisms, which are difficult to adapt to the dynamic evolution of component APIs (such as the addition of new interfaces and parameter changes), making test scripts prone to failure and drastically increasing maintenance workload.

[0005] 2. Lack of a unified exception handling mechanism

[0006] The current testing process lacks an effective circuit breaking and isolation strategy. When a component fails to call, the entire testing chain is often interrupted, lacking fault tolerance and failing to guarantee the continuity of testing tasks.

[0007] 3. Insufficient granularity of performance monitoring

[0008] Existing performance monitoring methods require intrusive modifications to component code, resulting in high execution overhead and an inability to achieve cross-platform performance data alignment analysis, thus limiting the efficiency of cross-platform performance evaluation.

[0009] Therefore, there is an urgent need to build an automated testing system for BIM components that can adapt to platform differences and version evolution, thereby improving the stability, efficiency and scalability of testing. Summary of the Invention

[0010] This disclosure provides an automated testing system for BIM components based on polymorphic interface adaptation. By constructing an automated testing system for BIM components that can adapt to platform differences and version evolution, the stability, efficiency, and scalability of testing are improved.

[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 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, 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 exception handling logic.

[0020] In some embodiments, the system further includes a runtime resource monitoring module (14), which has built-in monitoring template functions for monitoring the peak memory usage and runtime of the calls to the general interface methods of the proxy class instance.

[0021] In some embodiments, in the test program module (12), 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, specifically including:

[0022] 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).

[0023] In some embodiments, the system further includes a multi-dimensional result analysis module (15) for use case results of non-abnormal processing logic, pre-defining a unified algorithm execution success template for each type of functional component, and comparing the functional verification results of different platforms and different versions of the same type of functional components on a use case-by-use basis.

[0024] In some embodiments, for the test case results of non-exception handling logic, a runtime performance dataset aligned with multiple platforms, multiple versions, and multiple test cases is constructed for each type of functional component, and a performance baseline comparison mechanism is adopted to perform test case-by-test case comparison analysis of the performance of components of the same type on different platforms and different versions.

[0025] In some embodiments, for the test case results of exception handling logic, the divergence points in exception handling logic of different platforms and different versions of the same type of functional components are marked on a test case-by-test basis using a difference matrix.

[0026] The beneficial effects of this disclosure are that, compared with the prior art, this 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 3This is a schematic diagram of a code snippet for a factory management class unit provided in an embodiment of this disclosure;

[0037] Figure 4 This is a schematic diagram of a runtime resource monitoring code snippet provided in an embodiment of this disclosure.

[0038] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0039] The present disclosure will be further described below with reference to the accompanying drawings. The following embodiments are only used to illustrate the technical solutions of the present disclosure more clearly, and should not be used to limit the scope of protection of the present disclosure.

[0040] Terminology Explanation:

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

[0042] Reflection mechanism: The ability of a program to dynamically obtain class structure information and manipulate class attributes and methods at runtime.

[0043] Dynamic linking technology refers to the linking of required modules or libraries into memory at runtime, rather than the traditional static linking at compile time.

[0044] Lambda functions: These are functions without explicit names, also known as anonymous functions. They are typically used to concisely define one-time, temporary function logic and can be passed as arguments to other functions.

[0045] Figure 1 This is a schematic diagram of an automated testing system for BIM components based on polymorphic interface adaptation, provided according to an embodiment of this disclosure.

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

[0047] like Figure 2 As shown, 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 constructs a unified BIM component calling framework that can adapt to platform differences and version evolution through a general interface and dynamic proxy mechanism, and has the following improvement effects:

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

[0059] By building a standardized interface system, the internal differences between different platforms (such as Autodesk Revit, Bentley Systems, and Glodon) and different component versions are shielded. Test programs only need to call the general interface to achieve complete decoupling from the components.

[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. By configuring platform version identifiers, component version labels, and parameter information in the metadata, the system automatically loads and processes interface calls based on the metadata at runtime, dynamically adapting to changes in parameter structure between different platforms and versions, and ensuring consistency of interface calls.

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

[0063] When a new component version is launched, only the platform identifier, component version identifier, 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 is automatically loaded and adapted, thereby dynamically adapting to the version evolution of BIM components and greatly reducing the cost of subsequent maintenance and secondary development.

[0064] 4. Abnormal circuit breaker and process continuity assurance:

[0065] The dynamic proxy mechanism integrates exception handling logic. When a BIM component is missing, damaged, or fails to be called, the proxy class catches the exception, returns a preset default result and logs it. Subsequent interface calls continue to execute, avoiding the impact of a single component failure on the overall testing process.

[0066] 5. Centralized configuration of common logic simplifies interface maintenance:

[0067] By integrating common handling strategies such as parameter type conversion, default value filling, and circuit breaking into a unified dynamic interface proxy, "one-stop configuration, global effect" is achieved. This eliminates the need for re-definition across various functional interfaces, significantly improving interface development and maintenance efficiency.

[0068] In summary, the system achieves dual adaptability to different platforms and versions of BIM components through a universal interface and dynamic proxy mechanism, effectively improving the robustness and scalability of multi-component collaborative testing. Whether in development and debugging or automated testing scenarios, it significantly reduces maintenance costs and ensures the continuity, stability, and scalability of the testing process.

[0069] The test program module 12 is connected to 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] 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 Module 11 and obtains the specified component proxy class instance; when the test unit is executed, it uses the test scenarios 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.

[0071] Understandably, during the entire execution process, the test unit only needs to call the general interface method, and all processing logic is completed autonomously by the proxy class instance without any additional intervention.

[0072] In its implementation, this module is used to divide the same BIM component functions into independent test units in an atomic manner. Each test unit corresponds to an independent test header file, and the dynamic registration and on-demand loading of test units are realized through macro definitions.

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

[0074] Alternatively, module 12 is also used to dynamically schedule test units according to priority, in conjunction with a priority scheduling strategy based on risk or functional criticality.

[0075] This embodiment uses pre-compiled macros to achieve automatic registration and deregistration of test units: when adding a test, simply inserting the macro definition is sufficient for the framework to automatically recognize and load it; deleting a macro definition triggers resource release simultaneously, requiring no code modification throughout the process; runtime dynamic loading on demand effectively avoids redundant resource consumption and significantly simplifies the management and maintenance of the test framework. Simultaneously, a dynamic scheduling strategy based on risk or criticality is introduced, prioritizing the execution of test units with high risk or critical functions, improving overall testing 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] Accordingly, in 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:

[0083] The test unit encapsulates the call to the general interface method of the proxy class instance into a parameterized lambda function, and uses this lambda function as input. When each test case is executed, the monitoring template function provided by 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 operation and returns the function execution result and performance result to module 12.

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

[0085] 1. Initialize the memory of atomic types using peak variables;

[0086] 2. Record the start timestamp before the lambda function call and start an independent memory monitoring thread to collect memory usage data at preset sampling intervals;

[0087] 3. Execute the lambda function passed in by module 12, which is the call to the general interface method of the proxy class instance method;

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

[0089] 5. Read the peak memory usage recorded during execution and calculate the execution time (time = end timestamp – start timestamp).

[0090] 6. Encapsulate peak memory usage and runtime into structured performance results and return them to module 12.

[0091] Understandably, the monitoring template function is called once when each test case is executed, which means that the peak memory usage and runtime performance results are collected for each test case.

[0092] When a generic interface method of a proxy class instance is called, the proxy mechanism automatically runs all preset processing logic. In essence, the monitoring template function monitors the execution of proxy class instance methods, including parameter conversion, default value filling, exception circuit breaking, and actual component calls. This embodiment supports memory monitoring of any proxy class instance method call through the template mechanism, allowing for the general instrumentation of any proxy class instance method function, eliminating the need for repetitive code writing. Furthermore, due to the adoption of "dual-mode isolated monitoring of memory and execution time," the two monitoring channels operate completely independently when recording execution time (first and last timestamp mode) and memory usage (equal interval sampling mode), with extremely low execution overhead (far lower than the algorithm's own execution time). The interference to the target algorithm is negligible, ensuring the objectivity of monitoring data and the stability of system operation. In addition, atomic type variables are used to record memory peaks, ensuring the atomicity of data updates in a multi-threaded environment, avoiding race conditions, and balancing efficiency and thread safety.

[0093] In an optional embodiment, the system further includes a multi-dimensional result analysis module 15, which is used to: for test case results of non-anomaly handling logic, predefine a unified algorithm execution success template for each type of functional component, and compare the functional verification results of different platforms and different versions of the same type of functional component on a test case-by-test basis; for each type of functional component, construct a runtime performance dataset aligned with multiple platforms, multiple versions, and multiple test cases, and use a performance baseline comparison mechanism to perform a test case-by-test comparison analysis of the performance of different platforms and different versions of the same type of functional component; for test case results of anomaly handling logic, mark the divergence points in anomaly handling logic of different platforms and different versions of the same type of functional component on a test case-by-test basis using a difference matrix.

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

[0095] Taking a Boolean operation-type functional component as an example, the system checks the closure, manifold, self-intersection, and volume preservation of the output model. Taking a ray intersection operation-type functional component as an example, the system checks whether the number of intersection points, the geometric coordinates of the intersection points, and the equations of the surfaces they lie on meet the expected accuracy and logical consistency. The input to this step is the algorithm execution results of each use case, and the output is a structured functional verification result report.

[0096] Specifically, for each type of functional component, a runtime performance dataset aligned with multiple platforms, versions, and use cases is constructed. A performance baseline comparison mechanism is then used to perform a test case-by-test comparison analysis of the performance of components of the same type across different platforms and versions, including:

[0097] S1, for test case results that do not involve exception handling logic, obtain the key runtime performance metrics of the component during the algorithm execution process under different test cases;

[0098] S2 eliminates environmental noise and builds runtime performance datasets that are aligned across multiple platforms, versions, and use cases through a unified data cleaning and timestamp alignment process.

[0099] S3 periodically collects performance datasets of components during runtime, establishes a historical performance database, obtains performance data baselines for each component under different test cases through statistical modeling methods, evaluates the component performance in each test case based on the baseline, and performs test case-by-test case comparison analysis on the performance of components of the same type of function on different platforms and different versions based on the baseline.

[0100] The performance data includes peak memory usage and runtime.

[0101] The statistical modeling method is existing technology and can employ methods such as sliding window averaging and quantile regression. This disclosure does not impose any specific limitations on this method.

[0102] Understandably, this step ensures alignment of execution processes across heterogeneous platforms by assigning a uniform timestamp to each collected result.

[0103] Specifically, 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. For example, the ray intersection calculation component of the Revit platform returns an error code for a certain function, while the ray intersection calculation component of the Glodon platform triggers an unhandled exception.

[0104] This embodiment constructs a comprehensive evaluation system that spans multiple platforms and versions, covering comparative analysis of algorithm function verification, performance analysis, and anomaly handling: 1) Function verification level: Dedicated inspection rules are designed for different algorithm types, such as Boolean operation closure verification and ray intersection coordinate accuracy verification, and structured verification reports are output; 2) Performance analysis level: A unified runtime performance dataset and baseline comparison mechanism are established to achieve quantitative evaluation of performance differences across platforms and versions; 3) Anomaly handling level: A difference matrix is ​​used to mark the points of divergence in anomaly handling logic among various components. This system provides a multi-dimensional, full-lifecycle analysis toolchain for cross-platform, cross-version component quality evaluation.

[0105] 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. Those skilled in the art can understand and implement this without any creative effort.

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

[0107] It should be understood that the above embodiments are only used to illustrate the technical solutions of this disclosure, and not to limit them; although this 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 described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these 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 disclosure.

Claims

1. A BIM component automated testing system 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; 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; 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; 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 proxy class instances; 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).

2. The BIM component automated testing system based on polymorphic interface adaptation of claim 1, wherein, 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 algorithm by the parameter combination engine, inputting the test program module (12), and applying random disturbance to the input to trigger abnormal processing logic.

3. The BIM component automated testing system based on polymorphic interface adaptation of claim 1, wherein, The system further comprises a multi-dimensional result analysis module (15) for, for the test case results of non-abnormal processing logic, predefining a unified algorithm running success template for each type of functional component, 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.

4. The BIM component automated testing system based on polymorphic interface adaptation of claim 3, wherein, For the test case results of non-abnormal processing logic, a multi-platform, multi-version, and multi-case aligned runtime performance dataset 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.

5. The BIM component automated testing system based on polymorphic interface adaptation of claim 3, wherein, For the test case results of 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 abnormal processing logic on a case-by-case basis.

Images