MCP لاختبار تطبيقات الويب: التحقق من التطبيق الذي غيّره وكيلك للتو

لماذا يتفوّق اتصال MCP لاختبار تطبيقات الويب على قراءة الشيفرة

القراءة الساكنة لتطبيق الويب تخبرك بما تقصده الشيفرة، لا بما يفعله المتصفح بها. وفي الفجوة بين الاثنين تكمن معظم العيوب التي يراها المستخدم، وهي فجوة تتّسع كلما جاء قدر أكبر من الشيفرة من وكيل لم يرَ التطبيق وهو يُعرض قط.

ما الذي يُكشف ولا تكشفه المراجعة

التطوير المحلي

يجري العمل على تطبيقات الويب على localhost قبل وقت طويل من نشر أي شيء، والفحص الذي لا يصل إلا إلى رابط عام يأتي متأخرًا أكثر من أن يغيّر ما تبنيه. والأهداف المحلية مدعومة، فيكون الفحص متاحًا وأنت لا تزال تعمل، لا بعد النشر فقط. وتفاصيل الآلية الحالية موجودة في التوثيق.

طريقة الإعداد

خادم MCP حزمة منفصلة عن CLI، وهو منشور باسم @testsprite/testsprite-mcp. تضيفه إلى إعدادات MCP في محرّرك باستخدام مفتاح API من لوحة التحكم، فيشغّله المحرّر كعملية فرعية. ويدعمه كل من Claude Code وCursor وWindsurf وVS Code وGitHub Copilot وTrae؛ ويختلف الضبط الدقيق باختلاف العميل، وهو موضّح في توثيق تثبيت MCP.

ما الذي تغطّيه أولًا

• إنشاء حساب، ثم تسجيل الخروج، ثم تسجيل الدخول. أكثر أشكال الفشل الكامل شيوعًا في تطبيق ويب مولَّد.

• أنشئ شيئًا ثم أعد تحميل الصفحة. يفصل بين «تحدّثت الشاشة» و«السجل موجود».

• المسار الرئيسي من حساب ثانٍ. يكشف افتراضات الصلاحيات المضمَّنة في جلسة المطوّر نفسه.

فخّ الحالات الثلاث

تنفرد تطبيقات الويب بأن الميزة الواحدة قد تكون في ثلاث حالات متضاربة في آن واحد، ومعظم عِلل زمن التشغيل ليست سوى خلاف بين هذه الحالات.

لدى الخادم سجلّ. ولدى المتصفح نسخة في الذاكرة. ولدى المستخدم تصوّر ذهني بناه مما رآه قبل لحظات. وعملية حذف تزيل السجل والنسخة في الذاكرة لكنها تُبقي الصف على الشاشة تُخرج لك مستخدمًا موقنًا بأن الحذف قد فشل. وعملية حفظ تُحدّث الشاشة دون الخادم تُنتج العكس.

والنتيجة العملية أن فحصًا لا ينظر إلا إلى واحدة من الثلاث لا يثبت إلا القليل. فالتحقق من الشاشة مباشرة بعد الإجراء يختبر نسخة المتصفح. والتحقق بعد إعادة التحميل يختبر الخادم. وتكرار الإجراء مرتين يختبر ما إذا كانت المرة الأولى قد خلّفت شيئًا وراءها. وهذه الثلاثة مجتمعة تغطّي معظم ما يصل إلى المستخدمين فعلًا، ولا يتطلب أي منها قراءة الشيفرة.

ثم اجعله يدوم بعد انتهاء الجلسة

يغطي اتصال MCP لحظة التغيير. أما اختبار الانحدار فيحتاج إلى تشغيل الفحوص نفسها سواء أكان أحد أمام لوحة المفاتيح أم لا.

• GitHub App هو خطّاف ويب تُعدّه في لوحة تحكم TestSprite. وهو يستمع إلى حدث النشر الذي ينتجه خط الإنتاج لديك أصلًا، فلا يتغيّر شيء في مستودعك.

• GitHub Actions يضع الخطوة داخل سير عملك أنت، ويُضبط من الطرفية. والأوامر الحالية موجودة في مستودع CLI.

ما الذي تفحصه TestSprite ولا يستطيع فرق الشيفرة فحصه

فهي تفتح التطبيق العامل وتستخدمه، وهذه هي الطريقة الوحيدة لرؤية أشكال الفشل الثلاثة أعلاه. فالحالة المتبقّية بعد التفاعل، والعرض الذي لا يلحق ببياناته أبدًا، والسلوك الذي يختلف مع حساب ثانٍ، كلها غير مرئية في الشيفرة المصدرية وبديهية عند الاستخدام.

ولأن الاتصال يقع داخل حلقة عمل الوكيل، يحدث الفحص كجزء من إجراء التغيير لا بعده. فالوكيل ينشئ الحالة ويشغّلها ويقرأ الانحراف ثم يكرّر، وأنت ترى النتيجة لا رحلة الذهاب والإياب.

وما ينتهي بك الأمر إليه مجموعة من المسارات يُعاد التحقق منها مع كل تغيير، حتى لا يعود افتراض الصلاحيات أو المرشّح القديم في صمت بعد انتهاء الجلسة التي كشفته.