ஆதாயங்கள்:
- நிலைக் குறியீடு, திட்டம்/ஒப்பந்தம், வணிக விதி மற்றும் எதிர்மறை/அங்கீகார அடுக்குகளில் செயற்கை நுண்ணறிவு ஆதரவுடன் API சோதனையை ஆழமாக நடத்தும் திறன்
- மாதிரி பதிலில் இருந்து JSON ஸ்கீமாவை உருவாக்கும் திறன் மற்றும் வகை மற்றும் கட்டாய சரிபார்ப்புடன் நிலைக் குறியீட்டை மட்டும் பார்க்கும் போலி நம்பிக்கையைத் தவிர்க்கவும்
- அங்கீகாரம் மற்றும் IDOR போன்ற பாதுகாப்புக் காட்சிகளை செயற்கைத் தரவு மற்றும் தற்காப்பு நோக்கங்களுக்காக மட்டுமே அங்கீகாரத்திற்குள் சோதிக்கும் திறன்
பெரும்பாலான நவீன மென்பொருள்கள் API (Application Programming Interface — ஒரு குறிப்பிட்ட ஒப்பந்தத்தின்படி இரண்டு மென்பொருள் துண்டுகள் பேசும் இடைமுகம்) மூலம் பின்னணியில் ஒருவருக்கொருவர் பேசுகின்றன. ஒரு மொபைல் பயன்பாடு கார்ட்டில் உருப்படிகளைச் சேர்க்கும் போது, அது உண்மையில் சர்வரில் உள்ள APIக்கு கோரிக்கையை அனுப்புகிறது. இடைமுகம் எதுவாக இருந்தாலும், இந்த உரையாடல் சரியானது, பாதுகாப்பானது மற்றும் சீரானது என்பதை API சோதனை சரிபார்க்கிறது; இது UI சோதனையை விட வேகமானது, நிலையானது மற்றும் ஆழமானது. API சோதனையில் செயற்கை நுண்ணறிவு (AI) மிகவும் திறமையானது: இது API வரையறையிலிருந்து சோதனைகளை உருவாக்குகிறது, பதில் திட்டத்தைப் பிரித்தெடுக்கிறது (தரவின் கட்டமைப்பை வரையறுக்கும் ஒப்பந்தம்), விளிம்பு நிலைகளை பட்டியலிடுகிறது. ஆனால் மீண்டும் மைய எச்சரிக்கை பொருந்தும்: AI க்கு உங்கள் API இன் உண்மையான வணிக விதிகள் தெரியாது; "200 திரும்பியது" என்பதை மட்டுமே உறுதிப்படுத்தும் மேலோட்டமான சோதனைகளை உருவாக்க முனைகிறது. சோதனை உண்மையான ஒப்பந்தம் மற்றும் வணிக தர்க்கத்தை சரிபார்க்கிறது என்பதை உறுதிப்படுத்துவதே உங்கள் வேலை.
இந்த யூனிட்டில், போஸ்ட்மேன், ரெஸ்ட் அஷ்யூர்டு மற்றும் ஸ்கீமா சரிபார்ப்பு போன்ற அணுகுமுறைகளுடன் 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 /ஆர்டர் இறுதிப்புள்ளிக்கு REST உறுதியளிக்கப்பட்ட (ஜாவா) சோதனைகளை எழுதுங்கள். ஒப்பந்தம்: தயாரிப்பு ஐடி மற்றும் அளவு உடலில் கட்டாயம்; 201 மற்றும் {orderId, மொத்தம், தள்ளுபடி, நிலை} ஆகியவை வெற்றியின் போது திரும்பப் பெறப்படும். வணிக விதிகள்: 10% தள்ளுபடி 1000 TL க்கு மேல் இருந்தால் ; 400 க்கு மேல் மதிப்பு 400 TL; டோக்கன்;
சக்திவாய்ந்த ப்ராம்ட் ஒப்பந்தம், வணிக விதிகள், பாதுகாப்பு காட்சிகள் மற்றும் ஸ்கீமா சரிபார்ப்பு எதிர்பார்ப்பு ஆகியவற்றை வழங்குகிறது.
ஒப்பந்த சோதனை: அணிகளுக்கு இடையே முறிவுகளைத் தடுப்பது
மைக்ரோ சர்வீஸ் ஆர்கிடெக்சர்களில் (பயன்பாடு சிறிய சேவைகளாகப் பிரிக்கப்பட்டு, ஒன்றுக்கொன்று சார்பற்ற மற்றும் API உடன் பேசும் அமைப்பு), ஒரு சேவையின் மறுமொழி வடிவமைப்பை மாற்றுவது, அதனுடன் இணைக்கப்பட்ட பிற சேவைகளை அமைதியாக சீர்குலைக்கிறது. ஒப்பந்த சோதனை - வழங்குநர் சேவைக்கும் நுகர்வோர் சேவைக்கும் இடையிலான API ஒப்பந்தம் இருபுறமும் உடைக்கப்படவில்லை என்பதைச் சரிபார்க்கும் சோதனை - இது போன்ற முறிவுகளை முன்கூட்டியே பிடிக்கிறது. யோசனை இதுதான்: நுகர்வோர் தயாரிப்பாளரிடமிருந்து அவர் எதிர்பார்க்கும் பதிலின் வடிவத்தை "ஒப்பந்தம்" என்று வரையறுக்கிறார்; ஒவ்வொரு மாற்றத்திலும், உற்பத்தியாளர் இந்த ஒப்பந்தத்திற்கு இணங்குவதை சோதிக்கிறார். எனவே ஒரு புலத்தின் பெயர் அல்லது வகை மாறும்போது, அது செயலிழக்கும் முன் நுகர்வோர் பைப்லைனை அறிவிப்பார்.
இந்த சூழலில் AI இரண்டு பணிகளை துரிதப்படுத்துகிறது: ஏற்கனவே இருக்கும் API பதிலில் இருந்து நுகர்வோர் எதிர்பார்ப்பை பிரதிபலிக்கும் ஒரு ஒப்பந்தத்தை உருவாக்குவது மற்றும் எந்த ஒப்பந்த விதியை மாற்றினால் முறியலாம் என்பதை முன்கூட்டியே குறிப்பது. ஆனால் ஒப்பந்தமே ஒரு வணிக முடிவாகும்: எந்தப் பகுதிகள் உண்மையிலேயே முக்கியமானவை என்பதை நிபுணர் தீர்மானிக்கிறார், எந்த மாற்றங்கள் பின்தங்கிய இணக்கத்தன்மையை உடைக்கும் - பழைய நுகர்வோர் தொடர்ந்து வேலை செய்கிறார்கள். AI ஒப்பந்தத்தை எழுதுகிறது; அதை ஆமோதிப்பவர் நீங்கள்.
உதவிக்குறிப்பு: ஒரு புலத்தை நீக்குவது அல்லது API இல் புல வகையை மாற்றுவது எப்போதுமே ஒரு முக்கிய மாற்றமாகும். புதிய புலங்களைச் சேர்ப்பது பொதுவாக பாதுகாப்பானது. AI ஒரு மாற்றத்தை "பிரேக்கிங் அல்லது பாதுகாப்பானது" என வகைப்படுத்துவது விரைவான முன்-வெளியீட்டு பாதுகாப்பு சோதனையை வழங்குகிறது.
போஸ்ட்மேன் அல்லது குறியீடு அடிப்படையிலானதா?
அளவுகோல்
தபால்காரர்/நியூமேன்
ஓய்வு உறுதி / குறியீடு (ஜாவா, சி#, ஜேஎஸ்)
கற்றல்
எளிதானது, காட்சி
குறியீடு அறிவு தேவை
பதிப்பு கட்டுப்பாடு
சேகரிப்பு JSON
நேரடியாக மூலக் குறியீட்டில்
சிக்கலான தர்க்கம்
வரையறுக்கப்பட்ட (JS ஸ்கிரிப்டுகள்)
முழு நிரலாக்க சக்தி
CI/CD ஒருங்கிணைப்பு
நியூமன் உடன்
கட்டுமானத்தை நேரடியாக சார்ந்துள்ளது
திட்ட சரிபார்ப்பு
சோதனை ஸ்கிரிப்ட்களுடன்
நூலகத்துடன் சக்தி வாய்ந்தது
குழு அளவு
சிறிய/நடுத்தர
பெரிய, முதிர்ந்த
AI இரண்டிற்கும் குறியீட்டை உருவாக்குகிறது; உங்களுக்கு எது வேண்டும் என்பதில் தெளிவாக இருங்கள்.
நகலெடுக்கக்கூடிய நான்கு வார்ப்புருக்கள்
1) ஒப்பந்த அடிப்படையிலான API சோதனை:
உங்கள் பங்கு: மூத்த API சோதனைப் பொறியாளர். பின்வரும் இறுதிப் புள்ளிக்கான சோதனைகளை [கருவி/மொழி] மூலம் எழுதவும்: [முறை + பாதை]. ஒப்பந்தம்: [தேவையான புலங்கள், வெற்றிக் குறியீடு, மறுமொழி அமைப்பு]. வணிக விதிகள்: [விதிமுறைகள்]. சோதனை அடுக்குகள்: (1) நிலைக் குறியீடு (2) பதில் திட்டச் சரிபார்ப்பு(3) ஒவ்வொரு வணிக விதிக்கும் எதிர்மறையாகப் பயன்படுத்தவும்.
2) மாதிரி பதிலில் இருந்து திட்ட உருவாக்கம்:
கீழே உள்ள மாதிரி API பதிலில் இருந்து JSON ஸ்கீமாவை உருவாக்கவும். தேவையான புலங்கள், வகைகள், வடிவமைப்பு கட்டுப்பாடுகள் (தேதி, மின்னஞ்சல், எண் வரம்பு) ஆகியவற்றைக் குறிப்பிடவும். இந்த திட்டத்திற்கு எதிராக சரிபார்க்கும் ஒரு சோதனை உதாரணத்தை கொடுங்கள். மாதிரி பதில்: [JSON ஒட்டவும்]
3) எதிர்மறை மற்றும் அங்கீகார சூழ்நிலைகள்:
இறுதிப்புள்ளி[இறுதிப்புள்ளி]க்கான எதிர்மறை மற்றும் பாதுகாப்பு சோதனை நிகழ்வுகளை உருவாக்கவும். இதில் உள்ளடங்கும்: விடுபட்ட/தேவையான புலம், தவறான வகை, மிகப் பெரிய மதிப்பு, தவறான/காலாவதியான டோக்கன், அங்கீகரிக்கப்படாத ஆதாரத்திற்கான அணுகல் (IDOR — ஐடியை மாற்றுவதன் மூலம் வேறொருவரின் பதிவுக்கான அணுகல்), கட்டண வரம்பு. ஒவ்வொரு காட்சிக்கும் எதிர்பார்க்கப்படும் நிலைக் குறியீடு மற்றும் பிழையின் உள்ளடக்கத்தைக் குறிப்பிடவும். குறிப்பு: அங்கீகரிக்கப்பட்ட எனது சொந்த API இல் மட்டுமே சோதிக்கப்படும்.
4) போலி நம்பிக்கை கட்டுப்பாடு:
இந்த API சோதனையைப் பார்க்கவும். சேவையகம் சரியான நிலைக் குறியீட்டை வழங்கினால் இந்தச் சோதனை பிடிக்குமா ஆனால் FALSEbody/data? இல்லையெனில், ஸ்கீமா மற்றும் வணிக விதி சரிபார்ப்பைச் சேர்க்கவும். சோதனை: [ஒட்டு சோதனை]
மூன்று சிறிய வழக்குகள்
வழக்கு 1 - திட்ட சரிபார்ப்பின் சக்தி. ஒரு குழு AI உடன் தயாரித்த சோதனைகளில் நிலைக் குறியீட்டை மட்டுமே சரிபார்த்துக் கொண்டிருந்தது. ஒரு பதிப்பில், API ஆனது மொத்தப் புலத்தையும் உரையாக ("1200") தவறாகத் திரும்பத் தொடங்கியது; சோதனைகள் இன்னும் 200 திரும்பியதால் பச்சையாகவே இருந்தது. மொபைல் பயன்பாடு செயலிழந்தது. "மாதிரி மறுமொழியிலிருந்து ஸ்கீமா உருவாக்கம்" டெம்ப்ளேட்டுடன் வகை சரிபார்ப்பைச் சேர்த்த பிறகு, அதே பிழை உடனடியாகப் பிடிக்கப்பட்டது.
வழக்கு 2 - அதிகார இடைவெளி (IDOR). AI ஆல் உருவாக்கப்பட்ட "எதிர்மறை மற்றும் அங்கீகார சூழ்நிலைகளுக்கு" இடையே ஒரு நிபுணர் ஐடிஓஆர் சோதனையை நடத்தினார்: அவர் பயனர் A இன் டோக்கனுடன் பயனர் B இன் ஆர்டர் ஐடியைக் கோரினார். API 200 மற்றும் B இன் தரவை வழங்கியது - இது ஒரு தீவிர அங்கீகார பாதிப்பு. இந்த தற்காப்பு சோதனை நேரலைக்கு வருவதற்கு முன்பு தரவு கசிவை மூடியது.
வழக்கு 3 - வணிக விதி பைபாஸ். AI தள்ளுபடி இறுதிப் புள்ளிக்காக 8 சோதனைகளை உருவாக்கியது; அனைவரும் 200ஐச் சரிபார்த்துக் கொண்டிருந்தனர், யாரும் தள்ளுபடித் தொகையைச் சரிபார்க்கவில்லை. நிபுணர் வணிக விதிகளை உடனுக்குடன் சேர்த்து அவற்றை மீண்டும் உருவாக்கினார். 1000 TL வரம்பில் தள்ளுபடி தவறாகக் கணக்கிடப்பட்டது என்று புதிய சோதனைகள் வெளிப்படுத்தின (தள்ளுபடி 999 க்கும் பயன்படுத்தப்பட்டது). ஒப்பந்தக் கட்டுப்பாடு போதாது; வணிக விதி கட்டுப்பாடு அவசியம்.
பொதுவான தவறுகள்
- நிலைக் குறியீட்டைப் பார்க்கிறேன். "200 திரும்பி வந்து கடந்துவிட்டது" என்று சொல்ல; சிதைந்த உடலைப் பார்க்கவில்லை (பொய்-நம்பிக்கை).
- ஸ்கீமா சரிபார்ப்பைத் தவிர்க்கிறது. புல வகைகள் மற்றும் கடமைகளைச் சரிபார்க்கவில்லை; வகை மாற்றங்கள் அமைதியாக கடந்து செல்கின்றன.
- வணிக விதிகளை வழங்காமல் சோதனை கோருதல். AI க்கு விதிகள் தெரியாது; இது தொழில்நுட்ப கட்டுப்பாட்டை மட்டுமே உருவாக்குகிறது.
- எதிர்மறை மற்றும் உரிமைக் காட்சிகளை மறத்தல். பாதுகாப்பு பாதிப்புகள் (IDOR, அங்கீகரிக்கப்படாத அணுகல்) இந்த சோதனைகளால் மட்டுமே பிடிக்கப்படுகின்றன.
- உண்மையான/உற்பத்தி டோக்கன்கள் மற்றும் தரவைப் பயன்படுத்துதல். சோதனைக்காக பிரத்யேக மீடியா மற்றும் செயற்கைத் தரவைப் பயன்படுத்தவும்; உண்மையான சாவிகளை வாகனத்தில் ஒட்ட வேண்டாம்.
- அங்கீகரிக்கப்படாத பாதுகாப்பு சோதனை. உங்கள் சொந்த API மற்றும் அனுமதியுடன் மட்டுமே அங்கீகார சோதனைகளை இயக்கவும்.
சுருக்கமாக
ஏபிஐ சோதனையானது, இடைமுகத்தைப் பொருட்படுத்தாமல், மென்பொருள் துண்டுகளின் பேச்சை விரைவாகவும் ஆழமாகவும் சரிபார்க்கிறது. AI; மாதிரி பதிலில் இருந்து JSON ஸ்கீமா மற்றும் எதிர்மறை/பாதுகாப்பு காட்சிகளை உருவாக்குவதில் ஒப்பந்த சோதனைகள் மிகவும் திறமையானவை. ஆனால் நிலைக் குறியீட்டை மட்டுமே சரிபார்க்கும் மேலோட்டமான சோதனைகள் போலி நம்பிக்கையைத் தருகின்றன. நான்கு அடுக்குகளும் தேவை: நிலைக் குறியீடு, திட்டச் சரிபார்ப்பு, வணிக விதி, எதிர்மறை மற்றும் அங்கீகாரம். வணிக விதிகள் மற்றும் ஒப்பந்தங்களை உடனடியாக வைக்கவும்; செயற்கை தரவு மற்றும் அங்கீகாரத்துடன் மட்டுமே பாதுகாப்பு சோதனைகளைச் செய்யவும்.
விண்ணப்ப பணி
உங்கள் சொந்த திட்டத்திலிருந்து API இறுதிப் புள்ளியைத் தேர்வு செய்யவும். "ஒப்பந்த அடிப்படையிலான API சோதனை" டெம்ப்ளேட்டுடன் AI நான்கு-அடுக்கு சோதனைகளை எழுத வேண்டும். பின்னர் "மாதிரி பதிலில் இருந்து ஸ்கீமா உருவாக்கம்" உடன் வகை/செயல்படுத்தல் சரிபார்ப்பைச் சேர்த்து, "போலி நம்பிக்கை சரிபார்ப்பு" என்பதைப் பயன்படுத்தவும். உங்கள் சொந்த சோதனைச் சூழலில் குறைந்தது ஒரு ஐடிஓஆர்/அங்கீகாரச் சூழ்நிலையை இயக்கவும். நீங்கள் கண்டறிந்த ஒப்பந்தம் அல்லது வணிக விதி மீறல்களைப் புகாரளிக்கவும்; உங்களால் எதையும் கண்டுபிடிக்க முடியவில்லை எனில், அது பிடித்தது என்பதை நிரூபிக்க வேண்டுமென்றே தவறான பதிலுக்கு எதிராக சோதனையை இயக்கவும்.
சரிபார்ப்பு பட்டியல்
- [ ] நான் சோதனையின் நான்கு அடுக்குகளை (கேஸ், ஸ்கீமா, பிசினஸ் ரூல், நெகடிவ்/அங்கீகாரம்) உள்ளடக்கியிருக்கிறேன்.
- [ ] நான் ஒப்பந்தம் மற்றும் வணிக விதிகளை AIக்கு தெளிவாக வழங்கினேன்.
- [ ] நான் மறுமொழி திட்டத்தை (புலம், வகை, கட்டாயம்) சரிபார்க்கும் சோதனைகளை அமைத்துள்ளேன்.
- [ ] நான் குறைந்தபட்சம் ஒரு அங்கீகாரம்/IDOR காட்சியை தற்காப்புக்காக முயற்சித்தேன்.
- [ ] உண்மையான டோக்கன்/தரவுக்குப் பதிலாக சோதனைச் சூழல் மற்றும் செயற்கைத் தரவைப் பயன்படுத்தினேன்.
- [ ] ஒவ்வொரு சோதனையும் சிதைந்த பதிலைப் பிடிக்கும் என்பதை "போலி-நம்பிக்கை சோதனை" மூலம் நிரூபித்தேன்.