تست نرم افزار

شروع تست خودکار از صفر؛ نقشه راه ۸ هفته‌ای QA Automation

انتشار در تاریخ توسط محمد عسکری

بزرگ‌ترین اشتباه در شروع تست خودکار، نصب یک ابزار قبل از انتخاب مسئله است. بسیاری از تسترها چند هفته Selenium یا Playwright می‌خوانند، اما هنوز نمی‌دانند چه تستی ارزش خودکارسازی دارد، Assertion خوب چیست یا اسکریپتشان چگونه در CI اجرا می‌شود. نتیجه معمولاً چند تست نمایشی و شکننده است، نه یک نمونه‌کار قابل‌اعتماد.

این راهنما برای تستر دستی، دانشجو یا توسعه‌دهنده‌ای نوشته شده که می‌خواهد تست خودکار را از صفر شروع کند. پیش‌نیازها، انتخاب مسیر و ابزار، برنامه هشت‌هفته‌ای، پروژه نمونه فروشگاه اینترنتی، ساختار حداقلی فریمورک و نکات ساخت Portfolio برای بازار کار QA را قدم‌به‌قدم بررسی می‌کنیم. برای تعریف، مزایا و استراتژی سازمانی، مقاله جداگانه اتوماسیون تست چیست را بخوانید.

فهرست مطالب

قبل از یادگیری تست خودکار چه پیش‌نیازهایی داریم؟

برای شروع لازم نیست برنامه‌نویس ارشد باشید، اما اتوماسیون تست «کلیک ضبط‌شده» نیست؛ کدی است که باید قابل‌اعتماد، قابل‌نگهداری و قادر به تشخیص شکست واقعی باشد.

۱. مبانی تست نرم‌افزار

  • تفاوت Test Scenario، Test Case و Test Data؛
  • طراحی تست مثبت، منفی و مرزی؛
  • تفاوت Smoke، Regression و Retest؛
  • نتیجه مورد انتظار و Assertion قابل‌اندازه‌گیری؛
  • ریسک، اولویت و انتخاب تست مناسب برای اتوماسیون؛
  • درک اینکه تست خودکار جای تست اکتشافی و قضاوت انسانی را نمی‌گیرد.

اگر هنوز در انتخاب میان اجرای دستی و خودکار تردید دارید، راهنمای تست دستی در مقابل تست خودکار را ابتدا مرور کنید.

۲. برنامه‌نویسی پایه

در زبان انتخابی باید متغیر، نوع داده، شرط، حلقه، تابع، کلاس/ماژول، آرایه و Object، مدیریت خطا و کار با Promise یا Async را بدانید. هدف حفظ Syntax نیست؛ باید بتوانید شکست تست را Debug و کد تکراری را اصلاح کنید.

۳. وب و HTTP

  • HTML، DOM و نقش Attributeها؛
  • CSS Selector در حد خواندن و Debug؛
  • Request/Response، Method و Status Code؛
  • JSON، Header، Cookie، Session و Token؛
  • استفاده از Browser DevTools و تب Network.

۴. Git و خط فرمان

ساخت Repository، Commit، Branch، Pull Request و اجرای دستور در Terminal برای کار تیمی و CI ضروری‌اند. لازم نیست از روز اول Git پیشرفته بلد باشید؛ اما پروژه نمونه بدون تاریخچه نسخه، ارزش حرفه‌ای کمتری دارد.

ابتدا مسیر اتوماسیون خود را انتخاب کنید

یادگیری هم‌زمان وب، موبایل، API و Performance سرعت شما را کم می‌کند. یک مسیر اصلی انتخاب کنید و پس از ساخت پروژه واقعی، مسیر دوم را اضافه کنید.

مسیر برای چه محصولی؟ دانش کلیدی ابزارهای نمونه
Web UI وب‌سایت و پنل تحت مرورگر DOM، Locator، انتظار، مرورگر Playwright، Selenium، Cypress
API Backend و Microservice HTTP، JSON، Auth، Schema Postman/Newman، REST Assured، pytest
Mobile Android و iOS App lifecycle، Device، Locator موبایل Appium، Espresso، XCUITest
Performance سرویس پرترافیک Workload، Metric، تحلیل نتیجه k6، JMeter، Gatling

برای شروع حرفه‌ای، تست API معمولاً بازخورد سریع‌تر و نگهداری کمتری از UI دارد. اگر هدف شغلی شما Web Automation است، ترکیب یک مجموعه API کوچک با چند سناریوی مهم مرورگر، نمونه‌کار متعادل‌تری می‌سازد.

چگونه زبان و ابزار مناسب را انتخاب کنیم؟

ابزار «بهترین مطلق» وجود ندارد. فناوری محصول، زبان تیم، هدف شغلی، مستندات، جامعه، اجرای موازی، گزارش‌دهی و ادغام CI را بسنجید. راهنمای انتخاب ابزار تست اتوماسیون معیارهای کامل‌تری دارد.

Playwright

برای اتوماسیون مدرن وب، Playwright Test امکانات Runner، Assertion، Fixture، Trace و اجرای چندمرورگری را یکجا فراهم می‌کند. اگر با JavaScript/TypeScript راحت هستید، مسیر شروع منسجمی دارد. نصب و پروژه نمونه در مستندات رسمی Playwright ارائه شده است.

Selenium WebDriver

Selenium اکوسیستم قدیمی و گسترده‌ای دارد و از چند زبان پشتیبانی می‌کند. اگر تیم شما Java، C# یا Python دارد یا بازار هدف پروژه Selenium می‌خواهد، انتخاب منطقی است. راهنمای رسمی شروع Selenium WebDriver را مبنا قرار دهید و مقاله اولین تست با Selenium را نیز ببینید.

Appium

برای موبایل Cross-platform، Appium از اکوسیستم WebDriver استفاده می‌کند، اما تنظیم Driver، Emulator/Device و Capabilityها دانش اضافه می‌خواهد. نقطه شروع معتبر، Quickstart رسمی Appium است.

از کدام زبان شروع کنیم؟

  • TypeScript/JavaScript: مناسب Playwright/Cypress و تیم‌های وب؛
  • Java: رایج در سازمان‌های Enterprise و Selenium/REST Assured؛
  • Python: Syntax ساده، مناسب API، ابزار و داده؛
  • C#: انتخاب طبیعی برای اکوسیستم .NET.

اگر پروژه یا تیم واقعی دارید، زبان همان تیم معمولاً از ترجیح شخصی مهم‌تر است؛ بازبینی کد، کتابخانه مشترک و پشتیبانی آسان‌تر می‌شود.

چه تست‌هایی را اول خودکار کنیم؟

کاندیدای خوب معمولاً چند ویژگی دارد:

  • مکرر و زمان‌بر است؛
  • رفتار و نتیجه مورد انتظار پایدار و قابل‌اندازه‌گیری دارد؛
  • ریسک کسب‌وکار بالایی دارد؛
  • داده و پیش‌شرط آن قابل‌کنترل است؛
  • در هر Build یا Release باید اجرا شود؛
  • اجرای آن در سطح پایین‌تر ممکن نیست یا پوشش UI ارزش مشخصی دارد.

کاندیدای ضعیف: قابلیت بسیار ناپایدار، تست یک‌باره، ارزیابی زیبایی یا کاربردپذیری، سناریوی وابسته به CAPTCHA واقعی و تستی که نتیجه‌اش به قضاوت انسان نیاز دارد.

سناریو اولویت پیشنهادی دلیل
ورود کاربر فعال بالا حیاتی، پایدار و پرتکرار
محاسبه مبلغ سفارش بالا در Unit/API ریسک مالی و Assertion دقیق
رنگ و حس طراحی صفحه جدید دستی نیازمند قضاوت و بازخورد انسانی
فرم در حال بازطراحی هفتگی فعلاً پایین هزینه نگهداری بالا
رگرسیون ۲۰ حالت API بالا سریع، داده‌محور و مناسب CI

نقشه راه هشت‌هفته‌ای یادگیری تست خودکار

این برنامه برای مطالعه پاره‌وقت طراحی شده است. اگر زمان کمتر یا بیشتری دارید، ترتیب را حفظ و حجم را تنظیم کنید.

هفته ۱: تست و انتخاب مسئله

  • یک محصول نمونه و سه جریان پرریسک انتخاب کنید.
  • برای هر جریان تست دستی و نتیجه مورد انتظار بنویسید.
  • مشخص کنید کدام بخش در Unit/API/UI بهتر تست می‌شود.
  • Repository بسازید و README هدف پروژه را بنویسید.

هفته ۲: زبان برنامه‌نویسی

  • متغیر، تابع، شرط، آرایه، Object و Module تمرین کنید.
  • فایل JSON بخوانید و داده را Filter/Map کنید.
  • یک درخواست HTTP ساده بفرستید و پاسخ را Parse کنید.
  • تمرین‌ها را با Commitهای کوچک ثبت کنید.

هفته ۳: ابزار و اولین تست

  • Runner و ساختار Test/Suite را یاد بگیرید.
  • Setup، Action و Assertion را جدا ببینید.
  • یک تست عمداً شکست‌خورده بسازید تا مطمئن شوید Assertion واقعی است.
  • اجرا در Headed/Headless و Debug را تمرین کنید.

هفته ۴: Locator، Wait و Isolation

  • Locatorهای پایدار مانند Role، Label و Test ID را ترجیح دهید.
  • از Sleep ثابت و XPath شکننده دوری کنید.
  • هر تست را مستقل و با داده مخصوص خود اجرا کنید.
  • Screenshot، Video یا Trace شکست را فعال کنید.

هفته ۵: تست API و داده

  • Authentication، Header، Query و Body را تمرین کنید.
  • Status، Schema و قواعد کسب‌وکار را Assert کنید.
  • داده تست را با Factory یا Fixture بسازید.
  • Setup سریع را از API انجام دهید و UI را فقط برای رفتار کاربر نگه دارید.

برای مبانی، مقاله تست API چیست را بخوانید.

هفته ۶: طراحی قابل نگهداری

  • کد تکراری را به Helper یا Fixture منتقل کنید.
  • Selector را از منطق Assertion جدا نگه دارید.
  • Page Object را فقط جایی اضافه کنید که ارزش دارد.
  • نام تست را بر اساس رفتار و نتیجه بنویسید.
  • Code Review و Lint را اجرا کنید.

اصول SOLID، DRY و استقلال تست را در راهنمای نوشتن کد تست قابل نگهداری ببینید.

هفته ۷: گزارش و CI

  • تست‌ها را با یک دستور قابل‌تکرار اجرا کنید.
  • متغیر محیطی و Secret را از کد خارج کنید.
  • Pipeline بسازید که روی Pull Request تست سریع را اجرا کند.
  • Artifactهای شکست و گزارش JUnit/HTML را نگه دارید.
  • تست Flaky را Retry نامحدود نکنید؛ علت را پیدا کنید.

هفته ۸: تکمیل Portfolio

  • حداقل یک مسیر مثبت و چند حالت منفی/مرزی بسازید.
  • README شامل معماری، پیش‌نیاز، اجرای محلی و CI بنویسید.
  • Badge وضعیت Pipeline و نمونه گزارش اضافه کنید.
  • یک Issue نمونه برای باگ کشف‌شده ثبت کنید.
  • محدودیت‌ها و تصمیم‌های فنی را شفاف توضیح دهید.

پروژه نمونه: اتوماسیون یک فروشگاه اینترنتی

برای Portfolio، پروژه‌ای انتخاب کنید که نیاز به حساب واقعی، پرداخت واقعی یا داده شخصی نداشته باشد. یک فروشگاه Demo با API عمومی یا محیط آموزشی مناسب است.

دامنه پیشنهادی

  • ورود موفق و ناموفق؛
  • جست‌وجو و فیلتر محصول؛
  • افزودن و حذف از سبد؛
  • محاسبه جمع و تعداد کالا؛
  • تکمیل Checkout تا پیش از پرداخت واقعی؛
  • اعتبارسنجی API محصولات و سفارش؛
  • نمایش صحیح پیام خطا.

اولویت سطح تست

  • قواعد محاسبه را در API یا سطح پایین بررسی کنید.
  • فقط دو تا چهار مسیر حیاتی را End-to-End کنید.
  • Setup حساب و داده را از API انجام دهید تا UI سریع‌تر و پایدارتر بماند.
  • حالت فارسی را با RTL، ارقام، کد پستی و واحد تومان/ریال در صورت پشتیبانی محصول اضافه کنید.

نمونه تست ساده Playwright

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

test('کاربر می‌تواند یک محصول موجود را به سبد اضافه کند', async ({ page }) => {
  await page.goto('/products');

  const product = page.getByRole('article', { name: /هدفون/ });
  await product.getByRole('button', { name: 'افزودن به سبد' }).click();

  await expect(page.getByTestId('cart-count')).toHaveText('1');
  await expect(page.getByRole('status')).toContainText('به سبد اضافه شد');
});

کد واقعی باید با DOM محصول هماهنگ شود. نکته آموزشی این مثال، نام رفتاری تست، Locator قابل‌فهم و Assertion روی نتیجه کاربر است—نه صرفاً کلیک‌کردن.

فریمورک حداقلی چه اجزایی دارد؟

در شروع، فریمورک بزرگ نسازید. ساختار زیر برای یک پروژه کوچک کافی است:

tests/
  ui/
  api/
fixtures/
pages/
utils/
test-data/
playwright.config.ts
.env.example
README.md
  • tests: رفتارهای قابل‌اجرا، جداشده بر اساس سطح؛
  • fixtures: Setup و منابع مشترک کنترل‌شده؛
  • pages: تعامل‌های تکراری صفحه، نه Assertionهای کسب‌وکار همه تست‌ها؛
  • utils: ابزار عمومی کوچک و بدون وابستگی پنهان؛
  • test-data: داده غیرحساس و قابل‌نسخه‌بندی؛
  • config: Browser، Timeout، Reporter و پروژه‌های محیطی؛
  • .env.example: نام متغیرها بدون Secret واقعی؛
  • README: راهنمای اجرای قابل‌تکرار.

وقتی پروژه رشد کرد، بر اساس درد واقعی Pattern اضافه کنید. راهنمای انتخاب فریمورک اتوماسیون تست برای مرحله بعد مناسب است.

چگونه تست خودکار را وارد CI/CD کنیم؟

  1. اجرای محلی را به یک دستور پایدار تبدیل کنید.
  2. وابستگی و Browser را در محیط تمیز نصب کنید.
  3. Secret را در Secret Store پایپ‌لاین قرار دهید.
  4. روی Pull Request فقط تست‌های سریع و حیاتی را اجرا کنید.
  5. رگرسیون بزرگ‌تر را زمان‌بندی یا پیش از Release اجرا کنید.
  6. Report، Screenshot، Video و Trace شکست را Artifact کنید.
  7. شرط شکست Pipeline و مسئول رسیدگی را مشخص کنید.

یک نمونه عملی Jenkins/GitLab را در راهنمای راه‌اندازی پایپ‌لاین CI/CD برای تست خودکار ببینید.

چگونه کیفیت تست خودکار را بسنجیم؟

  • قابلیت کشف خطا: آیا تست با خراب‌شدن رفتار واقعاً قرمز می‌شود؟
  • پایداری: نرخ شکست تصادفی یا Flaky چقدر است؟
  • سرعت بازخورد: تست حیاتی چند دقیقه پس از تغییر نتیجه می‌دهد؟
  • نگهداری: تغییر کوچک UI چند فایل تست را می‌شکند؟
  • پوشش ریسک: کدام جریان‌های مهم پوشش دارند، نه فقط چند درصد کد؟
  • تشخیص‌پذیری: شکست با گزارش و Trace سریع قابل‌تحلیل است؟

تعداد اسکریپت معیار موفقیت نیست. صد تست سریع و قابل‌اعتماد از هزار تست Flaky ارزشمندتر است.

اشتباهات رایج در شروع Test Automation

  • انتخاب ابزار بر اساس ترند، بدون توجه به محصول و تیم؛
  • شروع از UI برای همه قوانین کسب‌وکار؛
  • خودکارسازی تستی که نتیجه مورد انتظار روشنی ندارد؛
  • استفاده از Sleep ثابت و Selector شکننده؛
  • وابستگی تست‌ها به ترتیب اجرا یا داده یکدیگر؛
  • ساخت فریمورک پیچیده پیش از اولین تست ارزشمند؛
  • قرار دادن Password و Token در Repository؛
  • استفاده از Retry برای پنهان‌کردن Flaky Test؛
  • نداشتن Assertion معنادار—تستی که فقط اجرا می‌شود؛
  • نادیده‌گرفتن نگهداری، Code Review و مالکیت تیمی.

چک‌لیست آماده شروع پروژه

  • یک مسئله و مسیر محصول مشخص انتخاب شده است.
  • تست دستی و نتیجه مورد انتظار پیش از کدنویسی روشن‌اند.
  • سطح مناسب Unit/API/UI برای هر سناریو انتخاب شده است.
  • زبان با تیم یا هدف شغلی هم‌راستاست.
  • ابزار مستندات رسمی و ادغام CI مناسب دارد.
  • داده تست مستقل و غیرحساس است.
  • هر تست مستقل، تکرارپذیر و دارای Assertion است.
  • شکست تست شواهد کافی برای Debug تولید می‌کند.
  • Pipeline سریع و مسئول رسیدگی به شکست مشخص است.
  • README به فرد دیگری اجازه اجرای پروژه را می‌دهد.

سوالات متداول

برای شروع تست خودکار برنامه‌نویسی لازم است؟

برای اتوماسیون قابل‌نگهداری بله، اما لازم نیست در آغاز پیشرفته باشید. مبانی زبان، Debug، Async و ساختار کد را هم‌زمان با یک پروژه کوچک یاد بگیرید. ابزار بدون کد نیز منطق تست و نگهداری می‌خواهد.

Playwright بهتر است یا Selenium؟

به زمینه بستگی دارد. Playwright برای پروژه وب مدرن تجربه یکپارچه‌ای دارد؛ Selenium پشتیبانی چندزبان و اکوسیستم بسیار گسترده دارد. زبان تیم، مرورگر هدف، زیرساخت و بازار شغلی را مقایسه کنید.

آیا از UI شروع کنیم یا API؟

اگر API در دسترس است، یادگیری و خودکارسازی قواعد در آن سطح معمولاً سریع‌تر و پایدارتر است. برای اثبات مسیر واقعی کاربر، چند تست UI حیاتی اضافه کنید.

چقدر زمان لازم است تا آماده بازار کار شویم؟

عدد ثابت وجود ندارد. معیار بهتر این است که بتوانید پروژه‌ای با تست پایدار، Git، API، گزارش، CI و توضیح تصمیم‌های فنی بسازید و شکست آن را Debug کنید. چند ماه تمرین منظم برای بسیاری از افراد واقع‌بینانه‌تر از دوره‌های بسیار کوتاه است.

آیا هوش مصنوعی یادگیری Automation را بی‌نیاز می‌کند؟

خیر. AI می‌تواند Syntax و کد اولیه را سریع‌تر کند، اما انتخاب پوشش، تشخیص Assertion ضعیف، کنترل داده، Debug شکست و تصمیم معماری همچنان به فهم تست و مهندسی نیاز دارند. هر کد تولیدشده باید Review و با شکست عمدی اعتبارسنجی شود.

جمع‌بندی

برای شروع تست خودکار، از ابزار شروع نکنید؛ از یک رفتار پرریسک و نتیجه قابل‌اندازه‌گیری شروع کنید. مبانی تست و برنامه‌نویسی را در پروژه واقعی تمرین کنید، سطح مناسب را انتخاب کنید، تستی بسازید که هم سبز و هم در خرابی واقعی قرمز شود، سپس آن را وارد CI کنید. یک Portfolio کوچک، پایدار و قابل‌توضیح بسیار بیشتر از انبوه اسکریپت‌های ضبط‌شده توانایی شما را نشان می‌دهد.

محمد عسکری

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

دیدگاهتان را بنویسید