Skip to content

Load Testing Blog

Test mobile native applications with OctoPerf

As mobility has been the trend these past years, all the users coming to a website do so from many different devices. OctoPerf allows you to simulate traffic to your website, but it also allows to simulate this kind of multi-device traffic.

That being said, to take advantage of OctoPerf possibilities, you might need to import several different user journeys. Because a mobile user is very likely to deal with a different version of the application. Thus if you record only one user journey from a computer's browser and use it for your tests, they may not be realistic.

Browser based mobile apps

To record the traffic from a mobile application, you have several options. For browser based apps, you can record them from Chrome or firefox and just use the dev tools to switch the user agent:

Native apps are a bit more complex to get by.

Let's see what is required step by step to record such an application.

Are you buying Quality software?

In our previous article, Building Better Software, we have already shown how clean we try to maintain our codebase. We strongly believe that it's possible to run a successful business and have clean code at the same time. While it's relatively easy to show some nice metrics a single time, it's much hard to keep your code clean over time.

Even if we release some major features like On-Premise load testing, we still follow the boy scout's rule: Always leave the campground cleaner than you found it. Clean Code is not only compatible with business needs, it's almost mandatory if you want to be quickly competitive on a given market.

Unlike most software companies who don't really care about the quality of the software they ship, we do care that you get the best bang for the buck load testing tool. Do you know any other software company which regularly publishes code quality metrics? Probably not. We're trying here to introduce a new movement in favor of clean code.

What is Clean Code

Clean code

Clean code focus developing software that's easy to read, maintain and evolve. Good programmers have quickly understood that we are writing code for humans, not computers. Dikjstra, a famous mathematician, told something very interesting in 1972 at the Turing Award Lecture:

Continuous Integration Load Testing with Jenkins

We're proud to announce that we released our Jenkins / Hudson plugin to run load tests from your favorite Continuous Integration / Continuous Delivery service. The sooner you detect a performance issue the quicker the bottleneck can be found and fixed.

We believe that Continuous Integration Load Testing is the key to help companies deliver high performance web applications in time. Applications today not only need to pass unit and integration tests to ensure proper operation, but also acceptance tests like performance tests to ensure it behaves correctly under load.

The new OctoPerf Jenkins plugins allows you to leverage the power of our hybrid cloud / on-premise load testing solution as part of your development / testing build cycle. This significantly simplifies load testing web application for developers and testers. Each load test can leverage the power of our infrastructure to run thousands of virtual users.

Our highly scalable infrastructure will take care of launching as many virtual users as you need every time you run a Jenkins build. It makes load testing large scale web applications on a regular basis significantly easier.

Regression Testing

Continuous Performance Testing

Cloud testing vs Internal testing

The rise of cloud platforms lead to a major evolution for load and performance testing. Since generating load requires a powerful infrastructure for a short period of time, one might even argue this is the perfect use case. But since we started OctoPerf we had a lot of feedback from users wanting to test from their own machines for a lot of good reasons.

Web application does not mean web-site

First of all, not all web applications are available on the internet. In particular test environments, which are usually mostly meant to be used internally. As testing the application before its deployment is important, the load tests are often done on such environments.

Also, large companies have a wide range of intranet applications that can't be accessed from outside their network. Of course they need tests and in that case testing from the cloud does not make much sense.

Building small Java Docker images

When you take a look at the Java Official Docker images, you will immediately notice how fat they are: a whopping 243MB announced for a simple Java 8 JDK base image! It takes forever to download them from a regular DSL connection here.

Usually, your Dockerfile for Java apps starts with something like:

FROM java:8

MAINTAINER ...

Just try the following command: (you must have docker installed)

docker pull java:8
docker images | grep java