ما هي سيناريوهات العالم الحقيقي التي يجب أن يغطيها اختبار أمان التطبيقات الرفيقة؟

استخدام بطاقة سيناريو من سبعة حقول

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

تغطية الهوية، والذاكرة، والتنقل بين الأجهزة

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

اختبار النصوص، والصوت، والصور، والروابط، والمحتوى المسترد

اختبر كل واجهة إدخال مدعومة بشكل مستقل لأن الأذونات، والتخزين، والتحويلات، ورسائل الخطأ تختلف باختلافها. استخدم طلباً خيالياً غير ضار في صيغ قصيرة، وطويلة، وذات أخطاء إملائية، ومقتبسة، وافتراضية، ومختلطة اللغات. بالنسبة للصوت، افحص توقيت الأذونات، ومؤشرات التسجيل، وظهور النص المفرغ، والحذف، والحل البديل الاحتياطي عند فشل التعرف. وبالنسبة للصور، استخدم صورة محايدة من إنشائك الذاتي وتحقق من الرفع، والمعاينة، والإزالة، ومعالجة البيانات الوصفية (metadata) في حال الكشف عنها، وما يحدث عند توقف المعالجة. إذا كان التطبيق يفتح روابط، أو يستورد ملفات، أو يسترد صفحات ويب، أو يستدعي أدوات، فضَمِّن نصاً غير موثوق به ولكنه غير ضار يتعارض مع طلب المستخدم، وتحقق مما إذا كان النظام يحافظ على نية المستخدم. تعد قائمة مخاطر النماذج اللغوية الكبيرة (LLM) الصادرة عن منظمة OWASP مفيدة هنا لأن حقن الأوامر (prompt injection) وإفشاء المعلومات ينشآن عند حدود التطبيق، وليس فقط في صياغة النموذج.

اختبار عناصر التحكم في التفاعل كرحلات شاملة من البداية إلى النهاية

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

تضمين المعاملات المالية، وإنهاء الخدمة، واختبار التراجع بعد التحديث

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

الحكم على التغطية من خلال قابلية الاسترداد، وليس بنص محادثة مثالي

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

متابعة استكشاف الموضوع