WO2019019454A1 - 分层测试方法、装置、计算机设备和存储介质 - Google Patents

分层测试方法、装置、计算机设备和存储介质 Download PDF

Info

Publication number
WO2019019454A1
WO2019019454A1 PCT/CN2017/108271 CN2017108271W WO2019019454A1 WO 2019019454 A1 WO2019019454 A1 WO 2019019454A1 CN 2017108271 W CN2017108271 W CN 2017108271W WO 2019019454 A1 WO2019019454 A1 WO 2019019454A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
subroutine
tested
layer
function point
Prior art date
Application number
PCT/CN2017/108271
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 WO2019019454A1 publication Critical patent/WO2019019454A1/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/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Definitions

  • the present application relates to the field of computer technology, and in particular, to a layered test method, apparatus, computer device, and storage medium.
  • a layered test method, apparatus, computer device, and storage medium are provided.
  • a layered test method that includes:
  • test script corresponding to the test layer and a test case corresponding to the test subroutine
  • the test result is output, and if the test result indicates that the test fails, the cause of the failure is located to the corresponding test layer.
  • a layered testing device comprising:
  • An identification module configured to acquire a subroutine to be tested of the application, and identify a test layer corresponding to the subroutine to be tested;
  • test module configured to invoke a test script corresponding to the test layer and a test case corresponding to the test subroutine; and the test subroutine is tested by the test script and the test case;
  • the positioning module is configured to output a test result, and if the test result indicates that the test fails, the cause of the failure is located to the corresponding test layer.
  • test terminal comprising a memory and one or more processors having stored therein computer readable instructions that, when executed by the processor, cause the one or more processors to execute The following steps:
  • test script corresponding to the test layer and a test case corresponding to the test subroutine
  • the test result is output, and if the test result indicates that the test fails, the cause of the failure is located to the corresponding test layer.
  • One or more computer readable non-volatile storage media storing computer readable instructions, when executed by one or more processors, cause one or more processors to perform the steps of:
  • test script corresponding to the test layer and a test case corresponding to the test subroutine
  • the test result is output, and if the test result indicates that the test fails, the cause of the failure is located to the corresponding test layer.
  • 1 is a flow chart of a layered test method in an embodiment
  • Figure 2 is a block diagram of a layered test apparatus in one embodiment
  • FIG. 3 is a block diagram of a computer device in one embodiment.
  • a layered test method is provided. It should be understood that although the steps in the flowchart of FIG. 2 are sequentially displayed as indicated by the arrows, these steps are not necessarily in accordance with The order indicated by the arrows is performed in order. Except as explicitly stated herein, the execution of these steps is not strictly limited, and may be performed in other sequences. Moreover, at least some of the steps in FIG. 2 may include a plurality of sub-steps or stages, which are not necessarily performed at the same time, but may be executed at different times, and the order of execution thereof is not necessarily This may be performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of the other steps.
  • the method is applied to the test terminal as an example, and includes:
  • Step 102 Acquire a subroutine to be tested of the application, and identify a test layer corresponding to the subroutine to be tested.
  • Step 104 Call a test script corresponding to the test layer and a test case corresponding to the subroutine to be tested.
  • step 106 the test subroutine is tested by the test script and the test case.
  • step 108 the test result is output. If the test result indicates that the test fails, the cause of the failure is located to the corresponding test layer.
  • An application can be split into multiple subroutines according to its software architecture during development. Each subroutine can have independent functions. During the development of the application, the tester can independently test the completed subroutine (ie, the subroutine to be tested) through the test terminal, and does not need to wait until the application is fully developed before testing.
  • the automated test platform can call automated test scripts to test subroutines.
  • the automated test platform can be divided into multiple layers according to its software architecture, including the control layer, interface layer, database layer and service layer.
  • Automated test scripts can also be divided into multiple layers according to the software architecture of the automated test platform, including the control layer, interface layer, database layer and service layer.
  • the divided layer can also be called a test layer. Different test scripts can be called through different test layers for different functional tests.
  • the test layer has a corresponding test layer configuration file
  • the step of identifying the test layer corresponding to the subroutine to be tested includes: obtaining version information corresponding to the subroutine to be tested; and the version information includes the subroutine corresponding to the subroutine to be tested.
  • Function point obtain multiple test layer configuration files
  • test layer configuration file includes function points corresponding to the test layer
  • the subroutine to be tested may have corresponding identification and version information.
  • the test terminal can obtain the identifier of the subroutine to be tested, and obtain corresponding version information according to the identifier.
  • One or more function points of the subroutine to be tested can be recorded in the version information.
  • Each test layer can have a corresponding test layer configuration file. Multiple configuration items and corresponding function points are recorded in the test layer configuration file.
  • the test terminal can identify the required test layer according to the version information of the subroutine to be tested.
  • the test terminal can obtain a test layer configuration file corresponding to multiple test layers, and query the multiple configuration files by using the function points corresponding to the test subroutine. If one or more function points corresponding to the subroutine to be tested are queried in the test layer configuration file, the test terminal configures the test layer The corresponding test layer is recorded as the test layer required for the subroutine to be tested. This makes it possible to accurately obtain all the test layers required for each subroutine to be tested.
  • the step of identifying a test layer corresponding to the subroutine to be tested includes: running a subroutine to be tested, detecting a test layer that interacts with the subroutine; and recording a test layer that interacts with the subroutine to be tested as The test layer required for the subroutine to be tested.
  • test terminal can detect the test layer interacting with the subroutine to be tested through the automated test platform calling thread, record the name of the test layer in which the interaction occurs, and record it as the test layer required by the subroutine to be tested. This makes it possible to accurately obtain all the test layers required for each subroutine to be tested.
  • test terminal After identifying the test layer required by the subroutine to be tested, the test terminal calls the test script corresponding to the test layer through the automated test platform.
  • the test scripts for different test layers are different.
  • the test terminal can also obtain corresponding test cases according to the subroutine program through the automated test platform. Different test subroutines have different function points, and the required test cases can be different. Test cases can exist locally on the test terminal or on the server.
  • the test terminal runs the test script corresponding to the test layer through the automated test platform, and calls the corresponding test case to test the test subroutine. Tests from different test layers can be isolated from each other during the test. The test terminal can independently test different subroutines to be tested. After the test of the subroutine to be tested is completed, the test result can be output through the automated test platform.
  • the test terminal asserts the test results.
  • the test result includes multiple interface parameters, and multiple interface parameters may be described by using a regular expression, and the test result described by the regular expression is compared with the expected result. If they are consistent, the test passes. If they are inconsistent, the test fails. If the test fails, the test terminal can locate the failure reason of the test subroutine according to the test layer. That is, the test terminal can determine which test layer the failure cause of the subroutine to be tested occurs, thereby enabling accurate positioning.
  • the subroutine to be tested is described as "login".
  • the test terminal can recognize that the required test layer can only have the interface layer.
  • the interface layer script calls the corresponding test case for testing. If the test fails, it can be pointed out that the reason for the failure is located in the interface layer test failure.
  • the test terminal can recognize that the required test layer can include an interface layer, a database layer, and a service layer. Each test layer calls a different test case to test.
  • the login request is sent to the server by the subroutine to be tested, and the login request carries information such as a username, a password, and a verification code.
  • the interface layer test script performs interface layer testing based on the login request.
  • the database layer test script calls the verification logic of the database for verification test based on the user name, password, and verification code.
  • the service layer test script calls the interface for page jump testing. Among them, the test of the interface layer, database layer and service layer can be completely isolated. If the test result of a layer indicates that the test of the layer fails, the cause of the failure can be located to the layer, and the test layer that fails the test can be one or more. This enables precise positioning.
  • the required test layer can be identified according to the subroutine to be tested.
  • the test subroutine is automatically tested by calling the test script corresponding to the test layer and the test case corresponding to the subroutine to be tested. If the test fails, the cause of the failure can be accurately located to the corresponding test layer. In this process, since the multiple subroutines of the application are independently tested, if the test fails, the cause of the failure can be accurately located only for the subroutine to be tested, and the entire application is not required to be excluded as a whole. The reason for failure can effectively improve the positioning efficiency of the cause of the test failure.
  • the subroutine to be tested has corresponding version information, and the version information includes a version number.
  • the method further includes: obtaining a test case configuration file, and the test case configuration file records the version number of the subroutine to be tested and the corresponding Test case name; obtain the corresponding test case name according to the version number of the subroutine to be tested; call the corresponding test case according to the test case name.
  • test terminal before testing the subroutine to be tested, the test terminal also needs to obtain a corresponding test case.
  • Test cases can be stored locally on the test terminal or on the server.
  • the test case has a corresponding test case configuration file.
  • the test case configuration file can be stored locally on the test terminal or on the server.
  • test case configuration file records the test cases required for all subroutines of the application to be tested, including the identifier of the subroutine to be tested, the version number, and the corresponding test case name.
  • Each subroutine to be tested can also have a separate test case configuration file. Only a single test case configuration file can record only The test cases required for the subroutine test to be tested include the identification of the subroutine to be tested, the version number, and the corresponding test case.
  • the test terminal can obtain the shared test case configuration file, and retrieve the corresponding test case name in the shared test case configuration file according to the identifier and version number of the test subroutine to be tested.
  • the test terminal invokes the corresponding test case according to the retrieved test case name, so as to test the test subroutine.
  • the test terminal can also obtain an independent test case configuration file according to the identifier of the subroutine to be tested, and retrieve the corresponding test case name by using the version number of the subroutine to be tested in the independent test case configuration file.
  • the test terminal invokes the corresponding test case according to the retrieved test case name, so as to test the test subroutine.
  • the test cases corresponding to the version number of the subroutine to be tested can be quickly obtained, which is beneficial to improve the test efficiency.
  • the method further includes: acquiring a mapping file of a current version of the subroutine to be tested; the mapping file of the current version includes a function point of the current version, a storage path, and a corresponding test case; and acquiring the subroutine to be tested
  • a version of the mapping file includes the function points, storage paths, and corresponding test cases of the previous version; compares the mapping file of the current version with the mapping file of the previous version, and obtains the function points that have changed. And/or a changed storage path; identifying the function point to be tested by using the changed function point and/or the changed storage path; and using the current version of the mapping file to obtain the test case corresponding to the function point to be tested in the subroutine to be tested.
  • the regression test can be considered in the regression test of the subroutine to be tested, and only the repaired function points or newly added function points are tested.
  • the subroutine to be tested may include one or more function points. Function points can be implemented in code files to achieve their corresponding functions.
  • the tester can generate a mapping file according to the function point of the subroutine to be tested, the storage path corresponding to the code file, and the test case corresponding to the function point through the test terminal. Different versions of the subroutine to be tested can have different mapping files.
  • the test terminal obtains the mapping file of the current version of the subroutine to be tested and the mapping file of the previous version, and compares the two mapping files to obtain the changed function point and/or the changed storage path.
  • the current version can fix one or more feature points in the previous version.
  • the repaired function points can also be referred to as function points that have changed.
  • the current version can also add function points.
  • the new function points can also be called function points that have changed compared with the function points of the previous version.
  • the code file of each function point of the current version of the subroutine to be tested may also be changed compared to the code files of the previous version.
  • the code file corresponding to the repaired function point may exist in a different path from the previous one. It is also possible to replace the previous version of the code file in the previous path.
  • the test terminal obtains the current version of the code file and the code file of the previous version according to the changed function point and/or the changed storage path, and compares the two versions of the code file. If different, the current version is The function points corresponding to the code file are recorded as the function points to be tested.
  • the test terminal retrieves the corresponding test case name in the test case configuration file according to the function point to be tested.
  • the corresponding test case is called according to the test case name to test the test subroutine.
  • the changed function point and/or the changed storage path are obtained. Further, the function point to be changed and/or the changed storage path can be used to accurately identify the function point to be tested, and the corresponding test case is obtained through the function point to be tested. Therefore, the test range can be accurately determined in the regression test of the subroutine to be tested, thereby effectively improving the test efficiency.
  • a layered testing device comprising: an identification module 202, a testing module 204, and a positioning module 206, wherein:
  • the identification module 202 is configured to acquire a subroutine to be tested of the application, and identify a test layer corresponding to the subroutine to be tested.
  • the test module 204 is configured to invoke a test script corresponding to the test layer and a test case corresponding to the test subroutine; and test the test subroutine through the test script and the test case.
  • the positioning module 206 is configured to output a test result. If the test result indicates that the test fails, the cause of the failure is located to the corresponding test layer.
  • the test layer has a corresponding test layer configuration file
  • the identification module 202 is further configured to obtain version information corresponding to the subroutine to be tested; the version information includes a function point corresponding to the subroutine to be tested; and acquiring multiple test layers Configuration file; the test layer configuration file includes the function corresponding to the test layer Point; according to the function point corresponding to the subroutine to be tested, the function points corresponding to the test layer in the plurality of test layer configuration files are retrieved, and the test layer required for the subroutine to be tested is obtained.
  • the identification module 202 is further configured to run a subroutine to be tested, detect a test layer that interacts with the subroutine, and record a test layer that interacts with the subroutine to be tested as a test layer required by the subroutine to be tested. .
  • the subroutine to be tested has corresponding version information, and the version information includes a version number.
  • the test module 204 is further configured to obtain a test case configuration file, and the test case configuration file records the version number and corresponding of the subroutine to be tested.
  • the name of the test case obtain the corresponding test case name according to the version number of the subroutine to be tested; and call the corresponding test case according to the test case name.
  • the test module 204 is further configured to obtain a mapping file of a current version of the subroutine to be tested; the mapping file of the current version includes a function point, a storage path, and a corresponding test case of the current version; and acquiring the subroutine to be tested.
  • a point and/or a changed storage path identifying a function point to be tested by using a changed function point and/or a changed storage path; and using the current version of the mapping file to obtain a test case corresponding to the function point to be tested in the subroutine to be tested .
  • a computer device including the test terminal mentioned in the above embodiments.
  • the computer device includes a processor, a memory, and a network interface connected by a system bus.
  • the processor of the computer device is used to provide computing and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium, an internal memory.
  • the non-volatile storage medium of the computer device stores an operating system and computer readable instructions that are executed by the processor to implement a layered test method.
  • the internal memory of the computer device provides an environment for the operation of an operating system and computer readable instructions in a non-volatile storage medium.
  • the network interface of the computer device is used for communicating with an external server through a network connection, for example, sending a login request to the server, and the like.
  • the processor can perform the following steps when executing computer readable instructions:
  • FIG. 3 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation of the computer device to which the solution of the present application is applied.
  • the specific computer device may It includes more or fewer components than those shown in the figures, or some components are combined, or have different component arrangements.
  • test layer has a corresponding test layer configuration file
  • processor performs the following steps when executing the computer readable instructions:
  • the version information includes a function point corresponding to the subroutine to be tested;
  • test layer configuration file includes function points corresponding to the test layer
  • the function points corresponding to the test layer in the plurality of test layer configuration files are retrieved according to the function points corresponding to the subroutine to be tested, and the test layer required for the subroutine to be tested is obtained.
  • the processor also performs the following steps when executing the computer readable instructions:
  • the test layer that interacts with the subroutine to be tested is recorded as the test layer required for the subroutine to be tested.
  • the subroutine to be tested has corresponding version information
  • the version information includes a version number
  • the processor further performs the following steps when executing the computer readable instructions:
  • test case configuration file Obtain a test case configuration file, and record the version number of the subroutine to be tested and the corresponding test case name in the test case configuration file;
  • test case name The corresponding test case is called according to the test case name.
  • the processor also performs the following steps when executing the computer readable instructions:
  • mapping file of a current version of the subroutine to be tested includes a function point, a storage path, and a corresponding test case of the current version;
  • mapping file of the previous version of the subroutine to be tested includes the function points, storage paths, and corresponding test cases of the previous version;
  • test case corresponding to the function point to be tested in the subroutine to be tested is obtained by using the mapping file of the current version.
  • one or more computer readable non-volatile storage media having computer readable instructions, when executed by one or more processors, causing one or more processors Perform the following steps:
  • Test the test subroutine through test scripts and test cases
  • test result is output. If the test result indicates that the test fails, the cause of the failure is located to the corresponding test layer.
  • the test layer has a corresponding test layer configuration file that, when executed by the processor, also performs the following steps:
  • the version information includes a function point corresponding to the subroutine to be tested;
  • test layer configuration file includes function points corresponding to the test layer
  • the function points corresponding to the test layer in the plurality of test layer configuration files are retrieved according to the function points corresponding to the subroutine to be tested, and the test layer required for the subroutine to be tested is obtained.
  • the computer readable instructions when executed by the processor, also perform the following steps:
  • the test layer that interacts with the subroutine to be tested is recorded as the test layer required for the subroutine to be tested.
  • the subroutine to be tested has corresponding version information, and the version information includes a version number.
  • the computer readable instructions are executed by the processor, the following steps are also performed:
  • test case configuration file Obtain a test case configuration file, and record the version number of the subroutine to be tested and the corresponding test case name in the test case configuration file;
  • test case name The corresponding test case is called according to the test case name.
  • the computer readable instructions when executed by the processor, also perform the following steps:
  • mapping file of a current version of the subroutine to be tested includes a function point, a storage path, and a corresponding test case of the current version;
  • mapping file of the previous version of the subroutine to be tested includes the function points, storage paths, and corresponding test cases of the previous version;
  • test case corresponding to the function point to be tested in the subroutine to be tested is obtained by using the mapping file of the current version.
  • the readable storage medium which when executed, may include the flow of an embodiment of the methods as described above.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or the like.

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

一种分层测试方法，包括：获取应用程序的待测子程序，识别待测子程序对应的测试层（102）；调用与测试层对应的测试脚本以及与待测子程序对应的测试用例（104）；通过测试脚本和测试用例对待测子程序进行测试（106）；输出测试结果，若测试结果表示测试失败，则将失败原因定位至对应的测试层（108）。

Description

分层测试方法、装置、计算机设备和存储介质
本申请要求于2017年07月26日提交中国专利局，申请号为2017106183122，发明名称为“分层测试方法、装置、计算机设备和存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，特别是涉及一种分层测试方法、装置、计算机设备和存储介质。
背景技术
随着APP(Application，应用程序)的普及，各种APP开始涌现，并且APP的版本也在不断更新。对APP进行版本测试时，如果出现测试失败的情况，需要定位失败原因。在传统的自动测试中，是通过自动化测试脚本对整个APP版本进行测试。如果出现测试失败，需要在整体上对该版本排除失败原因，由此导致失败原因定位的耗时较长，效率较低。
发明内容
根据本申请的各种实施例，提供一种分层测试方法、装置、计算机设备和存储介质。
一种分层测试方法，包括：
获取应用程序的待测子程序，识别待测子程序对应的测试层；
调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；
通过所述测试脚本和测试用例对所述待测子程序进行测试；及
输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
一种分层测试装置，包括：
识别模块，用于获取应用程序的待测子程序，识别待测子程序对应的测试层；
测试模块，用于调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；通过所述测试脚本和测试用例对所述待测子程序进行测试；及
定位模块，用于输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
一种测试终端，包括存储器和一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
获取应用程序的待测子程序，识别待测子程序对应的测试层；
调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；
通过所述测试脚本和测试用例对所述待测子程序进行测试；及
输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
获取应用程序的待测子程序，识别待测子程序对应的测试层；
调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；
通过所述测试脚本和测试用例对所述待测子程序进行测试；及
输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请 的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为一个实施例中分层测试方法的流程图；
图2为一个实施例中分层测试装置的框图；
图3为一个实施例中计算机设备的框图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
在一个实施例中，如图1所示，提供了一种分层测试方法，应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。以该方法应用于测试终端为例进行说明，包括：
步骤102，获取应用程序的待测子程序，识别待测子程序对应的测试层。
步骤104，调用与测试层对应的测试脚本以及与待测子程序对应的测试用例。
步骤106，通过测试脚本和测试用例对待测子程序进行测试。
步骤108，输出测试结果，若测试结果表示测试失败，则将失败原因定位至对应的测试层。
应用程序(Application，简称APP)在开发过程中可以按照其软件架构被拆分为多个子程序。每个子程序可以具有独立的功能。在应用程序的开发过程中，测试人员可以通过测试终端对已完成的子程序(即待测子程序)进行独立的测试，不需要等到应用程序全部开发完成才进行测试。
测试终端上运行了自动化测试平台。自动化测试平台可以调用自动化测试脚本对待测子程序进行测试。自动化测试平台可以按照其软件架构被划分为多个层，包括控制层、界面层、数据库层和服务层等。自动化测试脚本也可以按照自动化测试平台的软件架构被相应地划分为多个层，包括控制层、界面层、数据库层和服务层等。划分后的层也可以称为测试层。通过不同的测试层可以调用不同的测试脚本进行不同的功能测试。
在其中一个实施例中，测试层具有对应的测试层配置文件，识别待测子程序对应的测试层的步骤，包括：获取待测子程序对应的版本信息；版本信息中包括待测子程序对应的功能点；获取多个测试层配置文件；测试层配置文件中包括测试层对应的功能点；根据待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到待测子程序所需的测试层。
待测子程序可以具有对应的标识和版本信息。测试终端可以获取待测子程序的标识，根据该标识获取对应的版本信息。版本信息中可以记录了待测子程序的一个或多个功能点。每个测试层都可以具有对应的测试层配置文件。测试层配置文件中记录了多个配置项和对应的功能点。测试终端可以根据待测子程序的版本信息识别所需的测试层。
具体的，测试终端可以获取多个测试层对应的测试层配置文件，利用待测子程序对应的功能点对多个配置文件中进行查询。若在测试层配置文件中查询到待测子程序对应的一个或多个功能点，则测试终端将该测试层配置文 件对应的测试层记录为待测子程序所需的测试层。由此可以准确得到每个待测子程序所需的所有测试层。
在另一个实施例中，识别待测子程序对应的测试层的步骤，包括：运行待测子程序，检测与子程序发生交互的测试层；将与待测子程序发生交互的测试层记录为待测子程序所需的测试层。
待测子程序运行时，可能会与一个或多个测试层发生交互。测试终端可以通过自动化测试平台调用线程检测与待测子程序发生交互的测试层，记录发生交互的测试层的名称，将其记录为待测子程序所需的测试层。由此可以准确得到每个待测子程序所需的所有测试层。
在识别出待测子程序所需的测试层之后，测试终端通过自动化测试平台调用与测试层对应的测试脚本。不同的测试层所对应的测试脚本不同。测试终端通过自动化测试平台还可以根据待子程序获取对应的测试用例。不同的待测子程序其功能点不同，所需的测试用例可以不同。测试用例可以存在测试终端本地，也可以存在服务器。
测试终端通过自动化测试平台运行与测试层对应的测试脚本，调用相应的测试用例对待测子程序进行测试。在测试过程中，不同测试层的测试可以相互隔离。测试终端可以对不同待测子程序进行独立测试。待测子程序的测试结束之后，可以通过自动化测试平台输出测试结果。
测试终端对测试结果进行断言。具体的，测试结果中包括了多个接口参数，多个接口参数可以采用正则表达式进行描述，对采用正则表达式描述的测试结果与预期结果进行比对。若一致，则表示测试通过，若不一致，则表示测试失败。若测试失败，则测试终端可以根据测试层对待测子程序的失败原因进行定位。即测试终端可以确定待测子程序的失败原因发生在哪一个测试层，由此能够实现精准定位。
以待测子程序为“登录”进行说明。当游客登录时，测试终端可以识别出所需的测试层可以只有界面层。界面层脚本调用相应的测试用例进行测试。如果测试失败，则可以指将失败原因定位在界面层测试失败。当已注册的用 户登录时，测试终端可以识别出所需的测试层可以包括界面层、数据库层和服务层。每个测试层分别调用不同的测试用例进行测试。具体的，通过待测子程序向服务器发送登录请求，登录请求中携带了用户名、密码以及验证码等信息。界面层测试脚本根据登录请求进行界面层测试。数据库层测试脚本根据用户名、密码以及验证码，调用数据库的校验逻辑进行校验测试。服务层测试脚本调用接口进行页面跳转测试。其中，界面层、数据库层以及服务层的测试可以完全隔离。如果某一层的测试结果表示该层测试失败，则可以将其失败原因定位至该层，测试失败的测试层可以是一个也可以是多个。由此实现精准定位。
本实施例中，根据待测子程序可以识别所需的测试层。通过调用与测试层对应的测试脚本和待测子程序对应的测试用例对待测子程序进行自动化测试。如果测试失败，则能够将失败原因准确定位至对应的测试层。在这个过程中，由于应用程序的多个子程序是分别独立进行测试的，如果出现测试失败的情况，可以只针对待测子程序对失败原因进行精准定位，不需要对整个应用程序从整体上来排除失败原因，能够有效提高测试失败原因的定位效率。
在一个实施例中，待测子程序具有对应的版本信息，版本信息包括版本号，该方法还包括：获取测试用例配置文件，测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；根据待测子程序的版本号获取对应的测试用例名称；根据测试用例名称调用对应的测试用例。
本实施例中，在对待测子程序进行测试之前，测试终端还需要获取相应的测试用例。测试用例可以存储在测试终端本地，也可以存储在服务器。测试用例具有对应的测试用例配置文件。测试用例配置文件可以存储在测试终端本地，也可以存储在服务器。
不同的待测子程序可以共用一个测试用例配置文件。共用的测试用例配置文件中可以记录了应用程序所有待测子程序进行测试所需的测试用例，包括待测子程序的标识、版本号与对应的测试用例名称。每个待测子程序也可以具有单独的测试用例配置文件。单独的测试用例配置文件中可以只记录每 个待测子程序测试所需的测试用例，包括待测子程序的标识、版本号以及对应的测试用例。
测试终端可以获取测共用的测试用例配置文件，根据待测子程序的标识和版本号在共用的测试用例配置文件中检索对应的测试用例名称。测试终端根据检索到的测试用例名称调用对应的测试用例，以便对待测子程序进行测试。
测试终端还可以根据待测子程序的标识获取独立的测试用例配置文件，在独立的测试用例配置文件中利用待测子程序的版本号检索对应的测试用例名称。测试终端根据检索到的测试用例名称调用对应的测试用例，以便对待测子程序进行测试。通过测试用例配置文件，可以快速获取到与待测子程序版本号对应的测试用例，有利于提高测试效率。
在一个实施例中，该方法还包括：获取待测子程序的当前版本的映射文件；当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；获取待测子程序的上一版本的映射文件；上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；将当前版本的映射文件与上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；利用发生变化的功能点和/或发生变化的存储路径识别待测功能点；利用当前版本的映射文件获取待测子程序中待测功能点对应的测试用例。
为了进一步提高测试效率，在待测子程序的回归测试中可以考虑缩小测试范围，只对修复后的功能点或新增的功能点进行测试。待测子程序可以包括一个或多个功能点。功能点可以通过代码文件来实现其对应的功能。测试人员通过测试终端可以根据待测子程序的功能点、代码文件对应的存储路径以及功能点对应的测试用例生成映射文件。不同版本的待测子程序可以具有不同的映射文件。
测试终端获取待测子程序当前版本的映射文件与上一版本的映射文件，将两个映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径。当前版本可以对上一版本中的一个或多个功能点进行修复。当前版本中 修复后的功能点也可以称为发生变化的功能点。当前版本还可以新增功能点，新增的功能点与上一版本的功能点相比，也可以称为发生了变化的功能点。
待测子程序当前版本的各个功能点的代码文件与上一个版本的多个代码文件相比，存储路径也可能会发生变化。除了新增代码文件的存储路径之外，修复后的功能点所对应的代码文件可能会存在与之前不同的路径下。也可能会在之前的路径下替换掉上一版本的代码文件。
测试终端根据发生变化的功能点和/或发生变化的存储路径分别获取当前版本的代码文件以及上一版本的代码文件，将两个版本的代码文件进行比对，若不同，则将当前版本的代码文件所对应的功能点记录为待测功能点。测试终端根据待测功能点在测试用例配置文件中检索对应的测试用例名称。根据测试用例名称调用对应的测试用例，以便对待测子程序进行测试。
本实施例中，通过对待测子程序当前版本的映射文件与上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径。进而利用发生变化的功能点和/或发生变化的存储路径可以准确识别出待测功能点，通过待测功能点获取对应的测试用例。由此在待测子程序的回归测试中能够精准的确定测试范围，从而能够有效提高测试效率。
在一个实施例中，如图2所示，提供了一种分层测试装置，包括：识别模块202、测试模块204和定位模块206，其中：
识别模块202，用于获取应用程序的待测子程序，识别待测子程序对应的测试层。
测试模块204，用于调用与测试层对应的测试脚本以及与待测子程序对应的测试用例；通过测试脚本和测试用例对待测子程序进行测试。
定位模块206，用于输出测试结果，若测试结果表示测试失败，则将失败原因定位至对应的测试层。
在一个实施例中，测试层具有对应的测试层配置文件，识别模块202还用于获取待测子程序对应的版本信息；版本信息中包括待测子程序对应的功能点；获取多个测试层配置文件；测试层配置文件中包括测试层对应的功能 点；根据待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到待测子程序所需的测试层。
在一个实施例中，识别模块202还用于运行待测子程序，检测与子程序发生交互的测试层；将与待测子程序发生交互的测试层记录为待测子程序所需的测试层。
在一个实施例中，待测子程序具有对应的版本信息，版本信息包括版本号，测试模块204还用于获取测试用例配置文件，测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；根据待测子程序的版本号获取对应的测试用例名称；根据测试用例名称调用对应的测试用例。
在一个实施例中，测试模块204还用于获取待测子程序的当前版本的映射文件；当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；获取待测子程序的上一版本的映射文件；上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；将当前版本的映射文件与上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；利用发生变化的功能点和/或发生变化的存储路径识别待测功能点；利用当前版本的映射文件获取待测子程序中待测功能点对应的测试用例。
在一个实施例中，提供了一种计算机设备，包括上述实施例中提及的测试终端。如图3所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该计算机设备的非易失性存储介质存储有操作系统和和计算机可读指令，该计算机可读指令被处理器执行时以实现一种分层测试方法。该计算机设备的内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的网络接口用于与外部的服务器通过网络连接通信，比如，向服务器发送登录请求等。处理器执行计算机可读指令时可以执行以下步骤：
获取应用程序的待测子程序，识别待测子程序对应的测试层；调用与测试层对应的测试脚本以及与待测子程序对应的测试用例；通过测试脚本和测 试用例对待测子程序进行测试；输出测试结果，若测试结果表示测试失败，则将失败原因定位至对应的测试层。
本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，测试层具有对应的测试层配置文件，处理器执行计算机可读指令时还执行以下步骤：
获取待测子程序对应的版本信息；版本信息中包括待测子程序对应的功能点；
获取多个测试层配置文件；测试层配置文件中包括测试层对应的功能点；
根据待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到待测子程序所需的测试层。
在一个实施例中，处理器执行计算机可读指令时还执行以下步骤：
运行待测子程序，检测与子程序发生交互的测试层；
将与待测子程序发生交互的测试层记录为待测子程序所需的测试层。
在一个实施例中，待测子程序具有对应的版本信息，版本信息包括版本号，处理器执行计算机可读指令时还执行以下步骤：
获取测试用例配置文件，测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；
根据待测子程序的版本号获取对应的测试用例名称；
根据测试用例名称调用对应的测试用例。
在一个实施例中，处理器执行计算机可读指令时还执行以下步骤：
获取待测子程序的当前版本的映射文件；当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；
获取待测子程序的上一版本的映射文件；上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；
将当前版本的映射文件与上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；
利用发生变化的功能点和/或发生变化的存储路径识别待测功能点；
利用当前版本的映射文件获取待测子程序中待测功能点对应的测试用例。
在一个实施例中，提供了一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
获取应用程序的待测子程序，识别待测子程序对应的测试层；
调用与测试层对应的测试脚本以及与待测子程序对应的测试用例；
通过测试脚本和测试用例对待测子程序进行测试；
输出测试结果，若测试结果表示测试失败，则将失败原因定位至对应的测试层。
在一个实施例中，测试层具有对应的测试层配置文件，计算机可读指令被处理器执行时还执行以下步骤：
获取待测子程序对应的版本信息；版本信息中包括待测子程序对应的功能点；
获取多个测试层配置文件；测试层配置文件中包括测试层对应的功能点；
根据待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到待测子程序所需的测试层。
在一个实施例中，计算机可读指令被处理器执行时还执行以下步骤：
运行待测子程序，检测与子程序发生交互的测试层；
将与待测子程序发生交互的测试层记录为待测子程序所需的测试层。
在一个实施例中，待测子程序具有对应的版本信息，版本信息包括版本号，计算机可读指令被处理器执行时还执行以下步骤：
获取测试用例配置文件，测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；
根据待测子程序的版本号获取对应的测试用例名称；
根据测试用例名称调用对应的测试用例。
在一个实施例中，计算机可读指令被处理器执行时还执行以下步骤：
获取待测子程序的当前版本的映射文件；当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；
获取待测子程序的上一版本的映射文件；上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；
将当前版本的映射文件与上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；
利用发生变化的功能点和/或发生变化的存储路径识别待测功能点；
利用当前版本的映射文件获取待测子程序中待测功能点对应的测试用例。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一非易失性计算机可读取存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种分层测试方法，包括：
    获取应用程序的待测子程序，识别待测子程序对应的测试层；
    调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；
    通过所述测试脚本和测试用例对所述待测子程序进行测试；及
    输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
  2. 根据权利要求1所述的方法，其特征在于，所述测试层具有对应的测试层配置文件，所述识别待测子程序对应的测试层的步骤包括：
    获取所述待测子程序对应的版本信息；所述版本信息中包括待测子程序对应的功能点；
    获取多个测试层配置文件；所述测试层配置文件中包括测试层对应的功能点；及
    根据所述待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到所述待测子程序所需的测试层。
  3. 根据权利要求1所述的方法，其特征在于，所述识别待测子程序对应的测试层的步骤包括：
    运行所述待测子程序，检测与所述子程序发生交互的测试层；及
    将与所述待测子程序发生交互的测试层记录为所述待测子程序所需的测试层。
  4. 根据权利要求1所述的方法，其特征在于，所述待测子程序具有对应的版本信息，所述版本信息包括版本号，所述方法还包括：
    获取测试用例配置文件，所述测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；
    根据所述待测子程序的版本号获取对应的测试用例名称；及
    根据所述测试用例名称调用对应的测试用例。
  5. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    获取所述待测子程序的当前版本的映射文件；所述当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；
    获取所述待测子程序的上一版本的映射文件；所述上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；
    将所述当前版本的映射文件与所述上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；
    利用所述发生变化的功能点和/或所述发生变化的存储路径识别待测功能点；及
    利用所述当前版本的映射文件获取所述待测子程序中待测功能点对应的测试用例。
  6. 一种分层测试装置，包括：
    识别模块，用于获取应用程序的待测子程序，识别待测子程序对应的测试层；
    测试模块，用于调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；通过所述测试脚本和测试用例对所述待测子程序进行测试；及
    定位模块，用于输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
  7. 根据权利要求6所述的装置，其特征在于，所述测试层具有对应的测试层配置文件，所述识别模块还用于获取所述待测子程序对应的版本信息；所述版本信息中包括待测子程序对应的功能点；获取多个测试层配置文件；所述测试层配置文件中包括测试层对应的功能点；及根据所述待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到所述待测子程序所需的测试层。
  8. 根据权利要求6所述的装置，其特征在于，所述识别模块还用于运行所述待测子程序，检测与所述子程序发生交互的测试层；及将与所述待测子 程序发生交互的测试层记录为所述待测子程序所需的测试层。
  9. 根据权利要求6所述的装置，其特征在于，所述待测子程序具有对应的版本信息，所述版本信息包括版本号，所述测试模块还用于获取测试用例配置文件，所述测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；根据所述待测子程序的版本号获取对应的测试用例名称；及根据所述测试用例名称调用对应的测试用例。
  10. 根据权利要求6所述的装置，其特征在于，所述测试模块还用于获取所述待测子程序的当前版本的映射文件；所述当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；获取所述待测子程序的上一版本的映射文件；所述上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；将所述当前版本的映射文件与所述上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；利用所述发生变化的功能点和/或所述发生变化的存储路径识别待测功能点；及利用所述当前版本的映射文件获取所述待测子程序中待测功能点对应的测试用例。
  11. 一种测试终端，包括存储器和一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
    获取应用程序的待测子程序，识别待测子程序对应的测试层；
    调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；
    通过所述测试脚本和测试用例对所述待测子程序进行测试；及
    输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
  12. 根据权利要求11所述的测试终端，其特征在于，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
    获取所述待测子程序对应的版本信息；所述版本信息中包括待测子程序 对应的功能点；
    获取多个测试层配置文件；所述测试层配置文件中包括测试层对应的功能点；及
    根据所述待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到所述待测子程序所需的测试层。
  13. 根据权利要求11所述的测试终端，其特征在于，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
    运行所述待测子程序，检测与所述子程序发生交互的测试层；及
    将与所述待测子程序发生交互的测试层记录为所述待测子程序所需的测试层。
  14. 根据权利要求11所述的测试终端，其特征在于，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
    获取测试用例配置文件，所述测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；
    根据所述待测子程序的版本号获取对应的测试用例名称；及
    根据所述测试用例名称调用对应的测试用例。
  15. 根据权利要求11所述的测试终端，其特征在于，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
    获取所述待测子程序的当前版本的映射文件；所述当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；
    获取所述待测子程序的上一版本的映射文件；所述上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；
    将所述当前版本的映射文件与所述上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；
    利用所述发生变化的功能点和/或所述发生变化的存储路径识别待测功能点；及
    利用所述当前版本的映射文件获取所述待测子程序中待测功能点对应的测试用例。
  16. 一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
    获取应用程序的待测子程序，识别待测子程序对应的测试层；
    调用与所述测试层对应的测试脚本以及与所述待测子程序对应的测试用例；
    通过所述测试脚本和测试用例对所述待测子程序进行测试；及
    输出测试结果，若所述测试结果表示测试失败，则将失败原因定位至对应的测试层。
  17. 根据权利要求16所述的存储介质，其特征在于，所述测试层具有对应的测试层配置文件，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    获取所述待测子程序对应的版本信息；所述版本信息中包括待测子程序对应的功能点；
    获取多个测试层配置文件；所述测试层配置文件中包括测试层对应的功能点；及
    根据所述待测子程序对应的功能点对多个测试层配置文件中的测试层对应的功能点进行检索，得到所述待测子程序所需的测试层。
  18. 根据权利要求16所述的存储介质，其特征在于，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    运行所述待测子程序，检测与所述子程序发生交互的测试层；及
    将与所述待测子程序发生交互的测试层记录为所述待测子程序所需的测试层。
  19. 根据权利要求16所述的存储介质，其特征在于，所述待测子程序具有对应的版本信息，所述版本信息包括版本号，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    获取测试用例配置文件，所述测试用例配置文件中记录了待测子程序的版本号与对应的测试用例名称；
    根据所述待测子程序的版本号获取对应的测试用例名称；及
    根据所述测试用例名称调用对应的测试用例。
  20. 根据权利要求16所述的存储介质，其特征在于，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    获取所述待测子程序的当前版本的映射文件；所述当前版本的映射文件包括当前版本的功能点、存储路径和对应的测试用例；
    获取所述待测子程序的上一版本的映射文件；所述上一版本的映射文件包括上一版本的功能点、存储路径和对应的测试用例；
    将所述当前版本的映射文件与所述上一版本的映射文件进行比较，得到发生变化的功能点和/或发生变化的存储路径；
    利用所述发生变化的功能点和/或所述发生变化的存储路径识别待测功能点；及
    利用所述当前版本的映射文件获取所述待测子程序中待测功能点对应的测试用例。
PCT/CN2017/108271 2017-07-26 2017-10-30 分层测试方法、装置、计算机设备和存储介质 WO2019019454A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710618312.2A CN107688534A (zh) 2017-07-26 2017-07-26 分层测试方法、装置、计算机设备和存储介质
CN201710618312.2 2017-07-26

Publications (1)

Publication Number Publication Date
WO2019019454A1 true WO2019019454A1 (zh) 2019-01-31

Family

ID=61153035

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/108271 WO2019019454A1 (zh) 2017-07-26 2017-10-30 分层测试方法、装置、计算机设备和存储介质

Country Status (2)

Country Link
CN (1) CN107688534A (zh)
WO (1) WO2019019454A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110874315B (zh) * 2018-08-30 2024-04-19 阿里巴巴新加坡控股有限公司 测试方法、装置、电子设备和存储介质
CN109491916B (zh) * 2018-11-12 2022-03-25 北京东土科技股份有限公司 一种操作系统的测试方法、装置、设备、系统和介质
CN109684112B (zh) * 2018-12-29 2021-06-29 北京小米移动软件有限公司 程序文件运行方法、装置、终端及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070279701A1 (en) * 2006-05-30 2007-12-06 Microsoft Corporation Automatic Test Case For Graphics Design Application
CN104598376A (zh) * 2014-12-30 2015-05-06 中国科学院计算机网络信息中心 一种数据驱动的分层自动化测试系统和方法
CN105260300A (zh) * 2015-09-24 2016-01-20 四川长虹电器股份有限公司 基于会计准则通用分类标准应用平台的业务测试方法
CN106201894A (zh) * 2016-07-21 2016-12-07 浪潮电子信息产业股份有限公司 一种软件测试装置和方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101017457A (zh) * 2007-02-09 2007-08-15 山东浪潮齐鲁软件产业股份有限公司 一种计算机软件的自动化测试方法
CN102750145B (zh) * 2012-06-05 2015-02-25 怯肇乾 一种网络系统软件体系框架及其实现方法
JP2014056388A (ja) * 2012-09-12 2014-03-27 Hitachi Solutions Ltd ソフトウェア業務処理テスト簡易化装置
CN103699488B (zh) * 2013-12-30 2017-01-04 优视科技有限公司 基于调用关系依赖图的回归测试方法及系统
CN104317559A (zh) * 2014-08-26 2015-01-28 国家电网公司 基于gmf的可视化建模平台

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070279701A1 (en) * 2006-05-30 2007-12-06 Microsoft Corporation Automatic Test Case For Graphics Design Application
CN104598376A (zh) * 2014-12-30 2015-05-06 中国科学院计算机网络信息中心 一种数据驱动的分层自动化测试系统和方法
CN105260300A (zh) * 2015-09-24 2016-01-20 四川长虹电器股份有限公司 基于会计准则通用分类标准应用平台的业务测试方法
CN106201894A (zh) * 2016-07-21 2016-12-07 浪潮电子信息产业股份有限公司 一种软件测试装置和方法

Also Published As

Publication number Publication date
CN107688534A (zh) 2018-02-13

Similar Documents

Publication Publication Date Title
US10055338B2 (en) Completing functional testing
US10372594B2 (en) Method and device for retrieving test case based on code coverage
US9672029B2 (en) Determining test case priorities based on tagged execution paths
US8151247B2 (en) Test data management
US9026998B2 (en) Selecting relevant tests to quickly assess code stability
KR101410099B1 (ko) 단위 테스트 케이스 재사용 기반의 함수 테스트 장치 및 그 함수 테스트 방법
US20150007148A1 (en) Identifying Test Cases Based on Changed Test Code
BR102015030798A2 (pt) sistema e método
US20170220458A1 (en) Orchestrating and providing a regression test
WO2019019647A1 (zh) 应用程序测试范围确定方法、系统、服务器和存储介质
US10565091B2 (en) Method and apparatus for automatic cross-system program debugging
US10049031B2 (en) Correlation of violating change sets in regression testing of computer software
WO2019019454A1 (zh) 分层测试方法、装置、计算机设备和存储介质
CN111290941A (zh) 多个接口的测试方法、装置、计算设备和介质
US9183122B2 (en) Automated program testing to facilitate recreation of test failure
WO2017036068A1 (zh) 一种实现软件自动化测试的方法和系统
US11663113B2 (en) Real time fault localization using combinatorial test design techniques and test case priority selection
US9842044B2 (en) Commit sensitive tests
US11132286B1 (en) Dynamic reordering of test case execution
WO2023207973A1 (zh) 编译器测试方法、用例生成方法、装置及指令存储结构
CN113806209A (zh) 接口测试方法、框架、计算机设备和存储介质
CN111666200A (zh) 一种pc软件冷启动耗时的测试方法及终端
US11748246B2 (en) Crowd-sourced QA with trusted compute model
US20160275002A1 (en) Image capture in application lifecycle management for documentation and support
CN117435503A (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: 17919641

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

Country of ref document: EP

Kind code of ref document: A1

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 03.08.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 17919641

Country of ref document: EP

Kind code of ref document: A1