اگر کاربر روی «پرداخت» بزند و سفارش دوبار ثبت شود، نرم‌افزار از نظر کارکردی شکست خورده است—even اگر صفحه در یک ثانیه باز شود. تست عملکردی یا دقیق‌تر، تست کارکردی (Functional Testing) بررسی می‌کند سیستم چه کاری انجام می‌دهد و آیا خروجی آن با نیازمندی و انتظار کسب‌وکار سازگار است.
در فارسی، «تست عملکردی» گاهی با Performance Testing اشتباه می‌شود. این مقاله تفاوت را روشن می‌کند و سپس انواع، سطوح اجرا، تکنیک‌های طراحی، مراحل انجام، ابزارها و یک مثال عملی از فرایند سفارش فروشگاه اینترنتی را توضیح می‌دهد.
فهرست مطالب
تست عملکردی (Functional Testing) چیست؟
تست عملکردی رفتار قابل‌مشاهده نرم‌افزار را در برابر نیازمندی‌ها، قواعد کسب‌وکار و معیارهای پذیرش بررسی می‌کند. برای هر قابلیت معمولاً ورودی یا پیش‌شرطی داریم، اقدامی انجام می‌دهیم و خروجی، تغییر State یا اثر جانبی را ارزیابی می‌کنیم.
نمونه‌ها:
- ورود با حساب فعال موفق و با رمز اشتباه رد شود؛
- فقط مدیر بتواند کاربر دیگری را غیرفعال کند؛
- کد تخفیف در بازه و شرایط مجاز اعمال شود؛
- API برای داده نامعتبر Status و پیام درست برگرداند؛
- پرداخت موفق سفارش را دقیقاً یک‌بار نهایی کند؛
- لغو سفارش مبلغ صحیح را بازگرداند و موجودی را آزاد کند.
Functional Test بیشتر بر «چه کاری» تمرکز دارد تا «چگونه پیاده‌سازی شده». بسیاری از تست‌های عملکردی با رویکرد Black-box طراحی می‌شوند، اما در سطح Unit یا Component دانش ساختار داخلی نیز می‌تواند استفاده شود.
تفاوت Functional Testing و Performance Testing
در ترجمه فارسی، واژه «عملکرد» برای Function و Performance هر دو به‌کار می‌رود. برای کاهش ابهام می‌توان Functional Testing را «تست کارکردی» و Performance Testing را «تست کارایی» نامید.
| معیار | تست عملکردی / کارکردی | تست کارایی / Performance |
|---|---|---|
| پرسش | آیا سیستم کار درست را انجام می‌دهد؟ | سیستم با چه سرعت و ظرفیتی کار می‌کند؟ |
| نمونه معیار | تخفیف ۱۰٪ درست محاسبه شود | صدک ۹۵ زمان پاسخ زیر آستانه باشد |
| داده | سناریو و Rule کسب‌وکار | Workload، کاربر هم‌زمان و حجم داده |
| نتیجه | خروجی، State، پیام و اثر جانبی | Latency، Throughput، Error Rate و Resource |
| ابزار نمونه | JUnit، Postman، Playwright | k6، JMeter، Gatling |
یک قابلیت ممکن است از نظر Functional درست باشد اما زیر بار کند شود؛ یا سریع پاسخ دهد اما مبلغ اشتباه برگرداند. هر دو نوع تست لازم‌اند. راهنمای تست غیرکارکردی کیفیت‌هایی مانند کارایی، امنیت و کاربردپذیری را پوشش می‌دهد.
تفاوت تست عملکردی و غیرعملکردی
- Functional: رفتار، Rule، ورودی/خروجی، State و مجوز؛
- Non-functional: ویژگی‌های کیفیت مانند سرعت، امنیت، قابلیت اطمینان، دسترس‌پذیری، کاربردپذیری و سازگاری.
این مرز همیشه کاملاً جدا نیست. مثلاً «کاربر بدون مجوز نباید داده را ببیند» یک Rule عملکردی مرتبط با امنیت است، در حالی که ارزیابی عمیق آسیب‌پذیری و مقاومت امنیتی غیرکارکردی محسوب می‌شود. برنامه تست باید هر دو زاویه را روشن کند.
تست عملکردی در سطوح مختلف
Unit، Integration، System و Acceptance «سطح تست» هستند، نه صرفاً انواع Functional Testing. رفتار عملکردی را می‌توان در هر سطح بررسی کرد. توضیح کامل را در راهنمای سطوح تست نرم‌افزار بخوانید.
تست واحد یا Component
تابع، کلاس یا جزء کوچک را در برابر قراردادش بررسی می‌کند؛ مانند محاسبه تخفیف، اعتبارسنجی فرمت یا تغییر State. سریع و نزدیک به علت شکست است.
تست یکپارچگی
تعامل میان جزءها، پایگاه داده و سرویس را می‌سنجد؛ مانند ثبت سفارش و رزرو موجودی یا تبدیل پاسخ درگاه به وضعیت داخلی.
تست سیستم
رفتار سامانه کامل را از دید ورودی/خروجی و مسیر کاربر ارزیابی می‌کند؛ مانند Checkout از سبد تا نتیجه پرداخت آزمایشی.
تست پذیرش
بررسی می‌کند قابلیت با نیاز و معیار کسب‌وکار برای استفاده آماده است. UAT باید Outcome و زمینه واقعی را ببیند، نه فقط تکرار تست سیستم.
انواع رایج تست عملکردی
Smoke Testing
مجموعه‌ای کوچک برای اطمینان از سلامت پایه Build؛ مثلاً بازشدن برنامه، ورود، دسترسی به قابلیت اصلی و اتصال سرویس‌های حیاتی. Smoke می‌گوید آیا نسخه ارزش تست عمیق‌تر دارد.
Sanity Testing
بررسی متمرکز یک تغییر یا بخش اصلاح‌شده برای اطمینان اولیه از منطقی‌بودن رفتار. دامنه از رگرسیون کامل کوچک‌تر است.
Regression Testing
بررسی می‌کند تغییر جدید رفتار قبلی را خراب نکرده است. انتخاب رگرسیون باید بر اساس تحلیل اثر و ریسک باشد؛ اجرای کورکورانه همه تست‌ها بازخورد را کند می‌کند.
Confirmation Testing یا Retest
عیب مشخصِ اصلاح‌شده را با همان شرایط و نسخه جدید دوباره بررسی می‌کند. Retest با Regression فرق دارد: اولی Fix را تأیید می‌کند، دومی اثر جانبی تغییر را می‌سنجد.
API Functional Testing
Endpoint، Auth، Schema، Rule، Status Code و اثر داده را بررسی می‌کند. API Test معمولاً سریع‌تر و پایدارتر از UI است. برای شروع، راهنمای مبانی تست API را ببینید.
UI و End-to-End Testing
تعامل کاربر و همکاری چند جزء را از رابط تا Backend می‌سنجد. این تست‌ها ارزشمند اما کندتر و شکننده‌ترند؛ تعداد محدود مسیر حیاتی بهتر از Suite بزرگ و Flaky است.
Exploratory Functional Testing
تستر با Charter و شناخت ریسک، هم‌زمان یاد می‌گیرد، طراحی و اجرا می‌کند. برای قابلیت جدید و کشف رفتار خارج از Test Case مفید است.
مراحل اجرای تست عملکردی
۱. تحلیل نیازمندی و ریسک
Actor، پیش‌شرط، Rule، داده، خروجی، خطا، State و اثر جانبی را مشخص کنید. رفتار مبهم باید پیش از طراحی تست روشن شود.
۲. استخراج Test Condition
موضوع‌های قابل تست در سطح بالا را بنویسید؛ مانند «اعمال تخفیف»، «مجوز لغو» و «بازیابی پرداخت نامشخص».
۳. انتخاب سطح و تکنیک
هر Rule را در پایین‌ترین سطح مؤثر قرار دهید. منطق محاسبه Unit/API؛ قرارداد سرویس Integration؛ چند مسیر کاربر UI.
۴. طراحی تست و داده
مسیر مثبت، منفی، مرزی، خطا، مجوز، State و ترکیب شرط‌ها را پوشش دهید. داده باید مستقل، قابل‌تکرار و غیرحساس باشد.
۵. آماده‌سازی محیط
نسخه سرویس‌ها، تنظیمات، حساب، Mock/Sandbox و Seed داده را ثبت کنید. Smoke محیط پیش از اجرای عمیق انجام شود.
۶. اجرا و ثبت شواهد
نتیجه واقعی را با انتظار مقایسه و Pass/Fail/Blocked را همراه با Build، داده و شواهد ثبت کنید.
۷. مدیریت عیب
عنوان، پیش‌شرط، مراحل، نتیجه واقعی/مورد انتظار، شدت و Log/Trace لازم را ثبت کنید. پس از Fix، Retest و Regression اثر انجام شود.
۸. گزارش پوشش و ریسک
فقط درصد Pass را گزارش نکنید؛ نیازمندی پوشش‌نداده، تست Blocked، عیب باز و ریسک باقیمانده را روشن کنید.
تکنیک‌های طراحی تست عملکردی
تقسیم‌بندی هم‌ارزی و مقدار مرزی
فضای ورودی را به گروه‌های رفتار مشابه تقسیم و مرزهای مرتب را بررسی می‌کند. مثال‌ها را در راهنمای Equivalence Partitioning و BVA ببینید.
جدول تصمیم
برای ترکیب چند شرط و اقدام مناسب است؛ مانند تخفیف بر اساس نوع کاربر، مبلغ و زمان. مقاله تست جدول تصمیم قالب آن را توضیح می‌دهد.
تست انتقال حالت
برای رفتار وابسته به وضعیت قبلی، رویداد و انتقال مجاز/ممنوع؛ مانند سفارش، تیکت یا حساب قفل‌شده. راهنمای State Transition Testing مناسب است.
Use Case Testing
جریان اصلی و Alternate Flow را از هدف Actor تا نتیجه نهایی پوشش می‌دهد. برای مسیرهای End-to-End و پذیرش مفید است.
Error Guessing و Checklist
از تجربه، تاریخچه باگ و دامنه برای هدف‌گرفتن خطاهای محتمل استفاده می‌کند؛ مانند Double-click، Back/Refresh، ارقام فارسی، Timezone یا درخواست تکراری.
مثال عملی: تست عملکردی ثبت سفارش
نیازمندی فرضی: «کاربر کالا را به سبد اضافه می‌کند، آدرس و ارسال را انتخاب می‌کند و با پرداخت موفق سفارش ثبت می‌شود.»
قواعد اصلی
- فقط کالای موجود قابل خرید است.
- هزینه ارسال به شهر و وزن سبد وابسته است.
- تخفیف فقط در بازه و برای کاربر واجد شرایط اعمال می‌شود.
- پیش از رفتن به درگاه، مبلغ و موجودی Server-side دوباره بررسی می‌شوند.
- Callback تکراری نباید سفارش یا پرداخت تکراری بسازد.
نمونه تست‌کیس‌ها
| ID | سناریو | سطح مناسب | انتظار |
|---|---|---|---|
| FT-01 | محاسبه هزینه ارسال شهر مجاز | Unit/API | مبلغ مطابق Rule |
| FT-02 | کد تخفیف منقضی | API/UI | رد با پیام روشن، مبلغ بدون تغییر |
| FT-03 | کالا پس از افزودن ناموجود می‌شود | Integration/E2E | عدم ثبت، اعلام آیتم و حفظ سبد قابل اصلاح |
| FT-04 | Callback پرداخت دو بار می‌رسد | Integration | یک سفارش و یک تراکنش نهایی |
| FT-05 | Timeout درگاه | System/E2E | وضعیت نامشخص، امکان پیگیری، بدون سفارش تکراری |
| FT-06 | آدرس با ارقام فارسی | API/UI | طبق Rule نرمال یا با پیام مشخص رد شود |
مواردی که Functional نیستند اما لازم‌اند
- زمان پاسخ Checkout زیر بار؛
- امنیت Token و داده پرداخت؛
- کاربردپذیری پیام خطا؛
- دسترس‌پذیری فرم با Keyboard/Screen Reader؛
- نمایش RTL روی موبایل و Browserهای هدف.
این جداسازی کمک می‌کند پوشش کامل کیفیت را با Functional Test اشتباه نگیریم.
ابزارهای تست عملکردی
| سطح/نیاز | ابزارهای نمونه | نکته |
|---|---|---|
| Unit/Component | JUnit، pytest، Jest، xUnit | سریع و نزدیک به کد |
| API | Postman/Newman، REST Assured، Supertest | Rule و قرارداد را سریع پوشش دهید |
| Web UI | Playwright، Selenium، Cypress | مسیر حیاتی، Locator پایدار |
| Mobile | Appium، Espresso، XCUITest | Device و lifecycle مهم‌اند |
| Mock/Contract | WireMock، Pact | وابستگی بیرونی و قرارداد |
| مدیریت | TestRail، Jira، Azure DevOps | Traceability و نتیجه اجرا |
ابزار جای تحلیل و طراحی را نمی‌گیرد. انتخاب میان اجرای دستی و خودکار را با معیار تکرار، ریسک، پایداری و هزینه نگهداری انجام دهید؛ مقاله تست دستی یا خودکار ماتریس تصمیم دارد.
شاخص‌های مفید
- پوشش نیازمندی و ریسک؛
- درصد Test Conditionهای طراحی/اجراشده؛
- Pass/Fail/Blocked همراه با علت؛
- Defect Leakage به مرحله بعد یا تولید؛
- توزیع عیب بر اساس ماژول و Rule؛
- زمان بازخورد تست‌های CI؛
- Flaky Rate و زمان تحلیل شکست؛
- ریسک باقیمانده پیش از Release.
تعداد تست‌کیس و درصد Pass بدون زمینه کافی نیستند. ممکن است ۹۹٪ تست کم‌ریسک پاس و مسیر پرداخت بحرانی Blocked باشد.
اشتباهات رایج
- اشتباه‌گرفتن Functional با Performance؛
- نامیدن Unit/Integration/System به‌عنوان انواع انحصاری Functional؛
- تمرکز فقط بر Happy Path؛
- انتظار مبهم مانند «سیستم درست کار کند»؛
- اجرای همه قواعد از UI؛
- نادیده‌گرفتن State، مجوز، خطا و بازیابی؛
- داده وابسته و تست‌های نیازمند ترتیب اجرا؛
- Retest بدون Regression اثر تغییر؛
- گزارش Pass بدون پوشش و ریسک؛
- فرض اینکه Functional Test به‌تنهایی کیفیت محصول را تضمین می‌کند.
چک‌لیست تست عملکردی
- Actor، هدف و مجوز روشن است.
- پیش‌شرط، Trigger و نتیجه موفق تعریف شده‌اند.
- ورودی معتبر، نامعتبر، خالی و مرزی پوشش دارد.
- Ruleهای چندشرطی و اولویت آن‌ها مدل شده‌اند.
- State و انتقال مجاز/ممنوع بررسی شده‌اند.
- خطا، Timeout، Retry، لغو و Recovery پوشش دارند.
- اثر داده، پیام، Notification و سرویس جانبی Assert می‌شود.
- Rule در پایین‌ترین سطح مؤثر تست شده است.
- چند مسیر حیاتی End-to-End باقی مانده‌اند.
- داده و محیط مستقل و قابل‌تکرارند.
- Traceability به نیازمندی و ریسک وجود دارد.
- ریسک غیرکارکردی جدا ثبت شده است.
سوالات متداول
تست عملکردی چیست؟
ارزیابی رفتار و کارکرد قابل‌مشاهده نرم‌افزار در برابر نیازمندی و Rule کسب‌وکار است؛ مانند ورودی، خروجی، State، مجوز و اثر جانبی.
آیا Functional Testing همان Performance Testing است؟
خیر. Functional می‌سنجد سیستم کار درست را انجام می‌دهد؛ Performance سرعت، ظرفیت و پایداری زیر بار را اندازه می‌گیرد. «کارکردی» و «کارایی» ترجمه‌های کم‌ابهام‌تری‌اند.
آیا تست عملکردی فقط Black-box است؟
اغلب بر رفتار بیرونی و Black-box تکیه دارد، اما در Unit یا Component ممکن است ساختار داخلی نیز برای طراحی و پوشش استفاده شود. هدف Functional بودن از نوع اطلاعات تستر جداست.
آیا تست عملکردی را می‌توان خودکار کرد؟
بله. Unit، API، Contract و مسیرهای پایدار UI گزینه‌های خوبی‌اند. تست اکتشافی، کاربردپذیری و قابلیت ناپایدار ممکن است دستی یا ترکیبی باقی بمانند.
اول Functional Test یا Non-functional Test؟
ترتیب مطلق وجود ندارد. برخی بررسی‌های غیرکارکردی مانند امنیت طراحی یا بودجه کارایی از ابتدا شروع می‌شوند. اجرای عمیق بار معمولاً روی رفتار پایه پایدارتر معنی بیشتری دارد، اما برنامه باید ریسک‌محور باشد.
جمع‌بندی
تست عملکردی بررسی می‌کند محصول کار تعریف‌شده را با Rule، State و خروجی درست انجام می‌دهد. پوشش مؤثر فقط فهرست قابلیت‌ها نیست؛ مسیر مثبت، منفی، مرز، مجوز، خطا، بازیابی و اثر جانبی را در سطح مناسب می‌سنجد. Unit و API را برای سرعت و عمق به‌کار ببرید، UI را محدود و حیاتی نگه دارید و Functional Test را با ویژگی‌های غیرکارکردی کامل کنید.
