Systems | Development | Analytics | API | Testing

OctoPerf 18.0.0 is out! In version 17 we separated the injection engine from JMeter, and this release is where it starts to pay off: K6 is now available as a load engine next to JMeter and Playwright. Playwright Virtual Users also measure the Core Web Vitals of every page they open. K6 scripts are code, so they usually live in Git next to the application and get reviewed like it. With OctoPerf 18 you can run them without modifying them: This is why we did all that work in OctoPerf 17.

Migrating a load testing project is rarely difficult, but it takes time and it's easy to give up halfway. That's why OctoPerf 18 comes with a Gatling migration playbook for AI agents. In our NeoLoad and LoadRunner walkthroughs, the projects were converted into JMeter Virtual Users. A Gatling simulation is code, so here it stays code: the agent rewrites it as a K6 script, and its injection profile becomes an OctoPerf scenario.

We just released OctoPerf 18 and its main addition is a new load testing engine: K6. You can now import your K6 scripts and run them without changing a single line, next to JMeter and Playwright Virtual Users, in the same scenarios and the same reports. In this blog post I import a K6 script that browses our public demo shop, validate it, run it and go through the results. The scripts can be downloaded if you want to follow along. I will finish with the things that work differently than with JMeter.

Our BlazeMeter to OctoPerf Maven plugin is archived. What replaces it is not another tool to install: OctoPerf 17 ships a BlazeMeter migration playbook for AI agents. Real prompts, real output, run against a real BlazeMeter account. The plugin worked: one mvn command copied your workspaces, projects and JMeter scripts into OctoPerf. But a Maven command cannot ask you a question, so it never said which tests were worth moving, never brought your load profiles, and never replayed what it imported.

A VuGen script is C. Some scripts are a recorded journey with helpers around it, others are a framework that happens to send a few requests. OctoPerf 17 ships a LoadRunner migration playbook for AI agents whose first job is to tell you which one you have. Real prompts, real output, script downloadable. Target: JPetStore, our public MyBatis demo shop. Every step is reproducible. One Action.c, HTTP recording level, eight transactions walking a purchase. Around them: It replays green in VuGen.

Migrating a load testing project is rarely hard. It is long, and easy to abandon halfway. OctoPerf 17 ships a NeoLoad migration playbook for AI agents. Real prompts, real output, project downloadable. Target: JPetStore, our public MyBatis demo shop. Every step is reproducible. One User Path, split Init / Actions / End, six containers walking a purchase. Around them: Download it to follow along.

OctoPerf 17.0.0 is available, on the SaaS platform and for On-Premise installations. It rebuilds how test results are stored and read, upgrades Playwright, and considerably extends what an AI agent can do through the OctoPerf MCP server. One thing to know before you upgrade. A result recorded before this version must be updated before its report shows data again. Nothing is lost, and the update runs on its own the first time you open the report.

This is the sixth and final post in our "Features Sitting Idle" series, where we shine a light on OctoPerf features that are already in your account, ready to save you hours every week. It's a quiet but recurring friction. Teams that test regularly all end up with a preferred report layout. But in practice, that structure is often rebuilt manually after each run, or lost entirely when moving between projects.

The OctoPerf web application is a large Angular workspace: 7,786 TypeScript files, around 381,000 lines of code, 1,166 components and 2,738 test files. We have just taken it from Angular 20 to Angular 22, deleted zone.js, and replaced Karma and Jasmine with Vitest. The interesting part of this story is not the version number. It is that we got the strategy wrong first. We spent months migrating the codebase component by component, drowned in manual regression testing, and still let bugs reach production.