Добици:
- Способност да се изврши детаљно тестирање АПИ-ја уз подршку вештачке интелигенције на слојевима статусног кода, шеме/уговора, пословног правила и негативних/ауторизационих слојева
- Способност генерисања ЈСОН шеме из узорка одговора и избегавање псеудопоуздања гледања само у статусни код са типом и императивном валидацијом
- Могућност тестирања безбедносних сценарија као што су ауторизација и ИДОР са синтетичким подацима иу одбрамбене сврхе само у оквиру ауторизације
Већина модерних софтвера разговара једни са другима у позадини преко АПИ-ја (Апплицатион Программинг Интерфаце — интерфејс где два дела софтвера разговарају у складу са одређеним уговором). Када мобилна апликација додаје артикле у корпу, она заправо шаље захтев АПИ-ју на серверу. АПИ тестирање проверава да ли је овај разговор исправан, безбедан и доследан, без обзира на интерфејс; Бржи је, стабилнији и дубљи од тестирања корисничког интерфејса. Вештачка интелигенција (АИ) је веома ефикасна у тестирању АПИ-ја: генерише тестове из дефиниције АПИ-ја, издваја шему одговора (уговор који дефинише структуру података), наводи рубне случајеве. Али опет важи централно упозорење: АИ не познаје права пословна правила вашег АПИ-ја; тежи да произведе површне тестове који потврђују само „200 враћених“. Ваш посао је да проверите да ли тест потврђује стварни уговор и пословну логику.
У овој јединици ћете научити како да подесите дубоке АПИ тестове подржане вештачком интелигенцијом са приступима као што су Постман, РЕСТ Ассуред и валидација шеме.
Слојеви АПИ тестирања
Размислите о тестирању АПИ-ја у неколико дубина, при чему АИ помаже различито на сваком слоју:
1. Статусни код и основни одговор. Да ли захтев враћа очекивани ХТТП статусни код (200/201 за успех, 400/401/404 за грешку)? Ово је најповршнији слој; АИ производи лако, али сама даје лажно поверење.
2. Валидација шеме/уговора. Да ли структура одговора одговара уговору — да ли су присутна очекивана поља, да ли су њихови типови тачни, да ли недостају обавезна поља? АИ може да генерише ЈСОН шему — стандард који дефинише структуру ЈСОН документа — из узорка одговора, а тестови могу да се потврде у односу на ту шему. Ово је много робусније од ручног писања тврдње засноване на терену.
3. Валидација пословних правила. Права вредност је овде: „За поруџбину од 1000 ТЛ, поље попуста треба да буде 100“, „поништена поруџбина се не може поново отказати“. АИ ће ово потврдити само ако му дате правила; Ако га не даш, скочиће.
4. Негативно и сигурносно. 401 за неважећи токен, 403 за приступ туђим подацима, брисање 400 за лоше тело. Тестови ауторизације (који потврђују да корисник може да приступи само својим подацима) су срце безбедности АПИ-ја и раде се у одбрамбене сврхе.
Савет: Не захтевајте тест, а да не кажете АИ да „потврди не само статусни код, већ и шему одговора и та пословна правила“. У супротном, биће вам остављени тестови који кажу „200 враћено, прошло“, али нећете приметити да АПИ враћа оштећене податке.
Слаби промпт / Јаки промпт
Слабо: „Напишите тестове за овај АПИ.“
Снажно: „Напишите РЕСТ Ассуред (Јава) тестове за крајњу тачку ПОСТ/поруџбине. Договор: ИД производа и количина су обавезни у телу; 201 и {ордерИд, тотал, дисцоунт, статус} се враћају након успеха. Пословна правила: 10% попуста преко 1000 ТЛ; 400 ако је друго ако је неважеће; Тестови корисника: (1) статусни код, (2) провера ЈСОН шеме, (3) пословно правило за попуст, (4) везуј свако тврдње са експлицитним пословним правилом.“
Моћни промпт даје уговор, пословна правила, безбедносне сценарије и очекивања валидације шеме.
Тестирање уговора: спречавање распада између тимова
У архитектури микросервиса (структура у којој је апликација подељена на мале услуге које су независне једна од друге и разговарају са АПИ-јем), промена формата одговора услуге тихо омета друге услуге повезане са њом. Тестирање уговора — тест који потврђује да АПИ уговор између услуге провајдера и потрошачке услуге није прекинут са обе стране — рано открива такве прекиде. Идеја је следећа: потрошач дефинише облик одговора који очекује од произвођача као „уговор“; Са сваком променом, произвођач тестира да ли је и даље у складу са овим уговором. Дакле, када се промени име или тип поља, потрошач обавештава цевовод пре него што се сруши.
АИ убрзава два задатка у овом контексту: израду нацрта уговора који одражава очекивања потрошача од постојећег одговора АПИ-ја и претходно означавање клаузуле уговора која би промена могла да прекине. Али сам уговор је пословна одлука: стручњак одређује које области су заиста критичне, које промене ће прекинути компатибилност унатраг — стари потрошачи настављају да раде. АИ пише уговор; Ви сте тај који то одобрава.
Савет: Брисање поља или промена типа поља у АПИ-ју је скоро увек критична промена. Додавање нових поља је обично безбедно. Ако АИ класификује промену као „безболну или безбедну“, обезбеђује брзу безбедносну проверу пре објављивања.
Поштар или на основу кода?
критеријум
Поштар/Њумен
Осигуран РЕСТ / код (Јава, Ц#, ЈС)
Учење
Лако, визуелно
Потребно познавање кода
Контрола верзија
Колекција ЈСОН
Директно у изворном коду
сложена логика
Ограничено (ЈС скрипте)
Пуна моћ програмирања
ЦИ/ЦД интеграција
са Њуманом
Директно зависи од градње
Валидација шеме
Са тест скриптама
Моћан са библиотеком
Тимска скала
мала/средња
велики, зрео
АИ генерише код за оба; Будите јасни који желите.
Четири шаблона за копирање
1) АПИ тестирање на основу уговора:
Ваша улога: виши инжењер за тестирање АПИ-ја. Напишите тестове за следећу крајњу тачку помоћу [алатка/језика]: [метода + путање].Уговор: [обавезна поља, код успеха, структура одговора].Пословна правила: [правила].Слојеви тестирања: (1) статусни код (2) валидација шеме одговора (3) свако пословно правило (4) негативно + ауторизација. Повежите свако релевантно правило као/уговарање.
2) Генерисање шеме из одговора узорка:
Генеришите ЈСОН шему из примера АПИ одговора у наставку. Наведите обавезна поља, типове, ограничења формата (датум, емаил, опсег бројева). Затим дајте тест пример који потврђује ову шему. Пример одговора: [налепите ЈСОН]
3) Негативни сценарији и сценарији ауторизације:
Генеришите негативне и безбедносне тестове за крајњу тачку[ендпоинт]. Укључује: недостаје/обавезно поље, погрешан тип, превелика вредност, неважећи/истекли токен, приступ неовлашћеном ресурсу (ИДОР — приступ туђем запису променом ИД-а), ограничење стопе. Наведите очекивани статусни код и тело грешке за сваки сценарио. Напомена: биће тестиран само на мом сопственом АПИ-ју, овлашћеном.
4) Контрола псеудо поверења:
Погледајте овај АПИ тест. Да ли би овај тест ухватио ако сервер врати тачан статусни код али ФАЛСЕбоди/податке? Ако не, додајте шему и валидацију пословног правила. Тест: [пасте тест]
три мини кофера
Случај 1 — Моћ валидације шеме. Тим је само проверавао статусни код у тестовима које је произвео са АИ. У једној верзији, АПИ је почео грешком да враћа укупно поље као текст („1200“); тестови су остали зелени јер је и даље враћао 200. Мобилна апликација је пала. Након додавања валидације типа са шаблоном „Генерисање шеме из узорка одговора“, иста грешка је одмах ухваћена.
Случај 2 — Недостатак ауторитета (ИДОР). Експерт је извршио ИДОР тест између „негативног сценарија и сценарија ауторизације“ који је генерисао АИ: Захтевао је ИД налога корисника Б са токеном корисника А. АПИ је вратио податке од 200 и Б – озбиљну рањивост ауторизације. Овај одбрамбени тест затворио је цурење података пре него што је објављен.
Случај 3 — Заобилажење пословних правила. АИ је генерисао 8 тестова за крајњу тачку попуста; сви су проверавали 200, нико није верификовао износ попуста. Стручњак је додао пословна правила у упит и дао их репродуковати. Нови тестови су открили да је попуст погрешно израчунат на граници од 1000 ТЛ (попуст је такође примењен на 999). Контрола уговора није довољна; Контрола пословних правила је неопходна.
Уобичајене грешке
- Само гледам статусни код. Да каже „200 се вратило и прошло“; не видећи покварено тело (лажно поверење).
- Заобилажење валидације шеме. Не проверава врсте поља и обавезе; промене типа пролазе нечујно.
- Захтевање тестирања без навођења правила пословања. АИ не познаје правила; производи само техничку контролу.
- Заборављање негативних сценарија и сценарија права. Безбедносне рањивости (ИДОР, неовлашћени приступ) откривају се само овим тестовима.
- Коришћење стварних/производних токена и података. Користите наменске медије и синтетичке податке за тестирање; Не стављајте праве кључеве у возило.
- Неовлашћено тестирање безбедности. Покрените тестове ауторизације само на свом АПИ-ју и уз дозволу.
Укратко
АПИ тестирање верификује говор делова софтвера брзо и дубоко, без обзира на интерфејс. АИ; уговорни тестови су веома ефикасни у генерисању ЈСОН шеме и негативних/безбедносних сценарија из одговора узорка. Али површни тестови који само проверавају статусни код дају псеудопоуздање. Захтевају сва четири слоја: статусни код, валидацију шеме, пословно правило, негатив и ауторизацију. Ставите правила пословања и уговор на промпту; Извршите безбедносне тестове са синтетичким подацима и само са ауторизацијом.
Задатак апликације
Изаберите крајњу тачку АПИ-ја из сопственог пројекта. Нека АИ напише четворослојне тестове са шаблоном „АПИ тестирање на основу уговора“. Затим додајте проверу типа/примену са „генерисањем шеме из узорка одговора“ и примените „проверу псеудо поверења“. Покрените најмање један ИДОР/ауторизациони сценарио у сопственом тестном окружењу. Пријавите све повреде уговора или правила пословања које пронађете; Ако не можете да их пронађете, покрените тест са намерно искривљеним одговором да бисте доказали да га је ухватио.
контролна листа
- [ ] Покрио сам четири слоја тестирања (случај, шема, пословно правило, негативна/ауторизација).
- [ ] Јасно сам дао уговор и пословна правила АИ.
- [ ] Поставио сам тестове који потврђују шему одговора (поље, тип, императив).
- [ ] Покушао сам бар један сценарио ауторизације/ИДОР у одбрани.
- [ ] Користио сам тестно окружење и синтетичке податке уместо правих токена/података.
- [ ] Доказао сам са „провером псеудопоуздања“ да сваки тест открива неисправан одговор.