یونٹ 5 / 11

API ٹیسٹ آٹومیشن: AI کے ساتھ معاہدہ، سکیما اور اینڈ ٹو اینڈ توثیق

فائدہ:

  • اسٹیٹس کوڈ، اسکیما/معاہدے، کاروباری اصول اور منفی/ اجازت کی تہوں پر مصنوعی ذہانت کی مدد کے ساتھ گہرائی میں API ٹیسٹنگ کرنے کی صلاحیت
  • نمونے کے جواب سے JSON اسکیما بنانے کی صلاحیت اور قسم اور لازمی توثیق کے ساتھ صرف اسٹیٹس کوڈ کو دیکھنے کے چھدم اعتماد سے بچنا
  • حفاظتی منظرناموں کی جانچ کرنے کی صلاحیت جیسے کہ اجازت اور IDOR مصنوعی ڈیٹا کے ساتھ اور صرف اجازت کے اندر دفاعی مقاصد کے لیے

زیادہ تر جدید سافٹ ویئر API کے ذریعے پس منظر میں ایک دوسرے سے بات کرتے ہیں (ایپلی کیشن پروگرامنگ انٹرفیس - وہ انٹرفیس جہاں سافٹ ویئر کے دو ٹکڑے ایک مخصوص معاہدے کے مطابق بات کرتے ہیں)۔ جب ایک موبائل ایپ کارٹ میں آئٹمز شامل کرتی ہے، تو یہ دراصل سرور پر موجود API کو ایک درخواست بھیجتی ہے۔ API جانچ پڑتال کرتی ہے کہ انٹرفیس سے قطع نظر یہ گفتگو درست، محفوظ اور مستقل ہے۔ یہ UI ٹیسٹنگ سے تیز، زیادہ مستحکم اور گہری ہے۔ مصنوعی ذہانت (AI) API ٹیسٹنگ میں بہت کارآمد ہے: یہ API کی تعریف سے ٹیسٹ تیار کرتا ہے، رسپانس اسکیما (معاہدہ جو ڈیٹا کی ساخت کی وضاحت کرتا ہے) نکالتا ہے، ایج کیسز کی فہرست دیتا ہے۔ لیکن ایک بار پھر مرکزی انتباہ لاگو ہوتا ہے: AI آپ کے API کے حقیقی کاروباری قوانین کو نہیں جانتا ہے۔ سطحی ٹیسٹ تیار کرتا ہے جو صرف "200 واپس" کی تصدیق کرتا ہے۔ آپ کا کام یہ یقینی بنانا ہے کہ ٹیسٹ اصل معاہدے اور کاروباری منطق کی تصدیق کرتا ہے۔

اس یونٹ میں، آپ یہ سیکھیں گے کہ پوسٹ مین، REST Assured اور اسکیما کی توثیق جیسے طریقوں کے ساتھ AI سے تعاون یافتہ، گہرے API ٹیسٹ کیسے ترتیب دیے جائیں۔

API ٹیسٹنگ کی پرتیں۔

کئی گہرائیوں میں API ٹیسٹنگ پر غور کریں، ہر پرت پر AI مختلف طریقے سے مدد کرتا ہے:

1. اسٹیٹس کوڈ اور بنیادی جواب۔ کیا درخواست متوقع HTTP اسٹیٹس کوڈ (کامیابی کے لیے 200/201، غلطی کے لیے 400/401/404) واپس کرتی ہے؟ یہ سب سے سطحی پرت ہے؛ AI آسانی سے پیدا کرتا ہے لیکن اکیلے غلط اعتماد دیتا ہے۔

2. سکیما/معاہدے کی توثیق۔ کیا جواب کی ساخت معاہدے کے مطابق ہے — کیا متوقع فیلڈز موجود ہیں، کیا ان کی اقسام درست ہیں، کیا مطلوبہ فیلڈز غائب ہیں؟ AI نمونے کے جواب سے JSON اسکیما — وہ معیار جو JSON دستاویز کے ڈھانچے کی وضاحت کرتا ہے — تیار کر سکتا ہے، اور ٹیسٹ اس سکیما کے خلاف توثیق کر سکتے ہیں۔ یہ فیلڈ پر مبنی دعویٰ دستی طور پر لکھنے سے کہیں زیادہ مضبوط ہے۔

3. کاروباری اصول کی توثیق۔ اصل قیمت یہاں ہے: "1000 TL آرڈر کے لیے، ڈسکاؤنٹ فیلڈ 100 ہونی چاہیے"، "منسوخ آرڈر کو دوبارہ منسوخ نہیں کیا جا سکتا"۔ AI ان کی تصدیق صرف اس صورت میں کرے گا جب آپ اسے قواعد دیں گے۔ اگر آپ اسے نہیں دیتے تو یہ کود جائے گا۔

4. منفی اور سلامتی. غلط ٹوکن کے لیے 401، کسی اور کے ڈیٹا تک رسائی کے لیے 403، خراب باڈی کے لیے کلیئر 400۔ اجازت دینے کے ٹیسٹ (اس بات کی تصدیق کرنا کہ صارف صرف اپنے ڈیٹا تک رسائی حاصل کر سکتا ہے) API سیکیورٹی کا مرکز ہیں اور دفاعی مقاصد کے لیے کیے جاتے ہیں۔

مشورہ: AI کو یہ بتائے بغیر ٹیسٹ کی درخواست نہ کریں کہ "صرف اسٹیٹس کوڈ ہی نہیں بلکہ رسپانس اسکیما اور ان کاروباری اصولوں کی بھی توثیق کریں۔" بصورت دیگر، آپ کے پاس ایسے ٹیسٹ رہ جائیں گے جو کہتے ہیں کہ "200 واپس آ گئے، پاس ہو گئے" لیکن API کو خراب شدہ ڈیٹا کی واپسی پر توجہ نہیں دیں گے۔

کمزور فوری / مضبوط اشارہ

کمزور: "اس API کے لیے ٹیسٹ لکھیں۔"
مضبوط: "POST/order کے اختتامی نقطہ کے لیے REST Assured (Java) ٹیسٹ لکھیں۔ معاہدہ: پروڈکٹ آئی ڈی اور مقدار باڈی میں لازمی ہے؛ 201 اور {orderId, total, discount, status} کامیابی پر واپس کر دیے جاتے ہیں۔ کاروباری قواعد: 1000 TL سے زیادہ 10% رعایت; 4000 میں اگر valid = 400 ٹوکن؛ 403 جب دوسرے صارف کا آرڈر دیکھیں: (1) اسٹیٹس کوڈ، (2) جوابی JSON اسکیما کی توثیق، (4) ہر اصرار کو واضح کاروباری اصول سے منسلک نہ کریں۔

طاقتور پرامپٹ معاہدہ، کاروباری قواعد، حفاظتی منظرنامے، اور اسکیما کی توثیق کی توقع دیتا ہے۔

معاہدے کی جانچ: ٹیموں کے مابین ٹوٹ پھوٹ کو روکنا

مائیکرو سروس آرکیٹیکچرز میں (وہ ڈھانچہ جس میں ایپلیکیشن کو چھوٹی سروسز میں تقسیم کیا گیا ہے جو ایک دوسرے سے آزاد ہیں اور API سے بات کرتی ہیں)، کسی سروس کے رسپانس فارمیٹ کو تبدیل کرنا خاموشی سے اس سے منسلک دیگر سروسز میں خلل ڈالتا ہے۔ کنٹریکٹ ٹیسٹنگ - وہ ٹیسٹ جو اس بات کی تصدیق کرتا ہے کہ فراہم کنندہ کی خدمت اور صارف کی خدمت کے درمیان API کا معاہدہ دونوں طرف سے ٹوٹا نہیں ہے - ایسے وقفوں کو جلد پکڑتا ہے۔ خیال یہ ہے: صارف ردعمل کی وہ شکل بیان کرتا ہے جس کی وہ پروڈیوسر سے "معاہدہ" کے طور پر توقع کرتا ہے۔ ہر تبدیلی کے ساتھ، مینوفیکچرر ٹیسٹ کرتا ہے کہ وہ اب بھی اس معاہدے کی تعمیل کرتا ہے۔ لہذا جب کسی فیلڈ کا نام یا قسم تبدیل ہوتا ہے، تو صارف پائپ لائن کے کریش ہونے سے پہلے اسے مطلع کرتا ہے۔

AI اس تناظر میں دو کاموں کو تیز کرتا ہے: ایک معاہدے کا مسودہ تیار کرنا جو موجودہ API کے ردعمل سے صارفین کی توقعات کی عکاسی کرتا ہے، اور پہلے سے نشان زد کرنا کہ کون سی معاہدے کی شق میں تبدیلی ٹوٹ سکتی ہے۔ لیکن معاہدہ بذات خود ایک کاروباری فیصلہ ہے: ماہر اس بات کا تعین کرتا ہے کہ کون سے شعبے واقعی اہم ہیں، کون سی تبدیلیاں پسماندہ مطابقت کو توڑ دے گی — پرانے صارفین کام جاری رکھیں گے۔ AI معاہدہ لکھتا ہے؛ آپ وہ ہیں جو اسے منظور کرتے ہیں۔

ٹپ: کسی فیلڈ کو حذف کرنا یا API میں فیلڈ کی قسم کو تبدیل کرنا تقریباً ہمیشہ ایک اہم تبدیلی ہے۔ نئے فیلڈز کو شامل کرنا عام طور پر محفوظ ہوتا ہے۔ AI کا تبدیلی کو "بریکنگ یا سیف" کے طور پر درجہ بندی کرنے سے ریلیز سے پہلے کی فوری سیکیورٹی چیک ملتی ہے۔

ڈاکیا یا کوڈ پر مبنی؟

معیار

پوسٹ مین/نیو مین

REST Assured/code (Java, C#, JS)

سیکھنا

آسان، بصری

کوڈ کا علم درکار ہے۔

ورژن کنٹرول

مجموعہ JSON

براہ راست سورس کوڈ میں

پیچیدہ منطق

محدود (جے ایس اسکرپٹس)

مکمل پروگرامنگ پاور

CI/CD انضمام

نیومین کے ساتھ

براہ راست تعمیر پر منحصر ہے۔

اسکیما کی توثیق

ٹیسٹ اسکرپٹ کے ساتھ

لائبریری کے ساتھ طاقتور

ٹیم پیمانہ

چھوٹے/درمیانے

بڑا، بالغ

AI دونوں کے لیے کوڈ تیار کرتا ہے۔ واضح ہو کہ آپ کون سا چاہتے ہیں۔

چار کاپی کرنے کے قابل ٹیمپلیٹس

1) معاہدہ پر مبنی API ٹیسٹنگ:

آپ کا کردار: سینئر API ٹیسٹ انجینئر۔ مندرجہ ذیل اختتامی نقطہ کے لیے [tool/language] کے ساتھ ٹیسٹ لکھیں: [طریقہ + راستہ]۔ معاہدہ: [مطلوبہ فیلڈز، کامیابی کا کوڈ، رسپانس سٹرکچر]۔ بزنس رولز: [قواعد]۔ ٹیسٹ لیئرز: (1) اسٹیٹس کوڈ (2) رسپانس اسکیما کی توثیق (3) ہر کاروباری قاعدہ کو منفی قاعدہ کے طور پر (4) ہر ایک تصنیف کے اصول کے طور پر شق

2) نمونے کے جواب سے سکیما جنریشن:

ذیل میں نمونہ API جواب سے JSON اسکیما تیار کریں۔ مطلوبہ فیلڈز، اقسام، فارمیٹ کی رکاوٹیں (تاریخ، ای میل، نمبر کی حد) کی وضاحت کریں۔ پھر ایک ٹیسٹ مثال دیں جو اس اسکیما کے خلاف توثیق کرتی ہے۔ نمونہ جواب: [پیسٹ JSON]

3) منفی اور اجازت کے منظرنامے:

اینڈ پوائنٹ [اینڈ پوائنٹ] کے لیے منفی اور سیکیورٹی ٹیسٹ کیسز بنائیں۔ شامل ہیں: غائب/ضروری فیلڈ، غلط قسم، بہت بڑی قیمت، غلط/میعاد ختم شدہ ٹوکن، غیر مجاز وسائل تک رسائی (IDOR — ID تبدیل کرکے کسی اور کے ریکارڈ تک رسائی)، شرح کی حد۔ ہر منظر نامے کے لیے متوقع اسٹیٹس کوڈ اور ایرر باڈی کی وضاحت کریں۔ نوٹ: صرف میرے اپنے API پر تجربہ کیا جائے گا، مجاز۔

4) سیوڈو ٹرسٹ کنٹرول:

اس API ٹیسٹ کو چیک کریں۔ کیا یہ ٹیسٹ پکڑے گا اگر سرور نے درست اسٹیٹس کوڈ واپس کیا لیکن FALSEbody/data؟ اگر نہیں، تو اسکیما اور کاروباری اصول کی توثیق شامل کریں۔ ٹیسٹ: [پیسٹ ٹیسٹ]

تین چھوٹے مقدمات

کیس 1 - اسکیما کی توثیق کی طاقت۔ ایک ٹیم AI کے ساتھ تیار کردہ ٹیسٹوں میں صرف اسٹیٹس کوڈ کی جانچ کر رہی تھی۔ ایک ورژن میں، API نے غلطی سے کل فیلڈ کو بطور متن ("1200") واپس کرنا شروع کر دیا؛ ٹیسٹ سبز رہے کیونکہ یہ اب بھی 200 واپس کر رہا تھا۔ موبائل ایپلیکیشن کریش ہو گئی۔ "سمپلیٹ کے جواب سے سکیما جنریشن" ٹیمپلیٹ کے ساتھ قسم کی توثیق شامل کرنے کے بعد، وہی غلطی فوری طور پر پکڑی گئی۔

کیس 2 - اتھارٹی گیپ (IDOR)۔ ایک ماہر نے AI کے ذریعہ تیار کردہ "منفی اور اجازت کے منظرناموں" کے درمیان IDOR ٹیسٹ چلایا: اس نے صارف A کے ٹوکن کے ساتھ صارف B کے آرڈر ID کی درخواست کی۔ API نے 200 اور B کا ڈیٹا واپس کر دیا - ایک سنگین اجازت کا خطرہ۔ اس دفاعی ٹیسٹ نے لائیو ہونے سے پہلے ڈیٹا لیک کو بند کر دیا۔

کیس 3 - کاروباری اصول بائی پاس۔ AI نے ڈسکاؤنٹ اینڈ پوائنٹ کے لیے 8 ٹیسٹ بنائے۔ سب 200 چیک کر رہے تھے، کوئی بھی ڈسکاؤنٹ کی رقم کی تصدیق نہیں کر رہا تھا۔ ماہر نے کاروباری قواعد کو فوری طور پر شامل کیا اور انہیں دوبارہ پیش کیا۔ نئے ٹیسٹوں سے پتہ چلتا ہے کہ 1000 TL کی حد میں رعایت کا غلط حساب لگایا گیا تھا (رعایت کا اطلاق 999 پر بھی کیا گیا تھا)۔ معاہدہ کنٹرول کافی نہیں ہے؛ کاروباری حکمرانی کا کنٹرول ضروری ہے۔

عام غلطیاں

  • صرف اسٹیٹس کوڈ کو دیکھ رہے ہیں۔ یہ کہنا کہ "200 لوٹ آئے اور گزر گئے"؛ بگڑے ہوئے جسم کو نہ دیکھنا (جھوٹا اعتماد)۔
  • اسکیما کی توثیق کو نظرانداز کرنا۔ فیلڈ کی اقسام اور ذمہ داری کی جانچ نہ کرنا؛ قسم کی تبدیلیاں خاموشی سے گزر جاتی ہیں۔
  • کاروباری قواعد فراہم کیے بغیر جانچ کی درخواست کرنا۔ AI قوانین کو نہیں جانتا؛ یہ صرف تکنیکی کنٹرول پیدا کرتا ہے۔
  • منفی اور حقدارانہ منظرناموں کو بھولنا۔ سیکورٹی کے خطرات (IDOR، غیر مجاز رسائی) صرف ان ٹیسٹوں کے ذریعے پکڑے جاتے ہیں۔
  • اصلی/پروڈکشن ٹوکن اور ڈیٹا کا استعمال۔ جانچ کے لیے سرشار میڈیا اور مصنوعی ڈیٹا استعمال کریں۔ گاڑی میں اصلی چابیاں نہ لگائیں۔
  • غیر مجاز سیکیورٹی ٹیسٹنگ۔ صرف اپنے API پر اور اجازت کے ساتھ اجازت کے ٹیسٹ چلائیں۔

خلاصہ میں

API ٹیسٹنگ انٹرفیس سے قطع نظر سافٹ ویئر کے ٹکڑوں کی تقریر کی جلدی اور گہرائی سے تصدیق کرتی ہے۔ اے آئی معاہدے کے ٹیسٹ نمونے کے جواب سے JSON اسکیما اور منفی/سیکیورٹی منظرنامے بنانے میں بہت موثر ہیں۔ لیکن سطحی ٹیسٹ جو صرف اسٹیٹس کوڈ کو چیک کرتے ہیں وہ چھدم اعتماد دیتے ہیں۔ تمام چار تہوں کی ضرورت ہے: اسٹیٹس کوڈ، اسکیما کی توثیق، کاروباری اصول، منفی، اور اجازت۔ کاروباری قواعد اور معاہدے کو فوری طور پر رکھیں؛ مصنوعی ڈیٹا کے ساتھ اور صرف اجازت کے ساتھ حفاظتی ٹیسٹ کریں۔

درخواست کا کام

اپنے پروجیکٹ سے ایک API اینڈ پوائنٹ کا انتخاب کریں۔ AI کو "معاہدے پر مبنی API ٹیسٹنگ" ٹیمپلیٹ کے ساتھ چار پرتوں کے ٹیسٹ لکھیں۔ پھر "نمونے کے جواب سے اسکیما جنریشن" کے ساتھ قسم/نفاذ کی توثیق شامل کریں اور "سیڈو ٹرسٹ چیکنگ" کا اطلاق کریں۔ اپنے ٹیسٹ کے ماحول میں کم از کم ایک IDOR/ اجازت نامے کا منظر نامہ چلائیں۔ آپ کو ملنے والی کسی بھی معاہدے یا کاروباری اصول کی خلاف ورزیوں کی اطلاع دیں۔ اگر آپ کو کوئی نہیں ملتا ہے تو، جان بوجھ کر غلط جواب کے خلاف ٹیسٹ چلائیں تاکہ یہ ثابت ہو کہ اس نے اسے پکڑا ہے۔

چیک لسٹ

  • میں نے جانچ کی چار پرتوں کا احاطہ کیا (کیس، اسکیما، کاروباری اصول، منفی/اختیار)۔
  • [ ] میں نے واضح طور پر AI کو معاہدہ اور کاروباری اصول دے دیئے۔
  • [ ] میں نے ایسے ٹیسٹ مرتب کیے ہیں جو جوابی اسکیما (فیلڈ، قسم، ضروری) کی توثیق کرتے ہیں۔
  • میں نے کم از کم ایک اجازت/IDOR منظر نامے کو دفاعی طور پر آزمایا ہے۔
  • میں نے اصلی ٹوکن/ڈیٹا کے بجائے ٹیسٹ ماحول اور مصنوعی ڈیٹا استعمال کیا۔
  • میں نے "سیڈو اعتماد کی جانچ" کے ساتھ ثابت کیا کہ ہر ٹیسٹ خراب ردعمل کو پکڑتا ہے۔