CN113961448A - Test case verification method, device, equipment and storage medium - Google Patents

Test case verification method, device, equipment and storage medium Download PDF

Info

Publication number
CN113961448A
CN113961448A CN202111070498.5A CN202111070498A CN113961448A CN 113961448 A CN113961448 A CN 113961448A CN 202111070498 A CN202111070498 A CN 202111070498A CN 113961448 A CN113961448 A CN 113961448A
Authority
CN
China
Prior art keywords
test case
directory
verification
verification result
type
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111070498.5A
Other languages
Chinese (zh)
Inventor
胡平平
韩照光
薛大伟
农华莲
黄琪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and Technology Co Ltd
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 Beijing Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN202111070498.5A priority Critical patent/CN113961448A/en
Publication of CN113961448A publication Critical patent/CN113961448A/en
Pending legal-status Critical Current

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/3684Test management for test design, e.g. generating new test cases

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

The disclosure provides a test case verification method, a test case verification device, test case verification equipment and a storage medium, and relates to the technical field of computers, in particular to the technical fields of automatic testing, mobile application and the like. The test case verification method comprises the following steps: the method comprises the steps of obtaining a test case, and obtaining a standard type to be adopted, wherein the standard type is used for verifying the test case; based on the standard type to be adopted, verifying the test case to obtain a verification result of the test case; and if the verification result is failed, displaying first prompt information, wherein the first prompt information is used for prompting the specification type which the test case is not in conformity with. The method and the device can improve the verification efficiency of the test case.

Description

Test case verification method, device, equipment and storage medium
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to the technical fields of automated testing, mobile applications, and the like, and in particular, to a method, an apparatus, a device, and a storage medium for verifying a test case.
Background
Along with the upgrading iteration of user requirements, the test cases of the interface are increased, and the test cases can be applied to the automatic test task of the interface. In order to ensure the smooth execution of the automated test task, the standardization of the test case needs to be ensured.
In the related art, a manual method is generally adopted to carry out standardized verification on a test case.
Disclosure of Invention
The disclosure provides a test case verification method, a test case verification device, test case verification equipment and a storage medium.
According to an aspect of the present disclosure, a method for verifying a test case is provided, including: acquiring a standard type to be adopted of a test case, wherein the standard type is used for verifying the test case; based on the standard type to be adopted, verifying the test case to obtain a verification result of the test case; and if the verification result is failed, displaying first prompt information, wherein the first prompt information is used for prompting the specification type which the test case is not in conformity with.
According to another aspect of the present disclosure, there is provided a verification apparatus for a test case, including: the system comprises an acquisition module, a test case generation module and a test result generation module, wherein the acquisition module is used for acquiring a test case and acquiring a standard type to be adopted, and the standard type is used for verifying the test case; the verification module is used for verifying the test case based on the standard type to be adopted so as to obtain a verification result of the test case; and the display module is used for displaying first prompt information if the verification result is failed, wherein the first prompt information is used for prompting the specification type which is not met by the test case.
According to another aspect of the present disclosure, there is provided an electronic device including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of the above aspects.
According to another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method according to any one of the above aspects.
According to another aspect of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of the above aspects.
According to the technical scheme disclosed by the invention, the verification efficiency of the test case can be improved.
It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.
Drawings
The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:
FIG. 1 is a schematic diagram according to a first embodiment of the present disclosure;
FIG. 2 is a schematic diagram according to a second embodiment of the present disclosure;
FIG. 3 is a schematic diagram according to a third embodiment of the present disclosure;
FIG. 4 is a schematic diagram according to a fourth embodiment of the present disclosure;
FIG. 5 is a schematic diagram according to a fifth embodiment of the present disclosure;
FIG. 6 is a schematic diagram according to a sixth embodiment of the present disclosure;
fig. 7 is a schematic diagram of an electronic device for implementing any one of the test case verification methods according to the embodiments of the present disclosure.
Detailed Description
Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
In the related art, a manual mode is generally adopted to carry out standardized verification on a test case, but the manual verification mode has the problems of poor efficiency and the like.
In order to improve the verification efficiency of the test case, the present disclosure provides the following embodiments.
Fig. 1 is a schematic diagram according to a first embodiment of the present disclosure, where this embodiment provides a method for verifying a test case, where the method includes:
101. the method comprises the steps of obtaining a test case and obtaining a standard type to be adopted, wherein the standard type is used for verifying the test case.
102. And verifying the test case based on the standard type to be adopted to obtain a verification result of the test case.
103. And if the verification result is failed, displaying first prompt information, wherein the first prompt information is used for prompting the specification type which the test case is not in conformity with.
The execution subject of this embodiment may be a verification apparatus for a test case, and the specific form of the apparatus is not limited, and may be hardware, software, or a combination of hardware and software.
The Test Case (Test Case) refers to the description of a Test task performed on a specific software product, and embodies Test schemes, methods, techniques and strategies. The contents of the test object, the test environment, the input data, the test steps, the expected results, the test scripts and the like are included, and finally, a document is formed. Simply considered, a test case is a set of test inputs, execution conditions, and expected results tailored for a particular purpose to verify whether a particular software requirement is met.
In the embodiment, the test case is verified by adopting the standard type, so that the automatic verification of the test case can be realized, and the verification efficiency of the test case is improved. Furthermore, when the test case does not pass the verification, the non-conforming standard type of the test case is prompted, so that a user can modify the non-conforming test case in a targeted manner, and the modification efficiency is improved.
All test cases of the same tested service are divided into a Continuous Integration (CI) directory and a Development (DEV) directory, wherein a case set of an automatic regression task is stored in the CI directory; storing a newly-added case set in a development testing stage under the DEV directory; and the item is moved to the CI directory after being on-line.
Further, the test cases in the DEV directory may be further divided into written test cases and existing test cases in the DEV directory.
In some embodiments, obtaining the test case may include:
responding to the completion of test case compiling, and acquiring the compiled test case; alternatively, the first and second electrodes may be,
responding to the test case in the first directory being moved into a second directory, and acquiring the test case to be moved into the second directory; alternatively, the first and second electrodes may be,
and acquiring the existing test cases in the first directory or the second directory.
Specifically, the first directory may be a DEV directory, and the second directory may be a CI directory.
As shown in FIG. 2, the verification process of the test case can occur when the writing of the test case is completed, before moving into the CI directory, and verifying the existing test case in the DEV directory or the CI directory, and FIG. 2 shows the verification of the existing test case in the CI directory.
It is to be understood that fig. 2 shows a plurality of verification processes, and in practice, one or more of the verification processes may be selected according to the actual situation. The reason for failing to prompt may be specifically a specification type that prompts that the test case is not in compliance.
Through multiple obtaining ways of the test cases, the test cases at different stages can be verified, the normalization of the newly added and stored test cases can be ensured, and further the smooth proceeding of the automatic test is ensured.
In some embodiments, the method further comprises:
if the test case is the compiled test case and the verification result of the compiled test case is passed, performing interface debugging on an interface corresponding to the compiled test case; alternatively, the first and second electrodes may be,
if the test case is the test case to be moved into the second directory and the verification result of the test case to be moved into the second directory is passed, moving the test case to be moved into the second directory; alternatively, the first and second electrodes may be,
and if the test case is the existing test case and the verification result of the existing test case is passed, displaying second prompt information, wherein the second prompt information is used for prompting that no non-standard test case exists.
As shown in fig. 3, a verification process for a written test case is shown. Referring to fig. 3, after a research & development (rd) proposes a test, or after a quality assurance (qa) compiles a test case (which may be referred to as a case for short) daily, a verification process for the compiled test case may be triggered by page click verification.
After the written test case is verified, if the test case passes the verification, a normal interface debugging process can be executed, namely, a normal request is sent to the interface, and the return value of the interface is displayed.
If the verification fails, the failed use case and the reason can be displayed on the page, and modification is prompted.
As shown in FIG. 4, a verification process for test cases to be stolen into a CI directory is shown. Referring to fig. 4, after an item (an automated test related item) comes online, a test case in the DEV directory is regularly moved to the CI directory, before the test case is moved to the CI directory, the test case may be checked first, if the test case passes, the test case is moved to the CI directory, otherwise, the failed case and reason may be prompted in a manner of mail, etc., to prompt modification.
As shown in FIG. 5, a verification process for an existing test case in a CI directory or a DEV directory is shown. Referring to fig. 5, for an existing test case in the CI directory or the DEV directory, rd or qa may trigger a verification process for the written test case through page click verification. If the case passes through the page, prompting that no non-standard test case exists, otherwise, displaying the failed case and reason on the page, and prompting to modify.
Corresponding verification processes are executed in different stages, so that the method and the device can be suitable for respective characteristics of different stages, and the verification requirements of different stages are met.
In some embodiments, the obtaining the specification type to be adopted includes:
acquiring a default configuration standard type, and taking the default configuration standard type as the standard type to be adopted; alternatively, the first and second electrodes may be,
providing a plurality of optional specification types for a user, receiving a specification type selected by the user from the plurality of optional specification types, and taking the selected specification type as the specification type to be adopted.
That is, when the user (rd person or qa person) performs verification of the test case, a default configured specification type may be adopted, or an appropriate specification type may be selected according to its own requirements.
By providing multiple specification type acquisition modes, flexibility can be improved.
In some embodiments, the to-be-adopted specification types are multiple, and the verifying the test case based on the to-be-adopted specification types to obtain the verification result of the test case includes:
verifying the test case by adopting each of the multiple standard types to obtain a verification result of the test case corresponding to each standard type;
and if the verification result corresponding to each specification type is passed, determining that the verification result of the test case is passed, otherwise, determining that the verification result of the test case is not passed.
For example, the types of specifications to be adopted include: and the specification-1 and the specification-2 are used for obtaining a verification result-1 based on the specification-1 and obtaining a verification result-2 based on the specification-2, and the verification result of the test case is passed only when the verification result-1 and the verification result-2 are passed. Otherwise, if the verification result corresponding to any one of the to-be-adopted standard types is failed, the verification result of the test case is failed.
The verification result corresponding to each specification type is passed, and the verification result of the test case is passed, so that the standardization of the test case on different dimensions can be ensured.
In some embodiments, the type of specification to be adopted comprises at least one of:
naming and checking;
use cases;
a global variable;
initializing and restoring;
declaring a miss;
writing a dead domain name;
checking the relation;
the structured query language (sql) check of the write interface.
The specification types can characterize the maintainability, stability and validity of the test case.
The following describes each specification type:
(1) naming check
The automatic Test cases are uniformly maintained on an Integrated Test Platform (ITP) Test Platform, the ITP Platform supports case searching according to case names at present, and people often search related cases in a keyword searching mode when writing cases or troubleshooting problems in daily life, so that the case naming specification can help people to quickly find related cases.
Specifically, when the test case is verified based on naming, whether the name of the test case meets a preset specification or not can be detected, and the preset specification can be customized according to self requirements, for example, the name cannot contain non-character content and the like, or the name needs to contain which keywords and the like. If the rule does not meet the preset specification, the name check is not passed, otherwise, the name check is passed.
(2) Use case validation
When the use case is written, the use case application is explained, and the personnel who find out the use case failure can be assisted to quickly locate whether the parameters of the use case meet expectations.
Specifically, when checking based on use cases, it may be detected whether each parameter in the test case is marked with a use, and if there is a parameter with a use that is not marked, checking based on use cases is not passed. Otherwise, each parameter is marked with the use, and the use case is used for verification.
(3) Global variable check
The universal variable is extracted to be used as a global variable, when the business logic is changed or the raw material is deleted, the parameters of the global variable can be directly modified without modifying a single use case one by one, and the use case modification cost and time consumption are reduced.
Specifically, when the test case is verified based on the global variable, whether a variable that should be marked as the global variable in the test case is marked with the global variable may be detected, and the variable that should be marked as the global variable is known in advance, that is, corresponding to different test product lines, which variable is the global variable may be determined in advance, for example, the current global variable is age, if the age is marked as the global variable in the test case, the test case passes the global variable verification, otherwise, the test case does not pass the global variable verification.
(4) Initialization recovery check
Before writing a use case, usually, data on which a test case depends is constructed, and part of the use case does not delete the part of the data, so that the data reaches service limitation, and a regression task fails, therefore, for the use case on which the dependent data is constructed, an operation of deleting the dependent data needs to be added.
Specifically, when the verification is restored based on the initialization, if there is a new operation on a certain data, a deletion operation is also applied. For example, a new operation exists in the test case corresponding to the data1, if the test case further includes a deletion operation corresponding to the data1, the test case passes the initialization restoration check, otherwise, the test case does not pass the initialization restoration check.
(5) Assertion miss
The assertion is the key of the automatic regression case, if the assertion is not filled in the case, the case belongs to an invalid case, and whether the result meets the expectation or not can not be verified, so that the problem on the line leaks out, therefore, the assertion missing verification needs to be added, and the effectiveness of the regression task is improved.
Specifically, if no assertion is present in a certain test case, the test case fails assertion-missing verification, and otherwise passes assertion-missing verification.
(6) Write dead field names
In the case regression task, the case regression task is generally executed in an environment where a specified branch is deployed, when a case domain name is written to death, the environment of the domain name which is written to death is used by default, and the code versions between the two environments are different, so that the case regression is invalid, and therefore the case domain name which is written to death needs to be checked.
Specifically, if the URL in the test case is written as: if the domain name + the service name/the method name are used, the writing of the domain name is indicated, and the writing of the domain name verification is not passed; otherwise, if the URL only writes the service name/method name and does not write the domain name, the domain name is verified by the write-dead domain name.
(7) Relationship checking
In the regression testing task, the use cases related to the project upgrading are required to be screened according to the project upgrading points, and only the use case operation named as a specific value can be identified as the effective use case by the screening task, so that a plurality of operation of the use cases are required to contain the keyword.
Specifically, the keywords of the operation of the test case must include modification, rather than addition and deletion, and only if the keywords include modification, the relationship check is passed, otherwise the relationship check is not passed.
(8) Sql verification for write interfaces
For the writing interface, relevant data can be generated in the database, and the data values are the key of the service, so that sql check needs to be added for the writing interface to judge whether the data is normally put in storage.
Specifically, in the test case, the sql check must be performed on the corresponding write interface, and if not, the sql check of the write interface is not passed, otherwise, the sql check is passed.
Through the selected standard type, the multi-dimensional standardized evaluation of the test case can be realized.
In the embodiment of the disclosure, the test case is verified by adopting the standard type, so that the automatic verification of the test case can be realized, and the verification efficiency of the test case is improved. Furthermore, when the test case does not pass the verification, the non-conforming standard type of the test case is prompted, so that a user can modify the non-conforming test case in a targeted manner, and the modification efficiency is improved. Furthermore, through multiple specification types, the test cases can be subjected to normalized evaluation from multiple different dimensions, so that the test cases are more normalized. The newly added test cases and the stock test cases can be verified through the verification in different stages of the test cases.
Through automatic case specification verification, stock case specification is optimized on the basis of controlling increment case specification, the stability of an automatic regression task is improved to a great extent, and the labor consumption for troubleshooting automatic regression failure is reduced. Through the standardized verification of the test cases, the failure ratio of the automatic regression task caused by case problems is obviously reduced, and the stability of the automatic regression test is improved.
Fig. 6 is a schematic diagram according to a sixth embodiment of the present disclosure, which provides a verification apparatus for test cases. As shown in fig. 6, the apparatus 600 includes: an acquisition module 601, a verification module 602, and a display module 603.
The obtaining module 601 is configured to obtain a test case and obtain a standard type to be adopted, where the standard type is used to validate the test case;
the verification module 602 is configured to verify the test case based on the to-be-adopted specification type to obtain a verification result of the test case;
the display module 603 is configured to display a first prompt message if the verification result is failed, where the first prompt message is used to prompt a specification type that the test case does not conform to.
In the embodiment, the test case is verified by adopting the standard type, so that the automatic verification of the test case can be realized, and the verification efficiency of the test case is improved.
In some embodiments, the obtaining module 601 is specifically configured to: responding to the completion of test case compiling, and acquiring the compiled test case; or, in response to the test case in the first directory being moved into the second directory, obtaining the test case to be moved into the second directory; or acquiring the stock test case in the first catalogue or the second catalogue.
In some embodiments, the apparatus 600 further comprises: and a processing module.
The processing module is used for performing interface debugging on an interface corresponding to the compiled test case if the test case is the compiled test case and the verification result of the compiled test case is that the test case passes; or if the test case is the test case to be moved into the second directory and the verification result of the test case to be moved into the second directory is passed, moving the test case to be moved into the second directory; or if the test case is the stock test case and the verification result of the stock test case is passed, displaying second prompt information, wherein the second prompt information is used for prompting that no non-standard test case exists.
In some embodiments, the obtaining module 601 is specifically configured to:
acquiring a default configuration standard type, and taking the default configuration standard type as the standard type to be adopted; or, providing a plurality of alternative specification types for a user, receiving a specification type selected by the user from the plurality of alternative specification types, and taking the selected specification type as the specification type to be adopted.
In some embodiments, the types of the specification to be adopted are multiple, and the verification module 602 is specifically configured to: verifying the test case by adopting each of the multiple standard types to obtain a verification result of the test case corresponding to each standard type; and if the verification result corresponding to each specification type is passed, determining that the verification result of the test case is passed, otherwise, determining that the verification result of the test case is not passed.
In some embodiments, the type of specification to be adopted comprises at least one of:
naming and checking;
checking the use of the use case;
checking a global variable;
initializing recovery verification;
assertion miss checking;
checking a write-dead domain name;
checking the relation;
sql checks of the write interface.
In the embodiment of the disclosure, the test case is verified by adopting the standard type, so that the automatic verification of the test case can be realized, and the verification efficiency of the test case is improved. Furthermore, when the test case does not pass the verification, the non-conforming standard type of the test case is prompted, so that a user can modify the non-conforming test case in a targeted manner, and the modification efficiency is improved. Furthermore, through multiple specification types, the test cases can be subjected to normalized evaluation from multiple different dimensions, so that the test cases are more normalized. The newly added test cases and the stock test cases can be verified through the verification in different stages of the test cases.
It is to be understood that in the disclosed embodiments, the same or similar elements in different embodiments may be referenced.
It is to be understood that "first", "second", and the like in the embodiments of the present disclosure are used for distinction only, and do not indicate the degree of importance, the order of timing, and the like.
The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.
FIG. 7 illustrates a schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.
As shown in fig. 7, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM)702 or a computer program loaded from a storage unit 707 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the electronic device 700 can also be stored. The computing unit 701, the ROM 702, and the RAM 703 are connected to each other by a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.
A number of components in the electronic device 700 are connected to the I/O interface 705, including: an input unit 706 such as a keyboard, a mouse, or the like; an output unit 707 such as various types of displays, speakers, and the like; a storage unit 708 such as a magnetic disk, optical disk, or the like; and a communication unit 709 such as a network card, modem, wireless communication transceiver, etc. The communication unit 709 allows the electronic device 700 to exchange information/data with other devices via a computer network such as the internet and/or various telecommunication networks.
Computing unit 701 may be a variety of general purpose and/or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The computing unit 701 executes the respective methods and processes described above, such as the verification method of the test case. For example, in some embodiments, the verification method of test cases may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 700 via the ROM 702 and/or the communication unit 707. When loaded into RAM 703 and executed by computing unit 701, may perform one or more of the steps of the test case verification method described above. Alternatively, in other embodiments, the computing unit 701 may be configured in any other suitable manner (e.g., by way of firmware) to execute the verification method of the test case.
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.
Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable test case verification apparatus such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.
The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The Server can be a cloud Server, also called a cloud computing Server or a cloud host, and is a host product in a cloud computing service system, so as to solve the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service ("Virtual Private Server", or simply "VPS"). The server may also be a server of a distributed system, or a server incorporating a blockchain.
It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.
The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims (15)

1. A method for verifying a test case comprises the following steps:
the method comprises the steps of obtaining a test case, and obtaining a standard type to be adopted, wherein the standard type is used for verifying the test case;
based on the standard type to be adopted, verifying the test case to obtain a verification result of the test case;
and if the verification result is failed, displaying first prompt information, wherein the first prompt information is used for prompting the specification type which the test case is not in conformity with.
2. The method of claim 1, wherein the obtaining test cases comprises:
responding to the completion of test case compiling, and acquiring the compiled test case; alternatively, the first and second electrodes may be,
responding to the test case in the first directory being moved into a second directory, and acquiring the test case to be moved into the second directory; alternatively, the first and second electrodes may be,
and acquiring the existing test cases in the first directory or the second directory.
3. The method of claim 2, further comprising:
if the test case is the compiled test case and the verification result of the compiled test case is passed, performing interface debugging on an interface corresponding to the compiled test case; alternatively, the first and second electrodes may be,
if the test case is the test case to be moved into the second directory and the verification result of the test case to be moved into the second directory is passed, moving the test case to be moved into the second directory; alternatively, the first and second electrodes may be,
and if the test case is the existing test case and the verification result of the existing test case is passed, displaying second prompt information, wherein the second prompt information is used for prompting that no non-standard test case exists.
4. The method of claim 1, wherein the obtaining a canonical type to employ comprises:
acquiring a default configuration standard type, and taking the default configuration standard type as the standard type to be adopted; alternatively, the first and second electrodes may be,
providing a plurality of optional specification types for a user, receiving a specification type selected by the user from the plurality of optional specification types, and taking the selected specification type as the specification type to be adopted.
5. The method according to claim 1, wherein the to-be-adopted specification types are multiple types, and the verifying the test case based on the to-be-adopted specification types to obtain the verification result of the test case includes:
verifying the test case by adopting each of the multiple standard types to obtain a verification result of the test case corresponding to each standard type;
and if the verification result corresponding to each specification type is passed, determining that the verification result of the test case is passed, otherwise, determining that the verification result of the test case is not passed.
6. The method according to any one of claims 1-5, wherein the canonical type to employ comprises at least one of:
naming and checking;
checking the use of the use case;
checking a global variable;
initializing recovery verification;
assertion miss checking;
checking a write-dead domain name;
checking the relation;
and checking the structured query language sql of the writing interface.
7. A verification device for test cases comprises:
the system comprises an acquisition module, a test case generation module and a test result generation module, wherein the acquisition module is used for acquiring a test case and acquiring a standard type to be adopted, and the standard type is used for verifying the test case;
the verification module is used for verifying the test case based on the standard type to be adopted so as to obtain a verification result of the test case;
and the display module is used for displaying first prompt information if the verification result is failed, wherein the first prompt information is used for prompting the specification type which is not met by the test case.
8. The apparatus of claim 7, wherein the acquisition module is specifically configured to:
responding to the completion of test case compiling, and acquiring the compiled test case; alternatively, the first and second electrodes may be,
responding to the test case in the first directory being moved into a second directory, and acquiring the test case to be moved into the second directory; alternatively, the first and second electrodes may be,
and acquiring stock test cases in the first directory or the second directory.
9. The apparatus of claim 8, further comprising:
the processing module is used for performing interface debugging on an interface corresponding to the compiled test case if the test case is the compiled test case and the verification result of the compiled test case is that the test case passes; or if the test case is the test case to be moved into the second directory and the verification result of the test case to be moved into the second directory is passed, moving the test case to be moved into the second directory; or if the test case is the stock test case and the verification result of the stock test case is passed, displaying second prompt information, wherein the second prompt information is used for prompting that no non-standard test case exists.
10. The apparatus of claim 7, wherein the acquisition module is specifically configured to:
acquiring a default configuration standard type, and taking the default configuration standard type as the standard type to be adopted; alternatively, the first and second electrodes may be,
providing a plurality of optional specification types for a user, receiving a specification type selected by the user from the plurality of optional specification types, and taking the selected specification type as the specification type to be adopted.
11. The apparatus according to claim 7, wherein the specification types to be adopted are multiple, and the verification module is specifically configured to:
verifying the test case by adopting each of the multiple standard types to obtain a verification result of the test case corresponding to each standard type;
and if the verification result corresponding to each specification type is passed, determining that the verification result of the test case is passed, otherwise, determining that the verification result of the test case is not passed.
12. The apparatus according to any one of claims 7-11, wherein the type of specification to employ comprises at least one of:
naming and checking;
checking the use of the use case;
checking a global variable;
initializing recovery verification;
assertion miss checking;
checking a write-dead domain name;
checking the relation;
sql checks of the write interface.
13. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.
14. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-6.
15. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-6.
CN202111070498.5A 2021-09-13 2021-09-13 Test case verification method, device, equipment and storage medium Pending CN113961448A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111070498.5A CN113961448A (en) 2021-09-13 2021-09-13 Test case verification method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111070498.5A CN113961448A (en) 2021-09-13 2021-09-13 Test case verification method, device, equipment and storage medium

Publications (1)

Publication Number Publication Date
CN113961448A true CN113961448A (en) 2022-01-21

Family

ID=79461470

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111070498.5A Pending CN113961448A (en) 2021-09-13 2021-09-13 Test case verification method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN113961448A (en)

Similar Documents

Publication Publication Date Title
US8954930B2 (en) System and method for reducing test effort by object risk analysis
US8782609B2 (en) Test failure bucketing
US9384020B2 (en) Domain scripting language framework for service and system integration
US20140208169A1 (en) Domain scripting language framework for service and system integration
CN110688305B (en) Test environment synchronization method, device, medium and electronic equipment
CN114090113B (en) Method, device, equipment and storage medium for dynamically loading data source processing plug-in
CN113778849A (en) Method, apparatus, device and storage medium for testing code
CN111240981A (en) Interface testing method, system and platform
CN113961448A (en) Test case verification method, device, equipment and storage medium
CN114693116A (en) Method and device for detecting code review validity and electronic equipment
JP2023044720A (en) Computer implemented method for recovering crashed application, computer program product, and remote computer server (remote recovery of crashed process)
CN114546799A (en) Point burying log checking method and device, electronic equipment, storage medium and product
CN111767222A (en) Data model verification method and device, electronic equipment and storage medium
CN113239296B (en) Method, device, equipment and medium for displaying small program
US20240160558A1 (en) Automatic testing of interrelated components of a software application
CN116149707B (en) Method and device for detecting and avoiding upgrading risk of distributed system
CN113760765B (en) Code testing method and device, electronic equipment and storage medium
CN116955201A (en) Data development test method, device, equipment and medium
CN116955189A (en) Automatic testing method, device and equipment for user interface and storage medium
CN114693115A (en) Method and device for detecting code review validity and electronic equipment
CN115525521A (en) Log data verification method and device, electronic equipment, storage medium and product
CN114996141A (en) Software testing method, device, equipment and storage medium
CN111309865A (en) Similar defect report recommendation method, system, computer device and storage medium
CN117271333A (en) Data processing method and device, electronic equipment and readable storage medium
CN113157594A (en) User permission testing method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination