For our first time in Poland, we decided to attend to TestCamp conference. TestCamp is an event-based in Wroclaw, Poland. Test Army is behind the organisation. This event was split in two days, the first one, we trained a few people on OctoPerf. The second one as exhibitor and speaker. More than 500 people attended on Saturday, which is quite an impressive number.
This article follows our first blog post related to deployment on Kubernetes. It is a step-by-step guide explaining how to deploy the InfluxDb/Telegraf/Grafana stack.
More importantly we will se:
Here again we rely on declarative configuration of K8s to install the InfluxDB/Grafana stack. It's the easiest way to do since there are many configuration objects to create.
Kubernetes (commonly referred to as "K8s") is an open source system that aims to provide a platform for automating the deployment, scalability and implementation of application containers on server clusters. It works with a variety of container technologies, and is often used with Docker. It was originally designed by Google and then offered to the Cloud Native Computing Foundation.
This blog post belongs to a series that describe how to use Minikube, declarative configuration files and the kubectl command-line tool to deploy Docker micro-services on Kubernetes.
It focuses on the installation of an Angular 8 frontend application served by an NGinx Ingress controller.
While being the most complex kind of Kubernetes object management, the declarative object configuration allows to apply and revert configuration updates. Also, configuration files can easily be shared or saved into a version control system like Git.
But before going to the configuration of our frontend and its proxy, let's see what is needed in order to follow this tutorial.
This blog post is a guide for every developer that would like to create an Angular Workspace with several applications and libraries.
It starts by explaining how to generate such project with Angular CLI, then continues with shared resources and unit testing, to finish by giving tips on deployment.
We are going to talk about data in this blog post, predominately test data required for performance testing.
This is something that makes the life of a performance tester extremely difficult and awkward as because of the huge quantities required, in the right state, that match the criteria required for your test to run.
We often have to approach the use of large quantities data for the purpose of performance testing in a number of ways:
Fear not, help is at hand from your friends at OctoPerf.
As we have seen above there are a number of valid ways to get data but the one we are going to explore and the one that make our tests reusable and agile is to query the database of the application under test, or any supporting application databases, to retrieve usable data using SQL this way we avoid our defined pitfalls above by:
Ok, we need to caveat this if you have a performance test environment that does not contain a copy of production data, or artificially constructed representative data volumes then this approach will not work but you could argue that performance testing on a system that does not have production quantities of data is not representative so lets assume you do, because I think most will.
Before moving on there is obviously the ability, in JMeter, to create random data that conform to any number of rules (Dates, Random Strings or Integers, Values from Arrays, a value from any number of the JMeter native, or 3rd party, function libraries.
But if you need data that exists in your application under test to either use, update or delete then you need to know the values before testing starts and this is what we are looking at in this post.