تست اپلیکیشن موبایل؛ راهنمای Android و iOS با چک‌لیست

یک باگ موبایل ممکن است فقط وقتی رخ دهد که کاربر وسط پرداخت از اپ خارج شود، شبکه از Wi‑Fi به اینترنت همراه تغییر کند و سیستم‌عامل فرایند را ببندد. همان سناریو روی لپ‌تاپ توسعه و حتی یک Emulator سریع کاملاً سبز است. تفاوت تست اپلیکیشن موبایل با تست یک وب‌سایت فقط اندازهٔ صفحه نیست؛ چرخهٔ عمر برنامه، محدودیت منابع، مجوزها، دستگاه، سیستم‌عامل، شبکه و کانال انتشار همگی بخشی از Test Object هستند.

این راهنما یک استراتژی عملی برای Android و iOS می‌سازد: چه دستگاه‌هایی انتخاب کنیم، کجا از Emulator/Simulator یا دستگاه واقعی استفاده کنیم، چه سناریوهایی مخصوص موبایل‌اند، اتوماسیون را در چه لایه‌ای قرار دهیم و پیش از انتشار چه شواهدی لازم داریم. هدف «تست روی همهٔ گوشی‌ها» نیست؛ هدف پوشش قابل‌دفاعِ ریسک‌های کاربران واقعی است.

تست اپلیکیشن موبایل چیست؟

Mobile App Testing ارزیابی رفتار، کیفیت و ریسک یک برنامه در تعامل با پلتفرم موبایل، دستگاه، سرویس‌های Backend و کاربر است. دامنه می‌تواند برنامهٔ Native، Cross-platform یا Hybrid باشد. Mobile Web نیز بخشی از ریسک‌های دستگاه و مرورگر را دارد، اما نصب، مجوز، Lifecycle و Store را مانند اپ نصب‌شده تجربه نمی‌کند.

یک برنامهٔ موبایل فقط UI نیست. محدودهٔ تست ممکن است شامل این اجزا باشد:

• باینری/Bundle و تنظیمات Release؛
• منطق محلی، Cache، Database و Secure storage؛
• API، Push، Deep link و سرویس‌های ثالث؛
• مجوزها، Clipboard، Share sheet، Camera، Location و Sensor؛
• سیستم‌عامل، اندازهٔ Window، Theme و قابلیت‌های دسترس‌پذیری؛
• فرایند نصب، Update، Migration، Rollout و بازخورد پس از انتشار.

پس «صفحه باز شد» شواهد کافی نیست. باید State، دادهٔ محلی/سرور، اثر جانبی، مجوز، مصرف منابع و رفتار در قطع و بازگشت را نیز مشاهده کرد.

ریسک‌های منحصربه‌فرد موبایل

• Fragmentation: نسخهٔ OS، سازنده، اندازهٔ صفحه، Memory، CPU و قابلیت سخت‌افزاری متفاوت‌اند.
• Lifecycle: برنامه مدام Background/Foreground می‌شود، قفل صفحه می‌بیند یا فرایندش در فشار حافظه از بین می‌رود.
• شبکهٔ ناپایدار: Offline، Latency، Packet loss، تغییر Wi‑Fi/Cellular و پاسخ دیرهنگام عادی‌اند.
• تعامل با Platform: Permission، Notification، Deep link، Back navigation، Share و Keyboard روی نتیجه اثر دارند.
• منابع محدود: Startup، Frame rendering، Memory، Battery و Data usage برای کاربر محسوس‌اند.
• Update و Distribution: Migration از نسخهٔ قبلی و قواعد Store بخشی از Release هستند.
• حریم خصوصی: دستگاه داده را محلی نگه می‌دارد و SDKهای ثالث ممکن است داده جمع کنند.
• زمینهٔ استفاده: نور، حرکت، یک‌دستی، متن بزرگ، Screen reader و وقفه‌های بیرونی تجربه را تغییر می‌دهند.

راهنمای رسمی کیفیت Android مواردی مانند Background/Foreground، Sleep/Resume، Lock/Resume، تغییر Orientation و Fold، Navigation، Startup، Rendering و ANR را در خط مبنا قرار می‌دهد؛ این‌ها «لبه‌های عجیب» نیستند، بخشی از رفتار عادی موبایل‌اند.

چطور ماتریس Device و OS بسازیم؟

هیچ تیمی نمی‌تواند همهٔ ترکیب‌ها را تست کند. انتخاب باید از داده و ریسک بیاید، نه مدل گوشی اعضای تیم. منابع تصمیم:

• نسخه‌ها و مدل‌های پشتیبانی‌شده در Product policy؛
• Telemetry کاربران فعال و درآمد/ریسک هر Segment؛
• کمترین و جدیدترین نسخهٔ OS پشتیبانی‌شده؛
• دستگاه‌های پرتکرار در Crash/ANR/Support؛
• ردهٔ کم‌منبع، میان‌رده و Reference؛
• اندازهٔ Compact، Expanded، Tablet/Foldable در صورت پشتیبانی؛
• ویژگی خاص مانند Biometric، NFC، Camera یا Dual SIM؛
• Locale فارسی/انگلیسی، RTL/LTR، Font scale و Theme؛
• نوع نصب: Store، Enterprise، Sideload یا مسیر داخلی مجاز.

ماتریس کوچک ولی قابل‌دفاع

Segment	هدف	پوشش نمونه
Android کم‌منبع	Memory، Startup و Background limits	یک دستگاه واقعی رایج با پایین‌ترین OS پشتیبانی‌شده
Android مرجع	جدیدترین رفتار Platform	Emulator در CI + دستگاه واقعی پیش از Release
Android سازندهٔ پرتکرار	تفاوت OEM و Permission/Power policy	دستگاه واقعی مبتنی بر Telemetry
Window بزرگ	Resize، Rotation و Layout	Tablet/Foldable مجازی و یک نمونهٔ واقعی در صورت اهمیت
iOS پایین‌ترین نسخه	Compatibility و Performance	دستگاه واقعی تحت سیاست پشتیبانی
iOS جدید	رفتار SDK/OS جدید	Simulator سریع + دستگاه واقعی Release

این جدول نسخهٔ جهانی نیست. اگر محصول فقط Android است، ردیف‌های iOS حذف می‌شوند؛ اگر کاربران Tablet ناچیزند ولی قرارداد آن را الزام می‌کند، همچنان پوشش می‌گیرد. ماتریس باید با تغییر Telemetry و سیاست پشتیبانی بازبینی شود.

Cross-product را هوشمند کم کنید

لازم نیست هر Test Case روی هر دستگاه، شبکه و Locale اجرا شود. جریان‌های کارکردی اصلی را روی یک پیکربندی مرجع عمیق اجرا کنید؛ سپس زیرمجموعهٔ سازگاری، Layout، Lifecycle و Performance را روی Segmentهای دیگر پخش کنید. برای تعامل چند عامل می‌توانید از Pairwise کمک بگیرید، اما ترکیب‌های پرریسک مانند «دستگاه کم‌حافظه × شبکه ضعیف × پرداخت» را به‌صورت Seed اجباری نگه دارید.

دستگاه واقعی، Emulator یا Simulator؟

Android اصطلاح Emulator و Apple اصطلاح Simulator را برای ابزارهای رسمی خود به‌کار می‌برند. تعریف‌های عمومی «یکی فقط نرم‌افزار و دیگری سخت‌افزار را تقلید می‌کند» همیشه برای تصمیم تست دقیق نیستند؛ Fidelity هر قابلیت را باید در همان ابزار و سناریو بررسی کرد.

گزینه	مزیت	محدودیت	کاربرد مناسب
Emulator/Simulator محلی	سریع، قابل Reset و پیکربندی‌پذیر	سخت‌افزار، Battery، OEM و برخی Performanceها نماینده نیستند	توسعه، CI، OS/Screen matrix و تست‌های پرتکرار
دستگاه واقعی داخلی	حس لمس، Camera، Sensor، Memory و Network واقعی	تعداد محدود و نگهداری دشوارتر	Exploration، Release، Performance و ریسک‌های سخت‌افزاری
Device farm	دسترسی به مدل‌ها و OSهای متنوع	هزینه، صف، دسترسی حساب/شبکه و Debug محدود	Compatibility و Regression توزیع‌شده
Beta واقعی	زمینهٔ استفاده و شبکهٔ واقعی	کنترل کمتر و ریسک داده/کاربر	اعتبارسنجی محدود با گروه و Build کنترل‌شده

مستندات Android توصیه می‌کند پیش از انتشار روی دستگاه واقعی نیز تست انجام شود و از Emulator برای تنوع API level و اندازهٔ صفحه استفاده شود. Device farm جای Strategy را نمی‌گیرد؛ باید قابلیت دسترسی، پرداخت، Data residency، محدودیت شبکه و مسیر جایگزین داخلی را برای تیم ایرانی از پیش آزمایش کنید.

لایه‌های تست موبایل؛ هر ریسک در ارزان‌ترین سطح مناسب

راهبرد رسمی Android نمونه‌ای پنج‌لایه از Unit تا Release Candidate ارائه می‌کند. نام لایه‌ها می‌تواند در تیم شما فرق کند؛ مهم این است که هدف، Fidelity و محل اجرا روشن باشد.

Unit و Logic test

قواعد قیمت، Validation، State reducer، Formatter تاریخ/مبلغ و تصمیم‌های Permission را بدون دستگاه سریع تست کنید. وابستگی به Clock، Network و Storage باید قابل‌جایگزینی باشد.

Component و Screenshot test

یک View/Screen/Component را با Stateهای مشخص می‌سنجد: Loading، Empty، Error، Long text، RTL، Dark mode و Font scale. Screenshot به‌تنهایی رفتار Screen reader یا Touch را اثبات نمی‌کند.

Feature test

تعامل چند Component در یک قابلیت مانند Login یا Cart، با Backend ساختگی یا Staging کنترل‌شده. این لایه می‌تواند روی Host، Emulator یا دستگاه اجرا شود.

Application test

کل باینری Debuggable را در جریان‌هایی مانند ثبت سفارش، Deep link یا Resume بررسی می‌کند. Test hook مجاز است، اما تفاوت با Release باید معلوم باشد.

Release Candidate test

باینری Minified/Signed نزدیک Production را روی دستگاه و محیط نماینده می‌سنجد: Critical journey، Startup، Crash، Permission، Upgrade و Store metadata. حساب عمومی واقعی یا Backend بدون حفاظ نباید برای تست پرخطر مصرف شود.

بخش عمدهٔ قواعد باید در لایه‌های سریع‌تر پوشش بگیرد و تعداد محدودی از سفرهای ارزشمند در UI/Device باقی بماند. این تصمیم با اصول اتوماسیون تست هم‌راستاست.

چک‌لیست تست کارکردی موبایل

نصب، Update و حذف

• Fresh install و First launch؛
• Update از نسخهٔ جاری Production و نسخه‌های پشتیبانی‌شدهٔ مهم؛
• Migration دیتابیس، Cache، Preference و Credential؛
• حفظ یا خروج امن نشست پس از Update طبق سیاست؛
• کمبود Storage یا قطع فرایند Update در سناریوی مجاز؛
• Clear data، Reinstall و Uninstall با اثر سروری مورد انتظار؛
• نبود Debug menu، تست‌اکانت و Endpoint آزمایشی در Release.

Lifecycle و State restoration

• Background و Foreground در هر مرحلهٔ حساس؛
• قفل/بازکردن صفحه و Sleep/Resume؛
• Process death و بازسازی Screen؛
• Rotation، Resize، Multi-window و Fold/Unfold در صورت پشتیبانی؛
• بازگشت از Camera، Browser، بانک یا اپ ثالث؛
• ورود Notification یا تماس هنگام فرم و پرداخت؛
• تغییر Timezone/Clock با سیاست معتبر.

Oracle باید بگوید کدام State حفظ، کدام دوباره بارگیری و کدام برای امنیت حذف می‌شود. حفظ بی‌قید فرم رمز یا پرداخت «تجربه بهتر» نیست.

Permission و قابلیت‌های Platform

• اجازه در اولین درخواست، Deny، Deny دائمی و Revocation از Settings؛
• درخواست Permission فقط هنگام نیاز و با توضیح قابل‌فهم؛
• Location تقریبی/دقیق و دسترسی Background در صورت کاربرد؛
• Camera، Microphone، Photo picker و Notification؛
• Clipboard، Share، Screenshot و App switcher برای دادهٔ حساس؛
• Biometric با Fallback و تغییر Enrollment؛
• Deep link معتبر، نامعتبر، Universal/App link و مسیر بدون Login.

Network و Sync

• Offline هنگام شروع و وسط عملیات؛
• Latency، Timeout، Packet loss و پاسخ ناقص؛
• تغییر Wi‑Fi به Cellular و برعکس؛
• Retry دستی/خودکار بدون اثر تکراری؛
• Queue محلی، Conflict و Sync پس از بازگشت؛
• Cache قدیمی و سیاست Refresh؛
• پاسخ ۴xx/۵xx، Maintenance و Session expiration؛
• مصرف داده و دانلود روی شبکهٔ محدود.

قرارداد و رفتار Backend باید جداگانه با تست API پوشش داده شود؛ تست UI موبایل نباید تنها محل کشف خطای API باشد.

Notification، Deep link و Navigation

• Notification در Foreground، Background و App terminated؛
• Tap روی پیام منقضی یا منبع حذف‌شده؛
• چند Notification و ترتیب دریافت؛
• Back gesture/button، Navigation stack و بازگشت از لینک؛
• Deep link با ورودی دستکاری‌شده و نقش فاقد مجوز؛
• عدم نمایش دادهٔ حساس در Lock screen طبق سیاست.

Performance موبایل را چگونه بسنجیم؟

بار هم‌زمان کاربران عمدتاً ریسک Backend است؛ روی Client باید پاسخ‌گویی، منابع و تجربهٔ دستگاه سنجیده شود. دو حوزه به هم مرتبط‌اند، اما یک Benchmark UI جای Load test سرور نیست.

• Startup: Cold، Warm و حالت پس از Update؛
• Rendering: Frame time، Jank و Scroll در محتوای واقعی؛
• Responsiveness: ANR در Android، Hang و Main-thread block؛
• Memory: رشد، Leak، Peak و رفتار زیر Memory pressure؛
• CPU/GPU: جریان‌های پرمصرف و پس‌زمینه؛
• Battery: Wakeup، Location، Timer و Background work؛
• Network: تعداد Request، Payload، Retry و Cache؛
• Storage: اندازهٔ نصب، Cache growth و Migration.

Threshold را از SLO محصول، راهنمای Platform و Baseline دستگاه‌های هدف بگیرید؛ عدد جهانی برای همهٔ اپ‌ها نسازید. Release build را بسنجید، چون Debug، Logging و Minification رفتار را تغییر می‌دهند. راهنمای تست عملکرد مدل اندازه‌گیری و Percentile را برای Backend تکمیل می‌کند.

امنیت و حریم خصوصی اپ موبایل

اسکن عمومی وب برای Mobile کافی نیست. OWASP MASVS گروه‌های کنترل Storage، Cryptography، Authentication، Network، Platform، Code، Resilience و Privacy را پوشش می‌دهد و MASTG روش‌های آزمون را تکمیل می‌کند.

• Token و دادهٔ حساس در Log، Backup، Clipboard یا Storage ناامن نماند.
• Authorization در Server اجرا شود؛ مخفی‌کردن دکمه کنترل دسترسی نیست.
• TLS و Trust handling با سیاست Platform و مدل تهدید سنجیده شود.
• Deep link، Intent/URL scheme و IPC ورودی غیرقابل‌اعتماد محسوب شوند.
• Permission و SDK ثالث فقط دادهٔ لازم را جمع کنند.
• Release فاقد Debug flag، Endpoint تست و Secret hard-coded باشد.
• Screenshot، App switcher و Notification برای صفحهٔ حساس ارزیابی شوند.
• Reverse engineering و Tamper resistance بر اساس ریسک، نه وعدهٔ «غیرقابل‌هک»، طراحی شوند.

آزمون امنیتی باید مجوز، دامنه و شرایط توقف داشته باشد. مقالهٔ تست امنیت نرم‌افزار قواعد درگیری، گزارش و Retest را توضیح می‌دهد.

کاربردپذیری، دسترس‌پذیری و فارسی/RTL

تعامل و Context

• هدف‌های لمسی، فاصله و Gesture با یک دست؛
• Keyboard مناسب، Focus، Autofill و خطای فرم؛
• نور/Contrast، Dark mode و Reduce motion؛
• Font scale بزرگ بدون قطع متن یا پنهان‌شدن عمل اصلی؛
• Screen reader، Voice control/Switch access و ترتیب Focus؛
• Orientation و Window size بدون ازدست‌رفتن قابلیت؛
• پیام خطای قابل‌اقدام و Recovery روشن.

تست کاربردپذیری فقط نظر تستر نیست؛ وظیفه، کاربر هدف و معیار دارد. برای طراحی مطالعه و تحلیل Completion، Error و Observation به راهنمای Usability Testing مراجعه کنید.

سناریوهای فارسی و ایران

• چیدمان RTL و محتوای ترکیبی فارسی/لاتین مانند کد رهگیری؛
• حروف «ی/ی» و «ک/ک»، نیم‌فاصله و Normalization جست‌وجو؛
• عدد فارسی/لاتین در ورودی، OTP و مبلغ؛
• ریال/تومان با Label و محاسبهٔ بدون ابهام؛
• تاریخ جلالی/میلادی، UTC و منطقهٔ زمانی؛
• شماره همراه داخلی/بین‌المللی با دادهٔ آزمایشی غیرقابل‌مسیریابی؛
• نام و آدرس بلند، چندخطی و کاراکترهای ترکیبی؛
• Font فارسی روی دستگاه‌های کم‌منبع و نسخه‌های پشتیبانی‌شده؛
• بازگشت از درگاه/بانک Sandbox با Deep link و Process death.

OTP، شماره تماس و پرداخت باید از Sink و Sandbox آزمایشی استفاده کنند. مدیریت این داده‌ها در راهنمای مدیریت داده تست با جزئیات پوشش داده شده است.

نمونهٔ عملی: اپ خرید با پرداخت بیرونی

جریان: کاربر وارد می‌شود، سبد را می‌سازد، آدرس و کوپن می‌دهد، به درگاه Sandbox می‌رود و با Deep link برمی‌گردد. یک Test pack ریسک‌محور:

ریسک	سناریو	پیکربندی	Oracle
پرداخت دوگانه	Double tap و بازگشت دوباره از Deep link	Android/iOS مرجع + Sandbox	یک Order، یک اثر مالی، پاسخ Idempotent
از دست‌رفتن State	Process death در صفحهٔ درگاه	دستگاه کم‌حافظه	بازیابی امن از Server، بدون حدس موفقیت
شبکهٔ نامطمئن	Timeout سپس پاسخ دیرهنگام	Network profile ضعیف	State نامشخص، Poll/Retry امن، پیام قابل‌اقدام
RTL	آدرس و کد رهگیری فارسی/لاتین	fa-IR + Font بزرگ	ترتیب و خوانایی درست، داده بدون تغییر
مجوز	Location رد و از Settings باطل شود	OS پایین/جدید پشتیبانی‌شده	Fallback دستی، بدون Loop درخواست
Update	ارتقا از نسخهٔ جاری با سبد موجود	Release build واقعی	Migration موفق و State سازگار

برای هر شکست، Build، OS، مدل، Locale، Network profile، حساب آزمایشی، Timestamp و Trace ID ثبت شود. ویدئو کمک می‌کند، اما Log و State سرور را جایگزین نمی‌کند.

فرآیند گام‌به‌گام طراحی استراتژی موبایل

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

پلتفرم، OS، Form factor، منطقه، Locale، نیازهای دسترس‌پذیری و روش توزیع را ثبت کنید. Product policy باید حداقل OS و دستگاه‌های خارج از پشتیبانی را روشن کند.

۲. Journey و ریسک را مدل کنید

ورود، جست‌وجو، سفارش، پرداخت، اعلان و بازیابی را با State و وابستگی رسم کنید. Crash در Splash با خطای فاصلهٔ یک آیکن اولویت یکسان ندارد.

۳. ماتریس پوشش را بسازید

Device/OS × Screen × Locale × Network × Permission × App state را بسازید، سپس با Telemetry، ریسک و Pairwise کاهش دهید. ترکیب‌های حیاتی را Seed کنید.

۴. لایه و محیط هر تست را تعیین کنید

قاعده در Unit، Screen state در Component، Feature در محیط کنترل‌شده، Journey محدود در Application و Critical release در باینری Release. سرویس ثالث باید Sandbox یا Simulator با قرارداد معلوم داشته باشد.

۵. داده و قابلیت مشاهده را آماده کنید

حساب‌های نقش‌محور، Dataset مصنوعی، Reset، OTP sink و Payment sandbox بسازید. Crash، ANR/Hang، Log، Metric و Trace را به Build و Session وصل کنید.

۶. اجرای دستی و خودکار را ترکیب کنید

Regression پایدار و ماتریس تکراری را خودکار کنید؛ Gesture، Visual، Accessibility، Context واقعی و ریسک ناشناخته را با Session اکتشافی بپوشانید. راهنمای تست اکتشافی برای Charterهای Lifecycle/Network مفید است.

۷. Release Candidate و Beta را بسنجید

Signed/Minified build، Upgrade، Store metadata، Permission disclosure، Privacy، Crash و Journeyهای حیاتی را بررسی کنید. TestFlight برای توزیع Beta و دریافت Feedback/Crash در اکوسیستم Apple است؛ کانال معادل Android را بر اساس روش توزیع و دسترسی تیم انتخاب کنید.

۸. Rollout و بازخورد پس از انتشار را ببندید

در صورت پشتیبانی کانال، انتشار مرحله‌ای، Crash/ANR/Hang، Startup، Review و Ticket را پایش کنید. Threshold و Rollback owner پیش از انتشار تعیین شوند؛ مشاهدهٔ Production جای تست پیش از انتشار نیست، حلقهٔ تکمیل‌کننده است.

اتوماسیون موبایل پایدار

• Selector بر پایهٔ Accessibility identifier/Test tag پایدار؛ نه مختصات و متن ترجمه‌پذیر.
• انتظار بر اساس State/Idling؛ نه Sleep ثابت.
• Factory و Namespace مستقل برای هر Run؛ نه حساب مشترک.
• Clock، Network و Push قابل‌کنترل در لایهٔ مناسب.
• Setup از API/Fixture سریع و UI فقط برای رفتار UI.
• تعداد محدود Journey روی دستگاه‌های بیشتر؛ Suite کامل روی دستگاه مرجع.
• Screenshot، Video، Device log، Network trace و App state در شکست.
• Retry فقط با دسته‌بندی خطای زیرساخت؛ شکست تست نباید بی‌صدا سبز شود.
• Quarantine موقت با مالک، دلیل و مهلت؛ نه قبرستان Flaky test.
• Release build test برای تفاوت Minification، Signing و Feature flag.

AndroidX Test/Espresso/UI Automator، XCTest/XCUITest و Appium گزینه‌هایی با مرز متفاوت‌اند. انتخاب ابزار باید از Stack، مهارت، دسترسی Device، Diagnostic و هزینهٔ نگهداری بیاید. معماری Laneها را می‌توان با Continuous Testing در CI/CD همسو کرد.

چک‌لیست Store و Release readiness

• نسخه، Signing، Entitlement/Permission و Environment صحیح‌اند.
• Debug library، Test endpoint، Account و Menu در Release نیست.
• Fresh install و Upgrade از نسخهٔ جاری تست شده‌اند.
• Latest public OS و پایین‌ترین نسخهٔ پشتیبانی‌شده پوشش دارند.
• Critical journey روی حداقل یک دستگاه واقعی هر پلتفرم اجرا شده است.
• Privacy/Data safety label و رفتار واقعی SDKها هم‌خوان‌اند.
• Permissionها حداقلی، زمینه‌مند و دارای Fallback هستند.
• Deep link، Notification و Return from external app امن‌اند.
• Crash/ANR/Hang و Performance baseline معیار خروج دارند.
• Accessibility، RTL، Font scale، Theme و محتوای Store بررسی شده‌اند.
• Demo account/Review note در صورت نیاز معتبر و بدون دادهٔ واقعی است.
• Store policy فعلی درست پیش از Submission دوباره بررسی شده است.
• Rollout، Monitoring، Support و Rollback owner مشخص‌اند.

سیاست‌های Store تغییر می‌کنند؛ برای iOS مرجع جاری App Review Guidelines و برای Android صفحات رسمی Google Play/Android Developers هستند. تاریخ و نسخهٔ سیاست بررسی‌شده را در Release checklist بنویسید.

متریک‌های مفید کیفیت موبایل

متریک	پرسش	هشدار
Crash-free sessions/users	پایداری برای چه Segmentی افت کرده؟	Aggregate می‌تواند OS/Device پرخطر را پنهان کند.
ANR/Hang rate	کجا UI پاسخ‌گو نیست؟	Crash نبودن به معنی تجربهٔ سالم نیست.
Startup percentile	Cold/Warm روی دستگاه هدف چقدر است؟	Average و Debug build گمراه می‌کنند.
Jank/slow frames	کدام Journey روان نیست؟	FPS آزمایشگاه جای حس کاربر واقعی را نمی‌گیرد.
Battery/network delta	این Release مصرف را بدتر کرده؟	شرایط و Baseline باید ثابت باشند.
Permission denial recovery	کاربر بدون مجوز می‌تواند ادامه دهد؟	صرف نرخ Grant هدف کیفیت نیست.
Defect by Device/OS	ماتریس بعدی کجا عمیق‌تر شود؟	تعداد خام بدون تعداد کاربر و اثر کافی نیست.

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

• تست فقط روی گوشی تیم: نمونه با کاربران و ریسک هم‌خوان نیست.
• اجرای همه‌چیز روی همه‌چیز: هزینه بالا و سیگنال تکراری بدون اولویت.
• جایگزینی کامل دستگاه واقعی با Emulator: OEM، منابع و Context از دست می‌روند.
• تست فقط Happy path آنلاین: Lifecycle، Retry و Sync شکست می‌خورند.
• مخلوط‌کردن Load سرور با Client performance: علت و ابزار اشتباه انتخاب می‌شود.
• اعتماد به UI سبز: داده، Queue و اثر مالی بررسی نمی‌شوند.
• Sleep و مختصات در اتوماسیون: Suite کند و Flaky می‌شود.
• فارسی‌سازی در پایان: RTL، Font و ورودی ترکیبی دیر آشکار می‌شوند.
• امنیت فقط با اسکن: Storage، Platform interaction و SDK ثالث پوشش ناقص می‌مانند.
• نادیده‌گرفتن Update: کاربر واقعی از Fresh install شروع نمی‌کند.
• Submission بدون بازبینی سیاست جاری: کیفیت باینری با آمادگی Store یکسان نیست.

چک‌لیست نهایی تست موبایل

• پلتفرم، حداقل OS، نوع اپ و کانال توزیع روشن‌اند.
• ماتریس Device/OS/Screen/Locale/Network بر داده و ریسک استوار است.
• دستگاه واقعی، Virtual و Device farm نقش مشخص دارند.
• Unit تا Release Candidate هدف و مالک دارند.
• Install/Update/Migration/Lifecycle/Permission پوشش گرفته‌اند.
• Offline/Timeout/Switch network/Retry/Sync آزمون شده‌اند.
• Performance کلاینت از Load Backend جدا ولی مرتبط تحلیل شده است.
• MASVS/MASTG متناسب با ریسک امنیت استفاده شده‌اند.
• RTL، فارسی، دسترس‌پذیری و Context واقعی پوشش دارند.
• داده، Sandbox، OTP و حساب‌ها آزمایشی و قابل Reset هستند.
• Release build، Store checklist، Rollout و Monitoring شاهد دارند.

سوالات متداول تست اپلیکیشن موبایل

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

ابتدا پلتفرم و کاربران واقعی، جریان‌های حیاتی، حداقل OS و ریسک‌ها را مشخص کنید. سپس یک دستگاه مرجع، یک Device کم‌منبع، جدیدترین OS و پایین‌ترین OS پشتیبانی‌شده را انتخاب و Smoke، Lifecycle، Network و Update را کنار تست‌های کارکردی قرار دهید.

آیا Emulator یا Simulator برای تست کافی است؟

برای بازخورد سریع، نسخه‌های OS و اندازه‌های صفحه بسیار ارزشمند است، اما پیش از Release به دستگاه واقعی برای Performance، منابع، OEM، Sensor، لمس و شبکه نیاز دارید. میزان Device واقعی را ریسک قابلیت تعیین می‌کند.

چند دستگاه برای تست اپ لازم است؟

عدد جهانی وجود ندارد. ماتریس را از Telemetry، OS پشتیبانی‌شده، ردهٔ سخت‌افزار، Form factor و تاریخچهٔ نقص بسازید. همهٔ تست‌ها را روی همهٔ دستگاه‌ها اجرا نکنید؛ زیرمجموعهٔ هدفمند بسازید.

تفاوت تست کارایی موبایل و Load Testing چیست؟

Mobile client performance روی Startup، Rendering، Memory، CPU، Battery و Network usage دستگاه تمرکز دارد. Load Testing ظرفیت Backend را زیر Arrival/Concurrency می‌سنجد. یک Journey می‌تواند هر دو را در آزمایش‌های جدا و با Correlation مشترک نیاز داشته باشد.

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

قواعد قطعی در Unit/Component، Contractهای API، Smoke و چند Journey حیاتیِ پایدار گزینه‌های خوب‌اند. Visual، کاربردپذیری، Context واقعی و Exploration را کاملاً به اسکریپت تبدیل نکنید. ارزش بازخورد و هزینهٔ نگهداری معیار انتخاب است.

منابع و یادداشت بازبینی

راهبرد لایه‌ای و دستگاه با مستندات فعلی Android Developers، Beta/Review با منابع رسمی Apple و امنیت با OWASP MASVS/MASTG تطبیق داده شده است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. نسخهٔ OS، قواعد Target SDK و سیاست Store متغیرند؛ مرجع جاری باید در هر Release دوباره بررسی شود.

جمع‌بندی: استراتژی خوب موبایل مسابقهٔ تعداد دستگاه و Test Case نیست. ریسک را به Segment واقعی وصل کنید، قواعد را در لایهٔ ارزان پوشش دهید، Lifecycle و شبکه را مثل رفتار عادی ببینید، Release واقعی را روی دستگاه واقعی بسنجید و بازخورد Production را دوباره به ماتریس برگردانید.