CN115185809A - Software testing method and device and electronic equipment - Google Patents

Software testing method and device and electronic equipment Download PDF

Info

Publication number
CN115185809A
CN115185809A CN202210587665.1A CN202210587665A CN115185809A CN 115185809 A CN115185809 A CN 115185809A CN 202210587665 A CN202210587665 A CN 202210587665A CN 115185809 A CN115185809 A CN 115185809A
Authority
CN
China
Prior art keywords
test
software
document
data
node
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
CN202210587665.1A
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.)
Netease Hangzhou Network Co Ltd
Original Assignee
Netease Hangzhou Network 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 Netease Hangzhou Network Co Ltd filed Critical Netease Hangzhou Network Co Ltd
Priority to CN202210587665.1A priority Critical patent/CN115185809A/en
Publication of CN115185809A publication Critical patent/CN115185809A/en
Pending legal-status Critical Current

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
    • 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/3692—Test management for test results analysis

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 invention provides a software testing method, a software testing device and electronic equipment; wherein, the method comprises the following steps: acquiring a software test document of target software; the document at least comprises a use case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; converting the software test document into a language form corresponding to the target software through a software development kit, and executing the converted software test document in a test environment of the target software; and collecting the execution data generated in the software test document during the execution process, and generating the test result of the target software based on the execution data. The software test files in the method can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.

Description

Software testing method and device and electronic equipment
Technical Field
The present invention relates to the field of software testing technologies, and in particular, to a software testing method and apparatus, and an electronic device.
Background
In the software testing process, for software in a specific service line or project, a test file matched with the software needs to be independently written. Most of the test frameworks in the related art are only suitable for realizing software test requirements in a specific language or test scene. For example, the test file implemented by the HTTP tester framework is only suitable for software testing in Python and Pytest languages, and is suitable for API test scenarios in the HTTP protocol. The test file realized by the Ginkgo test framework is realized by depending on the Go language, and is suitable for test scenes such as unit test, integrated test and the like. In the above manner, the test language and the test scenario of the test file are both limited, so that the tester needs to maintain the test files of various languages and various test scenarios, and the test file has high maintenance cost and low universality.
Disclosure of Invention
In view of this, an object of the present invention is to provide a software testing method, device and electronic device, so as to improve the universality of test files, and reduce the maintenance cost of the test files without requiring a tester to maintain a large number of test files for various languages and various test scenarios.
In a first aspect, an embodiment of the present invention provides a software testing method, where the method includes: acquiring a software test document of target software; the software test document at least comprises a use case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence; converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software; and collecting the execution data generated in the execution process of the software test document, and generating the test result of the target software based on the execution data.
The step of obtaining the software test document of the target software includes: receiving document editing contents through a preset document editor, and generating a software test document through the document editing contents; and/or carrying out format conversion on the original test data through a preset format converter to obtain a software test document; wherein the raw test data comprises one or more of: the method comprises the steps of specifying a test case of an interface test tool, an interface file under specified specifications, a test case in a table form and an operation record file of a specified program.
The step of obtaining the software test document of the target software includes: generating a first step in the step nodes based on original test data in a first test scene; the first test scene is preset with a first protocol; the first step comprises at least one testing step; generating a second step in the step nodes based on the original test data in the second test scene; wherein, the second test scene is preset with a second protocol; the second protocol is different from the first protocol; the second step comprises at least one testing step; arranging the first step and the second step according to a preset arrangement sequence to obtain a test case; and generating a software test document based on the test case, the first step and the second step.
The software test document further comprises: the method comprises the following steps of version number nodes, information nodes, definition nodes and function nodes; the version number node comprises a standard version to which the software test document belongs; the information node comprises a test description, a test classification and a test object corresponding to the software test document; defining nodes including global variables, configuration information and tested services used by software test documents in the test process; the function nodes comprise step functions and check functions used by the software test documents in the test process.
The step of converting the software test document into the language form corresponding to the target software through the software development kit of the target software comprises the following steps: analyzing a software test document, and establishing a test object in a language corresponding to target software; mapping the use case nodes in the software test document and the node data in the step nodes to a test object; and determining the mapped test object as the converted software test document.
The software test documents comprise a plurality of documents; the step of executing the converted software test document in the test environment of the target software includes: acquiring scheduling configuration information corresponding to a software test document; the scheduling configuration information comprises the execution sequence of a plurality of software test documents and the execution mode of the software test documents; the scheduling configuration information is obtained by editing a preset scheduling configuration editor; a plurality of software test documents are executed based on the scheduling configuration information.
The step of collecting the execution data generated in the execution process of the software test document and generating the test result of the target software based on the execution data includes: based on the software test document, calling the target software and the service program which the target software depends on through a preset test tool, and collecting the execution data output by the target software and the service program; the execution data comprises one or more of monitoring index data, log data and link observation data; and summarizing the execution data and the output data of the test tool to obtain the test result of the target software.
In a second aspect, an embodiment of the present invention provides a software testing apparatus, where the apparatus includes: the document acquisition module is used for acquiring a software test document of the target software; the software test document at least comprises a use case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence; the document execution module is used for converting the software test document into a language form corresponding to the target software through a software development kit of the target software and executing the converted software test document in a test environment of the target software; and the result generating module is used for collecting the execution data generated in the execution process of the software test document and generating the test result of the target software based on the execution data.
In a third aspect, an embodiment of the present invention provides an electronic device, which includes a processor and a memory, where the memory stores machine executable instructions capable of being executed by the processor, and the processor executes the machine executable instructions to implement the software testing method.
In a fourth aspect, embodiments of the present invention provide a machine-readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the software testing method described above.
The embodiment of the invention has the following beneficial effects:
the software testing method, the device and the electronic equipment obtain the software testing document of the target software; the software test document at least comprises a case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence; converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software; and collecting the execution data generated in the software test document during the execution process, and generating the test result of the target software based on the execution data. The software test document in the method is separated from a specific computer language, the content of the test case is described through the case node and the step node, the software test document is converted into a language form corresponding to target software through a software development kit in the test process, and the test of the target software is completed. The software test document in the embodiment can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
In order to make the aforementioned and other objects, features and advantages of the present invention comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.
FIG. 1 is a flow chart of a software testing method according to an embodiment of the present invention;
FIG. 2 is a schematic structural diagram of a software test document provided in an embodiment of the present invention;
FIG. 3 is a schematic diagram of a software testing method of this embodiment implemented by a multi-layer interaction among an interaction layer, a data layer, and an execution layer according to an embodiment of the present invention;
fig. 4 is an architecture diagram of a test management scheme according to the software testing method of the embodiment of the present invention;
FIG. 5 is a schematic structural diagram of a software testing apparatus according to an embodiment of the present invention;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings, and it is apparent that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
First, the terms of art related to the present embodiment are explained:
1、OAS
OAS is an abbreviation for Open API Specification, interpreted as the Open Programming Interface (API) Specification, and the predecessor of OAS is the Swagger Specification. OAS is a specification for describing, generating and using visual RESTful Web services and machine-readable interface files.
2. Choreography
Orchestration is the automated configuration, management, and coordination of computer systems, applications, and services. Orchestration may help IT departments manage complex tasks and workflows more easily. The automation and layout concepts are different, but they are closely related. Typically, automation refers to the automatic execution of a single task. The layout is different, which refers to a flow or workflow that automatically executes multiple steps in different systems. The automation can be built into the process, and then the process can be arranged to realize automatic operation.
3、TaaS
TaaS is an abbreviation of Test as a Service, explained as Test as a Service. The testing behavior is extracted from a simple software engineering flow process, testing service is provided in a more systematic and platform mode, and testing capability is provided for the business of the software engineering in a more universal mode.
In the related testing process, testers of different service lines and different projects need to maintain a large number of test cases. In particular, the tester is faced with several problems in particular: the compiling modes of testing cases, testing statements and testing behavior descriptions by personnel of different projects and different service lines are different, the maintenance cost is high, the universality is low, the readability is poor, and the effective cross-project and different roles test evaluation is difficult to implement; the design, organization and management of manual test and automatic test are very split and completely depend on projects or testers, the automatic test cases can not be well in one-to-one correspondence with the thought brain map cases listed by points, and the actual execution conditions and details of the cases are difficult to evaluate; information such as organization of a test scheme, a test case, a test flow and the like is used as relatively special data, and on the level of a data layer, a good management and storage mode is not provided, so that the test engineering is difficult to be promoted to the level of TaaS.
In the related art, httplunner and Ginkgo are two relatively mature test frameworks. The HTTP (hypertext Transfer Protocol) Protocol-oriented universal test framework realizes various test requirements such as automatic test, performance test, online monitoring and continuous integration by compiling and maintaining a YAML/JSON script. The httpurn framework has the following limitations: only aiming at HTTP API test, the applicable test scene is relatively limited; the test framework is strongly bound with Python language and Pytest language, still belongs to a test framework of a certain language in definition, and is not a universal semantic specification irrelevant to form; the process flow of some complex test scenarios is difficult to connect in series.
Ginkgo is a mature BDD (Behavior-Driven Development) style Go testing framework. Ginkgo builds on Go's testingbasis and is supplemented by the Gomega matcher repository. It can be regarded as an encapsulation for Go language native testing packets, adding support for some specific test grammars. However, in practice, ginkgo has some problems: the grammatical description of the use case is complex, the Go language is fully mastered, and the understanding cost is high; the positioning belongs to a test library, and the method is more suitable for describing and executing some unit tests and integration tests; the data layer and the execution layer described by the test are coupled, and the maintenance is difficult.
In summary, the test framework in the related art has more practical problem scenarios, which are specific implementations of a tool library or framework in a certain language, and has more obvious defects.
Based on this, the software testing method, the device and the electronic device provided by the embodiment of the invention can be generally used in software testing processes of various projects and various service lines, are not limited to a certain specific language, and have high universality.
Referring to fig. 1, a flow chart of a software testing method is shown, which comprises the following steps:
s12, acquiring a software test document of the target software; the software test document at least comprises a case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence;
the present embodiment is directed to providing a software testing approach that is not limited to a particular computer language. Therefore, the software test document needs to have high readability and also needs to have the capability of being understood and processed by a computer program, so that the software test document is converted into a language form corresponding to target software in the test process. Based on the method, the structure of the software test document is realized in a node form; the case nodes in the software test document comprise a plurality of test cases, and the test cases are executed in the target software and can test whether the software function of the target software is normal or not. Each test case is generally composed of one or more test steps; the step nodes in the software test document comprise a plurality of test steps related to each test case in the current software test document. In practical implementation, the step identifiers and the specific step contents of each test step can be described in the step nodes, each test case includes the step identifiers of the test steps related to the test case in the case nodes, and the step identifiers are arranged according to a preset sequence. The preset sequence can be edited and adjusted by a tester according to the test requirements.
Other nodes, for example, a function node for describing a function involved in the testing step, a variable definition node for describing a variable involved in the testing step, and the like, may also be included in the software testing document.
Step S14, converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software;
the software test documentation in this embodiment is separate from the specific computer language, and the target software is typically implemented in the specific computer language. In order for the software test document to be executable and to implement the test of the target software, the software test document needs to be language-converted. The Software Development Kit may also be referred to as an SDK (Software Development Kit), and the Software Development Kit may identify each node in the Software test file, and then map the content of each node into a document in a language form corresponding to the target Software, so as to form a Software test file in a language recognizable by the target Software. And the preset test tool operates the file, and in the process of operating the file, the target software is called according to the requirements of the test case, so that the test of the target software is realized.
And step S16, collecting the execution data generated in the execution process of the software test document, and generating the test result of the target software based on the execution data.
The execution data may include output data of the target software when the test case is executed, an execution state of the test case, and operation data of the test tool; obtaining the test result of the target software by screening, counting and other processing of the executed data; the test result may include whether each function in the target software is normal.
The software testing method comprises the steps of obtaining a software testing document of target software; the software test document at least comprises a case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence; converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software; and collecting the execution data generated in the software test document during the execution process, and generating the test result of the target software based on the execution data. The software test document in the method is separated from a specific computer language, the content of the test case is described through the case node and the step node, the software test document is converted into a language form corresponding to target software through a software development kit in the test process, and the test of the target software is completed. The software test document in the embodiment can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.
The following embodiments continue to describe the manner in which software test documents are obtained.
The embodiment provides two ways for generating the software test document, the software test document can be stored in the database after being generated, and the software test document can be obtained from the database during test execution.
In a mode of generating a software test document, receiving document editing contents through a preset document editor, and generating the software test document through the document editing contents; the document editor can provide an editing window at a client, a tester can edit a software test document through the editing window and send editing contents to the document editor, and the editing contents can be specifically input test steps, test cases obtained by sequencing partial test steps and the like. In actual implementation, a document template of a software test document may be provided, and node contents of each node in the document template are empty, so that testers add description contents in the nodes, for example, a test step is edited in a step node, a step identifier included in a case is edited in a case node, and the like.
In addition, the document editor also provides a compliance verification function, and during the editing process of a tester or after the editing is completed, the format and the content of the current software test document are verified based on a preset verification rule, so that the software test document generated by editing is ensured to be in accordance with the preset document specification. After the software test document is edited, the software test document can be transmitted and stored in a YAML format or a JSON format.
In another mode of generating the software test document, format conversion is carried out on original test data through a preset format converter to obtain the software test document; wherein the raw test data includes one or more of: the method comprises the steps of specifying a test case of an interface test tool, specifying an interface file under a specification, a test case in a tabular form and specifying an operation record file of a program. The raw test data may be derived from specific software operating data, operating data of a test tool, etc., the raw test data typically having a particular computer language; the format converter may convert the raw test data into the node format of the software test document, thereby deviating from a specific computer language. The test case of the specified interface test tool may be, for example, collection data of a Postman interface test tool, where the data is structured JSON data; the interface file under the specified specification may be, for example, a standard service OAS document; the test case in the form of the table can be, for example, table case data which is written by an Excel table and meets a certain specification; the operation record file of the designated program may be, for example, an HAR record file generated after the browser executes a request. The format converter can firstly identify the language of the original test data, extract related contents from the original test data based on the data format under the language, and fill the related contents into corresponding nodes of the software test document.
For the software test document, only the preset document editor is used for receiving document editing contents, the software test document is generated through the document editing contents, and format conversion is performed on original test data through a preset format converter to obtain the software test document; in addition, if a proper software test document cannot be obtained only by one mode, the two modes can be combined; for example, format conversion is performed on original test data to obtain an initial software test document, and then a tester edits the initial software test document to obtain a final software test document.
In the above manner, a tester can edit the software test document and also can obtain the software test document through conversion of the original test data, so that on one hand, the use case quantity of the software test document can be enriched, and on the other hand, the use case can be flexibly edited, so that the test case meets the specific test requirements.
The following provides a specific generation mode of the software test document. Generating a first step in the step nodes based on original test data in a first test scene; the first test scene is preset with a first protocol; the first step comprises at least one testing step; generating a second step in the step nodes based on the original test data in the second test scene; the second test scene is preset with a second protocol; the second protocol is different from the first protocol; the second step comprises at least one testing step; arranging the first step and the second step according to a preset arrangement sequence to obtain a test case; and generating a software test document based on the test case, the first step and the second step.
In this embodiment, the test steps in different test scenarios may be connected in series to obtain a test case in multiple scenarios. For example, the first test scenario is HTTP interface test, the first protocol is HTTP protocol, the second test scenario is JAVA transmission test, and the second protocol is JAVA-related transmission protocol; through the format converter, original test data in the first test scene can be converted into one or more test steps in a software test document, namely the first step; similarly, the format converter can convert the original test data in the second test scenario into one or more test steps in the software test document, namely the second step; and performing splitting, sequencing and other editing operations on the testing steps in the first step and the second step to obtain the test cases of a plurality of scenes in series.
In addition, the first protocol and the second protocol may also be custom protocols, and the original test data under each protocol may be converted into the test steps in the software test document, regardless of the specific protocol or computer language. Based on the test cases obtained by the test steps, the multi-scenario serial test can be realized, and further, the mutual serial connection of test flows in a complex test scenario can be realized.
In the software testing document, besides the case nodes and the step nodes, the software testing document also comprises version number nodes, information nodes, definition nodes and function nodes; the version number node comprises a standard version to which the software test document belongs; the information node comprises a test description, a test classification and a test object corresponding to the software test document; defining nodes including global variables, configuration information and tested services used by software test documents in a test process; the function nodes comprise step functions and check functions used by the software test documents in the test process.
The software test document in this embodiment is implemented based on a certain semantic specification, and under the semantic specification, the software test document is organized according to a certain format and presented by a Markdown document spec.md with explicit version planning and iteration, and the document includes an example data file in a standard YAML format. The semantic Specification takes TCS (Test Case Specification, common semantic definition of Test Case) as its abbreviation, and provides a standard semantic Specification which can be converted among different forms and is used for describing Test cases. The method can be used as an intermediate protocol for sample conversion in different levels of testing, and has the capability of being understood by people and computer programs at the same time. The version of the semantic specification is continuously updated, so that the software test document needs to describe on which version of the semantic specification the current document is generated, and in the version number node of the software test document, the version of the language specification used by the current document is described.
In practical implementation, the version of the semantic specification can be described by using a version number of major. Therefore, a tool that supports version 0.1 should be compatible with all versions 0.1.
In the above information node, the relevant information for describing the test content corresponding to the current document is used, where the test description may include a test case title, content of a test case, a usage, and a description of input/output data; the test classification may include a hierarchy, classification, etc. of the current test, for example, the hierarchy of the current test may be, for example, an application layer test, a transport layer test, a network layer test, etc.; the classification of the current test may be, for example, an interface test, a transmission test, an interaction test, and the like.
FIG. 2 shows a schematic of the structure of a software test document. Each software test document comprises a root node, and the root node comprises the version number node, the information node, the definition node, the function node, the step node and the case node; the description of each node can be referred to the previous embodiment. Each node may also be represented by a field format, and the description content corresponding to each node is described in each field. For example, the version number node is a tcs field, the information node is an info field, the definition node is a definitions field, the function node is a functions field, the step node is a steps field, and the case node is a cases field.
In the semantic specification, the description mode and the specification and the description of the content of each node in the software test document are described; the case nodes and the step nodes in the software test document are used as core nodes, the description of the test cases and the test steps is specified in the semantic specification, and the attributes and the organization modes of the test cases and the test steps are defined, so that the test cases and the test steps have sufficient expandability. Through the semantic specification, testers can unify the description of the test work on the data level, and the operation of management, butt-joint of writing, maintenance, execution and the like of upper and lower levels is facilitated.
In the above manner, the tester can read, edit, store, manage, execute, etc. the test case in a simplified and unified format. Converter tools developed based on TCS can be used to convert TCS documents (i.e., files in YAML format or JSON format) into a more readable and editable form, or to convert test cases in other languages into standard TCS documents. After the TCS document states that the test code loading tool and the test execution device can perform operations of loading and test execution on the TCS document after the TCS document is automatically executed.
The following embodiments continue to describe implementations for language conversion of software test documents. Analyzing a software test document, and establishing a test object in a language corresponding to target software; mapping the use case nodes in the software test document and the node data in the step nodes to a test object; and determining the mapped test object as the converted software test document.
The language of the test object is generally the same as that of the target software, and the test object is understood to be an object that can communicate with and call the target software. In actual implementation, a blank test object may be established based on a language corresponding to target software, then, for each part in the test object, data corresponding to each part is extracted from the use case node and the node data in the step node of the software test document, and is converted into a language corresponding to the target software, and then, a corresponding position part in the test object is filled in, and finally, the converted test object is obtained.
When the target software has more functions to be tested, the software test documents include a plurality of software test documents, and in this case, the plurality of software test documents need to be scheduled to ensure that the test process is executed in order. Specifically, scheduling configuration information corresponding to a software test document is obtained; the scheduling configuration information comprises the execution sequence of a plurality of software test documents and the execution mode of the software test documents; the configuration information is obtained by editing a preset scheduling configuration editor; a plurality of software test documents are executed based on the scheduling configuration information.
In actual implementation, a task scheduling module can be set, a scheduling configuration editor is provided at a client through the task scheduling module, and a tester can edit and submit scheduling configuration information corresponding to a software test document through an editing window of the scheduling configuration editor. The scheduling configuration information is configured with an execution sequence of a plurality of software test documents, and a tester can sequence the plurality of software test documents and determine the execution sequence based on a sequencing result. The scheduling configuration information also includes an execution mode of the software test document, where the execution mode includes time for starting execution, a period of a timing task, a specific environment used for execution (for example, different runners, a network environment, and the like are selected), an execution number, and the like. When the software test document is updated, the corresponding scheduling configuration is also subjected to iterative optimization correspondingly.
Further, the test result of the target software is generated by the following method: based on the software test document, calling the target software and the service program which the target software depends on through a preset test tool, and collecting the execution data output by the target software and the service program; the execution data comprises one or more of monitoring index data, log data and link observation data; and summarizing the execution data and the output data of the test tool to obtain the test result of the target software.
The test tool may be a test executor or a test environment, such as Runner; the execution data may be further divided into a test record, a process operation log, a test result, and the like. The collection process of the execution data can be realized by a data collector, and the data collector collects the execution data according to a certain rule to obtain the test result, and the test result can be realized in the form of a test report. The test report can be stored in a database, and a tester can read the test report from the database through a client and display the test report through the client.
Similarly, the aforementioned software test documents can also be stored in a data structure in YAML or JSON language in a database, which can be implemented using a MongoDB database. And a tester can read and write the software test document and the test report stored in the database through the client.
FIG. 3 illustrates a software testing method of the present embodiment implemented interactively in multiple layers, an interaction layer, a data layer and an execution layer; it should be noted that, if the client-server architecture is used in the testing process, the interaction layer, the data layer, and the execution layer may be located in the terminal device, the database device, and the server, respectively; in addition, the user may also use only the local device to complete the software testing method of this embodiment, and at this time, the interaction layer, the data layer, and the execution layer are all located in the local device.
In the embodiment, around a software test document, also referred to as a TCS document, writing, scheduling, and execution of a test are divided into different levels, i.e., an interaction layer, a data layer, and an execution layer, and the unification of test cases in the data layer is realized, and data of the test cases is logically separated from execution code. The specific flow is illustrated as follows:
s101: the tester can directly, quickly and conveniently edit the TCS document through the TCS editor (i.e., the document editor in the foregoing embodiment), and the editor provides a compliance verification function to ensure that the TCS document generated by editing meets the specification. TCS documents are the core data in the data layer that describes the test, and are typically delivered and stored in YAML/JSON format.
S102: the original data sources for various tests may be input into the TCS-adapted converter (i.e., the format converter in the previous embodiment), including but not limited to: collection data of a Postman interface test tool, standard service OAS documents, TCS specification form case data compiled by an Excel table, HAR recording files generated after a browser executes a request and the like.
S103: the converter converts the various test data into a standard TCS document.
S104: the TCS document, through the SDK, can be read and loaded by a TCS-enabled test framework or tool, actually executing a test procedure in a test executor or test environment, such as Runner.
S105: the data generated by the tests performed at the test executor or test environment, including test records, process execution logs, test results, etc., are collected by the data collection device.
S106: the data collector collects the collected test execution related data and generates a test report according to a certain rule.
S107: the test reports are stored in a repository of reports at the data layer.
S108: the front-end interaction of the test management can read the test report from the report storage library for displaying.
S109: each TCS document is a conveniently storable data structure, such as that in YAML or JSON languages, that can be stored using a database such as MongoDB.
S110: the front end interaction of the test management can read and write the case database, check, organize and manage the test cases.
S111: the task scheduling module can read and write scheduling configuration and is used for scheduling the execution mode of the test tasks described by the TCS documents.
S112: the data layer scheduling configuration drives and manages the specific execution of the execution layer Runner.
In the above manner, the editor of the TCS and the translator support of various test scenario inputs are provided for supporting various test contents in an actual service scenario. The editor provides simple and visual TCS document editing capability, can carry out standard verification on the edited content, and timely checks and reminds the content which does not conform to the TCS standard; the converter is a functional component which is developed on a test framework for adapting the TCS in an extending way and is used for providing the capability of quickly converting data sources of various tests or generating TCS documents. The converter may support conversion by OAS documents, postman Collection data, browser HAR log data, excel edited tabular data, etc., or generate TCS documents editable by an editor executable by the test framework.
FIG. 4 is a diagram showing the architecture of a test management scheme according to the software testing method of the present embodiment; the architecture diagram is explained as follows:
s301: the front-end Client (i.e., the Client in the foregoing embodiment) is composed of modules such as a TCS editor, team test set management, task management and scheduling, observation and report execution, and interacts with the back-end Server (i.e., the Server in the foregoing embodiment) to provide functions such as test cases, test task scheduling, test report display, and the like written by the user.
S302: the back-end Server reads and writes a database storing test cases, wherein the case data which accords with the TCS format, namely the software test document, is stored in the database.
S303: the back-end Server reads and writes a database for storing task configuration, and scheduling and arranging data of the test tasks, namely the scheduling and configuring information, is stored in the database.
S304: the back-end Server reads and writes a database storing test reports, and the database stores the reports generated by the test, software As A Service (SAAS) data associated with the test, and the like.
S305: after receiving the test task, the back-end Server reads the TCS document in the database according to the scheduling configuration information, issues the TCS document to the Runner of the actually controlled test cluster to execute the test, and collects the test generation data and the report.
S306: during test execution, the tested object and the dependent SAAS service are called, and then data is generated. This portion of data includes, but is not limited to: monitoring index data, log data, link observation data, etc. of processes, services, machines, etc. which are monitored or SAAS collected.
S307: and the back-end Server pulls data generated in the test process from the tested object and the SAAS service according to the task configuration, summarizes the data with the data of the test Runner, and generates test report data.
The software testing method of the embodiment provides a more extensive and form-independent solution for testing description and layout, and a series of tool chains are generated around the specification in a matching way, so that the software testing method can better support multiple languages, multiple testing scenes and the like.
Corresponding to the above method embodiment, referring to fig. 5, a schematic structural diagram of a software testing apparatus is shown, the apparatus includes:
a document acquisition module 50, configured to acquire a software test document of target software; the software test document at least comprises a case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence;
the document execution module 52 is configured to convert the software test document into a language form corresponding to the target software through a software development kit of the target software, and execute the converted software test document in a test environment of the target software;
and the result generating module 54 is used for collecting the execution data generated in the software test document during the execution process and generating the test result of the target software based on the execution data.
The software testing device acquires a software testing document of target software; the software test document at least comprises a case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence; converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software; and collecting the execution data generated in the software test document during the execution process, and generating the test result of the target software based on the execution data. The software test document in the method is separated from a specific computer language, the content of the test case is described through the case node and the step node, the software test document is converted into a language form corresponding to target software through a software development kit in the test process, and the test of the target software is completed. The software test document in the embodiment can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.
The document acquiring module is further configured to: receiving document editing contents through a preset document editor, and generating a software test document through the document editing contents; and/or carrying out format conversion on the original test data through a preset format converter to obtain a software test document; wherein the raw test data comprises one or more of: the method comprises the steps of specifying a test case of an interface test tool, an interface file under specified specifications, a test case in a table form and an operation record file of a specified program.
The document acquiring module is further configured to: generating a first step in the step nodes based on original test data in a first test scene; the first test scene is preset with a first protocol; the first step comprises at least one testing step; generating a second step in the step nodes based on the original test data in the second test scene; the second test scene is preset with a second protocol; the second protocol is different from the first protocol; the second step comprises at least one testing step; and arranging the first step and the second step according to a preset arrangement sequence to obtain the test case.
The software test document further comprises: the method comprises the following steps of version number nodes, information nodes, definition nodes and function nodes; the version number node comprises a standard version to which the software test document belongs; the information node comprises a test description, a test classification and a test object corresponding to the software test document; defining nodes including global variables, configuration information and tested services used by software test documents in a test process; the function nodes comprise step functions and check functions used by the software test documents in the test process.
The document execution module is further configured to: analyzing a software test document, and establishing a test object in a language corresponding to target software; mapping the use case nodes in the software test document and the node data in the step nodes to a test object; and determining the mapped test object as the converted software test document.
The software test documents comprise a plurality of documents; the document execution module is further configured to: acquiring scheduling configuration information corresponding to a software test document; the scheduling configuration information comprises the execution sequence of a plurality of software test documents and the execution mode of the software test documents; the scheduling configuration information is obtained by editing a preset scheduling configuration editor; a plurality of software test documents are executed based on the scheduling configuration information.
The result generation module is further configured to: based on the software test document, calling the target software and the service program which the target software depends on through a preset test tool, and collecting the execution data output by the target software and the service program; the execution data comprises one or more of monitoring index data, log data and link observation data; and summarizing the execution data and the output data of the test tool to obtain the test result of the target software.
The embodiment also provides an electronic device, which comprises a processor and a memory, wherein the memory stores machine executable instructions capable of being executed by the processor, and the processor executes the machine executable instructions to realize the software testing method. The electronic device can be a server or a touch terminal device.
Referring to fig. 6, the electronic device includes a processor 100 and a memory 101, where the memory 101 stores machine executable instructions capable of being executed by the processor 100, and the processor 100 executes the machine executable instructions to implement the software testing method, for example:
acquiring a software test document of target software; the software test document at least comprises a use case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence; converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software; and collecting the execution data generated in the software test document during the execution process, and generating the test result of the target software based on the execution data.
The software test document in the method is separated from a specific computer language, the content of the test case is described through the case node and the step node, the software test document is converted into a language form corresponding to target software through a software development kit in the test process, and the test of the target software is completed. The software test document in the embodiment can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.
Receiving document editing contents through a preset document editor, and generating a software test document through the document editing contents; and/or carrying out format conversion on the original test data through a preset format converter to obtain a software test document; wherein the raw test data comprises one or more of: the method comprises the steps of specifying a test case of an interface test tool, specifying an interface file under a specification, a test case in a tabular form and specifying an operation record file of a program.
The two test document acquisition modes are provided, so that testers can edit the software test documents and can also obtain the software test documents through conversion of the original test data, on one hand, the use cases of the software test documents can be enriched, on the other hand, the use cases can be flexibly edited, and the use cases meet specific test requirements.
Generating a first step in the step nodes based on original test data in a first test scene; the first test scene is preset with a first protocol; the first step comprises at least one testing step; generating a second step in the step nodes based on the original test data in the second test scene; wherein, the second test scene is preset with a second protocol; the second protocol is different from the first protocol; the second step comprises at least one testing step; arranging the first step and the second step according to a preset arrangement sequence to obtain a test case; and generating a software test document based on the test case, the first step and the second step.
In the above manner, the original test data under each different protocol can be converted into the test steps in the software test document, regardless of the specific protocol or computer language. Based on the test cases obtained by the test steps, the multi-scenario serial test can be realized, and further, the mutual serial connection of test flows in a complex test scenario can be realized.
The software test document further comprises: the method comprises the following steps of version number nodes, information nodes, definition nodes and function nodes; the version number node comprises a standard version to which the software test document belongs; the information node comprises a test description, a test classification and a test object corresponding to the software test document; defining nodes including global variables, configuration information and tested services used by software test documents in the test process; the function nodes comprise step functions and check functions used by the software test documents in the test process.
Analyzing a software test document, and establishing a test object in a language corresponding to target software; mapping the use case nodes in the software test document and the node data in the step nodes to a test object; and determining the mapped test object as the converted software test document.
The software test document comprises a plurality of documents; acquiring scheduling configuration information corresponding to a software test document; the scheduling configuration information comprises the execution sequence of a plurality of software test documents and the execution mode of the software test documents; the scheduling configuration information is obtained by editing a preset scheduling configuration editor; a plurality of software test documents are executed based on the scheduling configuration information.
Based on the software test document, calling the target software and the service program which the target software depends on through a preset test tool, and collecting the execution data output by the target software and the service program; the execution data comprises one or more of monitoring index data, log data and link observation data; and summarizing the execution data and the output data of the test tool to obtain the test result of the target software.
The software test document in the mode is separated from a specific computer language, the content of the test case is described through the case node and the step node, the software test document is converted into a language form corresponding to the target software through the software development kit in the test process, and the test of the target software is completed. The software test document in the embodiment can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.
Further, the electronic device shown in fig. 6 further includes a bus 102 and a communication interface 103, and the processor 100, the communication interface 103, and the memory 101 are connected through the bus 102.
The Memory 101 may include a high-speed Random Access Memory (RAM) and may also include a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. The communication connection between the network element of the system and at least one other network element is realized through at least one communication interface 103 (which may be wired or wireless), and the internet, a wide area network, a local network, a metropolitan area network, and the like can be used. The bus 102 may be an ISA bus, a PCI bus, an EISA bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 6, but that does not indicate only one bus or one type of bus.
Processor 100 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 100. The Processor 100 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the device can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, a discrete Gate or transistor logic device, or a discrete hardware component. The various methods, steps, and logic blocks disclosed in the embodiments of the present invention may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present invention may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in ram, flash, rom, prom, or eprom, registers, etc. as is well known in the art. The storage medium is located in the memory 101, and the processor 100 reads the information in the memory 101 and completes the steps of the method of the foregoing embodiment in combination with the hardware thereof.
The present embodiments also provide a machine-readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the software testing method described above, for example:
acquiring a software test document of target software; the software test document at least comprises a case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence; converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software; and collecting the execution data generated in the software test document during the execution process, and generating the test result of the target software based on the execution data.
In the method, a software test document is separated from a specific computer language, the content of a test case is described through a case node and a step node, the software test document is converted into a language form corresponding to target software through a software development kit in the test process, and the test of the target software is completed. The software test document in the embodiment can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.
Receiving document editing contents through a preset document editor, and generating a software test document through the document editing contents; and/or carrying out format conversion on the original test data through a preset format converter to obtain a software test document; wherein the raw test data comprises one or more of: the method comprises the steps of specifying a test case of an interface test tool, an interface file under specified specifications, a test case in a table form and an operation record file of a specified program.
The two test document acquisition modes are provided, so that testers can edit the software test documents and can also obtain the software test documents through conversion of the original test data, on one hand, the use cases of the software test documents can be enriched, on the other hand, the use cases can be flexibly edited, and the use cases meet specific test requirements.
Generating a first step in step nodes based on original test data in a first test scene; the first test scene is preset with a first protocol; the first step comprises at least one testing step; generating a second step in the step nodes based on the original test data in the second test scene; the second test scene is preset with a second protocol; the second protocol is different from the first protocol; the second step comprises at least one testing step; arranging the first step and the second step according to a preset arrangement sequence to obtain a test case; and generating a software test document based on the test case, the first step and the second step.
In the above manner, the original test data under each different protocol can be converted into the test steps in the software test document, regardless of the specific protocol or computer language. Based on the test cases obtained by the test steps, the multi-scenario serial test can be realized, and further, the mutual serial connection of test flows in a complex test scenario can be realized.
The software test document further comprises: the method comprises the following steps of version number nodes, information nodes, definition nodes and function nodes; the version number node comprises a standard version to which the software test document belongs; the information node comprises a test description, a test classification and a test object corresponding to the software test document; defining nodes including global variables, configuration information and tested services used by software test documents in the test process; the function nodes comprise step functions and check functions used by the software test documents in the test process.
Analyzing a software test document, and establishing a test object in a language corresponding to target software; mapping the use case nodes in the software test document and the node data in the step nodes to a test object; and determining the mapped test object as the converted software test document.
The software test document comprises a plurality of documents; acquiring scheduling configuration information corresponding to a software test document; the scheduling configuration information comprises the execution sequence of a plurality of software test documents and the execution mode of the software test documents; the scheduling configuration information is obtained by editing a preset scheduling configuration editor; a plurality of software test documents are executed based on the scheduling configuration information.
Calling target software and a service program which the target software depends on through a preset test tool based on the software test document, and collecting execution data output by the target software and the service program; the execution data comprises one or more of monitoring index data, log data and link observation data; and summarizing the execution data and the output data of the test tool to obtain the test result of the target software.
The software test document in the mode is separated from a specific computer language, the content of the test case is described through the case node and the step node, the software test document is converted into a language form corresponding to the target software through the software development kit in the test process, and the test of the target software is completed. The software test document in the embodiment can be applied to test scenes in various computer languages, the universality is high, testers do not need to maintain a large number of test files for various languages and various test scenes, and the maintenance cost of the test files is reduced.
The software testing method, the software testing device and the computer program product of the electronic device provided by the embodiment of the invention comprise a computer readable storage medium storing program codes, wherein instructions included in the program codes can be used for executing the method described in the previous method embodiment, and specific implementation can refer to the method embodiment, and is not described herein again.
It can be clearly understood by those skilled in the art that, for convenience and simplicity of description, the specific working process of the system and the apparatus described above may refer to the corresponding process in the foregoing method embodiment, and details are not described herein again.
In addition, in the description of the embodiments of the present invention, unless otherwise explicitly specified or limited, the terms "mounted," "connected," and "connected" are to be construed broadly, e.g., as meaning either a fixed connection, a removable connection, or an integral connection; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meaning of the above terms in the present invention can be understood in specific cases for those skilled in the art.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention or a part thereof which substantially contributes to the prior art may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk, and various media capable of storing program codes.
In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicate orientations or positional relationships based on the orientations or positional relationships shown in the drawings, and are only for convenience of description and simplicity of description, but do not indicate or imply that the device or element being referred to must have a particular orientation, be constructed and operated in a particular orientation, and thus, should not be construed as limiting the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.
Finally, it should be noted that: although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: any person skilled in the art can modify or easily conceive the technical solutions described in the foregoing embodiments or equivalent substitutes for some technical features within the technical scope of the present disclosure; such modifications, changes or substitutions do not depart from the spirit and scope of the embodiments of the present invention, and they should be construed as being included therein. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims (10)

1. A method for testing software, the method comprising:
acquiring a software test document of target software; the software test document at least comprises a use case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence;
converting the software test document into a language form corresponding to the target software through a software development kit of the target software, and executing the converted software test document in a test environment of the target software;
and collecting the execution data generated in the execution process of the software test document, and generating the test result of the target software based on the execution data.
2. The method of claim 1, wherein the step of obtaining a software test document for the target software comprises:
receiving document editing contents through a preset document editor, and generating the software test document through the document editing contents;
and/or, carrying out format conversion on the original test data through a preset format converter to obtain the software test document; wherein the raw test data comprises one or more of: the method comprises the steps of specifying a test case of an interface test tool, specifying an interface file under a specification, a test case in a tabular form and specifying an operation record file of a program.
3. The method of claim 1, wherein the step of obtaining a software test document for the target software comprises:
generating a first step in the step nodes based on original test data in a first test scenario; the first test scene is preset with a first protocol; the first step comprises at least one testing step;
generating a second step in the step nodes based on original test data in a second test scenario; a second protocol is preset in the second test scene; the second protocol is different from the first protocol; the second step comprises at least one testing step;
arranging the first step and the second step according to the preset arrangement sequence to obtain the test case; and generating a software test document based on the test case, the first step and the second step.
4. The method of claim 1, wherein the software test document further comprises: the method comprises the following steps of version number nodes, information nodes, definition nodes and function nodes;
the version number node comprises a specification version to which the software test document belongs; the information node comprises a test description, a test classification and a test object corresponding to the software test document;
the definition node comprises global variables, configuration information and tested services used by the software test document in the test process; the function nodes comprise step functions and check functions used by the software test documents in the test process.
5. The method according to claim 1, wherein the step of converting the software test document into the language form corresponding to the target software through the software development kit of the target software comprises:
analyzing the software test document, and establishing a test object in a language corresponding to the target software;
mapping the node data in the case nodes and the step nodes in the software test document to the test object;
and determining the mapped test object as the converted software test document.
6. The method of claim 1, wherein the software test document comprises a plurality; the step of executing the converted software test document in the test environment of the target software comprises:
acquiring scheduling configuration information corresponding to the software test document; the scheduling configuration information comprises the execution sequence of a plurality of software test documents and the execution mode of the software test documents; the scheduling configuration information is obtained by editing a preset scheduling configuration editor;
and executing a plurality of software test documents based on the scheduling configuration information.
7. The method of claim 1, wherein the step of collecting the execution data generated by the software test document during the execution process and generating the test result of the target software based on the execution data comprises:
based on the software test document, calling the target software and the service program depended by the target software through a preset test tool, and collecting the execution data output by the target software and the service program; the execution data comprises one or more of monitoring index data, log data and link observation data;
and summarizing the execution data and the output data of the test tool to obtain the test result of the target software.
8. A software testing apparatus, the apparatus comprising:
the document acquisition module is used for acquiring a software test document of the target software; the software test document at least comprises a use case node and a step node; the case node comprises a plurality of test cases, and the step node comprises a plurality of test steps; the test case comprises at least part of the test steps in the step nodes; the test steps included in the test case are arranged according to a preset sequence;
the document execution module is used for converting the software test document into a language form corresponding to the target software through a software development kit of the target software and executing the converted software test document in a test environment of the target software;
and the result generating module is used for collecting the execution data generated in the execution process of the software test document and generating the test result of the target software based on the execution data.
9. An electronic device comprising a processor and a memory, the memory storing machine executable instructions executable by the processor, the processor executing the machine executable instructions to implement the software testing method of any one of claims 1-7.
10. A machine-readable storage medium having stored thereon machine-executable instructions which, when invoked and executed by a processor, cause the processor to implement the software testing method of any of claims 1-7.
CN202210587665.1A 2022-05-26 2022-05-26 Software testing method and device and electronic equipment Pending CN115185809A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210587665.1A CN115185809A (en) 2022-05-26 2022-05-26 Software testing method and device and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210587665.1A CN115185809A (en) 2022-05-26 2022-05-26 Software testing method and device and electronic equipment

Publications (1)

Publication Number Publication Date
CN115185809A true CN115185809A (en) 2022-10-14

Family

ID=83512630

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210587665.1A Pending CN115185809A (en) 2022-05-26 2022-05-26 Software testing method and device and electronic equipment

Country Status (1)

Country Link
CN (1) CN115185809A (en)

Similar Documents

Publication Publication Date Title
CN110764753B (en) Business logic code generation method, device, equipment and storage medium
US7596546B2 (en) Method and apparatus for organizing, visualizing and using measured or modeled system statistics
CN110232024B (en) Software automation test framework and test method
CN112327808A (en) Automobile fault diagnosis method and system and automobile fault diagnosis instrument
CN112394942B (en) Distributed software development compiling method and software development platform based on cloud computing
US11385898B2 (en) Task orchestration method for data processing, orchestrator, device and readable storage medium
CN111400186A (en) Performance test method and system
CN111158656B (en) Test code generation method and device based on fruit tree method
CN110837496A (en) Data quality management method and system based on dynamic sql
CN111694561A (en) Interface management method, device, equipment and storage medium
CN114328278B (en) Distributed simulation test method, system, readable storage medium and computer equipment
CN112464620A (en) Implementation method and implementation system of financial rule engine
CN115964272A (en) Transaction data automatic testing method, device, equipment and readable storage medium
CN113821554B (en) Method for realizing heterogeneous database data acquisition
CN113360353B (en) Test server and cloud platform
CN111143228B (en) Test code generation method and device based on decision table method
CN115185809A (en) Software testing method and device and electronic equipment
CN111984882A (en) Data processing method, system and equipment
CN114297074A (en) Method for realizing automatic testing of functions, interfaces and performances based on dynamic configuration
CN113342641A (en) Automatic test method and system for HTTP service interface
CN112699022A (en) Real-time efficient automatic contract testing method and system
US11726792B1 (en) Methods and apparatus for automatically transforming software process recordings into dynamic automation scripts
US20230266965A1 (en) Software development environment
CN113050925B (en) Block chain intelligent contract repairing method and device
CN115934684B (en) Multi-source database data migration method and device, 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