اختبار وجودة ألعاب الموبايل
قائمة اختبار لعبة الموبايل قبل الإطلاق
بوابة Release عملية تربط الأجهزة والأعطال والأداء والمتاجر بأدلة قبول قابلة للمراجعة.
إعداد ومراجعة: فريق Upload For Software. آخر مراجعة تحريرية وفنية: 3 سبتمبر 2026. معايير القبول تُخصص بحسب اللعبة والأجهزة والمنصات؛ لا نضمن قبول المتجر أو أداءً موحدًا على كل جهاز.
الإجابة المختصرة: لا تصبح لعبة الموبايل جاهزة للإطلاق لأنها «تعمل على هاتف الفريق». الجاهزية تعني أن نسخة محددة اجتازت بوابة قبول موثقة: حلقة اللعب مكتملة، لا توجد أعطال مانعة، الأداء مستقر على الأجهزة المستهدفة، الاستعادة بعد المقاطعة تعمل، والمشتريات والإعلانات والحفظ ومتطلبات المتجر اختُبرت بحسب نطاق المشروع.
هذه الـChecklist موجهة لصاحب المشروع أو مدير المنتج الذي يريد استلام دليل قابل للمراجعة قبل الموافقة على النشر. أما التفاصيل التجارية للتنفيذ فتوجد في صفحة تصميم وتطوير ألعاب الموبايل. الهدف هنا ليس الوعد بل تحويل كلمة «جاهزة» إلى اختبارات ونتائج ومسؤوليات واضحة.
ابدأ بتعريف نسخة الاختبار وبوابة الإطلاق
ثبّت رقم الـbuild، بيئة الخادم، قائمة الأجهزة، إعدادات الجودة، حسابات الاختبار ووقت الجولة. إذا تغيرت النسخة أثناء الاختبار تصبح النتائج القديمة مرجعًا لنسخة أخرى. أنشئ سجلًا واحدًا لكل نتيجة يتضمن الجهاز ونظام التشغيل وخطوات التكرار والنتيجة المتوقعة والفعلية وصورة أو فيديو وسجل الأعطال عند الحاجة.
لا تجعل شرط القبول «صفر أخطاء»؛ فهذا وصف غير قابل للإدارة. صنّف العيوب حسب أثرها: مانع للإطلاق، مرتفع، متوسط، منخفض. العطل الذي يمنع بدء اللعب أو يفقد التقدم أو يخصم مبلغًا دون منح العنصر يوقف الإصدار. العيب البصري الصغير قد يؤجل إذا كان موثقًا ولا يحجب الاستخدام.
ابنِ مصفوفة أجهزة تمثل الجمهور
اختبار أحدث هاتف فقط يخفي مشكلات الذاكرة والحرارة وأبعاد الشاشة. اختَر أجهزة حقيقية تمثل الحد الأدنى المقبول، جهازًا متوسطًا، وجهازًا حديثًا، مع أحجام شاشة ونِسب عرض وإصدارات نظام مختلفة. عند استهداف Android وiOS معًا، راجع دليل اختيار منصات لعبة الموبايل لأن مضاعفة المنصات توسع مصفوفة الاختبار والمتجر.
- سجّل طراز الجهاز وإصدار النظام ومساحة التخزين المتاحة.
- اختبر تثبيتًا جديدًا وترقية من نسخة سابقة عندما يوجد مستخدمون حاليون.
- جرّب أصغر شاشة وأطول نسبة عرض للتأكد من الأزرار والنصوص ومناطق اللمس.
- شغّل جلسة طويلة على الجهاز الأضعف لاكتشاف تراكم الذاكرة والحرارة.
اختبر حلقة اللعب والتحكم والكاميرا
نفّذ المسار الأساسي من أول فتح حتى إنهاء جولة والحصول على المكافأة والعودة للقائمة. اختبر اللمس السريع والمتزامن والسحب قرب حواف الشاشة، واتجاه الجهاز إذا كان مدعومًا. راقب هل تمنع الواجهة رؤية اللعب، وهل تظل الكاميرا قابلة للسيطرة عند التصادم أو الانتقال بين المساحات.
لا تكتفِ بالمسار المثالي. جرّب خسارة الجولة، إعادة المحاولة، إيقاف اللعبة مؤقتًا، مغادرة شاشة أثناء تحميلها، والضغط المتكرر على زر الشراء أو بدء المرحلة. الحالات غير المرتبة هي المكان الذي تظهر فيه أعطال الحالة المزدوجة وتكرار المكافآت.
الاستقرار: الأعطال والتجمّد والاستعادة
راقب الأعطال، حالات ANR على Android، التجمّد، وإغلاق النظام للتطبيق عند ضغط الذاكرة. توصي Android Developers بمراجعة مؤشرات الاستقرار والأداء والبطارية والمشكلات المتعلقة بالأذونات عبر Android vitals. اربط كل عطل بنسخة وجهاز وخطوات تكرار بدل تجميعه في ملاحظة عامة.
- أرسل اللعبة للخلفية ثم عد إليها من القتال والقائمة وشاشة الشراء.
- اقفل الشاشة وافتحها، واستقبل مكالمة أو إشعارًا أثناء اللعب.
- اختبر نفاد الذاكرة أو إغلاق التطبيق ثم تحقق من نقطة الاستعادة.
- كرر الدخول والخروج من المرحلة وابحث عن تحميل مزدوج أو صوت يستمر في الخلفية.
الأداء: قِس الثبات لا المتوسط وحده
حدد هدف الأداء المناسب لكل فئة جهاز ثم قِس ثبات الإطارات والتقطيع ووقت بدء اللعب والانتقال بين المشاهد واستهلاك الذاكرة. متوسط معدل الإطارات قد يبدو جيدًا رغم وجود قفزات واضحة؛ لذلك راقب frame pacing وأسوأ اللحظات في مشهد الضغط، كما توضح إرشادات Android الرسمية.
شغّل Profiling على الجهاز المستهدف، لا داخل المحرر فقط. اختبر أكبر عدد من الأعداء، أثقل مؤثرات، أكثر واجهة ازدحامًا، وجلسة ممتدة. سجّل حرارة الجهاز واستهلاك البطارية بصورة مقارنة داخل نفس شروط الاختبار، ولا تنقل نتيجة جهاز واحد إلى كل السوق.
الشبكة والوضع غير المتصل والمقاطعات
بدّل بين Wi‑Fi وبيانات الهاتف أثناء الجلسة، أوقف الشبكة في لحظة طلب، وأعدها بعد التأخير. يجب أن يعرف اللاعب ما حدث، وألا يعلق في شاشة تحميل بلا نهاية أو يفقد تقدمه. حدّد ما الذي يعمل Offline، وما الذي ينتظر إعادة الاتصال، وهل إعادة المحاولة آمنة ولا تكرر الجائزة أو الخصم.
اختبر زمنًا غير صحيح على الجهاز إذا كانت المكافآت مرتبطة بالوقت، وراجع سلوك الجلسة بعد انتهاء صلاحية تسجيل الدخول. إذا كانت اللعبة متعددة اللاعبين، اختبر الانقطاع والعودة ومغادرة لاعب ومزامنة النتيجة؛ كل حالة تحتاج نتيجة متوقعة مكتوبة.
الحفظ والحسابات والمشتريات والإعلانات
أنشئ حسابًا جديدًا، سجل الدخول والخروج، استعد الحساب، وجرّب اللعبة كضيف إذا كان ذلك مدعومًا. افحص الحفظ المحلي والسحابي والتعارض بين جهازين، ولا تعتمد على نجاح حفظ واحد. عند وجود مشتريات داخل التطبيق، اختبر النجاح والإلغاء والفشل والتأخير والاستعادة، وتأكد أن الخادم أو منطق اللعبة لا يمنح العنصر مرتين.
بالنسبة للإعلانات، اختبر عدم توفر إعلان، إغلاقه، فشل المكافأة، والتتابع بين الإعلان واللعبة. راجع أن الصوت والتركيز يعودان بعد الإعلان. افصل بيئات الاختبار عن الإنتاج، ولا تستخدم معاملات حقيقية عندما توفر المنصة حسابات Sandbox.
التحليلات والخصوصية والأذونات
تحقق أن أحداث التحليلات المهمة تُرسل مرة واحدة وبأسماء متفق عليها: بدء الجولة، نهايتها، التقدم، الخطأ، والشراء عند وجوده. لا يكفي ظهور الحدث؛ راجع خصائصه والبيئة والنسخة. اطلب الأذونات وقت الحاجة وبشرح واضح، واختبر الرفض ثم تفعيل الإذن لاحقًا من إعدادات الجهاز.
راجع شاشات الموافقة وروابط الخصوصية وحذف الحساب إذا كان مطلوبًا في نطاق المنتج. هذه القائمة ليست بديلًا عن مراجعة السياسات الحالية لكل متجر، لكنها تمنع وصول Build وظيفي إلى المراجعة ببيانات ناقصة.
جاهزية صفحة المتجر والمراجعة
تطلب إرشادات Apple اختبار الأعطال والأخطاء، اكتمال بيانات التطبيق، توفير وصول كامل للمراجعة وعدم ترك محتوى مؤقت. طبّق المبدأ نفسه عمليًا على كل متجر: اسم وإصدار وأيقونة ولقطات ووصف وتصنيف عمري وروابط دعم وخصوصية صحيحة، وحساب مراجعة أو تعليمات خاصة إذا كان الوصول مقيدًا.
طابق ما تقوله الصور والوصف مع النسخة الفعلية. افحص الروابط خارج اللعبة، وقم بتجربة تنزيل الحزمة من مسار قريب من المتجر إن أمكن، لا من جهاز التطوير فقط. لمتطلبات Android المتخصصة راجع متطلبات إطلاق لعبة Android.
بوابة القبول: متى نوقف الإطلاق؟
| المحور | الدليل المطلوب | حالة توقف الإطلاق |
|---|---|---|
| حلقة اللعب | فيديو لمسار كامل ونتائج الحالات الحرجة | تعذر البدء أو الإنهاء أو استلام المكافأة |
| الاستقرار | تقارير الأجهزة وسجلات الأعطال | Crash أو تجمّد قابل للتكرار في مسار أساسي |
| الأداء | قياس على الحد الأدنى ومشهد الضغط | تقطيع أو حرارة أو ذاكرة تمنع اللعب المقبول |
| الحفظ والدفع | نتائج نجاح وفشل واستعادة | فقد تقدم أو خصم خاطئ أو منح مزدوج |
| المتجر | Metadata وروابط وحساب مراجعة مكتمل | بيانات ناقصة أو وصول المراجع غير ممكن |
بعد إصلاح عيب مانع، لا تختبر موضعه فقط. نفّذ Regression على المسار الذي يمسه وعلى Smoke Test للنسخة كاملة، ثم ثبّت رقم Build جديدًا ووقّع قرار القبول باسم المسؤول والتاريخ.
Checklist قابلة للنسخ قبل النشر
- ثُبت رقم الـbuild والبيئة ومصفوفة الأجهزة والحسابات.
- اكتملت حلقة اللعب الأساسية والفوز والخسارة وإعادة المحاولة.
- اختُبرت المقاطعات والخلفية وقفل الشاشة واستعادة الحالة.
- لا توجد أعطال مانعة، وكل عيب متبقٍ مصنف وموثق.
- قيس الأداء والذاكرة والتحميل في مشهد ضغط وعلى جهاز الحد الأدنى.
- اختُبرت الشبكة الضعيفة والانقطاع وإعادة المحاولة دون تكرار العمليات.
- اختُبر الحفظ والحساب والمشتريات والإعلانات بحسب نطاق اللعبة.
- راجعت الأحداث التحليلية والأذونات والخصوصية.
- اكتملت مواد المتجر وروابط الدعم وحساب المراجعة.
- نُفذ Regression ثم Smoke Test على النسخة المرشحة نفسها.
- حُفظت الأدلة ووقّع صاحب القرار بوابة الإطلاق.
الخلاصة: الاختبار الجيد لا ينتج جملة «اللعبة تمام»، بل حزمة أدلة تحدد ما اختُبر، وعلى أي جهاز، وما الذي يمنع الإطلاق، ومن وافق على المخاطر المتبقية. أدخل هذه البوابة في الخطة الزمنية قبل موعد المتجر؛ دليل مدة تطوير لعبة الموبايل يوضح لماذا يحتاج الاختبار وقتًا مستقلًا.
هل يجب اختبار اللعبة على كل هاتف؟
لا يمكن تغطية كل هاتف. ابنِ مصفوفة تمثل الحد الأدنى والمتوسط والحديث وأحجام الشاشة وإصدارات النظام الأكثر أهمية لجمهورك، ثم وسّعها وفق تقارير الاستخدام والأعطال.
ما الفرق بين Smoke Test وRegression؟
الـSmoke Test يتأكد سريعًا أن المسارات الأساسية تعمل في النسخة، بينما Regression يعيد فحص المناطق التي قد تتأثر بالتغييرات والإصلاحات.
هل متوسط FPS يكفي للحكم على الأداء؟
لا. يجب مراجعة ثبات الإطارات والتقطيع والتحميل والذاكرة والحرارة على أجهزة حقيقية، لأن المتوسط قد يخفي لحظات سيئة واضحة للاعب.
متى يكون العطل مانعًا للإطلاق؟
عندما يمنع مسارًا أساسيًا، يسبب فقد تقدم أو معاملة مالية خاطئة، يعرّض البيانات للخطر، أو يجعل التجربة غير قابلة للاستخدام على جهاز مستهدف.