Systems | Development | Analytics | API | Testing

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.

This is the fifth post in our "Features Sitting Idle" series, where we look at OctoPerf features that are already in your platform but often missed by the teams that would benefit the most. This one is for IT teams running OctoPerf on-premise. IT teams managing an on-premise OctoPerf instance regularly run into the same friction around SSO.

When we released the OctoPerf MCP Server, most teams connected to it straight from Claude.ai. Then we showed how to run the whole stack on-premise with a local model. But a question kept coming back from European teams: can we drive our load tests with a French LLM, hosted in Europe, instead of a US model? The answer is yes, and it takes about five minutes.

This is the fourth post in our "Features Sitting Idle" series, where we explore OctoPerf features that are powerful, already available, and yet often replaced by manual workarounds. The distinction matters, and it is often overlooked in test scenarios. Teams that need to simulate a true simultaneous spike - flash sales, ticket drops, mass logins at a specific time, scheduled batch openings - usually end up working around the problem instead of using the tool's native support for it.

But a recurring question came from banks, hospitals, defense and public-sector teams: what if nothing is allowed to leave our network, not even the prompt? This article answers that question with a full walkthrough.. We will stand up a 100% on-premise, air-gapped stack, and it only takes two things to install: OctoPerf Enterprise in Docker, and a local Qwen3 large language model running in LM Studio, which doubles as the Model Context Protocol client.

This is the third post in our "Features Sitting Idle" series, where we shine a light on OctoPerf features that are already in your account but rarely used to their full potential. This is a blind spot many teams discover too late. Tests pass, metrics look fine, yet real users report slowness or errors after a release. The root cause is almost always the same: the load test was built against the HTTP protocol layer, but the user pain happens in the browser, above that layer.