کندی موبایل معمولاً با یک عدد مبهم مثل «اپ سنگین است» گزارش میشود؛ اما این عبارت نه قابل تکرار است، نه مالک اصلاح را مشخص میکند. آیا اولین فریم دیر دیده میشود؟ صفحه زود ظاهر میشود ولی هنوز نمیتوان روی آن کاری انجام داد؟ اسکرول در گوشی ۱۲۰ هرتز پرش دارد؟ درخواست پرداخت پشت شبکهٔ متغیر چند بار تکرار میشود؟ یا دستگاه پس از چند دقیقه گرم و کند میشود؟ تست عملکرد اپلیکیشن موبایل زمانی ارزش دارد که این تجربهها را به سناریو، معیار، بودجه و شواهد قابل مقایسه تبدیل کند.
این راهنما برای مهندس QA، توسعهدهندهٔ Android و iOS، مدیر محصول و SRE موبایل نوشته شده است. از تعریف سفر بحرانی و انتخاب دستگاه تا اندازهگیری زمان اجرا، پاسخگویی، فریم، CPU، حافظه، شبکه، انرژی و رگرسیون در CI پیش میرویم. ابزارهایی مانند Macrobenchmark، Perfetto، Android Studio Profiler، XCTest، Instruments، MetricKit و Apptim را نیز بر اساس پرسشی که پاسخ میدهند مقایسه میکنیم؛ نه بر اساس طول فهرست قابلیتهایشان.
خلاصهٔ اجرایی: یک تست خوب باید بگوید «کدام نسخه، روی کدام دستگاه و سیستمعامل، با چه وضعیت نصب و داده، در کدام شبکه و سناریو، چند بار اجرا شد و توزیع نتیجه چه بود». میانگین یک اجرای دستی یا درصد باتری قبل و بعد، مبنای قابل اتکایی برای انتشار نیست.
تست عملکرد اپلیکیشن موبایل دقیقاً چیست؟
Mobile App Performance Testing ارزیابی سرعت، پاسخگویی، پایداری و مصرف منابع برنامه در شرایط کنترلشده و سپس تطبیق آن با تجربهٔ کاربران واقعی است. موضوع فقط «سریع بودن» نیست. اپ ممکن است سریع باز شود اما حافظه را پس ندهد، در اسکرول فریم از دست بدهد، در پسزمینه شبکه و باتری مصرف کند یا هنگام بازگشت از درگاه پرداخت وضعیت سفارش را اشتباه بازیابی کند.
سه لایه را از هم جدا کنید:
- کلاینت و دستگاه: کد برنامه، main thread، رندر، تخصیص حافظه، ذخیرهسازی، سنسورها و چرخهٔ حیات؛
- شبکه: latency، پهنای باند، packet loss، تغییر اتصال، DNS/TLS، تعداد درخواست و retry؛
- بکاند: زمان پاسخ API، ظرفیت، صف، دیتابیس و وابستگیهای بیرونی.
این مقاله مالک لایهٔ کلاینت و تجربهٔ انتهابهانتها روی دستگاه است. برای ظرفیت سرویس و کاربر همزمان، راهنمای تست عملکرد و بار را بخوانید؛ برای طراحی ترکیب Load، Stress و Endurance نیز به برنامهریزی انواع تست عملکرد رجوع کنید. سریع بودن API تضمین نمیکند parsing پاسخ، ساخت View، نوشتن دیتابیس محلی و نمایش نتیجه روی موبایل سریع باشد.
پیش از ابزار: قرارداد اندازهگیری را بنویسید
بیشتر اختلافهای تیمی از ابزار نیست؛ از عوض شدن بیصدای شرایط تست است. پیش از ثبت اولین trace، یک manifest کوتاه کنار نتیجه نگه دارید.
۱. سفر بحرانی و نقطههای شروع و پایان
بهجای «عملکرد صفحهٔ پرداخت»، رویدادها را دقیق تعریف کنید: لمس «پرداخت»، نمایش حالت در حال پردازش، خروج به PSP، بازگشت با deep link، بازیابی وضعیت سفارش و قابل لمس شدن دکمهٔ مشاهدهٔ رسید. برای هر مرحله یک نشانهٔ قابل مشاهده یا signpost بگذارید. ساعت دستگاه، لاگ برنامه و trace باید امکان همبستگی داشته باشند.
سفرهای بحرانی معمولاً شامل اجرای برنامه، ورود، جستوجو، پیمایش فهرست، باز کردن جزئیات، بارگذاری یا ارسال فایل، خرید، پرداخت، استفادهٔ پسزمینه و بازیابی پس از قطعشدن فرایند هستند. انتخاب را با ریسک کسبوکار انجام دهید، نه فقط سهولت اتوماسیون.
۲. بودجهٔ عملکرد، نه عدد تزئینی
برای هر سفر، معیار و آستانهای تعریف کنید که با تجربهٔ محصول ارتباط دارد. نمونه: صدک ۹۰ زمان اولین نمایش در گروه دستگاه میانرده، صدک ۹۵ زمان قابل استفاده شدن صفحه، نرخ فریمهای کند در اسکرول، سقف رشد حافظه پس از ۲۰ چرخه، تعداد درخواست و بایت منتقلشده، یا بیشینهٔ زمان اشغال main thread. بودجه باید برای نسخه، دستگاه و شرایط مشخص باشد؛ یک عدد جهانی برای همهٔ محصولات وجود ندارد.
اگر هنوز baseline ندارید، ابتدا چند نسخه داده جمع کنید، سپس آستانه را بر اساس توزیع، ریسک و هدف محصول تعیین کنید. بودجهای که هر build آن را میشکند فقط نویز میسازد؛ بودجهای که هیچگاه نمیشکند نیز چیزی را محافظت نمیکند.
۳. ماتریس دستگاه و سیستمعامل
یک گوشی پرچمدار روی Wi-Fi آزمایشگاه نمایندهٔ کاربران نیست. ماتریس را بر اساس تلهمتری یا دستکم فرضیهٔ بازار بسازید: یک دستگاه پایینرده، یک میانردهٔ پرتکرار و یک بالارده؛ کمینه و نسخهٔ رایج سیستمعامل؛ نمایشگر ۶۰، ۹۰ یا ۱۲۰ هرتز در صورت ارتباط؛ RAM و معماری پردازنده؛ فضای ذخیرهسازی کم؛ و وضعیت battery saver یا thermal.
برای بازار ایران، سهم دستگاههای Android قدیمیتر، تفاوت ROM سازندگان، فونت و چیدمان راستبهچپ، اعداد فارسی، شبکهٔ متغیر موبایل، VPN و رفتوبرگشت به اپ PSP را در فرضیهها وارد کنید. روش ساخت ماتریس ریسکمحور در راهنمای ماتریس تست سازگاری آمده است.
۴. شرایط تکرارپذیر
- شمارهٔ build، نوع build و commit را ثبت کنید؛ build دیباگ را با release مقایسه نکنید.
- نسخهٔ OS، مدل دستگاه، سطح شارژ، دما، نرخ نوسازی، روشنایی و وضعیت power saver را ثبت کنید.
- مشخص کنید نصب تازه، پس از update، با cache گرم یا با دادهٔ کاربر اجرا میشود.
- شبکه را با profile نامگذاریشده ثبت کنید: latency، bandwidth، loss و نوع اتصال.
- برنامههای پسزمینه، اعلانها و همگامسازی ناخواسته را کنترل کنید.
- warm-up و تعداد iteration را ثابت نگه دارید و نتیجهٔ خام، میانه و صدکها را نگه دارید.
شبیهساز برای بازخورد سریع و پوشش نسخهها مفید است، اما زمان CPU، GPU، انرژی، thermal و برخی رفتارهای شبکه را جایگزین دستگاه واقعی نمیکند. سیاست رزرو، پاکسازی و پایش device lab را در مدیریت محیط تست مستند کنید.
معیارهای کلیدی تست عملکرد موبایل
زمان اجرا: اولین فریم با «آمادهٔ استفاده» یکی نیست
در Android، شروع سرد یعنی فرایند برنامه باید از صفر ساخته شود؛ شروع گرم و داغ بخشی از کار و state را حفظ کردهاند. مستند رسمی Android دو نقطهٔ مهم را تفکیک میکند: TTID و TTFD در زمان اجرای برنامه. TTID زمان رسیدن به اولین فریم و TTFD زمان رسیدن به نمایش کامل اعلامشده توسط برنامه است. یک splash یا skeleton سریع میتواند TTID را خوب کند، بیآنکه صفحه واقعاً قابل استفاده باشد؛ بنابراین «Time to Useful» یا «Time to Interactive» محصول را نیز با signpost مشخص کنید.
اصطلاحات و مسیر چرخهٔ حیات iOS را با تعریف Android یکی نگیرید. Apple در راهنمای کاهش زمان launch پیشنهاد میکند دادهٔ Xcode Organizer را در صدکهای ۵۰ و ۹۰ و میان مدلهای دستگاه مقایسه کنید و برای علتیابی از App Launch template و Time Profiler در Instruments بهره ببرید.
هر نتیجهٔ startup باید وضعیت را همراه خود داشته باشد: cold/warm، نخستین اجرای پس از نصب یا update، ورودشده یا مهمان، cache و دیتابیس، اتصال شبکه و مسیر اولیه. یک عدد «launch time» بدون این برچسبها قابل مقایسه نیست.
پاسخگویی و اشغال main thread
زمان پاسخ به لمس را از زمان کامل شدن عملیات شبکه جدا کنید. بازخورد بصری باید سریع آغاز شود، حتی اگر نتیجه بعداً برسد. کار طولانی، I/O همزمان، lock، serialization سنگین یا layout پیچیده روی main thread به تأخیر، hang یا در Android به ANR منجر میشود. برای هر تعامل این نقطهها را ثبت کنید:
- زمان رخداد ورودی کاربر؛
- زمان نخستین تغییر قابل مشاهده؛
- زمان آماده شدن محتوای اصلی؛
- زمانی که همهٔ کنترلهای لازم قابل تعاملاند.
در iOS، hang و hitch یک مفهوم نیستند: hang به پاسخگو نبودن main run loop مربوط است و hitch وقفه در چرخهٔ رندر است. Time Profiler، Hangs و Hitches در Instruments به پرسشهای متفاوت پاسخ میدهند. در Android نیز trace باید نشان دهد UI thread مشغول کار، منتظر lock/I/O یا از CPU کنار گذاشته شده است.
رندر، frame time و jank
صرفاً گزارش «FPS متوسط» جهشهای آزاردهنده را پنهان میکند. مدت هر فریم، نرخ فریمهای کند، فریمهای منجمد و context صفحه را ثبت کنید. بودجهٔ نظری فریم به نرخ نوسازی بستگی دارد:
| نرخ نمایشگر | بودجهٔ تقریبی هر فریم | برداشت درست |
|---|---|---|
| ۶۰ هرتز | ۱۶٫۷ میلیثانیه | کار CPU و GPU باید با چرخهٔ نمایش هماهنگ شود. |
| ۹۰ هرتز | ۱۱٫۱ میلیثانیه | همان صفحه در دستگاه سریعتر، بودجهٔ کوتاهتری دارد. |
| ۱۲۰ هرتز | ۸٫۳ میلیثانیه | «زیر ۱۶ میلیثانیه» دیگر تضمینکنندهٔ نرمی نیست. |
این اعداد deadline تقریبیاند، نه KPI مستقل. مستند Slow Rendering در Android تفاوت budget در ۶۰، ۹۰ و ۱۲۰ FPS را توضیح میدهد. در عمل نرخ پویا، pipeline رندر و نوع UI را لحاظ کنید. مسیرهای مهم مثل اسکرول فهرست تراکنش، باز شدن keyboard فارسی، انیمیشن ورود و نمودارهای طولانی را جدا برچسب بزنید.
CPU، thread و thermal throttling
میانگین CPU بهتنهایی علت را نمیگوید. spike کوتاه ممکن است طبیعی باشد؛ CPU پایدار بالا در همگامسازی پسزمینه، حلقهٔ polling یا decode تصویر میتواند باتری و دما را بالا ببرد. ابتدا بازهٔ کند را در system trace پیدا کنید، سپس call stack، thread state، فرکانس هسته و کار خود برنامه در برابر کار سیستم را ببینید. راهنمای رسمی انواع profile و system trace در Android برای انتخاب trace مناسب نقطهٔ شروع خوبی است.
آزمون کوتاه ممکن است مشکل thermal را پنهان کند. برای مسیری مانند پخش ویدئو، نقشه، تماس یا اسکن دوربین، تست sustained تعریف کنید و دما، افت فرکانس و تغییر frame time را در طول زمان ببینید. اجرای همزمان screen recording یا profiler سنگین میتواند خودش نتیجه را تغییر دهد؛ overhead ابزار را با یک اجرای کنترل بسنجید.
حافظه، leak و فشار سیستم
به peak حافظه اکتفا نکنید. baseline پس از ورود، رشد طی تکرار یک سفر، حافظه پس از خروج از صفحه، objectهای retained، دفعات و مکث GC، warning حافظه و رفتار پس از background/foreground را بررسی کنید. سناریوی مفید برای کشف leak این است که صفحهٔ جزئیات را ۲۰ بار باز و بسته کنید، GC قابل کنترل را در نقاط ثابت اعمال کنید و ببینید baseline به کجا برمیگردد.
تعریف حافظه در پلتفرمها متفاوت است. Android برای حافظهٔ مشترک از شاخصهایی مانند PSS استفاده میکند؛ توضیح آن در مرور مدیریت حافظهٔ Android آمده است. مقدار خام Android و iOS یا دو ابزار با تعریفهای متفاوت را مستقیماً رتبهبندی نکنید. روند یک معیار ثابت روی همان خانوادهٔ دستگاه معمولاً مفیدتر است.
شبکه و کارایی داده
«API دو ثانیه طول کشید» هنوز تشخیص نیست. DNS، برقراری اتصال، TLS، زمان سمت سرور، دانلود، decode/decompression، parsing، نوشتن cache و رندر را جدا کنید. تعداد درخواست، بایت ارسال/دریافت، cache hit، retry، درخواست تکراری و کار پسزمینه را نیز ثبت کنید.
حداقل این شرایط را روی سفرهای بحرانی اجرا کنید: شبکهٔ خوب، latency بالا، bandwidth پایین، packet loss، قطع و وصل، تغییر Wi-Fi به دادهٔ موبایل و offline. در اپ ایرانی، برگشت از PSP با اینترنت ضعیف و چند بار لمس دکمهٔ پرداخت باید به idempotency و بازیابی مطمئن وضعیت منجر شود، نه دو سفارش یا spinner بیپایان. برای دید جامعترِ سناریوهای موبایل، راهبرد تست اپلیکیشن موبایل را ببینید.
انرژی و باتری
درصد باتری قبل و بعد از یک اجرای کوتاه، معیار کمدقتی است؛ ظرفیت باتری، دما، روشنایی، سلامت باتری، شبکه، رادیو، screen recording و فعالیتهای سیستم نتیجه را جابهجا میکنند. ابتدا رفتارهای انرژیبر را اندازه بگیرید: CPU پایدار، wakeup و wakelock، GPS، دوربین، رادیوی شبکه، timer، کار پسزمینه و تکرار درخواست. سپس سناریوهای هممدت و شرایط همسان را مقایسه کنید.
یک نکتهٔ بهروز: مستند رسمی Battery Historian میگوید این ابزار دیگر فعالانه نگهداری نمیشود و در صورت امکان System Trace، Macrobenchmark power metric یا Power Profiler ترجیح دارد. در iOS، Energy Log و دادههای Organizer/MetricKit برای مشاهدهٔ الگو مناسباند. نتیجه را بهصورت «انرژی/اثر نسبی این سناریو در این دستگاه» بیان کنید، نه وعدهٔ قطعی چند درصد افزایش عمر باتری.
پایداری: crash، ANR، hang و termination
Crash-free rate لازم است اما کافی نیست. ANR، hang، watchdog termination، low-memory termination، freeze و failureهای خاموش مانند از دست رفتن نتیجهٔ پرداخت را جدا کنید. نسخه، مدل دستگاه، OS، مسیر کاربر و trace یا stack را به رخداد وصل کنید. در بازتولید خطاهای ناپایدار، روش جمعآوری شواهد در راهنمای باگهای متناوب کمک میکند.
حجم، نصب، update و ذخیرهسازی
حجم download تنها عدد مهم نیست. زمان نصب و update، فضای مصرفی پس از نخستین اجرا، رشد cache، migration دیتابیس، نوشتن زیاد روی storage و رفتار در فضای کم را بررسی کنید. یک update ممکن است launch نسخهٔ جدید را فقط برای کاربران قدیمی کند کند؛ اگر تست همیشه با نصب تازه انجام شود این رگرسیون دیده نمیشود.
انتخاب ابزار بر اساس پرسش
| پرسش | Android | iOS | ابزار مکمل |
|---|---|---|---|
| startup یا یک سفر بحرانی رگرس شده؟ | Macrobenchmark و StartupTimingMetric | XCTest و XCTApplicationLaunchMetric یا signpost | Apptim برای اجرای یکسان روی چند دستگاه |
| main thread کجا متوقف میشود؟ | Perfetto/System Trace و CPU Profiler | Instruments Time Profiler و Hangs | لاگ و trace ID محصول |
| اسکرول چرا پرش دارد؟ | FrameTimeline، JankStats، Macrobenchmark | Hitches/Core Animation و XCTHitchMetric | ویدئو و نشانهٔ مرحله |
| حافظه چرا رشد میکند؟ | Memory Profiler و heap dump | Allocations، Leaks و Memory Graph | چرخهٔ تکراری قابل اتوماسیون |
| مصرف انرژی از کجاست؟ | Power Profiler، System Trace و power metric | Energy Log و Organizer | آزمون پایدار روی دستگاه واقعی |
| کاربر واقعی کجا مشکل دارد؟ | Android vitals و تلهمتری محصول | Xcode Organizer/MetricKit و تلهمتری محصول | تقسیم بر نسخه، دستگاه، OS و سفر |
ابزارهای Android
Macrobenchmark برای سنجش تکرارشوندهٔ startup، scrolling و سفرهای سطح اپ در build نزدیک به انتشار مناسب است؛ Microbenchmark برای تابع یا قطعهکد محدود. تفاوت این دو در مرور رسمی Android Benchmark روشن شده است. نتیجهٔ benchmark را همراه trace نگه دارید تا regression فقط یک عدد قرمز نباشد.
Perfetto/System Trace تصویر زمانبندی threadها، CPU، رخدادهای فریم، I/O و بخشهای علامتگذاریشدهٔ برنامه را میدهد. Android Studio Profiler برای CPU، حافظه و انرژی در تحلیل تعاملی مفید است. JankStats به فریم کند context رابط کاربری میافزاید و Android vitals وضعیت کاربران منتشرشده را نشان میدهد. Baseline Profiles ابزار تست نیستند، اما پس از اندازهگیری میتوانند مسیرهای رایج را از نخستین اجرا بهینه کنند؛ بهبود باید دوباره benchmark شود.
ابزارهای iOS
XCTest Performance معیارهای launch، clock، CPU، memory، storage، hitch و signpost را به تست تکرارپذیر تبدیل میکند. فهرست فعلی این معیارها در مستند Performance Tests اپل قرار دارد. baseline و تنظیمات scheme/test plan را نسخهبندی کنید.
Instruments ابزار علتیابی است: Time Profiler برای CPU و main thread، Allocations/Leaks برای حافظه، Hangs/Hitches برای پاسخگویی و Energy Log برای انرژی. Xcode Organizer و MetricKit دادهٔ field را برای نسخههای منتشرشده تکمیل میکنند. چرخهٔ درست آن است که anomaly را در field ببینید، در آزمایشگاه بازتولید و profile کنید، سپس یک performance test برای جلوگیری از بازگشت آن بسازید؛ همین چرخه در راهنمای عملکرد Apple نیز توصیه میشود.
Apptim چه زمانی مفید است؟
Apptim یک لایهٔ چندسکویی برای ثبت session و مقایسهٔ معیارهای دستگاه و اپ است. طبق مستند رسمی Apptim، Desktop برای تست دستی با دستگاه خود و CLI برای سناریوهای خودکار و device farm ارائه میشود و معیارهایی مانند CPU، حافظه، رندر و رخدادها را پوشش میدهد. این ابزار برای شروع سریع، گزارش قابل اشتراک و regression روی چند دستگاه ارزشمند است.
اما گزارش Apptim جای trace بومی و دانش پلتفرم را نمیگیرد. وقتی CPU بالا یا frame کند دیدید، برای علت به Perfetto/Profiler یا Instruments برگردید. تعریف هر metric و تفاوت پلتفرم را از راهنمای معیارهای Apptim بخوانید؛ threshold پیشفرض را بدون baseline محصول به شرط انتشار تبدیل نکنید. قابلیتها، محدودیتهای پلن و پشتیبانی نسخهها نیز ممکن است تغییر کنند، پس مستند فعلی ابزار را مبنا بگذارید.
فرایند عملی تست عملکرد، گامبهگام
گام ۱: سؤال و مالک را مشخص کنید
نمونهٔ سؤال خوب: «آیا نسخهٔ ۳.۸ زمان قابل استفاده شدن صفحهٔ خانه را در دستگاه میانرده و نصب تازه بیش از ۱۰٪ بدتر کرده است؟» مالک میتواند تیم Android، iOS، backend یا زیرساخت باشد، اما تا trace ندارید مالک را از روی حدس تعیین نکنید.
گام ۲: baseline قابل بازتولید بسازید
نسخهٔ مرجع و candidate را روی یک device pool، داده و شبکه اجرا کنید. ترتیب اجرا را در صورت امکان جابهجا کنید تا اثر گرما یا باتری یکطرفه نباشد. چند iteration ثبت کنید؛ دادهٔ پرت را بیدلیل حذف نکنید و دلیل هر حذف را نگه دارید.
گام ۳: ابتدا اندازه بگیرید، بعد profile کنید
Profiler دائمی میتواند overhead بسازد. ابتدا با benchmark کممداخله regression را تأیید کنید؛ سپس همان بازه را trace بگیرید. markerهای معنایی مثل checkout_start، gateway_return و receipt_interactive اتصال trace فنی به سفر کاربر را ممکن میکنند.
گام ۴: علت را با آزمایش کوچک جدا کنید
یک متغیر را عوض کنید: تصویر را cache کنید، parsing را از main thread بیرون ببرید، polling را حذف کنید یا اندازهٔ payload را ثابت نگه دارید. اگر نتیجه تغییر کرد، فرضیه تقویت میشود؛ correlation در trace بهتنهایی اثبات علت نیست.
گام ۵: اصلاح، آزمون مجدد و guardrail
همان manifest و device pool را تکرار کنید. علاوه بر معیار هدف، guardrailها را ببینید: کاهش launch نباید crash، مصرف حافظه یا correctness را بدتر کند. نتیجهٔ قبل و بعد، confidence و trace را به PR وصل کنید. بعد یک تست پایدار به pipeline اضافه کنید؛ راهبرد ادغام در تست پیوسته در DevOps شرح داده شده است.
مثال ایرانی: رگرسیون صفحهٔ پرداخت
فرض کنید کاربران یک فروشگاه ایرانی میگویند پس از بازگشت از درگاه، اپ «هنگ» میکند. این مثال آموزشی و اعداد آن فرضیاند:
- دستگاه: Android میانرده با ۴ گیگابایت RAM، نمایشگر ۶۰ هرتز و نسخهٔ رایج OS؛
- شبکه: دادهٔ موبایل با latency و packet loss کنترلشده؛
- داده: سبد ۲۰ قلمی، مبلغ ریالی، کد تخفیف و کاربر واردشده؛
- شروع: لمس پرداخت؛ پایان: نمایش رسید و قابل لمس شدن دکمهٔ پیگیری؛
- تکرار: ۱۵ بار برای نسخهٔ مرجع و candidate، با ترتیب متناوب.
benchmark نشان میدهد صدک ۹۰ زمان قابل استفاده شدن از ۲٫۱ به ۳٫۴ ثانیه رسیده، اما زمان API فقط ۱۵۰ میلیثانیه تغییر کرده است. trace چند نشانه میدهد: deep link دو بار پردازش میشود، پاسخ بزرگ سفارش روی main thread parse میشود و list پس از هر item دوباره layout میگیرد. در این وضعیت افزایش ظرفیت backend راهحل اصلی نیست.
تیم handler بازگشت را idempotent میکند، parsing را از main thread خارج و update فهرست را batch میکند. اجرای مجدد با همان قرارداد باید زمان، فریمهای کند و correctness سفارش را همزمان مقایسه کند. سپس تست deep link، شمارش درخواست و بودجهٔ signpost به CI افزوده میشود و تلهمتری field بر اساس نسخه و مدل دستگاه پایش میشود.
تست عملکرد در CI/CD و محیط واقعی
همهٔ تستها را در هر commit اجرا نکنید. یک هرم عملی بسازید:
- PR: microbenchmarkها و چند سفر کوتاه و پایدار روی device ثابت؛
- شبانه: ماتریس کوچک دستگاه، startup، scrolling، memory loop و شبکههای منتخب؛
- پیش از انتشار: ماتریس ریسکمحور، update/migration، endurance و مقایسه با نسخهٔ تولید؛
- پس از انتشار: rollout مرحلهای و پایش vitals، Organizer/MetricKit و معیارهای محصول.
بهجای fail روی یک iteration، از حداقل نمونه، پنجرهٔ baseline و سیاست triage استفاده کنید. تغییر سختافزار runner، نسخهٔ OS یا ابزار را مثل تغییر محیط آزمایش ثبت کنید. داشبورد فقط روند را نشان دهد؛ برای تصمیم انتشار باید بتوان از نقطهٔ قرمز به build، دستگاه، سفر، لاگ و trace رسید. برای طراحی شاخصهای فرایندی، راهنمای معیارهای اثربخشی تست نیز مفید است.
خطاهای رایج و اصلاح آنها
- فقط یک گوشی سریع: device matrix را از دادهٔ کاربر و ریسک بسازید.
- فقط میانگین: توزیع، median، p90/p95، بدترین نمونه و تعداد iteration را نگه دارید.
- مقایسهٔ build دیباگ و release: variant و تنظیمات compiler/profiling را ثابت کنید.
- یکی گرفتن TTID با آمادهٔ استفاده: نقطهٔ مفید/تعاملی محصول را جدا علامتگذاری کنید.
- FPS ثابت برای همه: frame time و نرخ نوسازی واقعی را مبنا قرار دهید.
- باتری با اختلاف درصد کوتاه: شرایط را کنترل و رفتارهای انرژیبر و انرژی نسبی را بسنجید.
- مقصر دانستن backend: زمان شبکه، server، parsing، storage و render را تفکیک کنید.
- profile بدون baseline: نخست regression را تکرارپذیر کنید، سپس سراغ trace علت بروید.
- نادیده گرفتن observer effect: overhead ویدئو، debugger و profiler را با کنترل بسنجید.
- threshold کپیشده از ابزار: بودجه را به سفر، دستگاه، baseline و ریسک محصول وصل کنید.
چکلیست آمادهٔ اجرا
- سفر بحرانی، شروع، پایان و حالتهای خطا تعریف شدهاند.
- نسخهٔ برنامه، build type، commit، device، OS و داده ثبت میشوند.
- وضعیت cold/warm، نصب/update و cache مشخص است.
- شبکه با latency، bandwidth و loss نامگذاری شده است.
- زمان اولین نمایش و زمان واقعاً قابل استفاده شدن جدا هستند.
- frame time، responsiveness، CPU، memory، network، energy و stability بر اساس ریسک پوشش دارند.
- آزمون انرژی و thermal روی دستگاه واقعی و با شرایط کنترلشده انجام میشود.
- نتیجه شامل توزیع، تعداد تکرار، trace و مقایسهٔ نسخهٔ مرجع است.
- اصلاح با guardrailهای correctness، crash و مصرف منابع دوباره سنجیده میشود.
- تست پایدار به lane مناسب CI و anomaly واقعی به پایش field وصل میشود.
سؤالات متداول
تست عملکرد اپلیکیشن موبایل با تست بار چه تفاوتی دارد؟
تست عملکرد موبایل رفتار کلاینت روی دستگاه، رندر، پاسخگویی و مصرف منابع را میسنجد. تست بار معمولاً ظرفیت backend را زیر کاربران یا درخواستهای همزمان ارزیابی میکند. برای سفرهای مهم به هر دو نیاز دارید و trace ID باید زمان کلاینت را به زمان سرویس وصل کند.
برای تست عملکرد، شبیهساز کافی است؟
برای بازخورد سریع و بخشی از رگرسیونها مفید است، اما نمایندهٔ مطمئنی برای باتری، thermal، GPU، رادیوی شبکه و فشار حافظه نیست. تصمیم انتشار را برای معیارهای وابسته به سختافزار روی دستگاه واقعی تأیید کنید.
بهترین عدد برای زمان اجرای اپلیکیشن چیست؟
یک عدد جهانی وجود ندارد. cold/warm، TTID، زمان نمایش کامل و زمان قابل استفاده شدن را جدا کنید؛ سپس برای گروه دستگاه و سفر محصول baseline و بودجه بسازید. آستانههای platform vitals سیگنال سلامتاند، نه لزوماً هدف UX محصول شما.
آیا Apptim جای Android Studio Profiler و Instruments را میگیرد؟
خیر. Apptim برای ثبت و مقایسهٔ چندسکویی و CI مفید است؛ ابزارهای بومی برای دیدن call stack، thread state، تخصیص حافظه و pipeline رندر عمق بیشتری دارند. معمولاً Apptim یا benchmark مسئله را آشکار و ابزار بومی علت را مشخص میکند.
مصرف باتری اپ را چگونه قابل اعتماد مقایسه کنیم؟
سناریو، مدت، دستگاه، دما، شارژ، روشنایی، شبکه و فعالیت پسزمینه را ثابت کنید؛ چند بار اجرا و رفتارهایی مثل CPU، radio، GPS و wakeup را ثبت کنید. اثر نسبی دو نسخه روی همان شرایط معتبرتر از اختلاف درصد باتری در یک اجرای کوتاه است.
جمعبندی
تست عملکرد اپلیکیشن موبایل از خرید ابزار شروع نمیشود؛ از یک سؤال دقیق و قرارداد اندازهگیری آغاز میشود. سفر بحرانی و بودجه را تعریف کنید، device matrix واقعی بسازید، baseline را تکرارپذیر بگیرید، با trace علت را جدا کنید و اصلاح را با همان شرایط و guardrailها بسنجید. پیوند آزمایشگاه، CI و دادهٔ field است که یک نمودار performance را به تصمیم مطمئن انتشار تبدیل میکند.
