---
read_when:
    - توسيع qa-lab أو qa-channel
    - إضافة سيناريوهات QA مدعومة من المستودع
    - بناء أتمتة QA بدرجة واقعية أعلى حول لوحة معلومات Gateway
summary: شكل أتمتة QA الخاص لـ qa-lab وqa-channel والسيناريوهات المُهيأة مسبقًا وتقارير البروتوكول
title: أتمتة QA الشاملة من البداية إلى النهاية
x-i18n:
    generated_at: "2026-04-20T07:29:35Z"
    model: gpt-5.4
    provider: openai
    source_hash: 34245ce871356caeab0d9e0eeeaa9fb4e408920a4a97ad27567fa365d8db17c7
    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 مركّبة عبر 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 على صورة مبنية مسبقًا ويستخدم bind mount
لـ `extensions/qa-lab/web/dist` داخل حاوية `qa-lab`. ويعيد `qa:lab:watch`
بناء تلك الحزمة عند التغيير، ويُعاد تحميل المتصفح تلقائيًا عندما تتغير
بصمة أصول QA Lab.

لتشغيل مسار اختبار 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>` إلى ملف سجل محلي في المستودع.

لتشغيل مسار اختبار 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`
عندما تريد العناصر الناتجة من دون رمز خروج فاشل.

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

يبقى `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`
لتتبّع التنفيذ.

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

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

## مسارات مزوّدات المحاكاة

يحتوي `qa suite` على مسارين محليين لمزوّدات المحاكاة:

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

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

## مهايئات النقل

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

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