Ответ
При отсутствии документации наиболее эффективным подходом является исследовательское тестирование (Exploratory Testing). Это одновременное изучение приложения, проектирование тестов и их выполнение. Тестировщик полагается на свои знания, опыт и креативность для исследования функциональности и выявления дефектов.
Основные техники и сопутствующие методы:
- Исследовательское тестирование: Систематическое, но не предопределенное изучение продукта. Тестировщик создает ментальную модель приложения «на лету».
- Ad-hoc тестирование: Неформальное, спонтанное тестирование без какой-либо подготовки или документации. Часто используется для быстрой проверки.
- Тестирование методом черного ящика: Анализ поведения системы исключительно на основе входных данных и наблюдаемых выходных данных, без знания внутреннего устройства.
- Тестирование на основе ошибок (Error Guessing): Использование опыта тестировщика для предположения, где в приложении могут скрываться ошибки (например, ввод специальных символов, очень длинных строк, отрицательных чисел).
Пример структуры исследовательского тестового сеанса для поля ввода:
# Эвристики (правила-подсказки) для проверки текстового поля
def explore_input_field(field_name, submit_function):
"""Исследует поведение поля ввода."""
test_cases = [
("", "Пустое значение"),
(" ", "Пробел"),
("123", "Цифры"),
("Test@mail.com", "Email"),
("<script>alert('xss')</script>", "Попытка XSS"),
("A" * 1000, "Очень длинная строка"),
("NULL", "Специальное ключевое слово"),
("123e4567-e89b-12d3-a456-426614174000", "UUID"),
]
print(f"=== Исследование поля: {field_name} ===")
for value, description in test_cases:
result = submit_function(value)
# Анализ результата: упало ли приложение, корректно ли обработало ввод?
print(f"Ввод '{description}': {value[:30]}... -> Результат: {result}")
print("=== Сеанс завершен ===n")
# Предполагаемая функция, которая отправляет значение в систему
# (В реальности это мог бы быть вызов API или клик по кнопке в UI)
def submit_to_system(value):
# Заглушка для примера. В реальном тесте здесь был бы вызов Selenium или requests.
if value == "":
return "Ошибка: поле обязательно"
elif len(value) > 255:
return "Ошибка: превышена длина"
else:
return "Успех"
# Запуск исследования
explore_input_field("Имя пользователя", submit_to_system)Практические шаги:
- Разведка: Определить основные модули и потоки приложения.
- Формирование гипотез: Предположить, что может сломаться.
- Выполнение проверок: Тестировать на основе гипотез и стандартных эвристик (например, CRUD — Create, Read, Update, Delete).
- Документирование: Фиксировать найденные баги и уточненную логику работы для будущих тестов.
Ответ 18+ 🔞
Ну и ситуация, блядь! Документации нет, как с Луны свалились. Что делать? Сидеть и плакать? Да хуй там! Надо работать с тем, что есть, а что есть? Есть ты, есть продукт и есть твоя башка, которая, надеюсь, не просто для шапки.
Вот тут на сцену выходит наш спаситель — исследовательское тестирование (Exploratory Testing). Это когда ты одновременно и учишься, и придумываешь проверки, и выполняешь их. Никаких сценариев, написанных каким-то левым дядей год назад. Ты сам себе и капитан, и штурман, и юнга, который моет палубу. Работаешь на интуиции, опыте и, прости господи, креативности.
Какие есть приёмы в этом цирке?
- Исследовательское тестирование: Это по-нашему, по-взрослому. Ты строишь модель приложения у себя в голове прямо по ходу пьесы. Системно, но без дурацких бумажек.
- Ad-hoc тестирование: А это когда совсем по-простому, на коленке. Увидел кнопку — тыкнул. Никакого плана, чистая импровизация, чтобы быстро понять, не разваливается ли всё к ебеням.
- Тестирование чёрного ящика: Сука, а что внутри — похуй. Смотрим только на то, что всунули и что вывалилось обратно. Логика? Архитектура? Да иди ты нахуй со своей архитектурой, вот тебе спецсимволы в поле пароля.
- Тестирование на основе ошибок (Error Guessing): Это когда включаешь режим параноика. Где тут самое больное место? Ага, вот это поле для ввода суммы. Давай-ка я туда впишу минус миллиард, или букву "ё", или просто нажму пробел десять раз. Ой, а что это у нас упало? Сюрприз, блядь!
Вот смотри, как можно по-простому, но с умом, потыкать какое-нибудь поле. Берём Python, потому что на нём даже обезьяна что-то накодить может:
# Эвристики (правила-подсказки) для проверки текстового поля
def explore_input_field(field_name, submit_function):
"""Исследует поведение поля ввода."""
test_cases = [
("", "Пустое значение"),
(" ", "Пробел"),
("123", "Цифры"),
("Test@mail.com", "Email"),
("<script>alert('xss')</script>", "Попытка XSS"),
("A" * 1000, "Очень длинная строка"),
("NULL", "Специальное ключевое слово"),
("123e4567-e89b-12d3-a456-426614174000", "UUID"),
]
print(f"=== Исследование поля: {field_name} ===")
for value, description in test_cases:
result = submit_function(value)
# Анализ результата: упало ли приложение, корректно ли обработало ввод?
print(f"Ввод '{description}': {value[:30]}... -> Результат: {result}")
print("=== Сеанс завершен ===n")
# Предполагаемая функция, которая отправляет значение в систему
# (В реальности это мог бы быть вызов API или клик по кнопке в UI)
def submit_to_system(value):
# Заглушка для примера. В реальном тесте здесь был бы вызов Selenium или requests.
if value == "":
return "Ошибка: поле обязательно"
elif len(value) > 255:
return "Ошибка: превышена длина"
else:
return "Успех"
# Запуск исследования
explore_input_field("Имя пользователя", submit_to_system)А теперь, блядь, практика. Как действовать по шагам, чтобы не просто тыкать, а тыкать с умом:
- Разведка боем: Первым делом — понять, что это вообще за зверь такой. Где главное меню, где кнопка "сохранить", какие вообще есть разделы. Просто побродить по приложению, как мартышка по джунглям.
- Формирование гипотез: Думаем головой. Вот эта штука, которая сохраняет данные... а что, если нажать "отмена" после трёх часов ввода? А что, если попробовать удалить то, чего нет? А если в этом поле вписать SQL-инъекцию? Подозрение ебать чувствую!
- Выполнение проверок: Берём свои гипотезы и стандартные приёмы (типа CRUD — создай, прочитай, обнови, удали) и начинаем ебашить. Смотрим, что отваливается, а что работает.
- Документирование: А вот это важно, ёпта! Нашёл баг — запиши, как воспроизвести. Понял, как работает непонятная фича — набросай пару строк, чтобы завтра не ломать голову. Это не бюрократия, это помощь себе же, любимому, в будущем.
Вот и вся магия. Без бумажки ты, конечно, не какашка, а вполне себе тестировщик, который может мозгом работать. Главное — не бояться и думать, как сломать эту прекрасную, но такую беззащитную без документации систему.