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

تیم آرادتیم مهندسی

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

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

پس هدف، پوشش کامل نیست. پوشش هوشمندانه است.

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

به‌جای فهرست بلند، سه دسته:

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

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

قدیمی‌ترین نسخهٔ سیستم‌عامل که پشتیبانی می‌کنید.

و یک تصمیم که باید صریح باشد: از چه نسخه‌ای پشتیبانی می‌کنید؟ هر نسخهٔ قدیمی‌تر، هزینهٔ تست و توسعه دارد. این را با داده تصمیم بگیرید — اگر دو درصد کاربرانتان روی نسخه‌ای هستند که نیمی از باگ‌ها را می‌سازد، پشتیبانی‌اش را قطع کنید.

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

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

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

تماس ورودی وسط کار. اپ به پس‌زمینه می‌رود و برمی‌گردد. وضعیت حفظ شده؟

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

چرخش صفحه.

تغییر مجوز از تنظیمات. کاربر دسترسی دوربین را داده بود و بعد از تنظیمات گرفته. اپ باید بی‌درنگ نیفتد.

باتری کم و حالت ذخیرهٔ انرژی. بعضی قابلیت‌ها در این حالت محدود می‌شوند.

فضای ذخیره‌سازی پر.

تغییر ساعت یا منطقهٔ زمانی دستگاه.

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

چه چیزی را خودکار کنیم

هرم واقع‌بینانه برای موبایل:

تست واحد — بیشترین حجم. منطق، محاسبات، تبدیل داده. سریع و ارزان و مستقل از دستگاه. اگر منطق را از رابط کاربری جدا نگه دارید، بخش بزرگی از اپ اینجا قابل تست است.

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

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

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

تست شبکه، که باید عمدی باشد

شبیه‌سازی شرایط واقعی، نه دفتر با وای‌فای:

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

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

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

  • چیدمان راست‌به‌چپ روی همهٔ صفحات.
  • متن بلند فارسی که ممکن است دکمه یا کارت را بشکند.
  • اعداد فارسی و لاتین در ورودی و نمایش.
  • تاریخ شمسی، به‌ویژه در مرز سال و اسفند.
  • شمارهٔ تلفن با فرمت‌های مختلف.
  • جست‌وجو با «ی» و «ک» عربی — کاربری که با صفحه‌کلید عربی تایپ می‌کند باید نتیجه بگیرد.

فهرست کامل دام‌هایش در وب فارسی — و تقریباً همه‌اش به موبایل هم منتقل می‌شود.

تست پیش از انتشار

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

نسخهٔ توسعه با نسخهٔ انتشار تفاوت دارد — بهینه‌سازی و مبهم‌سازی کد می‌تواند رفتار را عوض کند. باگ‌هایی هستند که فقط در نسخهٔ انتشار ظاهر می‌شوند.

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

انتشار تدریجی و پایش

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

انتشار مرحله‌ای، اگر بازار پشتیبانی می‌کند. اول درصد کوچکی از کاربران.

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

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

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

چک‌لیست پیش از انتشار

  • روی دستگاه مرجع ضعیف تست شده
  • مسیر به‌روزرسانی از نسخهٔ قبلی تست شده
  • نصب تازه تست شده
  • قطع شبکه وسط عملیات تست شده
  • بازگشت از پس‌زمینه پس از کشته شدن تست شده
  • چیدمان راست‌به‌چپ و متن بلند بررسی شده
  • نسخهٔ انتشار تست شده، نه نسخهٔ توسعه
  • گزارش خرابی فعال است
  • برنامهٔ بازگشت مشخص است

بند آخر روی موبایل معنای متفاوتی دارد: بازگشت واقعی وجود ندارد. نمی‌توانید نسخهٔ بد را از دستگاه کاربران بردارید. تنها گزینه‌تان انتشار سریع نسخهٔ اصلاحی است — که چند روز طول می‌کشد.

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

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

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