It has been a bit of time since we sent our last product update. Since then, a lot of things have happened in the k6 community and LoadImpact; we want to give a quick update of the exciting features have landed during the recent Summer months.
The new k6 release brings a large number of bug fixes, massive performance improvements, and several new features.
With the new k6, your tests will start much quicker, consume less memory, and be more accurate!
The new features include:
open()function for reading data files.
response.urlfor redirected requests, which had non http errors
The full release notes can be found here
Along with the latest k6 changes, we also wanted to improve the developer ergonomics when working on k6 scripts with the editor of choice.
To install the k6 script definitions, run this in your terminal:
npm install -g @types/k6
IDEs like Visual Studio can read TypeScript definitions to provide an exceptional coding experience with features like auto-completion, auto imports or presenting in-context documentation.
Big kudos to @bookmoons for contributing to this and other k6 related projects.
When talking with our customers, having the ability to compare different test results has always been one of the most demanded features. There are many situations in which you might want to compare your load tests, but the general testing cases we’ve found for comparing tests are when doing A vs B, Baseline and Regression testing.
You will likely want to compare your tests before and after any meaningful change. Providing an overview of the performance comparison indicates clearly if the change impacts your application performance positively.
We strongly recommend comparing your performance when migrating to new infrastructure or modify its configuration as well as implementing any relevant application change.
We have written more about Baseline tests as part of our Performance Testing Methodology.
Basically, a baseline test is a test with an ideal number of load and duration to produce a clear stable result. This baseline test will give you initial performance metrics for you to compare to future test runs.
Nowadays, it’s more common to find teams doing performance testing continuously as part of the development cycle; integrating performance testing as part of the CI/CD pipelines or scheduling at regular periods the execution of the tests to be notified when tests fail.
In this case, during the analysis of a test which has started to fail, it’s common to compare the failing result with previous successful results.
You can read more about the feature in the Knowledge Base article.
We are excited about having received a positive response from the first launch of this feature. We are going to continue improving and experimenting in this area of the product, and your feedback is important to make it better. As always, don’t hesitate to let us know if there is anything you want to find.
The request builder is an easy-to-use UI to build k6 tests with minimal scripting. You simply input the URLs, and parameters and the UI will build the k6 script for you.
The request builder is very helpful to onboard new users into the k6 scripting API or a fast way to create a test for you, and it provides many advanced features to test and explore the powerful capabilities of the k6 API:
If you want to know more; the above options and more info are documented on the Request Builder Knowledge Base article.
In the short term, the k6 & LoadImpact team will be working on making k6 and the cloud service more reliable to edge cases as well as new features: more cloud locations, and the new VU schedulers.
If you want to know more about the k6 future plans, check out the k6 roadmap or contact us for any type of question; we’d love to hear from you.