WO2019085290A1 - 测试前置实现方法、装置、终端设备及存储介质 - Google Patents

测试前置实现方法、装置、终端设备及存储介质 Download PDF

Info

Publication number
WO2019085290A1
WO2019085290A1 PCT/CN2018/073918 CN2018073918W WO2019085290A1 WO 2019085290 A1 WO2019085290 A1 WO 2019085290A1 CN 2018073918 W CN2018073918 W CN 2018073918W WO 2019085290 A1 WO2019085290 A1 WO 2019085290A1
Authority
WO
WIPO (PCT)
Prior art keywords
system platform
code
test
tested
script
Prior art date
Application number
PCT/CN2018/073918
Other languages
English (en)
French (fr)
Inventor
李坤
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019085290A1 publication Critical patent/WO2019085290A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3696—Methods or tools to render software testable
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management

Definitions

  • the present application relates to the field of software testing, and in particular, to a test preamble implementation method, apparatus, terminal device, and storage medium.
  • test pre-position needs to be implemented to ensure that the system can operate normally.
  • the test pre-position refers to the preparation work that needs to be implemented before the test, including the preparation work such as configuring the test environment conditions and test data conditions.
  • joint testing it is difficult to implement joint testing of the system platform and related subsystems (hereinafter referred to as "joint testing") in the current test front-end, and some main processes in the system platform depend on the associated subsystems, so it is impossible to effectively test before Set, making the test effect is not good.
  • the current test pre-process needs to prepare test data such as the code to be tested. Before the test, the developer needs to submit the code to be tested to the version management tool, and then the handover personnel will submit the code code to be tested of the version management tool. Transfer to the deployment platform, packaged by the deployer and deployed to the corresponding test environment server to complete the handover data process. There is a lot of code to be tested that needs to be deployed in this handover data flow, and the deployment personnel are limited. The manual deployment process requires a lot of labor costs and time costs, resulting in low test efficiency.
  • the embodiment of the present application provides a test pre-implementation method, device, terminal device, and storage medium, so as to solve the problem that the associated subsystem in the test front is difficult to perform joint measurement.
  • an embodiment of the present application provides a test pre-implementation method, including:
  • the executable package is deployed on the system platform and the test preamble is implemented based on at least one of the test environment subsystems in communication with the system platform.
  • test pre-implementation apparatus including:
  • test environment connectivity module for connecting the system platform to the at least one test environment subsystem
  • An executable package obtaining module configured to run the compiled deployment script, to obtain an executable package capable of running on the system platform
  • a deployment module for deploying the executable package on the system platform and implementing a test preamble based on at least one of the test environment subsystems in communication with the system platform.
  • an embodiment of the present application provides a terminal device, including a memory, a processor, and computer readable instructions stored in the memory and executable on the processor, where the processor executes the computer The following steps are implemented when reading the instruction:
  • the executable package is deployed on the system platform and the test preamble is implemented based on at least one of the test environment subsystems in communication with the system platform.
  • an embodiment of the present application provides a computer readable storage medium, where the computer readable storage medium stores computer readable instructions, and when the computer readable instructions are executed by a processor, the following steps are implemented:
  • the executable package is deployed on the system platform and a test preamble is implemented based on at least one of the test environment subsystems in communication with the system platform.
  • the system platform is first connected with at least one test environment subsystem, and the test environment subsystems that can only perform independent system testing are associated with each other.
  • the test environment subsystems are connected to each other, and the test pre-environment can implement joint testing between the associated test environment subsystems to achieve more effective testing.
  • create a compilation deployment script which can simplify the process of handing over the code to be tested by creating a compilation deployment script, which is beneficial to improve the efficiency of the code to be tested.
  • run the compile deployment script to get the executable package that can run on the system platform.
  • the executable package is deployed on the system platform, and the test preamble is implemented based on at least one test environment subsystem connected to the system platform.
  • at least one test environment subsystem connected to the system platform implements test test environment conditions before the test
  • the executable package that can be run on the system platform implements test test data conditions before the test, so as to perform the test before the test.
  • Embodiment 1 is a flow chart of a method for implementing a test preamble in Embodiment 1 of the present application.
  • FIG. 2 is a specific flow chart subsequent to step S10 in FIG. 1.
  • FIG. 3 is a specific flow chart of step S20 of FIG. 1.
  • step S30 of FIG. 1 is a specific flow chart of step S30 of FIG. 1.
  • FIG. 5 is a specific flowchart of step S31 in FIG.
  • FIG. 6 is a schematic block diagram of a test pre-implementation device in Embodiment 2 of the present application.
  • FIG. 7 is a schematic diagram of a terminal device in Embodiment 4 of the present application.
  • FIG. 1 is a flow chart showing a method for implementing a test preamble in this embodiment.
  • the test pre-implementation method is applied to a terminal device configured by a financial institution such as a bank, a securities, and an insurance, and is used for implementing a test pre-test of a financial institution system test, and the joint test between the test environment subsystems can be implemented based on the system platform, and Make the test data transfer process easier to improve test efficiency.
  • the terminal device is a device that can perform human-computer interaction with the user, including but not limited to devices such as a computer, a smart phone, and a tablet.
  • the test pre-implementation method includes the following steps:
  • the system platform refers to the platform used to create the test application environment.
  • the test application environment can be understood as the running environment required for the code to be tested. For example, when testing whether a program can run in an operating system, its test application environment is the operating system; when testing whether a program can support multiple browsers. At runtime, the test application environment is an operating system with multiple browsers installed.
  • the test environment subsystem is relative to a test environment system consisting of multiple test environment subsystems, which is a system that has a specific function in the test environment system and can operate independently.
  • the system platform is installed on the terminal device, and the system platform can be connected to at least one test environment subsystem through a network protocol such as http and T3.
  • the test environment system may be a property insurance system
  • the test environment subsystem included therein may be a test environment subsystem such as a property insurance policy system, a property insurance distribution management system, and a property insurance claims system.
  • the subsystem is a relative concept, and the sub-system can also have the next-level subsystem.
  • the property insurance claims system can also include subsystems such as auto insurance claims system and housing insurance claims system.
  • Each test environment subsystem has Its specific features. When the policy information is added, modified or deleted in the property insurance policy system, the related information in the test environment subsystem such as the corresponding property insurance distribution management system and property insurance claims system will also be modified together. Not independent, but there is a certain relationship.
  • test code When testing the test code, it is often not directly tested on the entire test environment system, but on a specific test code, in at least one test environment subsystem related to the code to be tested, test and test Whether the result meets the expected impact on each test environment subsystem makes the test more purposeful, can effectively test the impact of the code to be tested on the associated test environment subsystem, and has the effect of high test efficiency.
  • the system platform can be a distributed system platform.
  • the distributed system platform can be Mesos+Marathon framework, which can complete the rapid creation, operation, rapid shrinkage, rapid expansion and self-healing of applications.
  • the distributed system platform uses independent IP to enable any cluster to communicate with external IP or traditional IP.
  • the independent IP means that the virtual host has a single IP address.
  • the IP address can be accessed in the address bar of the browser to access the website corresponding to the IP address. If there is no independent IP address, , access to the site can only be accessed by entering a domain name.
  • Independent IP can implement a single IP address for a site, and the same server is not affected by other users.
  • the distributed system platform has a lot of load balancing methods, which can be dynamically adjusted according to the dynamic change of the container (ie, the addition and deletion of the container); the distributed system platform also has independent domain name resolution, which can configure the management database and performance monitoring. Dynamic update.
  • the connection between the configuration and the test environment subsystem is performed on the distributed system platform (the specific method is as follows: the system platform and the test environment are implemented through network protocols such as http and T3.
  • the system is connected to realize that the system platform is connected to at least one test environment subsystem, so that there is no firewall problem between the test environment subsystems connected through the system platform, and between the test application environment and the test environment subsystem built on the system platform There is no need to apply for an additional firewall.
  • the test application environment is created through the distributed system platform, and the test environment subsystems that can only perform independent system testing are associated, the test environment subsystems are connected to each other, and the test code can be tested to achieve more effective testing.
  • the system platform is connected to at least one test environment subsystem for joint testing and individual testing.
  • the joint test is for at least two test environment subsystems. Only one test environment subsystem is equivalent to performing only the individual test of the test code of the system platform, and the test pre-environment condition under the test environment of the test environment subsystem can also be realized, that is, the test environment subsystem can be performed on the system platform.
  • the joint test between the two can also achieve separate testing of the test environment subsystem.
  • step S10 the system platform is connected to at least one test environment subsystem, and then includes the following steps:
  • the network protocol command refers to the instruction operation used in the collection of rules, standards or conventions established in the computer network for data exchange. For example, a computer user in the network communicates with an operator of a mainframe. Because the character sets used by the two terminals are different, the commands entered by the operator are not known to each other. In order to enable the two terminals to communicate, it is necessary to use the instruction operation according to the corresponding network protocol, and each terminal must first convert the characters in the respective character sets into the characters of the standard character set before entering the network transmission to reach the counterpart terminal. It can then be converted to the character of the terminal character set.
  • the network protocol command used may be a telnet command or other network protocol command, and according to the network protocol command, it may be verified whether the system platform and the test environment subsystem are connected. It can be understood that the system platform and the at least one test environment subsystem are connected in step S10, and the connection is not necessarily successful, and the network protocol command is required to check the connection, thereby confirming the connection relationship between the system platform and the test environment subsystem.
  • the test environment subsystems with associated relationships are connected through the system platform to implement the pre-test of the test environment.
  • the disconnected reminder information is output on the system platform.
  • the user reconnects the system platform and the test environment subsystem according to the unconnected reminder information fed back by the system platform, configures according to the environment required for the test, re-imports the test environment subsystem required for the test on the system platform, implements the system platform and at least A test environment subsystem is connected.
  • step S11 is repeated to check the connectivity between the system platform and the test environment subsystem until the connectivity result is confirmed to implement the test pre-configured environment configuration.
  • a script is an executable file written in a specific descriptive language according to a certain format, also known as a macro or batch file. Scripts can usually be called and executed temporarily by the application.
  • a script is an extension of a batch file. It is a program that saves plain text.
  • a script is a combination of a series of actions that control a computer to perform operations, in which a certain logical branch can be implemented. Scripts are closer to natural language than general program development, and can be interpreted without compiling, facilitating rapid development or some lightweight control.
  • the compiled deployment script specifically refers to a script designed to implement data acquisition and data deployment functions according to specific requirements.
  • the code to be tested uploaded by the developer can be obtained in time, and the code to be tested is compiled and packaged into an executable package based on the obtained code to be tested, and the executable can be deployed on the system platform.
  • the package provides a convenient way to obtain the code to be tested in order to implement the pre-test data condition configuration, thereby effectively improving the efficiency of data acquisition and data deployment.
  • step S20 a compiler deployment script is created, which specifically includes the following steps:
  • the script creation tool acquires a script instruction input by the user, and the script instruction is associated with the code to be tested.
  • the script creation tool refers to the tool used to create the compiled deployment script.
  • a script instruction is a specific code instruction that is input by a user in a script creation tool, and is an instruction that performs a specific operation, and the set of the script instructions is a compiled deployment script.
  • Script creation tools include, but are not limited to, Jenkins in this embodiment. Jenkins is a continuous integration tool developed in Java to monitor continuous repetitive work, with continuous software release/test projects and the ability to monitor external call execution. Jenkins is used to create a compiled deployment script that captures the user-entered script instructions to compile the test code based on the script directive to quickly obtain the code to be tested for the test and does not rely on the existing slow data handoff deployment process.
  • the code to be tested refers to the code that needs to be tested on the system platform and at least one test environment subsystem connected to it.
  • the code can be the code of the entire application or the code of a part of the function module of the entire application.
  • the script creation tool Jenkins is installed on the terminal device, and the terminal device may be the same device as the terminal device on which the system platform is installed, or may not be the same device as the terminal device on which the system platform is installed, but the two terminal devices may communicate with each other. Connected.
  • the script creation tool Jenkins creates the compiled deployment script
  • the user obtains a script instruction input by the user, which is for the code to be tested, that is, the script instruction in Jenkins is specific to the code to be tested to be acquired. Code instructions.
  • the script instruction should be associated with the code for obtaining the auto insurance claim module, and should not be related to other modules in the property insurance claim system, such as housing insurance claims.
  • the module's code is associated.
  • S22 Create a compiled deployment script based on the script instructions associated with the code to be tested.
  • the compiled deployment script is created by a script instruction input by the user in the script creation tool and associated with the code to be tested.
  • the user inputs a script instruction associated with the code to be tested to create a compiled deployment script according to the code to be tested that needs to be obtained.
  • the executable package refers to an executable file that can run on the system platform.
  • the executable package can be an executable package such as an EAR package or a JAR package. It is a platform-independent file format that can combine multiple files into one file. Users can bind multiple Java applets and their required components (.class files, images and sounds, etc.) into an executable package, and then download and browse as a single simple HTTP (Hypertext Transfer Protocol) transaction. In the device, which greatly increases the download speed.
  • the compiled deployment script is run, and the executable package for running on the system platform is obtained by the compiled deployment script, where the executable package contains the content of the code to be tested. Understandably, by running the compile deployment script, the code to be tested is converted into an executable package form that can be run on the system platform, and the effective test of the code to be tested is realized.
  • step S30 the compiled deployment script is run to obtain an executable package that can be run on the system platform, and specifically includes the following steps:
  • the version management tool is a tool for managing the system version and system source code.
  • the version management tool may be an SVN (Subversion) platform, and the SVN platform can realize the purpose of jointly developing the same project and sharing resources by multiple people.
  • the SVN platform is used as a code base of the open source software.
  • the developer stores the developed code to be tested on the SVN platform, and associates the code ID to be tested of the code to be tested with the storage address. It can be understood that the SVN platform is communicatively connected with the terminal device where the deployment script is located, so that the terminal device can obtain an executable package that can be run on the system platform from the SVN platform when the compiled deployment script is run.
  • the developer uploads the code to be tested to the version management tool, and the tester then runs the created deployment script on the terminal device, according to the script of the compiled deployment script associated with the code to be tested written by the tester. Directive to get the code to be tested saved in the version management tool.
  • the developer will upload the code to be tested for the new function development to the version management tool, and the tester then runs the compilation associated with the code to be tested. Deploy the script to find the code to be tested corresponding to the new feature to be tested in the version management tool.
  • S32 Compile and package the test code to obtain an executable package that can run on the system platform.
  • the code to be tested that is not compiled and packaged cannot be run and tested on the system platform. Therefore, in this embodiment, the compiled and deployed script is required to compile and package the obtained code to be tested, and convert it into an executable package to obtain An executable package that can run on a system platform.
  • step S31 running a compiled deployment script on the system platform to obtain the code to be tested from the version management tool includes the following steps:
  • S311 Run a compiled deployment script to obtain a storage address associated with the code ID to be tested.
  • the code to be tested refers to an identifier for uniquely identifying the code to be tested.
  • Each code to be tested represents the function of a respective module, and the code to be tested is an identifier for uniquely distinguishing these functional modules.
  • the created compiled deployment script is executed, and the script instruction in the compiled deployment script is associated with the code to be tested, and running the compiled deployment script can be understood as executing the script instruction associated with the code to be tested.
  • the script instruction is an instruction that compiles a specific operation in the deployment script.
  • one of the instructions is an instruction to obtain a memory address associated with the code to be tested.
  • Run the compile deployment script to obtain the storage address associated with the code ID to be tested, which can realize the automatic, flexible and fast acquisition of the code to be tested by using the compile and deploy script, without relying on the traditional manual acquisition method, and improving the acquisition of the code to be tested. s efficiency.
  • S312 Obtain a code to be tested according to the storage address.
  • the code ID to be tested of the code to be tested is associated with the storage address, and the code to be tested stored in the memory can be obtained by the storage address.
  • the code to be tested represents a code of a function module for testing, and the code ID to be tested is associated with a storage address of the code to be tested.
  • the code to be tested of the auto insurance claim module is newly added, and the code to be tested of the auto insurance claim module is associated with the storage address thereof, and is not associated with the functional modules represented by other code to be tested.
  • the storage address obtained by running the compilation deployment script is a specific storage address of the code to be tested in the memory, and the compiled deployment script automatically acquires the code to be tested stored in the corresponding memory according to the storage address.
  • S40 Deploying the executable package on the system platform, and implementing the test preamble based on at least one test environment subsystem connected to the system platform.
  • the test preposition refers to the preparatory work required before completing the test code, which includes testing the pre-environment conditions and testing the pre-data conditions.
  • the system platform is deployed, that is, after the test environment subsystem is connected to the system platform on the system platform, the test pre-data condition is deployed on the system platform, and the executable package is deployed on the system platform.
  • the compiled deployment script will deploy the executable package to the system platform.
  • the process of deploying an executable package is to compile and package the code to be tested originally in the version management tool into an executable package and install the process to be transferred to the system platform.
  • test pre-conditions and test pre-data conditions are implemented by deploying an executable package to implement test pre-fetching.
  • step S40 deploying the executable package on the system platform includes: associating the executable package with a domain name and a port number of the system platform.
  • Domain Name is the name of a computer or group of computers on the Internet consisting of a series of dot-separated names for identifying the electronic location of the computer during data transmission (sometimes referred to as geographic location, geography)
  • the domain name refers to a local area with administrative autonomy).
  • a domain name is the address of a group of servers (such as websites, emails, etc.) that are easy to remember and communicate.
  • the port number refers to the port in the TCP/IP protocol (Transmission Control Protocol/Internet Protocol). The port number ranges from 0 to 65535. For example, port 80 for browsing web services. 21 ports for file transfer protocol services, and so on.
  • the executable package after obtaining the executable package, should be associated with the domain name and port number of the system platform, so that the test can be performed when the associated subsystem is tested. Specifically, when at least two test environment subsystems are jointly tested, at least two test environment subsystems are selected on the system platform, and the domain name and port number are associated with the executable package selected for testing, so that at least two The test environment subsystem can simultaneously run the executable package, test the executable package, and feed back the test result to the system platform, thereby implementing joint testing of at least two test environment subsystems based on the system platform.
  • step S40 the executable package is deployed on the system platform, and further includes: restarting a server of the system platform, and updating the executable file deployed on the system platform. package.
  • the server package may be restarted to obtain a list of executable packages. And after the update, the list of executable packages will display information about all the executable packages that were retrieved. When there is an executable package just deployed in the list of executable packages displayed after restarting the system platform, the deployment is really completed.
  • the executable package deployed on the system platform is updated, that is, the test pre-data condition is completed, and the test pre-conditions are completed by combining at least one test environment subsystem and the system platform to complete the test pre-condition.
  • the system platform is first connected to at least one test environment subsystem, and the test application environment is created through the system platform, and the test environment subsystems that can only perform independent system testing are associated with each other.
  • the test environment subsystems are connected to each other, and the test application environment created by the system platform can implement joint testing between the associated test environment subsystems to implement test pre-test environment conditions.
  • compile deployment script which automatically takes the test code to get, compile, package, and deploy.
  • Compile the deployment script to obtain an executable package that can run on the system platform, compile and package the obtained code to be tested stored in the version management tool into an executable package that can be run on the system platform, and quickly obtain the test pre-data.
  • An executable package associated with the test code is deployed on the system platform, and the test preamble is implemented based on at least one test environment subsystem connected to the system platform.
  • At least one test environment subsystem connected to the system platform implements a pre-test environment condition for testing pre-test, and an executable package capable of running the test on the system platform implements a test pre-data condition of the test pre-test, Before the test, the preparation of the test pre-environment and the test pre-data is completed, and the purpose of the test environment subsystem joint measurement, the data transfer process is simple, and the test efficiency is high.
  • FIG. 6 is a schematic block diagram showing a test pre-implementation device corresponding to the test pre-implementation method in Embodiment 1.
  • the test pre-implementation device includes a test environment connectivity module 10, a compiled deployment script creation module 20, an executable package acquisition module 30, and a deployment module 40.
  • the implementation functions of the test environment connectivity module 10, the compilation deployment script creation module 20, the executable package acquisition module 30, and the deployment module 40 correspond to the steps corresponding to the test pre-implementation method in the first embodiment, in order to avoid redundancy, The examples are not described in detail.
  • the test environment connectivity module 10 is configured to communicate the system platform with at least one test environment subsystem.
  • the build deployment script creation module 20 is used to create a build deployment script.
  • the executable package obtaining module 30 is configured to run the compiled deployment script to obtain an executable package that can be run on the system platform.
  • the deployment module 40 is configured to deploy the executable package on the system platform, and implement the test pre-configuration based on at least one test environment subsystem connected to the system platform.
  • the compiled deployment script creation module 20 includes a script instruction acquisition unit 21 and an instruction creation unit 22.
  • the script instruction obtaining unit 21 is configured to acquire a script instruction input by a user, and the script instruction is associated with the code to be tested.
  • the instruction creation unit 22 is configured to create a compilation deployment script based on the script instructions associated with the code to be tested.
  • the executable package acquisition module 30 includes a test code acquisition unit 31 and a compilation packaging unit 32.
  • the test code obtaining unit 31 is configured to run a compiled deployment script on the system platform to obtain the code to be tested from the version management tool.
  • the compiling and packaging unit 32 is configured to compile and package the test code to obtain an executable package that can be run on the system platform.
  • the code to be tested acquisition unit 31 includes a storage address acquisition subunit 311 and an addressing subunit 312.
  • the storage address obtaining sub-unit 311 is configured to run a compiled deployment script to obtain a storage address associated with the code ID to be tested.
  • the addressing sub-unit 312 is configured to obtain a code to be tested according to the storage address.
  • the embodiment provides a computer readable storage medium on which computer readable instructions are stored.
  • the test preamble implementation method in Embodiment 1 is implemented. I won't go into details here.
  • the computer readable instructions are executed by the processor, the functions of the modules/units in the pre-implementation implementation in Embodiment 2 are implemented. To avoid repetition, details are not described herein again.
  • Fig. 7 is a schematic diagram of a terminal device in this embodiment.
  • terminal device 70 includes a processor 71, a memory 72, and computer readable instructions 73 stored in memory 72 and operative on processor 71.
  • the processor 71 implements the various steps of the test pre-implementation method of Embodiment 1 when the computer readable instructions 73 are executed, such as steps S10, S20, S30, and S40 shown in FIG.
  • the processor 71 executes the computer readable instructions 73
  • the functions of each module/unit of the test preamble implementation device in Embodiment 2 are implemented, as shown in FIG. 6, the test environment connectivity module 10, the compiled deployment script creation module 20, and the executable package.
  • the functions of module 30 and deployment module 40 are obtained.
  • computer readable instructions 73 may be partitioned into one or more modules/units, one or more modules/units being stored in memory 72 and executed by processor 71 to complete the application.
  • the one or more modules/units may be an instruction segment of a series of computer readable instructions 73 capable of performing a particular function for describing the execution of computer readable instructions 73 in the terminal device 70.
  • the computer readable instructions 73 can be divided into the test environment connectivity module 10, the compiled deployment script creation module 20, the executable package acquisition module 30, and the deployment module 40 in Embodiment 2, and the specific functions of each module are as in Embodiment 2. In order to avoid repetition, we will not repeat them here.
  • the terminal device 70 can be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • the terminal device may include, but is not limited to, a processor 71, a memory 72. It will be understood by those skilled in the art that FIG. 7 is merely an example of the terminal device 70, and does not constitute a limitation of the terminal device 70, and may include more or less components than those illustrated, or may combine certain components or different components.
  • the terminal device may further include an input/output device, a network access device, a bus, and the like.
  • the processor 71 may be a central processing unit (CPU), or may be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the memory 72 may be an internal storage unit of the terminal device 70, such as a hard disk or a memory of the terminal device 70.
  • the memory 72 may also be an external storage device of the terminal device 70, such as a plug-in hard disk provided on the terminal device 70, a smart memory card (SMC), a Secure Digital (SD) card, and a flash memory card (Flash). Card) and so on.
  • the memory 72 may also include both an internal storage unit of the terminal device 70 and an external storage device.
  • Memory 72 is used to store computer readable instructions as well as other programs and data required by the terminal device.
  • the memory 72 can also be used to temporarily store data that has been or will be output.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the integrated modules/units if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium.
  • the present application implements all or part of the processes in the foregoing embodiments, and may also be implemented by computer readable instructions, which may be stored in a computer readable storage medium.
  • the computer readable instructions when executed by a processor, may implement the steps of the various method embodiments described above.
  • the computer readable instructions include a computer to be tested code, and the computer to be tested code may be in the form of source code, an object code form, an executable file, or some intermediate form.
  • the computer readable medium may include any entity or device capable of carrying the computer to be tested code, a recording medium, a USB flash drive, a removable hard disk, a magnetic disk, an optical disk, a computer memory, a read only memory (ROM, Read-Only Memory). ), random access memory (RAM), electrical carrier signals, telecommunications signals, and software distribution media.
  • a recording medium a USB flash drive
  • a removable hard disk a magnetic disk, an optical disk
  • a computer memory a read only memory (ROM, Read-Only Memory).
  • RAM random access memory
  • electrical carrier signals telecommunications signals
  • software distribution media may be appropriately increased or decreased according to the requirements of legislation and patent practice in a jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, computer readable media It does not include electrical carrier signals and telecommunication signals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

一种测试前置实现方法、装置、终端设备及存储介质。该测试前置实现方法，包括：将系统平台和至少一个测试环境子系统相连通（S10）；创建编译部署脚本（S20）；运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包（S30）；将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置（S40）。该测试前置实现方法能够实现测试前置中相关联子系统之间进行联测的目的和实现测试效率高的效果。

Description

测试前置实现方法、装置、终端设备及存储介质
本专利申请以2017年10月31日提交的申请号为201711040815.2，名称为“测试前置实现方法、装置、终端设备及存储介质”的中国发明专利申请为基础，并要求其优先权。
技术领域
本申请涉及软件测试领域，尤其涉及一种测试前置实现方法、装置、终端设备及存储介质。
背景技术
当前银行、证券和保险等金融机构或者其他机构在生产经营过程中，需开发与机构经营范围相关的系统，且任一系统与至少一个相关联子系统相连。如保险机构需开发与保险相关的电话销售系统，该电话销售系统可能与机构内部的办公系统、售后服务系统等相关联子系统相连。当前系统开发测试过程中，需实现测试前置，以保证系统能够正常运行。其中，测试前置是指在测试之前需实现的准备工作，主要包括配置测试环境条件和测试数据条件等准备工作。当前测试前置难以实现对系统平台与相关联子系统进行联合测试(以下简称为“联测”)，而系统平台中部分主流程又依赖于相关联子系统，因此无法有 效地做到测试前置，使得测试效果不好。此外，当前测试前置过程需准备待测试代码等测试数据，在测试前置时需由开发人员将待测试代码提交到版本管理工具后，再由移交人员将提交版本管理工具的待测试代码代码移交到部署平台，由部署人员进行打包并部署到对应的测试环境服务器上，以完成移交数据流程。这种移交数据流程中需要部署的待测试代码又非常多，部署人员有限，人工部署过程需耗费大量的人工成本和时间成本，导致测试效率较低。
发明内容
本申请实施例提供一种测试前置实现方法、装置、终端设备及存储介质，以解决测试前置中相关联子系统难以进行联测的问题。
第一方面，本申请实施例提供一种测试前置实现方法，包括：
将系统平台和至少一个测试环境子系统相连通；
创建编译部署脚本；
运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置。
第二方面，本申请实施例提供一种测试前置实现装置，包括：
测试环境连通模块，用于将系统平台和至少一个测试环境子系统相连通；
编译部署脚本创建模块，用于创建编译部署脚本；
可执行包获取模块，用于运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
部署模块，用于将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置。
第三方面，本申请实施例提供一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现如下步骤：
将系统平台和至少一个测试环境子系统相连通；
创建编译部署脚本；
运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置。
第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如下步骤：
将系统平台和至少一个测试环境子系统相连通；
创建编译部署脚本；
运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
将所述可执行包部署在所述系统平台上，并基于与所述系统平台 相连通的至少一个所述测试环境子系统，实现测试前置。
本申请实施例提供的测试前置实现方法、装置、终端设备及存储介质中，首先将系统平台和至少一个测试环境子系统相连通，将原本只能进行独立系统测试的测试环境子系统关联起来，实现测试环境子系统相互之间的连通，通过该测试前置环境能够对相关联的测试环境子系统之间实现联测，实现更有效的测试。接着创建编译部署脚本，通过创建编译部署脚本能够简化移交待测试代码的流程，有利于提高待测试代码移交的效率。然后运行编译部署脚本，获取能够在系统平台上运行的可执行包，通过编译部署脚本获取可执行包使得获取测试所需的数据更加方便快捷。最后将可执行包部署在系统平台上，并基于与系统平台相连通的至少一个测试环境子系统，实现测试前置。其中，与系统平台相连通的至少一个测试环境子系统实现了测试前置的测试环境条件，能够在系统平台上运行的可执行包实现了测试前置的测试数据条件，为进行测试之前做好了测试环境和测试数据方面的准备，实现测试环境子系统联测的目的，达到提高测试效率高的效果。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例1中测试前置实现方法的一流程图。
图2是图1中步骤S10之后的一具体流程图。
图3是图1中步骤S20的一具体流程图。
图4是图1中步骤S30的一具体流程图。
图5是图4中步骤S31的一具体流程图。
图6是本申请实施例2中测试前置实现装置的一原理框图。
图7是本申请实施例4中终端设备的一示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
实施例1
图1示出本实施例中测试前置实现方法的流程图。该测试前置实现方法应用在银行、证券和保险等金融机构配置的终端设备中，用于实现金融机构系统测试的测试前置，可基于系统平台实现测试环境子系统之间的联测，并使得测试数据移交流程更简便，以提高测试效率。其中，该终端设备是可与用户进行人机交互的设备，包括但不限于电脑、智能手机和平板等设备。如图1所示，该测试前置实现方法包括如下步骤：
S10：将系统平台和至少一个测试环境子系统相连通。
其中，系统平台是指用于创建测试应用环境的平台。测试应用环境可以理解为待测试代码所需的运行环境，例如当测试一个程序能否在一操作系统中运行，则其测试应用环境为该操作系统；当测试一个程序能否支持多个浏览器运行时，则其测试应用环境为安装有多个浏览器的操作系统。测试环境子系统是相对于一个由多个测试环境子系统组成的测试环境系统而言的，是测试环境系统中具有某一特定功能并且能独立运行的系统。具体地，系统平台安装在终端设备上，可以通过http、T3等网络协议将系统平台与至少一个测试环境子系统连通起来。
本实施例中，测试环境系统可以为财产保险系统，其包含的测试环境子系统可以为财产保险保单系统、财产保险配送管理系统和财产保险理赔系统等测试环境子系统。其中，子系统是一个相对的概念，子系统中也可以有下一级的子系统，如财产保险理赔系统还可以包括车险理赔系统、房险理赔系统等子系统，每一测试环境子系统具有其特定功能。在财产保险保单系统中增加、修改或删除保单信息时，对应的财产保险配送管理系统、财产保险理赔系统等测试环境子系统中的相关联信息也将会一并修改，其原因在于这些系统并不是独立的，而是存在一定关联关系的。在对待测试代码进行测试时，往往不是对整个测试环境系统直接进行测试，而是对某一具体的待测试代码，在与该待测试代码相关的至少一个测试环境子系统中进行测试，检验测试结果是否符合预期对各个测试环境子系统的影响，使得测试更具备 目的性，能够有效测试待测试代码对相关联测试环境子系统的影响，并且具有测试效率高的效果。
本实施例中，该系统平台可以是一种分布式系统平台。该分布式系统平台采用的可以是Mesos+Marathon框架，能够完成应用程序的快速创建、运行、快速缩容、快速扩容以及故障自愈的功能。该分布式系统平台采用独立IP，可以实现任何集群与外部的IP或者传统的IP进行通讯。其中，独立IP是指虚拟主机有一个单独的IP地址，用户除了可以根据域名进行访问的方式外，在浏览器的地址栏输入IP地址也能访问该IP地址对应的网站；如果没有独立IP的话，访问该网站只能通过输入域名才能进行访问。独立IP可以实现一个站点对应一个单独的IP地址，且同一台服务器不受其他用户影响，具有防攻击、安全性高和搜索引擎收录快的优点。该分布式系统平台负载均衡的方式很多，可以根据容器的动态变化(即容器的增删)做动态调整；该分布式系统平台内还有独立的域名解析，可以做到配置管理数据库和性能监控的动态更新。用户通过分布式系统平台进行测试前置的环境配置时，在分布式系统平台上通过配置与测试环境子系统之间的连通(具体方式如通过http、T3等网络协议将系统平台与测试环境子系统连通起来)，实现系统平台和至少一个测试环境子系统相连通，使得测试环境子系统之间通过系统平台连通不存在防火墙问题，在系统平台上搭建的测试应用环境和测试环境子系统之间无需另外申请开通防火墙的操作。通过分布式系统平台创建测试应用环境，将原本只能进行独立系统测试的测试环境子系统关联起来，实现测试 环境子系统相互之间的连通，能够对待测试代码实现更有效的测试。
需要特别指出的是，系统平台和至少一个测试环境子系统相连通，可实现联测和单独测试。联测是针对至少两个测试环境子系统而言的。而只有一个测试环境子系统相当于只进行该系统平台对待测试代码的单独测试，同样能够实现测试环境子系统单独测试情况下的测试前置环境条件，即在系统平台上可以进行测试环境子系统之间的联测也可以实现对测试环境子系统的单独测试。
在一具体实施方式中，如图2所示，步骤S10中，将系统平台和至少一个测试环境子系统相连通，之后还包括如下步骤：
S11：采用网络协议命令检验系统平台和测试环境子系统是否连通。
其中，网络协议命令是指计算机网络中为了进行数据交换而建立的规则、标准或约定的集合所采用的指令操作。例如，网络中一个微机用户和一个大型主机的操作员进行通信，由于这两个终端所用字符集不同，因此操作员所输入的命令彼此不认识。为了使两个终端能够进行通信，需根据对应的网络协议采用指令操作规定每个终端都要将各自字符集中的字符先变换为标准字符集的字符后，才进入网络传送，使其到达对方终端后可变换为该终端字符集的字符。
本实施例中，采用的网络协议命令可以是telnet命令或其他网络协议命令，根据该网络协议命令可以检验系统平台和测试环境子系统是否连通。可以理解地，步骤S10中将系统平台和至少一个测试环境子系统相连通，该连通并非一定能成功，需通过网络协议命令对其 进行检验，从而确认系统平台和测试环境子系统间的连通关系，将具有关联关系的测试环境子系统通过系统平台连通，实现测试环境的前置。测试环境子系统之间通过系统平台连通不存在防火墙问题，使得在系统平台上搭建的测试应用环境和测试环境子系统之间无需另外申请开通防火墙的操作，有利于实现系统平台与测试环境子系统之间的联测。
S12：若未连通，则输出未连通提醒信息，重新将系统平台和测试环境子系统相连通。
本实施例中，若通过网络协议命令检验系统平台和测试环境子系统的连通结果为不连通，则在系统平台上输出未连通提醒信息。用户根据系统平台反馈的未连通提醒信息，重新连通系统平台和测试环境子系统，根据测试所需的环境进行配置，在系统平台上重新导入测试所需的测试环境子系统，实现系统平台和至少一个测试环境子系统相连通。在重新导入完成之后，需重复步骤S11，检验系统平台和测试环境子系统之间的连通，直至确认连通结果，以实现测试前置的环境配置。
S20：创建编译部署脚本。
其中，脚本是使用一种特定的描述性语言，依据一定的格式编写的可执行文件，又称作宏或批处理文件。脚本通常可以由应用程序临时调用并执行。脚本是批处理文件的延伸，是一种纯文本保存的程序，一般来说，脚本是确定的一系列控制计算机进行运算操作动作的组合，在其中可以实现一定的逻辑分支等。脚本相对一般程序开发来说比较 接近自然语言，可以不经编译而是解释执行，利于快速开发或一些轻量的控制。
本实施例中，编译部署脚本具体是指根据特定的需求设计出的能够实现数据获取和数据部署功能的脚本。通过创建该编译部署脚本，可以及时地获取开发人员上传的待测试代码，并基于获取到的待测试代码，将待测试代码编译和打包成可执行包，并在系统平台上进行部署该可执行包，为实现测试前置的数据条件配置提供便捷的待测试代码获取方式，即可有效提高数据获取和数据部署的效率。
在一具体实施方式中，如图3所示，步骤S20中，创建编译部署脚本，具体包括如下步骤：
S21：脚本创建工具获取用户输入的脚本指令，脚本指令与待测试代码相关联。
其中，脚本创建工具是指用于创建编译部署脚本的工具。脚本指令是指用户在脚本创建工具中进行开发而输入的具体代码指令，是执行某一具体操作的指令，这些脚本指令的集合即为编译部署脚本。脚本创建工具包括但不限于本实施例中的Jenkins。Jenkins是基于Java开发的一种持续集成工具，用于监控持续重复的工作，具有持续的软件版本发布/测试项目和监控外部调用执行工作的功能。采用Jenkins创建编译部署脚本，通过获取用户输入的脚本指令，以便基于该脚本指令对待测试代码进行编译，以快速获取测试所需的待测试代码，并且不依赖现有缓慢的数据移交部署流程。
待测试代码是指需在系统平台和与其连通的至少一个测试环境 子系统进行测试的代码。该代码可以是整个应用程序的代码，也可以是整个应用程序部分功能模块的代码。
本实施例中，脚本创建工具Jenkins安装在终端设备上，该终端设备可以与安装系统平台的终端设备为同一设备，也可以与安装系统平台的终端设备不为同一设备但两个终端设备可通信相连。用户在脚本创建工具Jenkins创建编译部署脚本时，获取用户输入的脚本指令，该脚本指令是针对待测试代码而言的，即该脚本指令在Jenkins中是与要获取的待测试代码相关联的具体代码指令。
具体地，如待测试代码为财产保险理赔系统中车险理赔模块的代码，则该脚本指令应与获取该车险理赔模块的代码相关联，而不应该与财产保险理赔系统中其他模块如房险理赔模块的代码相关联。通过脚本指令与待测试代码相关联，可以灵活地获取待测试代码，只需根据待测试代码进行脚本指令的修改，即可将脚本指令与待测试代码相关联，达到快速获取待测试代码的目的。
S22：基于与待测试代码相关联的脚本指令，创建编译部署脚本。
本实施例中，编译部署脚本是通过用户在脚本创建工具输入的脚本指令进行创建的，并与待测试代码相关联的脚本。在实际进行测试过程中，根据所需获取的待测试代码，用户输入与待测试代码相关联的脚本指令创建编译部署脚本。
S30：运行编译部署脚本，获取能够在系统平台上运行的可执行包。
其中，可执行包是指能够在系统平台上运行的可执行文件。该可 执行包可以是EAR包、JAR包等可执行包，是一种与平台无关的文件格式，可将多个文件合成一个文件。用户可将多个Java applet及其所需组件(.class文件、图像和声音等)绑定到可执行包中，而后作为单个简单的HTTP(Hypertext Transfer Protocol，超文本传输协议)事务下载到浏览器中，从而大大提高下载速度。本实施例中，运行编译部署脚本，通过该编译部署脚本获取用于在系统平台运行的可执行包，其中，该可执行包包含了待测试代码的内容。可以理解地，通过运行编译部署脚本，将待测试代码转换为能够在系统平台运行的可执行包形式，实现了对待测试代码的有效测试。
在一具体实施方式中，如图4所示，步骤S30中，运行编译部署脚本，获取能够在系统平台上运行的可执行包，具体包括如下步骤：
S31:在系统平台上运行编译部署脚本，以从版本管理工具获取待测试代码。
其中，版本管理工具是用于对系统版本和系统源代码进行管理的工具。本实施例中，版本管理工具可以是SVN(Subversion)平台，SVN平台能实现多个人共同开发同一个项目，共用资源的目的。SVN平台作为开源软件的代码库，开发人员将开发完成的待测试代码存储在SVN平台上，并使该待测试代码的待测试代码ID与存储地址关联。可以理解地，SVN平台与编译部署脚本所在的终端设备通信相连，以使终端设备可在运行编译部署脚本时，能够从SVN平台上获取可在系统平台上运行的可执行包。开发人员在开发系统的过程中，将待测试代码上传到版本管理工具后，测试人员随即在终端设备运行创建的编 译部署脚本，根据测试人员编写的与待测试代码相关联的编译部署脚本的脚本指令，获取保存在版本管理工具的待测试代码。
具体地，若需对开发人员新开发的一项新功能进行测试，则开发人员会将新功能开发的待测试代码上传到版本管理工具中，测试人员随后运行与该待测试代码相关联的编译部署脚本，查找版本管理工具中与待测试新功能对应的待测试代码。
S32：对待测试代码进行编译和打包，获取能够在系统平台上运行的可执行包。
未进行编译和打包的待测试代码是不能在系统平台上运行并测试的，因此，本实施例中需采用编译部署脚本将获取的待测试代码进行编译和打包，转换成能可执行包，获取能够在系统平台上运行的可执行包。
在一具体实施方式中，如图5所示，步骤S31中，在系统平台上运行编译部署脚本，以从版本管理工具获取待测试代码，具体包括如下步骤：
S311：运行编译部署脚本，获取与待测试代码ID相关联的存储地址。
其中，待测试代码ID是指用于唯一识别待测试代码的标识。每一待测试代码代表各自一模块的功能，待测试代码ID就是用于唯一区分这些功能模块的标识。
本实施例中，运行已创建好的编译部署脚本，该编译部署脚本中的脚本指令是与待测试代码相关联的，则运行编译部署脚本可以理解 为执行与待测试代码相关联的脚本指令，该脚本指令为编译部署脚本中具有某一具体操作的指令。在执行脚本指令的过程中，其中有一指令是获取与待测试代码相关联的存储地址的指令。运行编译部署脚本，获取与待测试代码ID相关联的存储地址，可以实现运用编译部署脚本自动、灵活和快速地获取待测试代码，而不必依赖于传统的人工获取方式，提高了获取待测试代码的效率。
S312：根据存储地址获取待测试代码。
待测试代码的待测试代码ID是与存储地址相关联的，则通过该存储地址就可以获取存储在内存中的待测试代码。本实施例中，待测试代码代表是指进行测试的某一功能模块的代码，该待测试代码ID与该待测试代码的存储地址相关联。例如财产保险理赔系统中刚刚新增了车险理赔模块的待测试代码，则将该车险理赔模块的待测试代码ID与其存储地址相关联，而不与其他待测试代码代表的功能模块相关联。具体地，通过运行编译部署脚本获取的存储地址，为待测试代码在内存中具体的存储地址，则编译部署脚本将根据存储地址自动获取对应内存中存储的待测试代码。
S40：将可执行包部署在系统平台上，并基于与系统平台相连通的至少一个测试环境子系统，实现测试前置。
其中，测试前置是指完成对待测试代码之前所需的预备工作，该预备工作包括测试前置环境条件和测试前置数据条件。本实施例中，对系统平台进行部署，即在系统平台上实现测试环境子系统与系统平台的连通之后，在系统平台上实现测试前置数据条件的部署，即将可 执行包在系统平台上部署，具体地，在通过编译部署脚本获取待测试代码编译打包而成的可执行包后，编译部署脚本将会部署该可执行包到系统平台中去。部署可执行包的过程就是将原本在版本管理工具中的待测试代码编译和打包成可执行包，并安装转移到在系统平台上的过程。通过在系统平台上部署可执行包，可以实现将待测试代码部署到一个能够实现测试环境子系统联测的系统平台上去。各个测试环境子系统在系统平台上连通不存在防火墙问题，无需另外开通防火墙的操作，使得测试的效率更高，并且实现测试环境子系统之间的联测。通过部署可执行包完成测试前置环境条件和测试前置数据条件，以实现测试前置。
在一具体实施方式中，步骤S40中，将可执行包部署在所述系统平台上，包括：将可执行包与系统平台的域名和端口号相关联。
其中，域名(Domain Name)，是由一串用点分隔的名字组成的因特网上某一台计算机或计算机组的名称，用于在数据传输时标识计算机的电子方位(有时也指地理位置，地理上的域名，指代有行政自主权的一个地方区域)。域名是便于记忆和沟通的一组服务器的地址(如网站，电子邮件等)。端口号是指TCP/IP协议(Transmission Control Protocol/Internet Protocol，中译名为传输控制协议/因特网互联协议)中的端口，端口号的范围从0到65535，比如用于浏览网页服务的80端口，用于文件传输协议服务的21端口等等。
本实施例中，在获取可执行包之后应将可执行包与系统平台的域名和端口号相关联，以使在进行关联子系统联测时可以进行测试。具 体地，当在实现至少两个测试环境子系统联测时，在系统平台上选择至少两个测试环境子系统，将其域名和端口号与选择要测试的可执行包关联，以使至少两个测试环境子系统可同时运行该可执行包，对该可执行包进行测试，并向系统平台反馈测试结果，从而实现基于系统平台实现至少两个测试环境子系统的联测。
在一具体实施方式中，步骤S40中，将所述可执行包部署在所述系统平台上，之后还包括：重启所述系统平台的服务器，更新部署在所述系统平台上的所述可执行包。
本实施例中，通过系统平台部署可执行包后，可以通过重启系统平台的服务器，更新获取可执行包列表。并在更新之后，可执行包列表将会显示重新获取的所有可执行包的信息。当重启系统平台后显示的可执行包列表中有刚刚部署的可执行包，则表示部署真正地完成。更新了部署在系统平台上的可执行包，即完成了测试前置数据条件，结合至少一个测试环境子系统与系统平台相连通完成的测试前置环境条件，实现了测试前置。
本实施例所提供的测试前置实现方法中，首先将系统平台和至少一个测试环境子系统相连通，通过系统平台创建测试应用环境，将原本只能进行独立系统测试的测试环境子系统关联起来，实现测试环境子系统相互之间的连通，通过该系统平台创建的测试应用环境能够对相关联的测试环境子系统之间实现联测，实现测试前置的测试前置环境条件。接着创建编译部署脚本，并基于编译部署脚本获取能够在系统平台上运行的可执行包，从而简化移交待测试代码的流程，有利于 高效地获取存储在版本管理工具的待测试代码，而无需依赖于繁琐的传统移交待测试代码流程。然后运行编译部署脚本，编译部署脚本能够自动地对待测试代码进行获取、编译、打包和部署的操作。编译部署脚本获取能够在系统平台上运行的可执行包，将获取的存储在版本管理工具的待测试代码编译并打包成可在系统平台上运行的可执行包，能够快速获取测试前置数据即与测试代码相关的可执行包。最后将可执行包部署在系统平台上，并基于与系统平台相连通的至少一个测试环境子系统，实现测试前置。其中，与系统平台相连通的至少一个测试环境子系统实现了测试前置的测试前置环境条件，能够在系统平台上运行测试的可执行包实现了测试前置的测试前置数据条件，为进行测试之前做好了测试前置环境和测试前置数据方面的准备，实现了测试环境子系统联测的目的、数据移交流程简便和测试效率高的效果。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
实施例2
图6示出与实施例1中测试前置实现方法一一对应的测试前置实现装置的原理框图。如图6所示，该测试前置实现装置包括测试环境连通模块10、编译部署脚本创建模块20、可执行包获取模块30和部署模块40。其中，测试环境连通模块10、编译部署脚本创建模块20、可执行包获取模块30和部署模块40的实现功能与实施例1中测试前 置实现方法对应的步骤一一对应，为避免赘述，本实施例不一一详述。
测试环境连通模块10，用于将系统平台和至少一个测试环境子系统相连通。
编译部署脚本创建模块20，用于创建编译部署脚本。
可执行包获取模块30，用于运行编译部署脚本，获取能够在系统平台上运行的可执行包。
部署模块40，用于将可执行包部署在系统平台上，并基于与系统平台相连通的至少一个测试环境子系统，实现测试前置。
优选地，编译部署脚本创建模块20包括脚本指令获取单元21和指令创建单元22。
脚本指令获取单元21，用于脚本创建工具获取用户输入的脚本指令，脚本指令与待测试代码相关联。
指令创建单元22，用于基于与待测试代码相关联的脚本指令，创建编译部署脚本。
优选地，可执行包获取模块30包括测试代码获取单元31和编译打包单元32。
测试代码获取单元31，用于在系统平台上运行编译部署脚本，以从版本管理工具获取待测试代码。
编译打包单元32，用于对待测试代码进行编译和打包，获取能够在系统平台上运行的可执行包。
优选地，待测试代码获取单元31包括存储地址获取子单元311和寻址子单元312。
存储地址获取子单元311，用于运行编译部署脚本，获取与待测试代码ID相关联的存储地址。
寻址子单元312，用于根据存储地址获取待测试代码。
实施例3
本实施例提供一计算机可读存储介质，该计算机可读存储介质上存储有计算机可读指令，该计算机可读指令被处理器执行时实现实施例1中测试前置实现方法，为避免重复，这里不再赘述。或者，该计算机可读指令被处理器执行时实现实施例2中测试前置实现中各模块/单元的功能，为避免重复，这里不再赘述。
实施例4
图7是本实施例中终端设备的示意图。如图7所示，终端设70包括处理器71、存储器72以及存储在存储器72中并可在处理器71上运行的计算机可读指令73。处理器71执行计算机可读指令73时实现实施例1中测试前置实现方法的各个步骤，例如图1所示的步骤S10、S20、S30和S40。或者，处理器71执行计算机可读指令73时实现实施例2中测试前置实现装置各模块/单元的功能，如图6所示测试环境连通模块10、编译部署脚本创建模块20、可执行包获取模块30和部署模块40的功能。
示例性的，计算机可读指令73可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器72中，并由处理器71执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令73的指令段，该指令段用于描述计算 机可读指令73在终端设备70中的执行过程。例如，计算机可读指令73可被分割成实施例2中的测试环境连通模块10、编译部署脚本创建模块20、可执行包获取模块30和部署模块40，各模块的具体功能如实施例2所示，为避免重复，此处不一一赘述。
终端设备70可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。终端设备可包括，但不仅限于，处理器71、存储器72。本领域技术人员可以理解，图7仅仅是终端设备70的示例，并不构成对终端设备70的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器71可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
存储器72可以是终端设备70的内部存储单元，例如终端设备70的硬盘或内存。存储器72也可以是终端设备70的外部存储设备，例如终端设备70上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，存储器72还可以既包括终端设备70的内部存 储单元也包括外部存储设备。存储器72用于存储计算机可读指令以及终端设备所需的其他程序和数据。存储器72还可以用于暂时地存储已经输出或者将要输出的数据。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一计算机可读存储介质中，该计算机可读指令在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机可读指令包括计算机待测试代码，所述计算机待测试代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机待测试代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只 读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括是电载波信号和电信信号。
以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (20)

  1. 一种测试前置实现方法，其特征在于，包括：
    将系统平台和至少一个测试环境子系统相连通；
    创建编译部署脚本；
    运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
    将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置。
  2. 根据权利要求1所述的测试前置实现方法，其特征在于，在所述将系统平台和至少一个测试环境子系统相连通的步骤之后，所述测试前置实现方法还包括：
    采用网络协议命令检验所述系统平台和所述测试环境子系统是否连通；
    若未连通，则输出未连通提醒信息，重新将所述系统平台和所述测试环境子系统相连通。
  3. 根据权利要求1所述的测试前置实现方法，其特征在于，所述创建编译部署脚本，包括：
    脚本创建工具获取用户输入的脚本指令，所述脚本指令与待测试代码相关联；
    基于与所述待测试代码相关联的所述脚本指令，创建编译部署脚本。
  4. 根据权利要求1所述的测试前置实现方法，其特征在于，所述运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包，包括：
    在所述系统平台上运行所述编译部署脚本，以从版本管理工具获取所述待测试代码；
    对所述待测试代码进行编译和打包，获取能够在所述系统平台上运行的可执行包。
  5. 根据权利要求4所述的测试前置实现方法，其特征在于，所述待测试代码的待测试代码ID与存储地址相关联；
    所述在所述系统平台上运行所述编译部署脚本，以从版本管理工具获取所述待测试代码，包括：
    运行所述编译部署脚本，获取与所述待测试代码ID相关联的所述存储地址；
    根据所述存储地址获取所述待测试代码。
  6. 根据权利要求1所述的测试前置实现方法，其特征在于，所述将所述可执行包部署在所述系统平台上，包括：
    将所述可执行包与所述系统平台的域名和端口号相关联。
  7. 根据权利要求1所述的测试前置实现方法，其特征在于，在将所述可执行包部署在所述系统平台上的步骤之后，所述测试前置实现方法还包括：
    重启所述系统平台的服务器，更新部署在所述系统平台上的所述可执行包。
  8. 一种测试前置实现装置，其特征在于，包括：
    测试环境连通模块，用于将系统平台和至少一个测试环境子系统相连通；
    编译部署脚本创建模块，用于创建编译部署脚本；
    可执行包获取模块，用于运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
    部署模块，用于将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置。
  9. 一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时实现如下步骤：
    将系统平台和至少一个测试环境子系统相连通；
    创建编译部署脚本；
    运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
    将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置。
  10. 根据权利要求9所述的终端设备，其特征在于，在所述将系统平台和至少一个测试环境子系统相连通的步骤之后，所述处理器执行所述计算机可读指令时还实现如下步骤：
    采用网络协议命令检验所述系统平台和所述测试环境子系统是否连通；
    若未连通，则输出未连通提醒信息，重新将所述系统平台和所述测试环境子系统相连通。
  11. 根据权利要求9所述的终端设备，其特征在于，所述创建编译部署脚本，包括：
    脚本创建工具获取用户输入的脚本指令，所述脚本指令与待测试代码相关联；
    基于与所述待测试代码相关联的所述脚本指令，创建编译部署脚本。
  12. 根据权利要求9所述的终端设备，其特征在于，所述运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包，包括：
    在所述系统平台上运行所述编译部署脚本，以从版本管理工具获取所述待测试代码；
    对所述待测试代码进行编译和打包，获取能够在所述系统平台上运行的可执行包。
  13. 根据权利要求9所述的终端设备，其特征在于，所述待测试代码的待测试代码ID与存储地址相关联；
    所述在所述系统平台上运行所述编译部署脚本，以从版本管理工具获取所述待测试代码，包括：
    运行所述编译部署脚本，获取与所述待测试代码ID相关联的所述存储地址；
    根据所述存储地址获取所述待测试代码。
  14. 根据权利要求9所述的终端设备，其特征在于，所述将所述可执行包部署在所述系统平台上，包括：
    将所述可执行包与所述系统平台的域名和端口号相关联。
  15. 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，其特征在于，所述计算机可读指令被处理器执行时实现如下步骤：
    将系统平台和至少一个测试环境子系统相连通；
    创建编译部署脚本；
    运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包；
    将所述可执行包部署在所述系统平台上，并基于与所述系统平台相连通的至少一个所述测试环境子系统，实现测试前置。
  16. 根据权利要求15所述的计算机可读存储介质，其特征在于，在所述将系统平台和至少一个测试环境子系统相连通的步骤之后，所述计算机可读指令被所述处理器执行时还实现如下步骤：
    采用网络协议命令检验所述系统平台和所述测试环境子系统是否连通；
    若未连通，则输出未连通提醒信息，重新将所述系统平台和所述测试环境子系统相连通。
  17. 根据权利要求15所述的计算机可读存储介质，其特征在于，所述创建编译部署脚本，包括：
    脚本创建工具获取用户输入的脚本指令，所述脚本指令与待测试代码相关联；
    基于与所述待测试代码相关联的所述脚本指令，创建编译部署脚本。
  18. 根据权利要求15所述的计算机可读存储介质，其特征在于，所述运行所述编译部署脚本，获取能够在所述系统平台上运行的可执行包，包括：
    在所述系统平台上运行所述编译部署脚本，以从版本管理工具获取所述待测试代码；
    对所述待测试代码进行编译和打包，获取能够在所述系统平台上运行的可执行包。
  19. 根据权利要求15所述的计算机可读存储介质，其特征在于，所述待测试代码的待测试代码ID与存储地址相关联；
    所述在所述系统平台上运行所述编译部署脚本，以从版本管理工具获取所述待测试代码，包括：
    运行所述编译部署脚本，获取与所述待测试代码ID相关联的所述存储地址；
    根据所述存储地址获取所述待测试代码。
  20. 根据权利要求15所述的计算机可读存储介质，其特征在于，所述将所述可执行包部署在所述系统平台上，包括：
    将所述可执行包与所述系统平台的域名和端口号相关联。
PCT/CN2018/073918 2017-10-31 2018-01-24 测试前置实现方法、装置、终端设备及存储介质 WO2019085290A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711040815.2A CN107885658B (zh) 2017-10-31 2017-10-31 测试前置实现方法、装置、终端设备及存储介质
CN201711040815.2 2017-10-31

Publications (1)

Publication Number Publication Date
WO2019085290A1 true WO2019085290A1 (zh) 2019-05-09

Family

ID=61782929

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/073918 WO2019085290A1 (zh) 2017-10-31 2018-01-24 测试前置实现方法、装置、终端设备及存储介质

Country Status (2)

Country Link
CN (1) CN107885658B (zh)
WO (1) WO2019085290A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109189676A (zh) * 2018-08-20 2019-01-11 北京旷视科技有限公司 人脸解锁软件测试方法、装置及测试系统
CN109101428B (zh) * 2018-08-21 2021-11-05 宜人恒业科技发展（北京）有限公司 一种ui自动化测试系统
CN109189680B (zh) * 2018-08-24 2019-08-06 苏州玩友时代科技股份有限公司 一种应用发布和配置的系统及方法
CN112148583A (zh) * 2019-06-27 2020-12-29 北京车和家信息技术有限公司 一种软件测试方法及系统
CN111459813B (zh) * 2020-03-30 2023-08-15 北京百度网讯科技有限公司 测试处理方法及装置
CN112035365B (zh) * 2020-09-01 2023-08-18 中国银行股份有限公司 支持多测试环境的版本部署方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101140541A (zh) * 2007-09-29 2008-03-12 中兴通讯股份有限公司 一种分布式软件系统的集成测试系统及方法
US20080320071A1 (en) * 2007-06-21 2008-12-25 International Business Machines Corporation Method, apparatus and program product for creating a test framework for testing operating system components in a cluster system
CN102156673A (zh) * 2011-04-20 2011-08-17 北京航空航天大学 面向测试用例描述的gui自动化测试系统及其测试方法
CN102650966A (zh) * 2011-02-24 2012-08-29 王轶辰 一种面向复用的嵌入式软件测试方法及其测试系统
CN103970650A (zh) * 2014-04-09 2014-08-06 广州杰赛科技股份有限公司 分布式测试方法和装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102043714B (zh) * 2010-12-10 2013-01-02 成电汽车电子产业园(昆山)有限公司 一种嵌入式软件自动测试系统
CN103581247A (zh) * 2012-07-30 2014-02-12 杭州洱海科技有限公司 一种基于云计算环境的分布式Web测试方法
CN106104467B (zh) * 2014-06-30 2019-09-27 北京新媒传信科技有限公司 一种自动化部署方法和终端
CN104539487B (zh) * 2015-01-20 2018-04-17 成都益联科创科技有限公司 一种基于云平台的系统测试及可靠性评估方法
CN104793946B (zh) * 2015-04-27 2018-07-06 广州杰赛科技股份有限公司 基于云计算平台的应用部署方法和系统
CN106933730A (zh) * 2015-12-29 2017-07-07 北京国睿中数科技股份有限公司 基于测试框架系统的测试方法、装置和测试框架系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080320071A1 (en) * 2007-06-21 2008-12-25 International Business Machines Corporation Method, apparatus and program product for creating a test framework for testing operating system components in a cluster system
CN101140541A (zh) * 2007-09-29 2008-03-12 中兴通讯股份有限公司 一种分布式软件系统的集成测试系统及方法
CN102650966A (zh) * 2011-02-24 2012-08-29 王轶辰 一种面向复用的嵌入式软件测试方法及其测试系统
CN102156673A (zh) * 2011-04-20 2011-08-17 北京航空航天大学 面向测试用例描述的gui自动化测试系统及其测试方法
CN103970650A (zh) * 2014-04-09 2014-08-06 广州杰赛科技股份有限公司 分布式测试方法和装置

Also Published As

Publication number Publication date
CN107885658A (zh) 2018-04-06
CN107885658B (zh) 2019-06-21

Similar Documents

Publication Publication Date Title
WO2019085290A1 (zh) 测试前置实现方法、装置、终端设备及存储介质
US10929117B2 (en) Container image building using shared resources
CN109739604B (zh) 页面渲染方法、装置、服务器及存储介质
Masek et al. Unleashing full potential of ansible framework: University labs administration
EP3454213B1 (en) Function library build architecture for serverless execution frameworks
US9672140B1 (en) Processing special requests at dedicated application containers
US9489189B2 (en) Dynamically generate and execute a context-specific patch installation procedure on a computing system
CN108804618A (zh) 数据库配置方法、装置、计算机设备和存储介质
US9460109B1 (en) Centralized provisioning process leveraging network attached storage
CN110377462B (zh) 接口测试方法、装置及终端设备
US8849947B1 (en) IT discovery of virtualized environments by scanning VM files and images
CN105487892A (zh) 一种Linux环境下的云中GIS服务部署系统
CN111488151B (zh) Android各模块间页面交互的方法、装置
CN109213498A (zh) 一种互联网web前端的配置方法及服务器
CN113076253A (zh) 一种测试方法和测试装置
CN112615759A (zh) 全链路压测组件、全链路压测方法及装置
CN110659021B (zh) 一种移动端内微应用的开发及测试系统
CN105094787B (zh) 企业互联网应用的处理方法及装置
US20230171179A1 (en) Method for testing pressure, electronic device and storage medium
CN117008920A (zh) 引擎系统、请求处理方法、装置、计算机设备及存储介质
US11803786B2 (en) Enterprise integration platform
CN110321507A (zh) 浏览器跨域通信方法及装置
CN113495498B (zh) 用于硬件设备的模拟方法、模拟器、设备和介质
CN116132344A (zh) 基于K8s集群的容器服务调试方法及装置、电子设备
CN115633073A (zh) 微服务调用方法、电子设备、系统及可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18872577

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 28.09.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18872577

Country of ref document: EP

Kind code of ref document: A1