CN111459793B - Full life cycle software automatic test method and device - Google Patents
Full life cycle software automatic test method and device Download PDFInfo
- Publication number
- CN111459793B CN111459793B CN202010115705.3A CN202010115705A CN111459793B CN 111459793 B CN111459793 B CN 111459793B CN 202010115705 A CN202010115705 A CN 202010115705A CN 111459793 B CN111459793 B CN 111459793B
- Authority
- CN
- China
- Prior art keywords
- test
- interface
- database
- resource
- case
- 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.)
- Active
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 device, wherein the method comprises the following steps: splitting the atomic resource function of the software automation platform; an independent test script expansion domain is arranged in the software automation platform; an independent user scene test case expansion domain is arranged in the software automation platform; software automates the full lifecycle management of project activities. The proposal has flexible expansion and splitting capability on the use cases, scripts and resources of the automatic platform; meanwhile, complete automatic activities can be output to the outside, so that the automatic platform can be conveniently grafted to an external service system to split the bottom atomic resource functions; the automatic project activity expansion is flexible, the real-time monitoring of project activity and resource consumption condition is realized, and the whole life cycle management flow generated from project activity establishment, operation and ending is reported.
Description
Technical Field
The invention belongs to the technical field of software automation testing systems, and particularly relates to a full life cycle software automation testing method and device.
Background
At present, the construction of an existing software automation platform is generally carried out by adopting an automation mode of constructing single project activities one by one, in order to avoid the mutual influence among test cases, the flexibility is higher, each test resource and each test script are independently constructed, the independent test script is called only when the final project activity test case resource processing is required, the independent test resource processing service is called through the test script, the construction mode is adopted, when the new project activity is required, the new project activity needs to do full-scale automatic test case coding development again based on the service requirement, the implanted monitoring code is required to be redefined according to the monitoring requirement of the project activity to carry out activity operation monitoring, the mutual exclusion or symbiotic relation among the activities cannot be flexibly configured, and additional coding control is required.
The main disadvantage of the single project activity independent development test automation script mode mentioned in the above technology is that the automation platform has poor flexibility and large resource consumption: the automatic testers of each project activity need to output test cases again to release online, and the requirements of improving the development efficiency of fast rhythms cannot be met; the mutual exclusion or symbiotic relation between project activities cannot be flexibly configured, the test case relation of the internal and external projects can not be processed by the visual test case of the external projects can not be accessed quickly, the independent repeated test script coding development is required to be carried out according to the activity requirement of each project, the time consumption is long, the automatic test code is easy to be unstable, and the resource loss is caused; when monitoring of the project activity test effect is required, because the project activity schemes which are independently developed are not consistent in normal format, unified monitoring modeling cannot be performed, and monitoring and development of single project activities are difficult, only the operation result of the activities is often concerned, and full life cycle monitoring from project activity creation to settlement is lacking.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a full life cycle software automatic test 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, constructing a test item aiming at the software to be tested, adding resources, adding keywords, constructing a request, responding to assertion, processing post 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 the call resource module, the called input-output rule and the resource keyword used in the automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103).
In step 1, the ActionOperation interface requests a resource module (101) for: creating a session, and transmitting URL (Uniform resource locator) parameters; assembling the input parameter data and processing the input parameter data into dictionary type parameters; according to the interface type, a post/get request is sent, and a parameter object is returned; the json string is rotated on the return parameter object.
In step 1, the DBOperation operation resource module (102) is configured to: the related information of the database is input through the keyword driving link database; inquiring, modifying, 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 configured to: packaging common keywords related to database operation, wherein the common keywords related to database operation comprise keywords such as a link Oracle database, database inquiry, database execution command, database submitting command, database connection disconnection command and the like; packaging public keywords required by initializing interface use cases, such as packaging public keywords such as a specified date, a backward offset date, a forward offset date, a current date and the like; the package processing interface case returns the data related public keywords, such as dictionary transfer, version transfer dictionary, dictionary transfer list, dictionary key value pair, dictionary data and other public keywords; various system resources are defined, including URL addresses and aliases for various system services for various product lines, account information, database connection information, and message header information.
The step 2 comprises the following steps: setting a test script extension field (200), wherein the test script extension field (200) is used for supporting call management of relations among various automation project test script activities, such as a relation (201) that a single test script can call a single resource and a relation (202) that multiple test scripts can call a single resource or multiple resources;
the test script extension field (200) performs call management of relationships between automation project test script activities by performing the steps of:
step 2-1, importing an ActionOperation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103), and initializing libraries required by the interface: typically include libraries that are self-contained in the system, third party libraries and custom library systems commonly used libraries such as: "RequestsLibrary library", "Collection library", and "String library".
Step 2-2, designing corresponding parameter entering and checking fields by the test script; the corresponding test script returns interface json data by calling the request key words of the tested interface;
examples: such as testing a login interface script, checking if $ { logionaddr.status_code } of the script is equal to 200 by entering the key "$ { username }" $ { passw } ".
Step 2-3, processing json data to obtain key data returned by the interface, calling database operation related to the interface to obtain the key data of the database, comparing the interface return value with the database return value through assertion, and if assertion is consistent, passing the test; and if the data are inconsistent, returning to test failure, and terminating the running of the test script.
The test script extension domain (200) has independent functions, zero invasion to the original system automation script, and can flexibly configure and control the rules of each project script to be independently controlled and independently managed, and the inheritance relationship or the mutual exclusion relationship between the automation project scripts arranged in the extension domain is not simply overlapped with the rules, but is stored and managed in a specific expression mode by adding the mapping of the relationship between the project scripts.
In step 3, the setting a user scene 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. naming the identity as required, verifying the core points using the clear keywords and the appropriate level of abstraction.
2. Naming the case file:
The name prepended ID should be as descriptive as possible and of a suitable level of abstraction. Such as a 001 login interface, etc.;
3. TestCase naming
The 3.1 name should be as descriptive as possible and not too long. E.g., correct username-password entry verification, etc.;
3.2 the name is unified with Chinese, only allowing the underline_symbol to exist. For example: logging in the interface_correct user name password input check and the like;
and 3-2, inputting test data and verification data of test case design, and setting an execution range through case labels instead of simple rule superposition for inheritance relations or mutual exclusion relations among automation project cases set in a user scene test case expansion domain (300), wherein for example, the case with the case tags set as 'secondary', the secondary cases in all case sets can be executed, and custom labels are supported, for example, if a self-defined comparison label is 'project main flow', the test cases of the main flow can be executed in all case sets.
In step 3, the user scenario test case extension field (300) is capable of invoking a single test script or more than two test scripts.
Step 4 comprises: executing the software test1 to be tested under the directory of the user scene test case expansion domain (300) in an automatic mode, calling the test script in the test script expansion domain (200), directly calling the test script in the test script expansion domain (200) to an action interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103) in the defined sub-resource function domain (100), outputting different test reports according to the case step types and the case grades of the items, and simultaneously providing automatic case resource execution conditions, log analysis and resource out early warning for each specific activity and providing warning service for test cases which do not pass the test.
The test cases are monitored through log monitoring, overall condition overview is provided for project case execution, and summarized contents comprise single-interface request verification, script calling and different user scene test information which are developed by various automatic project activity types.
Under the directory of the expansion domain (300) of the test case of the user scene, the directory can be continuously created or the test set date file can be directly created, and the test case or the user keyword can be created under the test set;
the directory can be continuously created under the resource directory testSource or the resource file or the key word can be directly created, and the key word can be placed under the resource file.
The sub-resource functional domain (100) is connected with a certain server by creating a Session; initiating a request in a get or Post mode, and returning response content; through To Json: converting the return text into json objects; through Get From Dictionary: and acquiring a json character string key field.
Checking whether the http request status code is normal or not through a test script extension domain (200) shold; checking whether the service status code is normal or not by using the shield; the Should check json returns whether the key field accords with the expectation; and meanwhile, whether the returned value of the interface is matched with the field queried by the database or not can be judged. And finally cleaning test data generated in the test process through the operation database.
The invention also provides a full life cycle software automation testing device, which comprises a sub-resource functional domain construction module, a test script extension domain construction module, a user scene test case extension domain construction module and a test module;
the sub-resource functional domain construction module is used for setting a sub-resource functional domain (100), wherein the sub-resource functional domain (100) is used for defining resources, and splitting the called resource module, the called input-output rule and the resource keyword used in the automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103);
the ActionOperation interface requests a resource module (101) for: creating a session, and transmitting URL (Uniform resource locator) parameters; assembling the input parameter data and processing the input parameter data into dictionary type parameters; according to the interface type, a post/get request is sent, and a parameter object is returned; transferring json strings to the returned parameter objects;
the DBoperation operation resource module (102) is configured to: the related information of the database is input through the keyword driving link database; inquiring, modifying, newly adding and deleting table data corresponding to the interface use case, and returning an operation result;
The PublicOperation common operation resource module (103) is configured to: packaging common keywords related to database operation, wherein the common keywords related to database operation comprise a linked Oracle database, database inquiry, database execution commands, database submitting commands and database connection disconnection commands; packaging public keywords required by initializing interface use cases; the package processing interface use case returns a public key word related to the data; defining various system resources, including URL addresses and aliases, account information, database connection information and message header information of various system services of various product lines;
the test script extension domain construction module is used for setting a test script extension domain (200), and the test script extension domain (200) completes the call management of the relation between the test script activities of each automation item by executing the following steps:
step a-1, importing an Actionoperation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103), and initializing libraries required by an interface;
step a-2, designing corresponding parameter entering and checking fields by a test script; the corresponding test script returns interface json data by calling the request key words of the tested interface;
Step a-3, processing json data, obtaining key data returned by the interface, calling database operation related to the interface, obtaining the key data of the database, comparing the interface return value with the database return value through assertion, and if assertion is consistent, passing the test; if the data are inconsistent, returning to test failure, and terminating the operation of the test script;
the user scene test case expansion domain construction module is used for setting a user scene test case expansion 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 of test case design, setting an execution range through a case label for inheritance relation or mutual exclusion relation among automation project cases set in a user scene test case expansion domain (300), and supporting a custom label;
the user scene test case extension domain (300) can call a single test script or more than two test scripts;
the test module is used for constructing test items aiming at the software to be tested and generating reports, and comprises the following steps: executing the software test1 to be tested under the directory of the user scene test case expansion domain (300) in an automatic mode, calling a test script in the test script expansion domain (200), directly calling an action interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103) in a defined sub-resource function domain (100) by the test script in the test script expansion domain (200), outputting different test reports according to the use case type and the use case level of the project, simultaneously providing an automatic use case resource execution condition, log analysis and resource out early warning for each specific activity, and providing an alarm service for the test use case which fails the test;
The test cases are monitored through log monitoring, overall condition overview is provided for project case execution, and summarized contents comprise single-interface request verification, script calling and different user scene test information which are developed by various automatic project activity types.
The invention also provides an electronic device, comprising: a processor and a memory, in which computer program instructions are stored which, when executed by the processor, cause the processor to perform a full lifecycle software automated test method as described above.
According to the invention, through deep understanding analysis of the software automation platform construction and the testing method, the atomic resolution of the software automation function is carried out, different automation project activities can be assembled without development through flexible atomic function configuration modeling, and only a single atomic function service is required to be developed in a targeted manner in the face of a brand new project automation requirement, so that the testing cost is reduced to a great extent, and the stability of the system is ensured. And moreover, the configuration of the relationships such as mutual exclusion, inheritance, symbiosis and the like among project activities is realized through modeling of the project activity rules and the expansion layer of the automation platform. The modeling of activity monitoring is guided through the configuration modeling of the atomic service, and multi-dimensional monitoring is carried out from project activity resource management, script management, use case management, various resource processing and the like, so that the management and tracking of the whole life cycle are realized. In summary, the present invention improves the automated testing performance.
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 and detailed description.
FIG. 1 is a schematic diagram of an architecture of the present invention;
FIG. 2 is a diagram illustrating an example of an individual activity that can be created for a user by performing an assembly of atomic function services according to an embodiment of the present invention.
Fig. 3 is a schematic diagram of an electronic device according to the present invention.
Detailed Description
The invention will be further described with reference to the accompanying drawings and examples. As shown in fig. 1 and 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, constructing a test item aiming at the software to be tested, adding resources, adding keywords, constructing a request, responding to assertion, processing post 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 the call resource module, the called input-output rule and the resource keyword used in the automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103).
In step 1, the ActionOperation interface requests a resource module (101) for: creating a session, and transmitting URL (Uniform resource locator) parameters; assembling the input parameter data and processing the input parameter data into dictionary type parameters; according to the interface type, a post/get request is sent, and a parameter object is returned; the json string is rotated on the return parameter object.
In step 1, the DBOperation operation resource module (102) is configured to: the related information of the database is input through the keyword driving link database; inquiring, modifying, 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 configured to: packaging common keywords related to database operation, wherein the common keywords related to database operation comprise keywords such as a link Oracle database, database inquiry, database execution command, database submitting command, database connection disconnection command and the like; packaging public keywords required by initializing interface use cases, such as packaging public keywords such as a specified date, a backward offset date, a forward offset date, a current date and the like; the package processing interface case returns the data related public keywords, such as dictionary transfer, version transfer dictionary, dictionary transfer list, dictionary key value pair, dictionary data and other public keywords; various system resources are defined, including URL addresses and aliases for various system services for various product lines, account information, database connection information, and message header information.
The step 2 comprises the following steps: setting a test script extension field (200), wherein the test script extension field (200) is used for supporting call management of relations among various automation project test script activities, such as a relation (201) that a single test script can call a single resource and a relation (202) that multiple test scripts can call a single resource or multiple resources;
the test script extension field (200) performs call management of relationships between automation project test script activities by performing the steps of:
step 2-1, importing an ActionOperation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103), and initializing libraries required by the interface: typically include libraries that are self-contained in the system, third party libraries and custom library systems commonly used libraries such as: "RequestsLibrary library", "Collection library", and "String library".
Step 2-2, designing corresponding parameter entering and checking fields by the test script; the corresponding test script returns interface json data by calling the request key words of the tested interface;
examples: such as testing a login interface script, checking if $ { logionaddr.status_code } of the script is equal to 200 by entering the key "$ { username }" $ { passw } ".
Step 2-3, processing json data to obtain key data returned by the interface, calling database operation related to the interface to obtain the key data of the database, comparing the interface return value with the database return value through assertion, and if assertion is consistent, passing the test; and if the data are inconsistent, returning to test failure, and terminating the running of the test script.
The test script extension domain (200) has independent functions, zero invasion to the original system automation script, and can flexibly configure and control the rules of each project script to be independently controlled and independently managed, and the inheritance relationship or the mutual exclusion relationship between the automation project scripts arranged in the extension domain is not simply overlapped with the rules, but is stored and managed in a specific expression mode by adding the mapping of the relationship between the project scripts.
In step 3, the setting a user scene 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. naming the identity as required, verifying the core points using the clear keywords and the appropriate level of abstraction.
2. Naming the case file:
The name prepended ID should be as descriptive as possible and of a suitable level of abstraction. Such as a 001 login interface, etc.;
3. TestCase naming
The 3.1 name should be as descriptive as possible and not too long. E.g., correct username-password entry verification, etc.;
3.2 the name is unified with Chinese, only allowing the underline_symbol to exist. For example: logging in the interface_correct user name password input check and the like;
and 3-2, inputting test data and verification data of test case design, and setting an execution range through case labels instead of simple rule superposition for inheritance relations or mutual exclusion relations among automation project cases set in a user scene test case expansion domain (300), wherein for example, the case with the case tags set as 'secondary', the secondary cases in all case sets can be executed, and custom labels are supported, for example, if a self-defined comparison label is 'project main flow', the test cases of the main flow can be executed in all case sets.
In step 3, the user scenario test case extension field (300) is capable of invoking a single test script or more than two test scripts.
Step 4 comprises: executing the software test1 to be tested under the directory of the user scene test case expansion domain (300) in an automatic mode, calling the test script in the test script expansion domain (200), directly calling the test script in the test script expansion domain (200) to an action interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103) in the defined sub-resource function domain (100), outputting different test reports according to the case step types and the case grades of the items, and simultaneously providing automatic case resource execution conditions, log analysis and resource out early warning for each specific activity and providing warning service for test cases which do not pass the test.
The test cases are monitored through log monitoring, overall condition overview is provided for project case execution, and summarized contents comprise single-interface request verification, script calling and different user scene test information which are developed by various automatic project activity types.
Under the directory of the expansion domain (300) of the test case of the user scene, the directory can be continuously created or the test set date file can be directly created, and the test case or the user keyword can be created under the test set;
the directory can be continuously created under the resource directory testSource or the resource file or the key word can be directly created, and the key word can be placed under the resource file.
The sub-resource functional domain (100) is connected with a certain server by creating a Session; initiating a request in a get or Post mode, and returning response content; through To Json: converting the return text into json objects; through Get From Dictionary: and acquiring a json character string key field.
Checking whether the http request status code is normal or not through a test script extension domain (200) shold; checking whether the service status code is normal or not by using the shield; the Should check json returns whether the key field accords with the expectation; and meanwhile, whether the returned value of the interface is matched with the field queried by the database or not can be judged. And finally cleaning test data generated in the test process through the operation database.
Examples
The embodiment adopts the automatic test method of the invention to test the software, and specifically comprises the following steps:
1. establishing a test item:
1. general principles of catalog management
The large hump mark has clear descriptive meaning following the path name.
2. Directory structure
Library of public custom libraries
Common resource files, keyword files and the like extracted from various directions of resources
Use cases of suites in all directions
-teardown initialization data, restore site
-publicOperation environment & account variables & request addresses
3. Catalog naming
The 3.1 name should be as descriptive as possible. Such as InterfaceTest, actionOperation, etc.;
3.2 large hump mark without symbol and no separation between words. Large hump method: the first letter of each word is capitalized. For example: firstName, lastName;
2. case management write specification
1. The name of the test case should be less than 40 characters;
2. the name of the test case should adopt a hump mode (capitalization of each initial letter and capitalization of other letters) for English;
3. the name must be readable and meaningful (by name it can be known what the test case is doing);
4. the document should be annotated according to the step of testing, and the condition information updated;
5. Giving each case the appropriate tags;
6. the tests should be independent;
7. the use of hard-coded object names should be avoided;
8. high level keywords should be packaged frequently instead of repeated steps;
3. keyword writing specification
1. The name must be readable and meaningful (by name it can be known what the method is doing);
2. hump naming is used;
3. the prefix/suffix is useful, for example, is to ask what 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: use, variable, returned value;
6. avoiding hard-coded object names;
7. the parameter should start with p, the return value should start with r, and the local variable should start with t;
8. the repeated method is not added;
9. can contain some program logic (for loop, if/else);
10. complex logic should be placed in class libraries instead of keywords;
11. important variables require annotations to be added later;
12. and setting detection points according to the emphasis points of the test cases. For example: e.g., check of the return code in the case execution result;
13. the detection points are set comprehensively. For example: on the premise of knowing the influence of the test operation, an important detection point is necessarily set
4. Variable writing specification
1. The variable name is not more than 20 characters;
2. variable names should be meaningful words;
3. named hump;
4. the parameters should start with p, the return values should start with r, the local variables should start with t, and the GUI variables should start with o;
5. the constants should all be capitalized. For example: the other type variables should be mixed types (lowercase uppercase);
6. script and global variables should be placed at the forefront of the script;
7. space and underlining may be used to improve legibility;
executing the software test1 to be tested under the directory of the user scene test case expansion domain (300) in an automatic mode, calling the test script in the test script expansion domain (200), directly calling the test script in the test script expansion domain (200) to an action interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103) in the defined sub-resource function domain (100), outputting different test reports according to the case step types and the case grades of the items, and simultaneously providing automatic case resource execution conditions, log analysis and resource out early warning for each specific activity and providing warning service for test cases which do not pass the test.
The test cases are monitored through log monitoring, overall condition overview is provided for project case execution, and summarized contents comprise single-interface request verification, script calling and different user scene test information which are developed by various automatic project activity types.
Under the directory of the expansion domain (300) of the test case of the user scene, the directory can be continuously created or the test set date file can be directly created, and the test case or the user keyword can be created under the test set;
the directory can be continuously created under the resource directory testSource or the resource file or the key word can be directly created, and the key word can be placed under the resource file.
The sub-resource functional domain (100) is connected with a certain server by creating a Session; initiating a request in a get or Post mode, and returning response content; through To Json: converting the return text into json objects; through Get From Dictionary: and acquiring a json character string key field.
Checking whether the http request status code is normal or not through a test script extension domain (200) shold; checking whether the service status code is normal or not by using the shield; the Should check json returns whether the key field accords with the expectation; and meanwhile, whether the returned value of the interface is matched with the field queried by the database or not can be judged. And finally cleaning test data generated in the test process through the operation database.
The invention also provides a full life cycle software automation testing device, which comprises a sub-resource functional domain construction module, a test script extension domain construction module, a user scene test case extension domain construction module and a test module;
the sub-resource functional domain construction module is used for setting a sub-resource functional domain (100), wherein the sub-resource functional domain (100) is used for defining resources, and splitting the called resource module, the called input-output rule and the resource keyword used in the automation project into an action operation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103);
the ActionOperation interface requests a resource module (101) for: creating a session, and transmitting URL (Uniform resource locator) parameters; assembling the input parameter data and processing the input parameter data into dictionary type parameters; according to the interface type, a post/get request is sent, and a parameter object is returned; transferring json strings to the returned parameter objects;
the DBoperation operation resource module (102) is configured to: the related information of the database is input through the keyword driving link database; inquiring, modifying, newly adding and deleting table data corresponding to the interface use case, and returning an operation result;
The PublicOperation common operation resource module (103) is configured to: packaging common keywords related to database operation, wherein the common keywords related to database operation comprise a linked Oracle database, database inquiry, database execution commands, database submitting commands and database connection disconnection commands; packaging public keywords required by initializing interface use cases; the package processing interface use case returns a public key word related to the data; defining various system resources, including URL addresses and aliases, account information, database connection information and message header information of various system services of various product lines;
the test script extension domain construction module is used for setting a test script extension domain (200), and the test script extension domain (200) completes the call management of the relation between the test script activities of each automation item by executing the following steps:
step a-1, importing an Actionoperation interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103), and initializing libraries required by an interface;
step a-2, designing corresponding parameter entering and checking fields by a test script; the corresponding test script returns interface json data by calling the request key words of the tested interface;
Step a-3, processing json data, obtaining key data returned by the interface, calling database operation related to the interface, obtaining the key data of the database, comparing the interface return value with the database return value through assertion, and if assertion is consistent, passing the test; if the data are inconsistent, returning to test failure, and terminating the operation of the test script;
the user scene test case expansion domain construction module is used for setting a user scene test case expansion 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 of test case design, setting an execution range through a case label for inheritance relation or mutual exclusion relation among automation project cases set in a user scene test case expansion domain (300), and supporting a custom label;
the user scene test case extension domain (300) can call a single test script or more than two test scripts;
the test module is used for constructing test items aiming at the software to be tested and generating reports, and comprises the following steps: executing the software test1 to be tested under the directory of the user scene test case expansion domain (300) in an automatic mode, calling a test script in the test script expansion domain (200), directly calling an action interface request resource module (101), a DBoperation operation resource module (102) and a PublicOperation public operation resource module (103) in a defined sub-resource function domain (100) by the test script in the test script expansion domain (200), outputting different test reports according to the use case type and the use case level of the project, simultaneously providing an automatic use case resource execution condition, log analysis and resource out early warning for each specific activity, and providing an alarm service for the test use case which fails the test;
The test cases are monitored through log monitoring, overall condition overview is provided for project case execution, and summarized contents comprise single-interface request verification, script calling and different user scene test information which are developed by various automatic project activity types.
As described above, according to the full life cycle software automation test device of the embodiment of the present application, the device may be implemented in various terminal devices, for example, a server of a distributed computing system. In one example, a full life cycle software automated test apparatus according to embodiments of the present application may be integrated into the terminal device as a software module and/or 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 automated test equipment may also be one of a plurality of hardware modules of the terminal device.
Alternatively, in another example, the automated test equipment and the terminal equipment may be separate terminal equipment, and the automated test equipment may be connected to the terminal equipment through a wired and/or wireless network and transmit the interaction information in a agreed data format.
As shown in fig. 3, the present application further provides an electronic device 10, including:
one or more processors 11 and a memory 12, the processor 11 may be a Central Processing Unit (CPU) or other form of processing unit having data processing 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) and/or cache memory (cache), and the like. The non-volatile memory may include, for example, read Only Memory (ROM), hard disk, flash memory, and the like. On which one or more computer program instructions may be stored that the processor 11 may execute to implement a full life cycle software automated testing method and/or other desired functions of the various embodiments of the present application described above.
In one example, the electronic device 10 may also include an input device 13 and an output device 14, which are interconnected by 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 to the outside, including the result of the automated test method, and the like. The output means 14 may comprise, for example, a display, speakers, a printer, and a communication network and remote output devices connected thereto, etc.
Of course, only some of the components of the electronic device 10 relevant to the present application are shown in fig. 3 for simplicity, components such as buses, input/output interfaces, etc. being omitted.
According to another aspect of the present application there is also provided a computer readable storage medium having stored thereon computer program instructions which, when executed by a computing device, are operable to perform an automated test method as described above.
The invention provides a full life cycle software automatic testing method and device, and the method and the way for realizing the technical scheme are numerous, the above is only the preferred implementation mode of the invention, and it should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the invention, and the improvements and modifications should be regarded as the protection scope of the invention. The components not explicitly described in this embodiment can be implemented by using the prior art.
Claims (2)
1. A full life cycle software automatic test method is characterized by comprising the following steps:
step 1, setting a sub-resource functional domain;
step 2, setting a test script extension domain;
step 3, setting an expansion domain of the user scene test case;
step 4, constructing a test item aiming at the software to be tested, and generating a report;
the step 1 comprises the following steps: setting a sub-resource functional domain, wherein the sub-resource functional domain is used for defining resources, splitting the resources of a calling resource module, a called input-output rule and a resource keyword used in an automation project into an action operation interface request resource module, a DBoperation operation resource module and a PublicOperation public operation resource module;
in step 1, the ActionOperation interface request resource module is configured to: creating a session, and transmitting URL and headers parameters; assembling the input parameter data and processing the input parameter data into dictionary type parameters; according to the interface type, a post/get request is sent, and a parameter object is returned; transferring json strings to the returned parameter objects;
in step 1, the DBOperation operation resource module is configured to: the related information of the database is input through the keyword driving link database; inquiring, modifying, newly adding and deleting table data corresponding to the interface use case, and returning an operation result;
In step 1, the PublicOperation public operation resource module is configured to: packaging common keywords related to database operation, wherein the common keywords related to database operation comprise a linked Oracle database, database inquiry, database execution commands, database submitting commands and database connection disconnection commands; packaging public keywords required by initializing interface use cases; the package processing interface use case returns a public key word related to the data; defining various system resources, including URL addresses and aliases, account information, database connection information and message header information of various system services of various product lines;
the step 2 comprises the following steps: setting a test script extension domain, wherein the test script extension domain completes the call management of the relation among the test script activities of each automation item by executing the following steps:
step 2-1, importing an action operation interface request resource module, a DBoperation operation resource module and a PublicOperation public operation resource module, and initializing libraries required by the interface;
step 2-2, designing corresponding parameter entering and checking fields by the test script; the corresponding test script returns interface json data by calling the request key words of the tested interface;
Step 2-3, processing json data to obtain key data returned by the interface, calling database operation related to the interface to obtain the key data of the database, comparing the interface return value with the database return value through assertion, and if assertion is consistent, passing the test; if the data are inconsistent, returning to test failure, and terminating the operation of the test script;
in step 3, the setting of the user scene test case extension domain includes the following steps:
step 3-1, configuring a test case template and associating a test script;
step 3-2, inputting test data and verification data of test case design, setting an execution range through a case label for inheritance relation or mutual exclusion relation among automation project cases set in a user scene test case expansion domain, and supporting a custom label;
in step 3, the user scene test case extension domain can call a single test script or more than two test scripts;
step 4 comprises: executing the software test1 to be tested under the user scene test case expansion domain directory in an automatic mode, calling a test script in the test script expansion domain, directly calling an action interface request resource module, a DBaction operation resource module and a publicaction public operation resource module in a defined sub-resource function domain by the test script in the test script expansion domain, outputting different test reports according to the case type and the case grade of the project, simultaneously providing an automatic case resource execution condition, log analysis and resource out early warning for each specific activity, and providing warning service for test cases which do not pass the test;
The test cases are monitored through log monitoring, overall condition overview is provided for project case execution, and summarized contents comprise single-interface request verification, script calling and different user scene test information which are developed by various automatic project activity types.
2. The full life cycle software automatic testing device is characterized by comprising a sub-resource functional domain construction module, a test script extension domain construction module, a user scene test case extension domain construction module and a test module;
the sub-resource functional domain construction module is used for setting a sub-resource functional domain, wherein the sub-resource functional domain is used for defining resources, splitting the called resource module, the called input-output rule and the resource keyword used in the automation project into an action interface request resource module, a DBoperation operation resource module and a PublicOperation public operation resource module;
the ActionOperation interface request resource module is used for: creating a session, and transmitting URL and headers parameters; assembling the input parameter data and processing the input parameter data into dictionary type parameters; according to the interface type, a post/get request is sent, and a parameter object is returned; transferring json strings to the returned parameter objects;
The DBoperation operation resource module is used for: the related information of the database is input through the keyword driving link database; 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 is used for: packaging common keywords related to database operation, wherein the common keywords related to database operation comprise a linked Oracle database, database inquiry, database execution commands, database submitting commands and database connection disconnection commands; packaging public keywords required by initializing interface use cases; the package processing interface use case returns a public key word related to the data; defining various system resources, including URL addresses and aliases, account information, database connection information and message header information of various system services of various product lines;
the test script extension domain construction module is used for setting a test script extension domain, and the test script extension domain completes the call management of the relation among the test script activities of each automation item by executing the following steps:
step a-1, importing an action operation interface request resource module, a DBoperation operation resource module and a PublicOperation public operation resource module, and initializing libraries required by the interface;
Step a-2, designing corresponding parameter entering and checking fields by a test script; the corresponding test script returns interface json data by calling the request key words of the tested interface;
step a-3, processing json data, obtaining key data returned by the interface, calling database operation related to the interface, obtaining the key data of the database, comparing the interface return value with the database return value through assertion, and if assertion is consistent, passing the test; if the data are inconsistent, returning to test failure, and terminating the operation of the test script;
the user scene test case expansion domain construction module is used for setting a user scene test case expansion domain, 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 of test case design, setting an execution range through a case label for inheritance relation or mutual exclusion relation among automation project cases set in a user scene test case expansion domain (300), and supporting a custom label;
the user scene test case extension domain can call a single test script or more than two test scripts;
The test module is used for constructing test items aiming at the software to be tested and generating reports, and comprises the following steps: executing the software test1 to be tested under the user scene test case expansion domain directory in an automatic mode, calling a test script in the test script expansion domain, directly calling an action interface request resource module, a DBaction operation resource module and a publicaction public operation resource module in a defined sub-resource function domain by the test script in the test script expansion domain, outputting different test reports according to the case type and the case grade of the project, simultaneously providing an automatic case resource execution condition, log analysis and resource out early warning for each specific activity, and providing warning service for test cases which do not pass the test;
the test cases are monitored through log monitoring, overall condition overview is provided for project case execution, and summarized contents comprise single-interface request verification, script calling and different user scene test information which are 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 CN111459793A (en) | 2020-07-28 |
| CN111459793B true 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) |
Families Citing this family (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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111459793A (en) | 2020-07-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10769228B2 (en) | Systems and methods for web analytics testing and web development | |
| CN102597993B (en) | Managing application state information by means of uniform resource identifier (URI) | |
| CN101697139A (en) | Method, device and registry for remote procedure call | |
| US20150089415A1 (en) | Method of processing big data, apparatus performing the same and storage media storing the same | |
| US20210117313A1 (en) | Language agnostic automation scripting tool | |
| CN110287069A (en) | ESB automatic interface testing method, server and computer readable storage medium | |
| CN109787974A (en) | Message data stream generating method, device, computer equipment and storage medium | |
| Groth et al. | A model of process documentation to determine provenance in mash-ups | |
| Zhou et al. | Confmapper: Automated variable finding for configuration items in source code | |
| CN111709026A (en) | Static security detection method and device, computer equipment and storage medium | |
| CN111459793B (en) | Full life cycle software automatic test method and device | |
| CN103326930A (en) | Automatic patrolling method and system for open platform interface | |
| CN113836014A (en) | Interface testing method and device, electronic equipment and storage medium | |
| CN113778897A (en) | Automatic test method, device, equipment and storage medium of interface | |
| CN113157554A (en) | Software automation question making test method and related equipment | |
| CN106201542B (en) | WOF rapid development platform | |
| WO2023151397A1 (en) | Application program deployment method and apparatus, device, and medium | |
| CN113434217B (en) | Vulnerability scanning method, vulnerability scanning device, computer equipment and medium | |
| CN116467156A (en) | Joint debugging test method and device, storage medium and electronic equipment | |
| Arora et al. | Mobile agent‐based regression test case generation using model and formal specifications | |
| US10817661B2 (en) | System architecture framework | |
| CN114371848A (en) | Page joint debugging method, device, equipment and storage medium | |
| CN114675989A (en) | Data verification method and device, electronic equipment and storage medium | |
| CN111400623A (en) | Method and apparatus for searching information | |
| CN113765731A (en) | Information processing method, device and computer readable 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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |