API Testing موضوع كبير! راح يكون عنا قسم كامل عنه لاحقاً في الكورس.
هسا لكن بدنا نفهم إنه في طريقة أسرع من الـ UI!
3. من خلال الـ Database
الطريقة الأكيدة - نتحقق من البيانات مباشرة بالـ Database!
كيف تشتغل؟
بنتصل بالـ Database مباشرة
نفعل SQL Queries حتى نشوف البيانات
نتأكد إنه البيانات انحفظت صح مش فقط "ظاهرة صح"
ليش نحتاج Database Testing؟
أحياناً الـ UI يقول "Success!" لكن البيانات ما انحفظت فعلياً! 😱
مثال 1: تسجيل مستخدم جديد
على الـ UI:
بنملي الـ Form (Name, Email, Password)
نضغط "Register"
الموقع يقول: "Registration Successful!" ✅
لكن هل فعلاً انحفظ؟
على الـ Database:
SELECT * FROM users WHERE email = 'ahmad@example.com';
نتأكد إنه:
الـ User موجود في الـ Database ✅
الـ Name صحيح ✅
الـ Email صحيح ✅
الـ Password متشفر (Hashed) ✅
الـ Created Date صحيح ✅
مثال 2: Amazon - Order
على الـ UI:
بنشتري منتج
الموقع يقول: "Order Placed!" ✅
على الـ Database:
SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 1;
نتأكد إنه:
الـ Order موجود ✅
الـ Total Price صحيح ✅
الـ Items موجودة (iPhone, Quantity: 1) ✅
الـ Shipping Address صحيح ✅
الـ Status = "Pending" ✅
تحذير
مهم جداً: لا تثق بالـ UI بنفسه! أحياناً الـ UI بيكذب! 😅
دايماً تحقق من الـ Database حتى تكون 100% متأكد.
مقارنة بين الطرق الثلاثة
الطريقة
السرعة
الدقة
متى نستخدمها؟
UI
بطيئة 🐌
تختبر تجربة المستخدم
عندما بدنا نتأكد من الـ User Experience
API
سريعة ⚡
تختبر الـ Backend Logic
عندما بدنا نختبر بسرعة ونركز على الـ Business Logic
Database
سريعة ⚡
الأدق - الحقيقة المطلقة 💯
عندما بدنا نتأكد 100% إنه البيانات انحفظت صح
نصيحة
الأفضل: نستخدم الطرق الثلاثة مع بعض!
- UI ← للتأكد من تجربة المستخدم
- API ← للسرعة والتفاصيل التقنية
- Database ← للتأكد من البيانات الفعلية
كل طريقة تكشف مشاكل مختلفة!
ما الأشياء التي نختبرها؟
الآن نعرف من وين نختبر (UI, API, Database)، خلينا نحكي عن شو نختبر!
1. User Roles (صلاحيات المستخدمين)
الأنظمة عادةً فيها أنواع مختلفة من المستخدمين، وكل نوع إله صلاحيات مختلفة.
مثال 1: Instagram
Admin:
يستطيع يحذف أي Post (حتى لو مش تبعه) 🗑️
يستطيع يمنع (Ban) أي User 🚫
يرى Statistics لكل التطبيق 📊
User عادي:
يستطيع يحذف لكن Posts تبعه 🗑️
لا يستطيع يمنع حد 🚫
يرى لكن Statistics تبعته 📊
اختبارنا:
Admin يستطيع يحذف post لمستخدم ثاني؟ ✅
User عادي لا يستطيع يحذف post لمستخدم ثاني؟ ✅
User عادي لو حاول، يطلعله Error Message مناسب؟ ✅
مثال 2: Netflix
Free User:
يرى لكن SD (480p) 📺
يرى إعلانات 📢
يستطيع يشغل على جهاز واحد لكن 📱
Premium User:
يرى 4K (2160p) 🎬
بدون إعلانات 🚫
يستطيع يشغل على 4 أجهزة بنفس الوقت 📱📱📱📱
اختبارنا:
Premium User يرى 4K فعلاً؟ ✅
Free User لا يشوف 4K؟ ✅
Free User لو حاول يشغل على جهازين، يطلعله Error؟ ✅
تحذير
خطأ شائع: كثير Testers يختبروا لكن User عادي وينسوا الـ Roles الثانية!
لازم نختبر كل User Role!
2. Error Messages (رسائل الخطأ)
مش فقط نختبر الـ Happy Path! (يعني عندما كل شي صح)
لازم أيضاً نختبر Unhappy Paths - عندما المستخدم يفعل غلط أو في مشكلة!
Error Messages الصحيحة مقابل السيئة
سيئة ❌:
"Error"
"Something went wrong"
"Error 500"
"Failed"
جيدة ✅:
"Password must be at least 8 characters"
"Email already exists. Please use a different email or login."
"Credit card declined. Please check your card details."
"Username can only contain letters and numbers"
مثال 1: Amazon - Login
السيناريو: المستخدم يدخل Password غلط
رسالة سيئة ❌:
Login failed
رسالة جيدة ✅:
Incorrect email or password. Please try again.
مثال 2: Facebook - Registration
السيناريو: المستخدم يسجل بإيميل موجود مسبقاً
رسالة سيئة ❌:
Error
رسالة جيدة ✅:
This email is already registered. Please login or use a different email.
نصيحة
رسالة الخطأ الجيدة:
1. توضح ما المشكلة بوضوح 📝
2. تساعد المستخدم يحل المشكلة 🛠️
3. مش مخيفة أو تقنية زيادة 😊
تذكر: المستخدم مش مطور! لازم يفهم ما الغلط!
3. System Integration (التكامل مع أنظمة أخرى)
التطبيق مش بنفسه! يتكلم مع أنظمة ثانية كثيرة.
لازم نتأكد إنه التكامل شغال صح!
مثال 1: Amazon - Payment Gateway
Amazon يتكلم مع:
Visa / Mastercard 💳
PayPal 💰
Apple Pay 🍎
Google Pay 📱
اختباراتنا:
عندما المستخدم يدفع بـ Visa، الدفع يمشي؟ ✅
عندما الـ Card مرفوض، Amazon يستقبل Response صحيح؟ ✅
الـ Error Message واضح للمستخدم؟ ✅
المبلغ الذي راح لـ Visa هو نفسه اللي في Amazon؟ ✅
مثال 2: Uber - Google Maps
Uber يتكلم مع:
Google Maps (للموقع والخريطة) 🗺️
Payment Gateways (للدفع) 💳
SMS Gateway (لإرسال كود التحقق) 📱
اختباراتنا:
عندما نطلب Uber، الخريطة تظهر صح؟ ✅
الـ Driver Location يتحدث real-time؟ ✅
لو Google Maps عطلان، في Fallback plan؟ ✅
مثال 3: أي تطبيق - Email Service
التطبيقات تبعث Emails:
Welcome Email عند التسجيل 📧
Reset Password Email 🔐
Order Confirmation Email 📦
اختباراتنا:
الـ Email يوصل فعلاً؟ ✅
المحتوى صحيح (اسم المستخدم، Order Details)؟ ✅
الـ Links بالإيميل شغالة (Reset Password link)؟ ✅
الإيميل ما راح على Spam؟ ✅
Integration Testing يكشف مشاكل كثيرة لا تظهر عندما نختبر التطبيق بنفسه!
النظام ممكن يكون شغال 100%، لكن التكامل مع الأنظمة الثانية مش شغال!
مثال عملي شامل: Amazon Order
خلينا ناخذ مثال كامل ونطبق كل لا تعلمناه!
السيناريو: مستخدم بيشتري iPhone من Amazon
1. اختبار من خلال الـ UI
الخطوات:
نفتح Amazon.com 🌐
نسجل دخول (Login) 👤
نبحث عن "iPhone 15 Pro" 🔍
نختار المنتج ونضغط "Add to Cart" 🛒
نروح على Cart ونتأكد إنه المنتج موجود ✅
نضغط "Proceed to Checkout" 💳
نختار Shipping Address 📍
نختار Payment Method (Visa) 💳
نضغط "Place Order" 📦
نشوف "Order Confirmation" ✅
اختباراتنا:
الـ UI سهلة الاستخدام؟ ✅
الصور والمعلومات واضحة؟ ✅
الـ Total Price صحيح (المنتج + Shipping)؟ ✅
الـ Confirmation Message واضح؟ ✅
2. اختبار من خلال الـ API
بدل كل الخطوات التي فوق، نقدر نبعث API Requests مباشرة:
ميزة الـ API: أسرع بكثير! نقدر نختبر مئات Scenarios في دقائق! ⚡
3. اختبار من خلال الـ Database
بعد أن نعمل Order، نروح على الـ Database ونتأكد:
-- نتأكد إنه الـ Order موجودSELECT * FROM orders WHERE order_id = 'ORD-111222';-- نتأكد من التفاصيلSELECT * FROM order_items WHERE order_id = 'ORD-111222';-- نتأكد من المبلغSELECT total, tax, shipping_fee FROM orders WHERE order_id = 'ORD-111222';-- نتأكد من الـ StatusSELECT status FROM orders WHERE order_id = 'ORD-111222';
اختباراتنا:
الـ Order موجود في الـ Database؟ ✅
الـ Product ID صحيح (iPhone 15 Pro)? ✅
الـ Quantity صحيح (1)? ✅
الـ Total Price صحيح ($999.00)? ✅
الـ Shipping Address محفوظ صح؟ ✅
الـ Status = "Pending"? ✅
الـ Created Date صحيح؟ ✅
4. اختبار User Roles
Admin User:
يستطيع يشوف كل Orders (لكل المستخدمين) 👀
يستطيع يلغي أي Order 🗑️
يستطيع يعدل Status (Pending → Shipped) 📦
Regular User:
يستطيع يشوف لكن Orders تبعه 👀
يستطيع يلغي لكن Orders تبعه (قبل Shipping) 🗑️
لا يستطيع يعدل Status ❌
اختباراتنا:
Admin يرى كل Orders؟ ✅
User عادي يرى لكن orders تبعه؟ ✅
User عادي لو حاول يشوف order لمستخدم ثاني، يطلعله Error؟ ✅
5. اختبار Error Messages
سيناريوهات Unhappy Path:
السيناريو 1: Credit Card مرفوض
الرسالة: "Payment declined. Please check your card details or use a different payment method." ✅
مش: "Error 500" ❌
السيناريو 2: المنتج Out of Stock
الرسالة: "This item is currently out of stock. Please check back later or choose a different product." ✅
مش: "Failed" ❌
السيناريو 3: Shipping Address غلط
الرسالة: "Invalid shipping address. Please provide a complete address with ZIP code." ✅
مش: "Error" ❌
6. اختبار System Integration
التكاملات التي لازم نختبرها:
أ. Payment Gateway (Visa)
Amazon يبعث Payment Request لـ Visa ✅
Visa يُرجع Response (Approved / Declined) ✅
لو Approved، الـ Order Status يحدث "Confirmed" ✅
لو Declined، الـ Error Message واضح للمستخدم ✅
ب. Email Service
بعد Order، المستخدم يستقبل Confirmation Email ✅
الإيميل فيه Order Details صحيحة (Order ID, Total, Items) ✅
فيه Link لـ Track Order ✅
ج. Shipping Company
Amazon يبعث Shipping Request ✅
Shipping Company يُرجع Tracking Number ✅
المستخدم يستطيع يتتبع Order ✅
ليش نستخدم طرق مختلفة؟
كل طريقة تكشف مشاكل مختلفة!
مثال واقعي: Bug في الـ Total Price
المشكلة: المستخدم يرى Total Price غلط!
اختبار UI:
الـ UI يعرض Total = $999.00 ✅
يظهر إنه كل شي صح! ✅
لكن عندما نختبر Database:
SELECT total FROM orders WHERE order_id = 'ORD-111222';-- Result: $900.00 ❌
المشكلة: الـ UI يحسب صح، لكن الـ Backend يحفظ رقم غلط!
لو ما اختبرنا الـ Database، كان ما اكتشفنا المشكلة! 🐛
مثال ثاني: Bug في الـ Discount
السيناريو: في Discount Code "SAVE10" لازم ينزل 10%