CN111858223A

CN111858223A - Method, device, equipment and storage medium for testing storage service interface

Info

Publication number: CN111858223A
Application number: CN202010598628.1A
Authority: CN
Inventors: 程锦; 王晓
Original assignee: Beijing Kingsoft Cloud Network Technology Co Ltd
Current assignee: Beijing Kingsoft Cloud Network Technology Co Ltd
Priority date: 2020-06-28
Filing date: 2020-06-28
Publication date: 2020-10-30

Abstract

The invention discloses a method, a device, equipment and a storage medium for testing a storage service interface. Wherein, the method comprises the following steps: determining a target file name, determining a service test request according to the target file name and a service interface of the storage service, sending the service test request to the storage service, receiving a service parameter returned by the service interface of the storage service, and evaluating the service parameter through a corresponding preset test unit according to the type of the service test request to obtain a test result of the storage service interface. By the method, the dimension of the robustness of the storage service interface can be effectively enriched, and the accuracy of the test result is improved.

Description

Method, device, equipment and storage medium for testing storage service interface

Technical Field

The present invention relates to the field of computers, and more particularly, to a method for testing a storage service interface, an apparatus for testing a storage service interface, an electronic device, and a computer-readable storage medium.

Background

The object storage service is low in cost and capable of providing massive, safe and highly reliable cloud storage services. Currently, in order to ensure that the object storage service can provide a stable and good storage service for a user, it is generally required to test the robustness of an interface of the object storage service.

In the related art, when the robustness of the interface of the object storage service is tested, an http request is usually encapsulated by a curl command or a postman command, and the robustness of the interface of the object storage service is evaluated by response information of the http request to complete the test.

However, when the robustness of the interface of the object storage service is tested at present, the testing dimension is single, and the accuracy of the testing result is poor.

Disclosure of Invention

It is an object of the present invention to provide a new solution for testing storage service interfaces.

According to a first aspect of the present invention, there is provided a method of testing a storage service interface, the method comprising:

determining a target file name;

determining a service test request based on the target file name and a service interface of the storage service;

receiving service parameters returned by the service interface of the storage service in response to the service test request;

and evaluating the service parameters through a corresponding preset test unit according to the type of the service test request to obtain a test result of the storage service interface.

Optionally, determining the target file name includes:

acquiring a pre-stored test character set, wherein the test character set comprises characters of various character types;

Extracting N characters from the test character set and combining the N characters to obtain at least one character string, wherein N is a positive integer;

and determining the at least one character string as a target file name.

Optionally, the method further includes:

writing the target file name to a test queue to obtain the target file name from the test queue before determining a service test request based on the target file name and a service interface of a storage service.

Optionally, determining a service test request based on the target file name and a service interface of the storage service includes:

determining a service test request of a write type based on the target file name and a write interface of the storage service; and/or

Determining a service test request of a reading type based on the target file name and a reading interface of the storage service; and/or

And determining a service test request of a deletion type based on the target file name and a deletion interface of the storage service.

Optionally, the method further includes:

writing a write type service test request, a read type service test request, and/or a delete type service test request to a service test request queue.

Optionally, the type of the service test request is a write type, and the service parameter is a first return code;

According to the type of the service test request, evaluating the service parameters through a corresponding preset test unit to obtain a test result of the storage service interface, wherein the test result comprises the following steps:

determining the number of first return codes containing the writing interface available identification;

and determining whether the writing interface is available according to the number of the first return codes containing the writing interface available identification and the number of the target file names.

Optionally, the type of the service test request is a read type, and the service parameter is a second return code;

determining the number of second return codes containing the available identifiers of the reading interface;

determining the number of target file names corresponding to a first return code containing the available identifier of the write interface;

and determining whether the reading interface is available according to the number of the second return codes containing the reading interface available identification and the number of the target file names corresponding to the first return codes containing the writing interface available identification.

Optionally, the service parameter is a first returning body;

determining the number of first returned volumes containing valid data;

and determining whether the semantics of the writing interface are correct or not according to the number of the first return bodies containing the valid data and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface.

Optionally, the evaluating the service parameter through a corresponding preset test unit according to the type of the service test request to obtain a test result of the storage service interface includes:

determining the number of first returned volumes containing correct valid data;

and determining whether the writing interface is reliable or not according to the number of the first return bodies containing the correct and valid data and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface, wherein the correct and valid data are consistent with the data of the corresponding target files.

Optionally, determining the first returning body containing the correct and valid data includes:

determining a hash value of effective data according to the effective data carried in the first return body;

determining a hash value of the data of the target file according to the data of the target file corresponding to the first returned body;

and under the condition that the hash value of the valid data is consistent with the hash value of the data of the target file, determining that the first returning body contains correct valid data.

Optionally, the type of the service test request is a deletion type, and the service parameter is a third return code;

determining the number of third return codes containing the usable identifier of the deleted interface;

and determining whether the deleting interface is available according to the number of the third return codes containing the available identifiers of the deleting interface and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface.

Optionally, the service parameter is a second returning body;

determining the number of second returning bodies which represent that the target file to be deleted does not exist;

and determining whether the semantics of the deletion interface is correct or not according to the number of the second return bodies which represent that the target file to be deleted does not exist and the number of the target file names corresponding to the first return codes containing the usable identifiers of the write-in interface.

According to a second aspect of the present invention, there is provided an apparatus for testing a storage service interface, the apparatus comprising:

the first determining module is used for determining a target file name;

the second determining module is used for determining a service test request based on the target file name and a service interface of the storage service;

the receiving module is used for receiving the service parameters returned by the service interface of the storage service responding to the service test request;

and the test module is used for evaluating the service parameters through a corresponding preset test unit according to the type of the service test request so as to obtain a test result of the storage service interface.

According to a third aspect of the invention, there is provided an electronic device comprising the apparatus of the second aspect; or,

comprising a memory for storing computer instructions and a processor for invoking the computer instructions from the memory for performing the method according to any of the first aspects.

According to a fourth aspect of the present invention, there is provided a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method according to any one of the first aspects.

In this embodiment, a target file name is determined, a service test request is determined according to the target file name and a service interface of a storage service, the service test request is sent to the storage service, a service parameter returned by the service interface of the storage service is received, and the service parameter is evaluated through a corresponding preset test unit according to the type of the service test request, so as to obtain a test result of the storage service interface. Therefore, compared with the prior art, the method for testing the storage service interface provided by the embodiment increases the test of semantic correctness of the storage service interface, enriches the dimension for testing the robustness of the storage service interface, and improves the accuracy of the test result.

Other features of the present invention and advantages thereof will become apparent from the following detailed description of exemplary embodiments thereof, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention.

FIG. 1 is a block diagram of a hardware configuration of an electronic device implementing a method for testing a storage service interface according to an embodiment of the present invention;

FIG. 2 is a flow chart of a method for testing a storage service interface according to an embodiment of the present invention;

FIG. 3 is a flowchart of a method for determining a target file name according to an embodiment of the present invention;

FIG. 4 is a flow chart of testing the availability of a write interface according to an embodiment of the present invention;

FIG. 5 is a flowchart illustrating a method for testing semantic correctness of a write interface according to an embodiment of the present invention;

FIG. 6 is a flow chart of testing reliability of a write interface according to an embodiment of the present invention;

FIG. 7 is a flow chart of testing the availability of a read interface according to an embodiment of the present invention;

FIG. 8 is a flow chart of testing the availability of a delete interface according to an embodiment of the present invention;

FIG. 9 is a flowchart of testing semantic correctness of a delete interface according to an embodiment of the present invention;

FIG. 10 is a schematic diagram of another method for testing a storage service interface according to an embodiment of the invention;

FIG. 11 is a schematic structural diagram of an apparatus for testing a storage service interface according to an embodiment of the present invention;

fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that: the relative arrangement of the components and steps, the numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present invention unless specifically stated otherwise.

The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses.

Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate.

In all examples shown and discussed herein, any particular value should be construed as merely illustrative, and not limiting. Thus, other examples of the exemplary embodiments may have different values.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.

Currently, a user typically pays for purchasing or using a storage service provided by a cloud service provider. Before using the storage service provided by the cloud service provider, the user typically tests the robustness of the interface of the storage service provided by the cloud service provider to determine whether the interface of the storage service provided by the cloud service provider meets the user's requirements or is consistent with the performance of the interface of the storage service promised by the cloud service provider. Based on this, the present embodiment provides a method capable of testing a storage service interface with a higher dimension.

< hardware configuration >

Fig. 1 is a block diagram of a hardware configuration of an electronic device that implements a method for testing a storage service interface according to an embodiment of the present invention.

The electronic device 1000 may generally be a laptop, desktop, tablet, etc.

The electronic device 1000 may include a processor 1100, a memory 1200, an interface device 1300, a communication device 1400, a display device 1500, an input device 1600, a speaker 1700, a microphone 1800, and so forth. The processor 1100 may be a central processing unit CPU, a microprocessor MCU, or the like. The memory 1200 includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device 1300 includes, for example, a USB interface, a headphone interface, and the like. Communication device 1400 is capable of wired or wireless communication, for example. The display device 1500 is, for example, a liquid crystal display panel, a touch panel, or the like. The input device 1600 may include, for example, a touch screen, a keyboard, and the like. A user can input/output voice information through the speaker 1700 and the microphone 1800.

Although a plurality of devices are shown in fig. 1 for each of the electronic devices 1000, the present invention may relate to only some of the devices, for example, the electronic device 1000 may relate to only the memory 1200 and the processor 1100.

In an embodiment of the present invention, the memory 1200 of the electronic device 1000 is used for storing instructions for controlling the processor 1100 to execute the method for testing the storage service interface according to the embodiment of the present invention.

In the above description, the skilled person will be able to design instructions in accordance with the disclosed solution. How the instructions control the operation of the processor is well known in the art and will not be described in detail herein.

< method examples >

The embodiment provides a method for testing a storage service interface, as shown in fig. 2, the method includes the following steps:

s201: the target file name is determined.

In this embodiment, since the present invention needs to test the robustness of the storage service interface, it is necessary to create an object file for testing the storage service interface.

Here, the target file name is a file name of the target file.

S202: and determining a service test request based on the target file name and a service interface of the storage service.

In this embodiment, since the service interfaces of the storage service are of multiple types, and the different types of service interfaces can only receive a specific type of service test request, that is, the types of the service interfaces are different, the types of the service test requests that can be received are also different, for example, the type of the service interface is a write type, and the type of the received service test request is a write type.

S203: and receiving the service parameters returned by the service interface of the storage service responding to the service test request.

In this implementation, after the service test request is determined, the determined service test request is sent to a service interface of the storage service, and the service interface responds to the service test request, generates a service parameter corresponding to the service test request, and returns the service parameter to the electronic device.

It should be noted here that the types of service interfaces are different, and the returned service parameters are also different. The service parameters can reflect the robustness of the service interface of the storage service, and are used for evaluating the robustness of the service interface of the storage service.

S204: and evaluating the service parameters through a corresponding preset test unit according to the type of the service test request to obtain a test result of the storage service interface.

In this embodiment, the types of the service test requests may be write-type service test requests, read-type service test requests, and delete-type service test requests, and for different types of service test requests and corresponding service parameters thereof, the corresponding preset test unit is determined, and the service parameters are evaluated by the corresponding preset test unit, so as to obtain a test result of robustness of the storage service interface.

Through the method, the method for testing the storage service interface provided by the embodiment increases the test of the semantic correctness of the storage service interface, enriches the dimension for testing the robustness of the storage service interface, and improves the accuracy of the test result.

On the basis of the foregoing embodiment, the method for testing a storage service interface provided in this embodiment further includes a step of determining a target file name, as shown in fig. 3, where the step includes:

s301, a pre-stored test character set is obtained.

The test character set comprises characters of various character types, and specifically comprises a symbolic character subset, an alphanumeric character subset, an encoding character subset and a custom character subset.

In this embodiment, the characters included in the symbol character subset may be exemplarily: "! "," @ "," # "," $ "," & ","% "," ", etc.

The characters in the alphanumeric character subset may be exemplified by: "1", "2", "3", "a", "b", "c", "D", etc.

The characters included in the subset of code characters may illustratively be code characters obtained by a coding algorithm. Wherein, the coding algorithm may be Base 64.

The characters included in the custom character subset may illustratively be user-defined characters, such as custom patterns, and the like.

S302, extracting N characters from the test character set and combining the N characters to obtain at least one character string, wherein N is a positive integer.

S303: and determining the at least one character string as a target file name.

In this embodiment, each of the at least one character string obtained based on the above S302 is used as a name corresponding to each of the at least one unnamed target file set. The unnamed target file can be a picture, a word document, audio, video and the like.

In an embodiment, the specific implementation of S302 may be: and randomly extracting characters from the test character set and randomly combining the characters to obtain at least one character string within a preset length range.

In addition, the method for testing the storage service interface provided by the embodiment can also process unnamed target files. Illustratively, the processing may be specifically: in the case where the unnamed target file is a picture, a watermark may be added to the picture, the size of the picture may be adjusted, and the like. The unnamed target files are word documents, audio, videos and the like, and the word documents, the audio, the videos and the like can be compressed.

In this embodiment, since the names of the target files for testing the storage service interface are all obtained by randomly extracting characters from the test character set and randomly combining the characters, the naming of the target files is normal or not normal. Therefore, the storage service interface can be tested by using the target file with naming diversity, and the finally obtained test result is more global.

In addition, the electronic device 1000 obtains an emphasized test character set, which includes characters that are most frequently used by the user when naming the file when using the storage service. Therefore, the storage service interface can be tested by using the target file with the targeted naming, so that the finally obtained test result has the targeting property.

Further, after determining the target file name, the embodiment may write the determined target file name into the test queue, so as to obtain the target file name from the test queue before performing the step S202 of determining the service test request based on the target file name and the service interface of the storage service.

In step S202, a service test request is determined based on the target file name and the service interface of the storage service, and specifically, the following three types of service test requests may be determined according to the actual service interface type:

determining a service test request of a write type based on the target file name and a write interface of the storage service; and/or determining a service test request of a reading type based on the target file name and a reading interface of the storage service; and/or determining a service test request of a deletion type based on the target file name and a deletion interface of the storage service.

It should be noted that, in this embodiment, after the three types of test service requests are determined, the write-type service test request, the read-type service test request, and/or the delete-type service test request are written into the service test request queue, and then the service test requests may be responded from the service test request queue in the order of arrangement.

In step S204, the present embodiment provides the following way to test the robustness of each type of service interface for three types of service interfaces.

Testing the robustness of the write interface of the storage service, as shown in FIG. 4:

s401: and determining a service test request of a writing type based on the target file name and a writing interface of the storage service.

The electronic device 1000 generates a corresponding write-type service test request according to the file name and the file content of each target file in the target file set and the write request format defined by the storage service write interface, and sequentially inputs the generated write-type service test request to the write interface of the storage service, so that the storage service writes each target file in the target file set.

S402: and receiving the service parameters returned by the write interface of the storage service in response to the write-type service test request.

Wherein the service parameter comprises a first return code.

In this embodiment, after the write interface receives the service test request of the write type, the storage service performs a write operation on a target file corresponding to the service test request of the write type, and outputs a corresponding service parameter through the write interface. Wherein a service parameter comprises a return code. In this embodiment, for clear distinction, the return code included in the service parameter is referred to as a first return code.

In this embodiment, the storage service defines a first return code returned by the write interface, so that whether the write interface of the storage service is available for the write-type service test request can be reflected by the first return code, that is, whether the write interface of the storage service writes the target file corresponding to the write-type service test request can be reflected by the first return code.

In one embodiment, the definition of the first return code of the write interface by the storage service may specifically be: when the first return code is at the beginning of "5", it is described that the write interface of the storage service is unavailable to the input write-type service test request, that is, that the write interface of the storage service is unavailable to write the target file corresponding to the input write-type service test request. When the first return code is not a "5" start, it is described that the storage service is available for the write-type service test request input to the write interface, that is, the write interface of the storage service is writable to the target file corresponding to the input write-type service test request, and as can be seen from the above description, the first return code "5" start is a write interface available identifier, and the first return code is not a "5" start is a write interface unavailable identifier.

Based on the above, it can be determined whether the first return code of each service parameter belongs to the available type of the first return code defined by the write interface according to the concrete embodiment of the first return code. Specifically, when the first return code is the beginning of "5", it is described that the first return code belongs to the first return code of the unusable type defined by the write interface. In the case that the first return code is not beginning with "5", the first return code is described as belonging to the first return code of the available type defined by the write interface, and it can be seen that the number "5" at the beginning of the first return code is the write interface available identifier, and the number not "5" is the write interface unavailable identifier.

S403: and determining the number of the first return codes containing the writing interface available identification, and determining whether the writing interface is available according to the number of the first return codes containing the writing interface available identification and the number of the target file names.

In this embodiment, step S403 is specifically implemented as: and determining the number of the first return codes containing the available marks of the writing interface, and determining whether the writing interface is available according to the size relation between the number of the first return codes containing the available marks of the writing interface and the number of the target file names and a first preset value. Specifically, the write interface is determined to be unavailable when the ratio of the number of the first return codes containing the available marks of the write interface to the number of the target file names is smaller than a first preset value. And determining that the writing interface is available under the condition that the ratio of the number of the first return codes containing the writing interface available identification to the number of the target file names is larger than or equal to a first preset value.

Wherein, the first preset value is a decimal which is less than 1 and close to 1. For example, the first preset value is 0.999. In this embodiment, the first preset value may be an expected value of the availability of the write interface of the storage service for the user, and may also be a commitment value of the availability of the write interface of the storage service for the storage service provider.

In addition, in the event that it is determined that the write interface is not available, the electronic device 1000 may issue a corresponding alert message to prompt the user that the write interface is not available. In this way, the user may know which target files the write interface is unavailable to, and may analyze the reasons for the unavailability, such as unavailability due to the naming of the target files, etc.

Based on the above description of the first return code, the target file corresponding to the first return code belonging to the available type defined by the write interface is written into the storage service through the write interface of the storage service.

By the method, the robustness of the write interface of the storage service can be tested, specifically, the availability of the robustness of the write interface is tested, and whether the semantics of the write interface included in the robustness of the write interface are correct or not needs to pass through the steps shown in fig. 5.

S501: and determining a service test request of a reading type based on the target file name and a reading interface of the storage service.

A read request to read each target file in the set of target files is input to a read interface of the storage service to read each target file by the storage service.

The target file set comprises a plurality of target files, and each target file is written into the storage service through a writing interface of the storage service in advance.

In one embodiment, the storage service may be an object storage service, but may also be other storage services, such as a block storage service, and the like.

S502: and receiving the service parameters returned by the reading interface of the storage service responding to the service test request of the reading type.

Wherein the service parameter comprises a first returnbody.

In this embodiment, after the reading interface receives the service test request of the reading type, the storage service performs a reading operation on the target file corresponding to the service test request of the reading type, and outputs the corresponding service parameter through the reading interface. Wherein a service parameter comprises a returnable body. In the present embodiment, for clear distinction, a returnbody included in the service parameter output through the reading interface is referred to as a first returnbody.

S503: the number of first returns containing valid data is determined.

The first returning body is used for reflecting the specific content read by the storage service under the condition of reading the target file corresponding to the service test request of the reading type, namely the read effective data. It should be noted that there is a field corresponding to valid data in the first return body, and if there is data in the field, it indicates that there is valid data in the return body. Correspondingly, if no data exists in the field, the fact that valid data does not exist in the return body is indicated. As can be seen from the above, valid data refers to whether data exists in a field, and the correctness of the data in the field is not concerned.

S504: and determining the number of target file names corresponding to the first return code containing the writing interface available identification.

In this embodiment, the number of the target file names corresponding to the first return code containing the write-in interface available identifier refers to the number of the target files actually and successfully written into the storage service in the process of writing the target files into the storage service, and if the target files are not successfully written into the storage service, the service parameter returned by the storage service is the first return code containing the write-in interface unavailable identifier.

S505: and determining whether the semantics of the writing interface are correct or not according to the number of the first return bodies containing the valid data and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface.

In this embodiment, the specific implementation of S504 is: and determining whether the semantics of the writing interface is correct or not according to the size relation between the ratio of the number of the first return bodies containing the valid data to the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface and a second preset value. Specifically, the method comprises the following steps: and determining that the semantics of the writing interface are incorrect under the condition that the ratio of the number of the first returning bodies containing the valid data to the number of the target file names corresponding to the first returning codes containing the available marks of the writing interface is less than a second preset value. And determining that the semantics of the writing interface are correct under the condition that the ratio of the number of the first return bodies containing the valid data to the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface is greater than or equal to a second preset value.

Wherein the second preset value is a decimal less than 1 and close to 1. For example, the first preset value is 0.999. In this embodiment, the second preset value may be an expected value of semantics of a write interface of the storage service by a user.

In addition, in the event that the semantics of the write interface are determined to be incorrect, the electronic device 1000 may issue a corresponding alert message to prompt the user that the semantics of the write interface are incorrect.

By the method, the robustness of the write interface of the storage service can be tested, specifically, whether the semantics of the write interface included in the robustness of the write interface are correct is tested, and the reliability of the write interface included in the robustness of the write interface needs to pass through the steps shown in fig. 6.

S601: and determining a service test request of a reading type based on the target file name and a reading interface of the storage service.

S602: and receiving the service parameters returned by the reading interface of the storage service responding to the service test request of the reading type.

Wherein the service parameter comprises a first returnbody.

S603: the number of first returns containing valid data is determined.

The correct valid data is valid data that is consistent with the data of the corresponding target file, that is, the correct valid data is consistent with the data of the corresponding target file.

As can be seen from the above, unlike the valid data in step S503, the correct valid data in this step does not only refer to whether or not data exists in the field, and the need of the data in the field is consistent with the data of the corresponding target file.

S604: and determining the number of target file names corresponding to the first return code containing the writing interface available identification.

S605: and determining whether the writing interface is reliable or not according to the number of the first return bodies containing the correct and valid data and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface.

In this embodiment, the foregoing S605 is implemented specifically as: and determining whether the writing interface is reliable or not according to the size relation between the ratio of the number of the first return bodies containing the correct and valid data to the number of the target file names corresponding to the first return codes containing the available marks of the writing interface and a third preset value. Specifically, the write interface is determined to be unreliable under the condition that the ratio of the number of the first return bodies containing correct and valid data to the number of the target file names corresponding to the first return codes containing the available identifiers of the write interface is smaller than a third preset value. And under the condition that the ratio of the number of the first return bodies containing the correct and valid data to the number of the target file names corresponding to the first return codes containing the available marks of the writing interface is greater than or equal to a third preset value, determining that the writing interface is unreliable.

Wherein the third preset value is a decimal less than 1 and close to 1. For example, the third preset value is 0.999. In this embodiment, the third preset value may be an expected value of the reliability of the write interface of the storage service by the user, and may also be a commitment value of the reliability of the write interface of the storage service by the storage service provider.

It should be noted that this embodiment provides an implementation manner of determining the first returning volume containing correct and valid data, which is specifically as follows:

determining a hash value of effective data according to the effective data carried in the first return body; determining a hash value of the data of the target file according to the data of the target file corresponding to the first returned body; and under the condition that the hash value of the valid data is consistent with the hash value of the data of the target file, determining that the first returning body contains correct valid data.

In this embodiment, the electronic device 1000 performs md5 operation on the valid data in each first returning volume to obtain an md5 value corresponding to the valid data in the first returning volume. And simultaneously carrying out md5 operation on the data of the target file corresponding to each first returned body to obtain the md5 value of the data of the corresponding target file. And then comparing the md5 value corresponding to each first retuning body with the md5 value of the matched target file to determine whether the md5 value is the same, and if the md5 value is the same, determining that the corresponding first retuning body contains correct and valid data.

In the embodiment, the first returning body containing correct and valid data is determined by comparing md5 values, so that the data amount of the operation can be reduced, and the calculation speed is improved.

In addition, the specific implementation manner of the step of determining the first returning body containing the correct and valid data may also be: performing hash operation on the effective data in each first return body, and determining a hash value corresponding to the effective data in the first return body; performing hash operation on the data of the target file corresponding to each first return body, and determining the hash value of the data of the corresponding target file; and under the condition that the hash value of the effective data corresponding to the first returning body is the same as the hash value of the data corresponding to the target file, determining that the corresponding first returning body is the returning body containing correct effective data.

It should be noted that, the specific implementation of the step of determining the first returning volume containing the correct valid data is not limited.

By the method, the robustness of the write interface of the storage service can be tested, and particularly whether the write interface included in the robustness of the write interface is reliable or not can be tested.

The robustness of the read interface of the storage service is tested as shown in FIG. 7:

S701: and determining a service test request of a reading type based on the target file name and a reading interface of the storage service.

S702: and receiving the service parameters returned by the reading interface of the storage service responding to the service test request of the reading type.

Wherein the service parameter comprises a second return code.

In this embodiment, after the reading interface receives the service test request of the reading type, the storage service performs a reading operation on the target file corresponding to the service test request of the reading type, and outputs the corresponding service parameter through the reading interface. Wherein a service parameter comprises a return code. In this embodiment, for clear distinction, the return code included in the service parameter output through the reading interface is referred to as a second return code.

In one embodiment, the definition of the second return code of the read interface by the storage service may specifically be: when the second return code is at the beginning of "5", it means that the read interface of the storage service is not available for the input read-type service test request, that is, the read interface of the storage service cannot read out the target file corresponding to the input read-type service test request. In the case that the second return code is not a "5" start, the storage service is described as being available for the read-type service test request input by the read interface, that is, the read interface of the storage service is described as being readable for the target file corresponding to the input read-type service test request.

Based on the above, it can be determined whether the second return code in each service parameter belongs to the available type of second return code defined by the reading interface according to the specific content of the second return code. Specifically, in the case where the second return code is the beginning of "5", it is described that the second return code belongs to the available type of the read interface definition. In the case where the second return code is not a "5" start, it is described that the second return code belongs to the first return code of the unusable type defined by the reading interface. As can be seen from the above, the number "5" at the beginning of the second return code is the identifier available to the reading interface, and the number not "5" is the identifier unavailable to the reading interface.

S703: the number of second return codes containing an identification available to the reading interface is determined.

S704: and determining the number of target file names corresponding to the first return code containing the writing interface available identification.

S705: and determining whether the reading interface is available according to the number of the second return codes containing the reading interface available identification and the number of the target file names corresponding to the first return codes containing the writing interface available identification.

In this embodiment, the specific implementation of S705 above is: and determining whether the reading interface is available according to the size relationship between the ratio of the number of the second return codes containing the available identification of the reading interface to the number of the target file names corresponding to the first return codes containing the available identification of the writing interface and a fourth preset value. Specifically, the ratio of the number of the second return codes containing the available reading interface identifiers to the number of the target file names corresponding to the first return codes containing the available writing interface identifiers is smaller than a fourth preset value, and the reading interface is determined to be unavailable. And determining that the reading interface is available when the ratio of the number of the second return codes containing the reading interface available identification to the number of the target file names corresponding to the first return codes containing the writing interface available identification is larger than or equal to a fourth preset value.

Wherein the fourth preset value is a decimal less than 1 and close to 1. For example, the fourth preset value is 0.999. In this embodiment, the fourth preset value may be an expected value of the availability of the reading interface of the storage service for the user, and may also be a commitment value of the availability of the reading interface of the storage service for the storage service provider.

By the method, the robustness of the reading interface of the storage service can be tested, and particularly whether the reading interface contained in the robustness of the reading interface is available or not can be tested.

The robustness of the delete interface of the storage service is tested as shown in fig. 8:

s801: and determining a service test request of a deletion type based on the target file name and a deletion interface of the storage service.

In this embodiment, the electronic device 1000 generates a corresponding deletion-type service test request according to the file name of each target file in the target file set and the deletion request format defined by the storage service deletion interface, and sequentially inputs the generated deletion-type service test request to the deletion interface of the storage service, so that the storage service deletes each target file in the target file set.

S802: and receiving the service parameters returned by the deletion interface of the storage service in response to the service test request of the deletion type.

Wherein the service parameter comprises a third return code.

In this embodiment, after the storage service receives the service test request of the deletion type at the deletion interface, the storage service performs a deletion operation on the target file corresponding to the service test request of the deletion type, and outputs the corresponding service parameter through the deletion interface. Wherein a service parameter comprises a return code. In this embodiment, for clear distinction, a return code included in the service parameter returned in response to the deletion-type service test request is referred to as a third return code.

S803: a number of third return codes containing identifiers available for deletion of the interface is determined.

In this embodiment, the storage service defines a third return code returned by the deletion interface, so that whether the deletion interface of the storage service is available for the service test request of the deletion type can be reflected by the third return code, that is, whether the target file corresponding to the service test request of the deletion type by the deletion interface of the storage service is deleted can be reflected by the third return code.

In one embodiment, the defining, by the storage service, the third return code of the deletion interface may specifically be: when the second return code is at the beginning of "5", it means that the deletion interface of the storage service is unavailable for the input deletion-type service test request, that is, it means that the deletion interface of the storage service cannot delete the target file corresponding to the input deletion-type service test request. In the case that the third return code is not the beginning of "5", the service test request indicating the deletion type input by the storage service to the deletion interface is available, that is, the deletion interface of the storage service indicates that the target file corresponding to the input service test request indicating the deletion type is deletable.

Based on the above, it can be determined whether the third return code in each service parameter belongs to the third return code of the available type defined by the deletion interface according to the specific content of the third return code. Specifically, when the third return code is the beginning of "5", it is described that the third return code belongs to the third return code of the available type defined by the deletion interface. If the third return code is not the "5" header, it is described that the third return code belongs to the third return code of the unusable type defined by the delete interface. It can be seen that the number "5" at the beginning of the third return code is the identifier available for deleting the interface, and the number not "5" is the identifier unavailable for deleting the interface.

S804: and determining the number of target file names corresponding to the first return code containing the writing interface available identification.

S805: and determining whether the deleting interface is available according to the number of the third return codes containing the available identifiers of the deleting interface and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface.

In this embodiment, the foregoing S805 is implemented specifically as follows: and determining whether the deleting interface is available according to the size relationship between the ratio of the number of the third return codes containing the available identifier of the deleting interface to the number of the target file names corresponding to the first return codes containing the available identifier of the writing interface and a fifth preset value. Specifically, when the ratio of the number of the third return codes containing the available identifier of the deletion interface to the number of the target file names corresponding to the first return codes containing the available identifier of the write interface is smaller than a fifth preset value, it is determined that the deletion interface is unavailable. And determining that the deleting interface is available under the condition that the ratio of the number of the third return codes containing the available identifiers of the deleting interface to the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface is greater than or equal to a fifth preset value.

Wherein the fifth preset value is a decimal less than 1 and close to 1. For example, the fifth preset value is 0.999. In this embodiment, the fifth preset value may be an expected value of the availability of the storage service deletion interface for the user, and may also be a commitment value of the storage service provider for the availability of the storage service deletion interface.

By the method, the robustness of the deletion interface of the storage service can be tested, and particularly whether the deletion interface contained in the robustness of the deletion interface is available or not can be tested. Whether the semantics of the delete interface are correct, as contained in the delete interface robustness, needs to go through the steps shown in fig. 9.

S901: and determining a service test request of a deletion type based on the target file name and a deletion interface of the storage service.

S902: and receiving the service parameters returned by the deletion interface of the storage service in response to the service test request of the deletion type.

Wherein the service parameter comprises a second returnbody.

In this embodiment, the second returning body is used to reflect a situation that the deletion interface of the storage service deletes the target file corresponding to the service test request of the deletion type, that is, a specific deletion result.

S903: and determining the number of the second returned bodies which represent that the target file to be deleted does not exist.

In this embodiment, a field corresponding to the deletion result exists in the second returning body, and if the data representation in the field indicates that the target file corresponding to the service test request of the deletion type does not exist, it indicates that the target file has been correctly deleted by the deletion interface. If the data in the field represents that the target file corresponding to the deletion type service test request is deleted, it indicates that the target file is not correctly deleted by the deletion interface.

S904: and determining the number of target file names corresponding to the first return code containing the writing interface available identification.

S905: and determining whether the semantics of the deletion interface is correct or not according to the number of the second return bodies which represent that the target file to be deleted does not exist and the number of the target file names corresponding to the first return codes containing the usable identifiers of the write-in interface.

In this embodiment, the specific implementation of S905 may be: and determining whether the semantics of the deletion interface is correct or not according to the size relationship between the ratio of the number of the second return bodies which represent that the target file to be deleted does not exist to the number of the target file names corresponding to the first return codes containing the available identifiers of the write-in interface and a sixth preset value. Specifically, the method comprises the following steps: and determining that the semantics of the deletion interface are incorrect under the condition that the ratio of the number of the second returning bodies which represent that the target file to be deleted does not exist to the number of the target file names corresponding to the first returning codes containing the available marks of the writing interface is less than a sixth preset value. And determining that the semantics of the deleted interface is correct under the condition that the ratio of the number of the second returning bodies which represent that the target file to be deleted does not exist to the number of the target file names corresponding to the first returning codes containing the available identifiers of the writing interface is greater than or equal to a sixth preset value.

Wherein, the sixth preset value is a decimal less than 1 and close to 1. For example, the sixth preset value is 0.999. In this embodiment, the sixth preset value may be an expected value of the user for the semantics of the deletion interface of the storage service, and may also be a commitment value of the storage service provider for the correctness of the semantics of the deletion interface of the storage service.

By the method, the robustness of the deletion interface of the storage service can be tested, and specifically, whether the semantics of the deletion interface contained in the robustness of the deletion interface are correct is tested.

Based on the above, as shown in fig. 10, a method for testing a storage service interface according to an embodiment of the present invention includes:

the electronic equipment generates a target file set according to the test character set and the unnamed target file; the test character set includes: a symbolic character subset, an alphanumeric character subset, an encoded character subset, and a custom character subset;

the electronic equipment receives the target file set and processes the target file, for example, adding a watermark to a picture, adjusting the size of the picture and the like by using a picture interface of the electronic equipment, and compressing word documents, audio, videos and the like;

and the electronic equipment calls a writing interface, a reading interface and a deleting interface of the object storage service by using the processed target file.

The object storage service writes each target file and returns a writing result to the electronic equipment through the writing interface; reading the target file, and returning a reading result to the electronic equipment through a writing interface; and deleting the target file, and returning a deletion result to the electronic equipment through the writing interface.

The electronic equipment judges the availability, reliability and semantic correctness of the writing interface of the object storage server based on the writing result, the reading result and the deleting result, judges the availability of the reading interface and judges the availability and semantic correctness of the deleting interface. Wherein, reliability refers to whether the data is available or not, reliability refers to whether the data is reliable or not, and semantic correctness refers to whether the semantics are correct or not.

< apparatus embodiment >

As shown in fig. 11, the present embodiment provides an apparatus 11 for testing a storage service interface, where the apparatus 11 includes:

a first determining module 1101, configured to determine a target file name;

a second determining module 1102, configured to determine a service test request based on the target file name and a service interface of the storage service;

a receiving module 1103, configured to receive a service parameter returned by a service interface of the storage service in response to the service test request;

and the test module 1104 is configured to evaluate the service parameter through a corresponding preset test unit according to the type of the service test request, so as to obtain a test result of the storage service interface.

In an embodiment, the first determining module 1101 is specifically configured to obtain a pre-stored test character set, where the test character set includes characters of multiple character types; extracting N characters from the test character set and combining the N characters to obtain at least one character string, wherein N is a positive integer; and determining the at least one character string as a target file name.

In one embodiment, the apparatus further comprises:

a queue module 1105, configured to write the determined target file name into a test queue, so as to obtain the target file name from the test queue before the step of determining the service test request by the second determining module 1102 based on the target file name and the service interface of the storage service.

In an embodiment, the second determining module 1102 is specifically configured to determine a service test request of a write type based on the target file name and a write interface of the storage service; and/or determining a service test request of a reading type based on the target file name and a reading interface of the storage service; and/or determining a service test request of a deletion type based on the target file name and a deletion interface of the storage service.

In one embodiment, the queue module 1105 is further configured to write type service test requests, read type service test requests, and/or delete type service test requests to a service test request queue.

In one embodiment, the type of the service test request is a write type, and the service parameter is a first return code; the test module 1104 is specifically configured to determine the number of first return codes containing the available identifier of the write interface; and determining whether the writing interface is available according to the number of the first return codes containing the writing interface available identification and the number of the target file names.

In one embodiment, the type of the service test request is a read type, and the service parameter is a second return code; the test module 1104 is specifically configured to determine the number of second return codes containing the available identifier of the read interface; determining the number of target file names corresponding to a first return code containing the available identifier of the write interface; and determining whether the reading interface is available according to the number of the second return codes containing the reading interface available identification and the number of the target file names corresponding to the first return codes containing the writing interface available identification.

In one embodiment, the service parameter is a first returnbody; the test module 1104 is specifically configured to determine the number of first returned volumes containing valid data; determining the number of target file names corresponding to a first return code containing the available identifier of the write interface; and determining whether the semantics of the writing interface are correct or not according to the number of the first return bodies containing the valid data and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface.

In one embodiment, the test module 1104 is specifically configured to determine the number of first returned volumes containing correct valid data; determining the number of target file names corresponding to a first return code containing the available identifier of the write interface; and determining whether the writing interface is reliable or not according to the number of the first return bodies containing the correct and valid data and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface, wherein the correct and valid data are consistent with the data of the corresponding target files.

In an embodiment, the testing module 1104 is specifically configured to determine, according to valid data carried in a first returning body, a hash value of the valid data; determining a hash value of the data of the target file according to the data of the target file corresponding to the first returned body; and under the condition that the hash value of the valid data is consistent with the hash value of the data of the target file, determining that the first returning body contains correct valid data.

In one embodiment, the type of the service test request is a deletion type, and the service parameter is a third return code; determining the number of third return codes containing the usable identifier of the deleted interface; the test module 1104 is specifically configured to determine the number of target file names corresponding to the first return code containing the available identifier of the write interface; and determining whether the deleting interface is available according to the number of the third return codes containing the available identifiers of the deleting interface and the number of the target file names corresponding to the first return codes containing the available identifiers of the writing interface.

In one embodiment, the service parameter is a second returnbody; the test module 1104 is specifically configured to determine the number of second returning bodies that characterize that the target file to be deleted does not exist; determining the number of target file names corresponding to a first return code containing the available identifier of the write interface; and determining whether the semantics of the deletion interface is correct or not according to the number of the second return bodies which represent that the target file to be deleted does not exist and the number of the target file names corresponding to the first return codes containing the usable identifiers of the write-in interface.

< electronic apparatus >

As shown in fig. 12, the present embodiment provides an electronic device 12, where the electronic device 12 includes the apparatus 11 for testing a storage service interface as shown in fig. 11, or includes a memory 1201 and a processor 1202. Wherein the memory 1201 is configured to store computer instructions and the processor 1202 is configured to retrieve the computer instructions from the memory 1201 to perform a method according to any of the above-described method embodiments.

< storage Medium embodiment >

The present embodiment provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any of the above method embodiments.

The present invention may be a system, method and/or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions embodied therewith for causing a processor to implement various aspects of the present invention.

The computer readable storage medium may be a tangible device that can hold and store the instructions for use by the instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as punch cards or in-groove projection structures having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing/processing device, or to an external computer or external storage device via a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing/processing device.

The computer program instructions for carrying out operations of the present invention may be assembler instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present invention are implemented by personalizing an electronic circuit, such as a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), with state information of computer-readable program instructions, which can execute the computer-readable program instructions.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable medium storing the instructions comprises an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. It is well known to those skilled in the art that implementation by hardware, by software, and by a combination of software and hardware are equivalent.

Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein were chosen in order to best explain the principles of the embodiments, the practical application, or technical improvements to the techniques in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. The scope of the invention is defined by the appended claims.

Claims

1. A method of testing a storage service interface, the method comprising:

determining a target file name;

2. The method of claim 1, wherein determining a target file name comprises:

and determining the at least one character string as a target file name.

3. The method of claim 2, further comprising:

4. The method of claim 1, wherein determining a service test request based on the target filename and a service interface of a storage service comprises:

5. The method of claim 4, further comprising:

6. The method of claim 4, wherein the type of the service test request is a write type, and the service parameter is a first return code;

7. The method of claim 6, wherein the type of the service test request is a read type, and the service parameter is a second return code;

8. The method of claim 7, wherein the service parameter is a first returnbody;

determining the number of first returned volumes containing valid data;

9. The method of claim 8, wherein evaluating the service parameters through a corresponding preset test unit according to the type of the service test request to obtain a test result of the storage service interface comprises:

Determining the number of first returned volumes containing correct valid data;

10. The method of claim 9, wherein determining the first returnbody that contains the correct valid data comprises:

11. The method of claim 6, wherein the type of the service test request is a delete type, and the service parameter is a third return code;

12. The method of claim 11, wherein the service parameter is a second returnbody;

13. An apparatus for testing a storage service interface, the apparatus comprising:

The first determining module is used for determining a target file name;

14. An electronic device, characterized in that the electronic device comprises the apparatus of claim 13; or,

comprising a memory for storing computer instructions and a processor for invoking the computer instructions from the memory to perform the method of any of claims 1-12.

15. A computer-readable storage medium, characterized in that a computer program is stored thereon, which computer program, when being executed by a processor, carries out the method according to any one of claims 1-12.