Прибыль:
- Способность определить роль искусственного интеллекта и точек утверждения человеком в сквозном потоке контроля качества от идеи до выпуска в контексте CI/CD.
- В CI/CD не разрешается ИИ автоматически «проходить» тест, а применяются ограничения для защиты конфиденциальных данных и ключей.
- Способность проводить тестирование безопасности в пределах полномочий и в защитных целях, а также принимать принципы ответственного раскрытия информации и этической прозрачности.
В предыдущих десяти модулях мы использовали ИИ в отдельных задачах: генерация сценариев, код автоматизации, отчеты об ошибках, анализ покрытия, тестирование мутаций. Этот последний блок объединяет их всех в один ответственный рабочий процесс. Современный контроль качества — это не работа, которая заканчивается за столом одного человека; Это процесс, который живет внутри CI/CD (Continious Integration/Continious Delivery — конвейер, в котором код постоянно комбинируется, автоматически тестируется и часто и безопасно готовится к публикации). ИИ может затронуть каждый этап этого процесса. Но по мере того, как растет мощь ИИ, растет и важность его ответственного использования: конфиденциальность, авторитет в тестировании безопасности, этика и, самое главное, сохранение решения о качестве за человеком. В этом модуле вы изучите сквозной поток и границы.
Комплексный процесс контроля качества на основе искусственного интеллекта
Роль ИИ на пути функции от идеи до релиза:
1. Анализ требований. ИИ отмечает двусмысленность требований и отсутствие критериев приемлемости («в этом правиле не указано, сколько символов должно быть минимум в пароле»).
2. Тестовый дизайн. Черновики сценариев и кейсов (блок 2), крайние случаи (блок 3) входят в число критериев приемки.
3. Автоматизация. Черновики тестового кода модуля (6), API (5) и пользовательского интерфейса (4); каждый подтверждается мутацией (10).
4. Интеграция CI/CD. Тесты запускаются автоматически при каждом слиянии кода. ИИ составляет конфигурацию конвейера (YAML), суммирует журналы неудачных тестов и предлагает возможную основную причину.
5. Решение об освобождении. Собираются результаты анализа риска (8) и регрессии (9), но эксперт решает, может ли он быть успешным.
6. Мониторинг производства и обратная связь. Ошибки вживую становятся испытаниями будущего; ИИ предлагает случай регрессии от производственного дефекта.
Совет: настройте ИИ как уровень в CI/CD, который «ускоряет создание проектов, проверяемых человеком», а не «пишет тесты и принимает решения». Никакие автоматически сгенерированные тесты не должны поступать в конвейер без проверки и одобрения человеком.
ИИ в CI/CD: где да, где нет
Этап
ИИ подходит
человек важен
Проект тестового кода
Да
Ревизия + мутация
Проект конвейера YAML
Да
Аутентификация + проверка секретного ключа
Неудачная сводка журнала
Да
Подтверждение основной причины
Хрупкий тест-диагностика
Да
Решение о постоянном решении
«Может быть версия?»
нет
Экспертное мнение и ответственность
Автоматически «пройти» тест
никогда
—
Внимание: никогда не давайте ИИ поручение типа «исправить, чтобы пройти неудачный тест» в CI/CD. Это противоречит цели тестирования и автоматически скрывает ошибки. ИИ может объяснить ошибку, предложить исправление; но «покрасить тест в зеленый цвет» должно быть сознательным и обоснованным решением человека.
Конфиденциальность, данные и безопасность: незыблемые границы
Конфиденциальность. В тестовой среде конфиденциальными являются фактические данные клиентов, копии производственных баз данных, ключи API и внутренняя информация системы. Не передавайте их общедоступным инструментам искусственного интеллекта. Персональные данные регулируются KVKK и аналогичными правилами; Маскируйте логи и скриншоты. По возможности используйте синтетические (вымышленные) данные испытаний.
Тестирование безопасности — защитное и авторизованное. Тесты безопасности, изученные в этом модуле (тесты авторизации/IDOR, ограничения на загрузку файлов, проверка входных данных), предназначены только для тестирования вашего собственного продукта в рамках письменного разрешения и определенного объема. Использование ИИ для доступа к чужой системе без разрешения, использования реальных уязвимостей в качестве оружия или проведения тестирования, выходящего за рамки области применения, является неэтичным и незаконным. Обнаружив уязвимость безопасности, соблюдайте принцип ответственного раскрытия — сохраняйте конфиденциальность уязвимости и сообщайте о ней соответствующей стороне, чтобы она могла быть устранена.
Этика и прозрачность. Не выдавайте тесты, созданные ИИ, как свою собственную работу; Заявление о том, что вы используете ИИ внутри команды, — это прозрачность. Вы несете ответственность за неточность результатов, полученных с помощью ИИ. «Это написал ИИ» не является оправданием.
Слабая подсказка / Сильная подсказка
Слабое: «Настроить тестовый конвейер для CI».
Сильный: «Составьте проект YAML рабочего процесса CI для GitHub. Действия: запускайте модульные тесты + API-тесты для каждого PR, генерируйте отчет о покрытии, запускайте мутационное тестирование (Stryker) еженедельно. Не встраивайте секреты в код; используйте только ссылку на секреты. Блокируйте объединение, если тесты отмечены красным. Это ЧЕРНОВИК; Я рассмотрю и отредактирую шаги управления и проверки секретных ключей. НЕ ДОБАВЛЯЙТЕ этап автоматического тестирования «исправление» или «перенос».
Мощная подсказка; Он накладывает ограничения на конфиденциальность, проверку человеком и отсутствие автоматического тестирования.
Четыре копируемых шаблона
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, и ИИ в качестве примера встроил в YAML реально выглядящий ключ API. Это было зафиксировано на этапе «предварительной проверки безопасности/конфиденциальности»; ключ преобразован в ссылку на секреты. Без этапа аудита ключ попадет в систему контроля версий (историю git).
Случай 3. Предел полномочий. Член команды захотел применить тест IDOR, который он узнал, к действующей системе делового партнера, потому что «мне было любопытно». Руководитель отдела контроля качества остановился: проводить тестирование безопасности в другой системе без письменного разрешения и определенных объемов незаконно. Тестирование проводилось только в тестовой среде собственных продуктов, с полномочиями; Открытая ответственная сторона была уведомлена соответствующей командой.
Распространенные ошибки
- Заставить ИИ принимать решения о выпуске. Задавая вопрос «Можно ли его выпустить?» к ИИ и поставив ответ вместо подписи.
- «Прохождение» автоматизированного теста. В CI ИИ окрашивает тест в зеленый цвет; сокрытие ошибок.
- Передача конфиденциальных данных/ключей от автомобиля. Передача производственных данных, личных данных или ключей API без присмотра.
- Несанкционированное тестирование безопасности. Тестирование злоумышленником другой системы без возможности и разрешения.
- Внедрение тестов в пайплайн без проверки. Автоматически запускать эскиз ИИ без одобрения человека.
- Возложение вины на ИИ. Защищая неправильный вывод, говоря: «Это написал ИИ».
В итоге
Сквозной контроль качества — это процесс, который простирается от требований до отслеживания производства и реализуется в рамках CI/CD; На каждом этапе ИИ создает черновики, обобщает журнал и предлагает основные причины. Но границы незыблемы: люди принимают решения о тестировании и выдают одобрение; ИИ никогда не имеет полномочий автоматически «пройти» тест; конфиденциальные данные и ключи не попадают в автомобиль; Тестирование безопасности проводится только для вашего собственного продукта, в пределах письменного разрешения и определенного объема, в защитных целях, а результаты сообщаются с ответственным раскрытием. Будьте прозрачны при использовании ИИ; Вы несете ответственность за точность вывода. ИИ ускоряется; Вы ручаетесь за качество и этику.
Задача приложения
Составьте план от идеи до выпуска с помощью шаблона «сквозного плана тестирования» для функции из вашего собственного проекта; Отметьте роль точек одобрения ИИ и человека отдельно на каждом этапе. Затем сгенерируйте YAML со «схемой конвейера CI/CD» и примените к этому YAML «предварительную проверку безопасности/конфиденциальности», чтобы проверить наличие встроенных ключей/секретных данных. Наконец, перечислите все пункты вашего плана, связанные с «человеческими решениями», и объясните в одном предложении, почему эти решения нельзя делегировать ИИ.
контрольный список
- [ ] Я приписываю решения о выпуске и тестировании одобрению человека; Я не передал его ИИ.
- [ ] В CI/CD я не давал ИИ разрешения на автоматическое «прохождение/исправление» теста.
- [ ] Я проверил и замаскировал конфиденциальные данные, личные данные и ключи перед отправкой их в автомобиль.
- [ ] Я рассматривал возможность тестирования безопасности только моего собственного продукта в пределах письменного разрешения и объема.
- [ ] Я устранил уязвимости, обнаруженные с помощью принципа ответственного раскрытия информации.
- [ ] Я открыто заявил, что использовал ИИ и несю ответственность за точность результатов.
Модульный экзамен
1. Как наиболее точно определяется «ложный проход» в контексте контроля качества?
- А) Хотя тест становится зеленым, на самом деле он не подтверждает никакого поведения; ✔ Не горит красным, даже если код поврежден
- Б) Тест выполняется очень медленно и время ожидания истекает.
- В) Тест обнаруживает реальную ошибку и загорается красным цветом.
- D) Тест выполняется только в производственной среде.
Пояснение: Псевдопрохождение — это когда тест говорит «пройдено», но на самом деле не подтверждает ничего значимого; Тест зеленый, но даже если софт неисправен, он его не отловит. Это риск номер один, связанный с ИИ в обеспечении качества, поскольку ИИ имеет тенденцию создавать тесты, которые выглядят аккуратно, но являются пустыми.
2. Каково наиболее точное позиционирование искусственного интеллекта в процессе тестирования и контроля качества?
- А) Искусственный интеллект может решить, можно ли выпустить версию без одобрения человека.
- Б) Искусственный интеллект – помощник, генерирующий черновики и идеи; Решение и ответственность по вопросу «готово ли оно к публикации» принадлежит эксперту ✔
- В) Искусственный интеллект только пишет текст и вообще не может справиться с тестовым кодом
- D) Искусственный интеллект всегда пишет тесты правильнее, чем человек, поэтому проверка не требуется.
Описание: Искусственный интеллект — помощник по тестированию, генератор проектов и умножитель идей; разрабатывает тестовые сценарии, код автоматизации и проекты отчетов. Однако ответственность и окончательное утверждение решений по качеству, таких как «готово ли это программное обеспечение к публикации» или «пройдено ли это тестирование», принадлежит компетентному эксперту.
3. Учитывая тот факт, что ошибки чаще всего возникают при пороговых значениях, какой метод проектирования тестов должен тестировать 17, 18 и 19 отдельно для возрастного ограничения 18 лет?
- А) Тест перехода состояний
- Б) Таблица решений
- C) Анализ граничных значений ✔
- Г) Исследовательское тестирование
Пояснение: Анализ граничных значений основан на наблюдении, что ошибки чаще всего возникают на границах, и пороговые значения (чуть ниже, чуть выше и чуть выше предела) проверяются отдельно. Это мощный метод, дополняющий классы эквивалентности.
4. Какому подходу следует отдать предпочтение при выборе элементов, чтобы снизить хрупкость кода автоматизации тестирования пользовательского интерфейса, созданного с помощью искусственного интеллекта?
- А) Использование максимально длинного пути XPath
- Б) Выбор элемента по его положению пикселя на экране
- В) Использование селекторов на основе имен классов CSS
- Г) Использование стабильных атрибутов (data-testid), добавленных для тестирования ✔
Объяснение: Длинные пути XPath и имена классов CSS чрезвычайно зависят от структуры и дизайна страницы; Он ломается при малейшем изменении интерфейса. Стабильные атрибуты, добавленные специально для тестирования (например, data-testid), не зависят от изменений конструкции и делают тесты надежными.
5. Почему для теста API недостаточно просто проверить код состояния HTTP (например, 200)?
- А) Поскольку данные тела с правильным кодом состояния могут быть повреждены, и одна только проверка статуса этого не выявит (псевдодоверие) ✔
- Б) Потому что коды состояния вообще ненадежны в тестах API.
- В) Потому что проверка кода состояния сильно замедляет тест.
- D) Поскольку код состояния никогда не возвращается в тестах API.
Объяснение: Хотя сервер возвращает правильный код состояния, он может возвращать поврежденные данные в теле (неправильный тип, отсутствующее поле, неправильно вычисленное значение). Тест, который только смотрит на ситуацию, не может этого увидеть и дает ложную уверенность. Поэтому следует также добавить проверку схемы/контракта и бизнес-правил.
6. Почему так важно сказать ИИ «вычислить ожидаемое значение вручную в соответствии с правилом приемки, не ссылаться на текущий вывод функции» при печати модульных тестов?
- А) Потому что ручное вычисление запускает тесты быстрее
- Б) Потому что в противном случае тест принимает текущее (возможно, ошибочное) поведение кода как «правильное» и подтверждает ошибку ✔
- В) Потому что искусственный интеллект вообще не умеет вычислять десятичные числа.
- Г) Потому что правила приемки никогда не используются в тестах.
Пояснение: если ИИ получает ожидаемое значение из выходных данных тестируемой функции, он сделает тест «пройденным», даже если функция неисправна; То есть, что бы ни выдал код, тест считается истинным. Вычисление ожидаемого значения независимо от правила приемки гарантирует, что тест является привратником правила, а не зеркалом кода.
7. Что из перечисленного является наиболее отличительной чертой хорошего отчета об ошибке?
- А) Быть максимально длинным и техническим
- Б) Написано искусственным интеллектом
- C) Содержит детерминированные шаги воспроизведения, которые разработчик может выполнить самостоятельно и выдать ошибку ✔
- Г) Это просто скриншот
Объяснение: Настоящая ценность отчета об ошибке заключается в том, что разработчик может воспроизвести ошибку без вашей помощи. Это обеспечивается детерминированными, отслеживаемыми этапами воспроизведения с нуля; Если эти шаги отсутствуют, отчет часто закрывается как «невозможно создать».
8. Какое наиболее точное выражение взаимосвязи между серьезностью и приоритетом ошибки в написании названия компании на домашней странице?
- А) Интенсивность и приоритет всегда должны иметь одно и то же значение
- Б) Серьезность и приоритет этой ошибки определенно низки.
- В) Серьезность и приоритет — одно и то же понятие, достаточно одной метки
- Г) Техническая интенсивность может быть низкой, но приоритет бизнеса (репутация) может быть высоким; Эти два оцениваются по-разному ✔
Пояснение: Серьезность — это техническое влияние ошибки (технически низкая опечатка), приоритет — насколько срочно ее необходимо исправить (высокая, потому что это элемент репутации, который видит каждый посетитель). Эти двое не всегда идут в одном направлении; Этот пример представляет собой ситуацию с низкой серьезностью и высоким приоритетом.
9. Какая интерпретация набора тестов с 90%-ным покрытием линии является наиболее точной?
- А) Показывает, что строки выполняются, но не доказывает, что они ведут себя правильно; ✔ высокий охват может дать ложную уверенность
- Б) Убедительно доказывает, что 90% программного обеспечения не содержит ошибок.
- В) Это окончательный показатель превосходного качества испытаний.
- Г) Указывает на то, что больше нет необходимости писать какие-либо дополнительные тесты
Объяснение: Покрытие строк указывает, что были выполнены только строки; Это не доказывает, что оно дает правильные результаты. Даже при использовании тестов без утверждений можно достичь 90% покрытия. Область применения — это карта «никогда не смотрел, где», а не гарантия «все было проверено»; фактическая защита измеряется путем мутационного тестирования.
10. Как при тестировании, основанном на рисках, рассчитывается риск функции, позволяющий направлять ограниченные усилия по тестированию?
- А) Только по количеству строк кода
- Б) Путем умножения вероятности отказа на эффект, который возникнет при его поломке ✔
- В) Только в том порядке, в котором была разработана функция.
- Г) Отдавать приоритет только той функции, для которой проще всего написать тесты.
Пояснение: При тестировании, основанном на оценке риска, риск оценивается как вероятность = вероятность (вероятность поломки) × воздействие (ущерб в случае поломки). Домены с высокой вероятностью и высоким уровнем воздействия (платежи, аутентификация) заслуживают самого интенсивного тестирования, в то время как домены с низким × низким уровнем подвергаются легкому тестированию.
11. Каков основной риск добавления повторной попытки к тесту, который иногда проходит, а иногда терпит неудачу (хрупкий/ненадежный), даже если код не изменился?
- А) Сокращение времени выполнения теста
- Б) Уменьшается процент покрытия
- В) Сокрытие истинной ошибки параллелизма или основной причины и подавление симптома ✔
- Г) Изменение названия теста
Объяснение: Повторная попытка — это диагностический инструмент, а не лечение. Нерешительность часто возникает из-за фактического расового состояния или зависимости; Прохождение теста путем повторной попытки скрывает эту реальную ошибку и может вызвать серьезные проблемы в работе. Сначала необходимо найти первопричину.
12. Как работает мутационное тестирование — самый честный метод определения того, действительно ли набор тестов защищает?
- А) Путем измерения скорости выполнения тестов
- Б) Подсчитав, сколько строк кода было написано
- В) Запуская тесты в разном порядке
- Г) Намеренно создавая небольшие перерывы в коде и проверяя, улавливают ли их тесты ✔
Описание. Мутационное тестирование приводит к небольшим преднамеренным искажениям (мутациям) в исходном коде; Хороший набор тестов должен улавливать эти искажения и становиться красными. Мутации, которые не были обнаружены (выжили), указывают на то, что тесты не сохраняют такое поведение. Оценка мутаций — гораздо более честная мера качества, чем процентное покрытие.
13. Каковы основные ограничения, которые следует соблюдать при проведении тестирования безопасности (например, тесты авторизации/IDOR)?
- А) Это следует делать только в отношении собственного продукта, в пределах письменного разрешения и в определенных объемах, в защитных целях ✔
- Б) Его можно свободно применять к любой интересующей системе.
- В) Его можно опробовать на действующих системах деловых партнеров без разрешения.
- D) Любые обнаруженные уязвимости должны быть немедленно опубликованы публично.
Описание. Тесты безопасности, изученные в этом модуле, предназначены только для тестирования вашего собственного продукта в защитных целях, в рамках письменного разрешения и определенного объема. Доступ к чужой системе без разрешения или проведение тестирования, выходящего за рамки области применения, является неэтичным и незаконным; О любых обнаруженных уязвимостях сообщается посредством ответственного раскрытия информации.
14. Какие полномочия никогда не следует предоставлять ИИ в конвейере CI/CD?
- А) Обобщение журналов неудачных тестов
- Б) Право автоматически «пройти» непройденный (красный) тест или покрасить его в зеленый цвет ✔
- В) Предложение проекта тестового кода
- D) Создание проекта файла YAML в конвейере
Описание. ИИ может создавать структуру тестового кода, конвейерный YAML и сводку журналов в CI/CD; однако никогда не следует предоставлять возможность автоматически «пройти/исправить» неудавшийся тест. Это противоречит цели тестирования и автоматически скрывает ошибки. Окрашивание теста в зеленый цвет должно быть осознанным и аргументированным решением человека.