تست عملکرد در توسعه موبایل: چیست، معیارها و چگونه انجام می‌شود

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

تست عملکرد نوعی تست غیرعملکردی است که تعیین می‌کند برنامه چقدر سریع و کارآمد وظایف خود را انجام می‌دهد. برخلاف تست‌های واحد یا تست‌های UI، تست عملکرد ویژگی‌های کمی را اندازه‌گیری می‌کند: زمان پاسخ، بار پردازنده، مصرف حافظه RAM و مصرف باتری. طبق گزارش Sauce Labs (2025)، 68% از تیم‌های توسعه موبایل تست عملکرد را در چرخه منظم تست قرار می‌دهند و 41% آن را در CI خودکار می‌کنند.

هدف اصلی تست عملکرد اطمینان از این است که برنامه الزامات عملکردی ثبت‌شده در مشخصات را برآورده می‌کند. اگر زمان باز شدن صفحه از 500 میلی‌ثانیه بیشتر شود یا برنامه بیش از 200 MB حافظه RAM در یک دستگاه متوسط مصرف کند، این سیگنالی برای بهینه‌سازی است. خط پایه عملکرد در مرحله اولین انتشار پایدار تعیین می‌شود و در هر به‌روزرسانی بزرگ بازبینی می‌شود.

تست عملکرد روی دستگاه‌های واقعی انجام می‌شود، نه روی شبیه‌سازها، زیرا شبیه‌سازی تصویر دقیقی از استفاده CPU، GPU و منابع شبکه ارائه نمی‌دهد. طبق Apple WWDC (2024)، تست‌های روی شبیه‌ساز نتایج 15–30% بالاتری نسبت به دستگاه واقعی نشان می‌دهند. دستگاه واقعی تنها منبع قابل اعتماد داده‌های عملکرد باقی می‌ماند.

منظم بودن اجرای تست عملکرد به چرخه توسعه بستگی دارد. در توصیه‌های Google Android Performance (2024) ذکر شده است که اندازه‌گیری‌های پایه عملکرد باید در هر درخواست pull اجرا شوند و مجموعه کامل قبل از هر انتشار. خودکارسازی این اندازه‌گیری‌ها امکان تشخیص پسرفت‌های عملکرد را در مراحل اولیه فراهم می‌کند.

معیارهای کلیدی عملکرد

در توسعه موبایل پنج معیار اصلی متمایز می‌شوند که 90% سناریوهای تست عملکرد را پوشش می‌دهند. زمان راه‌اندازی (شروع سرد و شروع گرم) اولین معیاری است که در هر انتشار بررسی می‌شود. Google Play Console (2024) زمان راه‌اندازی را بر اساس آستانه ثبت می‌کند: شروع سرد نباید از 5 ثانیه تجاوز کند، شروع گرم از 1.5 ثانیه. تجاوز از این آستانه‌ها مستقیماً بر رتبه در فروشگاه برنامه تأثیر می‌گذارد.

زمان راه‌اندازی (شروع سرد)

شروع سرد از لحظه کلیک روی آیکون تا ظاهر شدن اولین فریم برنامه اندازه‌گیری می‌شود. iOS از `dispatch_async` برای مقداردهی اولیه تأخیری استفاده می‌کند که زمان قابل مشاهده راه‌اندازی را کاهش می‌دهد. شروع سرد اندروید شامل ایجاد فرآیند، مقداردهی Application و راه‌اندازی Activity است. طبق Google Performance (2024)، هر 100 میلی‌ثانیه تأخیر در شروع سرد، نرخ تبدیل را در برنامه‌های تجارت الکترونیک 1.2% کاهش می‌دهد.

نرخ فریم (FPS)

FPS (Frames Per Second) نرخ فریم در انیمیشن‌ها و پیمایش لیست‌ها است. برای رابط کاربری روان، 60 FPS پایدار مورد نیاز است. Android Studio Profiler و Xcode GPU Report افت FPS را در عملیات سنگین — بارگذاری تصاویر، پردازش JSON یا رندر طرح‌بندی‌های پیچیده نشان می‌دهند. افت زیر 30 FPS توسط کاربر به عنوان «کندی» احساس می‌شود و طبق Adjust (2025) منجر به کاهش نرخ نگهداشت 22% می‌شود.

مصرف حافظه RAM

مصرف حافظه RAM سومین معیار حیاتی است. نشت حافظه علت اصلی کاهش عملکرد در جلسات طولانی است. Instruments Allocations و Android Memory Profiler به شناسایی ارجاعات چرخه‌ای در Swift و Activity‌های آزاد نشده در Android کمک می‌کنند. مصرف باتری معیاری است که اغلب در مرحله تست نادیده گرفته می‌شود. طبق Apple Developer (2024)، برنامه‌های با مصرف انرژی بالا در iOS در پس‌زمینه محدود می‌شوند. Energy Log در Xcode پروفایل وات برنامه را در طول جلسه ثبت می‌کند.

انواع تست عملکرد

تست بار (Load Test) رفتار برنامه را تحت تعداد مورد انتظار کاربران همزمان بررسی می‌کند. برای بک‌اند موبایل این به معنای شبیه‌سازی 1000–10000 درخواست همزمان به API است. بخش سرور باید بار اوج را بدون افزایش زمان پاسخ بیش از 20% از مقدار پایه مدیریت کند. طبق معیارهای k6 (2024)، پیکربندی معمول Load Test شامل افزایش از 0 به 1000 کاربر مجازی در 5 دقیقه است.

تست فشار (Stress Test) نقطه شکست برنامه را تعیین می‌کند — لحظه‌ای که سیستم از پاسخ به درخواست‌ها بازمی‌ایستد یا به طور غیرقابل قبولی تخریب می‌شود. برخلاف Load Test، Stress Test سیستم را فراتر از محدودیت‌های عادی بارگذاری می‌کند. نقطه شکست بر اساس یکی از معیارها ثبت می‌شود: زمان پاسخ از 10 ثانیه تجاوز کند، درصد خطاهای 5XX از 5% بیشتر شود، یا مصرف RAM به 90% از حافظه موجود برسد.

تست حجم (Volume Test) رفتار برنامه را هنگام کار با حجم زیاد داده ارزیابی می‌کند. در زمینه موبایل این بررسی کار با هزاران رکورد در پایگاه داده محلی، ده‌ها گیگابایت حافظه نهان یا میلیون‌ها اعلان push است. SQLite در Android و Core Data در iOS عملکرد متفاوتی در حجم بیش از 100000 رکورد نشان می‌دهند.

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

Xcode Instruments

Xcode Instruments ابزار اصلی برای پروفایل‌سازی برنامه‌های iOS است. Time Profiler نشان می‌دهد کدام روش‌ها بیشترین CPU را مصرف می‌کنند و Allocations تخصیص و آزادسازی حافظه را ردیابی می‌کند. Instruments از ضبط در جلسات طولانی (تا 30 دقیقه) و خروجی ردها برای مقایسه بین بیلدها پشتیبانی می‌کند. Activity Monitor در داخل Instruments بار کلی سیستم را در زمان واقعی نشان می‌دهد.

Android Studio Profiler

Android Studio Profiler پروفایل‌ساز داخلی برای Android است. پروفایلرهای CPU، Memory، Network و Energy را در یک رابط واحد ترکیب می‌کند. ویژگی Android Profiler پشتیبانی از جلسات تعاملی است: توسعه‌دهنده می‌تواند اقداماتی در برنامه انجام دهد و واکنش فوری معیارها را ببیند. طبق Google I/O (2024)، Profiler از ضبط در قالب .perf پشتیبانی می‌کند که قابل مقایسه با baseline در CI است.

Charles Proxy

Charles Proxy و Proxyman ابزارهایی برای تحلیل ترافیک شبکه هستند. آنها زمان هر درخواست HTTP، اندازه پاسخ و هدرها را نشان می‌دهند. برای تست عملکرد ثبت درخواست‌هایی که بیش از 500 میلی‌ثانیه طول می‌کشند مهم است — اینها کاندیدای ذخیره‌سازی یا بهینه‌سازی هستند. Charles از حالت throttle پشتیبانی می‌کند که شبکه‌های کند را شبیه‌سازی می‌کند: 3G، Edge و LTE. Proxyman جایگزین سبک‌تری برای macOS با معماری بومی Swift است.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

تست عملکرد در خط لوله CI/CD

تعبیه تست عملکرد در CI/CD استاندارد صنعت برای سال‌های 2025–2026 است. خط لوله عملکرد شامل سه مرحله است: پیش از commit (اندازه‌گیری‌های سریع در درخواست pull)، شبانه (مجموعه کامل تست‌ها) و پیش از انتشار (مقایسه با baseline در دستگاه‌های مرجع). Bitrise و GitHub Actions از اجرای Xcode Instruments CLI و Gradle Profiler پشتیبانی می‌کنند.

GitHub Actions (2024) یک الگوی رسمی برای تست عملکرد iOS با استفاده از `xcodebuild test-without-building` منتشر کرد. الگو تست‌ها را روی یکی از ماشین‌های GitHub اجرا می‌کند و گزارش را در artifact منتشر می‌کند. Baseline در یک فایل JSON در مخزن ذخیره می‌شود: هنگام تجاوز از آستانه 10%، خط لوله با خطا متوقف می‌شود. این رویکرد از تخریب عملکرد بدون بررسی دستی هر بیلد جلوگیری می‌کند.

مشکل تست عملکرد موبایل در CI ناپایداری نتایج در ماشین‌های مختلف است. Apple Silicon (M1–M4) و Intel Xeon زمان‌های اجرای متفاوتی می‌دهند. راه حل استفاده از نسبت درصدی به baseline به جای مقادیر مطلق است. اگر تست 15% بیشتر از baseline طول بکشد — بیلد به عنوان نیازمند بررسی علامت‌گذاری می‌شود.

نوشتن تست عملکرد در iOS و Android

XCTest Performance در iOS از روش `measure(metrics:)` استفاده می‌کند که بلوک کد را 10 بار اجرا می‌کند و آمار را برمی‌گرداند: میانگین، میانه، انحراف معیار. برای تست عملکرد پایگاه داده استفاده از XCTMemoryMetric که مصرف اوج RAM را ثبت می‌کند راحت است. آستانه از طریق `XCTPerformanceReport` پس از اتمام تست تنظیم می‌شود.

Android Macrobenchmark کتابخانه‌ای از Google برای اندازه‌گیری عملکرد در سطح برنامه است. Macrobenchmark سناریوهای کاربر (راه‌اندازی Activity، پیمایش RecyclerView، باز کردن WebView) را اجرا می‌کند و زمان اجرا را اندازه‌گیری می‌کند. Baseline Profile مجموعه‌ای از کلاس‌ها و روش‌هاست که کامپایلر Android از پیش بهینه‌سازی می‌کند. Google Play از Baseline Profile برای加速 اولین راه‌اندازی تا 30% استفاده می‌کند.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

هر دو رویکرد — XCTest Performance و Android Macrobenchmark — از یک مفهوم استفاده می‌کنند: اندازه‌گیری چندگانه با میانگین‌گیری و مقایسه با آستانه. عملکرد را نمی‌توان به یک عدد تقلیل داد. هر انتشار باید با گزارشی از عملکرد همراه باشد که روند معیارها را در 5 بیلد آخر نشان دهد. چنین گزارشی به تیم اجازه می‌دهد تخریب را قبل از اینکه کاربران متوجه شوند ببینند.