Работен процес от край до край, CI/CD интеграция, етика и сигурност: Отговорно използване на AI

Печалби:

• Възможност за проектиране на ролята на изкуствения интелект и точките за одобрение от човека в QA потока от край до край от идеята до пускането в контекста на CI/CD
• В CI/CD не разрешава на AI автоматично да „премине“ теста, но прилага ограничения за защита на поверителни данни и ключове
• Способност за извършване на тестове за сигурност в рамките на властта и за отбранителни цели и за възприемане на принципи за отговорно разкриване и етична прозрачност.

В предишните десет модула използвахме AI в отделни задачи: генериране на сценарий, код за автоматизация, докладване на грешки, анализ на покритието, тестване на мутации. Тази крайна единица ги комбинира в един отговорен работен процес. Съвременният QA не е работа, която завършва на бюрото на един човек; Това е процес, който живее в рамките на CI/CD (непрекъсната интеграция / непрекъсната доставка — тръбопроводът, където кодът постоянно се комбинира, автоматично се тества и подготвя за публикуване често и безопасно). AI може да докосне всеки етап от този процес. Но с нарастването на силата на AI нараства и значението на отговорното му използване: поверителност, авторитет при тестване на сигурността, етика и най-важното, запазване на решението за качеството на човека. В този модул ще научите потока и границите от край до край.

Захранван от край до край QA поток

Ролята на AI в пътуването на функцията от идеята до пускането:

1. Анализ на изискванията. AI маркира неясноти в изискването и липсващи критерии за приемане („това правило не казва колко знака е минимум паролата“).

2. Дизайн на теста. Сценарий и чернови на казуси (единица 2), крайни случаи (единица 3) са сред критериите за приемане.

3. Автоматизация. Проекти на тестови кодове на модул (6), API (5) и потребителски интерфейс (4); всеки се потвърждава от мутация ( 10 ).

4. CI/CD интеграция. Тестовете се изпълняват автоматично с всяко сливане на код. AI чертае конфигурацията на тръбопровода (YAML), обобщава регистрационни файлове на неуспешни тестове, предлага възможна основна причина.

5. Решение за освобождаване. Събират се резултати от анализ на риска (8) и регресия (9), но експертът решава дали може да бъде успешен.

6. Производствен мониторинг и обратна връзка. Грешките на живо се превръщат в бъдещи тестове; AI предлага случай на регресия от производствен дефект.

Съвет: Настройте AI като слой в CI/CD, който „ускорява прегледани от хора чернови“, а не „пише тестове и взема решения“. Никакви автоматично генерирани тестове не трябва да влизат в процеса без преглед и одобрение от човек.

AI в CI/CD: къде да, къде не

Етап

AI годни

човекът е от съществено значение

Чернова на тестов код

да

Ревизия + мутация

Тръбопровод YAML чернова

да

Удостоверяване + проверка на таен ключ

Неуспешно обобщение на регистрационния файл

да

Потвърждение на първопричината

Чуплив тест диагностика

да

Решение за постоянно решение

— Може ли да има версия?

не

Експертна преценка и отговорност

Автоматично "преминаване" на теста

никога

—

Внимание: Никога не давайте на AI мандат като „поправете го, за да премине неуспешния тест“ в CI/CD. Това проваля целта на тестването и автоматично прикрива грешките. AI може да обясни грешката, да предложи корекция; но "боядисването на теста в зелено" трябва да бъде съзнателно, обосновано решение на човек.

Поверителност, данни и сигурност: неизменни граници

Поверителност. В тестовата среда действителните клиентски данни, копията на производствената база данни, API ключовете и вътрешната системна информация са чувствителни. Не ги давайте на публични AI инструменти. Личните данни са предмет на KVKK и подобни разпоредби; Маскирайте регистрационни файлове и екранни снимки. Използвайте синтетични (измислени) тестови данни, когато е възможно.

Тестване на сигурността — защитно и разрешено. Тестовете за сигурност, научени в този модул (тестове за оторизация/IDOR, ограничения за качване на файлове, валидиране на вход) са само за тестване на вашия собствен продукт в рамките на писменото разрешение и дефиниран обхват. Използването на AI за достъп до нечия друга система без разрешение, използване на реални уязвимости или извършване на тестове извън обхвата е както неетично, така и незаконно. Когато откриете уязвимост в сигурността, спазвайте принципа на отговорно разкриване — запазване на поверителността на уязвимостта и докладване за нея на съответната страна, за да може да бъде коригирана.

Етика и прозрачност. Не представяйте тестовете, произведени от AI, като ваша собствена работа; Заявяването, че използвате AI в екипа, е прозрачно. Вие носите отговорност за неточността на резултата, произведен от AI — „AI го е написал“ не е извинение.

Слаба подкана / Силна подкана

Слаб: „Настройване на тестов канал за CI.“

Силно: „Изготвяне на работен поток на CI YAML за действия на GitHub: стартирайте тестове на единица + API за всеки PR, генерирайте отчет за покритие, изпълнявайте тестове за мутация (Stryker) седмично. Не вграждайте тайни в кода; използвайте само препратка към тайни. Блокирайте сливането, ако тестовете са червени. Това е ЧЕРНОВА; ще прегледам и редактирам стъпките за управление на тайни ключове и валидиране. НЕ ДОБАВЯЙТЕ „корекция“ за автоматизирано тестване или стъпка „мигриране“.

Мощна подсказка; Той налага ограничения върху поверителността, човешкия преглед и „без автоматизирано тестване“.

Четири копируеми шаблона

1) План за тестване от край до край:

Вашата роля: старши QA ръководител. Начертайте план за тестване от край до край от идеята до пускането за следната функция: [функция + критерии за приемане]. Фази: анализ на изискванията (несигурности), дизайн на теста, слоеве за автоматизация (единица/API/UI), CI/CD интеграция, критерии за решение за пускане, проследяване на производството. Посочете ролята на точките за одобрение на AI и HUMAN на всеки етап поотделно.

2) Схема на CI/CD тръбопровод:

CI YAML чернова за [GitHub Actions/GitLab CI/Azure Pipelines]:- Unit + API тест + обхват в PR- Предотвратяване на сливане в червен тест- Секретни стойности само с тайни; вграждане в код Това е чернова; Ще прегледам ключовите стъпки за управление и одобрение. Добавяне на стъпка за автоматично коригиране/издържане на тест.

3) Неуспешен анализ на регистрационния файл на теста:

В тази CI разпечатка тестовете са червени. Разгледайте дневника; групирайте неуспехите, разграничете възможната първопричина и КОЯ може да е реалната неуспех и коя може да е проблем с крехък тест/околна среда. Ако има лични данни, маскирайте ги. Решението и корекцията ще бъдат мои. Дневник: [поставяне]

4) Предварителна проверка за сигурност/поверителност:

Преди тези тестови данни/дневник да бъдат изпратени до инструмента за изкуствен интелект, проверете: съдържа ли лични данни, API ключ, вътрешен системен адрес, производствени данни? Избройте кои области, ако има такива, трябва да бъдат маскирани/премахнати. Обработка, каквато е. Съдържание: [поставяне]

три мини калъфа

Случай 1 — Скорост на потока от край до край. Един екип се зае с нова функция за „подновяване на абонамент“ с поток от край до край, задвижван от AI: несигурностите на изискванията, отбелязани отпред, изготвени трислойни тестове и валидирани чрез мутация, обвързани с CI. Функцията намали цикъла на тестване, който отне 5 дни при традиционния процес, до 2 дни; но одобрението от хора беше запазено на всеки етап и несигурността на изискванията (какво се случва, ако опресняването е неуспешно) беше затворено преди активирането.

Случай 2 — Връщане след изтичане на ключ. Един разработчик накара AI да генерира CI YAML и AI вгради реално изглеждащ API ключ в YAML като пример. Стъпката „предварителна проверка за сигурност/поверителност“ улови това; ключ, преобразуван в справка за тайни. Без стъпката за проверка ключът ще изтече в контрола на версиите (git history).

Случай 3 — Ограничение на правомощията. Член на екипа искаше да приложи теста IDOR, който научи, към системата на живо на бизнес партньор от „Бях любопитен“. Лидерът на QA спря: незаконно е да се извършва тест за сигурност на друга система без писмено разрешение и определен обхват. Тестването беше извършено само в тестовата среда на техните собствени продукти, с авторитет; Откритата отговорна страна е уведомена до съответния екип.

Често срещани грешки

• Каране на AI да взема решения за освобождаване. Задаването на въпроса "Може ли да се освободи?" към AI ​​и поставяне на отговора на мястото на подписа.
• „Преминаване“ на автоматизирания тест. В CI, AI боядисва теста в зелено; прикриване на грешки.
• Предоставяне на поверителни данни/ключ за автомобила. Споделяне на производствени данни, лични данни или API ключове без надзор.
• Неоторизирано тестване на сигурността. Тестване на хакер на друга система без обхват и разрешение.
• Въвеждане на тестове в процеса без преглед. Автоматично стартирайте скицата на AI без одобрение от човек.
• Прехвърляне на вината върху AI. Защита на неправилния резултат, като се каже „AI го е написал“.

В обобщение

QA от край до край е процес, който се простира от изискванията до проследяването на производството и живее в CI/CD; На всеки етап AI създава чернови, обобщава дневника и предлага първопричините. Но границите са неизменни: хората вземат решения за тестване и одобряват пускането; На изкуствения интелект никога не се дава правомощието автоматично да „премине“ теста; поверителни данни и ключове не влизат в автомобила; Тестването за сигурност се извършва само на вашия собствен продукт, в рамките на писменото разрешение и определения обхват, за защитни цели и констатациите се докладват с отговорно разкриване. Бъдете прозрачни, когато използвате AI; Вие носите отговорност за точността на изхода. AI ускорява; Вие гарантирате за качество и етика.

Задача за приложение

Изготвяне на план от идея до пускане с шаблон за „план за тестване от край до край“ за функция от вашия собствен проект; Маркирайте ролята на AI и точките за одобрение от хора отделно на всеки етап. След това генерирайте YAML с „схема на CI/CD тръбопровод“ и приложете „предварителна проверка за сигурност/поверителност“ към този YAML, за да проверите за вграден ключ/секретни данни. И накрая, избройте всички точки за „човешко решение“ във вашия план и обосновете с едно изречение защо тези решения не могат да бъдат делегирани на ИИ.

контролен списък

• [ ] Приписвам решенията за пускане и тестване на одобрението на хората; Не съм го предал на AI.
• [ ] В CI/CD не дадох разрешение на AI автоматично да „премине/коригира“ теста.
• [ ] Проверих и маскирах поверителни данни, лични данни и ключове, преди да ги изпратя на автомобила.
• [ ] Обмислях само тестване за сигурност на моя собствен продукт, в рамките на писменото разрешение и обхват.
• [ ] Обърнах внимание на откритите уязвимости с принципа на отговорно разкриване.
• [ ] Прозрачно заявих, че съм използвал AI и се държах отговорен за точността на изхода.

Изпит по модул

1. Как най-точно се дефинира „фалшивият пропуск“ в контекста на QA?

• A) Въпреки че тестът става зелен, той всъщност не потвърждава никакво поведение; ✔ Не става червен дори ако кодът е повреден
• B) Тестът работи много бавно и изтича.
• C) Тестът открива истинска грешка и светва в червено
• D) Тестът се изпълнява само в производствената среда

Обяснение: Псевдо-преминаване е, когато тест казва „преминаване“, но всъщност не потвърждава нищо смислено; Тестът е зелен, но дори софтуерът да е дефектен, няма да го хване. Това е риск номер едно за AI в QA, защото AI има тенденция да произвежда тестове, които изглеждат спретнати, но са кухи.

2. Кое е най-точното позициониране на изкуствения интелект в процеса на тестване и QA?

• A) Изкуственият интелект може да реши дали версията може да бъде пусната без одобрението на човек
• Б) Изкуственият интелект е помощник, който генерира чернови и идеи; Решението и отговорността „готово ли е за публикуване“ принадлежи на експерта ✔
• В) Изкуственият интелект само пише текст и изобщо не може да се справи с тестовия код
• Г) Изкуственият интелект винаги пише правилен тест от човешкия, така че прегледът е ненужен

Описание: Изкуственият интелект е помощник при тестване, генератор на чернови и мултипликатор на идеи; създава тестови сценарии, код за автоматизация и чернови на отчети. Въпреки това, отговорността и окончателното одобрение на качествени решения като „готов ли е този софтуер за публикуване“ или „преминал ли е този тест“ принадлежат на компетентния експерт.

3. Въз основа на факта, че грешките възникват най-вече при праговите стойности, коя техника за проектиране на тестове е да се тестват 17, 18 и 19 отделно за възрастовата граница от 18?

• A) Тест за преминаване на състояние
• B) Таблица с решения
• C) Анализ на гранични стойности ✔
• Г) Проучвателно изпитване

Обяснение: Анализът на граничните стойности се основава на наблюдението, че грешките възникват най-често на границите и тества праговите стойности (точно под, точно над и точно над границата) поотделно. Това е мощна техника, която допълва класовете за еквивалентност.

4. Кой подход трябва да бъде предпочетен при избора на елемент, за да се намали нестабилността в автоматизирания код за тестване на потребителския интерфейс, създаден с изкуствен интелект?

• A) Използване на възможно най-дългия XPath път
• B) Избиране на елемент според позицията на пиксела му на екрана
• C) Използване на селектори, базирани на имена на CSS класове
• D) Използване на стабилни атрибути (data-testid), добавени за тестване ✔

Обяснение: Дългите XPath пътища и имената на CSS класове са изключително зависими от структурата и дизайна на страницата; Чупи се при най-малката промяна на интерфейса. Стабилните атрибути, добавени специално за тестване (напр. data-testid), не се влияят от промени в дизайна и правят тестовете стабилни.

5. Защо е недостатъчно за API тест просто да провери кода на състоянието на HTTP (напр. 200)?

• A) Тъй като телесните данни с правилен код за състояние може да са повредени и само проверката на състоянието няма да улови това (псевдо доверие) ✔
• B) Тъй като кодовете за състояние изобщо не са надеждни в API тестовете
• C) Тъй като проверката на кода на състоянието забавя много теста
• D) Тъй като кодът на състоянието никога не се връща в API тестовете

Обяснение: Докато сървърът връща правилния код на състояние, той може да върне повредени данни в тялото (грешен тип, липсващо поле, неправилно изчислена стойност). Тестът, който разглежда само ситуацията, не може да види това и дава фалшива увереност. Така че трябва да се добави валидиране на схема/договор и бизнес правило.

6. Защо е критично да кажете на AI да „изчисли ръчно очакваната стойност според правилото за приемане, не препращайте към текущия изход на функцията“, когато отпечатвате тестове на единица?

• A) Тъй като ръчното изчисление изпълнява тестовете по-бързо
• B) Защото в противен случай тестът приема текущото (може би с грешки) поведение на кода като „правилно“ и потвърждава грешката ✔
• В) Защото изкуственият интелект изобщо не може да изчислява десетични числа
• Г) Защото правилата за приемане никога не се използват в тестовете

Обяснение: Ако изкуственият интелект извлече очакваната стойност от изхода на тестваната функция, той ще направи теста „преминат“, дори ако функцията е дефектна; Тоест, каквото и да генерира кодът, тестът се счита за верен. Изчисляването на очакваната стойност независимо от правилото за приемане гарантира, че тестът е вратар на правилото, а не огледало на кода.

7. Кое от следните е най-отличителната характеристика на добрия доклад за грешки?

• А) Да бъде възможно най-дълъг и техничен
• Б) Написано от изкуствен интелект
• C) Съдържа детерминистични стъпки за възпроизвеждане, които разработчикът може да следва независимо и да генерира грешката ✔
• Г) Това е само екранна снимка

Обяснение: Истинската стойност на доклада за грешка е, че разработчикът може да възпроизведе грешката без ваша помощ. Детерминистични, проследими стъпки на възпроизвеждане от нулата гарантират това; Ако тези стъпки липсват, отчетът често се затваря като „не може да се създаде“.

8. Кой е най-точният израз за връзката между тежестта и приоритета при грешката при неправилно изписване на името на фирмата на началната страница?

• А) Интензивността и приоритетът винаги трябва да имат една и съща стойност
• B) Както сериозността, така и приоритетът на тази грешка определено са ниски
• В) Тежест и приоритет са едно и също понятие, един етикет е достатъчен
• D) Техническата интензивност може да е ниска, но бизнес приоритетът (репутация) може да е висок; Двете се оценяват по различен начин ✔

Обяснение: Сериозността е техническото въздействие на грешката (техническата грешка е ниска), приоритетът е колко спешно трябва да бъде поправена (висока, защото това е елемент на репутацията, който всеки посетител вижда). Двете не винаги вървят в една и съща посока; Този пример е ситуация с ниска сериозност и висок приоритет.

9. Коя е най-точната интерпретация на набор от тестове с 90% покритие на линията?

• A) Показва, че линиите се изпълняват, но не доказва, че се държат правилно; ✔ високото покритие може да вдъхне фалшива увереност
• Б) Убедително доказва, че 90% от софтуера е без грешки
• C) Това е окончателна мярка за отлично качество на теста.
• Г) Показва, че вече няма нужда да пишете допълнителни тестове

Обяснение: Покритието на ред показва, че са изпълнени само редове; Това не доказва, че дава правилни резултати. Дори и с тестове без достоверност може да се постигне 90% покритие. Обхватът е карта „никога не съм търсил къде“, а не гаранция „всичко е тествано“; действителната защита се измерва чрез мутационен тест.

10. При тестване, базирано на риска, как се изчислява рискът от функция, за да насочи ограничени усилия за тестване?

• А) Само по брой редове код
• B) Чрез умножаване на вероятността от повреда и ефекта, който ще настъпи, когато се повреди ✔
• C) Само в реда, в който функцията е разработена
• Г) Даване на приоритет само на функцията, за която е най-лесно да се пишат тестове

Обяснение: При тестване, базирано на риска, рискът се оценява като вероятност = вероятност (вероятност от повреда) × въздействие (щета, ако е счупена). Домейните с висока вероятност и силно въздействие (плащане, удостоверяване) заслужават най-интензивното тестване, докато домейните с ниско × ниско ниво получават леко тестване.

11. Какъв е основният риск от добавяне на повторен опит към тест, който понякога преминава и понякога се проваля (крехък/нестабилен), въпреки че кодът не е променен?

• А) Съкращаване на времето за изпълнение на теста
• B) Намалява процента на покритие
• C) Прикриване на истинска грешка на паралелността или първопричина и потискане на симптома ✔
• Г) Промяна на името на теста

Обяснение: Повторният опит е диагностичен инструмент, а не лечение. Нерешителността често идва от действително расово състояние или пристрастяване; Правенето на теста да „премине“ чрез повторен опит прикрива тази истинска грешка и може да причини сериозни проблеми на живо. Първо трябва да се открие основната причина.

12. Как работи тестът за мутации, най-честният метод за измерване дали тестовият пакет наистина защитава, работи?

• А) Чрез измерване на скоростта на движение на тестовете
• B) Като преброите колко реда код са написани
• C) Чрез изпълнение на тестовете в различни редове
• Г) Чрез съзнателно създаване на малки прекъсвания в кода и измерване дали тестовете ги улавят ✔

Описание: Тестването на мутации води до малки умишлени изкривявания (мутации) в изходния код; Един добър пакет от тестове трябва да улови тези изкривявания и да стане червен. Мутациите, които не са уловени (оцелели), показват, че тестовете не запазват това поведение. Мутационният резултат е много по-честна мярка за качество от процентното покритие.

13. Какво е основното ограничение, което трябва да се спазва при извършване на тестове за сигурност (напр. тестове за авторизация/IDOR)?

• A) Трябва да се прави само на собствен продукт, в рамките на писмено разрешение и определен обхват, за защитни цели ✔
• Б) Може свободно да се прилага към всяка система от интереси
• C) Може да се изпробва на живи системи на бизнес партньори без разрешение
• Г) Всички открити уязвимости трябва незабавно да бъдат публикувани публично.

Описание: Тестовете за сигурност, научени в този модул, са само за тестване на вашия собствен продукт за защитни цели, в рамките на писмено разрешение и определен обхват. Достъпът до чужда система без разрешение или извършването на тестване извън обхвата е както неетично, така и незаконно; Всички открити уязвимости се докладват чрез отговорно разкриване.

14. Какви правомощия никога не трябва да се дават на AI в процеса на CI/CD?

• A) Обобщаване на неуспешни тестови журнали
• B) Правото автоматично да „премине“ неуспешен (червен) тест или да го оцвети в зелено ✔
• C) Предлагане на чернова на тестов код
• D) Конвейерно изготвяне на YAML файл

Описание: AI може да създаде очертания на тестовия код, YAML на конвейера и резюме на регистрационния файл в CI/CD; въпреки това никога не трябва да се дава възможност за автоматично „преминаване/поправяне“ на неуспешен тест. Това проваля целта на тестването и автоматично прикрива грешките. Оцветяването на теста в зелено трябва да бъде съзнателно и обосновано решение на човек.