Ecological product testing method and system based on operating system layered architecture

Abstract

The invention provides an ecological product testing method and system based on an operating system hierarchical architecture, and belongs to the technical field of product testing, and the method comprises the steps: obtaining a preset hierarchical testing strategy for a target ecological product, the preset layering strategy is based on a layering framework of an operation system operated by the target ecological product and hardware adaptation and function of the target ecological product to realize acceptance requirement definition; according to the preset layered test strategy, testing each layer of a target ecological product in sequence according to a layered architecture, and outputting a test result of each layer; and integrating the test results of each layer into a test report and outputting the test report. According to the invention, the test object is layered according to the architecture, and the differentiated test strategy is defined for each layer based on the hardware adaptation and function requirements of the product, so that the test resource can be accurately input to the variable and customized level, the repeated input on the stable and universal level is not needed, and the test efficiency can be obviously improved.

Description

Technical Field

[0001] This invention relates to the field of product testing technology, and in particular to an ecosystem product testing method and system based on an operating system layered architecture. Background Technology

[0002] In the testing of operating system ecosystem products, formulating efficient testing strategies is a major challenge, given the wide variety of products (such as core boards, development boards, and complete systems based on different chips). Current technologies typically design and execute a complete test plan for each product individually. This approach fails to fully consider the differences in hardware adaptation depth and functional verification focus among different products, resulting in insufficient targeting and flexibility of the testing strategies. For example, for products with similar hardware platforms, their underlying adaptation tests may be largely repetitive; while for products with similar functions, their upper-layer application tests lack reuse mechanisms. This one-size-fits-all testing method prevents the optimal allocation of testing resources based on the specific characteristics of the product, leading to overall low testing efficiency.

[0003] Therefore, existing technologies have shortcomings and need to be improved and developed. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide an ecosystem product testing method and system based on an operating system layered architecture, which addresses the above-mentioned deficiencies of the prior art and aims to solve the problem of low overall testing efficiency in the prior art.

[0005] The technical solution adopted by this invention to solve the technical problem is as follows: In a first aspect, embodiments of the present invention provide a method for testing ecosystem products based on an operating system layered architecture, the method comprising: Obtain a preset layered testing strategy for the target ecosystem products. The preset layered strategy is based on the layered architecture of the operating system running on the target ecosystem products and the hardware adaptation and functional implementation acceptance requirements of the target ecosystem products. According to the preset layered testing strategy, each layer of the target ecosystem product is tested sequentially according to the layered architecture, and the test results of each layer are output.

[0006] In one implementation, the operating system running the target ecosystem product is the Kaihong Operating System, and the layered architecture includes an application layer, a framework service layer, and a bottom-level software driver adaptation layer.

[0007] In one implementation, the step of performing tests on the application layer includes: Determine whether the system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications; If all system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications, then the system applications will be subjected to point inspection testing and free testing. If the application layer includes customized user business applications, then full functional testing will be performed on the customized user business applications.

[0008] In one implementation, the step of performing tests on the framework service layer includes: Determine whether the modules of the framework service layer are consistent with the main version of the operating system and have not undergone customized modifications; If all modules of the framework service layer are consistent with the main version of the operating system and have no customized modifications, then the existing test results of the main version on the modules in the framework service layer are reused. If there are customized modifications in the framework service layer, then module testing is performed on the corresponding customized modules in the framework service layer.

[0009] In one implementation, the step of performing tests on the underlying soft driver adapter layer includes: The hardware interface functionality of the underlying soft driver adaptation layer was tested. The tests include functional testing, stress testing, and stability testing.

[0010] In one embodiment, the method further includes: Obtain the certification types of the target ecosystem products; Perform authentication tests according to the standard requirements corresponding to the type to be authenticated, and output the authentication test results.

[0011] In one embodiment, the method further includes: Obtain the secondary development kits that accompany the target ecosystem products; Determine whether the documentation in the secondary development package is published material obtained from the main project; Based on the judgment results, the document is tested or existing test results of published materials are reused; The tools in the secondary development package are integrated into the test of the underlying soft driver adaptation layer and executed synchronously.

[0012] Secondly, embodiments of the present invention also provide an ecosystem product testing system based on an operating system layered architecture, the system comprising: The strategy acquisition module is used to acquire a preset layered testing strategy for the target ecosystem product. The preset layered strategy is based on the layered architecture of the operating system running on the target ecosystem product and the hardware adaptation and functional implementation acceptance requirements of the target ecosystem product. The layered testing module is used to test each layer of the target ecosystem product sequentially according to the preset layered testing strategy and the layered architecture, and output the test results of each layer. The report generation module is used to integrate the test results of each layer into a test report output.

[0013] Thirdly, embodiments of the present invention also provide a terminal, the terminal comprising: a memory, a processor, and an ecosystem product testing program based on an operating system layered architecture stored on the memory and executable on the processor, wherein when the ecosystem product testing program based on an operating system layered architecture is executed by the processor, the steps of the ecosystem product testing method based on an operating system layered architecture as described above are implemented.

[0014] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing an ecosystem product testing program based on an operating system layered architecture, the ecosystem product testing program based on an operating system layered architecture being executable to implement the steps of the ecosystem product testing method based on an operating system layered architecture as described above.

[0015] The beneficial effects of this invention are as follows: This invention obtains a preset layered testing strategy for a target ecosystem product. This preset layered strategy is based on the layered architecture of the operating system running the target ecosystem product and defines the hardware adaptation and functional implementation acceptance requirements of the target ecosystem product. According to the preset layered testing strategy, each layer of the target ecosystem product is tested sequentially according to the layered architecture, and the test results for each layer are output. This invention, by layering the test object according to its architecture and defining differentiated testing strategies for each layer based on the product's hardware adaptation and functional requirements, enables testing resources to be precisely targeted at volatile and customized layers, without redundant investment in stable and universal layers, thus significantly improving testing efficiency. Attached Figure Description

[0016] Figure 1 This is a flowchart of a preferred embodiment of the ecosystem product testing method based on the operating system layered architecture in this invention.

[0017] Figure 2 This is a flowchart of the application layer test performed in this invention.

[0018] Figure 3 This is a flowchart of the test performed on the framework service layer in this invention.

[0019] Figure 4 This is a flowchart of the certification test in this invention.

[0020] Figure 5 This is a flowchart of the secondary development package testing in this invention.

[0021] Figure 6 This is a schematic diagram of a preferred embodiment of the ecosystem product testing system based on the operating system layered architecture of the present invention.

[0022] Figure 7 This is a block diagram of the terminal principle of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0024] In the testing of operating system ecosystem products, formulating efficient testing strategies is a major challenge, given the wide variety of products (such as core boards, development boards, and complete systems based on different chips). Current technologies typically design and execute a complete test plan for each product individually. This approach fails to fully consider the differences in hardware adaptation depth and functional verification focus among different products, resulting in insufficient targeting and flexibility of the testing strategies. For example, for products with similar hardware platforms, their underlying adaptation tests may be largely repetitive; while for products with similar functions, their upper-layer application tests lack reuse mechanisms. This one-size-fits-all testing method prevents the optimal allocation of testing resources based on the specific characteristics of the product, leading to overall low testing efficiency.

[0025] To address the aforementioned shortcomings of existing technologies, this invention provides a method and system for testing ecosystem products based on an operating system layered architecture. The method includes: acquiring a preset layered testing strategy for a target ecosystem product, wherein the preset layered strategy is defined based on the layered architecture of the operating system running the target ecosystem product and the hardware compatibility and functional implementation acceptance requirements of the target ecosystem product; and, according to the preset layered testing strategy, sequentially testing each layer of the target ecosystem product according to the layered architecture, and outputting the test results for each layer. This invention, by layering the test object according to its architecture and defining differentiated testing strategies for each layer based on the product's hardware compatibility and functional requirements, enables testing resources to be precisely targeted at volatile and customized layers, without redundant investment in stable and universal layers, thus significantly improving testing efficiency.

[0026] Please see Figure 1 The present invention provides a method for testing ecosystem products based on an operating system layered architecture, comprising the following steps: Step S100: Obtain a preset layered testing strategy for the target ecosystem product. The preset layered strategy is based on the layered architecture of the operating system running on the target ecosystem product and the hardware adaptation and functional implementation acceptance requirements of the target ecosystem product.

[0027] Specifically, the target ecosystem products are self-developed ecosystem products based on the Kaihong OS, such as core boards and development boards for developers. The operating system adopts a layered architecture design, mainly including, from top to bottom: an application layer responsible for user interaction and business functions; a framework service layer that provides general system service interfaces for applications; and a low-level software driver adaptation layer that directly manages and drives hardware resources. The operating system running on the target ecosystem products is the Kaihong OS. The core idea behind the pre-defined layered testing strategy is to first layer the system according to its architecture, and then, for each layer, identify and distinguish between the stable and general parts and the variable and customized parts of the operating system, and allocate different testing resources accordingly.

[0028] For generic parts from the unified codebase that are unmodified (such as system-provided applications and basic services), a simplified testing strategy is adopted because they have already been fully verified, avoiding redundant testing and saving manpower. However, for parts that require adaptation and customization for different hardware (especially underlying hardware drivers), comprehensive functional, performance, and stability verification is conducted as the focus of testing. This layered strategy significantly improves testing efficiency while ensuring product quality, supporting rapid product iteration.

[0029] Please see Figure 1 The ecosystem product testing method based on operating system layered architecture described in this embodiment of the invention further includes the following steps: Step S200: According to the preset layered testing strategy, test each layer of the target ecosystem product in sequence according to the layered architecture, and output the test results of each layer.

[0030] Specifically, a layered testing strategy is employed, sequentially testing the application layer, framework service layer, and underlying software driver adaptation layer. This approach effectively separates testing concerns, breaking down complex systemic testing tasks into clearly defined and targeted sub-tasks. This ensures that the functionality and interfaces of each layer are specifically verified, allowing testing resources to be precisely allocated to the most frequently changing and highest-risk underlying driver adaptation areas. Consequently, while maintaining core quality, this significantly reduces redundant testing on stable code, achieving a balance between testing efficiency and product quality.

[0031] In one implementation, the steps of performing tests on the application layer include: Determine whether the system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications; If all system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications, then the system applications will be subjected to point inspection testing and free testing. If the application layer includes customized user business applications, then full functional testing will be performed on the customized user business applications.

[0032] Specifically, the flowchart for performing tests at the application layer in this invention is as follows: Figure 2 As shown. The judgment process is achieved through automated code scanning tools (such as comparison scripts or software composition analysis tools based on Git version control systems) integrated into the continuous integration / continuous deployment (CI / CD) pipeline. The tool automatically compares the code repository of the current ecosystem product's application layer with the corresponding code repository of the operating system's verified main branch version. By verifying code hash values, analyzing commit history, and identifying branch differences, it accurately determines whether the system applications in the application layer (such as system settings, desktop, notification center, etc.) completely reuse the code of the operating system's verified main branch version without any customized modifications.

[0033] If the judgment result is that all system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications, it means that these system applications have been verified on the backbone version, and full testing is not required. A non-full testing strategy is executed for these system applications, specifically point-based testing and free testing. Before point-based testing, corresponding point-based test cases are obtained. These test cases aim to verify the most core and frequently used user interaction paths of the system applications (such as network connection and application installation) with minimal time cost. After obtaining the point-based test cases, they are executed using preset automated testing tools or manually. Free testing simulates random user operations (such as quickly switching applications or abnormal input). Preset free test cases can be obtained and executed using preset automated testing tools or manually.

[0034] If the application layer includes customized user business applications, then obtain the corresponding full set of test cases, and perform full functional testing on the customized user business applications using preset automated testing tools or manually.

[0035] This approach allows for the identification and filtering of verified, stable code. For system applications directly reused from the main branch, replacing full regression test suites with spot testing and custom testing reduces unnecessary test case execution, directly lowering the workload of test engineers. For customized user business applications, full-scale testing is performed to ensure the stability and accuracy of the modified version. This method effectively balances efficiency and quality.

[0036] In one implementation, the steps of performing tests on the framework service layer include: Determine whether the modules of the framework service layer are consistent with the main version of the operating system and have not undergone customized modifications; If all modules of the framework service layer are consistent with the main version of the operating system and have no customized modifications, then the existing test results of the main version on the modules in the framework service layer are reused. If there are customized modifications in the framework service layer, then module testing is performed on the corresponding customized modules in the framework service layer.

[0037] Specifically, the flowchart for performing tests on the framework service layer in this invention is as follows: Figure 3 As shown. In this embodiment, the judgment method is also implemented through automated code scanning tools (such as comparison scripts or software composition analysis tools based on Git version management systems) integrated into the continuous integration / continuous deployment (CI / CD) pipeline, which will not be described in detail here.

[0038] As the crucial hub connecting upper-layer applications and underlying hardware, the stability of the framework service layer's interfaces and the correctness of its behavior are vital to the stable operation of the entire operating system. The framework service layer code has undergone extensive verification and testing in commercial versions, reaching a high level of maturity. Therefore, when it is confirmed that all modules of the framework service layer are completely consistent with the main branch version, it means that there are no new risk points in this layer's code, and its interface functionality, performance, and stability have been fully guaranteed during the testing process of the main branch version. Under this premise, directly reusing the complete test results of the main branch version, rather than performing repeated testing at the ecosystem product level, can effectively improve overall testing efficiency and reduce unnecessary manpower investment.

[0039] If there are customized modifications in the framework service layer, module testing is performed on the corresponding customized modules within the framework service layer. In this scenario, a systematic and specialized testing process needs to be initiated to ensure that the customized modifications do not introduce new risks or disrupt the original stability of the system. During module testing, interface testing, functional testing, performance testing, compatibility testing, and stability testing are required. Interface testing focuses on checking parameter boundaries, exception code returns, and data format compatibility. Functional testing verifies the functionality point by point for each customized requirement. Performance testing focuses on response time and system resource usage. Compatibility testing focuses on runtime environment compatibility and data format compatibility. Stability testing aims to evaluate the reliability of the module under long-term operation, focusing on its performance under continuous load and its fault self-recovery capability. Each type of test has corresponding test cases, which are executed using pre-set automated testing tools or manually to ensure the accuracy of module testing. For example, for Ethernet port testing of the core board, functional testing includes link negotiation and data transmission rate verification; stress testing uses high-concurrency network traffic simulation to check the packet loss rate of the driver under extreme load; and stability testing requires continuous operation for more than 7 days, with no abnormal system restarts monitored.

[0040] In one implementation, the step of performing tests on the underlying soft driver adaptation layer includes: The hardware interface functionality of the underlying soft driver adaptation layer was tested. The tests include functional testing, stress testing, and stability testing.

[0041] Specifically, for core board-type ecosystem products, the bottom-layer software driver adaptation layer bears the crucial mission of adapting the general capabilities of the Kaihong operating system to specific hardware platforms. Its function directly determines whether upper-layer applications can correctly call all hardware functions such as cameras, touch screens, audio codecs, and network communications. Therefore, comprehensive testing of the bottom-layer software driver adaptation layer is necessary, including functional testing, stress testing, and stability testing.

[0042] Functional testing must cover all hardware interfaces in the underlying software driver adaptation layer to ensure the operating system can correctly identify and control these interfaces. Test content may include: basic interface function verification, protocol compliance testing, and exception handling testing. Basic interface function verification tests the initialization, read / write operations, and basic control functions of each hardware interface. Protocol compliance testing focuses on the correctness and timing accuracy of the interface communication protocol. Exception handling testing simulates hardware anomalies to verify the driver's fault tolerance; scenarios such as hot-plugging and abnormal signal interruptions may be included during testing. These tests can be executed in batches using preset test cases, automatically comparing expected results with actual output.

[0043] Stress testing aims to evaluate the stability and performance of hardware interfaces and their drivers under extreme load conditions. By creating loads far exceeding normal usage scenarios, it verifies the system's boundary capabilities and robustness, including high-concurrency testing. High-concurrency testing can simulate high-concurrency scenarios for a single task or multiple tasks concurrently.

[0044] Stability testing focuses on the long-term reliability of the system and mainly includes aging tests and environmental adaptability tests. In aging tests, the system runs continuously for more than 7 x 24 hours under typical loads to assess its stability. In environmental adaptability tests, system stability is verified under different temperature and humidity conditions.

[0045] Through multi-faceted testing and verification, we ensure that the underlying software driver adaptation layer can operate stably and reliably in various application scenarios. Functional testing guarantees the correctness of the basic functions of the hardware interface, stress testing verifies the performance boundaries of the system under extreme conditions, and stability testing identifies potential problems through long-term operation. This combined testing strategy can effectively identify and eliminate various potential defects, significantly reduce the failure rate of the product in field applications, and provide end users with a highly reliable user experience.

[0046] In one implementation, the method further includes: Obtain the certification types of the target ecosystem products; Perform authentication tests according to the standard requirements corresponding to the type to be authenticated, and output the authentication test results.

[0047] Specifically, the flowchart of the certification test in this invention is as follows: Figure 4 As shown. The certification types include XTest Suite (XTS) certification and several hardware test certifications. The XTest Suite comprises the following key components: Application Compatibility Test Suite (ACTS), used to test whether basic system capabilities, APIs, etc., are consistent with standards to ensure normal application functionality; Driver Compatibility Test Suite (DCTS), used to test the compatibility and stability of the kernel and underlying drivers; and HarmonyOS Compatibility Test Suite (HCTS), used to ensure that all devices running HarmonyOS (or open-source HarmonyOS) are consistent with the system's basic capabilities.

[0048] Hardware certifications include wireless communication certification, electromagnetic compatibility (EMC) certification, electrical safety certification, environmental reliability certification, and industry-specific certifications. Wireless communication certification ensures that the product's radio frequency (RF) functions comply with national or regional regulations and is a fundamental prerequisite for market access. EMC certification primarily verifies the product's ability to operate normally in an electromagnetic environment without interfering with other devices. Electrical safety certification ensures electrical safety during product use, preventing risks such as electric shock and fire. Environmental reliability certification verifies the product's adaptability and durability under various environmental conditions. Industry-specific certifications include industrial-grade certification, automotive certification, and medical device certification. Through systematic hardware testing and certification, it is ensured that ecosystem products meet the regulatory requirements and industry standards of the target market in terms of RF performance, electrical safety, EMC, and environmental adaptability, providing comprehensive quality assurance for product commercialization.

[0049] In one implementation, the method further includes: Obtain the secondary development kits that accompany the target ecosystem products; Determine whether the documentation in the secondary development package is published material obtained from the main project; Based on the judgment results, the document is tested or existing test results of published materials are reused; The tools in the secondary development package are integrated into the test of the underlying soft driver adaptation layer and executed synchronously.

[0050] Specifically, the flowchart for testing the secondary development package in this invention is as follows: Figure 5 As shown. The secondary development package is a key supporting material for ecosystem partners to develop applications based on the core board, and its quality directly affects the development efficiency and product quality of ecosystem partners. The testing of the secondary development package is mainly divided into two parts: documentation testing and development tool testing. In terms of documentation testing, the source of the documentation first needs to be identified and confirmed. By comparing metadata such as document version information and modification records, it is determined whether it originates from the published materials of the core project. For documents that have been confirmed to be unchanged, the existing test conclusions can be directly adopted without repeated verification. For newly added or revised documentation, necessary review work needs to be carried out, focusing on checking the accuracy of technical descriptions, the feasibility of operation steps, and the internal consistency of the documentation system.

[0051] In terms of development tool testing, a strategy combining testing with system testing is adopted. Various tools in the secondary development kit are integrated into the corresponding testing phases for simultaneous verification. For example, the programming tool can be used for functional verification during the system deployment phase, while production testing tools serve as the primary means of hardware interface testing. In this way, the practicality verification of relevant tools is completed simultaneously with system testing. This testing arrangement ensures the basic quality of the secondary development kit while reasonably controlling the investment of testing resources, helping to improve overall testing efficiency and providing necessary technical support for the promotion and application of ecosystem products.

[0052] Please see Figure 1 The ecosystem product testing method based on operating system layered architecture described in this embodiment of the invention further includes the following steps: Step S300: Integrate the test results of each layer into a test report and output it.

[0053] Specifically, during the integration process, the system will automatically collect test output data from various layers, including the application layer, framework service layer, and underlying software driver adaptation layer. This data includes, but is not limited to: test case execution results (pass, fail, block), performance metrics (response time, throughput, resource utilization), stability test logs, and detailed defect records. Based on preset templates and rules, the system cleans, categorizes, and analyzes this raw data, ultimately generating a comprehensive test report that is thorough, focused, and easy to understand.

[0054] This test report includes an execution summary, test details for each layer, defect statistical analysis, and test conclusions and recommendations. The execution summary, located at the beginning of the report, aims to provide a holistic perspective for project management decision-makers. It highly summarizes the overall quality assessment conclusions, major risk points, key indicators of testing activities (such as test case execution rate and defect density), and comparison trends with historical versions or baseline data. This section is often supplemented with visual charts of core indicators (such as quality score radar charts and pass rate trend lines) to quickly grasp the version's quality status. The test details for each layer show the testing situation in detail. For the application layer, it lists the core paths covered by point inspection tests and free testing, as well as the issues found; for the framework service layer, it explains the reuse of test results for customized modules and the test results of the main version; for the underlying software driver adaptation layer, it presents detailed functional, stress, and stability test data for each hardware interface, and may include time-series graphs of key performance indicators or screenshots of system load monitoring during stability testing. For discovered defects, it records the steps to reproduce them, the deviation between actual and expected results, and related log snippets or screenshots, providing developers with sufficient context to locate the problem. The defect statistics and analysis section employs data analysis methods to conduct multi-dimensional statistical and in-depth analysis of all defects discovered during testing. Dimensions include the distribution of defects across various software modules, the distribution of severity levels (e.g., fatal, severe, general, warning), the distribution of defect status (e.g., new, processing, closed, reopened), and the trend of defect quantity comparison with previous testing cycles. This type of analysis identifies weak points and high-risk areas in the system, providing data support for subsequent testing priorities and development improvement directions. The test conclusions and recommendations section provides clear test conclusions, such as "The current version has stable core functions, but there is a high-risk defect XX; it is recommended to fix it before release." It also provides specific improvement suggestions, such as "It is recommended to strengthen the anomaly handling testing of the XX driver module in the next version" or "The XX interface exhibits performance regression and needs optimization."

[0055] Once the test report is generated, it can be automatically sent to relevant personnel to ensure that problems are fixed in a timely manner.

[0056] In summary, this invention obtains a pre-defined layered testing strategy for a target ecosystem product. This strategy is based on the layered architecture of the operating system running the target ecosystem product and the hardware compatibility and functional implementation acceptance requirements. According to the pre-defined layered testing strategy, each layer of the target ecosystem product is tested sequentially according to the layered architecture, and the test results for each layer are output. By layering the test object according to its architecture and defining differentiated testing strategies for each layer based on the product's hardware compatibility and functional requirements, this invention allows testing resources to be precisely targeted at volatile and customized layers, eliminating the need for repetitive investment in stable and universal layers, thus significantly improving testing efficiency. In one embodiment, such as Figure 6 As shown, based on the above-described ecosystem product testing method based on an operating system layered architecture, this invention also provides an ecosystem product testing system based on an operating system layered architecture, the system comprising: The strategy acquisition module 100 is used to acquire a preset layered testing strategy for the target ecosystem product. The preset layered strategy is based on the layered architecture of the operating system running on the target ecosystem product and the hardware adaptation and functional implementation acceptance requirements of the target ecosystem product. The layered testing module 200 is used to test each layer of the target ecosystem product sequentially according to the layered architecture based on the preset layered testing strategy, and output the test results of each layer. The report generation module 300 is used to integrate the test results of each layer into a test report output.

[0057] In one embodiment, the system further includes: The first judgment module is used to determine whether the system application in the application layer reuses the code of the verified backbone version of the operating system without any customized modifications. The first testing module is used to perform point inspection and free testing on the system applications if all system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications. The second testing module is used to perform full functional testing on the customized user business applications if the application layer includes them.

[0058] In one embodiment, the system further includes: The second judgment module is used to determine whether the modules of the framework service layer are consistent with the main version of the operating system and have not been customized. The third testing module is used to reuse the existing test results of the main version of the framework service layer for the modules in the framework service layer if all modules of the framework service layer are consistent with the main version of the operating system and have no customized modifications. The fourth testing module is used to perform module testing on the corresponding customized modules in the framework service layer if there are customized modifications in the framework service layer.

[0059] In one embodiment, the system further includes: The fifth testing module is used to test the hardware interface functions of the underlying software driver adaptation layer; wherein, the tests include functional testing, stress testing and stability testing.

[0060] In one embodiment, the system further includes: The type acquisition module is used to obtain the type of the target ecosystem product to be certified. The authentication module is used to perform authentication tests according to the standard requirements corresponding to the type to be authenticated, and output the authentication test results.

[0061] In one embodiment, the system further includes: The secondary development package acquisition module is used to acquire the secondary development packages that are compatible with the target ecosystem products. The third judgment module is used to determine whether the documentation in the secondary development package is published material obtained from the main project; The sixth testing module is used to perform document testing on the document based on the judgment result or to reuse existing test results of published materials; The tool testing module is used to integrate the tools in the secondary development package and execute them synchronously in the testing of the underlying soft driver adaptation layer.

[0062] Based on the above embodiments, the present invention also provides a terminal, the structural schematic diagram of which is as follows: Figure 7 As shown. The terminal includes a processor, memory, network interface, and display screen connected via a device bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and an ecosystem product testing program based on a layered operating system architecture. The internal memory provides an environment for the operation of the operating system and the ecosystem product testing program. The network interface is used to communicate with external terminals via a network connection. When executed by the processor, the ecosystem product testing program based on a layered operating system architecture implements the steps of any of the aforementioned ecosystem product testing methods based on a layered operating system architecture. The display screen can be a liquid crystal display (LCD) or an e-ink display.

[0063] Those skilled in the art will understand that Figure 7 The structural schematic diagram shown is only a schematic diagram of a part of the structure related to the present invention solution, and does not constitute a limitation on the terminal on which the present invention solution is applied. The specific terminal may include more or fewer components than shown in the figure, or combine some components, or have different component arrangements.

[0064] In one embodiment, a terminal is provided, the terminal including a memory, a processor, and an ecosystem product testing program based on an operating system layered architecture stored on the memory and executable on the processor. When the ecosystem product testing program based on an operating system layered architecture is executed by the processor, it implements the steps of any ecosystem product testing method based on an operating system layered architecture provided in the embodiments of the present invention.

[0065] This invention also provides a computer-readable storage medium storing an ecosystem product testing program based on an operating system layered architecture. When the ecosystem product testing program based on an operating system layered architecture is executed by a processor, it implements the steps of any of the ecosystem product testing methods based on an operating system layered architecture provided in this invention.

[0066] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0067] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the above device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this invention. The specific working process of the units and modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0068] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0069] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0070] In the embodiments provided by this invention, it should be understood that the disclosed apparatus / terminal devices and methods can be implemented in other ways. For example, the apparatus / terminal device embodiments described above are merely illustrative. For instance, the division of modules or units described above is only a logical functional division, and in actual implementation, it can be divided in other ways. For example, several units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0071] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not mean that the essence of the corresponding technical solutions deviates from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for testing ecosystem products based on a layered operating system architecture, characterized in that, The method includes: Obtain a preset layered testing strategy for the target ecosystem products. The preset layered strategy is based on the layered architecture of the operating system running on the target ecosystem products and the hardware adaptation and functional implementation acceptance requirements of the target ecosystem products. According to the preset layered testing strategy, each layer of the target ecosystem product is tested sequentially according to the layered architecture, and the test results of each layer are output. The test results from each layer are integrated into a test report for output.

2. The method for testing ecosystem products based on a layered operating system architecture according to claim 1, characterized in that, The target ecosystem products run on the Kaihong Operating System, and the layered architecture includes an application layer, a framework service layer, and a bottom-level software driver adaptation layer.

3. The method for testing ecosystem products based on a layered operating system architecture according to claim 2, characterized in that, The steps for performing tests on the application layer include: Determine whether the system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications; If all system applications in the application layer reuse the code of the verified backbone version of the operating system without any customized modifications, then the system applications will be subjected to point inspection testing and free testing. If the application layer includes customized user business applications, then full functional testing will be performed on the customized user business applications.

4. The method for testing ecosystem products based on a layered operating system architecture according to claim 2, characterized in that, The steps for performing tests on the framework service layer include: Determine whether the modules of the framework service layer are consistent with the main version of the operating system and have not undergone customized modifications; If all modules of the framework service layer are consistent with the main version of the operating system and have no customized modifications, then the existing test results of the main version on the modules in the framework service layer are reused. If there are customized modifications in the framework service layer, then module testing is performed on the corresponding customized modules in the framework service layer.

5. The method for testing ecosystem products based on a layered operating system architecture according to claim 2, characterized in that, The steps for performing tests on the underlying soft driver adapter layer include: The hardware interface functionality of the underlying soft driver adaptation layer was tested. The tests include functional testing, stress testing, and stability testing.

6. The method for testing ecosystem products based on a layered operating system architecture according to claim 1, characterized in that, The method further includes: Obtain the certification types of the target ecosystem products; Perform authentication tests according to the standard requirements corresponding to the type to be authenticated, and output the authentication test results.

7. The method for testing ecosystem products based on a layered operating system architecture according to claim 2, characterized in that, The method further includes: Obtain the secondary development kits that accompany the target ecosystem products; Determine whether the documentation in the secondary development package is published material obtained from the main project; Based on the judgment results, the document is tested or existing test results of published materials are reused; The tools in the secondary development package are integrated into the test of the underlying soft driver adaptation layer and executed synchronously.

8. An ecosystem product testing system based on an operating system layered architecture, characterized in that, include: The strategy acquisition module is used to acquire a preset layered testing strategy for the target ecosystem product. The preset layered strategy is based on the layered architecture of the operating system running on the target ecosystem product and the hardware adaptation and functional implementation acceptance requirements of the target ecosystem product. The layered testing module is used to test each layer of the target ecosystem product sequentially according to the preset layered testing strategy and the layered architecture, and output the test results of each layer. The report generation module is used to integrate the test results of each layer into a test report output.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and an ecosystem product testing program based on an operating system layered architecture stored on the memory and executable on the processor. When the ecosystem product testing program based on an operating system layered architecture is executed by the processor, it implements the steps of the ecosystem product testing method based on an operating system layered architecture as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an ecosystem product testing program based on an operating system layered architecture. When the ecosystem product testing program based on the operating system layered architecture is executed by a processor, it implements the steps of the ecosystem product testing method based on an operating system layered architecture as described in any one of claims 1-7.

Images