Reliability of browser load testing

At present, the reliability of browser load testing is suboptimal, as URLs may not open consistently even with a single user, and clicking buttons during the test could be challenging. However, improving the reliability of browser-based tests would be advantageous in the future. Leveraging a library such as Cypress and bolstering the reliability of test scripts could make this tool exceptional. As for our load test scenario, we aim to increase the load using an API and test on one browser while keeping track of the browser parameter variations under different loads.

Hi @Prashant-05 !

The Cypress part confused me. Are you talking about about browser testing in general? Or about browser testing in k6 specifically through k6 browser module?
k6 browser is still an experimental module and we aim to continuously improve its reliability and maturity level :slightly_smiling_face:

Is there any issue in particular that we can help you with?


Yes, Daniel, thank you for your assistance. I’d like to discuss browser load testing in K6. Currently, our K6 scripts are unreliable. My goal is to enhance the reliability of our K6 scripts to match the reliability of Cypress scripts.

Thanks for your information.

Hi, I am working with Prashant. I am sharing code we are facing issue using k6/experimental/browser on my Windows VDI. k6 fails to go to second tab or some times if it reaches second tab before filling fields of second tab it get closed and checks never gets asserted. K6 automatically stops running its 1st attempts in arounds 31 to 34 seconds and it retries.

Here i have pasted code for reference:

import { chromium } from 'k6/experimental/browser';
import { check, sleep, group } from "k6";

// k6 run -e K6_BROWSER_ENABLED=true Browser.js
export const options={
            executor: "constant-vus", //sends vus at constant speed
            exec: "browser", //name of exported js function to execute
            vus: "2",
            duration: "100s",

export async function browser(){
    const browser=chromium.launch({headless: false})
    const context =browser.newContext()
    const page=context.newPage()

        await page.goto("", {waitUntil: "networkidle"})

        const search= page.locator('img[src=""]');
        const search_type=page.locator('[class="sc-dIfARi bhsQmD k-input k-input-md k-rounded-md k-input-solid"]');
        const search_button = page.locator('[alt="search-icon"]');

        // check(page, {
        //     'successful' : search.successful()
        // })

          await Promise.all([
            console.log("print 2",search_type.textContent()),
            page.locator('.k-form.k-form-md.form-wrapper .claimHeader')

        //     page.WaitForSelector('.k-form.k-form-md.form-wrapper .claimHeader')
        //     expect(page.$('.k-form.k-form-md.form-wrapper .claimHeader')).to.contain('Claim-1682610805792');
        check(page, {
            'successfully navigated claim id': page => page.locator('.k-form.k-form-md.form-wrapper .claimHeader')
            .isVisible() === true});
            const options = page.locator('.k-form.k-form-md.form-wrapper .claimHeader');


Hi @ayushtripathi,

This Promise.all looks a bit suspect. Have you tried breaking the click navigations down into smaller steps? Also, it’s only worth using Promise.all on async APIs, so that’s waitForNavigation and click. I’ve tried to clean up that bit:

  await Promise.all([
  console.log("print 2",search_type.textContent());
  await Promise.all([

  page.locator('.k-form.k-form-md.form-wrapper .claimHeader').isVisible()

  check(page, {
    'successfully navigated claim id': page => page.locator('.k-form.k-form-md.form-wrapper .claimHeader').isVisible() === true
  const options = page.locator('.k-form.k-form-md.form-wrapper .claimHeader');

Let us know where the issue lies.


1 Like