Oct. 1st, 2014

View the Webcast: Understanding Performance Testing for Web and Mobile Apps

Missed our webinar on performance testing for web and mobile applications?

 

Nearly 1,500 people signed up for this webinar – and we recorded the session in full so you can enjoy it too!

 

In this webinar, BlazeMeter’s VP of Product Strategy Ophir Prusak revealed how you can ensure your backend will handle high traffic loads from mobile apps and websites. Key topics included:

 

  -  How and why companies are incorporating performance testing into their app development lifecycle

  -  The pros and cons of various open source tools and cloud based technologies

  -  Specific challenges that mobile brings and how to overcome them

  -  How to automate performance testing

  -  5 key components/stages of building a performance testing practice

  -  How to test any mobile site or app within 20 minutes

  •  
  • View the recorded webcast here:

 

 

Ophir stayed online at the end to answer questions from the audience. Top questions included:

 

Q. How do you wire BlazeMeter to test on every commit/pull request?

A. Excellent question! We have plugins with a few tools like Atlassian Bamboo, Jenkins and TeamCity.  Since BlazeMeter is a software-as-a-service, you can literally use a Jenkins plugin and say what the test is that you want to run. It’s basically a post, build action and it automatically runs in the cloud for you. It’s basically running your BlazeMeter test in Jenkins. This is similar with Bamboo and TeamCity.

 

Q. What about data which is ‘lazy loaded’?

A. I’d like to make the answer to this slightly more generic, as to ‘what about testing webpages which might have all sorts of elements which are loaded through AJAX or stuff like that?’ This is where it gets a bit fuzzy! While almost all tools out there work at the level of http, none of them actually execute Javascript. Having said that, if your tool does recordings (i.e. your BlazeMeter plugin, JMeter’s own recording functionality or any other tool out there with great functionality), any of those elements which are loaded after initial page load are still going to be recorded and you can still play them back. The ability to play back what’s recorded you still have, it’s just not necessarily going to be using exact same logic that you originally did.

 

I’d also like to add something that is critical when it comes to choosing an open source tool. In particular, when we talk about handling complex scenarios. If you haven’t done any performance or functional testing, you need to be aware of is that all check-in processes (things you have to log in) have security measures and normally involve some type of authentication. So, even if you’re using a recorder to record the initial traffic, if try to play back the exact same http request say an hour later from a different machine or whatever, if those requests involve a user login, they will probably fail as the backend will notice that the syndications are different. Now if you’re testing something that is for anonymous users, for the most part you don’t have to worry about this - but if you’re testing login users, you do need to be aware of authentication and stuff like that.  Now every tool has its own solution but at the high level, it involves taking an initial request, transferring the syndication, storing it in a variable and using that for future request. So when you’re looking at the different tools, you need to make sure that the tool does handle such complex scenarios.

 

Want to find out more? Check out our performance testing training center for more free webinars and online courses.

Interested in writing for our Blog? Send us a pitch!