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.
This blog is the opportunity to check on new technologies:
I wanted to try another build solution for my Java backends. I used Maven for several years, both on OctoPerf and in my previous work experiences. Moving from Maven to Gradle is not necessarily easy, as the concepts involved are different.
This blog post is a guide for every developer with a Maven background that would like to give a try to Gradle (version 5.x), especially for authoring multi-module/multi-project builds.
It lists the differences between the two build solutions, step by step. You will learn what pitfalls to avoid, and how to setup code quality tools.
This is not a beginner guide on Gradle, it aims at describing the build setup of a complex project. However, be warned that my experience with Gradle is limited to this single project.
What are they?
Well, non-functional requirements are requirements that define the operation of the system under test rather than the behaviour of the system under test, or the functional requirements as these are known.
The categories under which non-functional requirements are grouped are numerous with a degree of overlap, we are going to attempt to demystify some of these whilst attempting to articulate how they can be tested and some of the common pitfalls.
The world of non-functional testing can be murky and ambiguous in contrast to its functional counterpart where expected functionality and behaviour is easier to define.
Hopefully this blog post will give some insight in to how non-functional requirements can be tackled and made testable.
We are pleased to announce that you can now connect your own Microsoft Azure account to OctoPerf This way OctoPerf starts agents automatically for you inside your Azure environment exactly the same way we do with AWS. It's a neat option to avoid permanent firewall rules or load agents. Also Azure provides a large number of datacenters. As usual it is also available with your OctoPerf free account. You can find the procedure in our documentation on Microsoft Azure integration.