Добивки:
- Способност да се дизајнира улогата на вештачката интелигенција и точките за одобрување на човекот во протокот на QA од крај до крај од идеја до објавување во контекст на CI/CD
- Во CI/CD, не овластување вештачка интелигенција автоматски да го „положи“ тестот, туку применува ограничувања за заштита на доверливите податоци и клучеви
- Способност да се изврши безбедносно тестирање во рамките на овластувањата и за одбранбени цели и да се усвојат принципи за одговорно откривање и етичка транспарентност.
Во претходните десет единици користевме вештачка интелигенција во поединечни задачи: генерирање сценарија, код за автоматизација, известување за грешки, анализа на покриеност, тестирање на мутации. Оваа последна единица ги комбинира сите во еден одговорен работен тек. Модерната ОК не е работа што завршува на бирото на една личност; Тоа е процес кој живее во рамките на CI/CD (Континуирана интеграција / Континуирана испорака - цевковод каде кодот постојано се комбинира, автоматски се тестира и се подготвува за објавување често и безбедно). ВИ може да ја допре секоја фаза од овој процес. Но, како што расте моќта на вештачката интелигенција, така се зголемува и важноста за нејзино одговорно користење: приватност, авторитет во безбедносното тестирање, етика и што е најважно, одржување на квалитетот на одлуката на човекот. Во оваа единица, ќе научите проток и граници од крај до крај.
Проток на QA со вештачка интелигенција од крај до крај
Улогата на вештачката интелигенција во патувањето на функцијата од идеја до објавување:
1. Анализа на барањата. Вештачката интелигенција означува нејаснотии во барањата и недостасуваат критериуми за прифаќање („ова правило не кажува колку знаци лозинката е минимална“).
2. Дизајн на тест. Нацртите на сценарија и случаи (целина 2), случаи на рабови (единица 3) се меѓу критериумите за прифаќање.
3. Автоматизација. Единица (6), API (5) и UI (4) нацрт-кодови за тестирање; секој е потврден со мутација (10).
4. CI/CD интеграција. Тестовите се извршуваат автоматски со секое спојување на кодот. Вештачката интелигенција ја нацрта конфигурацијата на гасоводот (YAML), ги сумира дневниците на неуспешните тестови, сугерира можна основна причина.
5. Одлука за ослободување. Резултатите од анализата на ризик (8) и регресијата (9) се собираат - но експертот одлучува дали може да биде успешна.
6. Следење на производството и повратни информации. Грешките во живо стануваат идни тестови; AI предлага случај на регресија од производствен дефект.
Совет: поставете вештачка интелигенција како слој во CI/CD што „ги забрзува нацртите прегледани од човек“ наместо „да пишува тестови и да донесува одлуки“. Ниту еден автоматски генериран тест не треба да влезе во нафтоводот без човечко испитување и одобрување.
AI во CI/CD: каде да, каде не
Фаза
ВИ одговара
човекот е суштински
Тест нацрт-код
Да
Ревизија + мутација
Нафтоводот YAML нацрт
Да
Автентикација + проверка на таен клуч
Неуспешно резиме на дневникот
Да
Потврда за основната причина
Кревка тест дијагноза
Да
Одлука за трајно решение
„Дали може да има верзија?
бр
Стручна проценка и одговорност
Автоматски „положете“ го тестот
никогаш
-
Внимание: Никогаш не давајте на вештачката интелигенција мандат како „поправете го за да го помине тестот што не успеа“ во CI/CD. Ова ја поразува целта на тестирањето и автоматски ги прикрива грешките. ВИ може да ја објасни грешката, да предложи корекција; но „боење на тестот во зелено“ мора да биде свесна, образложена одлука на човекот.
Приватност, податоци и безбедност: непроменливи граници
Приватност. Во тест опкружувањето, вистинските податоци за клиентите, копии од базата на податоци за производство, клучеви за API и информации за внатрешниот систем се чувствителни. Не ги давајте овие на јавни алатки за вештачка интелигенција. Личните податоци се предмет на KVKK и слични прописи; Дневници на маски и слики од екранот. Користете синтетички (фиктивни) тест податоци секогаш кога е можно.
Безбедносно тестирање - одбранбено и овластено. Безбедносните тестови научени во овој модул (тестови за овластување/IDOR, ограничувања за поставување датотеки, валидација на влез) се само за тестирање на вашиот сопствен производ во рамките на писменото овластување и дефинираниот опсег. Користењето вештачка интелигенција за пристап до туѓ систем без дозвола, за вооружување на вистински пропусти или за тестирање надвор од опсегот е и неетички и незаконски. Кога ќе откриете безбедносна ранливост, почитувајте го принципот на одговорно откривање - чувајте ја ранливоста во тајност и пријавете ја до соодветната страна за да може да се поправи.
Етика и транспарентност. Не ги претставувајте тестовите произведени од вештачката интелигенција како ваша работа; Да се наведе дека користите вештачка интелигенција во тимот е транспарентност. Вие сте одговорни за неточноста на излезот произведен од вештачка интелигенција - „ВИ го напиша тоа“ не е изговор.
Слаб промпт / Силен промпт
Слаб: „Поставете пробен гасовод за CI“.
Силно: „Нацртајте CI workflow YAML за GitHub Actions: извршете единица + API тестови на секој PR, генерирате извештај за покриеност, извршувајте тестирање за мутација (Stryker) неделно. Не вметнувајте тајни во кодот; користете само референца за тајните. Блокирајте го спојувањето ако тестовите се црвени. Ова е DRAFT; ќе прегледам и валидна DOOTD чекори за управување со клучот. тестирање на чекор „поправи“ или „мигрирање“.
Моќен потсетник; Тој наметнува ограничувања за доверливост, човечки преглед и „нема автоматско тестирање“.
Четири шаблони за копирање
1) План за тестирање од крај до крај:
Вашата улога: виш лидер за ОК. Нацртај план за тестирање од крај до крај од идеја до објавување за следнава карактеристика: [функција + критериуми за прифаќање]. Фази: анализа на барања (неизвесности), дизајн на тест, слоеви за автоматизација (единица/API/UI), интеграција на CI/CD, критериуми за одлука за издавање, следење на производството. Наведете ја улогата на точките за одобрување на вештачката интелигенција и ЧОВЕКОТ во секоја фаза посебно.
2) Преглед на цевководот CI/CD:
CI YAML нацрт за [GitHub Actions/GitLab CI/Azure Pipelines]:- Единица + API тест + опсег во PR- Спречете спојување во црвено тест- Тајни вредности само со тајни; вградување во код Ова е нацрт; Ќе ги разгледам клучните чекори за управување и одобрување. Додавање чекор за автоматска корекција/поминување тест.
3) Неуспешна анализа на дневникот на тестот:
Во тој печатен CI тестовите се црвени. Испитајте го дневникот; групирајте ги неуспесите, разликувајте ја можната основна причина и КОЈ може да биде вистинскиот неуспех и кој може да биде кревок тест/прашање за животната средина. Доколку има лични податоци, маскирајте ги. Одлуката и исправката ќе бидат мои. Дневник: [залепи]
4) Претходна проверка на безбедност/приватност:
Пред да се испратат овие податоци/дневник од тестот до алатката за вештачка интелигенција, проверете: дали содржи лични податоци, клуч API, внатрешна адреса на системот, податоци за производство? Наведете кои области, доколку ги има, треба да се маскираат/отстранат. Обработка како што е. Содржина: [залепи]
три мини футроли
Случај 1 - Брзина на проток од крај до крај. Еден тим се справи со новата функција „обновување на претплатата“ со проток од крај до крај напојуван со вештачка интелигенција: однапред означени несигурности на барањата, нацртани тестови со три слоја и потврдени со мутации, врзани за CI. Функцијата го намали циклусот на тестирање, кој траеше 5 дена во традиционалниот процес, на 2 дена; но човечкото одобрување беше зачувано во секоја фаза, а несигурноста на барањата (што ќе се случи ако освежувањето не успее) беше затворена пред во живо.
Случај 2 - Враќање од истекување на клучот. Еден развивач ја генерираше вештачката интелигенција CI YAML, а вештачката интелигенција вгради API клуч со вистински изглед во YAML како пример. Чекорот „претходна проверка на безбедноста/приватноста“ го доловува ова; клучот претворен во референца за тајни. Без чекорот за ревизија, клучот ќе протече во контролата на верзијата (git history).
Случај 3 - Ограничување на овластувањата. Еден член на тимот сакаше да го примени IDOR тестот што го научи на системот во живо на деловниот партнер од „Бев љубопитен“. Водачот за ОК запре: незаконски е да се врши безбедносно тестирање на друг систем без писмено овластување и дефиниран опсег. Тестирањето беше направено само во тест средина на нивните сопствени производи, со авторитет; Отворената одговорна страна беше известена до релевантниот тим.
Вообичаени грешки
- Правењето вештачка интелигенција да донесува одлуки за ослободување. Поставувајќи го прашањето "Дали може да се ослободи?" на вештачката интелигенција и ставање на одговорот на местото на потписот.
- „Полагање“ на автоматизираниот тест. Во CI, ако вештачката интелигенција го обои тестот зелено; прикривање на грешките.
- Давање доверливи податоци/клуч на возилото. Споделување податоци за производство, лични податоци или клучеви на API без надзор.
- Неовластено безбедносно тестирање. Тестирање на напаѓачите на друг систем без опсег и дозвола.
- Воведување тестови во гасоводот без преглед. Автоматски стартувајте ја скицата со вештачка интелигенција без човечко одобрение.
- Ставајќи ја вината на вештачката интелигенција. Одбрана на неточниот излез со велејќи „ВИ го напиша“.
Сумирано
ОК од крај до крај е процес кој се протега од барања до следење на производството и живее во рамките на CI/CD; Во секоја фаза, вештачката интелигенција произведува нацрти, го сумира дневникот и предлага основни причини. Но, границите се непроменливи: луѓето донесуваат одлуки за тестирање и ослободуваат одобрение; На вештачката интелигенција никогаш не му се дава овластување автоматски да го „положи“ тестот; доверливите податоци и клучевите не влегуваат во возилото; Безбедносното тестирање се врши само на вашиот сопствен производ, во рамките на писменото овластување и дефинираниот опсег, за одбранбени цели, а наодите се пријавуваат со одговорно откривање. Бидете транспарентни кога користите вештачка интелигенција; Вие сте одговорни за точноста на излезот. ВИ забрзува; Вие гарантирате за квалитет и етика.
Задача за апликација
Нацртајте план од идеја до објавување со шаблон „план за тестирање од крај до крај“ за карактеристика од вашиот сопствен проект; Обележете ја улогата на вештачката интелигенција и точките за одобрување од луѓе посебно во секоја фаза. Потоа генерирајте YAML со „ЦИ/ЦД преглед на гасоводот“ и применете „претходна проверка на безбедност/приватност“ на овој YAML за да проверите дали има вграден клуч/тајни податоци. Конечно, наведете ги сите точки за „човечка одлука“ во вашиот план и оправдајте со една реченица зошто овие одлуки не можат да се делегираат на вештачката интелигенција.
листа за проверка
- [ ] Одлуките за ослободување и тестирање ги припишувам на човечкото одобрување; Јас не го предадов на АИ.
- [ ] Во CI/CD не и дадов дозвола на AI автоматски да го „положи/поправа“ тестот.
- [ ] Ги проверив и маскирав доверливите податоци, личните податоци и клучевите пред да ги испратам во возилото.
- [ ] Размислував само за безбедносно тестирање на мојот сопствен производ, во рамките на писменото овластување и опсег.
- [ ] Се осврнав на ранливостите пронајдени со принципот на одговорно откривање.
- [ ] Јас транспарентно изјавив дека користам вештачка интелигенција и се сметав себеси за одговорен за точноста на излезот.
Модул испит
1. Како најпрецизно се дефинира „лажна пропусница“ во контекст на ОК?
- А) Иако тестот станува зелен, тој всушност не потврдува никакво однесување; ✔ Не станува црвено дури и ако кодот е оштетен
- Б) Тестот работи многу бавно и истекува.
- В) Тестот открива вистинска грешка и станува црвено
- Г) Тестот се извршува само во производствената средина
Објаснување: Псеудо-успех е кога тестот вели „положи“, но всушност не потврдува ништо значајно; Тестот е зелен, но и да е погрешен софтверот, нема да го фати. Ова е ризик број еден од вештачката интелигенција во ОК бидејќи вештачката интелигенција има тенденција да произведува тестови кои изгледаат уредно, но се шупливи.
2. Кое е најточното позиционирање на вештачката интелигенција во процесот на тестирање и QA?
- А) Вештачката интелигенција може да одлучи дали верзијата може да биде објавена без човечко одобрение
- Б) Вештачката интелигенција е асистент кој генерира нацрти и идеи; Одлуката и одговорноста за „дали е подготвено за објавување“ му припаѓа на експертот ✔
- В) Вештачката интелигенција пишува само текст и воопшто не може да се справи со кодот за тестирање
- Г) Вештачката интелигенција секогаш пишува точен тест отколку човечкиот, така што прегледот е непотребен
Опис: Вештачката интелигенција е асистент за тестирање, генератор на нацрти и мултипликатор на идеи; произведува тест сценарија, код за автоматизација и нацрти на извештаи. Сепак, одговорноста и конечното одобрување на одлуките за квалитет како „дали софтверот е подготвен за објавување“ или „дали овој тест поминал“ припаѓа на надлежниот експерт.
3. Врз основа на фактот дека грешките најчесто се случуваат на праговите вредности, која техника на дизајнирање на тестот треба да ги тестира 17, 18 и 19 одделно за старосната граница од 18 години?
- А) Тест за транзиција на државата
- Б) Табела со одлуки
- В) Анализа на гранични вредности ✔
- Г) Истражувачко тестирање
Објаснување: Анализата на граничните вредности се заснова на набљудувањето дека грешките најчесто се случуваат на границите и ги тестира праготните вредности (веднаш под, веднаш над и веднаш над границата) одделно. Тоа е моќна техника која ги надополнува класите на еквивалентност.
4. Кој пристап треба да се претпочита при изборот на елементи за да се намали кршливоста во кодот за автоматизација на тестот на интерфејсот произведен со вештачка интелигенција?
- А) Користење на најдолгата можна патека XPath
- Б) Избор на елементот според неговата позиција на пиксели на екранот
- В) Користење на селектори базирани на имиња на класи CSS
- Г) Користење на стабилни атрибути (data-testid) додадени за тестирање ✔
Објаснување: Долгите патеки на XPath и имињата на класите на CSS се исклучително зависни од структурата и дизајнот на страницата; Се скрши при најмала промена на интерфејсот. Стабилните атрибути додадени специјално за тестирање (на пр. data-testid) не се засегнати од промените во дизајнот и ги прават тестовите робусни.
5. Зошто е недоволно за API тест само да го провери статусот на HTTP кодот (на пр. 200)?
- А) Бидејќи податоците на телото со точен статусен код може да бидат оштетени и само проверката на статусот нема да го открие ова (псевдо-доверба) ✔
- Б) Бидејќи статусните кодови воопшто не се сигурни во тестовите за API
- В) Бидејќи проверката на статусниот код многу го успорува тестот
- Г) Бидејќи кодот за статус никогаш не се враќа во тестовите на API
Објаснување: Додека серверот ја враќа точната статусна шифра, може да врати оштетени податоци во телото (погрешен тип, поле што недостасува, погрешно пресметана вредност). Тестот кој само ја разгледува ситуацијата не може да го види ова и дава лажна доверба. Значи, треба да се додаде и валидација на шема/договор и деловни правила.
6. Зошто е критично да се каже на вештачката интелигенција „рачно да ја пресмета очекуваната вредност според правилото за прифаќање, да не го повикува моменталниот излез на функцијата“ при печатење на тестовите на единицата?
- А) Бидејќи рачната пресметка ги извршува тестовите побрзо
- Б) Бидејќи во спротивно тестот го прифаќа моменталното (можеби кабриолет) однесување на кодот како „точно“ и ја потврдува грешката ✔
- В) Бидејќи вештачката интелигенција воопшто не може да пресмета декадни броеви
- Г) Бидејќи правилата за прифаќање никогаш не се користат во тестовите
Објаснување: Ако вештачката интелигенција ја извлече очекуваната вредност од излезот на функцијата што се тестира, тестот ќе го „положи“ дури и ако функцијата е погрешна; Односно, што и да произведува кодот, тестот се брои како вистинит. Пресметувањето на очекуваната вредност независно од правилото за прифаќање осигурува дека тестот е чувар на портите на правилото, а не огледало на кодот.
7. Која од следново е најпрепознатлива карактеристика на добар извештај за грешки?
- А) Да биде што е можно подолго и технички
- Б) Напишано од вештачка интелигенција
- В) Содржи детерминистички чекори за репродукција што развивачот може самостојно да ги следи и да ја произведе грешката ✔
- Г) Тоа е само слика од екранот
Објаснување: Вистинската вредност на извештајот за грешка е тоа што развивачот може да ја репродуцира грешката без ваша помош. Детерминистичките чекори за репродукција што може да се следат од нула го обезбедуваат ова; Ако недостасуваат овие чекори, извештајот често се затвора како „не може да се произведе“.
8. Кој е најточниот израз за односот помеѓу сериозноста и приоритетот при грешка при погрешно пишување на името на компанијата на почетната страница?
- А) Интензитетот и приоритетот секогаш треба да имаат иста вредност
- Б) И сериозноста и приоритетот на оваа грешка се дефинитивно ниски
- В) Сериозноста и приоритетот се ист концепт, доволна е една ознака
- Г) Техничкиот интензитет може да биде низок, но деловниот приоритет (репутацијата) може да биде висок; Двете се оценуваат поинаку ✔
Објаснување: Тежината е техничкото влијание на грешката (технички ниска печатна грешка), приоритет е колку итно треба да се поправи (висока затоа што е елемент за репутација што го гледа секој посетител). Тие двајца не секогаш одат во иста насока; Овој пример е ситуација со ниска сериозност-висок приоритет.
9. Која е најточната интерпретација на тест пакет со 90% покриеност на линијата?
- А) Покажува дека линиите се извршуваат, но не докажува дека се однесуваат правилно; ✔ високата покриеност може да даде лажна самодоверба
- Б) Дефинитивно докажува дека 90% од софтверот е без грешки
- В) Тоа е дефинитивна мерка за одличен квалитет на тестот.
- Г) Укажува дека повеќе нема потреба да пишувате дополнителни тестови
Објаснување: Покриеноста на редовите покажува дека биле извршени само редови; Тоа не докажува дека дава правилни резултати. Дури и со тестови без потврда, може да се постигне покриеност од 90%. Опсегот е гаранција за „никогаш не гледано каде“, а не „сè е тестирано“; вистинската заштита се мери со тестирање на мутации.
10. Во тестирањето засновано на ризик, како се пресметува ризикот од карактеристика за да ги насочи ограничените напори за тестирање?
- А) Само според бројот на линии на код
- Б) Со множење на веројатноста за неуспех и ефектот што ќе се појави кога ќе се распадне ✔
- В) Само по редоследот по кој е развиена карактеристиката
- Г) Давање приоритет само на карактеристиката за која е најлесно да се пишуваат тестови
Објаснување: Во тестирањето засновано на ризик, ризикот се оценува како веројатност = веројатност (веројатност за дефект) × влијание (оштетување ако е скршен). Домени со голема веројатност и големо влијание (плаќање, автентикација) заслужуваат најинтензивно тестирање, додека домените со ниска × ниска добиваат лесно тестирање.
11. Кој е главниот ризик од додавање на повторно обид на тест кој понекогаш поминува, а понекогаш не успева (кршлив/ронлив) иако кодот не е променет?
- А) Скратување на времето на извршување на тестот
- Б) Го намалува процентот на покриеност
- В) Прикривање на вистинска грешка на истовремена или основна причина и потиснување на симптомот ✔
- Г) Промена на името на тестот
Објаснување: Обидете се повторно е дијагностичка алатка, а не третман. Неодлучноста често доаѓа од вистинска состојба на раса или зависност; „Поминувањето“ на тестот со повторен обид ја покрива оваа вистинска грешка и може да предизвика сериозни проблеми во живо. Прво мора да се најде основната причина.
12. Како функционира тестирањето на мутации, најискрениот метод за мерење дали тест пакетот навистина штити?
- А) Со мерење на брзината на работа на тестовите
- Б) Со броење колку линии код се напишани
- В) Со извршување на тестовите во различни редоследи
- Г) Со намерно создавање мали прекини во кодот и мерење дали тестовите ги фатат ✔
Опис: Тестирањето на мутации создава мали намерни нарушувања (мутации) во изворниот код; Добар тест пакет треба да ги фати овие нарушувања и да стане црвено. Мутациите кои не се фатени (преживеани) покажуваат дека тестовите не го зачувуваат тоа однесување. Резултатот на мутација е многу поискрено мерило за квалитет отколку процентуалното покривање.
13. Која е главната граница што треба да се следи при извршување на безбедносно тестирање (на пр. тестови за авторизација/IDOR)?
- А) Тоа треба да се направи само на сопствен производ, во писмено овластување и дефиниран опсег, за одбранбени цели ✔
- Б) Може слободно да се примени на кој било систем од интерес
- В) Може да се обиде на живи системи на деловни партнери без дозвола
- Г) Сите пронајдени пропусти треба веднаш да бидат јавно објавени.
Опис: Безбедносните тестови научени во овој модул се само за тестирање на вашиот сопствен производ за одбранбени цели, во писмено овластување и дефиниран опсег. Пристапувањето до туѓ систем без дозвола или извршувањето на тестирање надвор од опсегот е и неетички и незаконски; Сите пронајдени пропусти се пријавуваат преку одговорно обелоденување.
14. Какво овластување никогаш не треба да се даде на ВИ во цевководот CI/CD?
- А) Сумирање на неуспешни тест дневници
- Б) Овластување автоматски да „положи“ неуспешен (црвен) тест или да го обои зелено ✔
- В) Предлагање нацрт-код за тестирање
- Г) Изготвување на датотека YAML со цевководи
Опис: AI може да произведе преглед на кодот за тестирање, YAML на цевка и резиме на дневник во CI/CD; сепак, никогаш не треба да се даде можност за автоматско „положување/поправање“ на неуспешен тест. Ова ја поразува целта на тестирањето и автоматски ги прикрива грешките. Сликањето на тестот во зелено треба да биде свесна и образложена одлука на една личност.