K6 Load Test in Browser :: Super Interesting!

K6 Load Test in Browser :: Super Interesting!

সাধারণত আমরা যখন সার্ভারের পারফরম্যান্স টেস্ট করি, তখন অনেকগুলো virtual user দিয়ে API-তে একসাথে রিকোয়েস্ট পাঠাই। যেমন—JMeter, k6, বা Postman দিয়ে শুধু API endpoint-এ বারবার হিট করি, কিন্তু ব্রাউজার দিয়ে ওয়েবসাইট ব্যবহার করার মতো Performance Test সাধারণত হয় না।

কিন্তু একবার ভাবুন, রিয়েল লাইফে আমরা কিভাবে ওয়েবসাইট ইউজ করি? আমরা তো ব্রাউজারেই লগইন করি, ফর্ম সাবমিট করি, অনেক কিছু ক্লিক করি—যা Pure API তে হয় না!

এখন যদি ঠিক আমাদের মতোই ১০০০ জন ব্রাউজার দিয়ে একসাথে কোনো ওয়েবসাইটে ভিজিট করে, তখন সার্ভারের পারফর্মেন্স আসলে কেমন হবে? k6 browser—এমন একটা দারুন ফিচার যেটা দিয়ে আমরা ঠিক এই কাজটি ই করতে পারব।


🌐 Real-World User Simulation: Now With Browser!

k6 অনেক দিন ধরে experimental ভাবে ব্রাউজার দিয়ে পারফর্মেন্স টেস্ট নিয়ে কাজ করছিল। অবশেষে তারা v0.52 থেকে এই ফিচারটা উন্মুক্ত করেছে, আর এখন (v1.0.0) আরও stable! এখন আপনি চাইলে ব্রাউজারে UI ইন্টার্যাকশন (login, fill form, navigate etc.) কিভাবে behave করে, সেটাও টেস্ট করতে পারবেন! 😮


🎯 Getting Started: A Sample Script

নিচে একটা working example দিচ্ছি—login page-এ গিয়ে, লগইন করে, স্ক্রিনশট নিয়ে, চেক করে নিচ্ছে লগইন সাক্সেসফুল কিনা।

import { browser } from 'k6/browser';
import { check } from 'k6';

/**
 * K6 browser test script demonstrating multiple test cases within one scenario.
 * Test Case 1: Login as admin and verify successful login.
 * Test Case 2: Assert welcome message, take screenshot, and logout.
 */

export const options = {
    scenarios: {
        ui: {
            executor: 'shared-iterations',
            vus: 5, //Simulate 5 virtual users
            iterations: 5, //Each VU runs once
            options: {
                browser: {
                    type: 'chromium'
                }
            },
        },
    },
};

/**
 * Test Case 1: Login as admin, assert successful login, and take a screenshot.
 * Steps:
 *  - Go to the login page
 *  - Enter credentials
 *  - Click submit
 *  - Wait and take a screenshot
 *  - Assert URL contains 'admin.php'
 */
async function testLogin(page) {
    await page.goto('https://test.k6.io/my_messages.php');
    await page.locator('input[name="login"]').type('admin');
    await page.locator('input[name="password"]').type('123');
    await page.locator('[type="submit"]').click();
    await page.waitForTimeout(1000);
    await page.screenshot({ path: 'screenshots/login.png' });

    check(page.url(), {
        'Login successful': (url) => url.includes('admin.php'),
    });
}

/**
 * Test Case 2: Assert welcome message, take a screenshot, and logout.
 * Steps:
 *  - Wait for the welcome message ("Welcome, admin!") to appear
 *  - Assert the text is present
 *  - Take a screenshot
 *  - Click the Logout button
 *  - Wait to ensure logout is processed
 */
async function testAssertWelcomeAndLogout(page) {
    // Wait for and assert welcome text
    const welcomeLocator = page.locator('h2');
    await welcomeLocator.waitFor({ state: 'visible', timeout: 3000 });
    const welcomeText = await welcomeLocator.textContent();
    check(welcomeText, {
        'Welcome message shown': (txt) => txt && txt.includes('Welcome, admin!'),
    });

    await page.screenshot({ path: 'screenshots/welcome.png' });

    // Click Logout button
    await page.locator('form[action="/my_messages.php"] input[type="submit"]').click();
    await page.waitForTimeout(1000);
}

/**
 * Main test flow: calls each test case in sequence for every virtual user.
 */
export default async function () {
    const page = await browser.newPage();
    try {
        await testLogin(page);                // Test Case 1: Login
        await testAssertWelcomeAndLogout(page); // Test Case 2: Welcome + Logout
    } finally {
        await page.close();
    }
}

        

👉 কিভাবে রান করবেন?

k6 run script.js        

(k6 browser module থাকতে হবে এবং latest ভার্সন ইনস্টল করা লাগবে!)

🏆Output:

Article content
K6 browser test output

⚡ What Makes It Exciting?

  • Real-User Simulation: Traditional API testing শুধু server-side performance দেয়। ব্রাউজার দিয়ে করলে actual user experience-ও measure হয়—DOM rendering, JS execution, network requests—সব কিছু!
  • Screenshots: যেকোনো সময় screenshot নিতে পারবেন—debug করার জন্য দারুণ সুবিধা।
  • Scripting Flexibility: JS/Puppeteer style coding—modern, readable, and easy.


🧠 Use Cases

  • Login flows & authentication testing
  • Form submission & validation under load
  • SPA (Single Page Application) performance check
  • রিয়েল ইউজার ব্রাউজারে ওয়েবসাইট ওপেন করলে যেমনভাবে পেজ লোড, রেন্ডার, বা রেসপন্স টাইম ফিল করে—সেই অভিজ্ঞতা মাপা যায় (যেমন TTI, TTFB, ও পেজ রেন্ডারিং টাইম)।


🚧 Limitations (as of v1.0.0)

তবে, কিছু মেজর লিমিটেশন এখনো রয়েছে (production use-এ যাওয়ার আগে অবশ্যই জেনে নিন):

  1. Headless Only: যতই headless: false বা K6_BROWSER_HEADLESS=false সেট করুন না কেন, ব্রাউজার UI দেখা যাবে না—সবসময় headless mode-এ চলে। UI-তে দেখে debug করতে চাইলে Playwright/Puppeteer ব্যবহার করতে হবে।
  2. Resource Heavy: Browsers spin-up করা মানে অনেক বেশি CPU/RAM লাগে, তাই বড় স্কেলে চালালে resource allocation issue হতে পারে।
  3. Concurrent VU Limit: Practical Estimate নিজের PC-তে কতজন Virtual User (VU) চালাতে পারবেন? 4GB RAM: সাধারণত ২-৩টি ব্রাউজার VU-র বেশি চালালে system slow হয়ে যায় বা hang করে। 8GB RAM (Core i5/Ryzen 5): এখানে ৫-৮টি VU handle করা সম্ভব, তবে ১০+ VU দিলেই RAM/CPU ফুল হতে শুরু করবে। 16GB+ RAM: এখানে ১২-১৫ VU চালানো যায়, কিন্তু আবারো নির্ভর করবে আপনার CPU, active background apps ইত্যাদির ওপর। প্রতিটি browser instance কমবেশি 300–600MB RAM খায়, এবং CPU usage দ্রুত বাড়ে (especially heavy JS/websites)। Baseline: 4GB RAM 👉 2-3 VU 8GB RAM 👉 5-8 VU 16GB RAM 👉 12-15 VU ⚠️ এগুলো শুধুই estimate—script, ব্রাউজার বেহেভিয়ার, OS, এবং background tasks ভেদে কমবেশি হতে পারে। Heavy SPA/React/Vue app হলে VU সংখ্যা আরও কমিয়ে আনুন।
  4. Feature Limitation: সব Playwright/Puppeteer ফিচার এখানে available না। যেমন—complex UI automation, video recording, full browser devtools integration—সব এখনো নাই।
  5. Ecosystem Support: এখনও experimental, API surface stable না, future updates-এ breaking change আসতে পারে।
  6. Element Locating Limitation: k6 browser দিয়ে টেস্ট লেখার সময়, Playwright বা Puppeteer-এর মতো ব্রাউজার ওপেন করে ডেভেলপার মোডে inspect বা এলিমেন্ট লোকেট করা যায় না। তাই স্ক্রিপ্ট লেখার জন্য আপনার Playwright/Puppeteer সম্পর্কে আগে থেকেই জানা দরকার। এছাড়া, Playwright-এর getByRole, getByLabel, getByPlaceholder এসব আধুনিক method এখানে সাপোর্ট করে না। শুধুমাত্র traditional way, যেমন await page.locator('selector') দিয়ে এলিমেন্ট ধরতে হবে।
  7. Higher concurrency: Distributed/Cloud setup ব্যবহার করুন, অথবা শুধুই API mode ব্যবহার করুন—browser mode PC-তে বড় স্কেল লোড টেস্টের জন্য উপযোগী না।


🎬 Final Thoughts

k6 ব্রাউজার পারফর্মেন্স টেস্টিং—প্রচন্ড শক্তিশালী ও এক্সাইটিং একটা টুল, যদিও কিছু লিমিটেশন আছে। রিয়েল-ওয়ার্ল্ড ইউজার এক্সপেরিয়েন্স capture করার জন্য এটি অনেক বড় একটা স্টেপ। আপনি যদি “modern load/performance testing” নিয়ে আগ্রহী হন, অবশ্যই try করে দেখুন!

Any questions? Drop a comment or DM! Happy testing! 🚀


Rafat Ahmed

Lead Software Engineer at Techjays

2mo

nice one brother

Masud Jahan

Lead Performance Engineer at bKash Limited

2mo

Good article. The mention of the K6 browser and core web vitals is exciting for the modern performance testing landscape. Traditional tools can measure static asset delivery from the server, but I see less value in client-side load testing for granular JS/image performance, or simulating multiple browsers from the one machine when no network calls occur. While the client-side behaviours are valuable, client-side performance is inherently tied to the end-user's device. Factors like client hardware, browser engine, and the network conditions heavily influence JS execution and image rendering, making it highly variable. This variability makes consistent client-side metrics in load testing tough. Load testing's primary goal is server capacity under concurrent usage. Though you simulate many browser sessions, each one processes elements individually. There's no collective client-side bottleneck among 1000 browser instances, like 1000 concurrent API requests cause on a server. Now, this raises a fundamental question: If a client-side action has no server network call, why simulate it with multiple concurrent browsers from one machine? Such isolated performance tests depend on the load generator, not server scalability. Thanks!

Noor Yeaser Khan

Lead Quality Assurance Analyst at Thoughtworks

2mo

The only time I remember executing a performance load test from a browser/actual end user perspective was back in 2014 using HPs LoadRunner v11.5 TruClient protocol. It was super resource heavy on the load generators. We discontinued it as it was super expensive protocol back then. In your article I do see that you’ve configured k6 to simulate chromium browser. And also in the output it displays core web vitals. However, I don’t see the custom browser metrics. For instance, is there a way to measure a certain JS file performance on my application? Or may be a certain custom image that loads on all pages. This is something I am currently looking into. There’s a whacky way with Jmeter to do so. Just record the outgoing request and replay with desired load. I’d be interested in hearing more from you regarding this. Kudos on writing such an article in Bengali though 😍

Al Amin choudhury Abeer

Senior SQA Engineer @ GP x Brain station 23 || Manual || Automation || Postman || Cypress || JMeter || Selenium || Manual || Full stack SQA || Laravel || PHP

2mo

Thanks for sharing, Salman bhai

Raihan Khan (Ryan)

Salesforce Admin | Manual & Automation Testing | Playwright | Selenium | API Testing | Jenkins CI/CD | Docker | n8n | UI/UX Testing

2mo

Insightful, thank you brother.

To view or add a comment, sign in

Explore topics