فرض کنید مسیر خرید یک فروشگاه اینترنتی از نظر منطقی بینقص است: کالا به سبد اضافه میشود، مبلغ درست محاسبه میشود و پرداخت هم ثبت میشود. اما در کمپین شب یلدا، صفحه پرداخت ۱۲ ثانیه طول میکشد، کد تخفیف زیر بار همزمان از کار میافتد یا اطلاعات سفارش کاربر دیگری نمایش داده میشود. قابلیتها «کار میکنند»، ولی محصول باکیفیت نیست. تست غیرکارکردی (Non-Functional Testing) دقیقاً برای کشف همین فاصله میان «کار کردن» و «خوب، امن و پایدار کار کردن» است.
پاسخ کوتاه: تست غیرکارکردی روشی برای سنجش ویژگیهای کیفی و محدودیتهای یک سیستم—مانند سرعت، ظرفیت، امنیت، دسترسپذیری، قابلیت اطمینان، بازیابی و سازگاری—در شرایط تعریفشده است. خروجی خوب این تست یک قضاوت مبهم مثل «سایت سریع است» نیست؛ نتیجهای قابلاندازهگیری مثل «در بار هدف، صدک ۹۵ زمان پاسخ کمتر از آستانه توافقشده باقی ماند» است.
نقشه سریع مقاله: ابتدا تفاوت تست کارکردی و غیرکارکردی را روشن میکنیم، سپس یاد میگیریم یک نیازمندی غیرکارکردی قابلآزمون بنویسیم، انواع اصلی را انتخاب کنیم و با یک سناریوی واقعیِ فروشگاه ایرانی برنامه تست بسازیم.
تست غیرکارکردی چیست؟
تست غیرکارکردی مجموعهای از فعالیتهای تحلیل، آزمایش و اندازهگیری است که کیفیت رفتار سیستم را در یک زمینه مشخص ارزیابی میکند. این زمینه میتواند تعداد کاربران، حجم داده، نوع دستگاه، وضعیت شبکه، مدت اجرا، نقش کاربر یا یک خرابی عمدی باشد. در این آزمونها فقط نمیپرسیم «نتیجه درست بود؟»؛ میپرسیم نتیجه با چه سرعت، هزینه منابع، سطح امنیت و میزان پایداری به دست آمد.
استاندارد ISO/IEC 25010:2023 یک مدل مرجع کیفیت محصول با ۹ ویژگی و زیرویژگیهای مرتبط ارائه میکند و برای تعریف، اندازهگیری و ارزیابی کیفیت در طول چرخه عمر قابل استفاده است. استاندارد جداگانه ISO/IEC 25019:2023 نیز کیفیت در زمان استفاده واقعی را پوشش میدهد. این مدلها به تیم کمک میکنند چیزی از قلم نیفتد؛ اما معیار و آستانه هر محصول باید بر اساس ریسک، کاربران، معماری و هدف کسبوکار خودش تعیین شود.
NFR فقط یک فعالیت تست در انتهای پروژه نیست
نیازمندی غیرکارکردی یا NFR از مرحله تحلیل و طراحی آغاز میشود. معماری، انتخاب زیرساخت، طراحی تجربه کاربر و راهبرد مانیتورینگ همگی روی آن اثر دارند. تستر کیفیت را به محصول «اضافه» نمیکند؛ با شواهد نشان میدهد طراحی و پیادهسازی تا چه اندازه به هدف کیفی توافقشده رسیدهاند.
تفاوت تست کارکردی و غیرکارکردی چیست؟
در فارسی، واژه «عملکرد» گاهی برای هر دو مفهوم Functional و Performance بهکار میرود و ابهام میسازد. در این مقاله، کارکردی معادل Functional و کارایی معادل Performance است.
| موضوع مقایسه | تست کارکردی | تست غیرکارکردی |
|---|---|---|
| پرسش اصلی | سیستم چه کاری انجام میدهد؟ | آن کار را با چه سطحی از کیفیت و تحت چه محدودیتی انجام میدهد؟ |
| نمونه نیازمندی | کاربر بتواند با رمز یکبارمصرف وارد شود. | در بار هدف، ورود در آستانه زمانی توافقشده انجام شود و سرویس پایدار بماند. |
| اوراکل تست | خروجی و قانون کسبوکار مورد انتظار | متریک، آستانه، بازه مشاهده و شرایط اجرا |
| نمونه شکست | مبلغ نهایی اشتباه است. | مبلغ درست است، اما پاسخ بسیار کند یا دسترسی ناامن است. |
| زمان اجرا | در همه سطوح تست | از تحلیل معماری تا پایش پس از انتشار |
این مرز همیشه مطلق نیست. برای مثال «کاربر عادی نباید گزارش مدیر را ببیند» یک قانون کارکردیِ کنترل دسترسی است، در حالی که مقاومت کل سامانه در برابر حمله و مدیریت آسیبپذیریها هدفی امنیتی و کیفی است. بهجای درگیری بر سر برچسب، مشخص کنید ریسک چیست، چه شواهدی لازم است و معیار قبولی چگونه اندازهگیری میشود. برای مرور دقیق سمت دیگر این مقایسه، راهنمای تست کارکردی و انواع آن را ببینید.
چرا تست غیرکارکردی مهم است؟
- از زیان کسبوکار پیشگیری میکند: کندی در صفحه پرداخت، قطعی هنگام کمپین یا از دست رفتن داده مستقیماً روی فروش و اعتماد اثر میگذارد.
- ریسکهای معماری را زود آشکار میکند: برخی گلوگاهها با یک اصلاح کوچک حل نمیشوند و به تغییر کش، پایگاه داده، صف یا طراحی سرویس نیاز دارند.
- تجربه کاربران واقعی را میسنجد: کاربر ایرانی ممکن است با گوشی میانرده، اینترنت موبایل ناپایدار، صفحه راستبهچپ و درگاه پرداخت بیرونی کار کند.
- تصمیم انتشار را شفاف میکند: تیم بهجای «به نظر سریع میآید»، درباره عدد، روند و ریسک باقیمانده تصمیم میگیرد.
- هزینه رخداد را کاهش میدهد: سناریوی بازیابی و هشدارها پیش از بحران تمرین میشوند، نه وسط قطعی تولید.
چگونه یک نیازمندی غیرکارکردی قابلآزمون بنویسیم؟
عبارتهایی مانند «سامانه باید سریع، امن و مقیاسپذیر باشد» قابل تست نیستند. یک NFR مفید معمولاً پنج جزء دارد:
- ویژگی کیفی: دقیقاً چه چیزی مهم است؛ زمان پاسخ، دسترسپذیری، بازیابی یا مصرف حافظه؟
- سناریو و دامنه: کدام سفر کاربر، API، سرویس یا مؤلفه بررسی میشود؟
- شرایط: بار، حجم داده، نوع شبکه، دستگاه، منطقه یا مدت اجرا چیست؟
- متریک و آستانه: چه عددی اندازهگیری میشود و حد قبولی چیست؟
- بازه و منبع مشاهده: عدد در چه بازهای و با داده کدام ابزار یا داشبورد محاسبه میشود؟
الگوی پیشنهادی: «برای [سناریو]، در [شرایط و بار تعریفشده]، مقدار [متریک] باید [آستانه] باشد و نتیجه در [بازه/منبع اندازهگیری] گزارش شود.»
مثال: «برای جستوجوی کالا، با مجموعهداده هماندازه تولید و الگوی بار توافقشده، صدک ۹۵ زمان پاسخ باید زیر بودجه عملکرد مصوب بماند و نرخ خطا از حد تعیینشده عبور نکند.» عدد آستانه را مالک محصول، تیم فنی و عملیات بر اساس داده و ریسک تعیین میکنند؛ یک عدد عمومی و جادویی برای همه سامانهها وجود ندارد.
چرا فقط میانگین کافی نیست؟
میانگین میتواند تجربه کاربران کند را پنهان کند. در تست کارایی، کنار میانگین معمولاً صدکهایی مانند P95 یا P99، نرخ خطا، توان عملیاتی و مصرف منابع بررسی میشوند. همچنین باید مرحله گرمشدن، داده تست، وابستگیهای بیرونی و فاصله محیط آزمایش با تولید ثبت شود تا نتیجه قابل تکرار باشد.
انواع تست غیرکارکردی
لازم نیست هر پروژه همه انواع زیر را با شدت یکسان اجرا کند. انتخاب باید ریسکمحور باشد: برای سامانه مالی امنیت و یکپارچگی داده اولویت بالاتری دارد؛ برای پخش ویدئو کارایی و پایداری شبکه؛ و برای خدمت عمومی دسترسپذیری و سادگی استفاده.
۱. تست کارایی، بار و مقیاسپذیری
این خانواده زمان پاسخ، توان عملیاتی، نرخ خطا، مصرف منابع و رفتار سیستم در بارهای مختلف را بررسی میکند. Load Test بار مورد انتظار، Stress Test مرز و نحوه شکست، Endurance Test پایداری در زمان طولانی و Scalability Test اثر افزایش بار یا منابع را میسنجد. نکته مهم این است که مدل بار باید از سفرهای واقعی کاربر و نسبت عملیاتها ساخته شود، نه فقط تعداد زیادی درخواست یکسان. جزئیات طراحی سناریو در راهنمای تست بار، استرس و مقیاسپذیری آمده است.
۲. تست امنیت و حریم خصوصی
هدف، کشف ضعفهایی است که محرمانگی، یکپارچگی یا دسترسپذیری اطلاعات را تهدید میکنند. مرور طراحی و مدل تهدید، تحلیل کد و وابستگیها، آزمون احراز هویت و مجوزها، اسکن پیکربندی و تست نفوذ کنترلشده مکمل یکدیگرند. تست امنیت نباید به اجرای یک اسکنر و تحویل فهرست هشدارها تقلیل پیدا کند؛ هر یافته باید از نظر قابلیت بهرهبرداری و اثر کسبوکار بررسی شود. نقطه شروع مناسب، مقاله مبانی تست امنیت نرمافزار است.
۳. تست قابلیت اطمینان، بازیابی و تابآوری
این تستها میپرسند سیستم در یک بازه معین چقدر پایدار میماند، هنگام خرابی چگونه افت میکند و با چه سرعت و صحتی برمیگردد. سناریوها میتوانند قطع سرویس وابسته، تأخیر شبکه، پر شدن فضای ذخیرهسازی، شکست یک نمونه یا بازگردانی نسخه پشتیبان باشند. RTO و RPO، نرخ موفقیت عملیات، زمان کشف رخداد و صحت داده پس از بازیابی از معیارهای محتملاند. برای آزمایش فرضیههای تابآوری در محیط کنترلشده، راهنمای مهندسی آشوب و سیستمهای تابآور را بخوانید.
۴. تست کاربردپذیری و دسترسپذیری
کاربردپذیری بررسی میکند کاربران هدف با چه میزان موفقیت، زمان و خطا به هدف میرسند. مشاهده کاربر واقعی، آزمون وظیفه، مصاحبه و ارزیابی اکتشافی شواهد متفاوتی میدهند. راهنمای تست کاربردپذیری روش برنامهریزی این ارزیابی را توضیح میدهد.
دسترسپذیری نیز فقط تطبیق رنگ یا اجرای یک ابزار خودکار نیست. ناوبری با صفحهکلید، نام قابلفهم کنترلها، ترتیب فوکوس، متن جایگزین و تجربه صفحهخوان باید ترکیبی از خودکارسازی و بررسی انسانی داشته باشند. برای ابزارها و محدودیت هر روش، صفحه ابزارهای تست دسترسپذیری و صفحهخوانها را ببینید.
۵. تست سازگاری و انتقالپذیری
این حوزه رفتار محصول را روی مرورگر، سیستمعامل، اندازه صفحه، دستگاه، نسخه API، پیکربندی و محیطهای پشتیبانیشده میسنجد. ماتریس تست باید از داده کاربران و تعهد پشتیبانی ساخته شود؛ پوشش همه ترکیبهای ممکن معمولاً اقتصادی نیست. در محصولات فارسی، راستبهچپ بودن، فونت، اعداد فارسی و لاتین، تاریخ شمسی، ریال/تومان و چیدمان در اندازههای مختلف نیز سناریوهای مهمی هستند. راهنمای تست Cross Browser به ساخت ماتریس پوشش کمک میکند.
۶. نگهداشتپذیری، آزمونپذیری و مشاهدهپذیری
کیفیت فقط چیزی نیست که کاربر نهایی مستقیم میبیند. ساختار ماژولار، امکان تشخیص علت خطا، لاگهای قابلاستفاده، متریک مناسب، ردیابی درخواست و توان اجرای تستهای پایدار، زمان تغییر و بازیابی را کم میکنند. این ویژگیها با بازبینی معماری، تحلیل ایستا، سنجش پیچیدگی، تمرین تشخیص رخداد و بررسی پوشش سیگنالها ارزیابی میشوند. شمار بالای لاگ بهتنهایی نشانه مشاهدهپذیری خوب نیست؛ تیم باید بتواند از سیگنالها به یک تصمیم عملی برسد.
مثال عملی: برنامه تست غیرکارکردی فروشگاه اینترنتی ایرانی
فرض کنید فروشگاه برای کمپین نوروز آماده میشود. مسیر بحرانی شامل ورود با رمز یکبارمصرف، جستوجو، افزودن به سبد، اعمال تخفیف و بازگشت از درگاه پرداخت است. جدول زیر نمونهای آموزشی است؛ عددهای واقعی باید با داده تولید، ظرفیت زیرساخت و سطح ریسک همان کسبوکار تعیین شوند.
| ریسک | سناریوی تست | شاهد یا متریک | معیار قبولی |
|---|---|---|---|
| کندی در کمپین | اجرای ترکیب واقعی جستوجو، سبد و پرداخت با افزایش تدریجی بار | P95/P99، نرخ خطا، throughput، CPU و DB | بودجه مصوب هر سفر نقض نشود |
| قطع درگاه | Timeout، پاسخ تکراری و بازگشت دیرهنگام درگاه | وضعیت سفارش، تراکنش تکراری، زمان بازیابی | نه دوبار برداشت شود و نه سفارش مبهم بماند |
| دسترسی غیرمجاز | تغییر شناسه سفارش و آزمون نقشهای مختلف | پاسخ سرویس، رویداد امنیتی و لاگ حسابرسی | داده کاربر دیگر افشا نشود |
| اینترنت ناپایدار | تأخیر، packet loss و قطعووصل روی موبایل | نرخ تکمیل خرید و پیام خطای قابلفهم | وضعیت قابل بازیابی و اقدام بعدی روشن باشد |
| مشکل رابط فارسی | تومان/ریال، اعداد، تاریخ، RTL و صفحهکلید | خطای کاربر، زمان انجام وظیفه و مشاهده انسانی | مبلغ و مسیر اقدام بدون ابهام باشد |
| بازیابی داده | خرابی کنترلشده و بازگردانی پشتیبان | RTO، RPO و تطبیق سفارشها | اهداف بازیابی توافقشده محقق شوند |
مراحل اجرای تست غیرکارکردی
- ریسکها و ذینفعان را مشخص کنید. شکست کدام سفر بیشترین اثر مالی، امنیتی یا اعتباری دارد؟ مالک تصمیم چه کسی است؟
- NFR قابلاندازهگیری بنویسید. سناریو، شرایط، متریک، آستانه و بازه مشاهده را ثبت کنید.
- خط مبنا بسازید. قبل از بهینهسازی، رفتار فعلی و نوسان طبیعی سیستم را اندازه بگیرید.
- محیط و داده نماینده آماده کنید. تفاوت زیرساخت، نسخهها، حجم داده و سرویسهای بیرونی با تولید را مستند کنید. چکلیست راهاندازی محیط تست در این مرحله مفید است.
- سناریو را کنترلشده اجرا کنید. تغییرها را مرحلهای اعمال کنید، زمانها را همگام نگه دارید و همزمان متریکهای سرویس، زیرساخت و پایگاه داده را جمع کنید.
- نتیجه را تحلیل و بازتولید کنید. همبستگی الزاماً علت نیست؛ گلوگاه یا آسیبپذیری را با آزمایش محدودتر تأیید کنید.
- ریسک باقیمانده را گزارش دهید. فقط Pass/Fail ننویسید؛ دامنه، محدودیت، روند، اثر و پیشنهاد اقدام را ذکر کنید.
- آزمون را در چرخه تحویل و تولید نگه دارید. تستهای سبک را در CI، آزمونهای سنگین را در بازه مناسب و شاخصهای حیاتی را پس از انتشار پایش کنید.
برای تست غیرکارکردی چه ابزاری لازم است؟
ابزار را بعد از سؤال و متریک انتخاب کنید. یک ابزار واحد همه ابعاد کیفیت را نمیسنجد.
| نیاز | دسته ابزار | خروجی مورد انتظار |
|---|---|---|
| کارایی | تولید بار و پروفایلینگ | زمان پاسخ، نرخ، خطا و گلوگاه منابع |
| امنیت | SAST، DAST، تحلیل وابستگی و تست دستی | یافته معتبر با شدت و مسیر اصلاح |
| دسترسپذیری | بررسی خودکار، صفحهکلید و صفحهخوان | نقض قابل بازتولید و اثر آن بر کاربر |
| سازگاری | مرورگر/دستگاه واقعی یا ابری | ماتریس پوشش و تفاوت رفتار |
| تابآوری | تزریق خطا، مانیتورینگ و tracing | رفتار افت، کشف و بازیابی |
پیش از انتخاب، هزینه نگهداری، مهارت تیم، ادغام با CI/CD، امنیت داده تست، امکان خروجیگیری و اعتبار متریکها را بسنجید. اجرای یک اسکریپت بدون مدل بار، داده مناسب و تحلیل سیگنالها «تست کارایی» کامل نیست.
اشتباهات رایج در Non-Functional Testing
- شروع پس از تکمیل محصول: ریسکهای معماری دیر و پرهزینه کشف میشوند.
- نوشتن معیارهای مبهم: واژههایی مثل سریع، پایدار و امن بدون شرایط و آستانه اختلاف ایجاد میکنند.
- کپی کردن عدد رقبا یا اینترنت: آستانهای که به سفر کاربر و هدف تجاری وصل نیست، ممکن است بیشازحد سخت یا بیاثر باشد.
- شبیهسازی غیرواقعی بار: تعداد کاربر مجازی بدون نرخ ورود، think time، نسبت تراکنش و داده نماینده معنای کمی دارد.
- نادیده گرفتن سرویس بیرونی: پیامک، درگاه، نقشه و API شریک میتوانند نتیجه و تجربه شکست را تعیین کنند.
- اتکا به ابزار خودکار: ابزار هشدار میدهد؛ تحلیلگر باید اعتبار، علت و اثر را بررسی کند.
- گزارش فقط یک عدد: نتیجه بدون نسخه، محیط، داده، سناریو و محدودیت قابل مقایسه نیست.
- تست در تولید بدون حفاظ: آزمایش تابآوری یا بار باید مجوز، محدوده، توقف اضطراری و طرح بازگشت داشته باشد.
چکلیست کوتاه تست غیرکارکردی
- سفرهای بحرانی و اثر شکست آنها مشخص شده است.
- برای هر ریسک، NFR قابلاندازهگیری و مالک تصمیم داریم.
- بار، داده، دستگاه و وضعیت شبکه به کاربران هدف نزدیکاند.
- تفاوت محیط تست با تولید مستند شده است.
- متریکهای سمت کاربر، سرویس، پایگاه داده و زیرساخت همزمان ثبت میشوند.
- معیار توقف و طرح بازگشت برای آزمایشهای پرریسک تعریف شده است.
- یافتهها قابل بازتولید و به اثر کسبوکار متصلاند.
- پس از اصلاح، آزمون مجدد و مقایسه با خط مبنا انجام میشود.
- شاخصهای حیاتی پس از انتشار نیز پایش میشوند.
سؤالات متداول درباره تست غیرکارکردی
آیا تست غیرکارکردی همان تست کارایی است؟
خیر. تست کارایی یکی از شاخههای تست غیرکارکردی است. امنیت، کاربردپذیری، دسترسپذیری، سازگاری، قابلیت اطمینان و بازیابی نیز در این خانواده قرار میگیرند.
تست غیرکارکردی را چه زمانی شروع کنیم؟
از زمان تحلیل نیازمندی و طراحی معماری. در مراحل بعد، نوع شواهد تغییر میکند: ابتدا بازبینی و نمونه اولیه، سپس benchmark و آزمون مؤلفه، بعد تست سیستم و پیش از انتشار، و در نهایت مانیتورینگ تولید.
چه کسی آستانه NFR را تعیین میکند؟
یک نفر بهتنهایی نباید آن را حدس بزند. مالک محصول هدف و اثر تجاری، معماری و عملیات ظرفیت و محدودیت فنی، امنیت ریسک تهدید و QA آزمونپذیری معیار را روشن میکنند. خروجی باید توافقی، نسخهبندیشده و قابلاندازهگیری باشد.
آیا میتوان همه تستهای غیرکارکردی را خودکار کرد؟
خیر. تولید بار، بعضی بررسیهای امنیتی و بخشی از دسترسپذیری قابل خودکارسازیاند؛ اما تحلیل ریسک، تست کاربردپذیری با انسان، اعتبارسنجی یافته امنیتی و ارزیابی کیفیت تجربه همچنان به قضاوت تخصصی نیاز دارند.
اگر محیط تست شبیه تولید نباشد، نتیجه بیارزش است؟
نه لزوماً، اما دامنه ادعا محدود میشود. تست کوچکتر میتواند برای مقایسه نسخهها یا یافتن روند مفید باشد، به شرط آنکه تفاوت محیط ثبت شود و عدد آن مستقیماً به ظرفیت تولید تعمیم داده نشود.
جمعبندی
تست غیرکارکردی پلی میان قابلیت درست و تجربه قابلاعتماد است. مسیر مؤثر از فهرست بلند ابزارها شروع نمیشود؛ از ریسکهای محصول و NFRهای قابلاندازهگیری آغاز میشود. سپس تیم با محیط و داده نماینده، متریک مناسب و گزارش شفاف بررسی میکند سیستم در شرایط واقعی چقدر سریع، امن، پایدار، قابلاستفاده و قابلبازیابی است. برای شروع، یک سفر بحرانی را انتخاب کنید، سه ریسک کیفی آن را بنویسید و هر ریسک را به یک سناریو، متریک و آستانه قابلتصمیم تبدیل کنید.
