> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # اختبار سياسة > قم بالاختبار العكسي لمسودة ضد حركة المرور التي لديك بالفعل، وأثبت أنها توقف ما يجب إيقافه وتسمح بما يجب السماح به، قبل أن تفرضها أي آلة. اختبر كل سياسة بطريقتين: ضد حركة المرور التي أنتجتها وكلاؤك بالفعل، وضد إجراء شرعي يجب أن تسمح به. السياسة التي لم ترَ سوى الحالة غير الآمنة لم تُختبر. ## الاختبار العكسي للمسودة محرر السياسة يعيد تشغيل مسودة ضد الاستدعاءات التي أجرتها أسطولك بالفعل، قبل نشرها. 1. افتح المسودة في **Admin → policy editor**. يؤكد المحرر أنها تحلل كـ JavaScript. 2. في **backtest**، اختر الوكلاء ونطاق الوقت الذي تريد إعادة تشغيله — **كل الوكلاء** و**30d** بشكل افتراضي — واترك آخر مرشح على **everything** ما لم تريد تضييقه. 3. اختر **run backtest**. لوحة الاختبار العكسي أسفل مسودة تحلل كـ JavaScript، مع مرشحاتها الثلاثة وإجراء تشغيل الاختبار العكسي، أعلى إصدار النشر. النتيجة هي ما كانت ستفعله المسودة لتلك الاستدعاءات — بما في ذلك عدد استدعاءات **working** التي كانت ستقاطع. هذه إيجابيات خاطئة تم العثور عليها قبل أن يواجهها أي وكيل: أحكم المسودة وشغلها مرة أخرى حتى يصبح هذا الرقم مقبولاً. الاختبار العكسي هو ميزة لوحة التحكم. من الطرفية، شغل السياسة ضد الأحداث التي تصفها بدلاً من ذلك، أدناه. ## شغله ضد حدث تصفه `fp policies test` يشغل ملف السياسة على جهازك ضد حدث اصطناعي ويتحقق من القرار. لا يتم نشر أي شيء ولا يصل أي شيء إلى Cloud: ```bash theme={null} fp policies test ./checkout.policy.mjs --command "git push --force" --expect deny fp policies test ./checkout.policy.mjs --command "git push" --expect allow ``` شكّل الحدث باستخدام `--event` و `--tool` و `--command` و `--file`. مرشح `match` الخاص بالسياسة نفسها ينطبق أيضاً، لذا فإن السياسة التي لا تغطي الحدث الذي وصفته تُرجع `skipped` بدلاً من قرار — عادة ما يكون علامة على أن `match` أضيق مما قصدت. ## شغله على جهاز واحد بعد ذلك، فرضه حقاً على جهازك الخاص، ضد وكيلك الخاص: ```bash theme={null} failproofai policies --install --custom ./checkout.policy.mjs --scope project failproofai policies ``` الأمر الأول يتحقق من صحة الملف وينصبه؛ والثاني يؤكد أنه تم تحميله، إلى جانب كل شيء آخر يفرضه هنا. اطلب من الوكيل أن يفعل ما تحقفه السياسة وشاهده يتم رفضه، ثم قم بالإصدار الشرعي وشاهده يمر. لا أحد آخر يتأثر. على جهاز متصل بـ Cloud، تحقق من كلا القرارين تحت **Observe → policy**: قم بالتصفية حسب اسم السياسة، ثم افتح كل جلسة مرتبطة لتأكيد إدخال الأداة التي طابقتها والسبب في عودتها. ## اختبر ما ينكسر التثبيت يرفض ملف مفقود، أو خطأ في بناء الجملة، أو استيراد لم يتم حله، أو استثناء على المستوى الأعلى، أو وحدة تتجاوز المهلة الزمنية أثناء التحميل — لذا أعد تشغيله بعد كل تغيير على الملف أو أي شيء يستورده. في وقت الفرض، يتم تسجيل نفس الملف المكسور و **skipped** بحيث تستمر كل سياسة أخرى في العمل: تعامل مع تحذير التحميل في سجلات الإنتاج كفرض مفقود. ملفات الاتفاقية يتم تحميلها بدون أمر التثبيت، لذا احتفظ بخطوة `failproofai policies --install --custom ` صريحة في CI — هذا ما يفشل البناء على سياسة مكسورة. ثم أطعمه ما يرسله الوكلاء فعلاً، ليس فقط الإدخال الذي تتوقعه: الحقول المفقودة، أسماء الأدوات البديلة مثل `Write` و `Edit`، مسارات Windows، إدخال مشوه. أرجع `allow` أو `instruct` أو `deny` متعمد على كل مسار، اجعل الدالة حتمية، واربط أي استدعاء خارجي برصيد زمني قصير. ## ثم انشره وراقبه يُظهر الاختبار العكسي ما كانت ستفعله السياسة لحركة المرور التي كانت لديك؛ لا يمكن أن يُظهر ما ستفعله حركة المرور التي لم تشهدها حتى الآن. اختر **publish version** في المحرر (أو شغل `fp policies publish`)، ثم [نشّرها](/ar/policies/deploy) في وضع **observe** أولاً — يتم تسجيل أحكامها ولا يتم حظر أي شيء — وفرضها بمجرد أن تفصل مطابقاتها الإجراءات غير الآمنة عن الإجراءات الصحيحة.