TestHive
ابدأ الآن

كيف تمنع TestHive احتيال المختبِرين

نُشر 2026-06-17

ملخّص

كل حملة (Campaign) في TestHive تجتاز فحص احتيال من 4 بوابات قبل مطابقة المختبِرين: تفرّد الحزمة (package)، وتجميع بصمة الجهاز، والتحقق عبر Play Store، والإشراف البشري على الحالات المُعلَّمة. تُبقى العتبات الدقيقة خاصة عمدًا لمنع التحايل عليها، لكن مخطط السياسة موضّح أدناه.

لماذا يهم هذا المطورين

عند إرسال تقرير الاختبار المغلق (Closed Testing) الخاص بك إلى Google Play، تُجري Google فحص الاحتيال الخاص بها. إذا اكتشفت مختبِرين بحسابات وهمية ضمن مجموعتك المكوّنة من 12 شخصًا، يمكن رفض تطبيقك بالكامل نهائيًا — ليس مرحلة الاختبار فحسب، بل الوصول إلى الإنتاج أيضًا.

مهمة TestHive هي تقديم مختبِرين تقبلهم Google. هذا يعني أن علينا أن نكون أكثر صرامة من Google.

البوابات الأربع

البوابة 1 · تفرّد الحزمة (package)

يمكن للمختبِر نفسه أن يكون نشطًا في حملة واحدة فقط لكل package_name على Android. إذا كان يختبر بالفعل com.example.myapp لمطوّر، فلا يمكنه اختباره في الوقت ذاته لمطوّر آخر.

هذا يمنع الشكل البديهي من الاحتيال حيث ينضم شخص واحد إلى 5 حملات للتطبيق ذاته فيبدو وكأنه 5 مختبِرين بالنسبة إلى Google.

البوابة 2 · بصمة الجهاز عبر الحسابات

عندما يسجّل مختبِر، نلتقط بصمة جهاز بعشرة أبعاد (إشارات الأجهزة + المتصفح + السلوك). إذا تشاطر حسابان بصمة تتجاوز عتبة معينة، يُعلَّم الحساب الثاني كحساب وهمي محتمل.

خوارزمية البصمة غير مُفصَح عنها عمدًا — فنشرها يتيح للمحتالين ضبط أساليبهم للالتفاف عليها. ونفصح أن أفراد العائلة على الجهاز الفيزيائي نفسه سيفشلون في هذا الفحص، وهذا مقصود (فحص Google نفسه سيُسقطهم أيضًا).

البوابة 3 · التحقق عبر Play Store

نستخدم واجهة Play Scraper API العامة من Google Play للتحقق من:

  • أن testing_url الخاص بالمختبِر يحلّ إلى مسار اختبار مغلق (Closed Testing) حقيقي
  • أن إدراج Play Store يطابق package_name الذي صرّح به المطوّر
  • أن حساب Play Store القائم خلف الاختبار في وضع سليم

توجد هذه البوابة لمنع المختبِرين من الانضمام إلى حملة لتطبيق غير موجود أو احتيالي.

البوابة 4 · الإشراف البشري (الملاذ الأخير)

عندما تكون نتائج البوابات 1-3 غير حاسمة (مخاطرة متوسطة، بصمة غامضة، حالة حدّية)، يتولّى مراجع من دعم TestHive الحالة. اتفاقية مستوى الخدمة (SLA) هي 24-48 ساعة.

البوابة 4 هي أيضًا مسار الاعتراض — يمكن الاعتراض على أي رفض من البوابات 1-3 ويُحال إلى هنا.

ما لا يستطيع المختبِرون أنفسهم فعله

  • دفع المال لشخص آخر ليقوم بتسجيلات الحضور اليومية نيابة عنهم (اختلاف عنوان IP / الجهاز ← علامة عدم تطابق البصمة)
  • استخدام VPN لتزييف بلدهم (بلد حساب Play Store هو مصدر الحقيقة)
  • إرسال لقطات شاشة مولَّدة بالذكاء الاصطناعي (نحسب التجزئة الإدراكية (perceptual hash) ونرفض المكررات عبر المختبِرين)
  • تشغيل سكربت للإرسال التلقائي في الوقت ذاته كل يوم (تحليل أنماط التوقيت يلتقط هذا)

ما لا ننشره

العتبات المحددة، ودرجات المخاطرة، وتفاصيل خوارزمية البصمة الداخلية. نشرها سيعلّم المحتالين كيفية التحايل علينا. لكننا ننشر ما يُفحَص على مستوى الفئة — شفافية في السياسة دون دليل استغلال.

ماذا يحدث إذا تأكّد الاحتيال بعد التسوية

إذا اكتشفنا احتيالًا بعد تسوية الحملة وصرف مدفوعات المختبِرين:

  1. تُعكَس أرباح المختبِر (خصم من محفظته، وحجز من أرباحه المستقبلية)
  2. التقرير المُتحقَّق منه للحملة لا يُلغى (لقد استخدمته بالفعل للإرسال إلى Google Play — وهذا حدث لمرة واحدة)
  3. تتحمل TestHive أي خسارة غير قابلة للاسترداد — لا يُحاسَب المطورون مرتين

تأمينك ضد الاحتيال مدمج في رسوم المنصة البالغة 20%. نحن نحمل المخاطرة حتى لا تضطر أنت لذلك.

أسئلة شائعة

  • Q: ماذا يحدث إذا تسلّل مختبِر محتال؟

    A: بوابات الموافقة اليومية لدينا تلتقط معظم الاحتيال خلال نافذة الـ 14 يومًا (لقطات شاشة مكررة، غياب أنماط تفاعل حقيقية). الاحتيال المؤكَّد يعكس أرباح المختبِر، وتتحمل TestHive الخسارة على جانب المنصة — لا يُحاسَب المطورون أبدًا على الاحتيال.

  • Q: هل يمكنني الاعتراض إذا رُفِضت حملتي بواسطة فحص الاحتيال؟

    A: نعم. كل رفض من البوابة الرابعة يتضمن سببًا مكتوبًا ورابط اعتراض. يرد المراجعون البشريون خلال 48 ساعة.

  • Q: هل تضمن TestHive مختبِرين خاليين من الاحتيال بنسبة 100%؟

    A: لا يمكن لأي نظام أن يضمن ذلك، لكن معدل الاحتيال لدينا أقل من 0.5% في الحملات التي جرى تخليصها — وأي احتيال مؤكَّد نتكفّل بتعويضه نحن، ولا يُحمَّل عليك.

ذات صلة

كيف تمنع TestHive احتيال المختبِرين · TestHive Docs · TestHive