Печалби:
- Възможността да се разграничи къде изкуственият интелект спестява реално време в процеса на QA и къде качествените решения, като например „готово за публикуване“, са оставени на хората, в зависимост от нивото на риск на задачата
- Способност за разпознаване на риска от фалшиви пропуски и прилагане на дисциплина за проверка, която тества всеки AI тест чрез умишлено разбиване на кода
- Възможност за защита на тестови данни, лични данни и ключове и придобиване на навик за извършване на тестове за сигурност само в рамките на разрешение и за защитни цели.
Помислете за освобождаване вечер. Бяха проведени стотици тестове, всички те получиха зелена светлина, екипът беше облекчен и софтуерът заработи. На следващата сутрин клиентът съобщи, че екранът за плащане се е сринал. Тестовете бяха зелени, но той не видя грешката. Това е най-коварният кошмар на професията за осигуряване на качеството (QA), тоест дисциплината, която систематично гарантира, че софтуерът е с желаното качество: тестът, който свети в зелено, но всъщност не потвърждава нищо. Когато изкуственият интелект (AI — софтуер, който извлича модели от исторически данни и генерира текст и код) навлезе в тази професия, има както огромно ускорение, така и увеличаване на точно този кошмар. Първоначалното обещание на този модул е ясно: AI е помощник при тестване, генератор на чертежи и умножител на идеи; Вие сте тестерът, който приема решението „готов ли е този софтуер за пускане“.
В тази първа част ще се фокусираме върху дисциплината, а не върху инструмента. Ще научите къде AI спестява реално време в процеса на QA, къде е опасно, защо измамното зелено така наречено „фалшиво преминаване“ е най-големият риск, как да проверите всеки изход и какви данни можете да дадете на кой инструмент. Без да се постави тази основа, следващите единици ще останат във въздуха.
Къде AI е полезен в процеса на тестване?
Нека разделим заданията за тестване на два големи клъстера. Първи клъстер: повтарящи се, производителни, чернови задачи. Изготвяне на тестов случай от изискване, изброяване на точки на прекъсване, писане на скелет на код за автоматизация за екран, преобразуване на сложен случай на грешка в чист отчет за грешка, обобщаване на стотици редове от лог файлове, извличане на схема от отговор на API. В тези задачи AI намалява минутите до секунди и не се уморява.
Втори клъстер: решения, чийто резултат е качество, доверие и отговорност. Решения като „може ли тази версия да се активира“, „критичен ли е този бъг или може ли да бъде отложен“, „достатъчно ли е това тестово покритие“, „този сценарий улавя ли реалния потребителски риск“ и т.н. изискват контекст, познаване на продукта и отговорност. Тук изкуственият интелект генерира опции, чернови – но вие решавате „преминаване/неуспех“ и „отивам/не вървя“.
Нека изясним разграничението с едно изречение: AI е силен в „кои ситуации могат да бъдат тествани и как да напишем код, който го тества“; Решението е ваше, когато става дума за въпроса „Наистина ли работи този софтуер и кой гарантира за него?“
Съвет: Преди да предадете работа на AI, попитайте: „Какво ще се случи, ако този резултат е грешен и аз не забележа?“ Ако отговорът е „Ще загубя няколко минути“, делегирайте лесно. Ако отговорът е „дефектният софтуер се активира“, оставете AI да създаде черновата и вие вземете решението и проверката.
Фалшив пропуск: риск номер едно от AI в QA
Когато даден тест свети в зелено, това може да означава две неща: или софтуерът действително работи правилно, или не вижда грешката, защото тестът е написан неправилно. Второто се нарича фалшиво преминаване - тестът казва "минаване", но всъщност не потвърждава нищо. Този риск се увеличава значително при тестове, създадени с AI, тъй като AI е много успешен при писането на гладки, гладко изглеждащи, но празни тестове.
Трите най-често срещани форми на псевдо-пропуск са: (1) Тестване без твърдения — кодът се изпълнява, не съдържа твърдения, винаги преминава. (2) Тест за самопроверка — очакваната стойност на теста се изчислява от изхода на тествания код; Тоест, каквото и да изведе кодът, тестът приема за "правилно". (3) Тест, който проверява грешното нещо — assert съществува, но проверява нещо тривиално (напр. „отговорът не е нула“), а не действителното бизнес правило.
Внимание: Зелен тест панел не е доказателство за качество; В най-добрия случай пише „контролите, които написахме, не са повредени в момента“. Не се утешавайте, като видите "преминаване" на теста, който AI произвежда - истинският въпрос е: този тест ще стане ли червен, ако умишлено наруша кода? Ако не се върти, този тест е декорация.
Златното правило, което се повтаря в този модул: тествайте всеки AI тест, като съзнателно разчупите кода. Ако тестът все още е зелен, този тест не работи. (Ще задълбочим тази идея като тестване на мутации в раздел 10.)
Дисциплина за проверка: три стъпки
AI говори с увереност; Това не означава, че е истина. Развийте рефлекс от три стъпки, който да прилагате към всеки резултат:
- Свържете го с изискването. Всеки тестов случай и твърдението, че AI произвежда, трябва да се основава на реално изискване или критерии за приемане (условия, на които трябва да отговаря дадена работа, за да се счита за „свършена“). „Кое правило потвърждава този сценарий?“ попитайте.
- Вижте червено. Изпълнете генерирания тест веднъж, като разбиете кода. Ако не светне червено, тестът е невалиден. Това е стъпката, която не подлежи на обсъждане в тестването на AI.
- Прекарайте го през контекстния филтър. Резултатът съвпада ли с това, което знаете, че е поведение на продукта, архитектура, действителен потребителски поток? Вашите знания за домейна са последният филтър.
Поверителност и сигурност на данните: какво къде отива?
Данните, с които работите в тестовата среда, често са чувствителни: записи на реални клиенти, копия на производствени бази данни, API ключове, вътрешни системни адреси, функции, които все още не са обявени. Направете проста класификация: отворените данни (документирани, публично достъпни) могат да влязат във всяко превозно средство. Вътрешни данни (фрагменти от изходния код, вътрешна документация) само за инструменти, одобрени от агенцията. Поверителните данни (реални клиентски данни, информация за самоличността, подробности за уязвимостта, ключове) влизат само в договорените инструменти на институцията, чиито данни не отиват в обучението на модела, за предпочитане маскирани.
Има допълнително ограничение в контекста на тестването на сигурността: всичко, научено в този модул, е за отбранителни цели — за авторитетно тестване на сигурността на вашия собствен продукт. Използването на AI за проникване в нечия друга система без разрешение, въоръжение на реални уязвимости или тестване на система, за която нямате правомощия, е едновременно неетично и престъпно. Няма да се прави обидно тестване без разрешение (обхват и разрешение).
Съвет: Използвайте синтетични (изкуствено произведени) тестови данни вместо реални клиентски данни. Искането на изкуствения интелект да „генерира реалистични, но напълно измислени тестови данни“ едновременно запазва поверителността и разнообразява крайните случаи.
три мини калъфа
Случай 1 — Спестяване на време на правилното място. Тестерът на екип на Ekomerce прекара 6 часа ръчно в създаване на тестов сценарий от документа с изисквания от 30 страници за всяка версия. Той даде документа (частта, която не съдържаше търговски тайни) на YZ и поиска структуриран проект на сценарий; Времето беше намалено до 90 минути. Той посвети спестеното време, за да провери сам, добавяйки крайни случаи на бизнес правила, които AI е пропуснал. AI премахна повтарящата се работа, оставяйки преценката на човека.
Случай 2 — Уловено фалшиво преминаване. Разработчик накара AI да напише 12 теста за единици за изчислителна функция; всички бяха зелени. Тестерът внедри стъпката „виж червено“: умишлено промени знака за събиране във функцията на умножение. Само 3 от 12 теста показаха червено. Останалите 9 теста не дадоха реално потвърждение; Току-що каза "не е извело грешка". 9 декоративни теста бяха изтрити и вместо тях бяха написани 5 истински теста.
Случай 3 — Връщане след нарушаване на поверителността. Стажант постави регистър на грешки, съдържащ имейли на истински клиенти и последните четири цифри на картата от производствената база данни в публичен инструмент и каза „обяснете тази грешка“. Ръководителят на QA се намеси: това са лични данни извън контрол и нарушение на KVKK (Закон за защита на личните данни). Същата работа беше извършена в одобрено от институцията превозно средство, маскирайки личните зони и оставяйки само следа от стека.
Четири копируеми шаблона
1) Оценка на работното място:
Вашата роля: старши QA ръководител. Ще ви опиша тестова работа. Кажете ми (1) дали тази работа е работа по чертане/анализ, която може безопасно да бъде делегирана на AI, или качествено решение, което човекът трябва да вземе, (2) потенциалната цена на неправилен резултат, (3) проверката, която трябва да направя, преди да делегирам. Работа: [вмъкнете работа тук]
2) Псевдо-пропуск контрол:
Вижте теста по-долу. Кажете ми: - Какво поведение потвърждава този тест? (едно изречение)- Как мога да разбия тествания код, така че тестът да стане ЧЕРВЕН?- Има ли слабост, която може да доведе до преминаване на този тест винаги (липсващо твърдение, самоутвърждаване, тривиална проверка)? Тест: [поставете тест тук]
3) Контрол на маскирането на тестови данни:
Регистърът/данните, които ще ви дам, може да съдържат лични или поверителни полета (имейл, име, карта, ключ, вътрешен адрес). Първо избройте полетата, които трябва да бъдат маскирани; Ще го маскирам и ще го изпратя отново. Не го анализирайте такъв, какъвто е.
4) Генериране на синтетични тестови данни:
Генерирайте 20 реда напълно измислени, реалистични тестови данни за [следната структура на полето]. Не използвайте данни за реално лице/организация. Включете също крайни случаи: празно пространство, твърде дълъг текст, гранични стойности, невалиден формат.
Слаба подкана / Силна подкана
Слаб: „Напишете тестове върху този код.“
Силно: „Изчислете това Напишете тестове за единица за функцията за отстъпка. Критерии за приемане на функцията: 10% отстъпка над 1000 TL, 20% отстъпка над 5000 TL; отрицателната сума трябва да изведе грешка. Посочете с ред за коментар кое правило валидирате за всеки тест. Тествайте граничните стойности (999, 1000, 1001, 5000, 0, -1) отделно. Използвайте реални твърдения, които ще станат червени, ако наруша кода, или не пиша тривиално твърдение."
Мощна подсказка; Той предоставя критерии за приемане, гранични стойности, очаквания за валидиране и изрични инструкции против фалшифициране. Слабата подкана приканва AI да напише декоративен тест.
Често срещани грешки
- Доверявайки се на зелено. Мислейки, че преминаването на теста е доказателство. Истинският въпрос е: става ли червено, когато разбиете кода?
- Искане на тест без посочване на причина. AI произвежда общи, често безполезни тестове, без да знае какво трябва да се провери.
- Пропускане на проверката. Казвайки „AI го е написал, вероятно е вярно“. Отговорността е на лицето, което използва изхода.
- Поставяне на реални/чувствителни данни в инструмента. Работа с производствени данни, ключове или лични данни.
- Неоторизирано тестване на сигурността. Опит за обидно тестване без обхват и разрешение.
- Използване на AI за делегиране на вземането на решения. Задаването на въпроса "Може ли да бъде пусната тази версия?" към AI и поставяне на отговора в подписа.
В обобщение
AI е мощен помощник в процеса на QA, който ускорява повтарящата се и продуктивна работа; Но отговорността за качественото решение е на човека. Риск номер едно от ИИ в тази професия е псевдо-пасирането: зелени тестове, които изглеждат спретнати, но не потвърждават нищо. Тествайте всеки AI тест чрез умишлено разбиване на кода; Ако не се зачерви, този тест е декорация. Свържете го с изискването, вижте червеното, прекарайте го през контекстния филтър. Маскирайте поверителни данни, извършвайте тестове за сигурност само за разрешени и защитни цели.
Задача за приложение
Направете 5 генерирани от AI (или генерирани от AI) единични теста от вашия собствен проект. За всеки: (1) запишете в едно изречение кое поведение проверява, (2) умишлено разбийте и стартирайте тествания код и отбележете колко стават червени, (3) маркирайте тези, които не стават червени като „декоративни тестове“ и ги пренапишете с истинското твърдение. Поставете резултата в таблица: име на теста / правилото е проверено / счупен ли е, когато е счупен / действие.
контролен списък
- [ ] Преди да предам работата, зададох въпроса "какво ще загубя, ако се обърка?"
- [ ] Тествах всеки AI тест чрез разбиване на кода; Смених този, който не се зачерви с истинския тест.
- [ ] Свързах тестовите случаи с действителните изисквания/критерии за приемане.
- [ ] Маскирах чувствителни/реални данни, без да ги давам на инструмента; Използвах синтетични данни, ако е възможно.
- [ ] Обмислих тестване на сигурността само в рамките на правомощията и за отбранителни цели.
- [ ] Оставих решението „дали версията ще бъде пусната“ на себе си, а не на AI.