Testing Application Communications

Network analysis must be a part of the test plan for any connected application. In our case, a connected application is one that communicates with a server. More and more, our products and feature are dependent on communication with a server, some entirely dependent on a server.

We are required to measure the following categories and there must be test cases for each for all applicable products/features:

1. Efficiency — is the product making efficient use of the network and the services on the other side of the network, or might there be some wasted work?
2. Security — is the product encrypting potentially sensitive user data?
3. Total Bandwidth Use — is overall bandwidth use in the range of normal? This is especially important when connected to a cellular network.

Measuring these categories requires the ability to view the full contents of outgoing requests and incoming responses. There are several free and paid tools available to help. We have found the following three tools to be the most useful, although this is certainly a matter of taste:

1. Chrome (or another browser) Dev Tools
2. Microsoft Message Analyzer
3. Wireshark

Measuring Efficiency

There are five common classes of inefficiencies:

1. Requests returning data for no obvious functional reason. For example, a request gets a list of gas station names, their addresses, and current fuel prices, but there is no feature in the product that uses fuel prices. The response may be returning extraneous data and possibly causing the server to perform unneeded work to get it.
2. Redundant requests. For example, a user status is sent to the server every minute whether the status changes or not. This may be unnecessary and the application logic should consider a smarter approach.
3. Deferrable requests. For example, opening a screen that shows a list of trips, but also gets all of the stop details and other attribution which is only displayed when each trip is selected. Perhaps it is best to only request this additional attribution when an item is selected instead of getting it all up front.
4. Non-scalable requests. For example, a list of favorite user’s stops is returned. What if a user has 100,000 favorite stops? Typically, a paging mechanism is required to avoid asking the server to get and return many MB of data all at once. A paging mechanism typically makes the client more responsive too.
5. Error requests. Most requests are expected to return 200 (HTTP OK) response codes. If requests are typically returning error codes (4xx or 5xx), this is probably an inefficiency, and possibly even a functional defect somewhere in the application.

Inefficiencies like this may seem trivial in isolation and especially from the perspective of a single client application. We must remember though that each running client is hitting the same service, which is hitting the same database(s), which may be a key bottleneck in the system to begin with. One inefficient client may be negligible. What if there are 100 clients running? Or 100,000 clients? Now a small inefficiency may be wasting tangible capacity on the database server, or worse. Every request matters and every byte returned counts.

Even from the client’s perspective, every byte counts and every byte may cost quite a bit too. If an application is communicating over a cellular network, data charges may apply. Wasteful communication can literally waste money.

When testing a web application, we use the Chrome Dev Tools to view network activity of the application. This tool is magical and intuitive to use so there’s not a real need to expand on it much here. We’ll focus on the desktop and mobile tools instead.

When testing a desktop or mobile application, our tool of choice so far is Microsoft Message Analyzer, which only runs on Windows. Message Analyzer nicely groups requests and responses and provides a number of filtering options so we can sift through the extensive noise. For simplicity of testing and because we control the source code, we simply change all of our endpoints to HTTP instead of HTTPS. Now we can read the clear text communications and make sense of it.

This same approach works for native desktop applications and anything running in an Android emulator.

Here’s how to use it:

1. Installation: Microsoft Message Analyzer
2. Capture localhost network traffic: New Session -> Live Trace -> Select Scenario = Loopback and Unencrypted IPSEC
3. Click Start
4. Add filter on top right filter, e.g.: tcp.Port == 80 and HTTP.Destination contains “.alk.com” and !HTTP.Destination contains “autotest”