تست عملکردی (Functional Testing) چیست؟ بررسی انواع، اهداف، مراحل و مثال‌های واقعی

هر نرم‌افزاری برای انجام وظایف و ارائه قابلیت‌های مشخصی ساخته می‌شود؛ از ورود و ثبت‌نام کاربران گرفته تا ثبت سفارش، انتقال وجه، ارسال پیام یا پردازش یک درخواست.

اما یک سؤال مهم وجود دارد:

از کجا بفهمیم نرم‌افزار واقعاً همان کاری را که باید انجام دهد، انجام می‌دهد؟ 🤔

اینجاست که تست عملکردی (Functional Testing) اهمیت پیدا می‌کند.

در تست عملکردی بررسی می‌کنیم که یک مؤلفه یا سیستم، عملکردهایی را که طبق نیازمندی‌های عملکردی باید ارائه دهد، انجام می‌دهد یا خیر.

برای مثال، در یک فروشگاه اینترنتی یکی از نیازمندی‌ها می‌تواند این باشد که کاربر بتواند محصولی را به سبد خرید خود اضافه کند.

در این حالت، تست عملکردی می‌تواند موارد زیر را بررسی کند:

• ✅ آیا محصول به سبد خرید اضافه می‌شود؟
• ✅ آیا محصول صحیح به سبد اضافه شده است؟
• ✅ آیا تعداد محصول درست نمایش داده می‌شود؟
• ✅ آیا قیمت محصول صحیح است؟
• ✅ آیا مبلغ نهایی سبد خرید به‌درستی محاسبه می‌شود؟

در واقع، سؤال اصلی در تست عملکردی این است:

سیستم باید چه کاری انجام دهد و آیا آن را مطابق نیازمندی‌های عملکردی انجام می‌دهد؟

در این مقاله، تست عملکردی را بر اساس مفاهیم مطرح‌شده در ISTQB Certified Tester Foundation Level (CTFL) بررسی می‌کنیم و با تعریف، اهداف، مثال‌های واقعی، تکنیک‌های طراحی تست، ارتباط آن با Test Levelها، تفاوت با تست غیرعملکردی و روش‌های اجرای آن آشنا می‌شویم.

تست عملکردی چیست؟ 🤔

تست عملکردی (Functional Testing) نوعی Test Type است که برای ارزیابی عملکردهایی انجام می‌شود که یک Component یا System باید ارائه دهد.

به زبان ساده‌تر، در تست عملکردی بررسی می‌کنیم که نرم‌افزار چه کاری باید انجام دهد و آیا رفتار واقعی آن با عملکردهای مورد انتظار و نیازمندی‌های عملکردی مطابقت دارد یا خیر.

برای مثال، فرض کنید در نیازمندی یک سامانه بانکی نوشته شده باشد:

کاربر باید بتواند مبلغ مشخصی را از حساب خود به یک حساب دیگر منتقل کند.

تستر می‌تواند سناریوهایی مانند موارد زیر را بررسی کند:

• آیا امکان انتخاب حساب مبدأ وجود دارد؟
• آیا حساب مقصد به‌درستی دریافت می‌شود؟
• آیا مبلغ انتقال درست ثبت می‌شود؟
• آیا سیستم از انتقال مبلغ بیشتر از موجودی جلوگیری می‌کند؟
• آیا مبلغ صحیح از حساب مبدأ کسر می‌شود؟
• آیا مبلغ صحیح به حساب مقصد منتقل می‌شود؟
• آیا وضعیت تراکنش به‌درستی ثبت می‌شود؟
• آیا در صورت نامعتبر بودن اطلاعات، سیستم رفتار مورد انتظار را نشان می‌دهد؟

در تمام این مثال‌ها، تمرکز روی رفتار عملکردی سیستم است؛ یعنی بررسی می‌کنیم سیستم در برابر ورودی‌ها و شرایط مختلف، همان رفتاری را دارد که طبق نیازمندی‌های عملکردی باید داشته باشد یا خیر.

هدف تست عملکردی چیست؟ 🎯

هدف تست عملکردی، ارزیابی عملکردهایی است که یک Component یا System باید ارائه دهد و بررسی میزان انطباق آن‌ها با نیازمندی‌های عملکردی.

در یک سیستم واقعی، فقط وجود یک قابلیت کافی نیست. باید بررسی کنیم که عملکردهای موردنیاز:

• وجود داشته باشند؛
• رفتار صحیحی ارائه دهند؛
• نتایج مورد انتظار را تولید کنند؛
• و در چارچوب نیازمندی‌های تعریف‌شده، نیازهای موردنظر را پوشش دهند.

این موضوع با سه مفهوم مهم در ویژگی کیفیت Functional Suitability ارتباط دارد:

۱. کامل بودن عملکردی (Functional Completeness) ✅

کامل بودن عملکردی به این موضوع مربوط است که آیا مجموعه عملکردهای ارائه‌شده، تمام وظایف و اهداف مشخص‌شده را پوشش می‌دهد یا خیر.

برای مثال، فرض کنید یک سامانه فروشگاهی باید امکان‌های زیر را داشته باشد:

• ثبت سفارش
• پرداخت
• لغو سفارش
• مشاهده وضعیت سفارش

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

۲. صحت عملکردی (Functional Correctness) 🎯

صحت عملکردی به این موضوع مربوط است که عملکردهای سیستم تا چه اندازه نتایج صحیح و دقیق را برای نیازهای مشخص‌شده ارائه می‌کنند.

برای مثال، فرض کنید یک محصول ۱۰ میلیون تومان قیمت دارد و برای آن تخفیف ۲۰ درصدی در نظر گرفته شده است.

اگر سیستم مبلغ نهایی را ۸ میلیون تومان محاسبه کند، نتیجه از نظر این نیازمندی صحیح است.

اما اگر سیستم به اشتباه مبلغ ۹ میلیون تومان را نمایش دهد، قابلیت محاسبه تخفیف وجود دارد، ولی نتیجه عملکردی صحیح نیست.

۳. مناسب بودن عملکردی (Functional Appropriateness) 🧩

مناسب بودن عملکردی به این موضوع مربوط است که عملکردهای ارائه‌شده تا چه اندازه انجام وظایف و دستیابی به اهداف مشخص‌شده را تسهیل می‌کنند.

برای مثال، فرض کنید یک سامانه سازمانی باید امکان «تأیید درخواست مرخصی» را فراهم کند. اگر سیستم علاوه بر ثبت درخواست، امکان بررسی وضعیت، تأیید یا رد درخواست و مشاهده نتیجه را در اختیار کاربر مجاز قرار دهد، عملکردهای آن به انجام وظیفه موردنظر کمک می‌کنند.

در اینجا سؤال اصلی این نیست که رابط کاربری چقدر زیبا یا ساده است؛ بلکه بررسی می‌کنیم آیا عملکردهای ارائه‌شده برای انجام وظیفه و رسیدن به هدف مشخص، مناسب هستند یا خیر.

بنابراین، در ارزیابی عملکردی یک سیستم می‌توان پرسید:

• آیا عملکرد موردنیاز وجود دارد؟
• آیا عملکرد به‌درستی کار می‌کند؟
• آیا نتیجه صحیح تولید می‌شود؟
• آیا عملکردهای ارائه‌شده برای انجام وظایف و اهداف موردنظر مناسب هستند؟

یک مثال ساده از تست عملکردی 🛒

فرض کنید در یک فروشگاه اینترنتی، نیازمندی زیر تعریف شده است:

کاربر باید بتواند محصول موردنظر خود را به سبد خرید اضافه کند.

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

اما یک تست عملکردی مناسب می‌تواند جزئیات بیشتری را بررسی کند.

سناریوی تست

پیش‌شرط:

محصول در سایت موجود است و کاربر صفحه آن را باز کرده است.

مراحل:

1. کاربر روی گزینه «افزودن به سبد خرید» کلیک می‌کند.
2. وارد صفحه سبد خرید می‌شود.
3. محصول اضافه‌شده را بررسی می‌کند.

نتیجه مورد انتظار:

• محصول صحیح به سبد اضافه شده باشد.
• تعداد محصول درست باشد.
• قیمت محصول صحیح نمایش داده شود.
• مبلغ کل سبد خرید درست محاسبه شود.

حالا فرض کنید محصول به سبد اضافه می‌شود، اما قیمت آن اشتباه نمایش داده می‌شود.

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

این مثال نشان می‌دهد که تست عملکردی فقط به بررسی وجود یک قابلیت محدود نمی‌شود؛ بلکه باید رفتار سیستم و نتیجه حاصل از آن را در شرایط مختلف ارزیابی کنیم.

تست عملکردی چه چیزهایی را بررسی می‌کند؟ 🔍

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

در یک فروشگاه اینترنتی 🛒

• ثبت‌نام کاربر
• ورود و خروج
• جستجوی محصول
• فیلتر محصولات
• افزودن به سبد خرید
• حذف کالا
• اعمال کد تخفیف
• محاسبه مبلغ نهایی
• ثبت سفارش
• پرداخت
• لغو سفارش

در یک سامانه بانکی 💳

• ورود کاربر
• مشاهده موجودی
• انتقال وجه
• پرداخت قبض
• دریافت صورتحساب
• ثبت تراکنش

در یک سامانه آموزش آنلاین 🎓

• ثبت‌نام
• ورود
• خرید دوره
• مشاهده محتوای آموزشی
• ثبت آزمون
• محاسبه امتیاز
• صدور گواهینامه

در تمام این موارد، تستر تلاش می‌کند بررسی کند که عملکردهای موردنیاز سیستم مطابق نیازمندی‌ها عمل می‌کنند یا خیر.

نکته مهم این است که Functional Testing به رابط کاربری محدود نیست. هر جا یک Component یا System عملکرد مشخصی دارد، می‌توان عملکرد مورد انتظار آن را ارزیابی کرد؛ بنابراین تست عملکردی می‌تواند در سطوح مختلف سیستم و حتی بدون وجود یک رابط کاربری گرافیکی انجام شود.

تست عملکردی یک Test Type است، نه یک Test Level 🧩

یکی از نکات مهم در چارچوب ISTQB، تفاوت بین Test Type و Test Level است.

Functional Testing یک Test Type است؛ در حالی که مواردی مانند Component Testing، Component Integration Testing، System Testing، System Integration Testing و Acceptance Testing در دسته Test Level قرار می‌گیرند.

به بیان ساده:

Test Level مشخص می‌کند تست در چه سطحی از سیستم انجام می‌شود.

Test Type مشخص می‌کند چه جنبه‌ای از سیستم یا کیفیت آن را ارزیابی می‌کنیم.

برای مثال، ممکن است در سطح System Testing عملکردهای موردنیاز یک سیستم کامل را ارزیابی کنیم یا در سطح دیگری، عملکرد یک Component را بررسی کنیم.

به همین دلیل، جمله زیر دقیق نیست:

❌ Unit Testing همان Functional Testing است.

بیان دقیق‌تر این است:

✅ Component Testing یک Test Level است و Functional Testing یک Test Type است؛ بنابراین می‌توان در یک Test Level مشخص، تست‌های عملکردی انجام داد.

این تفکیک مفهومی برای درک درست چارچوب ISTQB اهمیت زیادی دارد.

تست عملکردی چگونه انجام می‌شود؟ 🧪

تست عملکردی فقط به اجرای چند Test Case و بررسی نتیجه محدود نمی‌شود. برای اینکه تست‌ها ارزش واقعی داشته باشند، باید بر اساس نیازمندی‌ها، ریسک‌ها و اهداف مشخص طراحی و اجرا شوند.

به‌طور معمول، یک فرایند تست عملکردی می‌تواند شامل مراحل زیر باشد:

۱. بررسی نیازمندی‌ها 📋

اولین قدم این است که تستر بداند سیستم دقیقاً چه کاری باید انجام دهد.

برای این کار ممکن است منابعی مانند موارد زیر بررسی شوند:

• Functional Requirements
• User Stories
• Use Cases
• Business Rules
• Acceptance Criteria
• Specificationها

فرض کنید در یک فروشگاه اینترنتی نوشته شده است:

اگر کاربر یک محصول موجود را به سبد خرید اضافه کند، محصول باید به سبد اضافه شود و قیمت آن در مبلغ نهایی لحاظ شود.

همین یک نیازمندی می‌تواند مبنای طراحی چندین Test Case مختلف قرار گیرد.

۲. شناسایی شرایط تست 🔍

در مرحله بعد، تستر شرایطی را که باید بررسی شوند شناسایی می‌کند.

برای مثال، در قابلیت ورود به سیستم می‌توان شرایط زیر را در نظر گرفت:

• نام کاربری و رمز عبور صحیح
• نام کاربری اشتباه
• رمز عبور اشتباه
• خالی بودن نام کاربری
• خالی بودن رمز عبور
• حساب کاربری مسدودشده
• تلاش برای ورود با اطلاعات نامعتبر

هدف این است که تست فقط به یک مسیر موفق محدود نشود.

۳. طراحی Test Case ✍️

پس از شناسایی شرایط تست، Test Caseهای مناسب طراحی می‌شوند.

یک Test Case می‌تواند شامل اطلاعاتی مانند این موارد باشد:

• پیش‌شرط‌ها
• داده‌های ورودی
• مراحل اجرای تست
• نتیجه مورد انتظار

برای مثال:

سناریو: ورود کاربر

داده ورودی:

Username: user123

Password: 123456

نتیجه مورد انتظار:

کاربر با موفقیت وارد حساب کاربری شود و صفحه اصلی حساب نمایش داده شود.

۴. اجرای تست ▶️

در این مرحله Test Caseها اجرا می‌شوند و نتیجه واقعی سیستم با نتیجه مورد انتظار مقایسه می‌شود.

اگر نتیجه واقعی با نتیجه مورد انتظار مطابقت داشته باشد، تست موفق است.

اگر تفاوتی وجود داشته باشد، تستر باید موضوع را بررسی کند تا مشخص شود آیا این تفاوت ناشی از یک Defect است یا خیر.

۵. ثبت Defect 🐛

اگر رفتار سیستم با نیازمندی یا نتیجه مورد انتظار مطابقت نداشته باشد، ممکن است یک Defect شناسایی شود.

برای مثال:

Expected Result:

پس از پرداخت موفق، سفارش باید با وضعیت «پرداخت‌شده» ثبت شود.

Actual Result:

مبلغ از حساب کاربر کسر شده، اما وضعیت سفارش همچنان «در انتظار پرداخت» است.

در این شرایط، تستر باید Defect را با اطلاعات کافی ثبت کند تا تیم مربوطه بتواند آن را بررسی و اصلاح کند.

۶. Confirmation Testing و Regression Testing 🔄

پس از اصلاح یک Defect یا ایجاد تغییر در سیستم، ممکن است تست‌های دیگری نیز لازم باشند.

Confirmation Testing بررسی می‌کند که آیا نقص اصلی واقعاً برطرف شده است یا خیر.

Regression Testing بررسی می‌کند که تغییر انجام‌شده باعث ایجاد پیامدهای ناخواسته در بخش‌های دیگر سیستم نشده باشد.

برای مثال، اگر قابلیت اعمال کد تخفیف اصلاح شده باشد:

• Confirmation Testing بررسی می‌کند که آیا کد تخفیف حالا درست کار می‌کند.
• Regression Testing بررسی می‌کند که آیا این تغییر باعث خراب شدن محاسبه مبلغ نهایی، پرداخت یا ثبت سفارش نشده است.

این دو مفهوم را نباید صرفاً به‌عنوان «نوعی تست عملکردی» در نظر گرفت؛ در چارچوب ISTQB، آن‌ها در دسته Change-related Testing مطرح می‌شوند.

تست عملکردی با چه تکنیک‌هایی طراحی می‌شود؟ 🧠

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

در بسیاری از سناریوهای Functional Testing، تکنیک‌های Black-box کاربرد زیادی دارند؛ زیرا تستر می‌تواند بر اساس رفتار مورد انتظار و مشخصات سیستم، Test Caseها را طراحی کند، بدون اینکه لزوماً به ساختار داخلی نرم‌افزار وابسته باشد.

۱. Equivalence Partitioning

در این تکنیک، ورودی‌ها به گروه‌هایی تقسیم می‌شوند که انتظار می‌رود سیستم برای اعضای هر گروه رفتار مشابهی داشته باشد.

مثلاً فرض کنید یک سایت فقط به کاربران ۱۸ تا ۶۰ سال اجازه ثبت‌نام می‌دهد.

می‌توان ورودی‌ها را به پارتیشن‌های زیر تقسیم کرد:

• کمتر از ۱۸ سال
• بین ۱۸ تا ۶۰ سال
• بیشتر از ۶۰ سال

به‌جای تست کردن تمام اعداد ممکن، می‌توان نمایندگانی از هر پارتیشن را انتخاب کرد.

۲. Boundary Value Analysis

گاهی Defectها در مرزهای مقادیر مجاز بیشتر دیده می‌شوند؛ به همین دلیل، بررسی مقادیر نزدیک به مرزها اهمیت زیادی دارد.

در مثال قبلی، اگر محدوده مجاز ۱۸ تا ۶۰ باشد، مقادیر مهم می‌توانند شامل این موارد باشند:

• ۱۷
• ۱۸
• ۱۹
• ۵۹
• ۶۰
• ۶۱

این تکنیک زمانی ارزشمند است که سیستم دارای محدوده‌ها و محدودیت‌های عددی باشد.

۳. Decision Table Testing

وقتی رفتار سیستم به ترکیبی از چند شرط وابسته است، Decision Table Testing می‌تواند بسیار مفید باشد.

فرض کنید یک فروشگاه فقط در شرایط خاصی ارسال رایگان ارائه می‌دهد:

• مبلغ خرید بیشتر از ۲ میلیون تومان باشد.
• شهر کاربر در محدوده ارسال رایگان باشد.

حالا ترکیب‌های مختلف این شرایط می‌توانند رفتارهای متفاوتی ایجاد کنند.

Decision Table به تستر کمک می‌کند این ترکیب‌ها را به‌صورت منظم بررسی کند و شرایط مهم را از قلم نیندازد.

۴. State Transition Testing

برخی سیستم‌ها بر اساس وضعیت فعلی خود رفتار متفاوتی دارند. در این سیستم‌ها، بررسی انتقال بین وضعیت‌ها اهمیت زیادی دارد.

برای مثال، وضعیت یک سفارش ممکن است به این شکل تغییر کند:

ثبت‌شده → پرداخت‌شده → آماده‌سازی → ارسال‌شده → تحویل‌شده

تستر می‌تواند بررسی کند:

• آیا انتقال بین وضعیت‌ها صحیح است؟
• آیا انتقال نامعتبر جلوگیری می‌شود؟
• آیا سیستم در هر وضعیت رفتار مورد انتظار را دارد؟

این تکنیک برای سیستم‌هایی که رفتار آن‌ها به وضعیت فعلی یا رویدادهای قبلی وابسته است، کاربرد زیادی دارد.

تفاوت تست عملکردی و تست غیرعملکردی چیست؟ ⚖️

یکی از مهم‌ترین تفاوت‌ها بین این دو Test Type، سؤال اصلی آن‌هاست.

در تست عملکردی می‌پرسیم:

سیستم چه کاری باید انجام دهد؟

در تست غیرعملکردی می‌پرسیم:

سیستم آن کار را چقدر خوب انجام می‌دهد؟

برای مثال، در یک فروشگاه اینترنتی:

سؤال	نوع تست
آیا کاربر می‌تواند سفارش ثبت کند؟	Functional Testing
آیا مبلغ سفارش صحیح محاسبه می‌شود؟	Functional Testing
آیا کد تخفیف به‌درستی اعمال می‌شود؟	Functional Testing
آیا سفارش در زمان موردنیاز ثبت می‌شود؟	Non-functional Testing
آیا سیستم تحت بار زیاد همچنان عملکرد مناسبی دارد؟	Non-functional Testing
آیا سیستم از نظر امنیتی در برابر تهدیدهای مرتبط مقاوم است؟	Non-functional Testing

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

یک نکته مهم این است که گاهی یک سناریوی کسب‌وکار می‌تواند مبنای هر دو نوع تست قرار گیرد.

برای مثال، یک سناریو داریم:

کاربر سفارش خود را ثبت می‌کند.

تست عملکردی بررسی می‌کند:

آیا سفارش با موفقیت و مطابق قوانین کسب‌وکار ثبت می‌شود؟

تست غیرعملکردی می‌تواند بررسی کند:

آیا سفارش در زمان موردنیاز، تحت بار مشخص و با ویژگی‌های کیفی مورد انتظار ثبت می‌شود؟

پس یک Function می‌تواند مبنای هر دو نوع تست قرار گیرد، اما هدف و معیار ارزیابی متفاوت است.

۱۰ مثال واقعی برای درک تفاوت تست عملکردی و غیرعملکردی 🔍

گاهی تفاوت بین Functional Testing و Non-functional Testing در تئوری ساده به نظر می‌رسد، اما هنگام کار با یک نرم‌افزار واقعی، تشخیص آن ممکن است دشوارتر شود.

یک روش ساده برای تشخیص این دو این است که از خودمان بپرسیم:

آیا در حال بررسی این هستیم که سیستم «چه کاری» انجام می‌دهد؟

اگر پاسخ مثبت باشد، احتمالاً با یک تست عملکردی روبه‌رو هستیم.

آیا در حال بررسی این هستیم که سیستم «چقدر خوب» آن کار را انجام می‌دهد؟

در این صورت، احتمالاً با یک تست غیرعملکردی سروکار داریم.

۱. ورود به حساب کاربری 🔐

تست عملکردی:

• آیا کاربر با نام کاربری و رمز عبور صحیح وارد سیستم می‌شود؟
• آیا با رمز عبور اشتباه، ورود انجام نمی‌شود؟
• آیا در صورت خالی بودن فیلدها، پیام مناسب نمایش داده می‌شود؟
• آیا کاربر مسدودشده نمی‌تواند وارد حساب شود؟

در اینجا سؤال اصلی این است:

آیا قابلیت ورود مطابق نیازمندی‌ها کار می‌کند؟

تست غیرعملکردی:

• صفحه ورود با چه سرعتی بارگذاری می‌شود؟
• سیستم هنگام ورود هم‌زمان تعداد زیادی کاربر چه رفتاری دارد؟
• آیا فرآیند ورود از نظر امنیتی در برابر تهدیدهای مرتبط مقاوم است؟

۲. جستجوی محصول در فروشگاه اینترنتی 🛒

تست عملکردی:

• آیا نتایج مرتبط نمایش داده می‌شوند؟
• آیا جستجو با عبارت صحیح کار می‌کند؟
• آیا جستجوی محصولی که وجود ندارد، نتیجه مناسب نشان می‌دهد؟
• آیا فیلتر قیمت درست اعمال می‌شود؟

تست غیرعملکردی:

• نتایج جستجو چقدر سریع نمایش داده می‌شوند؟
• سیستم هنگام جستجوی هم‌زمان تعداد زیادی کاربر چه عملکردی دارد؟
• آیا جستجو از نظر امنیتی در برابر ورودی‌های مخرب محافظت شده است؟

در این مثال، نتیجه صحیح جستجو یک موضوع عملکردی است، اما سرعت پاسخ یا ویژگی‌های امنیتی در حوزه غیرعملکردی قرار می‌گیرد.

۳. ثبت سفارش 📦

تست عملکردی:

• آیا سفارش با موفقیت ثبت می‌شود؟
• آیا کالاهای صحیح در سفارش قرار دارند؟
• آیا مبلغ سفارش صحیح است؟
• آیا تخفیف به‌درستی اعمال شده است؟
• آیا موجودی کالا پس از ثبت سفارش به‌درستی به‌روزرسانی می‌شود؟

تست غیرعملکردی:

• آیا ثبت سفارش در زمان موردنیاز انجام می‌شود؟
• آیا سیستم در زمان افزایش شدید تعداد سفارش‌ها پایدار می‌ماند؟
• آیا فرآیند ثبت سفارش از نظر امنیتی محافظت شده است؟

در اینجا یک Function واحد، یعنی «ثبت سفارش»، می‌تواند مبنای هر دو نوع تست قرار گیرد؛ اما هدف و معیار ارزیابی متفاوت است.

۴. پرداخت آنلاین 💳

تست عملکردی:

• آیا مبلغ صحیح به درگاه پرداخت ارسال می‌شود؟
• آیا پرداخت موفق به‌درستی ثبت می‌شود؟
• آیا پرداخت ناموفق باعث ثبت سفارش پرداخت‌شده نمی‌شود؟
• آیا پس از پرداخت موفق، وضعیت سفارش تغییر می‌کند؟
• آیا تراکنش تکراری به‌درستی مدیریت می‌شود؟

تست غیرعملکردی:

• درگاه پرداخت در بار بالا چه عملکردی دارد؟
• زمان پاسخ سیستم چقدر است؟
• آیا ارتباط میان سیستم و درگاه از نظر امنیتی محافظت شده است؟
• آیا سیستم در شرایط خطای شبکه رفتار قابل‌قبولی دارد؟

بنابراین:

«آیا پرداخت انجام می‌شود؟» → عملکردی

«پرداخت با چه سرعت، امنیت و پایداری انجام می‌شود؟» → غیرعملکردی

۵. آپلود فایل 📁

فرض کنید یک سامانه به کاربر اجازه می‌دهد تصویر پروفایل خود را آپلود کند.

تست عملکردی:

• آیا فایل با فرمت مجاز آپلود می‌شود؟
• آیا فایل نامعتبر رد می‌شود؟
• آیا فایل پس از آپلود به کاربر نمایش داده می‌شود؟
• آیا محدودیت حجم فایل طبق نیازمندی‌ها رعایت می‌شود؟

تست غیرعملکردی:

• آیا آپلود فایل با حجم بالا سرعت مناسبی دارد؟
• سیستم در هنگام آپلود هم‌زمان تعداد زیادی فایل چه رفتاری دارد؟
• آیا سیستم از نظر امنیتی در برابر فایل‌های مخرب محافظت شده است؟

۶. ارسال پیام یا ایمیل 📧

فرض کنید یک سایت پس از ثبت‌نام کاربر، ایمیل تأیید ارسال می‌کند.

تست عملکردی:

• آیا ایمیل ارسال می‌شود؟
• آیا ایمیل به آدرس صحیح ارسال می‌شود؟
• آیا لینک تأیید صحیح است؟
• آیا لینک منقضی‌شده دیگر قابل استفاده نیست؟

تست غیرعملکردی:

• ایمیل با چه سرعتی ارسال می‌شود؟
• سیستم در زمان ارسال حجم زیادی از ایمیل‌ها چگونه عمل می‌کند؟
• آیا سرویس ارسال ایمیل قابلیت اطمینان مناسبی دارد؟

۷. اپلیکیشن حمل‌ونقل 🚕

فرض کنید در یک اپلیکیشن تاکسی اینترنتی، کاربر درخواست سفر ثبت می‌کند.

تست عملکردی:

• آیا کاربر می‌تواند مبدأ و مقصد را مشخص کند؟
• آیا درخواست سفر ثبت می‌شود؟
• آیا راننده مناسب به سفر اختصاص داده می‌شود؟
• آیا هزینه سفر به‌درستی محاسبه می‌شود؟
• آیا لغو سفر مطابق قوانین انجام می‌شود؟

تست غیرعملکردی:

• آیا سیستم در ساعات پرترافیک پاسخ‌گو است؟
• آیا موقعیت مکانی با سرعت مناسب به‌روزرسانی می‌شود؟
• آیا سیستم در بار بالا پایدار می‌ماند؟
• آیا اطلاعات حساس کاربران به‌صورت امن مدیریت می‌شوند؟

۸. سامانه بانکی 🏦

فرض کنید کاربر می‌خواهد مبلغ ۵ میلیون تومان انتقال وجه انجام دهد.

تست عملکردی:

• آیا حساب مبدأ و مقصد صحیح هستند؟
• آیا مبلغ انتقال درست ثبت می‌شود؟
• آیا انتقال بیش از سقف مجاز جلوگیری می‌شود؟
• آیا موجودی حساب مبدأ به‌درستی کاهش می‌یابد؟
• آیا تراکنش موفق ثبت می‌شود؟

تست غیرعملکردی:

• سیستم در زمان افزایش تعداد تراکنش‌ها چه عملکردی دارد؟
• زمان پاسخ سیستم چقدر است؟
• آیا اطلاعات تراکنش‌ها به‌صورت امن منتقل می‌شوند؟
• آیا سیستم در برابر خطاها و خرابی‌ها قابلیت اطمینان مناسبی دارد؟

۹. اپلیکیشن پخش ویدئو 🎬

فرض کنید کاربر می‌خواهد یک فیلم را پخش کند.

تست عملکردی:

• آیا ویدئو پخش می‌شود؟
• آیا دکمه Play و Pause کار می‌کنند؟
• آیا امکان جلو و عقب بردن ویدئو وجود دارد؟
• آیا زیرنویس فعال و غیرفعال می‌شود؟
• آیا انتخاب کیفیت ویدئو درست عمل می‌کند؟

تست غیرعملکردی:

• ویدئو با چه سرعتی شروع به پخش می‌کند؟
• سیستم در زمان افزایش تعداد کاربران چه عملکردی دارد؟
• آیا کیفیت پخش در شرایط مختلف شبکه مناسب است؟
• آیا سیستم در دستگاه‌ها و محیط‌های مختلف سازگاری مناسبی دارد؟

۱۰. سامانه آموزش آنلاین 🎓

فرض کنید دانشجو می‌خواهد یک آزمون آنلاین را تکمیل کند.

تست عملکردی:

• آیا دانشجو می‌تواند وارد آزمون شود؟
• آیا سؤال‌ها به‌درستی نمایش داده می‌شوند؟
• آیا پاسخ‌ها ذخیره می‌شوند؟
• آیا زمان آزمون به‌درستی محاسبه می‌شود؟
• آیا پس از پایان آزمون، نتیجه صحیح نمایش داده می‌شود؟

تست غیرعملکردی:

• آیا سامانه در زمان برگزاری آزمون برای تعداد زیادی دانشجو پایدار است؟
• صفحات با چه سرعتی بارگذاری می‌شوند؟
• آیا سیستم در مرورگرها و دستگاه‌های مختلف به‌درستی کار می‌کند؟
• آیا اطلاعات آزمون و نتایج کاربران به‌صورت امن محافظت می‌شوند؟

یک سناریو، دو نوع تست 🎯

یکی از نکات مهم در درک تفاوت Functional و Non-functional Testing این است که یک قابلیت واحد می‌تواند موضوع هر دو نوع تست قرار گیرد.

فرض کنید Function موردنظر این است:

کاربر بتواند سفارش خود را ثبت کند.

تست عملکردی می‌پرسد:

آیا سفارش با اطلاعات صحیح و مطابق قوانین کسب‌وکار ثبت می‌شود؟

تست غیرعملکردی می‌پرسد:

• آیا سفارش با سرعت مناسب ثبت می‌شود؟
• آیا سیستم در زمان بار زیاد همچنان توانایی ثبت سفارش را دارد؟
• آیا فرآیند ثبت سفارش از نظر امنیتی به‌اندازه کافی محافظت شده است؟

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

تست عملکردی چه زمانی کافی نیست؟ ⚠️

فرض کنید یک فروشگاه اینترنتی تمام Functional Testهای مهم خود را با موفقیت پشت سر گذاشته است.

کاربر می‌تواند:

• ✅ وارد حساب شود.
• ✅ محصول را پیدا کند.
• ✅ محصول را به سبد اضافه کند.
• ✅ تخفیف بگیرد.
• ✅ پرداخت کند.
• ✅ سفارش ثبت کند.

از نظر عملکردی، همه‌چیز درست به نظر می‌رسد.

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

اینجاست که متوجه می‌شویم:

درست کار کردن Functionها به‌تنهایی برای تضمین کیفیت نرم‌افزار کافی نیست.

نرم‌افزار باید علاوه بر ارائه عملکردهای موردنیاز، ویژگی‌های کیفی مناسب دیگری نیز داشته باشد. به همین دلیل، در یک پروژه واقعی معمولاً Functional Testing در کنار انواع دیگر تست‌ها انجام می‌شود تا جنبه‌های مختلف کیفیت سیستم ارزیابی شوند.

آیا تست عملکردی می‌تواند بدون نیازمندی انجام شود؟ 🤔

از نظر عملی، تستر ممکن است حتی در شرایطی که مستندات کامل نیستند، تست را آغاز کند؛ اما نبود Test Basis مناسب می‌تواند طراحی تست و ارزیابی نتایج را دشوارتر کند.

وقتی بدانیم سیستم باید چه کاری انجام دهد، راحت‌تر می‌توانیم مشخص کنیم:

• چه چیزی باید تست شود؟
• نتیجه مورد انتظار چیست؟
• چه رفتارهایی درست یا نادرست هستند؟
• چه سناریوهایی اهمیت بیشتری دارند؟

برای مثال، اگر بدانیم سیستم باید برای کاربران بالای ۱۸ سال امکان ثبت‌نام فراهم کند، می‌توان Test Caseهای مشخصی برای این قانون طراحی کرد.

اما اگر این قانون کسب‌وکار را ندانیم، ممکن است تستر متوجه نشود که ورود سن ۱۷ سال باید رد شود.

بنابراین، هرچه Test Basis بهتر و شفاف‌تر باشد، طراحی تست نیز هدفمندتر خواهد بود.

تست عملکردی در چرخه توسعه نرم‌افزار 🔄

Functional Testing فقط متعلق به مرحله پایانی پروژه نیست.

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

در Component Testing

ممکن است عملکرد یک Component مشخص به‌صورت مستقل بررسی شود.

در Component Integration Testing

می‌توان تعامل عملکردی میان Componentهای مختلف را بررسی کرد و دید آیا آن‌ها در کنار یکدیگر رفتار مورد انتظار را ارائه می‌دهند یا خیر.

در System Testing

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

در System Integration Testing

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

در Acceptance Testing

می‌توان بررسی کرد که آیا سیستم نیازهای کسب‌وکار و اهداف مورد انتظار ذی‌نفعان را برآورده می‌کند یا خیر.

این مثال‌ها دوباره اهمیت تفاوت میان Test Level و Test Type را نشان می‌دهند. Functional Testing می‌تواند در Test Levelهای مختلف انجام شود، اما هدف، دامنه و عمق تست بر اساس سطح موردنظر تغییر می‌کند.

تست عملکردی در Agile و DevOps چگونه انجام می‌شود؟ 🚀

در رویکردهای مدرن توسعه نرم‌افزار مانند Agile و DevOps، تست عملکردی فقط به پایان پروژه موکول نمی‌شود.

هدف این است که مشکلات هرچه زودتر شناسایی شوند تا اصلاح آن‌ها ساده‌تر و کم‌هزینه‌تر باشد.

این رویکرد با مفهوم Shift-Left Testing ارتباط دارد؛ یعنی فعالیت‌های تست و بررسی کیفیت تا حد امکان به مراحل ابتدایی‌تر چرخه توسعه منتقل شوند.

برای مثال، تصور کنید یک تیم در حال توسعه قابلیت «پرداخت آنلاین» است.

اگر تست عملکردی فقط پس از تکمیل کل سیستم انجام شود، ممکن است مشکلاتی مانند موارد زیر بسیار دیر شناسایی شوند:

• محاسبه اشتباه مبلغ پرداخت
• ارسال مبلغ نادرست به درگاه
• ثبت نشدن سفارش بعد از پرداخت موفق
• ثبت دوباره یک تراکنش
• مدیریت نادرست پرداخت ناموفق

اما اگر تست از مراحل ابتدایی‌تر آغاز شود، بخشی از این مشکلات می‌تواند زودتر شناسایی شود.

• قبل از تکمیل رابط کاربری، می‌توان منطق کسب‌وکار مربوط به محاسبه مبلغ را بررسی کرد.
• قبل از تکمیل کل جریان خرید، می‌توان APIهای مرتبط با پرداخت را تست کرد.
• پس از پیاده‌سازی جریان کامل، می‌توان سناریوی End-to-End پرداخت و ثبت سفارش را اجرا کرد.

در نتیجه، Functional Testing می‌تواند در نقاط مختلف چرخه توسعه و در سطوح مختلف انجام شود و لازم نیست تا آماده شدن کل محصول منتظر بمانیم.

تست عملکردی و Continuous Integration 🔄

در محیط‌های توسعه مدرن، ممکن است کد نرم‌افزار بارها در طول روز تغییر کند.

اگر هر تغییر کوچک باعث شود تیم مجبور باشد تمام تست‌ها را به‌صورت دستی اجرا کند، سرعت توسعه کاهش پیدا می‌کند.

به همین دلیل، بسیاری از تیم‌ها بخشی از Functional Testهای خود را خودکار می‌کنند و آن‌ها را در فرآیند Continuous Integration (CI) اجرا می‌کنند.

برای مثال، فرض کنید توسعه‌دهنده قابلیت جدیدی برای سبد خرید ایجاد کرده است.

پس از ثبت تغییر، ممکن است این مراحل انجام شوند:

1. کد Build می‌شود.
2. تست‌های خودکار اجرا می‌شوند.
3. تست‌های Functional مرتبط اجرا می‌شوند.
4. نتیجه تست‌ها گزارش می‌شود.
5. در صورت مشاهده خطای مهم، تیم موضوع را بررسی می‌کند.

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

البته همه Functional Testها برای اجرای مکرر در CI مناسب نیستند. تست‌هایی که طولانی، ناپایدار یا وابسته به محیط‌های پیچیده هستند ممکن است در مراحل دیگری اجرا شوند.

بنابراین هدف، خودکارسازی هدفمند تست‌ها است، نه صرفاً خودکار کردن هر تست ممکن.

Traceability در تست عملکردی چیست؟ 🔗

یکی از موضوعات مهم در پروژه‌های حرفه‌ای، ارتباط میان Requirement و Test Case است.

فرض کنید یک سیستم چندین نیازمندی عملکردی مهم دارد. اگر برای هر Requirement مشخص باشد که کدام Test Case آن را پوشش می‌دهد، تیم تست می‌تواند بهتر بررسی کند که آیا نیازمندی‌ها به‌اندازه کافی تست شده‌اند یا خیر.

Requirement	Test Case
کاربر بتواند ثبت‌نام کند	TC-001
کاربر بتواند وارد شود	TC-002
کاربر بتواند محصول را جستجو کند	TC-003
کاربر بتواند محصول را به سبد اضافه کند	TC-004
کاربر بتواند سفارش ثبت کند	TC-005
کاربر بتواند پرداخت کند	TC-006

حالا فرض کنید Requirement جدیدی اضافه شده است:

کاربر باید بتواند سفارش خود را لغو کند.

تیم تست می‌تواند به‌سرعت متوجه شود که برای این نیازمندی هنوز Test Case مرتبطی تعریف نشده است.

این ارتباط میان نیازمندی‌ها و Testware می‌تواند به شناسایی شکاف‌های پوشش تست کمک کند.

تست عملکردی چه نوع Defectهایی را پیدا می‌کند؟ 🐛

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

نتیجه محاسباتی اشتباه

سیستم باید ۲۰ درصد تخفیف اعمال کند، اما مقدار دیگری محاسبه می‌کند.

اجرای ناقص Business Rule

سیستم باید اجازه خرید کالای ناموجود را ندهد، اما سفارش ثبت می‌شود.

عملکرد ناقص یا پیاده‌سازی‌نشده

یک قابلیت مهم که در Requirement تعریف شده است، اصلاً پیاده‌سازی نشده یا بخشی از آن ناقص است.

رفتار اشتباه در شرایط خطا

سیستم باید پرداخت ناموفق را مدیریت کند، اما سفارش را به‌عنوان پرداخت‌شده ثبت می‌کند.

انتقال نادرست وضعیت

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

خطای تعامل بین سیستم‌ها

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

اعتبارسنجی نادرست داده

سیستم باید ورود یک مقدار نامعتبر را رد کند، اما آن را می‌پذیرد.

این مثال‌ها نشان می‌دهند که Defectهای Functional می‌توانند از یک خطای ساده در یک فیلد تا یک مشکل جدی در جریان‌های حیاتی کسب‌وکار گسترده باشند.

تستر هنگام اجرای تست عملکردی به دنبال چه چیزی است؟ 🔍

یک تستر حرفه‌ای فقط Test Case را اجرا نمی‌کند؛ او باید رفتار سیستم را با ذهنی پرسشگرانه بررسی کند.

برای مثال، هنگام تست قابلیت ثبت سفارش می‌توان پرسید:

• اگر موجودی محصول در همین لحظه تمام شود چه اتفاقی می‌افتد؟
• اگر کاربر چند بار روی دکمه ثبت سفارش کلیک کند چه می‌شود؟
• اگر پرداخت موفق شود، اما پاسخ به سیستم اصلی نرسد چه اتفاقی می‌افتد؟
• اگر کاربر صفحه را در وسط فرآیند Refresh کند چه می‌شود؟
• اگر ارتباط با سرویس خارجی قطع شود چه اتفاقی رخ می‌دهد؟
• اگر مبلغ سفارش تغییر کند چه می‌شود؟
• اگر دو کاربر هم‌زمان آخرین موجودی یک محصول را خریداری کنند چه اتفاقی می‌افتد؟

این نوع پرسش‌ها کمک می‌کنند تست از یک اجرای ساده و خطی فراتر برود.

در تست عملکردی، مهم است که فقط به آنچه سیستم باید در شرایط عادی انجام دهد توجه نکنیم؛ بلکه شرایط غیرعادی و مسیرهای جایگزین را نیز بررسی کنیم.

آیا یک Test Case می‌تواند هم عملکردی و هم غیرعملکردی باشد؟ 🤔

بهتر است این موضوع را بر اساس هدف اصلی تست تحلیل کنیم.

فرض کنید Test Case زیر را داریم:

کاربر وارد سیستم می‌شود و صفحه حساب کاربری باید نمایش داده شود.

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

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

بنابراین، ممکن است یک سناریوی کسب‌وکار مشابه در تست‌های مختلف استفاده شود، اما هدف تست مشخص می‌کند چه جنبه‌ای در حال ارزیابی است.

معیارهای ورود و خروج در تست عملکردی 📊

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

Entry Criteria

برخی نمونه‌های احتمالی عبارت‌اند از:

• نیازمندی‌های موردنظر قابل استفاده باشند.
• Build مناسب در دسترس باشد.
• محیط تست آماده باشد.
• Test Data موردنیاز موجود باشد.
• وابستگی‌های ضروری آماده باشند.

Exit Criteria

برخی نمونه‌های احتمالی عبارت‌اند از:

• Test Caseهای اولویت‌بالا اجرا شده باشند.
• Defectهای بحرانی باقی‌مانده تعیین تکلیف شده باشند.
• پوشش موردنظر حاصل شده باشد.
• Test Resultها ثبت شده باشند.
• ریسک باقی‌مانده قابل‌قبول باشد.

این معیارها باید متناسب با پروژه و ریسک‌های آن تعریف شوند و نمی‌توان برای تمام پروژه‌ها یک مجموعه معیار ثابت در نظر گرفت.

آیا تمام Test Caseها باید Pass شوند؟ ✅

لزوم Pass شدن تمام Test Caseها به شرایط پروژه، ریسک و معیارهای خروج بستگی دارد.

فرض کنید ۱۰۰ Test Case داریم و ۹۸ مورد Pass شده‌اند.

دو Test Case Fail شده‌اند، اما یکی از آن‌ها مربوط به یک قابلیت فرعی است که در Release فعلی استفاده نمی‌شود و ریسک آن پذیرفته شده است.

در این شرایط ممکن است تیم تصمیم بگیرد Release انجام شود.

اما اگر همان دو Fail مربوط به قابلیت‌های حیاتی مانند موارد زیر باشند، شرایط کاملاً متفاوت خواهد بود:

• پرداخت
• امنیت حساب
• انتقال وجه
• ثبت سفارش

پس:

تعداد Pass و Fail به‌تنهایی معیار کافی برای تصمیم‌گیری درباره کیفیت نیست.

باید ریسک، اهمیت کسب‌وکار، شدت Defect و تأثیر آن بر کاربران نیز در نظر گرفته شود.

تفاوت Functional Testing با Functional Suitability چیست؟ 🧩

این دو اصطلاح به دلیل شباهت ظاهری ممکن است با هم اشتباه گرفته شوند.

Functional Testing

یک Test Type است که عملکردهای موردنیاز یک Component یا System را ارزیابی می‌کند.

Functional Suitability

یک Quality Characteristic است که به این موضوع مربوط می‌شود که آیا سیستم عملکردهایی ارائه می‌دهد که نیازهای بیان‌شده و ضمنی را در شرایط مشخص برآورده کنند.

در این چارچوب، Functional Suitability شامل جنبه‌هایی مانند موارد زیر است:

• Functional Completeness
• Functional Correctness
• Functional Appropriateness

پس:

Functional Testing یک Test Type است.

Functional Suitability یک Quality Characteristic است که می‌تواند موضوع ارزیابی قرار گیرد.

نمونه Test Case برای تست عملکردی 🧪

برای اینکه مفهوم تست عملکردی کاملاً ملموس شود، یک مثال واقعی از طراحی Test Case را بررسی کنیم.

فرض کنید در یک فروشگاه اینترنتی، نیازمندی زیر وجود دارد:

کاربر باید بتواند محصول موجود را به سبد خرید اضافه کند.

حالا می‌توانیم یک Test Case برای این نیازمندی طراحی کنیم.

Test Case: افزودن محصول به سبد خرید

بخش	توضیحات
Test Case ID	TC-CART-001
عنوان	افزودن محصول موجود به سبد خرید
پیش‌شرط	محصول در سیستم موجود باشد
داده تست	یک محصول با موجودی حداقل ۱ عدد
مراحل اجرا	ورود به صفحه محصول → کلیک روی «افزودن به سبد خرید» → مشاهده سبد
نتیجه مورد انتظار	محصول در سبد خرید نمایش داده شود
وضعیت مورد انتظار	Pass

اما یک تستر حرفه‌ای به همین یک سناریو اکتفا نمی‌کند.

برای همین قابلیت، سناریوهای دیگری نیز باید در نظر گرفته شوند.

سناریوهای تکمیلی

• محصول موجود است: انتظار می‌رود محصول با موفقیت به سبد خرید اضافه شود.
• موجودی محصول صفر است: انتظار می‌رود سیستم اجازه اضافه کردن محصول به سبد را ندهد.
• کاربر چند بار روی دکمه افزودن کلیک می‌کند: انتظار می‌رود تعداد محصول مطابق قوانین سیستم مدیریت شود.
• کاربر محصول را به سبد اضافه کرده و سپس حذف می‌کند: انتظار می‌رود محصول از سبد حذف شود و مبلغ نهایی نیز به‌درستی به‌روزرسانی شود.
• قیمت محصول پس از اضافه شدن به سبد تغییر کرده است: سیستم باید مطابق Business Rule تعریف‌شده رفتار کند.

در این مثال می‌بینیم که تست عملکردی فقط بررسی یک مسیر ساده نیست؛ بلکه باید رفتار سیستم را در شرایط مختلف و بر اساس نیازمندی‌ها ارزیابی کرد.

ابزارهای مورد استفاده در تست عملکردی 🛠️

برای اجرای Functional Testing، بسته به نوع سیستم، سطح تست و لایه مورد آزمایش، می‌توان از ابزارهای مختلفی استفاده کرد.

نکته مهم این است که خود ابزار به‌تنهایی تعیین نمی‌کند تست عملکردی است یا غیرعملکردی؛ بلکه هدف و نوع تستی که با ابزار انجام می‌شود اهمیت دارد.

Selenium

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

Playwright

برای خودکارسازی تست‌های وب مدرن و اجرای سناریوهای مرورگر کاربرد دارد و می‌تواند برای بررسی جریان‌های عملکردی End-to-End مورد استفاده قرار گیرد.

Cypress

ابزاری برای تست برنامه‌های وب است که می‌تواند برای بررسی سناریوهای عملکردی رابط کاربری و جریان‌های کاربری استفاده شود.

Appium

برای خودکارسازی تست اپلیکیشن‌های موبایل کاربرد دارد و می‌توان از آن برای بررسی جریان‌های عملکردی در اپلیکیشن‌های موبایل استفاده کرد.

Postman

در تست API می‌توان از Postman برای ارسال درخواست و بررسی پاسخ استفاده کرد.

برای مثال، فرض کنید APIای برای ایجاد کاربر داریم. تستر می‌تواند بررسی کند:

• آیا درخواست معتبر پذیرفته می‌شود؟
• آیا کاربر در سیستم ایجاد می‌شود؟
• آیا Response مورد انتظار برگردانده می‌شود؟
• آیا داده‌های ایجادشده صحیح هستند؟

در چنین شرایطی، هدف می‌تواند Functional Testing باشد؛ زیرا تمرکز روی عملکرد مورد انتظار API است.

آیا API Testing یک تست عملکردی است؟ 🔌

پاسخ این سؤال به هدف تست بستگی دارد.

فرض کنید یک API برای ثبت سفارش داریم.

اگر هدف تست این باشد که بررسی کنیم:

• آیا درخواست صحیح پذیرفته می‌شود؟
• آیا سفارش در سیستم ایجاد می‌شود؟
• آیا مبلغ صحیح محاسبه می‌شود؟
• آیا Response مناسب برگردانده می‌شود؟

در این حالت، تست انجام‌شده می‌تواند یک Functional Test باشد.

اما اگر همان API را از نظر موارد زیر بررسی کنیم:

• زمان پاسخ
• تعداد درخواست قابل‌پشتیبانی
• رفتار تحت بار بالا

تمرکز تست دیگر روی ویژگی‌های عملکردی کسب‌وکار نیست و وارد حوزه تست‌های غیرعملکردی می‌شویم.

بنابراین:

API Testing یک محل یا رویکرد برای انجام تست است؛ Functional یا Non-functional بودن آن به هدف و جنبه مورد ارزیابی بستگی دارد.

آیا UI Testing همیشه Functional Testing است؟ 🖥️

خیر.

فرض کنید یک تستر بررسی می‌کند که یک صفحه وب در اندازه‌های مختلف صفحه‌نمایش به‌درستی نمایش داده می‌شود. در اینجا ممکن است موضوع اصلی تست، Compatibility یا ویژگی دیگری از کیفیت باشد، نه عملکرد کسب‌وکاری سیستم.

اما اگر تستر بررسی کند:

کاربر روی دکمه «ثبت سفارش» کلیک می‌کند و سفارش ایجاد می‌شود.

تمرکز اصلی روی یک Function سیستم است و می‌تواند Functional Testing باشد.

بنابراین:

UI Testing یک حوزه یا محل انجام تست است، نه الزاماً مترادف Functional Testing.

تست عملکردی دستی یا خودکار؟ 🤖

تست عملکردی می‌تواند به‌صورت Manual یا Automated انجام شود.

تست عملکردی دستی

در این روش، تستر سناریو را به‌صورت مستقیم اجرا می‌کند و نتیجه را بررسی می‌کند.

برای مثال:

1. باز کردن صفحه ورود
2. وارد کردن نام کاربری
3. وارد کردن رمز عبور
4. کلیک روی دکمه Login
5. بررسی نتیجه

تست دستی برای سناریوهایی که به مشاهده، بررسی یا تعامل انسانی نیاز دارند می‌تواند مفید باشد.

تست عملکردی خودکار

در این روش، ابزارها یا اسکریپت‌های خودکار اجرای Test Case و بررسی نتایج را انجام می‌دهند.

برای مثال، یک تست خودکار می‌تواند به‌صورت خودکار:

1. وارد سایت شود.
2. اطلاعات کاربر را وارد کند.
3. روی دکمه ورود کلیک کند.
4. نتیجه را بررسی کند.

در پروژه‌هایی که تست‌های تکراری، مانند بسیاری از Regression Testها، مرتباً اجرا می‌شوند، Automation می‌تواند ارزش زیادی داشته باشد.

بنابراین:

Functional Testing مشخص می‌کند چه جنبه‌ای از سیستم را ارزیابی می‌کنیم.

Test Automation مشخص می‌کند اجرای بخشی از این تست‌ها چگونه خودکار می‌شود.

چگونه پوشش تست عملکردی را افزایش دهیم؟ 📊

داشتن تعداد زیادی Test Case لزوماً به معنی پوشش خوب نیست. ممکن است یک تیم صدها Test Case داشته باشد، اما هنوز بخش مهمی از نیازمندی‌ها تست نشده باشند.

برای افزایش پوشش تست، می‌توان به این موارد توجه کرد:

پوشش نیازمندی‌ها

بررسی کنید هر Requirement مهم حداقل یک یا چند Test Case مرتبط داشته باشد.

پوشش سناریوها

فقط مسیر موفق را تست نکنید و مسیرهای جایگزین و شرایط خطا را نیز در نظر بگیرید.

پوشش داده‌ها

داده‌های معتبر، نامعتبر، مرزی و غیرعادی را بررسی کنید.

پوشش Business Ruleها

قوانین کسب‌وکار باید به‌صورت مشخص در تست‌ها پوشش داده شوند.

پوشش جریان‌های اصلی کسب‌وکار

سناریوهای حیاتی مانند ثبت سفارش، پرداخت یا انتقال وجه باید با دقت بیشتری تست شوند.

ارتباط تست عملکردی با تست مبتنی بر ریسک 🎯

در یک پروژه واقعی، معمولاً امکان تست کردن همه‌چیز با یک سطح یکسان از عمق و تکرار وجود ندارد.

بنابراین، تیم تست باید بر اساس عواملی مانند موارد زیر اولویت‌بندی انجام دهد:

• اهمیت کسب‌وکار
• احتمال وقوع خطا
• تأثیر خطا
• پیچیدگی سیستم
• تغییرات اخیر
• میزان استفاده کاربران

برای مثال، در یک سامانه بانکی، قابلیت انتقال وجه احتمالاً ریسک بالاتری نسبت به تغییر تصویر پس‌زمینه صفحه اصلی دارد.

بنابراین منطقی است تست‌های بیشتری روی عملکرد انتقال وجه طراحی و اجرا شود.

این رویکرد کمک می‌کند منابع تست روی بخش‌هایی متمرکز شوند که شکست آن‌ها می‌تواند بیشترین آسیب را ایجاد کند.

بهترین روش‌ها برای اجرای تست عملکردی ✅

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

قبل از طراحی تست، مشخص کنید سیستم دقیقاً چه کاری باید انجام دهد.

فقط Happy Path را تست نکنید

شرایط خطا، مسیرهای جایگزین و داده‌های نامعتبر را نیز بررسی کنید.

از تکنیک‌های طراحی تست استفاده کنید

برای جلوگیری از افزایش بی‌دلیل تعداد Test Caseها می‌توان از تکنیک‌هایی مانند Equivalence Partitioning و Boundary Value Analysis استفاده کرد.

سناریوهای حیاتی را اولویت‌بندی کنید

همه عملکردها اهمیت یکسانی ندارند. عملکردهای مهم کسب‌وکار و بخش‌های پرریسک باید توجه بیشتری دریافت کنند.

Test Data مناسب داشته باشید

داده تست نامناسب می‌تواند باعث شود تست نتواند رفتار واقعی سیستم را به‌درستی ارزیابی کند.

نتیجه مورد انتظار را دقیق تعریف کنید

عبارت‌هایی مانند «سیستم باید درست کار کند» برای یک Test Case مناسب نیستند. بهتر است Expected Result کاملاً مشخص و قابل ارزیابی باشد.

تست‌ها را قابل تکرار طراحی کنید

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

از Automation به‌صورت هدفمند استفاده کنید

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

تفاوت تست عملکردی با Component Testing چیست؟ 🔬

این سؤال بسیار رایج است.

Component Testing یا تست یک مؤلفه، به تست یک Component در سطح مشخصی مربوط می‌شود.

اما Functional Testing نوع تستی است که روی عملکرد مورد انتظار تمرکز دارد.

بنابراین این دو مفهوم در یک سطح از دسته‌بندی قرار نمی‌گیرند.

برای مثال:

• Component Testing → Test Level
• Functional Testing → Test Type

این دو می‌توانند با یکدیگر ارتباط داشته باشند، اما مترادف نیستند.

تست عملکردی و Regression Testing چه تفاوتی دارند؟ 🔄

این دو نیز اغلب با یکدیگر اشتباه گرفته می‌شوند.

Functional Testing مشخص می‌کند که آیا عملکرد موردنظر سیستم مطابق نیازمندی‌ها عمل می‌کند یا خیر.

Regression Testing برای بررسی آثار ناخواسته تغییرات در بخش‌هایی از سیستم انجام می‌شود که ممکن است تحت تأثیر تغییر قرار گرفته باشند.

برای مثال، فرض کنید تیم توسعه قابلیت «کد تخفیف» را تغییر داده است.

تست عملکردی بررسی می‌کند:

آیا کد تخفیف طبق قوانین تعریف‌شده درست کار می‌کند؟

تست Regression بررسی می‌کند:

آیا این تغییر باعث نشده بخش‌هایی مانند محاسبه مبلغ، پرداخت یا ثبت سفارش دچار مشکل شوند؟

پس این دو مفهوم یکی نیستند، هرچند ممکن است در یک پروژه در کنار هم استفاده شوند.

چک‌لیست نهایی تست عملکردی ✅

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

درباره نیازمندی‌ها

• ☐ آیا می‌دانیم سیستم دقیقاً چه کاری باید انجام دهد؟
• ☐ آیا تمام Business Ruleهای مرتبط شناسایی شده‌اند؟
• ☐ آیا نیازمندی‌های مبهم یا ناقص شناسایی شده‌اند؟

درباره طراحی تست

• ☐ آیا Happy Path تست شده است؟
• ☐ آیا Alternate Flowها بررسی شده‌اند؟
• ☐ آیا Error Flowها تست شده‌اند؟
• ☐ آیا داده‌های معتبر و نامعتبر بررسی شده‌اند؟
• ☐ آیا Boundaryها بررسی شده‌اند؟
• ☐ آیا Stateهای مختلف سیستم تست شده‌اند؟
• ☐ آیا ترکیب شرایط مهم بررسی شده است؟

درباره اجرا

• ☐ آیا نتیجه واقعی با نتیجه مورد انتظار مقایسه شده است؟
• ☐ آیا Defectها به‌درستی ثبت شده‌اند؟
• ☐ آیا پس از رفع Defect، Confirmation Testing انجام شده است؟
• ☐ آیا نیاز به Regression Testing بررسی شده است؟

درباره پوشش تست

• ☐ آیا Requirementهای مهم پوشش داده شده‌اند؟
• ☐ آیا سناریوهای حیاتی کسب‌وکار تست شده‌اند؟
• ☐ آیا تست‌ها بر اساس ریسک اولویت‌بندی شده‌اند؟
• ☐ آیا شکاف‌های پوشش تست شناسایی شده‌اند؟

خلاصه تست عملکردی در ۶ سؤال 🎯

۱. Functional Testing چیست؟

تستی برای ارزیابی عملکردهایی که یک Component یا System باید انجام دهد.

۲. مبنای آن چیست؟

نیازمندی‌های عملکردی و سایر Test Basisهای مرتبط.

۳. سؤال اصلی آن چیست؟

سیستم چه کاری باید انجام دهد و آیا آن را مطابق انتظار انجام می‌دهد؟

۴. آیا فقط به UI مربوط است؟

خیر. می‌تواند در لایه‌ها و Test Levelهای مختلف انجام شود.

۵. آیا فقط دستی است؟

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

۶. آیا برای تضمین کل کیفیت کافی است؟

خیر. باید در کنار سایر Test Typeهای مناسب، بر اساس ریسک و نیازهای پروژه استفاده شود.

جمع‌بندی نهایی تست عملکردی 🏁

تست عملکردی یکی از انواع مهم تست نرم‌افزار است که تمرکز آن بر ارزیابی عملکردهایی است که یک Component یا System باید ارائه دهد.

در این نوع تست، سؤالاتی مانند این مطرح می‌شوند:

• آیا قابلیت موردنیاز وجود دارد؟
• آیا عملکرد سیستم مطابق نیازمندی است؟
• آیا نتیجه صحیح تولید می‌شود؟
• آیا عملکردهای موردنیاز به‌طور کامل پوشش داده شده‌اند؟
• آیا عملکردهای ارائه‌شده برای انجام وظایف و اهداف موردنظر مناسب هستند؟

برای انجام Functional Testing می‌توان از نیازمندی‌ها، User Storyها، Use Caseها و سایر Test Basisها استفاده کرد و با تکنیک‌هایی مانند Equivalence Partitioning، Boundary Value Analysis، Decision Table Testing و State Transition Testing Test Caseهای مناسب طراحی کرد.

در عین حال باید به یک نکته مهم توجه داشت:

Functional Testing با Test Levelهایی مانند Component، System یا Acceptance یکسان نیست.

Functional Testing یک Test Type است و می‌تواند در Test Levelهای مختلف مورد استفاده قرار گیرد؛ در حالی که Test Level مشخص می‌کند تست در چه سطحی از سیستم انجام می‌شود.

همچنین Functional Testing تنها بخشی از فرایند ارزیابی کیفیت نرم‌افزار است. یک سیستم ممکن است از نظر عملکردی درست باشد، اما همچنان از نظر Performance، Security، Usability، Reliability یا سایر ویژگی‌های کیفیتی دچار مشکل باشد.

به همین دلیل، تست عملکردی در کنار سایر Test Typeهای مناسب به تیم کمک می‌کند تصویر کامل‌تری از کیفیت و ریسک محصول به دست آورد.

سخن پایانی: یک نرم‌افزار خوب فقط باید «کار کند»؟ 🤔

نه همیشه.

یک نرم‌افزار خوب باید کاری را که برای آن ساخته شده، درست انجام دهد؛ اما این تنها بخشی از داستان کیفیت نرم‌افزار است.

تست عملکردی به ما کمک می‌کند مطمئن شویم سیستم عملکردهای موردنیاز خود را ارائه می‌کند و رفتار آن با نیازمندی‌های عملکردی مطابقت دارد.

اما بعد از این سؤال:

آیا سیستم کاری را که باید انجام دهد، انجام می‌دهد؟

یک سؤال مهم دیگر مطرح می‌شود:

آیا این کار را با کیفیت مناسب انجام می‌دهد؟

• آیا سریع است؟ ⚡
• آیا امن است؟ 🔐
• آیا در برابر بار زیاد پایدار می‌ماند؟ 📈
• آیا استفاده از آن برای کاربر مناسب است؟ 👤

پاسخ به این پرسش‌ها ما را وارد دنیای تست غیرعملکردی (Non-Functional Testing) می‌کند؛ جایی که سؤال دیگر فقط این نیست که سیستم چه کاری انجام می‌دهد، بلکه می‌پرسیم آن کار را چقدر خوب انجام می‌دهد.

سوالات متداول درباره تست عملکردی ❓