Amir Jabbari
وقتی یک سایت فروشگاهی، پنل مدیریتی، سامانه SaaS یا حتی وب‌سایت خدماتی بزرگ می‌شود، فقط سالم بودن کد کافی نیست. ممکن است صفحه اصلی بدون مشکل باز شود، اما دکمه ورود کار نکند، فرم ثبت‌نام در یک مرحله متوقف شود، بعد از Login کاربر به صفحه اشتباه برود یا یک Workflow مهم فقط در شرایط خاص شکست بخورد.
اینجاست که AI QA Tester وارد می‌شود؛ یک Agent هوش مصنوعی که می‌تواند در محیط مرورگر حرکت کند، صفحه‌ها را ببیند، روی دکمه‌ها کلیک کند، اطلاعات آزمایشی وارد کند، Login را بررسی کند، نتیجه هر مرحله را ارزیابی کند و در صورت مشاهده مشکل، شواهدی مثل Screenshot و گزارش خطا تولید کند.
📌 در این آموزش چه می‌سازیم؟
یک معماری عملی برای اجرای AI QA Tester روی VPS می‌سازیم که در آن Agent برای تصمیم‌گیری و کشف مسیرهای تست استفاده می‌شود و Playwright وظیفه کنترل دقیق مرورگر و اجرای تست را بر عهده دارد. در پایان، می‌توانید یک Workflow مانند Login، ثبت فرم، ورود به Dashboard و بررسی نتیجه را به‌صورت خودکار آزمایش کنید.
چرا تست دستی سایت دیگر برای همه Workflowها کافی نیست؟
تست دستی برای پیدا کردن بعضی خطاها ضروری است، اما یک مشکل اساسی دارد: انسان نمی‌تواند بعد از هر تغییر کوچک، تمام مسیرهای مهم سایت را بارها و با نظم یکسان اجرا کند. هرچه تعداد صفحات و قابلیت‌ها بیشتر شود، احتمال جا ماندن یک مسیر هم افزایش پیدا می‌کند.
فرض کنید یک فروشگاه اینترنتی دارید. برای بررسی کامل مسیر خرید باید صفحه ورود، بازیابی رمز، جست‌وجو، صفحه محصول، افزودن به سبد، Checkout، فرم آدرس، پرداخت آزمایشی و صفحه نتیجه را بررسی کنید. اگر فقط یکی از این مراحل بعد از انتشار نسخه جدید خراب شود، تست صفحه اصلی به‌تنهایی چیزی را نشان نمی‌دهد.
AI QA Tester رویکرد متفاوتی دارد. به جای اینکه فقط بپرسیم «آیا صفحه باز می‌شود؟»، می‌توانیم هدف بدهیم:
🔹 وارد صفحه Login شو.
🔹 با حساب تست وارد شو.
🔹 بررسی کن Dashboard نمایش داده شود.
🔹 به بخش پروفایل برو.
🔹 یک مقدار مجاز را تغییر بده.
🔹 نتیجه را بررسی کن و اگر مرحله‌ای شکست خورد، علت و شواهد آن را گزارش کن.
این همان نقطه‌ای است که تست مرورگرمحور و Agentic QA از تست‌های ساده HTTP یا بررسی Status Code فراتر می‌رود. Playwright برای تست End-to-End طراحی شده و از Chromium، Firefox و WebKit پشتیبانی می‌کند. :contentReference[oaicite:0]{index=0}
AI QA Tester دقیقاً چه کاری انجام می‌دهد؟
AI QA Tester را بهتر است یک «کاربر مصنوعی قابل کنترل» بدانیم؛ با این تفاوت که می‌تواند نتیجه هر مرحله را ثبت و تحلیل کند و اجرای آن را در زمان‌های مختلف تکرار کند.
| قابلیت | کاری که Agent انجام می‌دهد | نمونه نتیجه |
|---|---|---|
| Navigation | صفحه‌ها را باز و مسیرها را دنبال می‌کند. | صفحه Login با موفقیت باز شد. |
| Click | دکمه‌ها و عناصر تعاملی را آزمایش می‌کند. | دکمه ورود کلیک شد اما Dashboard ظاهر نشد. |
| Forms | فیلدها را پر و Validation را بررسی می‌کند. | فرم با ایمیل نامعتبر پیام خطای مناسب نمایش داد. |
| Login | ورود با حساب تست و بررسی Session را انجام می‌دهد. | ورود موفق بود و نام کاربر در Dashboard دیده شد. |
| Screenshot | از وضعیت مهم صفحه تصویر می‌گیرد. | Screenshot مرحله شکست ذخیره شد. |
| Bug Report | مشکل را به شکل ساختاریافته گزارش می‌کند. | مرحله، Expected، Actual و شواهد ثبت شدند. |
معماری پیشنهادی AI QA روی VPS
برای ساخت یک سیستم قابل اتکا، بهتر است همه چیز را به یک Agent آزاد و بدون محدودیت نسپاریم. معماری مناسب ترکیبی از Agent + Browser Automation + Assertion + Evidence است.
معماری ساده سیستم
🔹 Test Planner: سناریوی مورد آزمایش را مشخص می‌کند.
🔹 AI Agent: بر اساس هدف، مسیر مناسب را در مرورگر انتخاب می‌کند.
🔹 Playwright: عملیات مرورگر را اجرا می‌کند.
🔹 Assertions: نتیجه را با معیارهای قطعی بررسی می‌کنند.
🔹 Evidence: Screenshot، URL، خطا و اطلاعات مرحله را ذخیره می‌کند.
🔹 Bug Reporter: خروجی قابل فهم برای توسعه‌دهنده تولید می‌کند.
این تفکیک اهمیت زیادی دارد. در معماری‌های Agentic Testing، بهتر است هوش مصنوعی مسیر و تصمیم‌گیری را مدیریت کند، اما «درست یا غلط بودن» نتیجه با Assertionهای قابل تکرار بررسی شود. این موضوع در راهنماهای جدید تست Agentic با Playwright نیز به‌عنوان یک اصل مهم مطرح شده است. :contentReference[oaicite:1]{index=1}
چرا VPS برای AI QA Tester مناسب است؟
اگر قرار است تست فقط یک بار اجرا شود، اجرای محلی ممکن است کافی باشد. اما وقتی می‌خواهید تست‌ها هر شب، بعد از Deploy یا حتی چند بار در روز اجرا شوند، داشتن یک محیط همیشه‌روشن مزیت مهمی ایجاد می‌کند.
در VPS می‌توانید مرورگر Headless، Agent، فایل‌های گزارش، Screenshotها و Scheduler را در یک محیط مستقل نگه دارید. در نتیجه اجرای تست به روشن بودن کامپیوتر شخصی شما وابسته نیست.
| منبع | تأثیر روی AI QA | پیشنهاد اولیه |
|---|---|---|
| CPU | اجرای مرورگر و پردازش Agent | حداقل 2 تا 4 هسته برای شروع |
| RAM | Browser + Python + Agent | حدود 4 تا 8GB برای سناریوهای سبک |
| Storage | Browser، گزارش و Screenshot | NVMe و فضای قابل توسعه |
| Network | دسترسی به سایت و API مدل | اتصال پایدار و تأخیر مناسب |
| GPU | فقط در معماری‌های خاص Local AI مهم می‌شود. | برای شروع معمولاً ضروری نیست. |
نکته: این منابع مقدار ثابت و اجباری نیستند. تعداد Browser Sessionها، مدل زبانی، اندازه Screenshotها، تعداد Workflowها و موازی‌سازی مستقیماً روی مصرف VPS اثر می‌گذارند.
انتخاب Playwright یا Computer-Use Agent؟
این دو فناوری رقیب مطلق نیستند. Playwright برای اجرای کنترل‌شده و قابل تکرار فوق‌العاده است؛ Computer-Use یا Browser Agent زمانی جذاب می‌شود که بخواهید Agent مانند کاربر با صفحه تعامل کند و در مسیرهای کمتر از پیش‌تعریف‌شده تصمیم بگیرد.
| سناریو | Playwright | AI Browser Agent |
|---|---|---|
| Regression Test ثابت | مناسب | قابل استفاده |
| Exploratory Testing | نیازمند طراحی تست | مناسب‌تر برای کشف مسیر |
| Workflow کاملاً مشخص | بسیار مناسب | قابل استفاده |
| رابط کاربری غیرقابل پیش‌بینی | ممکن است به نگهداری بیشتری نیاز داشته باشد. | انعطاف بیشتری دارد. |
| Assertion قطعی | مناسب | بهتر است با Assertion ترکیب شود. |
پروژه‌های جدیدی مانند Browser Use نیز امکان اجرای Agent روی مرورگر را فراهم می‌کنند و مستندات پروژه، استفاده از Python و Playwright را در کنار Agent نشان می‌دهد. :contentReference[oaicite:2]{index=2}
نصب محیط AI QA روی VPS
در این نمونه از Ubuntu 22.04 یا 24.04 و Python استفاده می‌کنیم. برای محیط واقعی بهتر است Agent را با کاربر غیر root اجرا کنید و مرورگر را داخل محیط محدودشده قرار دهید.
۱. ساخت محیط Python
sudo apt install -y python3 python3-venv python3-pipmkdir -p ~/ai-qa-tester
cd ~/ai-qa-testerpython3 -m venv .venv
source .venv/bin/activate
python -m pip install –upgrade pip
اگر نسخه Python مورد استفاده با نسخه جاری کتابخانه انتخابی سازگار است، محیط مجازی جداگانه کمک می‌کند وابستگی‌های پروژه QA با سایر سرویس‌های VPS تداخل پیدا نکنند.
۲. نصب Playwright
playwright install –with-deps chromium
طبق مستندات رسمی Playwright، نصب Browser Binary جدا از نصب کتابخانه انجام می‌شود و برای محیط‌های Linux/CI می‌توان وابستگی‌های سیستم را نیز با install –with-deps نصب کرد. :contentReference[oaicite:3]{index=3}
۳. نصب Browser Use
uvx browser-use install
روش نصب ممکن است با انتشار نسخه‌های جدید تغییر کند؛ بنابراین قبل از اجرای Production، مستندات نسخه‌ای که نصب می‌کنید را بررسی کنید. راهنمای فعلی پروژه Browser Use نیز نصب محیط Python و Browser را به همین شکل توضیح می‌دهد. :contentReference[oaicite:4]{index=4}
ساخت سناریوی واقعی تست Login
حالا بخش جذاب ماجرا شروع می‌شود. به جای اینکه فقط یک Browser را باز کنیم، یک هدف قابل اندازه‌گیری برای Agent تعریف می‌کنیم.
سناریوی تست
«به صفحه Login برو، با حساب تست وارد شو، بررسی کن Dashboard نمایش داده شود، سپس به صفحه پروفایل برو. اگر هر مرحله شکست خورد، URL، توضیح خطا و Screenshot مرحله شکست را ثبت کن.»
این روش نسبت به نوشتن یک تست بسیار محدود، امکان بررسی یک Workflow واقعی را فراهم می‌کند. البته برای محیط Production بهتر است بخش‌های حساس با Assertionهای دقیق پوشش داده شوند.
نمونه اجرای Agent
from browser_use import Agent, ChatBrowserUseasync def main():
llm = ChatBrowserUse()“`
task = “””
Test the login workflow of the website.
1. Open the login page.
2. Use the dedicated test account.
3. Submit the login form.
4. Verify that the dashboard is visible.
5. Navigate to the profile page.
6. If any step fails, describe the failure clearly.
7. Do not modify production data.
“””
agent = Agent(
task=task,
llm=llm
)
result = await agent.run()
print(result)
“`
if **name** == “**main**”:
asyncio.run(main())
این نمونه عمداً Credentials واقعی را داخل کد قرار نمی‌دهد. برای محیط عملیاتی باید اطلاعات ورود در Secret یا Environment Variable نگهداری شود و حساب تست، دسترسی محدود داشته باشد.
چطور اطلاعات Login را امن نگه داریم؟
یکی از خطرناک‌ترین اشتباهات در ساخت QA Agent این است که نام کاربری و رمز عبور را داخل Prompt، Git Repository یا فایل عمومی پروژه قرار دهیم.
⚠️ حساب تست را مثل حساب Administrator طراحی نکنید
🔹 حساب مخصوص QA بسازید.
🔹 اطلاعات مالی و داده حساس واقعی در اختیار آن قرار ندهید.
🔹 دسترسی Agent را به Domainهای موردنیاز محدود کنید.
🔹 برای عملیات حذف، پرداخت یا تغییرات حساس، تأیید انسانی در نظر بگیرید.
🔹 Session و Credential را در Log چاپ نکنید.
مستندات فعلی Browser Use نیز روی محدود کردن Domainها، استفاده از Session/Storage State و مدیریت Credentials حساس تأکید دارد. :contentReference[oaicite:5]{index=5}
ساخت تست قطعی با Playwright در کنار Agent
برای اینکه نتیجه تست فقط بر اساس برداشت مدل زبانی نباشد، یک Assertion قطعی اضافه می‌کنیم. مثلاً Agent می‌تواند وارد Dashboard شود، اما Playwright بررسی کند که عنصر مشخصی واقعاً وجود دارد.
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
“`
page.goto(“https://example.com/login”)
page.get_by_label(“Email”).fill(“qa@example.com”)
page.get_by_label(“Password”).fill(“TEST_PASSWORD”)
page.get_by_role(“button”, name=”Login”).click()
page.get_by_role(“heading”, name=”Dashboard”).wait_for()
print(“LOGIN TEST PASSED”)
browser.close()
“`
Playwright در تست‌های خود Locatorهای معنایی مانند Role و Text را پشتیبانی می‌کند و Codegen آن نیز می‌تواند برای شروع تست، تعاملات مرورگر را به کد تبدیل کند. :contentReference[oaicite:6]{index=6}
AI QA Tester چه Bugهایی را می‌تواند پیدا کند؟
🔹 دکمه‌ای که کلیک می‌شود اما هیچ اتفاقی نمی‌افتد.
🔹 فرم‌هایی که Validation نادرست دارند.
🔹 Login موفقی که به Dashboard منتقل نمی‌شود.
🔹 لینک‌هایی که به مسیر اشتباه می‌روند.
🔹 Workflowهایی که در یک مرحله متوقف می‌شوند.
🔹 خطاهای JavaScript قابل مشاهده در فرآیند تست.
🔹 مشکلات ظاهری واضح در صفحه.
🔹 تغییرات UI که باعث شکست مسیرهای قبلی شده‌اند.
در پژوهش‌های جدید Agentic Testing نیز مسئله کشف Bugهای واقعی در تعاملات طولانی وب به‌عنوان یک چالش مهم مطرح شده است؛ بنابراین نباید تصور کرد که یک Agent بدون طراحی تست و کنترل خروجی می‌تواند جایگزین کامل QA انسانی شود. :contentReference[oaicite:7]{index=7}
📌 AI باید دنبال Bug بگردد، اما معیار قبولی باید قابل اندازه‌گیری باشد
بهترین معماری این نیست که مدل بگوید «به نظر می‌رسد Login درست است». بهتر است مدل مسیر را اجرا کند و سیستم تست با معیارهایی مانند URL، وجود Element، Status، متن صفحه، Cookie، Redirect و نتیجه فرم، صحت Workflow را مشخص کند.
ساخت Bug Report حرفه‌ای
گزارش «Login خراب است» برای توسعه‌دهنده چندان مفید نیست. گزارش باید بتواند مسیر بازتولید مشکل را مشخص کند.
| فیلد | نمونه |
|---|---|
| عنوان | Login با Credential معتبر به Dashboard منتقل نمی‌شود |
| URL | /login |
| Steps | باز کردن Login → ورود اطلاعات → کلیک Login |
| Expected | Dashboard نمایش داده شود. |
| Actual | کاربر در صفحه Login باقی می‌ماند. |
| Evidence | Screenshot + Log + زمان اجرا |
ذخیره Screenshot و Trace برای پیدا کردن علت خطا
وقتی تست Fail می‌شود، مهم است که فقط یک پیام متنی ذخیره نکنیم. تصویر صفحه و Trace می‌تواند مشخص کند Agent دقیقاً در چه وضعیتی قرار داشته است.
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
“`
context = browser.new_context(
record_video_dir=”artifacts/video”
)
page = context.new_page()
try:
page.goto(“https://example.com/login”)
page.screenshot(path=”artifacts/login.png”, full_page=True)
# Run your test steps here.
except Exception as error:
page.screenshot(
path=”artifacts/failure.png”,
full_page=True
)
print(“QA FAILURE:”, error)
finally:
context.close()
browser.close()
“`
در یک پروژه واقعی می‌توانید پوشه‌ای برای هر Run بسازید تا گزارش‌ها با هم قاطی نشوند؛ مثلاً runs/2026-10-03/login-test/.
باکس تبلیغاتی: چرا اجرای AI QA روی VPS اهمیت دارد؟
یک VPS همیشه‌روشن برای تست‌های خودکار سایت
اگر قرار است AI QA Tester هر شب Workflowهای سایت را اجرا کند، Browser Agent و فایل‌های گزارش را نگه دارد و بعد از هر Deploy تست Regression انجام دهد، اجرای آن روی کامپیوتر شخصی انتخاب مناسبی برای یک سرویس دائمی نیست. یک سرور مجازی می‌تواند محیط مستقلی برای Agent، Chromium، Playwright و ذخیره گزارش‌ها فراهم کند.
در ایرانیکاسرور می‌توانید VPS متناسب با تعداد تست‌ها، مصرف RAM مرورگر، تعداد Sessionهای هم‌زمان و حجم گزارش‌های خود انتخاب کنید و محیط AI QA را جدا از سیستم اصلی توسعه اجرا کنید.
📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
اجرای تست‌ها به‌صورت دوره‌ای
بعد از اینکه تست‌ها پایدار شدند، مرحله بعدی اجرای خودکار آن‌هاست. برای نمونه می‌توانید تست Login را هر شب اجرا کنید یا بعد از Deploy نسخه جدید، مجموعه‌ای از Workflowها را اجرا کنید.
در لینوکس می‌توان از Cron، Systemd Timer یا یک CI/CD Pipeline استفاده کرد. برای شروع، Cron ساده‌ترین گزینه است.
برای مثال:
در این حالت تست هر روز ساعت ۳ بامداد اجرا می‌شود. برای پروژه‌های حساس‌تر بهتر است اجرای تست، ذخیره Artifact، هشدار و Retention گزارش‌ها نیز به شکل ساختاریافته طراحی شود.
چطور AI QA را بعد از هر Deploy اجرا کنیم؟
یکی از کاربردهای جذاب‌تر این معماری، اتصال تست مرورگر به فرآیند انتشار است. روند می‌تواند به شکل زیر باشد:
🔹 توسعه‌دهنده نسخه جدید را Deploy می‌کند.
🔹 Pipeline تست Smoke را اجرا می‌کند.
🔹 AI QA Tester وارد سایت می‌شود.
🔹 Login و Workflowهای اصلی اجرا می‌شوند.
🔹 Assertionهای قطعی نتیجه را بررسی می‌کنند.
🔹 در صورت شکست، Screenshot و گزارش تولید می‌شود.
🔹 تیم توسعه قبل از ادامه انتشار، نتیجه را بررسی می‌کند.
این مدل باعث می‌شود QA از یک مرحله جداگانه در پایان توسعه، به بخشی از چرخه انتشار تبدیل شود.
چه تست‌هایی را برای سایت خودکار کنیم؟
| Workflow | تست پیشنهادی | اهمیت |
|---|---|---|
| Login | ورود موفق و ناموفق | بالا |
| Registration | Validation و ساخت حساب تست | بالا |
| Search | جست‌وجوی عبارت و نتیجه | متوسط |
| Checkout | سبد تا صفحه پرداخت تست | بسیار بالا |
| Contact Form | ارسال و Validation | بالا |
| Password Reset | درخواست بازیابی و نتیجه | بالا |
یک اشتباه مهم: اجازه ندهید Agent هر کاری انجام دهد
AI QA Tester باید برای تست طراحی شود، نه اینکه یک Agent با دسترسی کامل به سایت باشد. این تفاوت از نظر امنیتی بسیار مهم است.
⚠️ Agent را به حساب واقعی مدیر متصل نکنید.
⚠️ برای تست پرداخت از محیط Sandbox استفاده کنید.
⚠️ دسترسی Domainهای غیرضروری را محدود کنید.
⚠️ امکان Delete یا تغییر اطلاعات حساس را بدون کنترل فعال نکنید.
⚠️ نتیجه Agent را بدون Assertion و بررسی شواهد، مبنای قطعی سلامت سیستم قرار ندهید.
بهینه‌سازی VPS برای Browser Agent
مرورگرهای Chromium سبک نیستند؛ اگر چند Session هم‌زمان اجرا کنید، مصرف RAM و CPU به‌سرعت افزایش پیدا می‌کند. بنابراین قبل از افزایش تعداد Agentها، منابع VPS را اندازه‌گیری کنید.
🔹 Sessionهای غیرضروری را بعد از هر تست ببندید.
🔹 Screenshotهای قدیمی را پاک یا آرشیو کنید.
🔹 تعداد Browserهای هم‌زمان را محدود کنید.
🔹 تست‌های سنگین را در ساعات کم‌مصرف اجرا کنید.
🔹 مصرف CPU، RAM و Disk را هنگام اجرای چند تست هم‌زمان اندازه‌گیری کنید.
اگر VPS برای تست‌ها کند شد چه کنیم؟
اول باید مشخص کنید مشکل از Browser، Agent، مدل زبانی یا خود سایت است. برای این کار هنگام اجرای تست، مصرف منابع را بررسی کنید.
free -h
df -h
uptime
اگر چند Chromium هم‌زمان اجرا می‌شود و RAM پر شده است، افزایش تعداد Workerها مشکل را حل نمی‌کند؛ ابتدا باید تعداد Sessionهای هم‌زمان، Browser Lifecycle و حجم Artifactها مدیریت شوند.
📌 برای نصب یا تنظیم VPS مشکل دارید؟
اگر Chromium روی VPS اجرا نمی‌شود، وابستگی‌های سیستم مشکل دارند، منابع سرور برای چند Browser کافی نیست یا می‌خواهید محیط اجرای AI QA را اصولی کانفیگ کنید، می‌توانید درخواست بررسی و تنظیم سرور ارسال کنید.
ایرانیکاسرور می‌تواند در انتخاب منابع و تنظیم محیط سرور برای اجرای سرویس‌های نرم‌افزاری و Workflowهای خودکار به شما کمک کند.
📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
آیا AI QA می‌تواند جای QA Engineer را بگیرد؟
بهتر است به جای چنین فرضی، AI QA را به‌عنوان یک لایه جدید در فرآیند تست ببینیم. Agent می‌تواند تعداد زیادی مسیر را اجرا کند، سناریوهای اکتشافی بسازد و برای پیدا کردن مشکلات UI و Workflow زمان زیادی ذخیره کند؛ اما تصمیم‌های حساس، طراحی استراتژی تست، بررسی False Positiveها و تست‌های امنیتی همچنان به تخصص انسانی نیاز دارند.
حتی ارزیابی‌های پژوهشی سال ۲۰۲۶ نشان می‌دهند که Agentهای فعلی در تست‌های طولانی و پیچیده وب هنوز با مشکلاتی مانند ناقص بودن Coverage و ناپایداری تعاملات مواجه‌اند. :contentReference[oaicite:8]{index=8}
چک‌لیست ساخت AI QA Tester روی VPS
🔹 یک VPS با منابع متناسب با تعداد Browser Sessionها انتخاب کنید.
🔹 Python و محیط مجازی مستقل بسازید.
🔹 Playwright و Chromium را نصب کنید.
🔹 Browser Agent را نصب و پیکربندی کنید.
🔹 یک حساب مخصوص QA ایجاد کنید.
🔹 Credential را داخل Source Code قرار ندهید.
🔹 سناریوهای Login، Form و Workflow را تعریف کنید.
🔹 Assertionهای قطعی به تست‌ها اضافه کنید.
🔹 Screenshot و Log را برای Failure ذخیره کنید.
🔹 اجرای دوره‌ای با Cron یا CI/CD ایجاد کنید.
🔹 منابع VPS و تعداد Sessionهای هم‌زمان را مانیتور کنید.
جمع‌بندی؛ از تست ساده تا یک کارمند QA همیشه‌روشن
✅ AI QA Tester روی VPS چه چیزی به شما می‌دهد؟
یک محیط همیشه‌روشن برای اجرای تست‌های مرورگری، بررسی Login و فرم‌ها، آزمایش Workflowهای مهم، ثبت Screenshot و تولید گزارش Bug.
معماری پیشنهادی این مقاله به جای تکیه کامل بر AI، از ترکیب AI Agent برای تصمیم‌گیری، Playwright برای کنترل مرورگر و Assertion برای تشخیص قطعی نتیجه استفاده می‌کند.
اگر تعداد تست‌ها، Browser Sessionها یا Workflowهای شما افزایش پیدا کند، VPS می‌تواند محیط مناسبی برای اجرای مداوم این فرآیند فراهم کند؛ به‌خصوص زمانی که تست‌ها باید مستقل از کامپیوتر شخصی و به‌صورت زمان‌بندی‌شده اجرا شوند.
منابع و مستندات پیشنهادی برای ادامه کار
برای یادگیری اجرای تست‌های Browser با Playwright می‌توانید مستندات رسمی Playwright Python را مطالعه کنید. :contentReference[oaicite:9]{index=9}
برای نصب Browser و وابستگی‌های Chromium نیز راهنمای رسمی مرورگرهای Playwright مفید است. :contentReference[oaicite:10]{index=10}
برای ساخت Agentهای مرورگرمحور می‌توانید مخزن رسمی Browser Use را بررسی کنید. :contentReference[oaicite:11]{index=11}
📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور
دیدگاه‌ها (۰)