CN111459793A - Full-life-cycle software automatic testing method and device - Google Patents
Full-life-cycle software automatic testing method and device Download PDFInfo
- Publication number
- CN111459793A CN111459793A CN202010115705.3A CN202010115705A CN111459793A CN 111459793 A CN111459793 A CN 111459793A CN 202010115705 A CN202010115705 A CN 202010115705A CN 111459793 A CN111459793 A CN 111459793A
- Authority
- CN
- China
- Prior art keywords
- test
- resource
- database
- interface
- domain
- 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.)
- Granted
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/3684—Test management for test design, e.g. generating new test cases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
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 discloses a full-life-cycle software automatic testing method and a full-life-cycle software automatic testing device, wherein the method comprises the following steps: splitting the atomic resource function of the software automation platform; setting an independent test script extension domain inside the software automation platform; setting an independent user scene test case expansion domain in the software automation platform; software automates the full lifecycle management of project activities. The scheme has flexible expansion and splitting capability on the use cases, scripts and resources of the automation platform; meanwhile, complete automation activities can be output externally, and can be conveniently grafted to an external service system, and the automation platform can split the bottom atomic resource function; the automatic project activities are flexible to expand, real-time monitoring of project activities and resource consumption conditions is achieved, and a full life cycle management process is generated by reporting after the project activities are established, operated and finished.
Description
Technical Field
The invention belongs to the technical field of software automatic testing systems, and particularly relates to a full-life-cycle software automatic testing method and device.
Background
At present, the construction of the existing software automation platform generally adopts an automation mode of single project activity construction one by one for configuration, in order to avoid mutual influence between test cases, the flexibility is higher, each test resource and test script are independently constructed, only when the test case resource processing of the final project activity is required, the independent test script is called, the independent test resource processing service is called through the test script, and the construction mode has the advantages that when a new project activity requirement exists, the new project activity needs to be re-developed based on the service requirement for full-scale automation test case coding, and the embedded monitoring codes are redefined according to the monitoring requirement of the project activity to be in butt joint with the monitoring platform for activity operation monitoring, the mutual exclusion or symbiotic relation between the activity and the activity can not be flexibly configured, and additional coding control is required.
The main disadvantages of the independent development and test automation script mode of single project activity mentioned in the above technology are poor flexibility of the automation platform and large resource consumption: automatic testers of each project activity need to output test cases again to release the online, and the requirement of improving the fast-paced research and development efficiency cannot be met; mutual exclusion or symbiotic relation among project activities cannot be flexibly configured, external project test cases cannot be quickly accessed to process the test case relation of internal and external projects, independent repeated test script coding development needs to be carried out according to each project activity requirement, time consumption is long, and unstable automatic test codes are easy to cause resource loss; when the project activity test effect monitoring is needed, because the independently developed project activity schemes are usually inconsistent in standard format, unified monitoring modeling cannot be performed, and monitoring and development of a single project activity are difficult, only the operation result of the activity is concerned, and full-life-cycle monitoring from project activity creation to settlement is lacked.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a full-life-cycle software automatic testing method, which comprises the following steps:
step 1, setting a sub-resource functional domain (100);
step 2, setting a test script extension domain (200);
step 3, setting a user scene test case expansion domain (300);
and 4, aiming at the software to be tested, constructing a test project, adding resources, adding keywords, constructing a request, responding to assertion, post-processing data and generating a report (400).
The step 1 comprises the following steps: setting a sub-resource functional domain (100), wherein the sub-resource functional domain (100) is used for defining resources, splitting resources of a calling resource module, a called input/output rule and a resource keyword which are used in an automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103).
In the step 1, the ActionOperation interface request resource module (101) is used for creating a session, transmitting UR L and header parameters, assembling parameter-entering data, processing the parameter into dictionary type parameters, sending a post/get request according to the interface type, returning a parameter object, and converting the returned parameter object into a json string.
In step 1, the DBOperation operation resource module (102) is configured to: the database is linked through the keyword drive, and the related information of the database is input; and inquiring, modifying, newly adding and deleting the table data corresponding to the interface use case, and returning an operation result.
In step 1, the PublicOperation public operation resource module (103) is used for packaging public keywords related to database operation, wherein the public keywords related to database operation comprise keywords such as link Oracle database, database query, database execution command, database submission command, database disconnection command and the like, public keywords required by a package initialization interface use case such as package appointed date, backward offset date, forward offset date and current date return and the like, public keywords related to package processing interface use case return data such as dictionary conversion, conversion dictionary, dictionary conversion list, dictionary key value pair fetching and dictionary data assembling operations, and various system resources are defined and comprise UR L addresses and aliases, account information, database connection information and message header information of each system service of each product line.
The step 2 comprises the following steps: setting a test script extension domain (200), wherein the test script extension domain (200) is used for supporting the calling management of the relationship between the test script activities of each automation project, such as the relationship (201) that a single test script can call a single resource and the relationship (202) that multiple test scripts can call a single or multiple resources;
the test script extension domain (200) completes the call management of the relationship between the test script activities of the automation projects by executing the following steps:
step 2-1, an ActionOperation interface request resource module (101), a DBOperation operation resource module (102) and a publicOperation public operation resource module (103) are led in, libraries needed by the initialization interface generally comprise a library of the system, a third party library and a custom library commonly used by the system, such as 'Requests L library', 'Collections library' and 'String library'.
Step 2-2, designing corresponding entry and check fields by the test script; the corresponding test script returns json data of the interface by calling the request keyword of the tested interface;
examples are: for example, test the login interface script, check if $ { logenaddr.
Step 2-3, processing the json data, acquiring key data returned by the interface, calling database operation related to the interface, acquiring key data of the database, comparing an interface return value with a database return value through assertion, and if the assertion is consistent, passing the test; and if the data are inconsistent, returning that the test fails, and stopping running the test script.
The test script extension domain (200) has independent functions, has zero intrusion to the original system automation script, can flexibly configure and control the rules of each project script independently and independently, and stores and manages the inheritance relationship or the mutual exclusion relationship among the automation project scripts set in the extension domain in a special expression form by increasing the mapping of the relationship among the project scripts instead of simple rule superposition.
In step 3, the setting of the user scenario test case extension domain (300) includes the following steps:
step 3-1, configuring a test case template and associating a test script;
the general principle of test case template configuration is as follows:
1. the identifiers are named as required and the core points are verified using a clear key and a suitable level of abstraction.
2. Naming by using a file:
the name prepended ID should be as descriptive as possible and at the appropriate level of abstraction. Such as a 001 login interface, etc.;
3. testcase nomenclature
The 3.1 name should be as descriptive as possible and not overly long. E.g., correct username password entry verification, etc.;
3.2 the name is unified in Chinese, allowing only the underlined _ symbol to exist. For example: login interface _ correct username password input verification, etc.;
step 3-2, inputting test data and check data designed by the test cases, setting an execution range for inheritance relationship or mutual exclusion relationship among automatic project cases set in a user scene test case expansion domain (300) through case labels instead of simple rule superposition, for example, setting case tags as 'second-level' cases can execute all case-centralized second-level cases, and simultaneously supporting self-defined labels, for example, if the self-defined ratio labels are 'project main flow', the test cases of the main flow can be executed through all case-centralized execution.
In step 3, the user scenario test case extension domain (300) can call a single test script or more than two test scripts.
Step 4 comprises the following steps: the software test1 to be tested under the directory of the user scenario test case expansion domain (300) is executed in an automatic mode, a test script in the test script expansion domain (200) is called, the test script in the test script expansion domain (200) directly calls an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) in a defined sub-resource functional domain (100) to output different test reports according to the case class step type and the case class of a project, meanwhile, the automatic case resource execution condition, daily treatment analysis and resource warning are provided for each specific activity, and warning service is provided for the test cases which cannot pass the test.
The test cases are monitored by setting log monitoring, an overall situation summary is provided for project case execution, and the summarized content comprises single-interface request verification, script calling and different user scene test information developed by various automatic project activity types.
Under the directory of the user scene test case expansion domain (300), the directory can be continuously created or a test set note file can be directly created, and a test case or a user keyword is created under the test set;
under the resource directory testSource, the directory can be continuously created or the resource file or the keyword can be directly created, and under the resource file, the keyword of the resource can be placed.
The sub-resource functional domain (100) creates a Session through Create Session and connects with a certain server; initiating a request in a get or Post mode, and returning response content; by To Json: converting the returned text into a json object; by Get From Dictionary: and acquiring a key field of the json character string.
Verifying whether the http request state code is normal or not through the should of the test script extended domain (200); should checks whether the service state code is normal; should checks whether the json returns the key field to meet the expectation; meanwhile, whether the returned value of the interface is matched with the field inquired by the database or not can be judged. And finally, cleaning test data generated in the test process by operating the database.
The invention also provides a full-life-cycle software automatic testing device, which comprises a sub-resource functional domain building module, a testing script extended domain building module, a user scene testing case extended domain building module and a testing module;
the sub-resource functional domain construction module is used for setting a sub-resource functional domain (100), the sub-resource functional domain (100) is used for defining resources, splitting a resource calling module, a called input/output rule and a resource keyword which are used in an automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103);
the ActionOperationinterface request resource module (101) is used for creating a session, transmitting UR L and header parameters, assembling parameter data, processing the parameter data into dictionary type parameters, sending a post/get request according to the interface type, returning a parameter object, and converting the returned parameter object into a json string;
the DBoperation operation resource module (102) is configured to: the database is linked through the keyword drive, and the related information of the database is input; inquiring, modifying, newly adding and deleting table data corresponding to the interface use case, and returning an operation result;
the PublicOperation public operation resource module (103) is used for packaging public keywords related to database operation, wherein the public keywords related to the database operation comprise an Oracle database link, a database query, a database execution command, a database submission command and a database disconnection command;
the test script extended domain building module is used for setting a test script extended domain (200), and the test script extended domain (200) completes the calling management of the relationship among the test script activities of each automation project by executing the following steps:
step a-1, an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) are led in, and a library required by an interface is initialized;
step a-2, designing a corresponding entry parameter and check field by a test script; the corresponding test script returns json data of the interface by calling the request keyword of the tested interface;
step a-3, processing json data, acquiring key data returned by an interface, calling database operation related to the interface, acquiring key data of the database, comparing an interface return value with a database return value through assertion, and if the assertion is consistent, passing the test; if the data are inconsistent, returning test failure, and stopping running the test script;
the user scenario test case extended domain building module is used for setting a user scenario test case extended domain (300), and comprises the following steps:
b-1, configuring a test case template and associating a test script;
b-2, inputting test data and verification data designed by the test cases, setting an execution range through case labels for inheritance relation or mutual exclusion relation among automatic project cases set in a user scene test case expansion domain (300), and supporting custom labels;
the user scenario test case extension domain (300) can call a single test script or more than two test scripts;
the test module is used for constructing a test item and generating a report aiming at software to be tested, and comprises the following steps: executing software test1 to be tested under a user scene test case expansion domain (300) directory in an automatic mode, calling a test script in a test script expansion domain (200), directly calling an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) in a defined sub-resource functional domain (100) by the test script in the test script expansion domain (200), outputting different test reports according to the case type and the case grade of a project, simultaneously providing automatic case resource execution condition, daily analysis and resource warning for each specific activity, and providing warning service for the test cases which do not pass the test;
the test cases are monitored by setting log monitoring, an overall situation summary is provided for project case execution, and the summarized content comprises single-interface request verification, script calling and different user scene test information developed by various automatic project activity types.
The present invention also provides an electronic device, comprising: a processor and a memory having stored therein computer program instructions which, when executed by the processor, cause the processor to perform a full life cycle software automation testing method as described above.
According to the invention, through deep understanding and analysis of the software automation platform construction and test method, the atom splitting of the software automation function is carried out, through flexible configuration modeling of the atom function, different automation project activities can be assembled without development, and only a single atom function service needs to be developed specifically in the face of a brand-new project automation requirement, so that the test cost is reduced to a great extent and the stability of the system is ensured. And moreover, the configuration of mutual exclusion, inheritance, symbiosis and other relationships among project activities is realized through the project activity rules of the automation platform and the modeling of the extension layer. The modeling of activity monitoring is guided through the configuration modeling of the atomic service, multi-dimensional monitoring is carried out from project activity resource management, script management, use case management, various resource processing and the like, and the management and tracking of the whole life cycle are realized. In conclusion, the invention improves the efficiency of automatic testing.
Drawings
The foregoing and other advantages of the invention will become more apparent from the following detailed description of the invention when taken in conjunction with the accompanying drawings.
FIG. 1 is a schematic diagram of the present invention;
FIG. 2 is a diagram illustrating an example of the atomic function service assembly to create a single activity for a user according to an embodiment of the present invention.
Fig. 3 is an architecture diagram of an electronic device provided by the present invention.
Detailed Description
The invention is further explained below with reference to the drawings and the embodiments. As shown in fig. 1 and fig. 2, the present invention provides a full-life-cycle software automated testing method, which includes the following steps:
step 1, setting a sub-resource functional domain (100);
step 2, setting a test script extension domain (200);
step 3, setting a user scene test case expansion domain (300);
and 4, aiming at the software to be tested, constructing a test project, adding resources, adding keywords, constructing a request, responding to assertion, post-processing data and generating a report (400).
The step 1 comprises the following steps: setting a sub-resource functional domain (100), wherein the sub-resource functional domain (100) is used for defining resources, splitting resources of a calling resource module, a called input/output rule and a resource keyword which are used in an automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103).
In the step 1, the ActionOperation interface request resource module (101) is used for creating a session, transmitting UR L and header parameters, assembling parameter-entering data, processing the parameter into dictionary type parameters, sending a post/get request according to the interface type, returning a parameter object, and converting the returned parameter object into a json string.
In step 1, the DBOperation operation resource module (102) is configured to: the database is linked through the keyword drive, and the related information of the database is input; and inquiring, modifying, newly adding and deleting the table data corresponding to the interface use case, and returning an operation result.
In step 1, the PublicOperation public operation resource module (103) is used for packaging public keywords related to database operation, wherein the public keywords related to database operation comprise keywords such as link Oracle database, database query, database execution command, database submission command, database disconnection command and the like, public keywords required by a package initialization interface use case such as package appointed date, backward offset date, forward offset date and current date return and the like, public keywords related to package processing interface use case return data such as dictionary conversion, conversion dictionary, dictionary conversion list, dictionary key value pair fetching and dictionary data assembling operations, and various system resources are defined and comprise UR L addresses and aliases, account information, database connection information and message header information of each system service of each product line.
The step 2 comprises the following steps: setting a test script extension domain (200), wherein the test script extension domain (200) is used for supporting the calling management of the relationship between the test script activities of each automation project, such as the relationship (201) that a single test script can call a single resource and the relationship (202) that multiple test scripts can call a single or multiple resources;
the test script extension domain (200) completes the call management of the relationship between the test script activities of the automation projects by executing the following steps:
step 2-1, an ActionOperation interface request resource module (101), a DBOperation operation resource module (102) and a publicOperation public operation resource module (103) are led in, libraries needed by the initialization interface generally comprise a library of the system, a third party library and a custom library commonly used by the system, such as 'Requests L library', 'Collections library' and 'String library'.
Step 2-2, designing corresponding entry and check fields by the test script; the corresponding test script returns json data of the interface by calling the request keyword of the tested interface;
examples are: for example, test the login interface script, check if $ { logenaddr.
Step 2-3, processing the json data, acquiring key data returned by the interface, calling database operation related to the interface, acquiring key data of the database, comparing an interface return value with a database return value through assertion, and if the assertion is consistent, passing the test; and if the data are inconsistent, returning that the test fails, and stopping running the test script.
The test script extension domain (200) has independent functions, has zero intrusion to the original system automation script, can flexibly configure and control the rules of each project script independently and independently, and stores and manages the inheritance relationship or the mutual exclusion relationship among the automation project scripts set in the extension domain in a special expression form by increasing the mapping of the relationship among the project scripts instead of simple rule superposition.
In step 3, the setting of the user scenario test case extension domain (300) includes the following steps:
step 3-1, configuring a test case template and associating a test script;
the general principle of test case template configuration is as follows:
1. the identifiers are named as required and the core points are verified using a clear key and a suitable level of abstraction.
2. Naming by using a file:
the name prepended ID should be as descriptive as possible and at the appropriate level of abstraction. Such as a 001 login interface, etc.;
3. testcase nomenclature
The 3.1 name should be as descriptive as possible and not overly long. E.g., correct username password entry verification, etc.;
3.2 the name is unified in Chinese, allowing only the underlined _ symbol to exist. For example: login interface _ correct username password input verification, etc.;
step 3-2, inputting test data and check data designed by the test cases, setting an execution range for inheritance relationship or mutual exclusion relationship among automatic project cases set in a user scene test case expansion domain (300) through case labels instead of simple rule superposition, for example, setting case tags as 'second-level' cases can execute all case-centralized second-level cases, and simultaneously supporting self-defined labels, for example, if the self-defined ratio labels are 'project main flow', the test cases of the main flow can be executed through all case-centralized execution.
In step 3, the user scenario test case extension domain (300) can call a single test script or more than two test scripts.
Step 4 comprises the following steps: the software test1 to be tested under the directory of the user scenario test case expansion domain (300) is executed in an automatic mode, a test script in the test script expansion domain (200) is called, the test script in the test script expansion domain (200) directly calls an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) in a defined sub-resource functional domain (100) to output different test reports according to the case class step type and the case class of a project, meanwhile, the automatic case resource execution condition, daily treatment analysis and resource warning are provided for each specific activity, and warning service is provided for the test cases which cannot pass the test.
The test cases are monitored by setting log monitoring, an overall situation summary is provided for project case execution, and the summarized content comprises single-interface request verification, script calling and different user scene test information developed by various automatic project activity types.
Under the directory of the user scene test case expansion domain (300), the directory can be continuously created or a test set note file can be directly created, and a test case or a user keyword is created under the test set;
under the resource directory testSource, the directory can be continuously created or the resource file or the keyword can be directly created, and under the resource file, the keyword of the resource can be placed.
The sub-resource functional domain (100) creates a Session through Create Session and connects with a certain server; initiating a request in a get or Post mode, and returning response content; by To Json: converting the returned text into a json object; by Get From Dictionary: and acquiring a key field of the json character string.
Verifying whether the http request state code is normal or not through the should of the test script extended domain (200); should checks whether the service state code is normal; should checks whether the json returns the key field to meet the expectation; meanwhile, whether the returned value of the interface is matched with the field inquired by the database or not can be judged. And finally, cleaning test data generated in the test process by operating the database.
Examples
In this embodiment, the automated testing method of the present invention is used for testing software, and specifically includes:
firstly, establishing a test item:
1. general principles of directory management
The large hump method identifies that following a path name has clear descriptive properties.
2. Directory structure
- -library public custom
Public resource files, keyword files, etc. extracted from various directions of resources
-cases for each direction of suites
- -Teardown initialization data, restoring the site
-publicOperation environment & account variable & request address
3. Directory naming
The 3.1 name should be as descriptive as possible. Such as InterfaceTest, ActionOperation, etc.;
3.2 big hump mark without symbol and separation between words, big hump method, the first letter of each word adopts capital letter, for example, FirstName, L astName;
second, case management writing standard
1. The name of the test case should be less than 40 characters;
2. the test case name should adopt a hump mode (each initial letter is capital, and other letters are lowercase) for English, for example;
3. the name must be legible and meaningful (from which one can know what the test case does);
4. the document should be updated according to the steps of testing, annotation, and condition information;
5. giving an appropriate tag for each case;
6. should be independent between tests;
7. hard-coded object names should be avoided;
8. high-level keywords should be packed often instead of repeated steps;
third, the writing standard of key words
1. The name must be legible and meaningful (it can be known from the name what the method does);
2. named using humps;
3. prefix/suffix is useful, e.g. is to ask a question, get gets a value, set assigns a value;
4. to increase readability, there may be spaces;
5. the document should contain a clear description: usage, variables, returned values;
6. avoid hard-coded object names;
7. the parameter should begin with p, the return value should begin with r, and the local variable should begin with t;
8. no duplicate method is added;
9. can contain some program logic (for loop, if/else);
10. complex logic should be put into class libraries instead of keywords;
11. very important variables require an annotation behind them;
12. and setting detection points according to the emphasis points of the test cases. For example: for example, checking the return code in the case execution result;
13. the set detection points are comprehensive. For example: under the premise of knowing the influence of test operation, important detection points must be set
Four, variable writing specification
1. The variable name does not exceed 20 characters;
2. variable names should be meaningful words;
3. named after hump;
4. the parameter should begin with p, the return value should begin with r, the local variable should begin with t, and the GUI variable should begin with o;
5. the constants should be all capitalized. For example: $ HZGAccount, some other type variables should be of mixed type (lower case plus upper case);
6. scripts and global variables should be placed at the forefront of the script;
7. spaces and underlines may be used to improve legibility;
the software test1 to be tested under the directory of the user scenario test case expansion domain (300) is executed in an automatic mode, a test script in the test script expansion domain (200) is called, the test script in the test script expansion domain (200) directly calls an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) in a defined sub-resource functional domain (100) to output different test reports according to the case class step type and the case class of a project, meanwhile, the automatic case resource execution condition, daily treatment analysis and resource warning are provided for each specific activity, and warning service is provided for the test cases which cannot pass the test.
The test cases are monitored by setting log monitoring, an overall situation summary is provided for project case execution, and the summarized content comprises single-interface request verification, script calling and different user scene test information developed by various automatic project activity types.
Under the directory of the user scene test case expansion domain (300), the directory can be continuously created or a test set note file can be directly created, and a test case or a user keyword is created under the test set;
under the resource directory testSource, the directory can be continuously created or the resource file or the keyword can be directly created, and under the resource file, the keyword of the resource can be placed.
The sub-resource functional domain (100) creates a Session through Create Session and connects with a certain server; initiating a request in a get or Post mode, and returning response content; by To Json: converting the returned text into a json object; by Get From Dictionary: and acquiring a key field of the json character string.
Verifying whether the http request state code is normal or not through the should of the test script extended domain (200); should checks whether the service state code is normal; should checks whether the json returns the key field to meet the expectation; meanwhile, whether the returned value of the interface is matched with the field inquired by the database or not can be judged. And finally, cleaning test data generated in the test process by operating the database.
The invention also provides a full-life-cycle software automatic testing device, which comprises a sub-resource functional domain building module, a testing script extended domain building module, a user scene testing case extended domain building module and a testing module;
the sub-resource functional domain construction module is used for setting a sub-resource functional domain (100), the sub-resource functional domain (100) is used for defining resources, splitting a resource calling module, a called input/output rule and a resource keyword which are used in an automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103);
the ActionOperationinterface request resource module (101) is used for creating a session, transmitting UR L and header parameters, assembling parameter data, processing the parameter data into dictionary type parameters, sending a post/get request according to the interface type, returning a parameter object, and converting the returned parameter object into a json string;
the DBoperation operation resource module (102) is configured to: the database is linked through the keyword drive, and the related information of the database is input; inquiring, modifying, newly adding and deleting table data corresponding to the interface use case, and returning an operation result;
the PublicOperation public operation resource module (103) is used for packaging public keywords related to database operation, wherein the public keywords related to the database operation comprise an Oracle database link, a database query, a database execution command, a database submission command and a database disconnection command;
the test script extended domain building module is used for setting a test script extended domain (200), and the test script extended domain (200) completes the calling management of the relationship among the test script activities of each automation project by executing the following steps:
step a-1, an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) are led in, and a library required by an interface is initialized;
step a-2, designing a corresponding entry parameter and check field by a test script; the corresponding test script returns json data of the interface by calling the request keyword of the tested interface;
step a-3, processing json data, acquiring key data returned by an interface, calling database operation related to the interface, acquiring key data of the database, comparing an interface return value with a database return value through assertion, and if the assertion is consistent, passing the test; if the data are inconsistent, returning test failure, and stopping running the test script;
the user scenario test case extended domain building module is used for setting a user scenario test case extended domain (300), and comprises the following steps:
b-1, configuring a test case template and associating a test script;
b-2, inputting test data and verification data designed by the test cases, setting an execution range through case labels for inheritance relation or mutual exclusion relation among automatic project cases set in a user scene test case expansion domain (300), and supporting custom labels;
the user scenario test case extension domain (300) can call a single test script or more than two test scripts;
the test module is used for constructing a test item and generating a report aiming at software to be tested, and comprises the following steps: executing software test1 to be tested under a user scene test case expansion domain (300) directory in an automatic mode, calling a test script in a test script expansion domain (200), directly calling an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) in a defined sub-resource functional domain (100) by the test script in the test script expansion domain (200), outputting different test reports according to the case type and the case grade of a project, simultaneously providing automatic case resource execution condition, daily analysis and resource warning for each specific activity, and providing warning service for the test cases which do not pass the test;
the test cases are monitored by setting log monitoring, an overall situation summary is provided for project case execution, and the summarized content comprises single-interface request verification, script calling and different user scene test information developed by various automatic project activity types.
As described above, the full-life-cycle software automation test device according to the embodiment of the present application can be implemented in various terminal devices, such as a server of a distributed computing system. In one example, a full-life software automation test device according to the embodiment of the application can be integrated into the terminal equipment as a software module and/or a hardware module. For example, the automated test equipment may be a software module in the operating system of the terminal device, or may be an application developed for the terminal device; of course, the automatic testing device can also be one of many hardware modules of the terminal equipment.
Alternatively, in another example, the automatic testing device and the terminal device may be separate terminal devices, and the automatic testing device may be connected to the terminal device through a wired and/or wireless network and transmit the interaction information according to an agreed data format.
As shown in fig. 3, the present application also provides an electronic device 10, comprising:
one or more processors 11 and memory 12, the processor 11 may be a Central Processing Unit (CPU) or other form of processing unit having data processing capabilities and/or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.
Memory 12 may include one or more computer program products that may include various forms of computer-readable storage media, such as volatile memory and/or non-volatile memory. The volatile memory may include, for example, Random Access Memory (RAM), cache memory (cache), and/or the like. The non-volatile memory may include, for example, Read Only Memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium and executed by processor 11 to implement a full-life software automation testing method of the various embodiments of the present application described above and/or other desired functionality.
In one example, the electronic device 10 may also include an input device 13 and an output device 14, which may be interconnected via a bus system and/or other form of connection mechanism (not shown).
For example, the input device 13 may be a keyboard, a mouse, or the like.
The output device 14 may output various information including the results of the automated testing method to the outside. The output devices 14 may include, for example, a display, speakers, a printer, and a communication network and its connected remote output devices.
Of course, for simplicity, only some of the components of the electronic device 10 relevant to the present application are shown in fig. 3, omitting components such as buses, input/output interfaces, and the like.
According to another aspect of the present application, there is also provided a computer readable storage medium having stored thereon computer program instructions operable, when executed by a computing device, to perform an automated testing method as described above.
The present invention provides a full-life software automatic testing method and device, and a plurality of methods and approaches for implementing the technical solution are provided, the above description is only a preferred embodiment of the present invention, it should be noted that, for those skilled in the art, a plurality of improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be regarded as the protection scope of the present invention. All the components not specified in the present embodiment can be realized by the prior art.
Claims (10)
1. A full life cycle software automatic test method is characterized by comprising the following steps:
step 1, setting a sub-resource functional domain (100);
step 2, setting a test script extension domain (200);
step 3, setting a user scene test case expansion domain (300);
and 4, constructing a test item aiming at the software to be tested, and generating a report.
2. The method of claim 1, wherein step 1 comprises: setting a sub-resource functional domain (100), wherein the sub-resource functional domain (100) is used for defining resources, splitting resources of a calling resource module, a called input/output rule and a resource keyword which are used in an automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103).
3. The method of claim 2, wherein in step 1, the ActionOperation interface request resource module (101) is used for creating a session, transmitting UR L, header parameters, assembling parameter data, processing the parameter data into dictionary type parameters, sending a post/get request according to the interface type, returning a parameter object, and converting the returned parameter object into a json string.
4. The method of claim 3, wherein in step 1, the DBoperation operation resource module (102) is configured to: the database is linked through the keyword drive, and the related information of the database is input; and inquiring, modifying, newly adding and deleting the table data corresponding to the interface use case, and returning an operation result.
5. The method as claimed in claim 4, wherein in step 1, the PublicOperation public operation resource module (103) is used for encapsulating public keywords related to database operation, wherein the public keywords related to database operation comprise a link Oracle database, a database query, a database execution command, a database submission command, a database connection disconnection command, public keywords required by an encapsulation initialization interface use case, and public keywords related to encapsulation processing interface use case return data, and for defining various system resources, including UR L addresses and aliases, account information, database connection information and message header information of various system services of various product lines.
6. The method of claim 5, wherein step 2 comprises: setting a test script extension domain (200), wherein the test script extension domain (200) completes the calling management of the relation between the test script activities of each automation project by executing the following steps:
step 2-1, an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) are led in, and a library required by an interface is initialized;
step 2-2, designing corresponding entry and check fields by the test script; the corresponding test script returns json data of the interface by calling the request keyword of the tested interface;
step 2-3, processing the json data, acquiring key data returned by the interface, calling database operation related to the interface, acquiring key data of the database, comparing an interface return value with a database return value through assertion, and if the assertion is consistent, passing the test; and if the data are inconsistent, returning that the test fails, and stopping running the test script.
7. The method according to claim 6, wherein in step 3, the setting of the user scenario test case extension field (300) comprises the following steps:
step 3-1, configuring a test case template and associating a test script;
and 3-2, inputting test data and verification data designed by the test cases, setting an execution range through case labels for inheritance relation or mutual exclusion relation among the automatic project cases set in the user scene test case extension domain (300), and supporting custom labels.
8. The method of claim 7, wherein in step 3, the user scenario test case extension field (300) is capable of calling a single test script or more than two test scripts.
9. The method of claim 8, wherein step 4 comprises: executing software test1 to be tested under a user scene test case expansion domain (300) directory in an automatic mode, calling a test script in a test script expansion domain (200), directly calling an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) in a defined sub-resource functional domain (100) by the test script in the test script expansion domain (200), outputting different test reports according to the case type and the case grade of a project, simultaneously providing automatic case resource execution condition, daily analysis and resource warning for each specific activity, and providing warning service for the test cases which do not pass the test;
the test cases are monitored by setting log monitoring, an overall situation summary is provided for project case execution, and the summarized content comprises single-interface request verification, script calling and different user scene test information developed by various automatic project activity types.
10. A full-life-cycle software automatic testing device is characterized by comprising a sub-resource functional domain building module, a testing script extended domain building module, a user scenario testing case extended domain building module and a testing module;
the sub-resource functional domain construction module is used for setting a sub-resource functional domain (100), the sub-resource functional domain (100) is used for defining resources, splitting a resource calling module, a called input/output rule and a resource keyword which are used in an automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103);
the ActionOperationinterface request resource module (101) is used for creating a session, transmitting UR L and header parameters, assembling parameter data, processing the parameter data into dictionary type parameters, sending a post/get request according to the interface type, returning a parameter object, and converting the returned parameter object into a json string;
the DBoperation operation resource module (102) is configured to: the database is linked through the keyword drive, and the related information of the database is input; inquiring, modifying, newly adding and deleting table data corresponding to the interface use case, and returning an operation result;
the PublicOperation public operation resource module (103) is used for packaging public keywords related to database operation, wherein the public keywords related to the database operation comprise an Oracle database link, a database query, a database execution command, a database submission command and a database disconnection command;
the test script extended domain building module is used for setting a test script extended domain (200), and the test script extended domain (200) completes the calling management of the relationship among the test script activities of each automation project by executing the following steps:
step a-1, an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) are led in, and a library required by an interface is initialized;
step a-2, designing a corresponding entry parameter and check field by a test script; the corresponding test script returns json data of the interface by calling the request keyword of the tested interface;
step a-3, processing json data, acquiring key data returned by an interface, calling database operation related to the interface, acquiring key data of the database, comparing an interface return value with a database return value through assertion, and if the assertion is consistent, passing the test; if the data are inconsistent, returning test failure, and stopping running the test script;
the user scenario test case extended domain building module is used for setting a user scenario test case extended domain (300), and comprises the following steps:
b-1, configuring a test case template and associating a test script;
b-2, inputting test data and verification data designed by the test cases, setting an execution range through case labels for inheritance relation or mutual exclusion relation among automatic project cases set in a user scene test case expansion domain (300), and supporting custom labels;
the user scenario test case extension domain (300) can call a single test script or more than two test scripts;
the test module is used for constructing a test item and generating a report aiming at software to be tested, and comprises the following steps: executing software test1 to be tested under a user scene test case expansion domain (300) directory in an automatic mode, calling a test script in a test script expansion domain (200), directly calling an action operation interface request resource module (101), a DBoperation operation resource module (102) and a public operation resource module (103) in a defined sub-resource functional domain (100) by the test script in the test script expansion domain (200), outputting different test reports according to the case type and the case grade of a project, simultaneously providing automatic case resource execution condition, daily analysis and resource warning for each specific activity, and providing warning service for the test cases which do not pass the test;
the test cases are monitored by setting log monitoring, an overall situation summary is provided for project case execution, and the summarized content comprises single-interface request verification, script calling and different user scene test information developed by various automatic project activity types.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010115705.3A CN111459793B (en) | 2020-02-25 | 2020-02-25 | Full life cycle software automatic test method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010115705.3A CN111459793B (en) | 2020-02-25 | 2020-02-25 | Full life cycle software automatic test method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111459793A true CN111459793A (en) | 2020-07-28 |
| CN111459793B CN111459793B (en) | 2023-05-30 |
Family
ID=71685136
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010115705.3A Active CN111459793B (en) | 2020-02-25 | 2020-02-25 | Full life cycle software automatic test method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111459793B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112463627A (en) * | 2020-12-10 | 2021-03-09 | 北京明略软件系统有限公司 | Testing method and system for enterprise WeChat, electronic equipment and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102063372A (en) * | 2010-12-30 | 2011-05-18 | 浪潮集团山东通用软件有限公司 | Main key driven modularized automated test method |
| CN107832231A (en) * | 2017-12-05 | 2018-03-23 | 郑州云海信息技术有限公司 | A kind of system detection method, device and medium |
| CN110175126A (en) * | 2019-05-27 | 2019-08-27 | 中国航空无线电电子研究所 | Test case based on scripting language |
-
2020
- 2020-02-25 CN CN202010115705.3A patent/CN111459793B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102063372A (en) * | 2010-12-30 | 2011-05-18 | 浪潮集团山东通用软件有限公司 | Main key driven modularized automated test method |
| CN107832231A (en) * | 2017-12-05 | 2018-03-23 | 郑州云海信息技术有限公司 | A kind of system detection method, device and medium |
| CN110175126A (en) * | 2019-05-27 | 2019-08-27 | 中国航空无线电电子研究所 | Test case based on scripting language |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112463627A (en) * | 2020-12-10 | 2021-03-09 | 北京明略软件系统有限公司 | Testing method and system for enterprise WeChat, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111459793B (en) | 2023-05-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108108297B (en) | Method and device for automatic testing | |
| US20180011780A1 (en) | Web application test script generation to test software functionality | |
| US20040199818A1 (en) | Automated testing of web services | |
| Zhang et al. | Criteria analysis and validation of the reliability of web services-oriented systems | |
| Tsai et al. | Developing and assuring trustworthy web services | |
| CN112187558B (en) | Data verification method and device and electronic equipment | |
| US20210117313A1 (en) | Language agnostic automation scripting tool | |
| CN110007926A (en) | Language transfer method and device | |
| CN113127108A (en) | Service request processing method and device, storage medium and electronic equipment | |
| CN110704394B (en) | Report configuration modification method and device | |
| CN106649110B (en) | Software testing method and system | |
| CN111459793B (en) | Full life cycle software automatic test method and device | |
| CN113778897A (en) | Automatic test method, device, equipment and storage medium of interface | |
| CN113885876A (en) | Parameter checking method, device, storage medium and computer system | |
| CN113836014A (en) | Interface testing method and device, electronic equipment and storage medium | |
| CN113391972A (en) | Interface testing method and device | |
| CN111506305A (en) | Tool kit generation method and device, computer equipment and readable storage medium | |
| CN115904317A (en) | Method, device, equipment and storage medium for uniformly calling front-end interface and back-end interface | |
| CN115408059A (en) | Front-end and service-end data interaction method and device and computer equipment | |
| Arora et al. | Mobile agent‐based regression test case generation using model and formal specifications | |
| CN114371848A (en) | Page joint debugging method, device, equipment and storage medium | |
| CN112380142A (en) | Interface document management method and device and test equipment | |
| CN112948232A (en) | Game protocol testing method and device, electronic equipment and storage medium | |
| CN111240958A (en) | Interface testing method and device, electronic equipment and medium | |
| Habibi et al. | Sharif-TaaWS: a tool to automate unit testing of web services |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |