CN111782250A - Software upgrading compatibility testing method, system and storage medium - Google Patents
Software upgrading compatibility testing method, system and storage medium Download PDFInfo
- Publication number
- CN111782250A CN111782250A CN202010799650.2A CN202010799650A CN111782250A CN 111782250 A CN111782250 A CN 111782250A CN 202010799650 A CN202010799650 A CN 202010799650A CN 111782250 A CN111782250 A CN 111782250A
- Authority
- CN
- China
- Prior art keywords
- version
- version software
- docker
- test
- test case
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The embodiment of the specification relates to a method and a system for testing software upgrading compatibility and a storage medium, and the software upgrading compatibility test can be automatically realized by using a docker mode, so that manual intervention is reduced, and the result unreliability caused by human factors is avoided; a uniform universal test case is set for the common characteristics of each version of the compatibility to be tested, so that the test efficiency is high; after the docker is used for packaging, each version can be combined with a designated high version to be upgraded at will, and compatibility among the versions is verified quickly; the compatibility of a plurality of versions can be verified simultaneously, the environment isolation is guaranteed, and the report issuing speed is high.
Description
Technical Field
Embodiments of the present disclosure relate to the field of network technologies, and in particular, to a method, a system, and a storage medium for testing software upgrade compatibility
Background
Docker, an open source application container engine, allows application developers to package applications and dependencies into a portable container and then publish the portable container to any machine, i.e., publish applications. Meanwhile, Docker can also realize virtualization, containers completely use a sandbox mechanism, and no interfaces exist among the containers. Therefore, the technical characteristics of docker are widely used in the industry for software testing.
Most of the existing compatibility tests for software version upgrading are manually tested, which is troublesome, and when more compatible cases are upgraded, the time consumption is long, and the error rate of manual execution is high. And when the version is more, the compatibility verification cannot be carried out quickly.
Disclosure of Invention
Embodiments of the present description provide a method, a system, and a storage medium for testing software upgrade compatibility, so as to solve the problems in the prior art that a compatibility test for software version upgrade consumes resources and is low in efficiency.
In order to solve the above technical problem, the embodiments of the present specification adopt the following technical solutions:
in a first aspect, a method for testing software upgrade compatibility is provided, where the method includes:
setting a corresponding unique test case for the unique characteristics of each version of the compatibility to be tested; setting a unified universal test case for the common characteristics of each version of the compatibility to be tested;
starting high-version software by a docker method, and copying executable contents of the high-version software to a first storage space of a host, wherein the docker corresponding to the high-version software is a first docker;
starting the low-version software by a docker method, and operating a corresponding unique test case and a corresponding general test case, wherein the docker corresponding to the low-version software is a second docker;
deleting the executable content of the low-version software in the second docker, and stopping the running of the low-version software;
copying the executable content of the high-version software in the first storage space into the second docker;
starting the second docker middle and high version software, and operating the corresponding unique test case and the corresponding general test case;
and outputting a test report according to the test result.
In a second aspect, a software upgrade compatibility testing system is provided, the system comprising:
the test case setting module: the test system is used for setting a corresponding unique test case for the unique characteristics of each version of the compatibility to be tested and setting a unified universal test case for the common characteristics of each version of the compatibility to be tested;
the high-version software starting module: the system comprises a first storage space, a second storage space and a third storage space, wherein the first storage space is used for storing executable contents of high-version software, and the second storage space is used for storing the executable contents of the high-version software;
the low-version software testing module: starting the low-version software by a docker method, and operating a corresponding unique test case and a corresponding general test case, wherein the docker corresponding to the low-version software is a second docker;
a low-version software shutdown module: the executable content of the low-version software in the second docker is deleted, and the running of the low-version software is stopped;
the high-version software migration module: the executable content of the high-version software in the first storage space is copied into the second docker;
the high-version software testing module: the system is used for starting the second docker middle and high version software and running a corresponding unique test case and a corresponding general test case;
a test report output module: and the test report is output according to the test result.
In a third aspect, a storage medium is proposed, on which a computer program is stored, which computer program, when being executed by one or more processors, carries out the steps of the software upgrade compatibility testing method as described above.
The embodiment of the specification adopts at least one technical scheme which can achieve the following beneficial effects: by using the docker mode, the software upgrading compatibility test can be automatically realized, the manual intervention is reduced, and the result unreliability caused by human factors is avoided; a uniform universal test case is set for the common characteristics of each version of the compatibility to be tested, so that the test efficiency is high; after the docker is used for packaging, each version can be combined with a designated high version to be upgraded at will, and compatibility among the versions is verified quickly; the compatibility of a plurality of versions can be verified simultaneously, the environment isolation is guaranteed, and the report issuing speed is high.
Drawings
In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present specification, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative efforts.
Fig. 1 is a schematic step diagram of a software upgrade compatibility testing method provided in an embodiment of the present specification;
fig. 2 is a schematic structural diagram of a software upgrade compatibility test system provided in an embodiment of this specification.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present disclosure more clear, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the specific embodiments of the present disclosure and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort belong to the protection scope of the embodiments in the present specification.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
It should be noted that the precondition for implementing each embodiment is as follows: each version to be tested has a corresponding docker image (docker-image) and can be directly pulled for use. The upgrade difference for each version is that the software execution in each docker-image must be packaged or binary executable.
Example one
Referring to fig. 1, a schematic step diagram of a software upgrade compatibility testing method provided in an embodiment of the present specification is shown, where the method includes:
step 101: setting a corresponding unique test case for the unique characteristics of each version of the compatibility to be tested; setting a unified universal test case for the common characteristics of each version of the compatibility to be tested;
step 102: starting high-version software by a docker method, and copying executable contents of the high-version software to a first storage space of a host, wherein the docker corresponding to the high-version software is a first docker;
step 103: starting the low-version software by a docker method, and operating a corresponding unique test case and a corresponding general test case, wherein the docker corresponding to the low-version software is a second docker;
step 104: deleting the executable content of the low-version software in the second docker, and stopping the running of the low-version software;
step 105: copying the executable content of the high-version software in the first storage space into the second docker;
step 106: starting the second docker middle and high version software, and operating the corresponding unique test case and the corresponding general test case;
step 107: and outputting a test report according to the test result.
It should be noted that the executable content may include a corresponding executable software must package or binary executable file for each version.
Further, the test results may include the following:
when the second docker middle-high version software cannot be started, the test report result is incompatible;
and when the results and the expectation of the unique test case and the universal test case corresponding to the high-version software are inconsistent, the test report result is incompatible.
Further, after the second docker middle-high version software is started in step 106, comparing whether the historical data obtained in step 103 is consistent with a preset data;
if the test cases are consistent, operating the unique test case and the universal test case corresponding to the high-version software; and if the test results are not consistent, the test report results are incompatible.
Further, the step 102 of starting the high-version software by the docker method further includes the following steps: checking whether the version number of the high-version software is consistent with the preset version number; if the executable content is consistent with the first storage space of the host machine, copying the executable content to the first storage space of the host machine; if not, stopping operation; problems may arise with the test package at this point and manual intervention checks may be required after the shutdown.
The step 103 of starting the low-version software by the docker method further includes the following steps: checking whether the version number of the low-version software is consistent with the preset version number; and if the test cases are consistent, the unique test case and the general test case corresponding to the low-version software are operated, and if the test cases are not consistent, the operation is stopped.
Further, after the test report is output according to the test result, the method further comprises the following steps of clearing data: and deleting the first docker and the second docker, and releasing the first storage space. The executable content of the high-version software is copied into a self-defined identifiable folder in the host, and the folder is deleted when the storage space is released.
It should be noted that: the first docker may also be deleted immediately after the step 102 is executed, so as to ensure better test performance.
According to the technical scheme, the software upgrading compatibility test can be automatically realized by using a docker mode, so that manual intervention is reduced, and the result unreliability caused by human factors is avoided; a uniform universal test case is set for the common characteristics of each version of the compatibility to be tested, so that the test efficiency is high; after the docker is used for packaging, each version can be combined with a designated high version to be upgraded at will, and compatibility among the versions is verified quickly; the compatibility of a plurality of versions can be verified simultaneously, the environment isolation is guaranteed, and the report issuing speed is high.
Example two
Referring to fig. 2, a software upgrade compatibility testing system provided for the embodiment of the present specification includes:
test case setting module 201: the test system is used for setting a corresponding unique test case for the unique characteristics of each version of the compatibility to be tested and setting a unified universal test case for the common characteristics of each version of the compatibility to be tested;
the high-version software startup module 202: the system comprises a first storage space, a second storage space and a third storage space, wherein the first storage space is used for storing executable contents of high-version software, and the second storage space is used for storing the executable contents of the high-version software;
low version software test module 203: starting the low-version software by a docker method, and operating a corresponding unique test case and a corresponding general test case, wherein the docker corresponding to the low-version software is a second docker;
the low-version software outage module 204: the executable content of the low-version software in the second docker is deleted, and the running of the low-version software is stopped;
the high-version software migration module 205: the executable content of the high-version software in the first storage space is copied into the second docker;
high-version software test module 206: the system is used for starting the second docker middle and high version software and running a corresponding unique test case and a corresponding general test case;
the test report output module 207: and the test report is output according to the test result.
It should be noted that the executable content may include a corresponding executable software must package or binary executable file for each version.
Further, the test results may include the following:
when the second docker middle-high version software cannot be started, the test report result is incompatible;
and when the results and the expectation of the unique test case and the universal test case corresponding to the high-version software are inconsistent, the test report result is incompatible.
Further, the high-version software testing module 206 further includes:
a historical data query module: the historical data comparison module is used for comparing whether the historical data obtained by operating the unique test case and the universal test case corresponding to the low-version software is consistent with the preset data or not;
if the test cases are consistent, the high-version software test module continues to run the unique test cases and the general test cases corresponding to the high-version software; and if the test results are not consistent, the test report results are incompatible.
The high-version software startup module 202 further comprises a high version number checking module: the version number of the high-version software is checked to be consistent with the preset version number; if the executable content is consistent with the first storage space of the host machine, copying the executable content to the first storage space of the host machine; if not, stopping operation; problems may arise with the test package at this point and manual intervention checks may be required after the shutdown.
The low-version software testing module 203 further comprises a low version number checking module: the version number of the low-version software is checked to be consistent with the preset version number; and if the test cases are consistent, the unique test case and the general test case corresponding to the low-version software are operated, and if the test cases are not consistent, the operation is stopped.
Further, the system may include a reset module, configured to delete the first docker and the second docker and release the first storage space after outputting a test report according to a test result. The executable content of the high-version software is copied into a self-defined identifiable folder in the host, and the folder is deleted when the storage space is released.
It should be noted that: the first docker can also be deleted immediately after the executable content of the high-version software is copied to the first storage space of the host machine, so that better test performance is guaranteed.
According to the technical scheme, the software upgrading compatibility test can be automatically realized by using a docker mode, so that manual intervention is reduced, and the result unreliability caused by human factors is avoided; a uniform universal test case is set for the common characteristics of each version of the compatibility to be tested, so that the test efficiency is high; after the docker is used for packaging, each version can be combined with a designated high version to be upgraded at will, and compatibility among the versions is verified quickly; the compatibility of a plurality of versions can be verified simultaneously, the environment isolation is guaranteed, and the report issuing speed is high.
It should be understood that the system described in the second embodiment may execute all technical solutions related to the software upgrade compatibility test method in the form of functional modules, and implement corresponding technical effects, which are not described herein again.
EXAMPLE III
Embodiments of the present specification also provide a storage medium having stored thereon a computer program, which when executed by one or more processors, implements the steps of the software upgrade compatibility testing method as described above.
By the technical scheme, software upgrading compatibility test can be automatically realized by using a docker mode, so that manual intervention is reduced, and results are prevented from being unreliable due to human reasons; a uniform universal test case is set for the common characteristics of each version of the compatibility to be tested, so that the test efficiency is high; after the docker is used for packaging, each version can be combined with a designated high version to be upgraded at will, and compatibility among the versions is verified quickly; the compatibility of a plurality of versions can be verified simultaneously, the environment isolation is guaranteed, and the report issuing speed is high.
In short, the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of the present disclosure. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present specification shall be included in the protection scope of the present specification.
The system, apparatus, module or unit illustrated in one or more of the above embodiments may be implemented by a computer chip or an entity, or by an article of manufacture with a certain functionality. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Claims (12)
1. A software upgrade compatibility testing method, the method comprising:
setting a corresponding unique test case for the unique characteristics of each version of the compatibility to be tested; setting a unified universal test case for the common characteristics of each version of the compatibility to be tested;
starting high-version software by a docker method, and copying executable contents of the high-version software to a first storage space of a host, wherein the docker corresponding to the high-version software is a first docker;
starting the low-version software by a docker method, and operating a corresponding unique test case and a corresponding general test case, wherein the docker corresponding to the low-version software is a second docker;
deleting the executable content of the low-version software in the second docker, and stopping the running of the low-version software;
copying the executable content of the high-version software in the first storage space into the second docker;
starting the second docker middle and high version software, and operating the corresponding unique test case and the corresponding general test case;
and outputting a test report according to the test result.
2. The method of claim 1, further comprising:
when the second docker middle-high version software cannot be started, the test report result is incompatible;
and when the results and the expectation of the unique test case and the universal test case corresponding to the high-version software are inconsistent, the test report result is incompatible.
3. The method of claim 2, wherein after launching the second docker mid-high version software, further comprising:
comparing whether the historical data obtained by operating the unique test case and the universal test case corresponding to the low-version software is consistent with the preset data or not;
if the test cases are consistent, operating the unique test case and the universal test case corresponding to the high-version software; and if the test results are not consistent, the test report results are incompatible.
4. The method of claim 1, wherein
Starting the high-version software by the docker method further comprises the following steps: checking whether the version number of the high-version software is consistent with the preset version number; if the executable content is consistent with the first storage space of the host machine, copying the executable content to the first storage space of the host machine; if not, stopping operation;
starting the low-version software by the docker method further comprises the following steps: checking whether the version number of the low-version software is consistent with the preset version number; and if the test cases are consistent, the unique test case and the general test case corresponding to the low-version software are operated, and if the test cases are not consistent, the operation is stopped.
5. The method of claims 1-4, further comprising the following steps after outputting the test report according to the test result: and deleting the first docker and the second docker, and releasing the first storage space.
6. The method of claim 1, wherein the executable content comprises an executive software must package or a binary executable file.
7. A software upgrade compatibility testing system, the system comprising:
the test case setting module: the test system is used for setting a corresponding unique test case for the unique characteristics of each version of the compatibility to be tested and setting a unified universal test case for the common characteristics of each version of the compatibility to be tested;
the high-version software starting module: the system comprises a first storage space, a second storage space and a third storage space, wherein the first storage space is used for storing executable contents of high-version software, and the second storage space is used for storing the executable contents of the high-version software;
the low-version software testing module: starting the low-version software by a docker method, and operating a corresponding unique test case and a corresponding general test case, wherein the docker corresponding to the low-version software is a second docker;
a low-version software shutdown module: the executable content of the low-version software in the second docker is deleted, and the running of the low-version software is stopped;
the high-version software migration module: the executable content of the high-version software in the first storage space is copied into the second docker;
the high-version software testing module: the system is used for starting the second docker middle and high version software and running a corresponding unique test case and a corresponding general test case;
a test report output module: and the test report is output according to the test result.
8. The system of claim 7, further comprising:
when the second docker middle-high version software cannot be started, the test report result is incompatible;
and when the results and the expectation of the unique test case and the universal test case corresponding to the high-version software are inconsistent, the test report result is incompatible.
9. The system of claim 8, wherein the high-version software testing module further comprises:
a historical data query module: the historical data comparison module is used for comparing whether the historical data obtained by operating the unique test case and the universal test case corresponding to the low-version software is consistent with the preset data or not;
if the test cases are consistent, the high-version software test module continues to run the unique test cases and the general test cases corresponding to the high-version software; and if the test results are not consistent, the test report results are incompatible.
10. The system of claim 7, wherein
The high-version software starting module further comprises a high-version number checking module: the version number of the high-version software is checked to be consistent with the preset version number; if the executable content is consistent with the first storage space of the host machine, copying the executable content to the first storage space of the host machine; if not, stopping operation;
the low-version software testing module further comprises a low-version number checking module: the version number of the low-version software is checked to be consistent with the preset version number; and if the test cases are consistent, the unique test case and the general test case corresponding to the low-version software are operated, and if the test cases are not consistent, the operation is stopped.
11. The system of claims 7-10, further comprising a reset module: and the device is used for deleting the first docker and the second docker and releasing the first storage space after a test report is output according to a test result.
12. A storage medium having stored thereon a computer program which, when executed by one or more processors, performs the steps of the software upgrade compatibility testing method according to any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010799650.2A CN111782250A (en) | 2020-08-11 | 2020-08-11 | Software upgrading compatibility testing method, system and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010799650.2A CN111782250A (en) | 2020-08-11 | 2020-08-11 | Software upgrading compatibility testing method, system and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111782250A true CN111782250A (en) | 2020-10-16 |
Family
ID=72761781
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010799650.2A Pending CN111782250A (en) | 2020-08-11 | 2020-08-11 | Software upgrading compatibility testing method, system and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111782250A (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101196817A (en) * | 2008-01-04 | 2008-06-11 | 福建星网锐捷网络有限公司 | Test case generating method and system |
| CN102045191A (en) * | 2009-10-22 | 2011-05-04 | 华为技术有限公司 | Method and equipment for testing compatibility after upgrading of system |
| CN105446868A (en) * | 2014-08-25 | 2016-03-30 | 阿里巴巴集团控股有限公司 | System compatibility testing method, test case management method and related devices |
| CN106873975A (en) * | 2016-12-30 | 2017-06-20 | 武汉默联股份有限公司 | Devops based on Docker persistently pays and automated system and method |
| CN109002307A (en) * | 2018-06-27 | 2018-12-14 | 郑州云海信息技术有限公司 | A kind of upgrading and automated testing method automatically |
-
2020
- 2020-08-11 CN CN202010799650.2A patent/CN111782250A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101196817A (en) * | 2008-01-04 | 2008-06-11 | 福建星网锐捷网络有限公司 | Test case generating method and system |
| CN102045191A (en) * | 2009-10-22 | 2011-05-04 | 华为技术有限公司 | Method and equipment for testing compatibility after upgrading of system |
| CN105446868A (en) * | 2014-08-25 | 2016-03-30 | 阿里巴巴集团控股有限公司 | System compatibility testing method, test case management method and related devices |
| CN106873975A (en) * | 2016-12-30 | 2017-06-20 | 武汉默联股份有限公司 | Devops based on Docker persistently pays and automated system and method |
| CN109002307A (en) * | 2018-06-27 | 2018-12-14 | 郑州云海信息技术有限公司 | A kind of upgrading and automated testing method automatically |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10140461B2 (en) | Reducing resource consumption associated with storage and operation of containers | |
| US9880837B2 (en) | Artifact manager for release automation | |
| US9274768B2 (en) | Runtime code hooking for print driver and functionality testing | |
| US20180088988A1 (en) | Return Flow Guard Using Control Stack Identified By Processor Register | |
| EP1782191B1 (en) | Method for loading software with an intermediate object oriented language in a portable device | |
| CN110968357B (en) | Method and device for packaging maven item, storage medium and processor | |
| CN110399184B (en) | Method and device for executing intelligent contracts in block chain | |
| CN110716845B (en) | Log information reading method of Android system | |
| US11593091B2 (en) | Method and apparatus for upgrading firmware of transfer device on mobile carrier, and non-transitory storage medium | |
| US11003668B2 (en) | Programming language independent software testing environment | |
| CN108595246B (en) | Method, device and equipment for running application | |
| CN114077460A (en) | Method, equipment and medium for calling Android dynamic library HAL interface by software operating system | |
| CN117707543A (en) | Application installation package manufacturing and installation method, computing device and storage medium | |
| CN112799778A (en) | Container application starting method, device and medium | |
| US20110202903A1 (en) | Apparatus and method for debugging a shared library | |
| CN111782250A (en) | Software upgrading compatibility testing method, system and storage medium | |
| US10901783B2 (en) | Reducing the startup latency of functions in a FaaS infrastructure | |
| CN115617459A (en) | Method, device and equipment for resource scheduling | |
| CN112181606B (en) | Container configuration updating method, device, system, storage medium and electronic equipment | |
| WO2020135129A1 (en) | Method and device for loading plug-in of application, and terminal | |
| CN110515751B (en) | Method and system for loading and running VxWorks real-time protection process | |
| CN110175053B (en) | Picture loading method and device | |
| US12032970B2 (en) | Reducing the startup latency of functions in a FaaS infrastructure | |
| CN112328213B (en) | Isolation method, equipment and medium for online software development process | |
| US11436062B2 (en) | Supporting universal windows platform and Win32 applications in kiosk mode |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20201016 |