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

# أتمتة QA من طرف إلى طرف

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

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

- `extensions/qa-channel`: قناة رسائل اصطناعية بواجهات للرسائل الخاصة DM، والقنوات، والخيوط، والتفاعلات، والتحرير، والحذف.
- `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 مربوطة بالتحميل:

```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`. ويعيد `qa:lab:watch` بناء تلك الحزمة عند التغيير، ويُعاد تحميل المتصفح تلقائيًا عندما يتغير تجزئة أصول QA Lab.

لتشغيل مسار Matrix اختباري يعتمد نقلًا حقيقيًا، شغّل:

```bash
pnpm openclaw qa matrix
```

يوفّر هذا المسار خادم Tuwunel منزليًا مؤقتًا في Docker، ويسجل مستخدمين مؤقتين للسائق وSUT والمراقب، وينشئ غرفة خاصة واحدة، ثم يشغّل Plugin Matrix الحقيقي داخل child خاص بـ QA gateway. ويحافظ مسار النقل الحي على إعدادات child محصورة ضمن النقل قيد الاختبار، لذلك يعمل Matrix من دون `qa-channel` في إعدادات child.

لتشغيل مسار 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`.

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

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

| المسار | Canary | بوابة الإشارات Mention | حظر قائمة السماح | رد على المستوى الأعلى | استئناف بعد إعادة التشغيل | متابعة الخيط | عزل الخيط | مراقبة التفاعلات | أمر Help |
| ------- | ------ | ---------------------- | ----------------- | ---------------------- | -------------------------- | ------------ | ---------- | ---------------- | -------- |
| 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 معزولين افتراضيًا، حتى 64 عاملًا أو عدد السيناريوهات المحددة. استخدم `--concurrency <count>` لضبط عدد العمال، أو `--concurrency 1` للتنفيذ التسلسلي.
تعيد عمليات التشغيل الحية تمرير مدخلات مصادقة QA المدعومة والعملية للضيف: مفاتيح المزوّد المعتمدة على env، ومسار إعدادات موفّر QA الحي، و`CODEX_HOME` عند وجوده. أبقِ `--output-dir` تحت جذر المستودع حتى يتمكن الضيف من الكتابة مرة أخرى عبر مساحة العمل المركّبة.

## البذور المدعومة من المستودع

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

- `qa/scenarios/index.md`
- `qa/scenarios/*.md`

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

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

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

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

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

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

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

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

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

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

توجد إرشادات الاعتماد الخاصة بالمشرفين لمحولات القنوات الجديدة في
[Testing](/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
```

يشغّل هذا الأمر عمليات child محلية لـ QA gateway، وليس Docker. يجب أن تضبط سيناريوهات تقييم الطابع الشخصية عبر `SOUL.md`، ثم تشغّل أدوار مستخدم عادية مثل الدردشة، والمساعدة في مساحة العمل، ومهام الملفات الصغيرة. يجب ألا يُخبَر النموذج المرشح بأنه قيد التقييم. يحتفظ الأمر بكل نص حواري كامل، ويسجّل إحصاءات تشغيل أساسية، ثم يطلب من نماذج التحكيم في وضع fast مع استدلال `xhigh` ترتيب التشغيلات بحسب الطبيعية والأجواء والفكاهة.
استخدم `--blind-judge-models` عند المقارنة بين المزوّدين: ستظل مطالبة التحكيم تتلقى كل نص حواري وحالة تشغيل، لكن تُستبدل مراجع المرشحين بتسميات محايدة مثل `candidate-01`؛ ويعيد التقرير ربط التصنيفات بالمراجع الحقيقية بعد التحليل.
تستخدم تشغيلات المرشحين افتراضيًا مستوى تفكير `high`، مع `xhigh` لنماذج OpenAI التي تدعمه. يمكنك تجاوز مرشح محدد مباشرةً باستخدام
`--model provider/model,thinking=<level>`. وما يزال `--thinking <level>` يضبط قيمة احتياطية عامة، كما جرى الإبقاء على الصيغة الأقدم `--model-thinking <provider/model=level>` للتوافق.
تستخدم مراجع المرشحين من OpenAI وضع fast افتراضيًا حتى تُستخدم المعالجة ذات الأولوية حيث يدعمها المزوّد. أضف `,fast` أو `,no-fast` أو `,fast=false` مباشرةً عندما يحتاج مرشح واحد أو حكم واحد إلى تجاوز. مرّر `--fast` فقط عندما تريد فرض وضع fast على كل نموذج مرشح. تُسجَّل مدد المرشحين والحكام في التقرير لتحليل المقاييس، لكن مطالبات التحكيم تنص صراحةً على عدم الترتيب بحسب السرعة.
تستخدم كل من تشغيلات نماذج المرشحين والحكام توازيًا افتراضيًا مقداره 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`.

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

- [Testing](/ar/help/testing)
- [QA Channel](/ar/channels/qa-channel)
- [Dashboard](/web/dashboard)
