Добивки:
- Способност да се спроведе длабинско тестирање на API со поддршка за вештачка интелигенција на статусен код, шема/договор, деловно правило и негативни/овластувачки слоеви
- Способност да се генерира JSON шема од примерок одговор и да се избегне псевдодовербата да се гледа само статусниот код со тип и императивна валидација
- Способност да се тестираат безбедносни сценарија како овластување и IDOR со синтетички податоци и за одбранбени цели само во рамките на овластувањето
Повеќето модерни софтвери разговараат меѓу себе во заднина преку API (Application Programming Interface — интерфејс каде што два софтвери разговараат според одреден договор). Кога мобилната апликација додава ставки во количката, таа всушност испраќа барање до API на серверот. Тестирањето на API проверува дали овој разговор е точен, безбеден и конзистентен, без оглед на интерфејсот; Тој е побрз, постабилен и подлабок од тестирањето на UI. Вештачката интелигенција (АИ) е многу ефикасна во тестирањето на API: генерира тестови од дефиниција на API, ја извлекува шемата за одговор (договорот што ја дефинира структурата на податоците), наведува случаи на рабови. Но, повторно важи централното предупредување: вештачката интелигенција не ги знае вистинските деловни правила на вашиот API; има тенденција да произведе површни тестови кои само потврдуваат „вратени 200“. Ваша задача е да бидете сигурни дека тестот ги потврдува вистинскиот договор и деловната логика.
Во оваа единица, ќе научите како да поставите длабоки API тестови поддржани со вештачка интелигенција со пристапи како што се Postman, REST Assured и валидација на шема.
Слоеви на API тестирање
Размислете за тестирање на API во неколку длабочини, при што вештачката интелигенција помага поинаку во секој слој:
1. Шифра за статус и основен одговор. Дали барањето го враќа очекуваниот статус на HTTP код (200/201 за успех, 400/401/404 за грешка)? Ова е најповршниот слој; ВИ произведува лесно, но сама по себе дава лажна доверба.
2. Валидација на шема/договор. Дали структурата на одговорот одговара на договорот - дали се присутни очекуваните полиња, дали се точни нивните типови, дали недостасуваат задолжителни полиња? Вештачката интелигенција може да генерира JSON Шема - стандард што ја дефинира структурата на документот JSON - од примерок одговор, а тестовите може да се потврдат според таа шема. Ова е многу поцврсто од рачно пишување тврдење базирано на терен.
3. Потврда на деловните правила. Вистинската вредност е тука: „За нарачка од 1000 TL, полето за попуст треба да биде 100“, „откажана нарачка не може повторно да се откаже“. ВИ ќе ги потврди само ако и ги дадете правилата; Ако не го дадеш, ќе скокне.
4. Негативно и сигурност. 401 за неважечки токен, 403 за пристап до туѓи податоци, исчистете 400 за лошо тело. Тестовите за овластување (потврда дека корисникот може да пристапи само до сопствените податоци) се срцето на безбедноста на API и се прават за одбранбени цели.
Совет: Не барајте тест без да ѝ кажете на вештачката интелигенција „да ја потврди не само статусната шифра, туку и шемата за одговор и тие деловни правила“. Во спротивно, ќе останете со тестови на кои пишува „200 се вратија, поминаа“, но нема да забележите дека API враќа оштетени податоци.
Слаб промпт / Силен промпт
Слабо: „Напишете тестови за овој API“.
Силно: "Напишете REST Assured (Java) тестови за POST /крајната точка на нарачката. Договорот: productId и количината се задолжителни во телото; 201 и {orderId, total, discount, status} се враќаат по успех. Деловни правила: 10% попуст над 1000 TL; 400 ако 400 во вредност од 1 до 40. гледање нарачка на друг корисник: (1) статусен код, (2) валидација на шемата JSON, (3) деловно правило за попуст, (4) врзување на секое тврдење со експлицитно деловно правило.
Моќното известување го дава договорот, деловните правила, безбедносните сценарија и очекувањата за валидација на шемата.
Тестирање на договор: спречување на распади меѓу тимовите
Во микросервисните архитектури (структурата во која апликацијата е поделена на мали сервиси кои се независни една од друга и разговараат со API), менувањето на форматот на одговор на услугата тивко ги нарушува другите услуги поврзани со неа. Тестирање на договор - тестот што потврдува дека договорот за API помеѓу услугата на давателот и услугата за потрошувачи не е прекинат од двете страни - ги фаќа таквите прекини рано. Идејата е следна: потрошувачот ја дефинира формата на одговор што ја очекува од производителот како „договор“; Со секоја промена, производителот тестира дали сè уште е во согласност со овој договор. Значи, кога името или типот на полето се менува, потрошувачот го известува гасоводот пред да се сруши.
Вештачката интелигенција забрзува две задачи во овој контекст: изготвување договор што ги одразува очекувањата на потрошувачите од постојниот одговор на API и претходно означување која договорна клаузула може да ја прекине промената. Но, самиот договор е деловна одлука: експертот одредува кои области се навистина критични, кои промени ќе ја нарушат компатибилноста наназад - старите потрошувачи продолжуваат да работат. АИ го пишува договорот; Вие сте тој што го одобрува тоа.
Совет: Бришењето поле или менувањето на типот на полето во API е скоро секогаш прекршна промена. Додавањето нови полиња обично е безбедно. Ако вештачката интелигенција ја класифицира промената како „скршена или безбедна“ обезбедува брза безбедносна проверка пред објавувањето.
Поштар или базиран на код?
критериум
Поштар/Њумен
ОСИГУРЕН / код (Java, C#, JS)
Учење
Лесно, визуелно
Потребно е познавање на кодот
Контрола на верзијата
Колекција JSON
Директно во изворниот код
сложена логика
Ограничено (JS скрипти)
Целосна програмска моќ
CI/CD интеграција
со Њуман
Директно зависна од градбата
Потврда на шемата
Со тест скрипти
Моќен со библиотека
Тимска скала
мали/средни
голем, зрел
AI генерира код и за двете; Биди јасен кој сакаш.
Четири шаблони за копирање
1) Тестирање на API засновано на договор:
Вашата улога: виш инженер за тестирање на API. Напишете тестови за следната крајна точка со [алатка/јазик]: [метод + патека]. Договор: [задолжителни полиња, код за успех, структура на одговор]. Деловни правила: [правила]. Тест слоеви: (1) статусен код (2) валидација на шемата за одговор (3) секое деловно правило за авторизација.
2) Генерирање шема од одговор на примерокот:
Генерирајте JSON шема од примерокот за одговор на API подолу. Наведете ги потребните полиња, типови, ограничувања за формат (датум, е-пошта, опсег на броеви). Потоа дајте пример за тестирање што се потврдува во однос на оваа шема. Примерок одговор: [залепи JSON]
3) Негативни и овластени сценарија:
Генерирајте негативни и безбедносни случаи на тест за крајна точка[крајна точка]. Вклучува: недостасува/задолжително поле, погрешен тип, преголема вредност, неважечки/истечен токен, пристап до неовластен ресурс (IDOR — пристап до туѓ запис со промена на ID), ограничување на стапката. Наведете го очекуваниот статусен код и телото за грешка за секое сценарио. Забелешка: ќе се тестира само на моето сопствено API, овластено.
4) Псевдо-доверба контрола:
Проверете го овој API тест. Дали овој тест ќе се фати ако серверот ја врати точната статусна шифра, но FALSEbody/податоци? Ако не, додадете валидација на шема и деловни правила. Тест: [залепи тест]
три мини футроли
Случај 1 - Моќта на валидација на шемата. Тим само ја проверуваше статусната шифра во тестовите што ги направи со вештачка интелигенција. Во една верзија, API почна погрешно да го враќа вкупното поле како текст („1200“); тестовите останаа зелени бидејќи сè уште враќаше 200. Падна мобилната апликација. По додавањето валидација на типот со шаблонот „Генерирање на шема од одговор на примерок“, истата грешка веднаш беше фатена.
Случај 2 - Јаз во авторитет (IDOR). Експерт го спроведе IDOR тестот помеѓу „негативното и овластување сценарија“ генерирано од вештачката интелигенција: тој побара ID на нарачката на корисникот B со токенот на корисникот А. API врати податоци од 200 и B - сериозна ранливост за авторизација. Овој одбранбен тест го затвори истекувањето на податоците пред да започне во живо.
Случај 3 - Заобиколување на деловните правила. ВИ генерира 8 тестови за крајната точка на попустот; сите проверуваа 200, никој не го потврдуваше износот на попустот. Експертот ги додал деловните правила на известувањето и ги репродуцирал. Новите тестови открија дека попустот е погрешно пресметан на лимитот од 1000 TL (попустот е применет и на 999). Контролата на договорот не е доволна; Контролата на деловните правила е задолжителна.
Вообичаени грешки
- Само гледајќи го статусниот код. Да се каже „200 се вратија и поминаа“; не гледање на расипано тело (лажна доверба).
- Заобиколувајќи ја валидацијата на шемата. Непроверување на видовите и обврските на полињата; промените на типот минуваат тивко.
- Барање тестирање без обезбедување деловни правила. ВИ не ги знае правилата; произведува само техничка контрола.
- Заборавајќи на негативни сценарија и права. Безбедносните пропусти (IDOR, неовластен пристап) се фатени само со овие тестови.
- Користење на реални/производствени токени и податоци. Користете посветен медиум и синтетички податоци за тестирање; Не ставајте вистински клучеви во возилото.
- Неовластено безбедносно тестирање. Извршете само тестови за авторизација на сопствен API и со дозвола.
Сумирано
Тестирањето на API го проверува говорот на парчиња софтвер брзо и длабоко, без оглед на интерфејсот. ВИ; тестовите за договор се многу ефикасни за генерирање на JSON шема и негативни/безбедносни сценарија од одговорот на примерокот. Но, површните тестови кои само ја проверуваат статусната шифра даваат псевдодоверба. Потребни се сите четири слоеви: статусен код, валидација на шема, деловно правило, негативен и авторизација. Ставете ги деловните правила и договорот на барање; Вршете безбедносни тестови со синтетички податоци и само со овластување.
Задача за апликација
Изберете крајна точка на API од вашиот сопствен проект. Нека вештачката интелигенција пишува четирислојни тестови со шаблонот „АПИ тестирање базирано на договор“. Потоа додадете валидација на тип/спроведување со „генерирање шема од одговор на примерок“ и примени „проверка на псевдодоверба“. Извршете барем едно сценарио за IDOR/овластување во вашата сопствена околина за тестирање. Пријавете ги сите прекршувања на договорот или деловните правила што ќе ги најдете; Ако не можете да најдете, извршете го тестот против намерно погрешен одговор за да докажете дека го фатил.
листа за проверка
- [ ] Ги опфатив четирите слоеви на тестирање (случај, шема, деловно правило, негативно/овластување).
- [ ] Јасно ги дадов договорот и деловните правила на АИ.
- [ ] Поставив тестови кои ја потврдуваат шемата за одговор (поле, тип, императив).
- [ ] Пробав барем едно сценарио за авторизација/IDOR дефанзивно.
- [ ] Користев тест околина и синтетички податоци наместо вистински токен/податоци.
- [ ] Докажав со „проверка на псевдодоверба“ дека секој тест го фаќа корумпираниот одговор.