How did I do interface testing step by step

The purpose of the interface test

This is a cliche, but I think when it comes to interfaces, there is no standard without a goal, so the purpose of testing is important.

First of all, let’s move the English explanation on Wikipedia (Chinese is not found, baidu is ignored…). :

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and As part of integration testing to determine if they meet expectations for functionality, reliability, performance, [1] Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps).[3][4]

Translation:

API testing is a software testing activity that, as part of integration testing, directly controls the interfaces (apis) of the application under test to determine whether the desired functionality, reliability, performance, and security are achieved. [1] Because none of the apis have GUI interfaces, API testing is done at the communication layer. [2] API testing now plays an important role in automated testing because APIS are generally the primary interface for application logic, and GUI testing is difficult to maintain amid rapid iteration and frequent change in agile development and DevOps. [3] [4]

[1]: Reputation Protection for Testing APIs and Reputations, by Amy Reichert, SearchSoftwareQuality March 2015

[2]:All About API Testing: An Interview with Jonathan Cooper， by Cameron Philipp-Edmonds， Stickyminds August 19， 2014

[3]:The Forrester Wave? Evaluation Of Functional Test Automation (FTA) Is Out And It’s All About Going Beyond GUI Testing， by Diego Lo Giudice， Forrester April 23， 2015

[4]:Produce Better Software by Using a Layered Testing Strategy， by Sean Kenefick， Gartner January 7， 2014

Then I currently work in the Leader of my expectations:

Find as many problems as possible. First, I want to talk about the background. He is the main program of the APP side, and he expects me to find the problems of the interface as soon as possible so as to reduce the problems found in the connection between the APP and the server side. He gives an example where the server returns {“width”:30, “URL “:”http://xxx/a.jpg”}, and there may be a mismatch between the actual width of the image and the width field.

Communication with Daito and other people who have done API testing:

Cover business, including business normal/abnormal conditions

My initial understanding:

Find a problem, yeah. That is, the document said that the required field is missing try, only must field try, must field with invalid value try. Optional field missing try, optional field invalid value try.

The result: at least six use cases per interface, or more. Moreover, in many cases, the business may not be measured (for example, the interface only returns success failure, but it may actually fail but return success, and other interfaces need to be called for verification).

Current understanding (probably a little off base) :

Design use cases with the business. If there are page-turning parameters, try default, valid, last page, last page +1, invalid. Design use cases for each parameter and business scenario.

Implementation of interface testing

I went down two paths at this point: Jmeter and pure Java code. Right now, neither path is good, so I won’t share it. Here are some recent posts on Testerhome about interface testing tools, and a brief summary of their implementation:

A summary of the interface tests done so far

Well, I think what I’m doing right now is interface testing, but I’m designing use cases that are more functional. For example, to publish moments, I will call the upload interface (check whether the md5 of the uploaded file is correct, whether the order is correct, and whether the relevant attribute fields are correct), and send the circle interface (basically check the return value is enough, but there should be different types of text, including special symbols, lengths, etc.). View the circles interface (image MD5, order, related attributes, publisher, reply and thumbs-on data). Because there are three separate interfaces, each interface needs to have some encapsulation method (sending messages, retrieving specified fields in return values, etc.). Each encapsulation method averages about 10 lines of code, and a use case with three interfaces basically requires 3×10+10 lines of code (some specification and some hard encapsulation). A feature covers about 10 use cases, so you need 10×40 lines of code, which is 400 lines of code. Excluding some code that can be shared, you need roughly 300 lines of code (more for some complex features).

PS: According to git statistics, my daily code quantity is about 1000, but the number of use cases is still about 15.

As can be seen, my speed is mainly slow because of the large amount of code, time is spent in the code, and the code debugging will take a certain amount of time, so the efficiency is naturally low. So if you optimize the way you write your use cases, you won’t be able to write them fast. The next step is to summarize which areas can be extracted, recorded or automatically generated, and reduce the writing of use cases to filling out forms or filling out data.

The Updated 2015.11.30

Today I talked to Monkey and another colleague in the company who had done API testing and found a fundamental problem: MY use case design had a problem

This is a difficult concept to explain, but take the published circle of friends mentioned above as an example.

Suppose I want to validate the interface to publish a circle of friends, which works like this:

Upload images and the server returns urls for those images

Publish the circle of friends, including the circle of friends text content and each picture URL two main fields. The server only returns the success and the id of the circle of friends

I design the normal hair circle of friends for example:

Upload pictures through the upload picture interface to verify whether the pictures are uploaded successfully and whether the MD5 of the corresponding files of each URL matches the MD5 of the locally uploaded pictures.

Use the send loop interface to send a loop where the image URL comes from the return value of the first step

Use the View loop interface to view the outgoing loop and check that its content and image are correct.

At first glance it may seem like nothing is wrong (as anyone who has done API testing has already seen), but there is a serious problem with this use case: the interface becomes the means, and the verification point is the function.

There are two main types of API test cases that I came up with:

Single interface test. Invoking an interface is a use case

Multi-interface business testing. Multiple interfaces are invoked, and there may be data passing between the interfaces.

API testing is the simplest, and each interface should have at least one use case that calls a single interface with default parameters. Here’s the point: single. Use cases like mine are no longer verifying the interface to post to friends, but the functionality of Posting to friends.

So what should be the use case for the moments interface? I think about it again according to the current test interface ideas, there are mainly the following:

With pictures, text, expected to return published successfully

No pictures, text, expected return published successfully

With picture, no text, expected to return published successfully

No pictures, no text, expected return publish failed

There are pictures, text, expected to return the success of the publication, and the records in the database as expected

Each use case tests a point, and a separate use case is sufficient to cover the correctness of the return value for success.

Once the use cases are identified, you can see that interface testing actually has many reusable points. The essence of interface testing is to verify that the return value/database change is as expected by permutations and combinations of test parameters, and thus determine whether the interface-related code is correct. By thinking in business terms, I mean that these permutations and combinations are not just random ideas, but possible permutations and combinations within the business.

This is why many interface test cases are written in Excel tables, because it is easiest and fast to display the arrangement and combination of parameters in tables.

Here’s another example of the use case being as concise as possible.

For example, the list interface has a page-turning function. It has one entry: lastTopicId, and the return value has an isMore field. LastTopicId indicates which topic to start with, and isMore indicates whether the next page exists (1 for yes, 0 for none).

For one of the use cases for this interface, you need to verify that the isMore field is 0 on the last page. My initial idea was to keep turning pages like functionality until I got to a large page count or isMore zero. Because the number of pages is uncertain, even if this is a very large number of pages set to a very large number of pages there is no certainty that it will never exceed this number of pages. So there’s something wrong with the idea.

After talking to Monkey and my colleague, he pointed out that the correct line of thinking is:

Know how to get to the last page all at once in one step, using a trusted approach (calculating directly from the server database, or having a port that tells you what the last page is).

Go straight to the last page

Verify isMore parameter values

There are some things that developers can easily give us, so we don’t have to struggle to figure it out ourselves, but just let developers add an interface that allows us to access the data directly. Development assistance is integral to making interface testing better.

Getting interface testing right isn’t as easy as it might seem, but it’s not as hard as it was when you started. Anyway, if you start it, you have to find a way to do it well. Next I’ll use the new design use case thinking for the rest of the interface test cases and modify the Java code to support using Excel as a use case. If there is something wrong in my comprehension, I welcome you to raise it in time.

For more information about interface testing, you can add QQ group: 747981058