Benchmark results are gathered in lists, that might usually have length one, except when they don't, that probably should be handled differently; and those lists are gathered up into lists, of which we routinely only look at the first entry; see QList<QList<QBenchmarkResult>> usage and especially qMedian(). In particular, I suspect the inner lists (when they may have more than one entry) are actually for different metrics, so qMedian() should be separating its outer list into one simple list per measurement type, taking (up to) one entry from each of the inner lists within the outer list. Then it should sort each, find the median of each, combine those medians into the list that it returns, which is really a mapping from measurement types to results. Or we should replace the inner list-of-results with a mapping from measurement type to results, so that we then have a list of mappings and take the median as just sketched.
And that's just the lists of lists of results.

Every time I read any of the benchmark code, I'm faced with incomprehensible complexity and no documentation to guide me. We need to, at the very least, document what's going on with the (at least) two layers of looping, namely (IIUC):

• the QBENCHMARK-loop within the test code, that expands to a loop controlled by a QBenchmarkIterationController, that eventually decides whether it got "enough data" in some sense for a sensible result
• the TestMethods::invokeTestOnData() inner loop until (among other things) resultsAccepted() is true, during which the number of iterations to be done by the preceding gets doubled (IIUC) if results haven't been accepted.

There's lots of other stuff going on there that needs to be better explained, so that someone working on the code can make sense of the baffling tangle of things accessing each other's global data members – it is madness, that we need to at least describe clearly, and should probably review with an eye to some (possibly drastic) clean-up, for which I currently don't have the time.