لا: لا يُعاد أبدًا
حدّث بحرية؛ إصدار جديد يُبقي عدّاد 14 يومًا يعمللا توجد قاعدة تقول إن إنشاء إصدار جديد يعيد ضبط عدّاد الاختبار المغلق (closed testing). شرط 14 يومًا يُقاس بالحفاظ على 12 مختبِرًا على الأقل وافقوا على المشاركة بشكل متواصل: لا علاقة له بإصدار التطبيق، أو version code، أو عدد الـ builds التي ترفعها.
عدد المختبِرين الذين وافقوا على المشاركة ينخفض دون 12.
إن خرج المختبِرون رسميًا من الاختبار وانخفضت دون الحد الأدنى، تنكسر السلسلة المتواصلة: لا لأنك حدّثت، بل لأنك انخفضت دون 12.
جواب سريع
لا: تحديث تطبيقك أثناء اختبار 14 يومًا المغلق لا يعيد ضبط العدّاد، فترفع إصدارات جديدة بقدر ما تحتاج. رفع build جديد (AAB) إلى مسار الاختبار المغلق الحالي لا يعيد الـ14 يومًا. العدّاد مربوط بالحفاظ على 12 مختبِرًا على الأقل وافقوا على المشاركة بشكل متواصل، لا بإصدار التطبيق أو version code أو مفتاح التوقيع. الشيء الوحيد الذي يكسر النافذة المتواصلة هو انخفاض عدد من وافقوا دون 12 أو خروجهم رسميًا من الاختبار. رفع التحديثات آمن، وجوجل تشجّعه فعليًا. PrimeTestLab (برايم تست لاب) تبقي 12 مختبِرًا حقيقيًا على الأقل موافقين بشكل متواصل، فيستمر عدّادك وأنت تنشر الإصلاحات.
هذا من أكثر مخاوف الاختبار المغلق شيوعًا: أنت في منتصف نافذة 14 يومًا، تكتشف خطأً، وتتجمد خوفًا من أن رفع إصلاح يمحو تقدمك ويجبرك على بدء الأسبوعين من جديد. لن يفعل. عدّاد 14 يومًا يراقب مختبِريك، لا إصداراتك. يفصل هذا الدليل ما يعيد ضبط مؤقت الاختبار المغلق عمّا لا يعيده، ويعطيك أداتين تفاعليتين لاختبار أي إجراء بنفسك، ويشرح لماذا تريد Google فعليًا رؤية تحديثاتك. محدّث حتى 30 يونيو 2026.
في هذا الدليل
هل يعيد تحديث تطبيقي ضبط عدّاد 14 يومًا للاختبار المغلق؟
لا. هذا أكثر مخاوف المطوّرين شيوعًا أثناء نافذة الاختبار، والجواب مطمئن: رفع حزمة تطبيق جديدة إلى مسار الاختبار المغلق الحالي لا يعيد شرط الاختبار المتواصل 14 يومًا.
عدّاد 14 يومًا مربوط بـمختبِريك، لا بـإصدارك. شرط Google يُقاس بما إذا حافظت على 12 مختبِرًا على الأقل وافقوا على المشاركة لآخر 14 يومًا متواصلة. رقم إصدار التطبيق، وكم مرة ترفع AAB جديدًا، وما تغيّره في ملاحظات الإصدار ليست جزءًا من ذلك المؤقت.
يُطرح هذا السؤال مرارًا في مجتمع مطوّري Google Play: هل إنشاء إصدار جديد للاختبار المغلق يعيد 14 يومًا، أم يعاد العدّاد عند تحديث التطبيق. بدل اقتباس ردود المنتديات حرفيًا دون تحقق مستقل، يعتمد هذا الدليل على وثائق Play Console Help الرسمية لدى Google، التي تعرّف الشرط فقط بمختبِرين وافقوا على المشاركة والوقت، لا برفع الإصدارات.
عبر 9,800+ تطبيقًا دعمناهم في هذه العملية، لم يُعد تحديث build روتيني على نفس المسار المغلق العدّاد بمفرده أبدًا. لست متأكدًا من إجراء معيّن؟ استخدم الفاحص أدناه: اختر ما أنت على وشك فعله فيخبرك فورًا إن كان يمس مؤقت 14 يومًا.
أي إجراء يقلقك؟
مبني على شرط Play Console المنشور لدى Google (مختبِرون وافقوا × أيام متواصلة) وتجربة مطوّرين شائعة. الخطران المُبلَّغان من المجتمع مُعلَّمان كذلك.
ما الذي يعيد ضبط مؤقت 14 يومًا فعليًا؟
أفضل فهم لنافذة 14 يومًا المتواصلة أنها فحص اتساق، لا عدّاد تقويم سلبي. تريد Google أن ترى أنك حافظت على 12 مختبِرًا على الأقل وافقوا على المشاركة بلا انقطاع. هناك فقط محفّزان مؤكدان يكسران تلك الاستمرارية:
عدد من وافقوا ينخفض دون 12
إن خرج مختبِر واحد وانخفضت إلى 11، قد تنكسر السلسلة المتواصلة وتبدأ أسبوعين كاملين من جديد. هذا السبب رقم واحد لفشل مطوّري DIY.
خروج المختبِرين رسميًا من الاختبار
يخرج المختبِر بفتح رابط الاختبار الويب واختيار المغادرة. هذا مختلف عن إزالة التثبيت، ولا يضر العدّاد إلا إن دفعك دون 12.
رفع إصدار جديد ليس في تلك القائمة. ولا إصلاح خطأ مطبعي في قائمة المتجر، ولا إرسال مختبِر لملاحظات، ولا تعطل تطبيقك على جهازه: الأخيرة هي جوهر الاختبار. المحاكي أدناه يجعل الفرق واضحًا: اضغط زر التحديث مرارًا ولا يتحرك شيء، لكن اخسر مختبِرين دون 12 فتنهار السلسلة.
ما لا يعيد ضبط العدّاد
رفع AAB جديد على نفس المسار
تعديل ملاحظات الإصدار أو قائمة المتجر
مختبِر يرسل ملاحظات
تعطل التطبيق على جهاز مختبِر
رفع version code أو اسم الإصدار
مختبِر يزيل التثبيت دون الخروج
كيف أرفع تحديثًا إلى اختبار مغلق؟
رفع تحديث هو نفس تدفق إصدارك الأول، مع فرق مهم: تنشئ الإصدار الجديد على نفس مسار الاختبار المغلق الذي وافق عليه المختبِرون. لا تبدأ اختبارًا جديدًا: تضيف buildًا إلى اختبار يعمل، ولهذا بالضبط يستمر عدّاد 14 يومًا. هاتان الخطوتان في Play Console.
أنشئ إصدارًا جديدًا على مسارك المغلق Testing > Closed testing > Manage track
افتح مسار الاختبار المغلق الذي كنت تشغّله، انقر Create new release، وارفع حزمة التطبيق المحدّثة (AAB). أضف ملاحظات إصدار قصيرة تصف التغيير، ثم احفظ. أبقِه على نفس المسار: ذلك ما يحافظ على نافذة 14 يومًا المتواصلة.
راجع الإصدار وابدأ الطرح Review release > Start roll-out
مرّ عبر Next وReview release، ثم ابدأ الطرح على مسارك المغلق (وانقر Send changes for review في Publishing overview إن طُلب). بمجرد أن يصبح الإصدار حيًا (تذكّر Google أن التغيير المنشور قد يستغرق عدة ساعات ليصل إلى المختبِرين)، تحدّث أجهزتهم تلقائيًا إلى الإصدار الجديد: بلا إعادة تثبيت وبلا موافقة ثانية.
هذا لا يعيد العدّاد أبدًا. لأنك تطرح على نفس المسار المغلق الذي وافق عليه المختبِرون، تستمر نافذة 14 يومًا المتواصلة تحت الإصدار الجديد. تضيف buildًا، لا تبدأ اختبارًا جديدًا: وهذا كل جواب السؤال الذي بُني عليه هذا الدليل.
ما الفرق بين المختبِرين المدعوّين ومن وافقوا على المشاركة؟
هذا التمييز يعثّر ناشرين أكثر من أي شيء آخر، وهو مفتاح فهم لماذا لا تهم الإصدارات للعدّاد. نظام Google يمرّر المختبِرين في قمع، والمراحل اللاحقة وحدها تحمل الوزن.
مدعو
أضفت بريدًا إلى قائمة المختبِرين أو Google Group. لم يحدث شيء أكثر بعد.
وافق على المشاركة
ضغط رابط الانضمام، سجّل بحساب Google، واختار Become a tester. هذه الحالة التي يقيسها عدّاد 14 يومًا.
ثبّت ونشط
نزّل التطبيق ويواصل استخدامه. لا يغيّر العدّ الخام، لكنه ما تزنه Google للتفاعل عند طلب الإصدار العلني.
كما توضّح وثائق Google، إضافة بريد لا تكفي. يجب أن يفتح كل مختبِر رابط الانضمام، يوثّق هويته، ويصبح مختبِرًا صراحة قبل أن يُحتسب. ولهذا أيضًا لا يعيد تحديث التطبيق تقدّمك: المختبِرون لا يغادرون حالة الموافقة، فيستمر العدّاد عبر كل إصدار جديد. لشرح كامل، راجع دليلنا عن كيف تدعو المختبِرين بشكل صحيح.
نصيحة من إدارة آلاف الاختبارات: شغّل مختبِريك عبر Google Group لا قائمة بريد ثابتة. مع مجموعة مربوطة بـ Play Console، تبدّل مختبِرًا بإدخال أو إخراج من المجموعة: رابط الانضمام يبقى نفسه والمسار يستمر. ذلك يزيل خطر مسح مختبِرين نشطين بالخطأ أثناء تعديل القائمة، وهو من الأشياء القليلة التي قد تكسر سلسلتك فعليًا.
ما نص شرط Google الرسمي بالضبط؟
صفحة مساعدة Play Console الرسمية «متطلبات اختبار التطبيقات لحسابات المطوّر الشخصية الجديدة» تنصّ بدقة:
«إذا كان لديك حساب مطوّر شخصي جديد، يجب إجراء اختبار مغلق لتطبيقك يضم 12 مختبِرًا على الأقل ممّن وافقوا على المشاركة لآخر 14 يومًا متواصلة.»
Google Play Console Help · answer 14151465وبشكل منفصل، عند لحظة طلب الإصدار العلني:
«يجب أن يكون 12 مختبِرًا على الأقل قد وافقوا على المشاركة في اختبارك المغلق عند تقديم طلب الإصدار العلني. ويجب أن يكونوا قد وافقوا على المشاركة لآخر 14 يومًا متواصلة.»
Google Play Console Help · answer 14151465توضّح Google أيضًا بكلماتها أن الأيام يجب أن تكون متتالية: لن تُحتسب مختبِرين وافقوا، اختبروا أقل من 14 يومًا، ثم خرجوا، وحتى إن عادوا، يجب أن تكون الـ14 يومًا متتالية لتُحتسب. ذلك البند وحده يقتل أسطورة «14 يومًا تراكمية»، والأهم: لا يقول شيئًا عن إصداراتك.
ثلاث حقائق لتثبيتها
هل رفع التحديثات أثناء الاختبار جيد أم سيء؟
هنا ينقلب قلق المطوّر إلى فرصة. رفع التحديثات أثناء الاختبار المغلق يُنظر إليه على نطاق واسع كإشارة تفاعل إيجابية. يجدر فصل ما تقوله Google رسميًا عمّا خلص إليه مجتمع المطوّرين، لأنهما يتداخلان دون أن يكونا متطابقين:
واصل التكرار والإصلاح
تشجّع مساعدة Play Console على التكرار المستمر: واصل استخدام الاختبار المغلق أثناء إصلاح المشاكل والأخطاء التي يبلّغ عنها المستخدمون، وتحديث تطبيقك في الاختبار المغلق قبل الإصدار العلني «طريقة رائعة لتقليل التقييمات والمراجعات منخفضة الجودة».
عند طلب الإصدار العلني، تطلب منك الأسئلة وصف التفاعل الذي تلقيته وما فعلت بملاحظات المختبِرين.
النشط يتفوّق على المتجمّد
يمضي الممارسون أبعد: تطبيق متجمّد عند الإصدار 1.0 لأربعة عشر يومًا بلا نشاط يبدو اختبارًا للخانة فقط، بينما تطبيق يرفع تحديثات استجابة للملاحظات يبدو تطويرًا حقيقيًا. يدفع بعض المطوّرين تحديثين أو ثلاثة صغيرة عمدًا لإظهار الاستجابة.
هذا إجماع مجتمعي واستدلال معقول، لا قاعدة Google منشورة. لم تفرض Google عددًا رقميًا لـ«ارفع X تحديثًا».
الخلاصة: التحديث آمن ومشجَّع، وقصة التفاعل التي تبنيها به قد تساعدك في الإجابة عن أسئلة طلب الإصدار العلني. الخطر الحقيقي الوحيد يأتي مما تنشره، لا من فعل النشر: وهذا يقود إلى التحفّظ الوحيد الجوهري.
هل يمكن أن يعيد تحديث سيء ضبط العدّاد بشكل غير مباشر؟
نعم: وهذا التحفّظ الوحيد المهم. بينما فعل التحديث لا يعيد المؤقت مباشرة، قد تفعل عواقب تحديث مكسور ذلك. اتبع السلسلة:
إذن القاعدة بسيطة: حدّث بحرية، لكن افحص كل إصدار لاستقرار أساسي قبل رفعه إلى مسارك المغلق. ولا تشغّل عند 12 مختبِرًا بالضبط، لأن خروجًا واحدًا من إصدار سيء قد يسقطك. هامش مختبِرين فوق 12 يمتص ذلك الخطر.
اقرأ السلسلة بعناية: إعادة الضبط لا يسببها التحديث أبدًا. يسببها الانخفاض دون 12 مختبِرًا وافقوا. الإصدار المكسور مجرد ما أشعل الخروج. أبقِ إصداراتك مستقرة وابقِ هامشًا، فيختفي الخطر غير المباشر أيضًا.
هل يحتاج المختبِرون إعادة تثبيت أو موافقة بعد التحديث؟
لا. بعد أن يوافق المختبِر على المشاركة ويثبّت تطبيقك، تتولى Google التحديثات تلقائيًا. لا شيء يضغطونه ولا شيء تعيد إرساله.
التحديثات تُطرح تلقائيًا
تنص مساعدة Play Console، في Set up an open, closed, or internal test (answer 9845334)، بوضوح: «بمجرد أن يثبّت المختبِرون تطبيقك، يُحدَّثون تلقائيًا لاستخدام إصدار الاختبار خلال دقائق.» يبقون موافقين عبر كل إصدار: بلا إعادة تثبيت، بلا ضغطة موافقة ثانية.
تحفّظ توقيت من الصفحة نفسها: عند نشر تغييرات إضافية، «قد لا تكون متاحة للمختبِرين لعدة ساعات» قبل أن يبدأ التحديث التلقائي على الجهاز. لكن حالة الموافقة، وهي ما يقيسه عدّاد 14 يومًا، تنتقل عبر كل AAB جديد. ولهذا لا يعيد تحديث الإصدار العدّاد: المختبِرون لم يغادروا.
استثناء مهم الأذونات الجديدة قد تقطع التحديث الصامت
نوع واحد من الإصدارات لا يُطرح دائمًا بصمت: تحديث يضيف إذنًا خطيرًا (حسّاسًا) جديدًا مثل ACCESS_FINE_LOCATION أو الكاميرا أو الميكروفون. حسب الإذن ومستوى API المستهدف، قد يعرض Google Play زر Update يجب أن يضغطه المختبِر ويوافق عليه يدويًا بدل التثبيت في الخلفية، ومن يتجاهله يبقى على الإصدار القديم. وحتى عند التثبيت الصامت، يُمنح الإذن الجديد وقت التشغيل فقط، فقد تبدو ميزة مشروطة بالإذن مكسورة حتى يسمح المختبِر.
في اختبار مغلق هذا فخ هادئ: ارفع تحديثًا ثقيل الأذونات في اليوم 5 وقد تنخفض أرقام المختبِرين النشطين، إشارة التفاعل التي تزنها Google عند طلب الإصدار العلني، لأن نصف مختبِريك لم يروا المطالبة. إذن عالي المخاطر جديد قد يفعّل أيضًا مراجعة تصريح الأذونات تؤخر نشر الإصدار أصلًا.
قبل الطرح في منتصف الاختبار: قارن أذونات الـ manifest الجديد مع الإصدار الحي. إن تغيّرت مجموعة الأذونات، راسل مختبِريك ليفتحوا متجر Play ويحدّثوا يدويًا (ويوافقوا على المطالبة الجديدة)، واحسب وقتًا لمراجعة تصريح محتملة.
أساطير شائعة عن الاختبار المغلق، مفكّكة
معظم الذعر حول التحديث يعود إلى حفنة أساطير. هذه الخمس التي تكلّف المطوّرين أكثر نوم، مع ما هو صحيح فعليًا:
أسطورة 1«إنشاء إصدار جديد يعيد ضبط العدّاد.»
أسطورة 2«إزالة التثبيت تساوي الخروج من الاختبار.»
أسطورة 3«الـ14 يومًا تراكمية.»
أسطورة 4«12 مختبِرًا بالضبط يكفي.»
أسطورة 5«يجب أن يستخدم المختبِرون التطبيق كل يوم.»
ما يعيد ضبط العدّاد وما لا يعيده
السؤال كله على شاشة واحدة. احفظها، التقطها، أو أرسلها لمن في فريقك يسأل مرارًا. كل ما يتعلق بإصدارك آمن؛ فقط ما يتعلق بعدد المختبِرين ليس كذلك.
| الإجراء | يعيد عدّاد 14 يومًا؟ |
|---|---|
| رفع AAB جديد على نفس المسار المغلق | لا |
| تعديل ملاحظات الإصدار أو بيانات قائمة المتجر | لا |
| مختبِر يرسل ملاحظات | لا |
| تعطل التطبيق على جهاز مختبِر | لا |
| مختبِر يزيل التثبيت (دون الخروج) | لا* |
| انخفاض عدد من وافقوا دون 12 | نعم |
| خروج رسمي عبر رابط الاختبار الويب | نعم** |
| رفع إصدار مكسور يدفع الخروج دون 12 | بشكل غير مباشر |
| إيقاف مسار الاختبار المغلق | خطر مُبلَّغ |
| استبدال قائمة المختبِرين وحذف النشطين | خطر مُبلَّغ |
* المؤقت يستمر تقنيًا، لكن من يزيل التثبيت نادرًا ما يعود. ** فقط إن دفعك دون 12. الصفّان الأخيران تحذير مجتمعي لا وثائق Google مؤكدة، فاعتبرهما «لا تخاطر» لا قواعد معلنة. استخدام Google Group يتجاوز خطر استبدال القائمة تمامًا.
كيف تغيّر الشرط عبر الزمن
إن كنت تقرأ دروسًا أقدم، فهذا سبب اختلاف الأرقام. المدة كانت دائمًا 14 يومًا متواصلة؛ فقط عدد المختبِرين تحرّك.
قبل نوفمبر 2023 لم يكن هناك اختبار مغلق مطلوب للوصول إلى الإصدار العلني. كان يمكن النشر دون جمع مختبِرين.
حسابات شخصية أُنشئت بعد 13 نوفمبر 2023 كان عليها إجراء اختبار مغلق مع 20 مختبِرًا وافقوا لـ14 يومًا متواصلة. حسابات المؤسسات معفاة.
في 11 ديسمبر 2024 انخفض الحد من 20 إلى 12، مع بقاء مدة 14 يومًا. حسابات المؤسسات ما زالت معفاة.
أي دليل ما زال يطلب 20 مختبِرًا قديم. نفصّل التحويل في ما تغيّر من 20 إلى 12 مختبِرًا.
تغييرات سياسة 2026 يجب أن تعرفها
الاختبار المغلق لا يعيش في فراغ. مواعيد 2026 قد تتقاطع مع جدول إطلاقك: لا يغيّر أي منها عمل عدّاد 14 يومًا، لكنها قد تصطدم بنافذتك إن لم تراقب التقويم:
مواعيد 2026 التي تتقاطع مع جدولك
التواريخ حسب مساعدة Play Console (مستوى API المستهدف) ومدونة Android Developers (التحقق من المطوّر). توقيت التحقق مرحلي وقد يتوسع عبر 2026-2027، فأكّد من الصفحات الرسمية قبل التخطيط. دليلنا عن متطلبات النشر 2026 يتتبع القائمة الكاملة.
كيف تبقي PrimeTestLab عدّادك يعمل
أصعب جزء في الاختبار المغلق ليس فهم القواعد؛ بل إبقاء 12 إنسانًا حقيقيًا أو أكثر موافقين ومتفاعلين 14 يومًا بلا انقطاع وأنت تكرّر. هذا بالضبط ما بُنيت PrimeTestLab لأجله. نوفّر مختبِرين على أجهزة حقيقية وافقوا على المشاركة ونرشد إعداد Play Console حتى يبدأ العدّاد نظيفًا ويبقى يعمل وأنت تنشر الإصلاحات. اطّلع على خدمة الاختبار المغلق لجوجل بلاي لمعرفة ما يشمله العرض. نحافظ على نسبة نجاح 99.9% عبر 9,800+ تطبيقًا، ويبدأ الاختبار خلال 4-6 ساعات.
تضيف مختبِرينا في Play Console، تشارك رابط الاختبار، ويبدأ العدّاد. من هناك حدّث إصدارك بقدر ما تشاء: يبقون موافقين، فتستمر السلسلة تحتك.
يختار معظم المطوّرين أكثر من الحد الأدنى 12 مختبِرًا تحديدًا حتى لا يسقطهم خروج واحد، بما فيه خروج بسبب إصدار سيء، دون 12 ويعيد العدّاد. الهامش أرخص تأمين ضد الشيء الوحيد الذي يكسر سلسلتك فعليًا.
الأسئلة الشائعة
هل يمكنني تحديث تطبيقي أثناء الاختبار المغلق دون إعادة 14 يومًا؟
نعم. رفع إصدار جديد إلى مسار الاختبار المغلق الحالي لا يعيد نافذة 14 يومًا المتواصلة. العدّاد مربوط بالحفاظ على 12 مختبِرًا على الأقل وافقوا على المشاركة بشكل متواصل، لا بإصدار تطبيقك. يُحدَّث المختبِرون تلقائيًا ويبقون موافقين، فينتقل تقدّمك عبر الإصدارات.
ما الشيء الوحيد الذي يعيد ضبط عدّاد الاختبار المغلق؟
تنكسر نافذة 14 يومًا المتواصلة عندما ينخفض عدد من وافقوا دون 12، أو عندما يخرجون رسميًا ويدفعونك دون الحد. تحديثات الإصدار وتعديلات قائمة المتجر والأعطال لا تعيد الضبط. الإبقاء على هامش مختبِرين فوق 12 هو أوثق طريقة لحماية سلسلتك.
ما الفرق بين المدعوّين ومن وافقوا على المشاركة؟
مدعو يعني أنك أضفت بريده إلى قائمتك، وهذا لا يُحتسب لشيء. وافق على المشاركة يعني أنه ضغط رابطك، سجّل الدخول، واختار Become a tester، وهذه الحالة التي يقيسها عدّاد 14 يومًا. فقط من وافقوا يُحتسبون في الشرط، فأكّد دائمًا أنهم أكملوا خطوة الموافقة.
هل يجب أن يعيد المختبِرون الموافقة بعد رفع تحديث؟
لا. بعد أن يوافق المختبِر ويثبّت، توصل Google تحديثاتك تلقائيًا خلال دقائق. لا يعيدون التثبيت ولا يضغطون رابط الانضمام مجددًا. حالة الموافقة، وهي ما يقيسه شرط 14 يومًا، تستمر بلا انقطاع عبر كل إصدار ترفعه إلى نفس المسار المغلق.
هل إزالة التثبيت مثل الخروج من الاختبار؟
لا. يخرج المختبِر رسميًا فقط بزيارة رابط الاختبار الويب واختيار المغادرة. إن أزال التثبيت فحسب، يستمر المؤقت تقنيًا. عمليًا، من يزيل التطبيق نادرًا ما يعود، ما قد يضعف التفاعل الذي تقدّمه عند طلب الإصدار العلني، لذا يبقى إبقاء المختبِرين نشطين مهمًا.
هل تريد Google أن أرفع تحديثات أثناء الاختبار؟
توصي وثائق Google بمواصلة إصلاح المشاكل في الاختبار المغلق قبل الإصدار العلني واختبار التحديثات المستقبلية بانتظام. يذهب إجماع مجتمع المطوّرين أبعد، فيعتبر التحديثات النشطة إشارة تفاعل إيجابية مقابل تطبيق متجمّد يبدو كملء خانات. لم تنشر Google عدد تحديثات مطلوبًا، فكرّر بصدق لا بحشو.
كم مختبِرًا أحتاج فعليًا للاختبار المغلق؟
الحد الأدنى لدى Google 12 مختبِرًا وافقوا لـ14 يومًا متواصلة لحسابات شخصية أُنشئت بعد 13 نوفمبر 2023. لأن خروجًا واحدًا قد ينزلك دون 12 ويكسر السلسلة، يشغّل كثير من المطوّرين 20 إلى 25 مختبِرًا كهامش. تقدّم PrimeTestLab خطط 12 و20 و25 مختبِرًا تبدأ من 19.99 US$.
الخلاصة
ملخص
تحديث تطبيقك أثناء اختبار 14 يومًا المغلق آمن وطبيعي ومشجَّع. يُقاس العدّاد بالحفاظ على 12 مختبِرًا على الأقل وافقوا على المشاركة بشكل متواصل، فإصدار جديد لا يعيده بمفرده. المخاطر الحقيقية هي الانخفاض دون 12، أو خروج المختبِرين رسميًا، أو رفع إصدار مكسور لدرجة خروجهم. انشر إصلاحاتك، كرّر على الملاحظات، واحمِ عدد مختبِريك بهامش فوق الحد الأدنى. إن أردت عدّادًا لا ينكسر ببساطة، تبقي PrimeTestLab من 12 إلى 25 مختبِرًا حقيقيًا موافقين من 19.99 US$، ويبدأ الاختبار خلال 4-6 ساعات. اطّلع على خطط الأسعار ←