الاختبار الساكن

ما هو الاختبار الساكن — أبعد من «عدم تشغيل الكود»

يخصص منهج ISTQB للمستوى التأسيسي (CTFL v4.0) فصله الثالث للاختبار الساكن ويقسمه إلى عائلتين: المراجعات (Reviews)، وفيها يفحص أشخاص أحد مخرجات العمل، والتحليل الساكن (Static analysis)، وفيه تقيّم الأدوات ذلك المُخرَج وفق قواعد رسمية. وللعائلتين الأهداف نفسها: اكتشاف العيوب مباشرةً في مُخرَج العمل، وتقييم جودته وبناء الثقة به، وإيجاد فهم مشترك بين من كتبوه ومن سيبنون ويختبرون ويشغّلون استناداً إليه.

أهم تمييز هنا هو الفرق بين العيب (Defect) والإخفاق (Failure). العيب خلل في مُخرَج العمل — جملة متناقضة، أو قيمة null غير معالجة، أو استجابة خطأ مفقودة في عقد API. أما الإخفاق فهو ما يفعله النظام خطأً أثناء التشغيل بسبب عيب. يرصد الاختبار الديناميكي الإخفاقات، ثم يتتبع أحدهم العيب بالتنقيح (Debugging) رجوعاً. أما الاختبار الساكن فيصل إلى العيب مباشرةً، وغالباً بموقعه الدقيق. لذلك يكون إصلاح ما يكتشفه الاختبار الساكن أرخص عادةً: لا شيء يُعاد إنتاجه، ولا شيء يُشخَّص، وكثيراً لا يوجد كود يُعاد كتابته بعد.

كل ما يستطيع الإنسان قراءته وفهمه يمكن مراجعته، حتى الوثائق التي لن تُشغَّل أبداً؛ وكل ما له بنية رسمية — كود أو مخطط بيانات (Schema) أو نموذج أو ملف إعدادات — يمكن أيضاً تحليله بأداة.

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

الاختبار الساكن مقابل الاختبار الديناميكي

النوعان متكاملان لا بديلان. تنطلق الفروق أدناه من المقارنة الواردة في منهج ISTQB؛ ومعظم الفرق تحتاج إلى الاثنين في كل مستوى اختبار.

• ما الذي يكتشفه — الساكن: العيوب مباشرةً في مُخرَج العمل. الديناميكي (Dynamic testing): الإخفاقات، ومنها تُتتبَّع العيوب بالتنقيح.
• متى يمكن أن يبدأ — الساكن: بمجرد وجود مُخرَج عمل، حتى قبل أي كود. الديناميكي: عند وجود شيء قابل للتشغيل.
• ما الذي يمكنه فحصه — الساكن: المخرجات القابلة للتشغيل وغير القابلة (المتطلبات والتصاميم وخطط الاختبار والعقود). الديناميكي: البرنامج أثناء تشغيله فقط.
• خصائص الجودة — الساكن: الخصائص التي لا تعتمد على التشغيل مثل قابلية الصيانة والاتساق والالتزام بالمعايير. الديناميكي: الخصائص التي تعتمد عليه مثل كفاءة الأداء والموثوقية تحت الحمل وسلوك التكامل الحقيقي.
• العيوب الأسهل اكتشافاً — الساكن: المتطلبات الغامضة أو المتناقضة، والكود غير القابل للوصول أو المكرر، والمتغيرات غير المعرّفة أو غير المهيأة، وعدم تطابق معاملات الواجهات، والانحراف عن معايير الكتابة، وبعض نقاط الضعف الأمنية، ومعايير القبول التي لا يغطيها أي اختبار. الديناميكي: المخرجات الخاطئة لبيانات معينة، وإخفاقات التوقيت والتزامن، ومشكلات البيئة والإعدادات، ومشكلات قابلية الاستخدام.
• كلفة الاكتشاف — الساكن: أقل عادةً، لأن الموقع معروف وما بُني فوق العيب أقل. الديناميكي: أعلى، لأنها تشمل إعادة الإنتاج والتشخيص وإعادة العمل على ما بُني فوق العيب.

ما الذي يمكن اختباره ساكناً، وما الذي يكتشفه عادةً

مثال: تقول قصة مستخدم «يُطبَّق الخصم على الطلبات التي تزيد على 500 ريال». يسأل المراجع: هل يستحق الطلب الذي قيمته 500.00 ريال بالضبط الخصم؟ هذا اكتشاف ساكن في جملة واحدة، قبل أي كود. وإن لم يسأل أحد، يختار المطور «أكبر من» أو «أكبر من أو يساوي»، وقد يكشف اختبار القيم الحدّية بعد أسابيع أن اختياره يخالف ما توقعته الإدارة المالية. العيب نفسه، اكتُشف في موضعين، بكلفتين مختلفتين جداً. وتبيّن القائمة أدناه ما يخفيه كل نوع من المخرجات عادةً.

• المتطلبات وقصص المستخدم — الغموض، والتناقضات، والإغفالات (مسارات الخطأ والصلاحيات والحدود)، والعبارات غير القابلة للاختبار، وقواعد العمل المكررة أو المتعارضة.
• المعمارية والتصميم — ضعف التقسيم إلى وحدات، ونقاط الإخفاق المنفردة، وهياكل البيانات أو تصميم قاعدة البيانات غير الكفء، وغياب معالجة الأخطاء بين المكونات، وعدم وضوح ملكية البيانات.
• عقود API ومخططات البيانات — التسمية غير المتسقة، واستجابات الخطأ المفقودة، والأنواع التي تناقض أمثلتها، والتغييرات الكاسرة بين الإصدارات، والحقول بلا قيود.
• الكود المصدري — المتغيرات غير المعرّفة أو غير المستخدمة، والكود غير القابل للوصول أو المكرر، والتعقيد المفرط، والاستدعاءات غير الآمنة، وبناء الاستعلامات من مدخلات المستخدم، ومخالفة معايير الكتابة.
• الإعدادات والبنية التحتية ككود (Infrastructure as code) — أسرار محفوظة كنص صريح، وقيم افتراضية غير آمنة، وقيم خاطئة لبيئة ما، وYAML غير صالح، وجدول cron لا يعمل أبداً.
• وثائق الاختبار — خطة اختبار بلا معايير خروج، وحالات اختبار بنتائج متوقعة مبهمة، ومعايير قبول بلا أي اختبار، وحالات مكررة أو متقادمة.

جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي جرّبها: محلّل مخاطر عقود API بالذكاء الاصطناعي

الاكتشاف المبكر للعيوب ومنع العيوب

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

الاكتشاف المبكر ومنع العيوب (Defect prevention) مترابطان لكنهما مختلفان. الاكتشاف يجد هذا العيب أسرع؛ والمنع يوقف العيب التالي قبل أن يُرتكب. وتسهم المراجعات في المنع بطريقتين: الأشخاص يتعلمون — فالمطور الذي تتكرر على تغييراته ملاحظة «المدخلات غير متحقق منها» يبدأ بالتحقق منها — والملاحظات تعود إلى العملية بنوداً في قوائم التحقق وقوالب وقواعد كتابة وقواعد linter. ونوع العيب الذي يظهر في عدة مراجعات مرشّح لفحص آلي، كي لا يضطر أي إنسان للبحث عنه مجدداً.

• صنّف ملاحظات المراجعة حسب النوع — غموض، أو غياب معالجة الأخطاء، أو تسمية، أو أمان، أو فجوة اختبار. الأعداد تبيّن من أين تأتي العيوب.
• أصلح القالب لا الوثيقة وحدها: قالب قصة مستخدم فيه عنوان «حالات الخطأ» يزيل فئة كاملة من الإغفالات.
• أشرك المختبرين في جلسات تنقيح القصص. سؤال «كيف سأختبر هذا؟» هو في حد ذاته اختبار ساكن.

المراجعات: الجانب البشري من الاختبار الساكن

المراجعة فحص منظّم لمُخرَج عمل يجريه أشخاص غير مؤلفه أو إضافةً إليه. وتتدرج المراجعات من زميل يقرأ طلب دمج (Pull request) إلى تفتيش رسمي بأدوار مدرَّبة ومعايير دخول ومقاييس تُجمع. يصف CTFL v4.0 أربعة أنواع على هذا المقياس من الرسمية: المراجعة غير الرسمية (Informal review)، والجولة التفقدية (Walkthrough)، والمراجعة الفنية (Technical review)، والتفتيش (Inspection). ويعرّف معيار IEEE 1028-2008 لمراجعات البرمجيات وتدقيقها (المدرج لدى IEEE حالياً كمعيار غير نشط محفوظ) إضافةً إليها مراجعات الإدارة (Management reviews) والتدقيق (Audits)، وهما يقيّمان التقدم والامتثال لا المحتوى الفني للمُخرَج. ويصف المعيار ISO/IEC 20246 إطاراً عاماً لمراجعة مخرجات العمل.

تستند المراجعات إلى عملية عامة واحدة — التخطيط، وبدء المراجعة، والمراجعة الفردية، والتواصل والتحليل، والإصلاح والتقرير — وكلما زادت رسمية المراجعة نُفّذ منها قدر أكبر؛ أما المراجعة غير الرسمية فلا تتبع عملية محددة. والأدوار الرئيسية هي: المدير، والمؤلف، والميسّر (Moderator)، والمدوّن (Scribe)، والمراجع، وقائد المراجعة. وتقارن صفحة أنواع مراجعات البرمجيات بين الأنواع الأربعة من حيث الغرض والرسمية والقائد والأدوار والتوثيق والمقاييس، وتشرح العملية والأدوار وعوامل النجاح بالتفصيل.

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

مراجعات المتطلبات والتصميم والكود ووثائق الاختبار

نوع المراجعة يصف مدى رسميتها؛ أما مُخرَج العمل فيحدد ما يبحث عنه المراجعون. قد يجري الفريق نفسه جولة تفقدية على تصميم، ومراجعة غير رسمية لمعظم تغييرات الكود، وتفتيشاً على قواعد الدفع.

• مراجعات المتطلبات — تفحص الغموض والاكتمال والاتساق والصحة وقابلية الاختبار وقابلية التنفيذ وقابلية التتبع والاحتياجات غير الوظيفية، ويفضَّل أن يشارك فيها المنتج والتطوير والاختبار معاً. هنا يؤتي الاختبار الساكن أكبر ثماره عادةً، ولها صفحة خاصة بقائمة تحقق ومثال عملي.
• مراجعات التصميم — تتحقق من أن التصميم يلبي المتطلبات بما فيها غير الوظيفية: كيف ينتقل الإخفاق بين الخدمات، وأين تعيش البيانات ومن يملكها، وماذا يحدث تحت ذروة الحمل، وكيف سيُختبر النظام ويُراقَب. اسأل عن كل سهم في المخطط: «ماذا يحدث إن كانت هذه التبعية بطيئة أو غير متاحة؟».
• مراجعات الكود (Code review) — تفحص الصحة والاختبارات وقابلية القراءة والأمان والاتساق مع قاعدة الكود. ويضع دليل Google المنشور لمراجعة الكود معياراً عملياً: وافق على التغيير متى حسّن بوضوح الصحة العامة للكود حتى لو لم يكن مثالياً، وميّز الملاحظات الاختيارية (مثلاً بالبادئة «Nit:») كي يعرف المؤلف ما الذي يمنع الدمج. ودع الأدوات تفرض التنسيق والأسلوب لتتجه عناية البشر إلى المنطق والتصميم والاختبارات.
• مراجعات خطة الاختبار — تفحص النطاق وما هو خارجه صراحةً، والمخاطر التي تعالجها الخطة، والنهج في كل مستوى اختبار، ومعايير الدخول والخروج، والبيئات والبيانات، والمسؤوليات والجدول الزمني. الخطة التي بلا معايير خروج لا تستطيع أن تخبر أحداً متى ينتهي الاختبار.
• مراجعات حالات الاختبار — تتحقق من أن كل حالة ترتبط بمتطلب أو معيار قبول، وتذكر شروطها المسبقة وبياناتها، ولها نتيجة متوقعة قابلة للملاحظة، وأن المجموعة تغطي الحالات السلبية والحدّية دون تكرار. أما تشريح حالة الاختبار الجيدة فيشرحه دليل كتابة حالات الاختبار.

جرّبها: مراجع معايير القبول بالذكاء الاصطناعي جرّبها: محسّن حالات الاختبار بالذكاء الاصطناعي جرّبها: كاشف حالات الاختبار المكرّرة بالذكاء الاصطناعي جرّبها: محلّل تغطية الاختبار بالذكاء الاصطناعي

التحليل الساكن: أصناف الأدوات وما تفحصه

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

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

• أدوات linter وفحص الأسلوب — تنبّه إلى البنى المريبة ومخالفات الأعراف: متغيرات غير مستخدمة، وكود غير قابل للوصول، وأسماء محجوبة، وawait مفقود، وتنسيق غير متسق. أمثلة: ESLint (JavaScript وTypeScript)، وPylint وRuff (Python)، وCheckstyle (Java)، وRuboCop (Ruby)، وShellCheck (سكربتات shell)، وSQLFluff (SQL).
• مدققات الأنواع والمترجمات (Type checkers) — تتحقق من استخدام القيم بما يتسق مع أنواعها المعلنة، فتلتقط فئات كاملة من أخطاء null والأنواع قبل التشغيل. أمثلة: مترجم TypeScript، وmypy للغة Python، ومترجمات اللغات ذات الأنواع الساكنة مثل Java وC# وGo وRust.
• الاختبار الأمني الساكن للتطبيقات (SAST) — يتتبع البيانات من المصادر غير الموثوقة إلى المواضع الخطرة ويطابق أنماط الضعف المعروفة: حقن SQL، والبرمجة عبر المواقع (XSS)، واجتياز المسارات، والأسرار المكتوبة في الكود، والتشفير الضعيف. أمثلة: Semgrep وCodeQL وSonarQube وSpotBugs مع إضافات الأمان. وتنشر OWASP إرشادات حول ما تستطيعه أدوات تحليل الكود المصدري وما لا تستطيعه، ويحتفظ برنامج SAMATE التابع لـ NIST بمجموعات اختبار لتقييمها.
• التحقق من مخططات البيانات والمواصفات — يتحقق من صلاحية المخرجات المنظمة وفق مواصفاتها: JSON مقابل JSON Schema، ووثيقة OpenAPI مقابل مواصفة OpenAPI، وسلامة بنية XML، وصياغة YAML وcron. وتضيف أدوات فحص OpenAPI مثل Spectral قواعد اتساق وأسلوب فوق الصلاحية البنيوية.
• مقاييس التعقيد وقابلية الصيانة — التعقيد الدوري (Cyclomatic complexity)، وطول الدوال، والتكرار، والاقتران؛ وهي توجّه المراجعين إلى الكود الصعب اختباره وتغييره.
• ماسحات التبعيات والأسرار والبنية التحتية — تفحص التبعيات المعلنة مقابل قواعد بيانات الثغرات، وتبحث في الـ commits عن بيانات الاعتماد، وتفحص ملفات البنية التحتية ككود والحاويات بحثاً عن إعدادات غير آمنة. أمثلة: npm audit وpip-audit، وOWASP Dependency-Check، وgitleaks، وhadolint، وCheckov.

# Illustrative findings from three kinds of static analysis
src/checkout/discount.ts:41:18  error  "rate" is possibly "undefined".              TS18048 (type checker)
src/checkout/discount.ts:57:3   error  Unreachable code.                              no-unreachable (linter)
src/orders/search.ts:22:9       error  SQL query built by concatenating request
                                       parameter "q"; use a parameterised query.   sql-injection (SAST)
openapi.yaml  paths./orders/{id}.get.responses
                                warn   Operation defines no 4xx response.           (contract linter)

جرّبها: مدقّق OpenAPI جرّبها: مدقّق JSON Schema جرّبها: مدقّق استعلامات SQL جرّبها: منسّق YAML

ما الذي لا يستطيع التحليل الساكن اكتشافه

التقرير النظيف من التحليل الساكن يعني أن المُخرَج اجتاز القواعد التي كتبها أحدهم. ولا يقول شيئاً عن كون البرنامج يفعل ما يحتاجه مستخدموه.

وكل أداة ترتكب نوعين من الخطأ. الإيجابيات الكاذبة (False positives) — تحذيرات عن كود سليم — تآكل الثقة حتى يتوقف الناس عن قراءة التقرير؛ والسلبيات الكاذبة (False negatives) — عيوب تفوت الأداة — تخلق ثقة زائفة. ومن النتائج الكلاسيكية في نظرية الحوسبة أنه لا توجد أداة تحليل تستطيع الحسم في كل خاصية سلوكية غير بديهية لأي برنامج كان، لذا توازن كل أداة بين نوعي الخطأ. تعامل مع التحليل الساكن كمرشِّح سريع يسبق المراجعات والاختبارات الديناميكية، لا كحكم نهائي.

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

الاختبار الساكن في خط CI/CD

الفحوص الساكنة أرخص مراحل خط التسليم، لذلك تعمل أولاً ومع كل تغيير.

• في المحرر وفي خطافات ما قبل الـ commit (Pre-commit hooks) — تعطي أدوات التنسيق وlinter وفحص الأنواع ملاحظاتها قبل أن يوجد الـ commit أصلاً.
• مع كل طلب دمج — linter وفحص الأنواع وSAST والتحقق من المخططات والعقود ومسح الأسرار، مع عرض النتائج مباشرةً على الفروق (Diff) كي يراها المراجع البشري.
• كبوابة جودة (Quality gate) — المخالفات الجديدة فوق خطورة متفق عليها تمنع الدمج؛ أما المخالفات القائمة في الكود القديم فتُسجَّل كخط أساس (Baseline) وتُسدَّد تدريجياً بدلاً من إيقاف الجميع من اليوم الأول.
• فحوص المواصفات — تحقق من ملفات OpenAPI وJSON Schema والإعدادات في خط التسليم نفسه الذي يبني الكود المعتمد عليها، كي يُفشل العقدُ المكسور البناءَ الذي أدخله.

# Illustrative stage order (commands are examples, not requirements)
stages:
  static-checks:
    - format-check        # formatter in check mode
    - lint                # e.g. eslint . --max-warnings=0
    - typecheck           # e.g. tsc --noEmit
    - validate-contracts  # OpenAPI and JSON Schema files
    - sast                # security rules on changed code
    - secret-scan
  unit-tests:          { needs: static-checks }
  integration-tests:   { needs: unit-tests }

خطة عملية للبدء

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

جرّبها: محلّل فجوات المتطلبات بالذكاء الاصطناعي جرّبها: مراجع معايير القبول بالذكاء الاصطناعي

الأسئلة الشائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsISO/IEC · 2017إطار عام لمراجعة مخرجات العمل — عملية المراجعة وأدوارها وتقنياتها.
• IEEE 1028-2008 — IEEE Standard for Software Reviews and AuditsIEEE Standards Association · 2008التعريفات الكلاسيكية لمراجعات الإدارة والمراجعات الفنية والتفتيش والجولات التفقدية والتدقيق (مدرج لدى IEEE كمعيار غير نشط محفوظ).
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Source Code Analysis ToolsOWASP Foundationما الذي تفعله أدوات الاختبار الأمني الساكن للتطبيقات (SAST)، ونقاط قوتها وضعفها، وكيف تُختار.
• Software Assurance Metrics And Tool Evaluation (SAMATE)NISTبرنامج NIST لتقييم أدوات ضمان البرمجيات، ومنها أدوات التحليل الساكن، ومجموعات الاختبار المستخدمة لقياسها.
• Code Review Developer GuideGoogle (eng-practices)ممارسات Google المنشورة لمراجعة الكود: ما الذي يبحث عنه المراجعون، ومعيار الموافقة على التغيير، وكيفية كتابة تعليقات المراجعة.