CN107092535B - Method and apparatus for data storage of test interface - Google Patents

Method and apparatus for data storage of test interface Download PDF

Info

Publication number
CN107092535B
CN107092535B CN201710253456.2A CN201710253456A CN107092535B CN 107092535 B CN107092535 B CN 107092535B CN 201710253456 A CN201710253456 A CN 201710253456A CN 107092535 B CN107092535 B CN 107092535B
Authority
CN
China
Prior art keywords
data
stored
interface
local
acquiring
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
Application number
CN201710253456.2A
Other languages
Chinese (zh)
Other versions
CN107092535A (en
Inventor
刘涛
唐远征
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Raxtone Software Co ltd
Original Assignee
Shanghai Raxtone Software Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Raxtone Software Co ltd filed Critical Shanghai Raxtone Software Co ltd
Priority to CN201710253456.2A priority Critical patent/CN107092535B/en
Publication of CN107092535A publication Critical patent/CN107092535A/en
Application granted granted Critical
Publication of CN107092535B publication Critical patent/CN107092535B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0787Storage of error reports, e.g. persistent data storage, storage using memory protection
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems

Abstract

The method comprises the steps of obtaining data to be stored for a test interface; acquiring a local folder according to the configuration file of the test interface; creating a local file in the local folder according to the environment where the request of the test interface is located and the port name; and formatting the data to be stored and storing the data in the local file. Therefore, the key data or the repeatedly used data are stored locally, the read-write function of a local file is realized, the data to be stored are formatted, the data are stored in a dictionary type, the data are read subsequently, and the corresponding value can be found through keys in the dictionary.

Description

Method and apparatus for data storage of test interface
Technical Field
The present application relates to the field of computers, and in particular, to a method and an apparatus for storing data of a test interface.
Background
With the development of the test industry, functional tests, performance tests and automatic tests successively appear, at present, the architecture of most of platforms is no longer the traditional MVC structure, the system continuously develops towards the directions of distribution, service centralization and high availability, the system architecture is numerous and complex nowadays, interfaces among systems are numerous and diverse, the traditional functional tests, performance tests and automatic tests are difficult to meet the requirements of system development, a more effective and practical test mode capable of being continuously carried out is urgently needed to ensure the quality of the system, the traditional interface tests mainly aim at the test of a single interface, linkage tests of a plurality of interfaces cannot be carried out, return data of a front interface cannot be transmitted, and the test and the quick iteration are difficult.
At present, Postman is an interface testing tool which can adapt to most service scenes, is convenient and quick, and a flow chart of an overall architecture idea is shown in fig. 1. The above-mentioned framework can't read and write the file, when calling the non-login interface each time, need to reacquire the new SID, the operation is complicated, convenient and fast and easy to make mistakes.
Content of application
An object of the present application is to provide a method and an apparatus for storing data of a test interface, which solve the problem in the prior art that critical data required by the test interface cannot be read and written locally.
According to an aspect of the present application, there is provided a method for data storage of a test interface, the method comprising:
acquiring data to be stored for a test interface;
acquiring a local folder according to the configuration file of the test interface;
creating a local file in the local folder according to the environment where the request of the test interface is located and the port name;
and formatting the data to be stored and storing the data in the local file.
Further, the step of storing the data to be stored in the local file after formatting the data to be stored includes:
and formatting the data to be stored into a dictionary type, and storing the dictionary type in the local file.
Further, obtaining a local folder according to the configuration file of the test interface includes:
acquiring a storage path of the data to be stored from a configuration file of the test interface;
and judging whether a local folder exists locally or not according to the storage path, if so, acquiring the local folder, and if not, generating the local folder corresponding to the configuration file.
Further, the data to be stored includes session unique identification information corresponding to the test interface.
Further, after the data to be stored is stored in the local file after being formatted, the method includes:
and acquiring session unique identification information corresponding to the test interface from the local file according to the account in the configuration file.
Further, before acquiring the session unique identification information corresponding to the test interface from the local file according to the account in the configuration file, the method includes:
if the test interface is a non-login interface, acquiring a request of the non-login interface;
determining a login interface to be called according to the request of the non-login interface;
and determining the configuration file according to the login interface to be called.
Further, acquiring session unique identification information corresponding to the test interface from the local file according to the account in the configuration file includes:
acquiring session unique identification information corresponding to the login interface to be called from the local file according to the account in the configuration file;
and taking the session unique identification information as the session unique identification for data transmission of the non-login interface.
Further, acquiring session unique identification information corresponding to the test interface from the local file according to the account in the configuration file includes:
acquiring a key value corresponding to the request of the test interface from the local file according to the account in the configuration file;
and determining a value corresponding to the key value in the dictionary according to the key value, and taking the determined value as the unique session identification information.
According to another aspect of the present application, there is also provided an apparatus for data storage of a test interface, the apparatus comprising:
the first acquisition device is used for acquiring data to be stored for the test interface;
the second acquisition device is used for acquiring a local folder according to the configuration file of the test interface;
the creating device is used for creating a local file in the local folder according to the environment where the request of the test interface is located and the port name;
and the storage device is used for formatting the data to be stored and then storing the data in the local file.
Further, the storage device is configured to:
and formatting the data to be stored into a dictionary type, and storing the dictionary type in the local file.
Further, the second obtaining device is configured to:
acquiring a storage path of the data to be stored from a configuration file of the test interface;
and judging whether a local folder exists locally or not according to the storage path, if so, acquiring the local folder, and if not, generating the local folder corresponding to the configuration file.
Further, the data to be stored includes session unique identification information corresponding to the test interface.
Further, the apparatus further comprises:
and the query device is used for acquiring the session unique identification information corresponding to the test interface from the local file according to the account in the configuration file.
Further, the apparatus comprises:
the request acquisition device is used for acquiring a request of the non-login interface if the test interface is the non-login interface;
the calling device is used for determining a login interface to be called according to the request of the non-login interface;
and the determining device is used for determining the configuration file according to the login interface to be called.
Further, the querying device is configured to:
acquiring session unique identification information corresponding to the login interface to be called from the local file according to the account in the configuration file;
and taking the session unique identification information as the session unique identification for data transmission of the non-login interface.
Further, the querying device is configured to:
acquiring a key value corresponding to the request of the test interface from the local file according to the account in the configuration file;
and determining a value corresponding to the key value in the dictionary according to the key value, and taking the determined value as the unique session identification information.
Compared with the prior art, the method and the device have the advantages that the data to be stored for the test interface are obtained; acquiring a local folder according to the configuration file of the test interface; creating a local file in the local folder according to the environment where the request of the test interface is located and the port name; and formatting the data to be stored and storing the data in the local file. Therefore, the key data or the repeatedly used data are stored locally, and the local file reading and writing function is realized. Further, the data to be stored is formatted, the data is stored in a dictionary type, and the corresponding value can be found out through a key in the dictionary after the data is subsequently read.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
FIG. 1 illustrates an architecture diagram of interface testing in the prior art;
FIG. 2 is a schematic diagram illustrating an interface architecture of an efficient hierarchical server side according to an embodiment of the present application;
FIG. 3 illustrates a method flow diagram for data storage of a test interface provided in accordance with an aspect of the subject application;
FIG. 4 is a flow chart illustrating data storage for a test interface in one embodiment of the present application;
FIG. 5 illustrates a schematic diagram of an apparatus for data storage of a test interface according to another aspect of the present application;
the same or similar reference numbers in the drawings identify the same or similar elements.
Detailed Description
The present application is described in further detail below with reference to the attached figures.
In a typical configuration of the present application, the terminal, the device serving the network, and the trusted party each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (transient media), such as modulated data signals and carrier waves.
FIG. 2 is a schematic diagram illustrating an interface architecture of an efficient hierarchical server side according to an embodiment of the present application; firstly, running a script, and loading an environment, a Uniform Resource Locator (URL), a port name, an account number, request parameters, an assertion condition and a structured query statement (SQL statement); loading a configuration file, taking out a session unique identifier (SID) stored in a local file according to an account, loading an encryption template to generate encryption information, automatically generating a legal message header (header) according to an incoming parameter, after requesting an interface, judging whether the interface correctly processes the request by analyzing the content returned by a server, if so, taking out the content of a message Body (Body), connecting a corresponding database when an SQL statement is incoming, executing the SQL statement, returning a query result, processing the query result into a JSON format, checking whether a corresponding value (value) is correct by traversing a key (key), if so, passing the test, and if not, outputting a test result of the local round; and when the taken Body content is not transmitted into the SQL statement, entering a static assertion flow, judging whether the result meets the service requirement through assertion conditions, if so, passing the test, if not, failing the test, judging whether other unexecuted cases exist, and if so, reading the next case for testing. And if the login is successful, the acquired SID stores a local file in a key value pair mode, the SID stored in the local file is taken out according to an account number, and the test process is executed. When the interface is not processed correctly and the SID is not expired, the error information is extracted, and if the result is an expected result, the test is successful.
Through the interface test architecture diagram shown in fig. 2, the problem of weak script universality is solved, and through the design of shallow encapsulation, template mode and the like of data and modules, after receiving an execution command, the script can automatically generate a parameter set corresponding to the execution command without manually configuring excessive parameters, so that quick and convenient execution is realized. The problem of locally reading and writing files is solved, the key data are stored to the local, the storage format is Dictionary (Dictionary), data are read in the later period, the corresponding value (value) can be found through a key (key), the problem that an external library cannot be introduced is solved, the encrypted data are directly returned to a calling function, the problem that the data cannot be read and written in the database is solved, the specified database can be connected to obtain or update test related data, the problem that the assertion mode is too single is solved, after the interface returned data and the database query data are obtained, whether the assertion interface data are accurate or not can be rapidly and massively judged in a key-value comparison mode, meanwhile, by using the framework, an Application Program Interface (API) can be opened for other tests or open frameworks, and expansion can be carried out.
The test mode using the interface architecture diagram shown in fig. 2 mainly includes local storage of critical or reusable data, and the function of local read/write is mainly embodied. The specific implementation mode is realized by the following embodiments:
fig. 3 shows a schematic flow chart of a method for storing data of a test interface according to an aspect of the present application, the method including: step S11-step S14, wherein in step S11, data to be stored for testing the interface is obtained; in step S12, a local folder is obtained according to the configuration file of the test interface; in step S13, a local file is created in the local folder according to the environment where the request of the test interface is located and the port name; in step S14, the data to be stored is formatted and stored in the local file. Therefore, the key data or the repeatedly used data are stored locally, and the local file reading and writing function is realized.
Specifically, in step S11, data to be stored for the test interface is acquired; the data to be stored is key data or reusable data for the test interface, and if the data can be stored locally, the data can be directly read from the local area during subsequent query, so that the call of the login interface is reduced, and the server resource is saved.
Specifically, in step S12, a local folder is obtained according to the configuration file of the test interface; after the data to be stored is acquired, the data needs to be stored locally, a local folder for storing the data to be stored is acquired according to a configuration file of a test interface, wherein the configuration file comprises a project name, an environment name, a login account number, a password, an address of a database, a host domain name, a client name, a local file storage path and the like.
Specifically, in step S13, a local file is created in the local folder according to the environment where the request of the test interface is located and the port name; here, the environment refers to a general term of computer hardware, software, network equipment, and historical data necessary for completing software testing work, the environment may be a testing environment, a development environment, or an environment of other applications, the created local file is a storage file format of data to be stored, for example, a text file, and different environments and port names may correspond to different names of text files, so as to correctly and quickly read the stored data in the subsequent process.
Specifically, in step S14, the data to be stored is formatted and stored in the local file. In an embodiment of the present application, the data to be stored is formatted into a dictionary type and stored in the local file, where the data to be stored is stored in the dictionary type, and the dictionary type is a key value pair manner to construct data, where a key (key) is an index and a value (value) is data that needs to be saved, so as to facilitate subsequent reading and updating.
Preferably, in step S12, a storage path of the data to be stored is obtained from a configuration file of the test interface; and judging whether a local folder exists locally or not according to the storage path, if so, acquiring the local folder, and if not, generating the local folder corresponding to the configuration file. In an embodiment of the application, the configuration file is read, a storage path of data to be stored is obtained from the configuration file, whether the path exists already is checked, if yes, a local folder is determined, if not, the local folder is generated, and files are uniformly stored in the folder, so that management and query are facilitated.
Preferably, the data to be stored includes session unique identification information corresponding to the test interface. In an embodiment of the present application, session unique identification information (SID) is a key and reusable data, and is used for the server to give an identifier to the user after logging in the interface, so as to prove that the user is a legitimate and logged-in user, and when the user requests another interface, the SID needs to be included in the user, and thus needs to be stored locally.
In an embodiment of the present application, after the data to be stored is formatted and stored in the local file, the method includes: step S15, obtaining session unique identification information corresponding to the test interface from the local file according to the account in the configuration file. The session unique identifier (SID) corresponding to the test interface is acquired according to the account in the configuration file and used for identifying the user, and the SID can be used as a legal certificate for calling the interface, so that repeated calling is avoided, and the safety of the server is ensured. It should be noted that the SID has a valid period, for example, a new SID is recorded at a certain time in the afternoon of the day, and the newly recorded SID can be acquired when the non-login interface is called in a day from the time, and the acquisition from the login interface does not need to be repeated. In fig. 2, parameters and encryption information for login are generated according to the environment and the request port, and after login is successful, since an SID which has not expired is stored locally, the SID is obtained from a local file according to an account in a configuration file for subsequent data communication.
In an embodiment of the present application, before acquiring, according to an account in the configuration file, session unique identification information corresponding to the test interface from the local file, the method includes: step S151, if the test interface is a non-login interface, acquiring a request of the non-login interface; step S152, determining a login interface to be called according to the request of the non-login interface; step S153, determining the configuration file according to the login interface to be called. Here, interfaces are divided into two main categories according to function: the login interface and the non-login interface, for example, in the ticket refunding process, "login interface-ticket purchasing interface-ticket refunding interface", wherein the ticket purchasing interface and the ticket refunding interface are non-login interfaces. The request of the non-login interface needs to be transmitted into the SID provided by the login interface as a reliable session mark, and subsequent data communication is carried out through the SID, so that the SID of the login interface to be used by the non-login interface needs to be determined according to the acquired request of the non-login interface, the login interface to be called is determined firstly, a configuration file is determined, and then the corresponding SID is acquired from a local file according to the configuration file.
Preferably, in step S15, obtaining session unique identification information corresponding to the login interface to be called from the local file according to the account in the configuration file; and taking the session unique identification information as the session unique identification for data transmission of the non-login interface. The process of acquiring the SID used by the above-mentioned non-login interface is specifically described by the following embodiments: acquiring a key value corresponding to the request of the test interface from the local file according to the account in the configuration file; and determining a value corresponding to the key value in the dictionary according to the key value, and taking the determined value as the unique session identification information.
In an embodiment of the application, the SID of the login interface is stored in a local file, the stored type is a dictionary type, the non-login interface extracts the SID corresponding to the local file through a determined key (key), wherein a value (value) corresponding to the key in the dictionary is the SID, so that repeated obtaining of the SID from the login interface is avoided, and the key is unique, the SID can be accurately read or updated, and meanwhile, server resources are saved.
To sum up, fig. 4 shows a flowchart for storing data of a test interface in an embodiment of the present application, where data (to-be-stored data) to be stored is transmitted to a local file generator, the local file generator reads a configuration file, obtains a corresponding storage path, and determines whether a local folder corresponding to the path and used for storing a local file exists, if not, the local folder is created, after the local folder already exists or is newly created, a text file is created according to a request environment and a port name, and then, the data to be stored is formatted by a formatting processor, so as to store the data in a dictionary type. Therefore, the problem of locally reading and writing files is solved, the key data or the repeatedly used data are stored to the local in a dictionary format, the subsequent data reading is carried out, the corresponding value can be found through the key in the dictionary, and the data related to the test can be obtained or updated.
Fig. 5 is a schematic diagram illustrating an apparatus for storing data of a test interface according to another aspect of the present application, where the apparatus includes: the device comprises a first acquisition device 11, a second acquisition device 12, a creation device 13 and a storage device 14, wherein the first acquisition device 11 is used for acquiring data to be stored for a test interface; the second obtaining device 12 is configured to obtain a local folder according to the configuration file of the test interface; the creating device 13 is configured to create a local file in the local folder according to the environment where the request of the test interface is located and the port name; and the storage device 14 is used for storing the data to be stored in the local file after formatting processing is performed on the data. Therefore, the key data or the repeatedly used data are stored locally, and the local file reading and writing function is realized.
FIG. 2 is a schematic diagram illustrating an interface architecture of an efficient hierarchical server side according to an embodiment of the present application; firstly, running a script, and loading an environment, a Uniform Resource Locator (URL), a port name, an account number, request parameters, an assertion condition and a structured query statement (SQL statement); loading a configuration file, taking out a session unique identifier (SID) stored in a local file according to an account, loading an encryption template to generate encryption information, automatically generating a legal message header (header) according to an incoming parameter, after requesting an interface, judging whether the interface correctly processes the request by analyzing the content returned by a server, if so, taking out the content of a message Body (Body), connecting a corresponding database when an SQL statement is incoming, executing the SQL statement, returning a query result, processing the query result into a JSON format, checking whether a corresponding value (value) is correct by traversing a key (key), if so, passing the test, and if not, outputting a test result of the local round; and when the taken Body content is not transmitted into the SQL statement, entering a static assertion flow, judging whether the result meets the service requirement through assertion conditions, if so, passing the test, if not, failing the test, judging whether other unexecuted cases exist, and if so, reading the next case for testing. And if the login is successful, the acquired SID stores a local file in a key value pair mode, the SID stored in the local file is taken out according to an account number, and the test process is executed. When the interface is not processed correctly and the SID is not expired, the error information is extracted, and if the result is an expected result, the test is successful.
Through the interface test architecture diagram shown in fig. 2, the problem of weak script universality is solved, and through the design of shallow encapsulation, template mode and the like of data and modules, after receiving an execution command, the script can automatically generate a parameter set corresponding to the execution command without manually configuring excessive parameters, so that quick and convenient execution is realized. The problem of locally reading and writing files is solved, the key data are stored to the local, the storage format is Dictionary (Dictionary), data are read in the later period, the corresponding value (value) can be found through a key (key), the problem that an external library cannot be introduced is solved, the encrypted data are directly returned to a calling function, the problem that the data cannot be read and written in the database is solved, the specified database can be connected to obtain or update test related data, the problem that the assertion mode is too single is solved, after the interface returned data and the database query data are obtained, whether the assertion interface data are accurate or not can be rapidly and massively judged in a key-value comparison mode, meanwhile, by using the framework, an Application Program Interface (API) can be opened for other tests or open frameworks, and expansion can be carried out.
The test mode using the interface architecture diagram shown in fig. 2 mainly includes local storage of critical or reusable data, and the function of local read/write is mainly embodied. The specific implementation manner is implemented by the device shown in fig. 5:
specifically, the first obtaining device 11 is configured to obtain data to be stored for the test interface; the data to be stored is key data or reusable data for the test interface, and if the data can be stored locally, the data can be directly read from the local area during subsequent query, so that the call of the login interface is reduced, and the server resource is saved.
Specifically, the second obtaining device 12 is configured to obtain a local folder according to the configuration file of the test interface; after the data to be stored is acquired, the data needs to be stored locally, a local folder for storing the data to be stored is acquired according to a configuration file of a test interface, wherein the configuration file comprises a project name, an environment name, a login account number, a password, an address of a database, a host domain name, a client name, a local file storage path and the like.
Specifically, the creating device 13 is configured to create a local file in the local folder according to the environment where the request of the test interface is located and the port name; here, the environment refers to a general term of computer hardware, software, network equipment, and historical data necessary for completing software testing work, the environment may be a testing environment, a development environment, or an environment of other applications, the created local file is a storage file format of data to be stored, for example, a text file, and different environments and port names may correspond to different names of text files, so as to correctly and quickly read the stored data in the subsequent process.
Specifically, the storage device 14 is configured to format the data to be stored and store the formatted data in the local file. In an embodiment of the present application, the data to be stored is formatted into a dictionary type and stored in the local file, where the data to be stored is stored in the dictionary type, and the dictionary type is a key value pair manner to construct data, where a key (key) is an index and a value (value) is data that needs to be saved, so as to facilitate subsequent reading and updating.
Preferably, the second obtaining device 12 is configured to obtain a storage path of the data to be stored from a configuration file of the test interface; and judging whether a local folder exists locally or not according to the storage path, if so, acquiring the local folder, and if not, generating the local folder corresponding to the configuration file. In an embodiment of the application, the configuration file is read, a storage path of data to be stored is obtained from the configuration file, whether the path exists already is checked, if yes, a local folder is determined, if not, the local folder is generated, and files are uniformly stored in the folder, so that management and query are facilitated.
Preferably, the data to be stored includes session unique identification information corresponding to the test interface. In an embodiment of the present application, session unique identification information (SID) is a key and reusable data, and is used for the server to give an identifier to the user after logging in the interface, so as to prove that the user is a legitimate and logged-in user, and when the user requests another interface, the SID needs to be included in the user, and thus needs to be stored locally.
In an embodiment of the present application, the apparatus includes: and the query device 15 is configured to, after the data to be stored is formatted and stored in the local file, obtain, according to the account in the configuration file, session unique identification information corresponding to the test interface from the local file. Here, a session unique identifier (SID) corresponding to the test interface is acquired according to an account in the configuration file to identify the user, and the SID can be used as a legal certificate for calling the interface, so that the security of the server is ensured. It should be noted that the SID has a valid period, for example, a new SID is recorded at a certain time in the afternoon of the day, and the newly recorded SID can be acquired when the non-login interface is called in a day from the time, and the acquisition from the login interface does not need to be repeated. In fig. 2, parameters and encryption information for login are generated according to the environment and the request port, and after login is successful, since an SID which has not expired is stored locally, the SID is obtained from a local file according to an account in a configuration file for subsequent data communication.
In an embodiment of the present application, the apparatus includes: a request obtaining device 151, configured to obtain a request of a non-login interface if the test interface is the non-login interface; a calling device 152, configured to determine a login interface to be called according to the request of the non-login interface; the determining device 153 is configured to determine the configuration file according to the login interface to be called. Here, interfaces are divided into two main categories according to function: the login interface and the non-login interface, for example, in the ticket refunding process, "login interface-ticket purchasing interface-ticket refunding interface", wherein the ticket purchasing interface and the ticket refunding interface are non-login interfaces. The request of the non-login interface needs to be transmitted into the SID provided by the login interface as a reliable session mark, and subsequent data communication is carried out through the SID, so that the SID of the login interface to be used by the non-login interface needs to be determined according to the acquired request of the non-login interface, the login interface to be called is determined firstly, a configuration file is determined, and then the corresponding SID is acquired from a local file according to the configuration file.
Preferably, the query device 15 is configured to obtain, from the local file, session unique identification information corresponding to the login interface to be called according to the account in the configuration file; and taking the session unique identification information as the session unique identification for data transmission of the non-login interface. The process of acquiring the SID used by the above-mentioned non-login interface is specifically described by the following embodiments: acquiring a key value corresponding to the request of the test interface from the local file according to the account in the configuration file; and determining a value corresponding to the key value in the dictionary according to the key value, and taking the determined value as the unique session identification information.
In an embodiment of the application, the SID of the login interface is stored in a local file, the stored type is a dictionary type, the non-login interface extracts the SID corresponding to the local file through a determined key (key), wherein a value (value) corresponding to the key in the dictionary is the SID, so that repeated obtaining of the SID from the login interface is avoided, and the key is unique, the SID can be accurately read or updated, and meanwhile, server resources are saved.
To sum up, fig. 4 shows a flowchart for storing data of a test interface in an embodiment of the present application, where data (to-be-stored data) to be stored is transmitted to a local file generator, the local file generator reads a configuration file, obtains a corresponding storage path, and determines whether a local folder corresponding to the path and used for storing a local file exists, if not, the local folder is created, after the local folder already exists or is newly created, a text file is created according to a request environment and a port name, and then, the data to be stored is formatted by a formatting processor, so as to store the data in a dictionary type. Therefore, the problem of locally reading and writing files is solved, the key data or the repeatedly used data are stored to the local in a dictionary format, the subsequent data reading is carried out, the corresponding value can be found through the key in the dictionary, and the data related to the test can be obtained or updated.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
It should be noted that the present application may be implemented in software and/or a combination of software and hardware, for example, implemented using Application Specific Integrated Circuits (ASICs), general purpose computers or any other similar hardware devices. In one embodiment, the software programs of the present application may be executed by a processor to implement the steps or functions described above. Likewise, the software programs (including associated data structures) of the present application may be stored in a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. Additionally, some of the steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.
In addition, some of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application through the operation of the computer. Program instructions which invoke the methods of the present application may be stored on a fixed or removable recording medium and/or transmitted via a data stream on a broadcast or other signal-bearing medium and/or stored within a working memory of a computer device operating in accordance with the program instructions. An embodiment according to the present application comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to perform a method and/or a solution according to the aforementioned embodiments of the present application.
It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is obvious that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. A plurality of units or means recited in the apparatus claims may also be implemented by one unit or means in software or hardware. The terms first, second, etc. are used to denote names, but not any particular order.

Claims (14)

1. A method for testing data storage of an interface, wherein the method comprises:
acquiring data to be stored for a test interface;
transmitting the data to be stored to a local file generator, and acquiring a storage path of the data to be stored from a configuration file of the test interface by using the local file generator;
judging whether a local folder exists locally or not according to the storage path, if so, acquiring the local folder, and if not, generating the local folder corresponding to the configuration file;
creating a local file in the local folder according to the environment where the request of the test interface is located and the port name;
and formatting the data to be stored and storing the data in the local file.
2. The method of claim 1, wherein the formatting the data to be stored and storing the data in the local file comprises:
and formatting the data to be stored into a dictionary type, and storing the dictionary type in the local file.
3. The method of claim 1, wherein the data to be stored comprises session unique identification information corresponding to the test interface.
4. The method of claim 3, wherein after the data to be stored is formatted and stored in the local file, the method comprises:
and acquiring session unique identification information corresponding to the test interface from the local file according to the account in the configuration file.
5. The method according to claim 4, wherein before acquiring the session unique identification information corresponding to the test interface from the local file according to the account in the configuration file, the method includes:
if the test interface is a non-login interface, acquiring a request of the non-login interface;
determining a login interface to be called according to the request of the non-login interface;
and determining the configuration file according to the login interface to be called.
6. The method according to claim 5, wherein acquiring session unique identification information corresponding to the test interface from the local file according to the account in the configuration file comprises:
acquiring session unique identification information corresponding to the login interface to be called from the local file according to the account in the configuration file;
and taking the session unique identification information as the session unique identification for data transmission of the non-login interface.
7. The method according to claim 2, wherein acquiring session unique identification information corresponding to the test interface from the local file according to the account in the configuration file comprises:
acquiring a key value corresponding to the request of the test interface from the local file according to the account in the configuration file;
and determining a value corresponding to the key value in the data to be stored of the dictionary type according to the key value, and taking the determined value as the unique session identification information.
8. An apparatus for testing a data store of an interface, wherein the apparatus comprises:
the first acquisition device is used for acquiring data to be stored for the test interface;
the second acquisition device is used for transmitting the data to be stored to a local file generator and acquiring a storage path of the data to be stored from the configuration file of the test interface by using the local file generator; judging whether a local folder exists locally or not according to the storage path, if so, acquiring the local folder, and if not, generating the local folder corresponding to the configuration file;
the creating device is used for creating a local file in the local folder according to the environment where the request of the test interface is located and the port name;
and the storage device is used for formatting the data to be stored and then storing the data in the local file.
9. The apparatus of claim 8, wherein the storage device is to:
and formatting the data to be stored into a dictionary type, and storing the dictionary type in the local file.
10. The device of claim 8, wherein the data to be stored comprises session unique identification information corresponding to the test interface.
11. The apparatus of claim 10, wherein the apparatus further comprises:
and the query device is used for acquiring the session unique identification information corresponding to the test interface from the local file according to the account in the configuration file.
12. The apparatus of claim 11, wherein the apparatus comprises:
the request acquisition device is used for acquiring a request of the non-login interface if the test interface is the non-login interface;
the calling device is used for determining a login interface to be called according to the request of the non-login interface;
and the determining device is used for determining the configuration file according to the login interface to be called.
13. The apparatus of claim 12, wherein the querying means is configured to:
acquiring session unique identification information corresponding to the login interface to be called from the local file according to the account in the configuration file;
and taking the session unique identification information as the session unique identification for data transmission of the non-login interface.
14. The apparatus of claim 12, the querying means to:
acquiring a key value corresponding to the request of the test interface from the local file according to the account in the configuration file;
and determining a value corresponding to the key value in the data to be stored of the dictionary type according to the key value, and taking the determined value as the unique session identification information.
CN201710253456.2A 2017-04-18 2017-04-18 Method and apparatus for data storage of test interface Active CN107092535B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710253456.2A CN107092535B (en) 2017-04-18 2017-04-18 Method and apparatus for data storage of test interface

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710253456.2A CN107092535B (en) 2017-04-18 2017-04-18 Method and apparatus for data storage of test interface

Publications (2)

Publication Number Publication Date
CN107092535A CN107092535A (en) 2017-08-25
CN107092535B true CN107092535B (en) 2020-06-19

Family

ID=59638579

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710253456.2A Active CN107092535B (en) 2017-04-18 2017-04-18 Method and apparatus for data storage of test interface

Country Status (1)

Country Link
CN (1) CN107092535B (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107995160A (en) * 2017-10-26 2018-05-04 常熟市第人民医院 A kind of JSON data packet encrypting and decrypting methods based on high in the clouds management and control
CN108683567B (en) * 2018-05-30 2021-12-07 郑州云海信息技术有限公司 Switch port fault testing method and system based on MCS and server
CN109739701A (en) * 2018-12-14 2019-05-10 北京奇安信科技有限公司 Interface test method and device
CN110046288A (en) * 2019-04-19 2019-07-23 新华三技术有限公司 The method and device of data is extracted from message body
CN110348217A (en) * 2019-05-28 2019-10-18 深圳壹账通智能科技有限公司 Interface test method, device, electronic equipment and storage medium
CN113434419A (en) * 2021-06-29 2021-09-24 青岛海尔科技有限公司 Interface test case assertion method and device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103237094A (en) * 2013-04-17 2013-08-07 北京亿赞普网络技术有限公司 Method and device for user identification
CN103701800A (en) * 2013-12-25 2014-04-02 贝壳网际(北京)安全技术有限公司 Cookie processing method, cookie processing device, browser and client
CN104009880A (en) * 2013-02-27 2014-08-27 阿里巴巴集团控股有限公司 Web test method, proxy server and Web test device
CN104410650A (en) * 2014-12-24 2015-03-11 四川金网通电子科技有限公司 Method for authenticating user based on Session and Cookie
CN105337949A (en) * 2014-08-13 2016-02-17 中国移动通信集团重庆有限公司 SSO (Single Sign On) authentication method, web server, authentication center and token check center

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104009880A (en) * 2013-02-27 2014-08-27 阿里巴巴集团控股有限公司 Web test method, proxy server and Web test device
CN103237094A (en) * 2013-04-17 2013-08-07 北京亿赞普网络技术有限公司 Method and device for user identification
CN103701800A (en) * 2013-12-25 2014-04-02 贝壳网际(北京)安全技术有限公司 Cookie processing method, cookie processing device, browser and client
CN105337949A (en) * 2014-08-13 2016-02-17 中国移动通信集团重庆有限公司 SSO (Single Sign On) authentication method, web server, authentication center and token check center
CN104410650A (en) * 2014-12-24 2015-03-11 四川金网通电子科技有限公司 Method for authenticating user based on Session and Cookie

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Http自动跳转Https的接口测试实践;臭臭爸爸;《https://www.cnblogs.com/appstest/p/4962336.html》;20151130;第1-2页 *

Also Published As

Publication number Publication date
CN107092535A (en) 2017-08-25

Similar Documents

Publication Publication Date Title
CN107122296B (en) Method and apparatus for data assertion for test interface
CN107122297B (en) Method and equipment for generating request message of test interface
CN107122258B (en) Method and equipment for checking state code of test interface
CN107092535B (en) Method and apparatus for data storage of test interface
US10949335B2 (en) Designer defined mocking service behavior
US10963370B2 (en) Default mock implementations at a server
US11561889B2 (en) Orchestration for automated performance testing
CN111818035B (en) Permission verification method and device based on API gateway
US20190138433A1 (en) Evaluation of library test suites using mutation testing
CN114091099A (en) Authority hierarchical control method, equipment and storage medium for business system
CN110688111A (en) Configuration method, device, server and storage medium of business process
CN112860507B (en) Control method and device for sampling rate of distributed link tracking system
CN113868698A (en) File desensitization method and equipment
CN113408254A (en) Page form information filling method, device, equipment and readable medium
CN113672233B (en) Server out-of-band management method, device and equipment based on Redfish
CN112395591A (en) Encryption method and system
CN112363944A (en) Method and equipment for comparing return values of multiple environment interfaces
CN108135000B (en) Authentication method and equipment
CN112632211A (en) Semantic information processing method and equipment for mobile robot
CN112153061A (en) Data access method, device, equipment and computer readable storage medium
CN111427863A (en) Data migration method, device and equipment based on domain model
CN112799952A (en) Method and equipment for automatically testing cloud platform account system authority
CN114039873B (en) Audit method and operation and maintenance security audit system aiming at client type
Kirsan et al. Improved access speed of the Codeigniter framework and REST APIs for the implementation of SIAKAD: Academic information system in Balikpapan schools
CN117251384B (en) Interface automation test case generation method and system

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