عامل‌های Playwright چرخهٔ تست نرم‌افزار را با حلقه‌های خودکار ترمیم کردند

اگر مهندس اتوماسیون هستید و ساعت‌ها وقت خود را صرف اصلاح اسکریپت‌های شکننده می‌کنید، باید بدانید که دوران مدیریت دستی لوکیتورها به پایان رسیده است. در گذشته، مهندسان اتوماسیون روزهای خود را به نوشتن اسکریپت‌های سخت و شکننده می‌گذراندند، اما اکنون می‌توانند یک حلقه خودمختار را مدیریت کنند که تست‌های خود را برنامه‌ریزی کرده و ترمیم می‌کند. با معرفی عامل‌های تست (Test Agents) در نسخه ۱.۵۶، Playwright جریان کاری را از اجرای ساده کد به سیستمی تبدیل کرده است که فعالانه اپلیکیشن را کاوش می‌کند تا مجموعه تست‌ها را بسازد و نگهداری کند.

صنعت سال‌هاست با چرخهٔ فرسایشی «اصلاح-اجرا-تکرار» دست‌وپنجه نرم می‌کند. نیازمندی‌ها دریافت می‌شوند، موارد تست نوشته می‌شوند، اسکریپت‌ها اتوماتیک می‌شوند، لوکیتورها می‌شکنند، اسکریپت‌ها شکست می‌خورند و سپس فرآیند دیباگ آغاز می‌شود. طبق گزارش‌های فنی، حتی با انتقال از Selenium به Cypress، بار اصلی همچنان بر دوش انسان بود؛ مهندسان باید نیازمندی‌ها را به سناریو تبدیل می‌کردند و با هر تغییر در رابط کاربری (UI)، لوکیتورها را دستی به‌روز می‌کردند. این نگهداری مداوم در پروژه‌های مقیاس‌بزرگ منجر به انباشت بدهی فنی شدید می‌شود.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی اتوماسیون هوشمند اشاره کردیم، کلید حل این مشکل در حذف ترجمه دستی نیازمندی‌هاست. Playwright در ابتدا با حل مشکلات همگام‌سازی و ناپایداری از طریق انتظار خودکار (Automatic Waiting)، ردیابی داخلی (Built-in Tracing) و لوکیتورهای معنایی مانند getByRole محبوب شد. با این حال، تلاش دستی برای تبدیل سناریوها به کد و بازنویسی آن‌ها برای تغییرات UI همچنان باقی بود. طبق راهنمای فنی منتشر شده در ۱۷ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، رویکرد جدید عامل‌محور (Agentic) مستقیماً در ساختار پروژه ادغام شده است. این سیستم جایگزین ترجمه دستی نیازمندی‌ها شده و از یک معماری سه‌گانه شامل عامل برنامه‌ریز، تولیدکننده و ترمیم‌کننده استفاده می‌کند.

معماری سه‌گانهٔ عامل‌ها

عامل برنامه‌ریز (Planner Agent) مانند یک تحلیل‌گر QA مجازی عمل می‌کند. این عامل نیازمندی‌های متنی (Natural Language) و یک «تست بذر» — اسکریپت اولیه‌ای که زمینه‌ای مثل اطلاعات ورود را فراهم می‌کند — می‌گیرد تا اپلیکیشن زنده را کاوش کند. خروجی این عامل به‌جای کد، یک برنامه تست ساختاریافته در قالب Markdown است که جریان‌های کاربر، گام‌ها و نتایج مورد انتظار را با جزئیات شرح می‌دهد. برای مثال، درخواستی مانند «ایجاد برنامه تست برای قابلیت ورود با سناریوهای معتبر و نامعتبر با استفاده از زمینه تست بذر» منجر به ایجاد فایلی در مسیر specs/login-plan.md می‌شود. این مرحله دقیقاً مشابه فرآیند معمول QA در نوشتن مستندات موارد تست است، با این تفاوت که عامل آن را به‌طور خودکار تولید می‌کند.

عامل تولیدکننده (Generator Agent) این برنامه‌های Markdown را به کدهای اجرایی TypeScript تبدیل می‌کند. برخلاف ابزارهای عمومی هوش مصنوعی، این عامل با مرورگر زنده تعامل دارد تا انتخاب‌گرها (Selectors) را اعتبارسنجی کرده و مطمئن شود که ادعاهای تست (Assertions) بازتاب‌دهنده رفتار واقعی UI هستند. این عامل می‌تواند الگوهای معماری حرفه‌ای مانند مدل شیء صفحه (Page Object Model یا POM) را پیاده کند تا کد نهایی مقیاس‌پذیر باشد. یک پرامپت نمونه برای این عامل می‌تواند این باشد: «کد تست Playwright را به زبان TypeScript برای برنامه تست موجود در specs/amazon-search-add-to-cart.plan.md تولید کن. در صورت لزوم از مدل شیء صفحه استفاده کن و داده‌های تست را از testdata/seed.json بردار.»

عامل ترمیم‌کننده (Healer Agent) سخت‌ترین بخش اتوماسیون، یعنی تست‌های ناپایدار یا Flaky را هدف قرار می‌دهد. وقتی تستی به‌دلیل تغییر در UI، مانند به‌روزرسانی برچسب یک دکمه، شکست می‌خورد، این عامل سناریو را در حالت دیباگ بازپخش کرده، DOM را بررسی می‌کند و به‌طور خودکار پیشنهاداتی برای اصلاح لوکیتورها یا منطق تعامل ارائه می‌دهد تا شکست را برطرف کند. با فراخوانی آن از طریق پرامپتی مانند «تست شکست‌خورده tests/amazon-search-add-to-cart-edge.spec.spec.ts را اجرا و اصلاح کن»، این عامل چرخه‌های تکراری دیباگ دستی را کاهش می‌دهد. این عامل می‌تواند تشخیص دهد که آیا تست به یک به‌روزرسانی لوکیتور نیاز دارد یا اینکه شکست، نشان‌دهنده یک باگ واقعی در قابلیت نرم‌افزار است.

پیاده‌سازی و جریان کاری

برای راه‌اندازی این محیط، یک پروژه استاندارد Node با بسته @playwright/test لازم است. فرآیند با ایجاد یک دایرکتوری و مقداردهی اولیه پروژه آغاز می‌شود:

• mkdir playwright-agent-demo
• cd playwright-agent-demo
• npm init -y
• npm install -D @playwright/test
• npx playwright install

سپس کاربران عامل‌ها را با دستور npx playwright init-agents --loop=vscode مقداردهی می‌کنند که ساختار دایرکتوری خاصی را ایجاد می‌کند:

• .github/agents/: شامل فایل‌های تعریف عامل (playwright-test-planner.agent.md ، playwright-test-generator.agent.md و playwright-test-healer.agent.md) است که رفتار هوش مصنوعی را هدایت می‌کنند. این فایل‌ها توسط ابزارهای AI مانند Claude Code، VS Code Copilot یا OpenCode استفاده می‌شوند.
• specs/: محل ذخیره برنامه‌های تست Markdown که توسط برنامه‌ریز تولید شده‌اند.
• tests/: محل قرارگیری اسکریپت‌های نهایی و اجرایی Playwright.

بوت‌استرپینگ زمینه‌ای

برای اثربخشی عامل‌ها، سیستم به یک فایل seed.spec.ts متکی است. این فایل محیط را بوت‌استرپ (آماده‌سازی) کرده و به هوش مصنوعی می‌گوید کاوش را از کجا شروع کند، مثلاً هدایت به یک صفحه لندینگ خاص یا مدیریت احراز هویت. یک نمونه تست بذر می‌تواند شامل موارد زیر باشد:

import { test, expect } from '@playwright/test';

test.describe('Test group', () => {
  test('seed', async ({ page }) => {
    await page.goto('http://www.amazon.in');
    await expect(page).toHaveTitle(/Amazon.in/);
    await page.click('text=Amazon Basics');
  });
});

علاوه بر این، فایل‌های JSON اختیاری در پوشه testdata/ اطلاعات لازم برای تست‌های لبه‌ای (Edge-case)، مانند نام‌های کاربری و رمزهای عبور معتبر و نامعتبر را فراهم می‌کنند. برای مثال، یک فایل seed.json ممکن است به این شکل تعریف شود:

{
  "validUser": {
    "username": "qa_user",
    "password": "Password@123"
  },
  "invalidUser": {
    "username": "user_qa",
    "password": "wrong_pass"
  }
}

حلقهٔ عامل‌محور در عمل

قدرت واقعی در «حلقهٔ عامل‌محور» نهفته است: برنامه‌ریز $\rightarrow$ تولیدکننده $\rightarrow$ ترمیم‌کننده. کاربر پرامپتی برای یک قابلیت می‌دهد، برنامه‌ریز مشخصات (Spec) را می‌سازد، تولیدکننده کد می‌زند و ترمیم‌کننده آن را نگهداری می‌کند. این حلقه به هوش مصنوعی اجازه می‌دهد فایل‌های پروژه را بخواند، تست‌ها را اجرا کند و DOM زنده را در لحظه بازرسی نماید.

در پس‌زمینه، این پیچیدگی‌ها انتزاع شده‌اند. برنامه‌ریز از تست بذر برای درک جریان‌ها استفاده می‌کند، تولیدکننده هنگام نوشتن اسکریپت‌ها لوکیتورها را در لحظه اعتبارسنجی می‌کند و ترمیم‌کننده تست‌های شکست‌خورده را برای شناسایی مشکلات بازپخش می‌کند. کاربران صرفاً پرامپت‌ها را ارائه می‌دهند و برنامه‌های ساختاریافته یا اسکریپت‌های اجرایی را دریافت می‌کنند.

این رویکرد اساساً با ابزارهایی مثل Cursor یا ChatGPT متفاوت است. در حالی که AIهای عمومی بر اساس پرامپت‌های استاتیک کد می‌زنند، عامل‌های Playwright از پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) استفاده می‌کنند تا با اپلیکیشن در حال اجرا تعامل داشته باشند. این آگاهی از زمینه (Context-awareness) به این معناست که AI قبل از نوشتن خط کد برای کلیک روی یک دکمه، می‌داند که آیا آن دکمه واقعاً در صفحه وجود دارد یا خیر.

مقایسه: عامل‌های Playwright در برابر AI عمومی

مقیاس‌پذیری حرفه‌ای با POM

برای جلوگیری از تبدیل کد به یک «توده نامنظم» (Big Ball of Mud)، تولیدکننده را می‌توان مجبور به استفاده از مدل شیء صفحه (POM) کرد. اگر پرامپت دهید: «از مدل شیء صفحه استفاده کن و لوکیتورها را در فایل‌های صفحه مجزا ذخیره کن»، تولیدکننده یک معماری ساختاریافته خروجی می‌دهد:

• pages/login.page.ts: شامل تعریف لوکیتورها و اکشن‌های قابل استفاده مجدد صفحه.
• tests/login/login.spec.ts: استفاده از شیء صفحه و داده‌های بذر برای منطق تست.

این جداسازی تضمین می‌کند که وقتی یک المان UI تغییر می‌کند، عامل ترمیم‌کننده فقط نیاز دارد یک شیء صفحه واحد را به‌روز کند، نه ده‌ها فایل تست مجزا، که منجر به یک فریم‌ورک قابل نگهداری و مقیاس‌پذیر می‌شود.

بهترین روش‌های استقرار

برای تیم‌هایی که این سیستم را پیاده می‌کنند، راهنما چندین نکته عملی را پیشنهاد می‌کند:

• ارائه زمینهٔ دقیق: همیشه یک تست بذر شفاف ارائه دهید، از داده‌های بذر ساختاریافته استفاده کنید و به جزئیات محیطی اشاره کنید.
• نوشتن پرامپت‌های صریح: مطمئن شوید پرامپت‌ها شامل ترجیحات معماری، مراجع داده‌های تست و خروجی‌های مورد انتظار باشند.
• بازبینی انسانی: AI می‌تواند کدهای اولیه (Boilerplate) عالی تولید کند، اما بازبینی انسانی همچنان برای اطمینان از صحت منطق تست‌ها ضروری است.
• ادغام محتاطانه در CI: با تست‌های ترمیم‌شده و تولیدشده به عنوان «پیش‌نویس» برخورد کنید تا زمانی که کاملاً بازبینی شوند؛ این کار برای جلوگیری از این است که AI یک باگ رگرسیون واقعی را با نادیده گرفتن آن، «ترمیم» کند.

این تحول، نقش مهندس QA را از یک «نویسنده اسکریپت» به یک «ارکستراتور» تغییر می‌دهد. تمرکز از سینتکس لوکیتورها به استراتژی پوشش تست و کیفیت پرامپت‌هایی که عامل‌ها را هدایت می‌کنند، منتقل می‌شود.

برای شروع آزمایش، مهندسان باید حلقهٔ عامل‌ها را مقداردهی کرده و یک تست بذر قدرتمند بسازند تا زمینه محیطی لازم را در اختیار AI قرار دهند. با انتقال از نوشتن دستی اسکریپت‌ها به یک چرخه حیات به کمک AI، تیم‌ها می‌توانند هزینه‌های عملیاتی را به‌طور قابل توجهی کاهش داده و پایداری را افزایش دهند.

گام بعدی شما

• حلقهٔ عامل‌ها را با دستور init-agents در یک پروژه کوچک راه‌اندازی کنید.
• یک تست بذر (Seed Test) جامع بنویسید تا مدل زمینهٔ محیطی شما را به‌درستی درک کند.
• برای تست‌های حساس، از الگوی POM استفاده کنید تا هزینه ترمیم در آینده کاهش یابد.

اما تأثیر این رویکرد بر هزینه‌های زیرساختی استنتاج در مقیاس سازمانی موضوع دیگری است — به تحلیل ما درباره‌ی بهینه‌سازی هزینه‌های GPU مراجعه کنید.