യൂണിറ്റുകൾ
1. സോഫ്‌റ്റ്‌വെയർ ടെസ്റ്റിംഗിലും ക്യുഎയിലും ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസിൻ്റെ ആമുഖം: റോളുകൾ, അതിരുകൾ, വ്യാജ അപകടസാധ്യത, മൂല്യനിർണ്ണയം 2. ടെസ്റ്റ് സാഹചര്യവും ടെസ്റ്റ് കേസ് ജനറേഷനും: ആവശ്യകത മുതൽ സമഗ്രമായ നിയന്ത്രണം വരെ 3. പര്യവേക്ഷണ പരിശോധനയും ടെസ്റ്റ് ഐഡിയ ജനറേഷനും: AI ഉപയോഗിച്ച് ക്രിയേറ്റീവ് ബഗ് ഹണ്ടിംഗ് 4. UI ടെസ്റ്റ് ഓട്ടോമേഷൻ: AI ഉപയോഗിച്ച് സെലിനിയം, പ്ലേറൈറ്റ്, സൈപ്രസ് കോഡ് എന്നിവ സൃഷ്ടിക്കുന്നു 5. API ടെസ്റ്റ് ഓട്ടോമേഷൻ: AI-യുമായുള്ള കരാർ, സ്കീമ, എൻഡ്-ടു-എൻഡ് മൂല്യനിർണ്ണയം 6. യൂണിറ്റ് ടെസ്റ്റ് ജനറേഷനും ടെസ്റ്റബിലിറ്റിയും: AI ഉപയോഗിച്ചുള്ള ശക്തമായ പരിശോധന 7. പിശക് റിപ്പോർട്ട് റൈറ്റിംഗും മുൻഗണനയും: AI ഉപയോഗിച്ച് വ്യക്തവും പുനർനിർമ്മിക്കാവുന്നതുമായ റെക്കോർഡുകൾ 8. ടെസ്റ്റ് കവറേജ് അനാലിസിസും റിസ്ക്-ബേസ്ഡ് ടെസ്റ്റിംഗും: AI ഉപയോഗിച്ച് ശരിയായ ലക്ഷ്യം 9. റിഗ്രഷൻ ടെസ്റ്റിംഗ്, ടെസ്റ്റ് മെയിൻ്റനൻസ്, ഫ്രാഗിൾ ടെസ്റ്റുകളെ ചെറുക്കുക 10. ഫാൾസ്-ട്രസ്റ്റ് റിസ്ക്, ടെസ്റ്റ് ക്വാളിറ്റി, മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ്: ടെസ്റ്റിംഗ് ടെസ്റ്റുകൾ 11. എൻഡ്-ടു-എൻഡ് വർക്ക്ഫ്ലോ, സിഐ/സിഡി ഇൻ്റഗ്രേഷൻ, എത്തിക്‌സ് ആൻഡ് സെക്യൂരിറ്റി: എഐയെ ഉത്തരവാദിത്തത്തോടെ ഉപയോഗിക്കുന്നു
യൂണിറ്റ് 5 / 11

API ടെസ്റ്റ് ഓട്ടോമേഷൻ: AI-യുമായുള്ള കരാർ, സ്കീമ, എൻഡ്-ടു-എൻഡ് മൂല്യനിർണ്ണയം

നേട്ടങ്ങൾ:

  • സ്റ്റാറ്റസ് കോഡ്, സ്കീമ/കരാർ, ബിസിനസ് റൂൾ, നെഗറ്റീവ്/ഓഥറൈസേഷൻ ലെയറുകൾ എന്നിവയിൽ ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് പിന്തുണയോടെ ആഴത്തിൽ API ടെസ്റ്റിംഗ് നടത്താനുള്ള കഴിവ്
  • സാമ്പിൾ പ്രതികരണത്തിൽ നിന്ന് JSON സ്കീമ ജനറേറ്റുചെയ്യാനുള്ള കഴിവും തരവും നിർബന്ധിത മൂല്യനിർണ്ണയവും ഉപയോഗിച്ച് സ്റ്റാറ്റസ് കോഡ് മാത്രം നോക്കുന്നതിനുള്ള കപട ആത്മവിശ്വാസം ഒഴിവാക്കുക
  • സിന്തറ്റിക് ഡാറ്റ ഉപയോഗിച്ച് അംഗീകാരം, IDOR എന്നിവ പോലുള്ള സുരക്ഷാ സാഹചര്യങ്ങൾ പരിശോധിക്കാനുള്ള കഴിവ്, അംഗീകാരത്തിനുള്ളിൽ മാത്രം പ്രതിരോധ ആവശ്യങ്ങൾക്കായി

മിക്ക ആധുനിക സോഫ്‌റ്റ്‌വെയറുകളും API വഴി പശ്ചാത്തലത്തിൽ പരസ്പരം സംസാരിക്കുന്നു (അപ്ലിക്കേഷൻ പ്രോഗ്രാമിംഗ് ഇൻ്റർഫേസ് - ഒരു പ്രത്യേക കരാർ പ്രകാരം രണ്ട് സോഫ്‌റ്റ്‌വെയറുകൾ സംസാരിക്കുന്ന ഇൻ്റർഫേസ്). ഒരു മൊബൈൽ ആപ്പ് കാർട്ടിലേക്ക് ഇനങ്ങൾ ചേർക്കുമ്പോൾ, അത് സെർവറിലെ ഒരു API-ലേക്ക് യഥാർത്ഥത്തിൽ ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുന്നു. ഇൻ്റർഫേസ് പരിഗണിക്കാതെ തന്നെ ഈ സംഭാഷണം ശരിയും സുരക്ഷിതവും സ്ഥിരതയുള്ളതുമാണെന്ന് API പരിശോധന പരിശോധിക്കുന്നു; ഇത് യുഐ ടെസ്റ്റിങ്ങിനേക്കാൾ വേഗതയേറിയതും സ്ഥിരതയുള്ളതും ആഴമേറിയതുമാണ്. API ടെസ്റ്റിംഗിൽ ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് (AI) വളരെ കാര്യക്ഷമമാണ്: ഇത് ഒരു API നിർവചനത്തിൽ നിന്ന് ടെസ്റ്റുകൾ സൃഷ്ടിക്കുന്നു, പ്രതികരണ സ്കീമ എക്‌സ്‌ട്രാക്‌റ്റ് ചെയ്യുന്നു (ഡാറ്റയുടെ ഘടന നിർവചിക്കുന്ന കരാർ), എഡ്ജ് കേസുകൾ ലിസ്റ്റുചെയ്യുന്നു. എന്നാൽ വീണ്ടും കേന്ദ്ര മുന്നറിയിപ്പ് ബാധകമാണ്: നിങ്ങളുടെ API-യുടെ യഥാർത്ഥ ബിസിനസ്സ് നിയമങ്ങൾ AI-ക്ക് അറിയില്ല; "200 മടങ്ങിയെത്തി" എന്ന് മാത്രം സ്ഥിരീകരിക്കുന്ന ഉപരിപ്ലവമായ പരിശോധനകൾ നിർമ്മിക്കാൻ പ്രവണത കാണിക്കുന്നു. ടെസ്റ്റ് യഥാർത്ഥ കരാറും ബിസിനസ്സ് ലോജിക്കും സ്ഥിരീകരിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക എന്നതാണ് നിങ്ങളുടെ ജോലി.

ഈ യൂണിറ്റിൽ, പോസ്റ്റ്മാൻ, REST അഷ്വേർഡ്, സ്കീമ മൂല്യനിർണ്ണയം എന്നിവ പോലുള്ള സമീപനങ്ങൾ ഉപയോഗിച്ച് AI- പിന്തുണയുള്ള ആഴത്തിലുള്ള API ടെസ്റ്റുകൾ എങ്ങനെ സജ്ജീകരിക്കാമെന്ന് നിങ്ങൾ പഠിക്കും.

API പരിശോധനയുടെ പാളികൾ

ഓരോ ലെയറിലും AI വ്യത്യസ്തമായി സഹായിക്കുന്നതിലൂടെ, നിരവധി ആഴത്തിലുള്ള API പരിശോധന പരിഗണിക്കുക:

1. സ്റ്റാറ്റസ് കോഡും അടിസ്ഥാന പ്രതികരണവും. അഭ്യർത്ഥന പ്രതീക്ഷിച്ച HTTP സ്റ്റാറ്റസ് കോഡ് (വിജയത്തിന് 200/201, പിശകിന് 400/401/404) നൽകുന്നുണ്ടോ? ഇത് ഏറ്റവും ഉപരിപ്ലവമായ പാളിയാണ്; AI എളുപ്പത്തിൽ ഉൽപ്പാദിപ്പിക്കുന്നു, എന്നാൽ മാത്രം തെറ്റായ വിശ്വാസം നൽകുന്നു.

2. സ്കീമ/കരാർ മൂല്യനിർണ്ണയം. പ്രതികരണത്തിൻ്റെ ഘടന കരാറിന് അനുയോജ്യമാണോ - പ്രതീക്ഷിക്കുന്ന ഫീൽഡുകൾ നിലവിലുണ്ടോ, അവയുടെ തരങ്ങൾ ശരിയാണോ, ആവശ്യമായ ഫീൽഡുകൾ നഷ്‌ടമാണോ? ഒരു സാമ്പിൾ പ്രതികരണത്തിൽ നിന്ന് JSON സ്കീമ - ഒരു JSON ഡോക്യുമെൻ്റിൻ്റെ ഘടന നിർവചിക്കുന്ന സ്റ്റാൻഡേർഡ് - AI-ക്ക് സൃഷ്ടിക്കാൻ കഴിയും, കൂടാതെ ടെസ്റ്റുകൾക്ക് ആ സ്കീമയ്‌ക്കെതിരെ സാധൂകരിക്കാനും കഴിയും. ഫീൽഡ് അധിഷ്‌ഠിത അവകാശവാദം സ്വമേധയാ എഴുതുന്നതിനേക്കാൾ ഇത് വളരെ ശക്തമാണ്.

3. ബിസിനസ് റൂൾ മൂല്യനിർണ്ണയം. യഥാർത്ഥ മൂല്യം ഇവിടെയുണ്ട്: "1000 TL ഓർഡറിന്, കിഴിവ് ഫീൽഡ് 100 ആയിരിക്കണം", "റദ്ദാക്കിയ ഓർഡർ വീണ്ടും റദ്ദാക്കാൻ കഴിയില്ല". നിങ്ങൾ നിയമങ്ങൾ നൽകിയാൽ മാത്രമേ AI ഇവ സ്ഥിരീകരിക്കുകയുള്ളൂ; കൊടുത്തില്ലെങ്കിൽ ചാടും.

4. നെഗറ്റീവ്, സെക്യൂരിറ്റി. അസാധുവായ ടോക്കണിനായി 401, മറ്റൊരാളുടെ ഡാറ്റ ആക്‌സസ് ചെയ്യുന്നതിന് 403, മോശം ശരീരത്തിന് 400 ക്ലിയർ ചെയ്യുക. ഓതറൈസേഷൻ ടെസ്റ്റുകൾ (ഒരു ഉപയോക്താവിന് അവരുടെ സ്വന്തം ഡാറ്റ മാത്രമേ ആക്‌സസ് ചെയ്യാൻ കഴിയൂ എന്ന് പരിശോധിക്കുന്നത്) API സുരക്ഷയുടെ ഹൃദയമാണ്, അവ പ്രതിരോധ ആവശ്യങ്ങൾക്കായി ചെയ്യുന്നു.

നുറുങ്ങ്: "സ്റ്റാറ്റസ് കോഡ് മാത്രമല്ല, പ്രതികരണ സ്കീമയും ആ ബിസിനസ്സ് നിയമങ്ങളും സാധൂകരിക്കാൻ" AI-യോട് പറയാതെ ഒരു ടെസ്റ്റ് അഭ്യർത്ഥിക്കരുത്. അല്ലാത്തപക്ഷം, "200 മടങ്ങിയെത്തി, പാസായി" എന്ന് പറയുന്ന ടെസ്റ്റുകൾ നിങ്ങൾക്ക് അവശേഷിക്കും, എന്നാൽ API കേടായ ഡാറ്റ തിരികെ നൽകുന്നത് ശ്രദ്ധിക്കില്ല.

ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ്

ദുർബലമായത്: "ഈ API-ക്കായി ടെസ്റ്റുകൾ എഴുതുക."
ശക്തമായത്: "POST/ഓർഡർ എൻഡ്‌പോയിൻ്റിനായി REST അഷ്വേർഡ് (Java) ടെസ്റ്റുകൾ എഴുതുക. ഉടമ്പടി: ഉൽപ്പന്ന ഐഡിയും അളവും ശരീരത്തിൽ നിർബന്ധമാണ്; 201, {orderId, ആകെ, കിഴിവ്, സ്റ്റാറ്റസ്} എന്നിവ വിജയിക്കുമ്പോൾ തിരികെ നൽകും. ബിസിനസ് നിയമങ്ങൾ: 10% കിഴിവ് 1000 TL-ൽ കൂടുതൽ വില ; മറ്റൊരു ഉപയോക്താവിൻ്റെ ഓർഡറുകൾ കാണുമ്പോൾ 403: (1) സ്റ്റാറ്റസ് കോഡ്, (2) പ്രതികരണം JSON സ്കീമ മൂല്യനിർണ്ണയം, (4) 200/201 വ്യക്തതയുള്ള ബിസിനസ്സ് നിയമവുമായി ബന്ധിപ്പിക്കരുത്

ശക്തമായ പ്രോംപ്റ്റ് കരാർ, ബിസിനസ്സ് നിയമങ്ങൾ, സുരക്ഷാ സാഹചര്യങ്ങൾ, സ്കീമ മൂല്യനിർണ്ണയ പ്രതീക്ഷ എന്നിവ നൽകുന്നു.

കരാർ പരിശോധന: ടീമുകൾ തമ്മിലുള്ള വേർപിരിയൽ തടയൽ

മൈക്രോസർവീസ് ആർക്കിടെക്ചറുകളിൽ (പരസ്പരം സ്വതന്ത്രവും API-യുമായി സംസാരിക്കുന്നതുമായ ചെറിയ സേവനങ്ങളായി ആപ്ലിക്കേഷൻ വിഭജിച്ചിരിക്കുന്ന ഘടന), ഒരു സേവനത്തിൻ്റെ പ്രതികരണ ഫോർമാറ്റ് മാറ്റുന്നത്, അതുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന മറ്റ് സേവനങ്ങളെ നിശബ്ദമായി തടസ്സപ്പെടുത്തുന്നു. കരാർ പരിശോധന - ദാതാവിൻ്റെ സേവനവും ഉപഭോക്തൃ സേവനവും തമ്മിലുള്ള API കരാർ ഇരുവശത്തും ലംഘിച്ചിട്ടില്ലെന്ന് സ്ഥിരീകരിക്കുന്ന ടെസ്റ്റ് - അത്തരം ഇടവേളകൾ നേരത്തെ പിടിക്കുന്നു. ആശയം ഇതാണ്: ഉപഭോക്താവ് നിർമ്മാതാവിൽ നിന്ന് താൻ പ്രതീക്ഷിക്കുന്ന പ്രതികരണത്തിൻ്റെ രൂപത്തെ ഒരു "കരാർ" ആയി നിർവചിക്കുന്നു; ഓരോ മാറ്റത്തിലും, നിർമ്മാതാവ് അത് ഇപ്പോഴും ഈ കരാറിന് അനുസൃതമാണെന്ന് പരിശോധിക്കുന്നു. അതിനാൽ ഒരു ഫീൽഡിൻ്റെ പേരോ തരമോ മാറുമ്പോൾ, അത് തകരാറിലാകുന്നതിന് മുമ്പ് ഉപഭോക്താവ് പൈപ്പ്ലൈനെ അറിയിക്കുന്നു.

ഈ സന്ദർഭത്തിൽ AI രണ്ട് ജോലികൾ ത്വരിതപ്പെടുത്തുന്നു: നിലവിലുള്ള ഒരു API പ്രതികരണത്തിൽ നിന്നുള്ള ഉപഭോക്തൃ പ്രതീക്ഷയെ പ്രതിഫലിപ്പിക്കുന്ന ഒരു കരാർ തയ്യാറാക്കുക, ഏത് കരാർ വ്യവസ്ഥയിൽ മാറ്റം വരുത്താമെന്ന് മുൻകൂട്ടി അടയാളപ്പെടുത്തുക. എന്നാൽ കരാർ തന്നെ ഒരു ബിസിനസ്സ് തീരുമാനമാണ്: ഏതൊക്കെ മേഖലകളാണ് യഥാർത്ഥത്തിൽ നിർണായകമെന്ന് വിദഗ്ദ്ധർ നിർണ്ണയിക്കുന്നു, ഏത് മാറ്റങ്ങൾ പിന്നോക്ക അനുയോജ്യതയെ തകർക്കും - പഴയ ഉപഭോക്താക്കൾ പ്രവർത്തിക്കുന്നത് തുടരുന്നു. AI കരാർ എഴുതുന്നു; അത് അംഗീകരിക്കുന്നത് നിങ്ങളാണ്.

നുറുങ്ങ്: ഒരു ഫീൽഡ് ഇല്ലാതാക്കുകയോ API-യിലെ ഫീൽഡ് തരം മാറ്റുകയോ ചെയ്യുന്നത് മിക്കവാറും എല്ലായ്‌പ്പോഴും ഒരു ബ്രേക്കിംഗ് മാറ്റമാണ്. പുതിയ ഫീൽഡുകൾ ചേർക്കുന്നത് സാധാരണയായി സുരക്ഷിതമാണ്. AI ഒരു മാറ്റത്തെ "ബ്രേക്കിംഗ് അല്ലെങ്കിൽ സേഫ്" എന്ന് തരംതിരിക്കുന്നത് ഒരു ദ്രുത-റിലീസ് സുരക്ഷാ പരിശോധന നൽകുന്നു.

പോസ്റ്റ്മാൻ അല്ലെങ്കിൽ കോഡ് അടിസ്ഥാനമാക്കി?

മാനദണ്ഡം

പോസ്റ്റ്മാൻ/ന്യൂമാൻ

വിശ്രമം ഉറപ്പ് / കോഡ് (Java, C#, JS)

പഠിക്കുന്നു

എളുപ്പം, ദൃശ്യം

കോഡ് പരിജ്ഞാനം ആവശ്യമാണ്

പതിപ്പ് നിയന്ത്രണം

ശേഖരം JSON

നേരിട്ട് സോഴ്സ് കോഡിൽ

സങ്കീർണ്ണമായ യുക്തി

ലിമിറ്റഡ് (JS സ്ക്രിപ്റ്റുകൾ)

പൂർണ്ണ പ്രോഗ്രാമിംഗ് പവർ

CI/CD സംയോജനം

ന്യൂമാൻ കൂടെ

നിർമ്മാണത്തെ നേരിട്ട് ആശ്രയിച്ചിരിക്കുന്നു

സ്കീമ മൂല്യനിർണ്ണയം

ടെസ്റ്റ് സ്ക്രിപ്റ്റുകൾക്കൊപ്പം

ലൈബ്രറി ഉപയോഗിച്ച് ശക്തമാണ്

ടീം സ്കെയിൽ

ചെറിയ/ഇടത്തരം

വലിയ, പക്വതയുള്ള

AI രണ്ടിനും കോഡ് സൃഷ്ടിക്കുന്നു; നിങ്ങൾക്ക് ഏതാണ് വേണ്ടതെന്ന് വ്യക്തമാക്കുക.

പകർത്താവുന്ന നാല് ടെംപ്ലേറ്റുകൾ

1) കരാർ അടിസ്ഥാനത്തിലുള്ള API ടെസ്റ്റിംഗ്:

നിങ്ങളുടെ റോൾ: സീനിയർ API ടെസ്റ്റ് എഞ്ചിനീയർ. ഇനിപ്പറയുന്ന എൻഡ്‌പോയിൻ്റിനായി [ഉപകരണം/ഭാഷ] ഉപയോഗിച്ച് ടെസ്റ്റുകൾ എഴുതുക: [രീതി + പാത]. കരാർ: [ആവശ്യമായ ഫീൽഡുകൾ, വിജയ കോഡ്, പ്രതികരണ ഘടന]. ബിസിനസ് നിയമങ്ങൾ: [നിയമങ്ങൾ]. ടെസ്റ്റ് ലെയറുകൾ: (1) സ്റ്റാറ്റസ് കോഡ് (2) പ്രതികരണ സ്കീമ മൂല്യനിർണ്ണയം (3) ഓരോ ബിസിനസ്സ് റൂളിലും പ്രസക്തമായ നിയമങ്ങൾ (4) നിഷേധാത്മകമായി ഉറപ്പിക്കുക.

2) സാമ്പിൾ പ്രതികരണത്തിൽ നിന്ന് സ്കീമ ജനറേഷൻ:

ചുവടെയുള്ള സാമ്പിൾ API പ്രതികരണത്തിൽ നിന്ന് JSON സ്കീമ സൃഷ്ടിക്കുക. ആവശ്യമായ ഫീൽഡുകൾ, തരങ്ങൾ, ഫോർമാറ്റ് നിയന്ത്രണങ്ങൾ (തീയതി, ഇമെയിൽ, നമ്പർ ശ്രേണി) വ്യക്തമാക്കുക. തുടർന്ന് ഈ സ്കീമയെ സാധൂകരിക്കുന്ന ഒരു ടെസ്റ്റ് ഉദാഹരണം നൽകുക. മാതൃകാ പ്രതികരണം: [JSON ഒട്ടിക്കുക]

3) നെഗറ്റീവ്, അംഗീകൃത സാഹചര്യങ്ങൾ:

എൻഡ് പോയിൻ്റിനായി നെഗറ്റീവ്, സെക്യൂരിറ്റി ടെസ്റ്റ് കേസുകൾ സൃഷ്ടിക്കുക[എൻഡ് പോയിൻ്റ്]. ഉൾപ്പെടുന്നവ: നഷ്‌ടമായ/ആവശ്യമായ ഫീൽഡ്, തെറ്റായ തരം, വളരെ വലിയ മൂല്യം, അസാധുവായ/കാലഹരണപ്പെട്ട ടോക്കൺ, അനധികൃത ഉറവിടത്തിലേക്കുള്ള ആക്‌സസ് (IDOR — ഐഡി മാറ്റുന്നതിലൂടെ മറ്റൊരാളുടെ റെക്കോർഡിലേക്കുള്ള ആക്‌സസ്), നിരക്ക് പരിധി. ഓരോ സാഹചര്യത്തിനും പ്രതീക്ഷിക്കുന്ന സ്റ്റാറ്റസ് കോഡും പിശക് ബോഡിയും വ്യക്തമാക്കുക. ശ്രദ്ധിക്കുക: അംഗീകൃതമായ എൻ്റെ സ്വന്തം API-യിൽ മാത്രമേ പരീക്ഷിക്കൂ.

4) കപട വിശ്വാസ നിയന്ത്രണം:

ഈ API ടെസ്റ്റ് പരിശോധിക്കുക. സെർവർ ശരിയായ സ്റ്റാറ്റസ് കോഡ് നൽകിയാൽ ഈ പരിശോധന പിടിക്കപ്പെടുമോ, എന്നാൽ FALSEbody/data? ഇല്ലെങ്കിൽ, സ്കീമയും ബിസിനസ് റൂൾ മൂല്യനിർണ്ണയവും ചേർക്കുക. ടെസ്റ്റ്: [പേസ്റ്റ് ടെസ്റ്റ്]

മൂന്ന് മിനി കേസുകൾ

കേസ് 1 - സ്കീമ മൂല്യനിർണ്ണയത്തിൻ്റെ ശക്തി. ഒരു ടീം AI ഉപയോഗിച്ച് നിർമ്മിച്ച ടെസ്റ്റുകളിലെ സ്റ്റാറ്റസ് കോഡ് മാത്രമാണ് പരിശോധിക്കുന്നത്. ഒരു പതിപ്പിൽ, API മൊത്തം ഫീൽഡ് ടെക്‌സ്‌റ്റായി ("1200") തെറ്റായി തിരികെ നൽകാൻ തുടങ്ങി; പരിശോധനകൾ പച്ചയായി തുടർന്നു, കാരണം അത് ഇപ്പോഴും 200 മടങ്ങുന്നു. മൊബൈൽ ആപ്ലിക്കേഷൻ തകരാറിലായി. "സാമ്പിൾ പ്രതികരണത്തിൽ നിന്നുള്ള സ്കീമ ജനറേഷൻ" ടെംപ്ലേറ്റിനൊപ്പം തരം മൂല്യനിർണ്ണയം ചേർത്തതിന് ശേഷം, അതേ പിശക് ഉടനടി പിടിക്കപ്പെട്ടു.

കേസ് 2 - അധികാര വിടവ് (IDOR). AI സൃഷ്ടിച്ച "നെഗറ്റീവ്, ഓതറൈസേഷൻ സാഹചര്യങ്ങൾ"ക്കിടയിൽ ഒരു വിദഗ്ധൻ IDOR ടെസ്റ്റ് നടത്തി: ഉപയോക്താവ് A യുടെ ടോക്കൺ സഹിതം അവൻ B എന്ന ഉപയോക്താവിൻ്റെ ഓർഡർ ഐഡി അഭ്യർത്ഥിച്ചു. API 200-ൻ്റെയും B-യുടെയും ഡാറ്റ തിരികെ നൽകി - ഗുരുതരമായ ഒരു അംഗീകൃത അപകടസാധ്യത. ഈ പ്രതിരോധ പരിശോധന തത്സമയമാകുന്നതിന് മുമ്പ് ഡാറ്റ ചോർച്ച അടച്ചു.

കേസ് 3 - ബിസിനസ് റൂൾ ബൈപാസ്. ഡിസ്കൗണ്ട് എൻഡ് പോയിൻ്റിനായി AI 8 ടെസ്റ്റുകൾ സൃഷ്ടിച്ചു; എല്ലാവരും 200 പരിശോധിക്കുന്നു, ആരും കിഴിവ് തുക പരിശോധിച്ചില്ല. വിദഗ്ധൻ ബിസിനസ്സ് നിയമങ്ങൾ പ്രോംപ്റ്റിലേക്ക് ചേർക്കുകയും അവ പുനർനിർമ്മിക്കുകയും ചെയ്തു. 1000 TL പരിധിയിൽ കിഴിവ് തെറ്റായി കണക്കാക്കിയതായി പുതിയ പരിശോധനകൾ വെളിപ്പെടുത്തി (കിഴിവ് 999 നും ബാധകമാക്കി). കരാർ നിയന്ത്രണം പോരാ; ബിസിനസ് റൂൾ നിയന്ത്രണം അനിവാര്യമാണ്.

സാധാരണ തെറ്റുകൾ

  • സ്റ്റാറ്റസ് കോഡ് നോക്കിയാൽ മതി. "200 തിരിച്ചെത്തി കടന്നുപോയി" എന്ന് പറയാൻ; ദുഷിച്ച ശരീരം കാണുന്നില്ല (തെറ്റായ വിശ്വാസം).
  • സ്കീമ മൂല്യനിർണ്ണയം മറികടക്കുന്നു. ഫീൽഡ് തരങ്ങളും ബാധ്യതകളും പരിശോധിക്കുന്നില്ല; തരം മാറ്റങ്ങൾ നിശബ്ദമായി കടന്നുപോകുന്നു.
  • ബിസിനസ്സ് നിയമങ്ങൾ നൽകാതെ പരിശോധന അഭ്യർത്ഥിക്കുന്നു. AI-ക്ക് നിയമങ്ങൾ അറിയില്ല; അത് സാങ്കേതിക നിയന്ത്രണം മാത്രമാണ് ഉൽപ്പാദിപ്പിക്കുന്നത്.
  • നെഗറ്റീവ്, അർഹതയുള്ള സാഹചര്യങ്ങൾ മറക്കുന്നു. സുരക്ഷാ കേടുപാടുകൾ (IDOR, അനധികൃത ആക്സസ്) ഈ പരിശോധനകളിലൂടെ മാത്രമേ പിടിക്കപ്പെടുകയുള്ളൂ.
  • യഥാർത്ഥ/പ്രൊഡക്ഷൻ ടോക്കണുകളും ഡാറ്റയും ഉപയോഗിക്കുന്നു. പരിശോധനയ്ക്കായി സമർപ്പിത മീഡിയയും സിന്തറ്റിക് ഡാറ്റയും ഉപയോഗിക്കുക; വാഹനത്തിൽ യഥാർത്ഥ താക്കോലുകൾ ഒട്ടിക്കരുത്.
  • അനധികൃത സുരക്ഷാ പരിശോധന. നിങ്ങളുടെ സ്വന്തം API-യിലും അനുമതിയോടെയും മാത്രം അംഗീകാര പരിശോധനകൾ നടത്തുക.

ചുരുക്കത്തിൽ

ഇൻ്റർഫേസ് പരിഗണിക്കാതെ തന്നെ, സോഫ്‌റ്റ്‌വെയർ ശകലങ്ങളുടെ സംഭാഷണം വേഗത്തിലും ആഴത്തിലും API പരിശോധന പരിശോധിക്കുന്നു. AI; സാമ്പിൾ പ്രതികരണത്തിൽ നിന്ന് JSON സ്കീമയും നെഗറ്റീവ്/സെക്യൂരിറ്റി സാഹചര്യങ്ങളും സൃഷ്ടിക്കുന്നതിൽ കരാർ ടെസ്റ്റുകൾ വളരെ കാര്യക്ഷമമാണ്. എന്നാൽ സ്റ്റാറ്റസ് കോഡ് മാത്രം പരിശോധിക്കുന്ന ഉപരിപ്ലവമായ പരിശോധനകൾ കപട ആത്മവിശ്വാസം നൽകുന്നു. നാല് ലെയറുകളും ആവശ്യമാണ്: സ്റ്റാറ്റസ് കോഡ്, സ്കീമ മൂല്യനിർണ്ണയം, ബിസിനസ് റൂൾ, നെഗറ്റീവ്, അംഗീകാരം. ബിസിനസ്സ് നിയമങ്ങളും കരാറുകളും പ്രോംപ്റ്റിൽ ഇടുക; സിന്തറ്റിക് ഡാറ്റ ഉപയോഗിച്ച് സുരക്ഷാ പരിശോധനകൾ നടത്തുക, അംഗീകാരത്തോടെ മാത്രം.

ആപ്ലിക്കേഷൻ ടാസ്ക്

നിങ്ങളുടെ സ്വന്തം പ്രോജക്റ്റിൽ നിന്ന് ഒരു API എൻഡ്‌പോയിൻ്റ് തിരഞ്ഞെടുക്കുക. "കരാർ അടിസ്ഥാനമാക്കിയുള്ള API ടെസ്റ്റിംഗ്" ടെംപ്ലേറ്റ് ഉപയോഗിച്ച് നാല്-ലെയർ ടെസ്റ്റുകൾ എഴുതാൻ AI-യെ അനുവദിക്കുക. തുടർന്ന് "സാമ്പിൾ പ്രതികരണത്തിൽ നിന്നുള്ള സ്കീമ ജനറേഷൻ" എന്നതിനൊപ്പം ടൈപ്പ്/എൻഫോഴ്‌സ്‌മെൻ്റ് മൂല്യനിർണ്ണയം ചേർത്ത് "സ്യൂഡോ-ട്രസ്റ്റ് ചെക്കിംഗ്" പ്രയോഗിക്കുക. നിങ്ങളുടെ സ്വന്തം ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ കുറഞ്ഞത് ഒരു IDOR/അംഗീകൃത സാഹചര്യമെങ്കിലും പ്രവർത്തിപ്പിക്കുക. നിങ്ങൾ കണ്ടെത്തുന്ന ഏതെങ്കിലും കരാർ അല്ലെങ്കിൽ ബിസിനസ് നിയമ ലംഘനങ്ങൾ റിപ്പോർട്ട് ചെയ്യുക; നിങ്ങൾക്ക് ഒന്നും കണ്ടെത്താൻ കഴിയുന്നില്ലെങ്കിൽ, അത് പിടിച്ചെന്ന് തെളിയിക്കാൻ മനഃപൂർവ്വം വികലമായ പ്രതികരണത്തിനെതിരെ ടെസ്റ്റ് നടത്തുക.

ചെക്ക്ലിസ്റ്റ്

  • [ ] ഞാൻ പരിശോധനയുടെ നാല് പാളികൾ കവർ ചെയ്തു (കേസ്, സ്കീമ, ബിസിനസ് റൂൾ, നെഗറ്റീവ്/അംഗീകാരം).
  • [ ] ഞാൻ കരാറും ബിസിനസ്സ് നിയമങ്ങളും AI യ്ക്ക് വ്യക്തമായി നൽകി.
  • [ ] പ്രതികരണ സ്കീമ (ഫീൽഡ്, തരം, നിർബന്ധിതം) സാധൂകരിക്കുന്ന ടെസ്റ്റുകൾ ഞാൻ സജ്ജീകരിച്ചു.
  • [ ] ഞാൻ പ്രതിരോധത്തിനായി ഒരു അംഗീകാരം/IDOR സാഹചര്യമെങ്കിലും പരീക്ഷിച്ചു.
  • [ ] ഞാൻ യഥാർത്ഥ ടോക്കൺ/ഡാറ്റയ്ക്ക് പകരം ടെസ്റ്റ് എൻവയോൺമെൻ്റും സിന്തറ്റിക് ഡാറ്റയും ഉപയോഗിച്ചു.
  • [ ] എല്ലാ ടെസ്റ്റുകളും കേടായ പ്രതികരണം പിടിക്കുമെന്ന് ഞാൻ ഒരു "കപട-വിശ്വാസ പരിശോധന" ഉപയോഗിച്ച് തെളിയിച്ചു.