octoperf-loadrunner-migration

OctoPerf — LoadRunner migration

import_loadrunner_virtual_user does the mechanical part: the requests — web_rest included, whose headers are written inside the call rather than before it — the transactions, the extractors and checks, the headers, the think times, the .prm parameters with their .dat files uploaded, and the parameters the script writes with lr_save_string and lr_save_datetime, and the credentials web_set_user puts on a server. Given a provider it also reads the .lrs — each Controller group becomes a user profile carrying the load its schedule describes. It deliberately stops short of what has no OctoPerf equivalent, and hands back everything it left undone in the response's unconverted list, some of it as a named marker planted in the tree. This skill is what turns that list into a test that runs.

Work in this order. Skipping the first step is how migrations get committed to and then abandoned.

1. Decide before you import

Call analyze_loadrunner_project and read portability before anything else:

MOSTLY_MANUAL is not a difficulty rating, it is a different script. A VuGen .c is C: an author is free to build a whole framework in it, and plenty have. In the reference corpus of 276 published scripts, 120 come out MOSTLY_MANUAL, and they are not near misses — they are scripts whose calls are getenv, sprintf, strtok and the author's own wi_* helpers, branching on a rc returned by another of their own functions. Nothing in that converts, because nothing in it is a request.

A script can be QTWeb and send nothing at all. Check inventory, not the protocol: a script with 99 calls and no pages is a framework. Importing it produces a tree of markers and no traffic, which reads as a broken importer and is not one.