WO2019128299A1 - Système et procédé de test - Google Patents

Système et procédé de test Download PDF

Info

Publication number
WO2019128299A1
WO2019128299A1 PCT/CN2018/104317 CN2018104317W WO2019128299A1 WO 2019128299 A1 WO2019128299 A1 WO 2019128299A1 CN 2018104317 W CN2018104317 W CN 2018104317W WO 2019128299 A1 WO2019128299 A1 WO 2019128299A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
access request
access
test
software
Prior art date
Application number
PCT/CN2018/104317
Other languages
English (en)
Chinese (zh)
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 WO2019128299A1 publication Critical patent/WO2019128299A1/fr
Priority to US16/911,722 priority Critical patent/US20200327045A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3684Test management for test design, e.g. generating new test cases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3692Test management for test results analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3696Methods or tools to render software testable

Definitions

  • the present application relates to the field of computer technology, and in particular, to a test system and a test method.
  • test case is designed by a software developer, it will cause extra work.
  • artificially designed test cases have limitations and cannot guarantee the accuracy of the test.
  • the present application provides a test method that improves test accuracy.
  • a first aspect of the present application provides a testing method, including: a testing system acquiring an access request received by a software to be tested, the access request including an operation code, a uniform resource locator URL, and a request parameter; and the test system acquiring the request for the access request The value range of the parameter; the test system generates a plurality of test cases corresponding to the access request according to the value range of the request parameter of the access request, each test case includes the operation code and the URL, and each test case includes a request The parameter belongs to the value range of the request parameter of the access request; the test system executes a plurality of test cases corresponding to the access request to the software to be tested.
  • the access request further includes a request body; the method includes: the test system obtains a value range of the request body of the access request; and the test system generates the value range of the request parameter according to the access request.
  • the plurality of test cases corresponding to the access request include: the test system generates a plurality of test cases corresponding to the access request according to the value range of the request parameter of the access request and the value range of the request body of the access request, and each test The request parameter included in the use case belongs to the value range of the request parameter of the access request, and the request body included in each test case belongs to the value range of the request body of the access request.
  • the value range of the request parameter of the test system for obtaining the access request includes: the test system acquires multiple pre-access requests, each pre-access request includes the opcode and the URL; and the test system is configured according to The request parameters of the plurality of pre-access requests determine a range of values of the request parameters of the access request.
  • the method includes: the test system determines a pre-access request that the access request depends on; and the test system sends the test software to the software to be tested before executing the plurality of test cases corresponding to the access request to the software to be tested A pre-access request that is relied upon.
  • the method includes: the test system acquires an access frequency of an access request carrying the URL; and the test system determines, according to the access frequency, a frequency of executing the plurality of test cases corresponding to the access request to the software to be tested.
  • a second aspect of the present application provides a test system for performing the test method provided by the first aspect and its various possible designs.
  • the test system includes at least one physical server, each physical server including at least one processor and a memory, each processor being coupled to the memory, the processor for obtaining an access request received by the software to be tested, the access request including an operation a code, a URL, and a request parameter; obtaining a value range of the request parameter of the access request; generating, according to the value range of the request parameter of the access request, a plurality of test cases corresponding to the access request, where each test case includes the operation code And the URL, the request parameter included in each test case belongs to a value range of the request parameter of the access request; and the plurality of test cases corresponding to the access request are executed by the software to be tested.
  • the processor is configured to obtain a value range of the request body of the access request, and generate the value according to the value range of the request parameter of the access request and the value range of the request body of the access request. Accessing a plurality of test cases corresponding to the request, each of the test cases includes a request parameter that belongs to a range of values of the request parameters of the access request, and the request body included in each test case belongs to a value range of the request body of the access request.
  • the processor is configured to obtain a plurality of pre-access requests, each pre-access request includes the opcode and the URL; and determining the access according to the request parameters of the multiple pre-access requests The range of values of the requested request parameters.
  • the processor is configured to determine a pre-access request that the access request depends on, and send the dependent to the software to be tested before executing the multiple test cases corresponding to the access request to the software to be tested. Pre-access request.
  • the processor is configured to obtain an access frequency of an access request that carries the URL, and determine, according to the access frequency, a frequency of executing multiple test cases corresponding to the access request to the software to be tested.
  • a third aspect of the present application provides a non-volatile storage medium for storing program code that, when executed by a physical server, performs the test method provided by the first aspect and its various possible designs.
  • the physical server is configured to obtain an access request received by the software to be tested, where the access request includes an operation code, a URL, and a request parameter; a value range of the request parameter for obtaining the access request; and a request parameter according to the access request a range of values, generating a plurality of test cases corresponding to the access request, each test case includes the operation code and the URL, and each test case includes a request parameter that belongs to a range of values of the request parameter of the access request;
  • the software executes a plurality of test cases corresponding to the access request.
  • the storage medium includes, but is not limited to, a flash memory (English: flash memory), a hard disk (English: hard disk drive, abbreviated as HDD) or a solid state drive (English: solid state drive, abbreviation: SSD).
  • a flash memory English: flash memory
  • HDD hard disk drive
  • SSD solid state drive
  • the physical server is configured to obtain a value range of the request body of the access request, and generate the access according to the value range of the request parameter of the access request and the value range of the request body of the access request.
  • a plurality of test cases are requested, and each of the test cases includes a request parameter that belongs to a value range of the request parameter of the access request, and the request body included in each test case belongs to a value range of the request body of the access request.
  • the physical server is configured to obtain a plurality of pre-access requests, each pre-access request includes the opcode and the URL; and determining the access request according to the request parameters of the multiple pre-access requests The range of values of the request parameters.
  • the physical server is configured to determine a pre-access request that the access request depends on; before the plurality of test cases corresponding to the access request are executed by the software to be tested, the dependent software is sent to the software to be tested. Pre-access request.
  • the physical server is configured to acquire an access frequency of an access request that carries the URL; and determine, according to the access frequency, a frequency of executing multiple test cases corresponding to the access request to the software to be tested.
  • FIG. 1 is a schematic diagram of a software application system according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of a software application system according to an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of a testing method provided by an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram of a physical server according to an embodiment of the present application.
  • first, second, etc. are used in this application to distinguish each object, but there is no logical or temporal dependency between each of the "first” and “second”.
  • test cases include a set of conditions or variables.
  • the tester can judge whether the software to be tested meets the requirements or is in a normal working state according to the test result of the test case on the software to be tested.
  • the client can be a virtual machine, a physical machine, a tablet, and the like.
  • the user can access the software to be tested in the business system through the user terminal.
  • the software application system includes a plurality of clients, a business system, and a test system.
  • the client accesses the service system through the communication network, and the common business system may be a public cloud.
  • a communication connection is established between the business system and the test system.
  • the business system includes multiple physical servers.
  • the test system includes multiple physical servers.
  • the test system includes a use case generation unit and a use case execution unit, and each unit may be composed of one or more physical servers.
  • an acquisition module can be deployed in the software to be tested, which is also called an intrusive deployment.
  • the acquisition module is configured to collect an access request received by the software to be tested and an access response sent by the software to be tested, and send the access request and the access response to the test system.
  • the collection module may obtain an access request and an access response by monitoring a network card of a physical server where the software to be tested is located, or an operating system of a physical server where the software to be tested is monitored, and send the access request and the access response to the use case generating unit.
  • the setup module can also be deployed in the software to be tested.
  • the designer of the software to be tested can set the value of the request parameter and/or the request body in the access request, and the dependency relationship between the access requests in the setting. In the module.
  • the collection module can also be deployed outside the software to be tested, that is, deployed on the physical server where the software to be tested is located, also called non-intrusive deployment.
  • the designer of the software to be tested cannot preset the range of request parameters and/or the scope of the request body in the access request, and the dependencies between the access requests.
  • a user issues an access request, such as a request to establish a virtual machine, to a software to be tested, such as a virtual machine management platform, through a client.
  • the software to be tested establishes a virtual machine according to the access request, and carries the information about the created virtual machine in the access response to the client, so that the user can subsequently access the established virtual machine through the related information.
  • the software to be tested may be updated during operation.
  • the software to be tested may be defective during the design phase, or the physical server where the software to be tested may have various types of abnormalities, such as insufficient memory capacity and operating system failure. These updates, defects, or exceptions can cause the software under test to fail to process access requests or to process a partial access request correctly. Therefore, it is necessary to regularly test the test software to ensure that the function and running state of the software to be tested are normal.
  • the present application provides a test system and a test method based on the test system.
  • the test case is automatically generated and the test case is executed on the software to be tested, thereby improving the accuracy of the test. And coverage.
  • Figure 3 illustrates a test method.
  • the client sends an access request to the software to be tested.
  • the access request includes the following fields, and the contents of each field are examples:
  • Request header header 1;
  • the request body may not be carried.
  • Other types of requests such as requests for modified POST types, may carry the request body.
  • the software to be tested sends an access response to the client.
  • the access response can be an HTTP response, and the access response includes the following fields, and the contents of each field are examples:
  • return codes There are many types of return codes, and the return code can be used to determine whether the access request is normally responded. For example, 200, 201, 202, etc. indicate a normal response, 400 indicates a bad request, 404 indicates not found, 500 indicates an internal error, and the like. Refer specifically to the HTTP status code. When the access response of the software to be tested is abnormal, the access response may not carry the response body.
  • the acquiring module corresponding to the software to be tested acquires the access request, and sends the access request to the use case generating unit of the testing system.
  • the acquiring module corresponding to the software to be tested acquires the access response, and sends the access response to the use case generating unit of the testing system.
  • the order of execution of 204 and 206 is not limited, and may be performed in parallel. 204 can be executed at any time after 200. 206 is an optional step in which the acquisition module may not send an access response to the use case generation unit of the test system during the generation of the test case.
  • the use case generating unit stores the access request, distinguishes each field in the access request, and stores each field of the access request separately.
  • Request header header 1;
  • the use case generating unit acquires a value range of the request parameter and/or the request body in the access request.
  • 210 For intrusive and non-intrusive deployments, 210 has two implementations.
  • the use case generating unit directly acquires the request parameter and/or the request in the access request preset in the setting module.
  • the range of values of the body is set in the case of intrusive deployment.
  • the setting module stores a setting instruction (URL, request parameter, value range) indicating the range of the request parameter for a certain URL.
  • a setting instruction URL, request parameter, value range
  • the indication URL is http://192.168.
  • the request parameter name ranges from az or 0-9, and the length of the name is 4.
  • the use case generation unit executes multiple times 200-206 to obtain a plurality of pre-access requests carrying the same URL and the same operation code, and request parameters and/or requests according to the plurality of pre-access requests.
  • the value of the body determines the range of values of the request parameters and/or request body in the access request. If the request parameter and/or request body includes a number, the value ranges from the minimum value of the number in the request parameter and/or request body to the maximum value of the number in the request parameter and/or request body. If the request parameter and/or the request body include characters, the range of values is the various permutation combinations of the request parameters and/or the characters included in the request body.
  • the multiple access requests carry the URL http://192.168.1.1:8080/servers.
  • the length of the request parameter name in the multiple access requests is 4, and the values of all the name characters include a, b, d, and e. , x, 0, 9.
  • the access request of the URL http://192.168.1.1:8080/servers can be carried.
  • the value range of the name is a, b, d, e, x, 0-9. Any combination of four.
  • the value range of the request parameter in the access request is determined according to the value of the request parameter of the multiple access requests.
  • the value range of the request body in the access request is determined according to the value of the request body of the plurality of access requests.
  • the request parameter and the value range of the request body in the access request are determined according to the request parameter of the plurality of access requests and the value of the request body.
  • the value of the request parameter of the multiple access requests is used to determine a value range of the request parameter in the access request
  • the value of the request body of the multiple access requests is used to determine the request in the access request. The range of values of the body.
  • the value range of the request parameter set in the setting module is X
  • the use case determining unit determines the request parameter according to the collected multiple access requests.
  • the range of values is Y.
  • the value range of the request parameter in the end can be the union of X and Y.
  • the acquisition of the value range of the request body is similar to the acquisition of the value range of the request parameter.
  • the use case generation unit combines the request parameters and/or the value range of the request body and the respective fields of the access request.
  • the use case generating unit may also store the fields of the access response together, for example:
  • Request header header 1;
  • the return code and the response body belong to the access response.
  • the use case generating unit acquires a pre-access request that the access request depends on.
  • a pre-access request for an access request is sent to the software to be tested before the access request. If an access request has a dependent pre-access request, the software to be tested cannot be processed until the dependent pre-access request is sent to the software to be tested and the software to be tested has responded to the dependent pre-access request. Respond correctly to the access request.
  • Partial access requests rely on pre-access requests, for example, access requests for accessing virtual machines depend on access requests for establishing virtual machines. Only after the virtual machine management platform receives the access request for establishing the virtual machine, creates a virtual machine, and sends the created virtual machine information, such as the virtual machine ID, to the client through the access response, the user can respond according to the access.
  • the virtual machine ID carried in the virtual machine sends an access request for accessing the created virtual machine, and the access request for accessing the virtual machine carries the virtual machine ID. Therefore, the access request for accessing the virtual machine depends on the access request used to establish the virtual machine.
  • the designer of the software to be tested can pre-set the dependency relationship between the access requests in the setting module, and the use case generating unit acquires the access request dependency according to the dependency relationship between the access requests in the setting module. Pre-access request.
  • the use case generating unit determines that the request parameter of the access request or the request body is carried in a certain pre-access request or an access response corresponding to a pre-access request, and the pre-access request is The access request depends.
  • the dependency relationship set in the setting module indicates that the pre-access request dependent on the access request 1 is the access request 2, and the access request determined by the use case generating unit 1 The dependent pre-access request is access request 3. Finally, the pre-access request for the access request can be confirmed as access request 2 and/or access request 3.
  • the use case generating unit combines the pre-access request and the request parameter of the access request and/or the value range of the request body and the respective fields of the access request, for example:
  • Request header header 1;
  • 212 is an optional step.
  • the execution order of 212 is not limited, and may be performed before executing the test case corresponding to the access request.
  • the use case generating unit generates a test case corresponding to the access request according to the request parameter and/or the value range of the request body in the access request.
  • test cases are generated using the same opcode, request header, and URL as the access request, and the request parameters of each test case are different, and/or the request body is different.
  • the request parameters for each test case are within the range of values of the request parameters.
  • the request body of each test case belongs to the value range of the request body.
  • the request parameters of the multiple test cases, and/or the request body cover the request parameters and/or the range of values of the request body as much as possible.
  • the request parameters of the plurality of test cases, and/or the request body completely cover the range of values of the request parameters and/or the request body.
  • An example of a request parameter for a test case is generated based only on the value range of the request parameter.
  • the request body is similar to:
  • Access request GET header 1URL: http://192.168.1.1:8080/servers ;
  • the length of the request parameter is 4;
  • the value range of the request parameter [a-z, 0-9].
  • the request parameters of each test case generated include any 4 characters in [a-z, 0-9].
  • C 36 4 can be generated for a total of 58905 test cases. If the request is a case where a predetermined standard naming parameters can reuse the same numbers or characters, the generated test case parameters of the request to completely cover the range of request parameters, test cases may be generated 364. The request parameters of the generated test case may not completely cover the value range of the parameter request, so as to avoid the test case being too long and the test time is long.
  • the use case generation unit sends the generated test case to the use case execution unit.
  • the use case execution unit executes the generated test case.
  • the use case execution unit may consist of one or more physical servers, each of which is responsible for executing a portion of the test cases.
  • Each test case includes a test access request, and the use case execution unit executes the test case including sending the test access request to the software to be tested. Subsequently, the use case execution unit receives the test access response returned by the software to be tested according to the test access request. The use case execution unit determines whether the test access response is normal by testing the return code of the access response. The use case execution unit may also compare the response body of the test access response with the response body of the previously recorded access request, and if the same, determine that the access response is normal.
  • the previous use case execution unit needs to send the dependent pre-access request to the software to be tested. Otherwise, the software to be tested cannot respond normally after receiving the test access request.
  • the use case generating unit may also collect the frequency at which the access request carrying the same URL is invoked, that is, the number of times the software to be tested receives the access request carrying the same URL in the same time, and sends the frequency of the access request carrying the same URL to be called. To the use case execution unit. When the use case execution unit executes 216, the test cases generated according to the access requests carrying different URLs may be executed according to the frequency at which the access request carrying the different URLs is called. In general, the frequency with which test cases generated based on access requests with higher frequency are executed is higher. It is guaranteed that the higher the called frequency, the more frequent and more important the access request is tested.
  • the access request 1 carrying the URL 1 is called 500 times/hour, and the access request 2 carrying the URL 2 is called 2000 times/hour.
  • the use case execution unit executes the test case generated according to the access request 2 more frequently to ensure that the function corresponding to the access request 2 runs normally.
  • test method can automatically generate test cases and execute test cases according to the access request received by the software to be tested. Testers are not required to write test cases, reducing test costs. At the same time, the request parameters of the automatically generated test cases and the value range of the request body can better cover various situations and improve the test coverage.
  • Figure 4 provides a physical server 400 that can be used in the above system.
  • a part of the use case generation unit or the use case generation unit is run on the physical server 400.
  • a portion of the utility instance execution unit or use case execution unit is run on the physical server 400.
  • the physical server 400 includes a bus 402, a processor 404, a memory 408, and a communication interface 406.
  • the processor 404, the memory 408, and the communication interface 406 communicate via a bus 402.
  • the processor 404 can be a central processing unit (English: central processing unit, abbreviation: CPU).
  • the memory 408 may include a volatile memory (English: volatile memory) (English: random access memory, abbreviation: RAM).
  • the memory 408 may also include a non-volatile memory such as a read-only memory (ROM), a flash memory, an HDD or an SSD.
  • ROM read-only memory
  • HDD hard disk drive
  • SSD solid state drive
  • the program is stored in the memory 408, and the processor 404 executes the program to execute the operation of the use case generation unit in the above method. Specifically includes 208-216 and its alternatives.
  • the program is stored in the memory 408, and the processor 404 executes the program to execute a part of the operation of the use case generation unit in the above method. Specifically, one or several steps of 208-216 and its alternatives are included.
  • a program is stored in the memory 408, and the processor 404 executes the program to execute 218.
  • program is stored in memory 408, and processor 404 executes the program to execute a portion of the generated test case.
  • the physical server 400 can automatically generate test cases and execute test cases according to the access request received by the software to be tested. Testers are not required to write test cases, reducing test costs. At the same time, the request parameters of the automatically generated test cases and the value range of the request body can better cover various situations and improve the test coverage.
  • the business system is also comprised of a plurality of physical servers 400, each of which runs one or more software to be tested.
  • a software to be tested and an acquisition module corresponding to the software to be tested generally run on the same physical server 400.
  • a program is stored in the memory 408 of the physical server 400 in the service system, and the processor 404 executes the program to execute the actions of the software to be tested, the collection module corresponding to the software to be tested, and the setting module corresponding to the software to be tested.
  • the methods described in connection with the present disclosure can be implemented by a processor executing software instructions.
  • the software instructions can be composed of corresponding software modules, which can be stored in RAM, flash memory, read-only memory (English: read only memory, abbreviation: ROM), erasable programmable read-only memory (English: erasable programmable) Read only memory (abbreviation: EPROM), electrically erasable programmable read only memory (EEPROM), hard disk, optical disk, or any other form of storage medium known in the art.
  • the functions described herein may be implemented in hardware or software.
  • the functions may be stored in a computer readable medium or transmitted as one or more instructions or code on a computer readable medium.
  • a storage medium may be any available media that can be accessed by a general purpose or special purpose computer.

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)

Abstract

La présente invention concerne un système de test, comprenant une unité de génération de cas d'utilisation et une unité d'exécution de cas d'utilisation. Le procédé de test comprend les étapes suivantes : une unité de génération de cas d'utilisation acquiert une demande d'accès reçue par un logiciel à tester, détermine, conformément à la demande d'accès, une plage de valeurs d'un paramètre de demande dans la demande d'accès, et génère des cas d'utilisation de test pour la demande d'accès conformément à la plage de valeurs ; et ensuite, l'unité d'exécution de cas d'utilisation exécute ces cas d'utilisation de test pour le logiciel à tester. Le système de test peut générer automatiquement des cas d'utilisation de test destinés à un logiciel à tester, améliorant ainsi la précision de test.
PCT/CN2018/104317 2017-12-28 2018-09-06 Système et procédé de test WO2019128299A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/911,722 US20200327045A1 (en) 2017-12-28 2020-06-25 Test System and Test Method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711464339.7 2017-12-28
CN201711464339.7A CN108319550A (zh) 2017-12-28 2017-12-28 一种测试系统及测试方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/911,722 Continuation US20200327045A1 (en) 2017-12-28 2020-06-25 Test System and Test Method

Publications (1)

Publication Number Publication Date
WO2019128299A1 true WO2019128299A1 (fr) 2019-07-04

Family

ID=62892650

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/104317 WO2019128299A1 (fr) 2017-12-28 2018-09-06 Système et procédé de test

Country Status (3)

Country Link
US (1) US20200327045A1 (fr)
CN (1) CN108319550A (fr)
WO (1) WO2019128299A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112650666A (zh) * 2019-10-12 2021-04-13 北京达佳互联信息技术有限公司 一种软件测试系统、方法、装置、控制设备及存储介质

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108319550A (zh) * 2017-12-28 2018-07-24 华为技术有限公司 一种测试系统及测试方法
US11663339B2 (en) * 2019-07-31 2023-05-30 International Business Machines Corporation Security testing based on user request
CN111338943A (zh) * 2020-02-21 2020-06-26 北京字节跳动网络技术有限公司 一种测试方法、装置、电子设备及可读存储介质
US11467824B2 (en) * 2020-06-30 2022-10-11 Vmware, Inc. Method and system for fast building and testing software
CN113138934B (zh) * 2021-05-14 2024-01-19 杭州网易云音乐科技有限公司 自动测试的方法、介质、装置和计算设备
CN117234949B (zh) * 2023-11-13 2024-03-19 广州品唯软件有限公司 测试数据降噪方法、装置、存储介质、计算机设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130055028A1 (en) * 2011-08-31 2013-02-28 Ebay Inc. Methods and systems for creating software tests as executable resources
CN103905258A (zh) * 2012-12-24 2014-07-02 百度国际科技(深圳)有限公司 一种客户端数据上传功能的测试方法及装置
CN105988922A (zh) * 2015-02-06 2016-10-05 阿里巴巴集团控股有限公司 应用程序的测试方法、装置及服务器
CN106294102A (zh) * 2015-05-20 2017-01-04 腾讯科技(深圳)有限公司 应用程序的测试方法、客户端、服务器及系统
CN108319550A (zh) * 2017-12-28 2018-07-24 华为技术有限公司 一种测试系统及测试方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7007207B2 (en) * 2002-10-21 2006-02-28 International Business Machines Corporation Scheduling of transactions in system-level test program generation
CN106528395B (zh) * 2015-09-09 2019-08-23 阿里巴巴集团控股有限公司 测试用例的生成方法及装置
CN107102941B (zh) * 2017-03-30 2021-01-08 腾讯科技(深圳)有限公司 一种测试用例的生成方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130055028A1 (en) * 2011-08-31 2013-02-28 Ebay Inc. Methods and systems for creating software tests as executable resources
CN103905258A (zh) * 2012-12-24 2014-07-02 百度国际科技(深圳)有限公司 一种客户端数据上传功能的测试方法及装置
CN105988922A (zh) * 2015-02-06 2016-10-05 阿里巴巴集团控股有限公司 应用程序的测试方法、装置及服务器
CN106294102A (zh) * 2015-05-20 2017-01-04 腾讯科技(深圳)有限公司 应用程序的测试方法、客户端、服务器及系统
CN108319550A (zh) * 2017-12-28 2018-07-24 华为技术有限公司 一种测试系统及测试方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112650666A (zh) * 2019-10-12 2021-04-13 北京达佳互联信息技术有限公司 一种软件测试系统、方法、装置、控制设备及存储介质
CN112650666B (zh) * 2019-10-12 2024-04-09 北京达佳互联信息技术有限公司 一种软件测试系统、方法、装置、控制设备及存储介质

Also Published As

Publication number Publication date
CN108319550A (zh) 2018-07-24
US20200327045A1 (en) 2020-10-15

Similar Documents

Publication Publication Date Title
WO2019128299A1 (fr) Système et procédé de test
US20180375726A1 (en) Resource Configuration Method, Virtualized Network Function Manager, and Element Management System
US9146755B2 (en) System and method for transporting platform independent power configuration parameters
US9727439B2 (en) Tracking application deployment errors via cloud logs
EP3311529B1 (fr) Résilience sous la forme d'un service
CN109460343A (zh) 基于日志的系统异常监控方法、装置、设备及存储介质
US11444785B2 (en) Establishment of trusted communication with container-based services
CN113835836B (zh) 动态发布容器服务的系统、方法、计算机设备及介质
BR112017001171B1 (pt) Método executado em um dispositivo de computação, dispositivo de computação e dispositivo de memória legível por computador para recuperar a operacionalidade de um serviço baseado em nuvem
CN109273045B (zh) 存储设备在线检测方法、装置、设备及可读存储介质
CN110063042A (zh) 一种数据库故障的响应方法及其终端
CN113438292A (zh) 一种基于自动化运维工具的代理部署方法及装置
CN110968560A (zh) 日志采集器的配置方法、装置及系统
WO2014204470A1 (fr) Génération d'une empreinte digitale représentant une réponse d'une application à une simulation d'une panne d'un service externe
CN110955544A (zh) 一种web系统的可用性检测方法、装置及系统
US20170264527A1 (en) Diagnostic service for devices that employ a device agent
CN112306871A (zh) 数据处理方法、装置、设备及存储介质
CN105592173B (zh) 一种防止dns缓存被染的方法、系统及本地dns服务器
US11561848B2 (en) Policy-based logging using workload profiles
CN109669829A (zh) 一种基于bmc的诊断调试方法、装置及服务器
Schmieders et al. Architectural runtime models for privacy checks of cloud applications
KR101630088B1 (ko) 가상머신의 라이프사이클 모니터링 방법 및 그 장치
CN114039778A (zh) 一种请求处理方法、装置、设备及可读存储介质
US11487570B1 (en) Efficient creation of endpoints for accessing services directly within a cloud-based system
US9092397B1 (en) Development server with hot standby capabilities

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: 18893429

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18893429

Country of ref document: EP

Kind code of ref document: A1