*all photos are taken from public sources and serve as an example of how the described functionality works
The first thing we need to do is to handle access keys — a kind of encrypted lines that give us the possibility to communicate safely via numerous PCs.
To access Google Drive, a tester (or a common user) should possess a special token. This may be done by selecting token’s coverage in Oauth 2.0 Playground.
Follow this link and select a necessary Google Drive API.
Google Drive API
After this, we can change this authorization code to a necessary token (a temporary one) that can be used during a certain amount of time to access all functions of Google Drive.
We’ll use JMeter as a token to illustrate this.
Preparing Jmeter plan
The used JMeter will consist exclusively of a list of requests, a controller, HTTP requests, and several event handlers.
JMeter Plan
Now our task is to find necessary global variables for the test plan we are using.
Global Variables
We should specify that we will send requests directly to the Google API server, by using POST HTTPs. Apart from this, we should indicate the access token that has been already created.
We should write that we will send up to ten requests inside a group of flows.
While working with HTTP Request, we should edit its content in the way we wish (mention a necessary server, a method from a test plan, and the HTTP protocol we are using).
HTTP Request
In the Path field, we should add an endpoint: /upload/drive/v3/files. Additionally, we should tell a system that we would like to transfer data in multiple parts: uploadType=multipart.
And finally, we should fill the Data field where we should encrypt the text that we’d like to save inside the file. Now we should manually configure the HTTP title components.
Then we should enter an authorization key in Bearer — a special layout that can read QAuth. We should also set the Content type as Multipart to make the Google Drive web application understand the exact type of our information.
Connection results
If we use the See all results event handler and launch a test plan, we can see that every request we have created was successfully sent. We can also analyze the results of every request.
The Request’s Details
What should we do if the number of users will rise?
If we test the possibility to load the Drive endpoint by sending a high number of requests, we can get very interesting results. For example, if we try to send 200 requests in 5 seconds, we can see that most of them will simply fail:
Sending over 200 Requests
This not a result of Google Drive’s low performance. This happens because every virtual user is limited in the number of requests that can be sent.
If we analyze the situation when some requests were successful and some — were not, it happens because the See all results event handler shows requests only in the order the requests were received.
It may happen due to the fact that a bug with limitation needs more time on its processing than successful requests.
If we analyze the timestamps of the created requests, we can see that the first ones were successful.
Timestamps of the Created Requests
Conclusion
To conclude, we’d like to mention that the analysis of how documents are saved on Google Drive on the basis of authenticating requests for JMeter needs a lot of time to perform all possible preparatory tasks: configuring access tokens, deploying a work environment, establishing a stable web connection, performing prior load tests and so on.
0 Comments