Ответ
Keyword-Driven Testing (KDT) — это подход к автоматизации тестирования, основанный на абстракции. Логика теста описывается с помощью ключевых слов (keywords), которые представляют собой высокоуровневые действия, скрывающие детали реализации.
Как это работает?
- Ключевые слова (например,
Open Browser,Enter Text,Click Button) определяются как переиспользуемые функции. - Тестовые сценарии пишутся в виде таблиц (например, в Excel/CSV) или скриптов, последовательно перечисляющих эти ключевые слова и их аргументы.
- Драйвер тестов (Test Driver) или фреймворк читает сценарий, интерпретирует ключевые слова и вызывает соответствующие функции-реализации.
| Пример структуры теста в табличном виде: | Keyword | Argument 1 | Argument 2 |
|---|---|---|---|
Open Browser |
Chrome |
||
Navigate To |
https://example.com/login |
||
Enter Text |
id=username |
testuser |
|
Enter Text |
id=password |
secret123 |
|
Click Button |
id=submit |
||
Verify Text |
Welcome, testuser |
Преимущества KDT:
- Отделение логики от реализации: Тест-дизайнеры/аналитики могут писать сценарии, не зная кода.
- Высокая переиспользуемость: Ключевые слова используются в множестве тестов.
- Упрощённая поддержка: Изменения в приложении часто требуют правки только реализации ключевых слов, а не всех тестовых сценариев.
Недостатки KDT:
- Сложность начальной настройки: Требуется разработать фреймворк и библиотеку ключевых слов.
- Накладные расходы: Дополнительный слой абстракции может замедлить выполнение.
- Ограниченная гибкость: Для сложных, нестандартных проверок может потребоваться расширение фреймворка.
Инструменты: Robot Framework, Cucumber (в некоторой степени).
Ответ 18+ 🔞
Э, слушай, давай я тебе про эту вашу ключеводривенную хуйню расскажу, а то ты, наверное, думаешь, что это какая-то космическая технология. А на деле всё просто, как три копейки.
Keyword-Driven Testing (KDT) — это, блядь, такая философия, когда ты не пишешь код, а как будто команды собаке отдаёшь. Представь: у тебя есть набор заклинаний — ключевых слов (keywords). «Сидеть!», «Лежать!», «Открыть браузер!», «Ввести текст!». И ты из этих заклинаний собираешь сценарий, даже не задумываясь, как там внутри эта собака-браузер исполняет твою волю.
Как это в жизни выглядит?
- Ты сначала нарешаешь этих ключевых слов — функций, которые делают что-то конкретное.
ОткройХром,НажмиНаХуйню,ВведиПарольИЗакройГлаза. - Потом ты, такой довольный, садишься в Excel или ещё куда и пишешь тестовый сценарий просто списком этих команд. Без единой строчки кода! Чистая магия, ёпта.
- А потом запускаешь какого-нибудь драйвера (Test Driver) — это такой обезьянник, который читает твой список, видит слово
НажмиНаХуйнюи бежит выполнять ту самую функцию, которую ты когда-то написал.
Вот смотри, как тест выглядит в табличке. Прям как инструкция для домработницы:
| Ключевое Слово | Аргумент 1 | Аргумент 2 |
|---|---|---|
Open Browser |
Chrome |
|
Navigate To |
https://example.com/login |
|
Enter Text |
id=username |
testuser |
Enter Text |
id=password |
secret123 |
Click Button |
id=submit |
|
Verify Text |
Welcome, testuser |
Красота же? Прочитал сверху вниз — и всё понятно, даже если ты менеджер, который последний раз код видел в матрице.
Почему это иногда — охуенно:
- Логика отдельно, код отдельно. Тестировщик-аналитик, который в коде нихуя не шарит, может накидать сценариев. А программист потом под них реализацию напишет. Разделение труда, блядь!
- Переиспользуемость — заебись. Один раз написал ключевое слово
УдалиВсёНахуй— и используй его в сотне тестов. Не надо копипастить одно и то же. - Поддержка проще. Поменяли кнопку на сайте? Идёшь не в 500 тестов, а в ОДНУ функцию
Click Buttonи правишь её. И все тесты, которые её используют, автоматически починятся. Волшебство, ебать мои старые костыли!
Но почему это иногда — пиздец:
- Начальная настройка — просто жесть. Пока свой фреймворк и библиотеку слов напишешь, можно поседеть. Это овердохуища работы.
- Дополнительный слой — это накладные расходы. Вместо того чтобы напрямую кликнуть, ты сначала ищешь ключевое слово, потом его интерпретируешь... Скорость может просесть.
- Гибкость не всегда. Если нужно сделать какую-то нестандартную, хитрожопую проверку, может оказаться, что твои ключевые слова для этого не приспособлены. Придёшь к программисту на коленях: «Допили, пожалуйста, новое слово
ПроверьЭтуДичь».
Из чего такое обычно собирают? Ну, Robot Framework — это классика жанра, он прямо для этого создан. Ну и Cucumber со своими сценариями на псевдо-человеческом языке — это тоже, в общем-то, из этой же оперы.
Короче, инструмент мощный, но не серебряная пуля. Как молоток: гвозди забивать — идеально, а вот шурупы им закручивать — так себе затея.