---
read_when:
    - توسيع qa-lab أو qa-channel
    - إضافة سيناريوهات QA مدعومة من المستودع
    - بناء أتمتة QA ذات واقعية أعلى حول لوحة تحكم Gateway
summary: شكل أتمتة QA الخاصة لـ qa-lab وqa-channel والسيناريوهات المُهيّأة مسبقًا وتقارير البروتوكول
title: أتمتة QA الشاملة من البداية إلى النهاية
x-i18n:
    generated_at: "2026-04-23T13:59:22Z"
    model: gpt-5.4
    provider: openai
    source_hash: a967a74d2e70b042e9443c5ec954902b820d2e5a22cbecd9be74af13b9085553
    source_path: concepts/qa-e2e-automation.md
    workflow: 15
---

# أتمتة QA الشاملة من البداية إلى النهاية

تهدف حزمة QA الخاصة إلى اختبار OpenClaw بطريقة أكثر واقعية
ومشابهة للقنوات من مجرد اختبار وحدة واحد.

المكونات الحالية:

- `extensions/qa-channel`: قناة رسائل اصطناعية تحتوي على أسطح للرسائل المباشرة والقناة والخيط
  والتفاعل والتحرير والحذف.
- `extensions/qa-lab`: واجهة مستخدم لتصحيح الأخطاء وناقل QA لمراقبة السجل النصي
  وحقن الرسائل الواردة وتصدير تقرير Markdown.
- `qa/`: أصول تهيئة أولية مدعومة من المستودع لمهمة الانطلاق وخطوط QA
  الأساسية.

تدفق عمل مشغّل QA الحالي هو موقع QA ذو لوحتين:

- اليسار: لوحة تحكم Gateway (Control UI) مع الوكيل.
- اليمين: QA Lab، ويعرض سجلًا نصيًا شبيهًا بـ Slack وخطة السيناريو.

شغّله باستخدام:

```bash
pnpm qa:lab:up
```

يقوم هذا ببناء موقع QA، وبدء مسار Gateway مدعوم بـ Docker، ويعرض
صفحة QA Lab حيث يمكن للمشغّل أو حلقة الأتمتة إعطاء الوكيل
مهمة QA، ومراقبة سلوك القناة الفعلي، وتسجيل ما نجح أو فشل أو
ظل محظورًا.

للحصول على تكرار أسرع في واجهة QA Lab دون إعادة بناء صورة Docker في كل مرة،
ابدأ الحزمة باستخدام حزمة QA Lab مركبة عبر bind mount:

```bash
pnpm openclaw qa docker-build-image
pnpm qa:lab:build
pnpm qa:lab:up:fast
pnpm qa:lab:watch
```

يبقي `qa:lab:up:fast` خدمات Docker على صورة مبنية مسبقًا ويركب
`extensions/qa-lab/web/dist` داخل حاوية `qa-lab` عبر bind mount. ويقوم `qa:lab:watch`
بإعادة بناء تلك الحزمة عند التغيير، وتُعاد تحميل الصفحة في المتصفح تلقائيًا عندما يتغير
تجزئة أصول QA Lab.

لتشغيل مسار smoke حقيقي للنقل لـ Matrix، نفّذ:

```bash
pnpm openclaw qa matrix
```

يقوم هذا المسار بتهيئة خادم Tuwunel منزلي مؤقت داخل Docker، وتسجيل
مستخدمين مؤقتين للسائق وSUT والمراقب، وإنشاء غرفة خاصة واحدة، ثم تشغيل
Plugin الحقيقي لـ Matrix داخل عملية فرعية لـ QA gateway. ويحافظ مسار النقل الحي
على تكوين العملية الفرعية محصورًا في النقل قيد الاختبار، لذلك يعمل Matrix من دون
`qa-channel` في تكوين العملية الفرعية. ويكتب عناصر التقرير المنظم
وسجل stdout/stderr الموحّد في دليل مخرجات Matrix QA المحدد. وللالتقاط
مخرجات البناء/التشغيل الخاصة بـ `scripts/run-node.mjs` الخارجية أيضًا، اضبط
`OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` إلى ملف سجل محلي داخل المستودع.

لتشغيل مسار smoke حقيقي للنقل لـ Telegram، نفّذ:

```bash
pnpm openclaw qa telegram
```

يستهدف هذا المسار مجموعة Telegram خاصة حقيقية واحدة بدلًا من تهيئة خادم
مؤقت. ويتطلب `OPENCLAW_QA_TELEGRAM_GROUP_ID`،
و`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN`، و
`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`، بالإضافة إلى روبوتين مختلفين في المجموعة
الخاصة نفسها. يجب أن يمتلك روبوت SUT اسم مستخدم في Telegram، وتعمل
المراقبة بين الروبوتات بأفضل شكل عندما يكون لدى كلا الروبوتين وضع
Bot-to-Bot Communication Mode مفعّلًا في `@BotFather`.
يخرج الأمر برمز غير صفري عند فشل أي سيناريو. استخدم `--allow-failures` عندما
تريد العناصر الناتجة دون رمز خروج فاشل.
يتضمن تقرير Telegram وملخصه RTT لكل رد من طلب إرسال رسالة السائق
إلى رد SUT المرصود، بدءًا من canary.

تتشارك مسارات النقل الحي الآن عقدًا أصغر واحدًا بدلًا من أن يخترع كل مسار
شكل قائمة السيناريوهات الخاص به:

يبقى `qa-channel` مجموعة سلوك المنتج الاصطناعية الواسعة وليس جزءًا
من مصفوفة تغطية النقل الحي.

| المسار   | Canary | بوابة الإشارات | حظر قائمة السماح | رد على المستوى الأعلى | الاستئناف بعد إعادة التشغيل | متابعة الخيط | عزل الخيط | مراقبة التفاعل | أمر المساعدة |
| -------- | ------ | -------------- | ---------------- | ---------------------- | --------------------------- | ------------ | ---------- | ---------------- | ------------ |
| Matrix   | x      | x              | x                | x                      | x                           | x            | x          | x                |              |
| Telegram | x      |                |                  |                        |                             |              |            |                  | x            |

يبقي هذا `qa-channel` مجموعة سلوك المنتج الواسعة بينما تتشارك
Matrix وTelegram ووسائل النقل الحية المستقبلية قائمة فحص صريحة واحدة لعقد النقل.

لتشغيل مسار Linux VM مؤقت من دون إدخال Docker في مسار QA، نفّذ:

```bash
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
```

يقوم هذا بتشغيل ضيف Multipass جديد، وتثبيت التبعيات، وبناء OpenClaw
داخل الضيف، وتشغيل `qa suite`، ثم نسخ تقرير QA العادي والملخص
مرة أخرى إلى `.artifacts/qa-e2e/...` على المضيف.
ويعيد استخدام سلوك اختيار السيناريو نفسه الذي يستخدمه `qa suite` على المضيف.
تُنفّذ عمليات suite على المضيف وMultipass عدة سيناريوهات محددة بالتوازي
مع عمّال Gateway معزولين افتراضيًا. يستخدم `qa-channel` افتراضيًا تزامنًا بمقدار 4،
مع حد أقصى بعدد السيناريوهات المحددة. استخدم `--concurrency <count>` لضبط
عدد العمال، أو `--concurrency 1` للتنفيذ التسلسلي.
يخرج الأمر برمز غير صفري عند فشل أي سيناريو. استخدم `--allow-failures` عندما
تريد العناصر الناتجة دون رمز خروج فاشل.
تقوم التشغيلات الحية بتمرير مدخلات مصادقة QA المدعومة والعملية للضيف:
مفاتيح الموفر المعتمدة على env، ومسار تكوين موفر QA الحي، و
`CODEX_HOME` عند وجوده. أبقِ `--output-dir` تحت جذر المستودع حتى يتمكن الضيف
من الكتابة مرة أخرى عبر مساحة العمل المركبة.

## العناصر الأولية المدعومة من المستودع

توجد أصول التهيئة الأولية في `qa/`:

- `qa/scenarios/index.md`
- `qa/scenarios/<theme>/*.md`

وُضعت هذه عمدًا داخل git حتى تكون خطة QA مرئية لكل من البشر
والوكيل.

يجب أن يظل `qa-lab` مشغّل Markdown عامًا. يجب أن يكون كل ملف Markdown لسيناريو
هو المصدر المرجعي لتشغيل اختبار واحد، ويجب أن يحدد:

- بيانات تعريف السيناريو
- بيانات تعريف اختيارية للفئة والقدرة والمسار والمخاطر
- مراجع الوثائق والشفرة
- متطلبات Plugin اختيارية
- تصحيح تكوين Gateway اختياري
- `qa-flow` القابل للتنفيذ

يُسمح لسطح وقت التشغيل القابل لإعادة الاستخدام الذي يدعم `qa-flow` بأن يظل عامًا
وعابرًا للجوانب. على سبيل المثال، يمكن لسيناريوهات Markdown الجمع بين
مساعدات جهة النقل ومساعدات جهة المتصفح التي تقود Control UI المضمّن عبر
واجهة Gateway `browser.request` من دون إضافة مشغّل حالة خاصة.

يجب تجميع ملفات السيناريو حسب قدرة المنتج بدلًا من مجلد شجرة المصدر.
أبقِ معرّفات السيناريو مستقرة عند نقل الملفات؛ واستخدم `docsRefs` و`codeRefs`
لتتبع التنفيذ.

يجب أن تظل القائمة الأساسية واسعة بما يكفي لتغطية:

- الرسائل المباشرة ودردشة القناة
- سلوك الخيوط
- دورة حياة إجراءات الرسائل
- استدعاءات Cron
- استدعاء الذاكرة
- تبديل النماذج
- التسليم إلى وكيل فرعي
- قراءة المستودع وقراءة الوثائق
- مهمة بناء صغيرة واحدة مثل Lobster Invaders

## مسارات mock للموفرين

يحتوي `qa suite` على مسارين محليين لـ mock الموفرين:

- `mock-openai` هو mock الواعي بالسيناريوهات الخاص بـ OpenClaw. ويبقى
  مسار mock الحتمي الافتراضي لـ QA المدعوم من المستودع وبوابات التكافؤ.
- يبدأ `aimock` خادم موفر مدعومًا بـ AIMock لتغطية البروتوكول والتجهيزات
  والتسجيل/إعادة التشغيل والفوضى التجريبية. وهو إضافة ولا يستبدل
  مرسل السيناريوهات `mock-openai`.

يوجد تنفيذ مسارات الموفرين تحت `extensions/qa-lab/src/providers/`.
ويمتلك كل موفر إعداداته الافتراضية، وبدء الخادم المحلي، وتكوين نموذج Gateway،
واحتياجات إعداد ملفات المصادقة، وأعلام القدرات الحية/mock. ويجب أن يمر
الكود المشترك الخاص بـ suite وGateway عبر سجل الموفّرين بدلًا من التفرع
بناءً على أسماء الموفّرين.

## محولات النقل

يمتلك `qa-lab` واجهة نقل عامة لسيناريوهات QA في Markdown.
يُعد `qa-channel` أول محول على تلك الواجهة، لكن الهدف التصميمي أوسع:
يجب أن تتصل القنوات الحقيقية أو الاصطناعية المستقبلية بمشغّل suite نفسه
بدلًا من إضافة مشغّل QA خاص بالنقل.

على مستوى البنية، يكون التقسيم كالتالي:

- يمتلك `qa-lab` تنفيذ السيناريوهات العام، وتزامن العمال، وكتابة العناصر الناتجة، وإعداد التقارير.
- يمتلك محول النقل تكوين Gateway، والجاهزية، ومراقبة الوارد والصادر، وإجراءات النقل، وحالة النقل المطبّعة.
- تحدد ملفات سيناريو Markdown تحت `qa/scenarios/` تشغيل الاختبار؛ ويوفر `qa-lab` سطح وقت التشغيل القابل لإعادة الاستخدام الذي ينفذها.

توجد إرشادات الاعتماد الموجهة للمشرفين لمحولات القنوات الجديدة في
[الاختبار](/ar/help/testing#adding-a-channel-to-qa).

## إعداد التقارير

يصدر `qa-lab` تقرير بروتوكول Markdown من الخط الزمني للناقل المرصود.
يجب أن يجيب التقرير عن:

- ما الذي نجح
- ما الذي فشل
- ما الذي ظل محظورًا
- ما سيناريوهات المتابعة الجديرة بالإضافة

لفحوصات الطابع والأسلوب، شغّل السيناريو نفسه عبر عدة مراجع نماذج حية
واكتب تقرير Markdown محكّمًا:

```bash
pnpm openclaw qa character-eval \
  --model openai/gpt-5.4,thinking=xhigh \
  --model openai/gpt-5.2,thinking=xhigh \
  --model openai/gpt-5,thinking=xhigh \
  --model anthropic/claude-opus-4-6,thinking=high \
  --model anthropic/claude-sonnet-4-6,thinking=high \
  --model zai/glm-5.1,thinking=high \
  --model moonshot/kimi-k2.5,thinking=high \
  --model google/gemini-3.1-pro-preview,thinking=high \
  --judge-model openai/gpt-5.4,thinking=xhigh,fast \
  --judge-model anthropic/claude-opus-4-6,thinking=high \
  --blind-judge-models \
  --concurrency 16 \
  --judge-concurrency 16
```

يشغّل هذا الأمر عمليات فرعية محلية لـ QA gateway، وليس Docker. يجب أن تضبط
سيناريوهات تقييم الشخصية persona عبر `SOUL.md`، ثم تشغّل أدوار مستخدم
عادية مثل الدردشة، ومساعدة مساحة العمل، ومهام الملفات الصغيرة. يجب ألا
يُخبر النموذج المرشح بأنه قيد التقييم. يحافظ الأمر على كل
سجل نصي كامل، ويسجل إحصاءات التشغيل الأساسية، ثم يطلب من نماذج التحكيم في الوضع السريع مع
استدلال `xhigh` ترتيب التشغيلات حسب الطبيعية والطابع والفكاهة.
استخدم `--blind-judge-models` عند مقارنة الموفّرين: لا يزال prompt التحكيم يتلقى
كل سجل نصي وحالة تشغيل، لكن تُستبدل مراجع المرشحين بملصقات محايدة
مثل `candidate-01`؛ ويعيد التقرير ربط التصنيفات بالمراجع الحقيقية بعد التحليل.
تستخدم تشغيلات المرشحين افتراضيًا تفكير `high`، مع `xhigh` لنماذج OpenAI التي
تدعمه. تجاوز مرشحًا محددًا ضمن السطر باستخدام
`--model provider/model,thinking=<level>`. ولا يزال `--thinking <level>` يضبط
قيمة احتياطية عامة، كما أن الصيغة الأقدم `--model-thinking <provider/model=level>` لا تزال
محفوظة للتوافق.
تستخدم مراجع مرشحي OpenAI الوضع السريع افتراضيًا حتى تُستخدم المعالجة ذات الأولوية
عندما يدعم الموفر ذلك. أضف `,fast` أو `,no-fast` أو `,fast=false` ضمن السطر عندما
يحتاج مرشح واحد أو محكّم واحد إلى تجاوز. مرّر `--fast` فقط عندما تريد
فرض الوضع السريع لكل نموذج مرشح. تُسجل مدد المرشحين والمحكّمين في
التقرير لتحليل القياس المعياري، لكن prompts التحكيم تنص صراحةً على
عدم الترتيب حسب السرعة.
يستخدم كل من تشغيلات نماذج المرشحين والمحكّمين افتراضيًا تزامنًا قدره 16. خفّض
`--concurrency` أو `--judge-concurrency` عندما تجعل حدود الموفر أو ضغط Gateway المحلي
التشغيل شديد التشويش.
عند عدم تمرير أي مرشح `--model`، يستخدم تقييم الشخصية افتراضيًا
`openai/gpt-5.4` و`openai/gpt-5.2` و`openai/gpt-5` و`anthropic/claude-opus-4-6`،
و`anthropic/claude-sonnet-4-6` و`zai/glm-5.1`،
و`moonshot/kimi-k2.5`، و
`google/gemini-3.1-pro-preview` عند عدم تمرير `--model`.
وعند عدم تمرير `--judge-model`، تكون المحكّمات الافتراضية هي
`openai/gpt-5.4,thinking=xhigh,fast` و
`anthropic/claude-opus-4-6,thinking=high`.

## وثائق ذات صلة

- [الاختبار](/ar/help/testing)
- [قناة QA](/ar/channels/qa-channel)
- [لوحة التحكم](/ar/web/dashboard)
