История моей фасетной классификации видов тестирования
(Из ленты 255 ступеней)
Немного некропост. Или мемуары.
В 2001 я познакомился с шаблонами документации RUP. В частности, в «Плане тестирования» была интересная и нетривиальная классификация видов тестирования. На мой скромный взгляд, эта классификация из 90-х и сейчас превосходит классификацию ISTQB.
Но что-то мне в ней не нравилось. В 2003 я разработал свою фасетную классификацию. Правда тогда я не знал, что она фасетная. В 2005 впервые опубликовал. Но ее еще нужно было дорабатывать и дорабатывать. Тогда еще я не знал о ГОСТ 9126, а до ГОСТ 25010 оставалось 10 лет…
Потом эта классификация появилась в книге у Савина, на тренингах Баранцева, в докладах на конференциях.
Потом Vader опубликовал ее в википедии.
Потом ее в википедии испортили.
На текущий момент я ее доработал, как и хотел. И даю на тренингах. Собираю фидбек. Очень неплохо прокомментировали эту классификацию в СКБ-Контур. Спасибо им большое.
По-хорошему, надо бы в книгу ее включить. Но это столько ж писать надо…
А теперь тот самый исторический пост.
4.2 Типы тестов
4.2.1 Объект тестирования
Unit (Элемент) – наименьший компонент, который можно скомпилировать.
Unit testing (поэлементное тестирование) – заключается в изолированной проверке каждого отдельного элемента путем запуска тестов в искусственной среде. Для этого необходимо использовать драйверы и заглушки. Поэлементное тестирование – первейшая возможность реализовать исходный код. Оценивая каждый элемент изолированно и подтверждая корректность его работы, точно установить проблему значительно проще, чем если бы элемент был частью системы.
Драйверы – модули тестов, которые запускают тестируемый элемент.
Заглушки — заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:
• возвращаются к элементу, не выполняя никаких других действий;
• отображают трассировочное сообщение и иногда предлагают тестеру продолжить тестирование;
• возвращают постоянное значение или предлагают тестеру самому ввести возвращаемое значение;
• осуществляют упрощенную реализацию недостающей компоненты;
• Имитируют исключительные или аварийные условия.
Тестирование сборки. Проверяется корректность функционирования скомбинированных вместе элементов. Существует четыре стратегии сборки:
• Снизу вверх. Сначала следует выполнить поэлементное тестирование для компонентов, находящихся на более низком уровне, а затем перейти к высокоуровневым компонентам. Для этого метода используются драйверы.
• Сверху вниз. Высокоуровневые подпрограммы становятся драйверами для остальных элементов. В этом методе используются заглушки, имитирующие поведение низкоуровневых элементов.
• Сэндвич. Здесь комбинируются методы сверху-вниз и снизу-вверх.
• Большой взрыв. Объединяются все элементы.
System testing (тестирование системы)- Проверяется продукт в целом. После того как все программные и аппаратные компоненты собраны, подтверждается соответствие продукта исходным требованиям проекта. При наличии полностью скомпонованной системы тестировщик может оценить многие атрибуты, которые нельзя оценить на более низких уровнях тестирования. Результатом данного тестирования является решение о готовности системы к выпуску. Среда тестирования должна быть как можно точнее повторять среду развертывания. Идеальный вариант – эти среды (стенды / окружения) совпадают.
Integration testing – в ходе этого тестирования проверяется взаимодействие тестируемого приложения с другими приложениями.
4.2.2 По целям
Инсталляционное тестирование – основная цель, убедиться, что программное обеспечение может быть установлено при различных условиях.
• новая инсталляция,
• усовершенствование системы (upgrade),
• полная или выборочная инсталляция – при нормальных и ненормальных условиях. Недостаточное количество дискового пространства, недостаток привилегий (например, на создание директорий) и т.д.
Данные и целостность базы данных. Проверяется консистентность данных. Включает в себя проверку:
• ссылочной целостности (основной источник проблем)
• ограничений на значения параметров
• ограничений на неинициализацию значений
• ограничений на уникальность значений
Функциональное тестирование — основной тест. Проверка правильности работы. Каждая функция должна отвечать требованиям.
Тестирование бизнес-цикла — должно имитировать действия, выполняемые пользователем и охватывать все типичные операции пользователя. Как правило, тесты объединяются в единый тест сьют.
Тестирование графического интерфейса пользователя.
Тестирование производительности — скорость работы системы при идеальных условиях и максимальная нагрузка
Нагрузочное тестирование – это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).
Объемное тестирование — приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.
Стресс тестирование — поведение системы при недостатке ресурсов (дискового пространства, обрывов сети, …)
Конфигурационное тестирование — тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения (MDAC, .Net, браузеры, …).
Тестирование безопасности и прав доступа — сосредоточено на двух ключевых областях безопасности:
• Безопасность уровня приложения, в том числе доступ к данным или бизнес-функциям.
• Безопасность уровня системы, включая вход в систему или удаленный доступ к системе.
4.2.3 Способ работы с кодом
White-box test. Тестирование методом «Белого ящика». Для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность, что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.
Black-box test. Тестирование методом «Черного ящика». Для конструирования тестов используются требования и спецификации ПО. Недостатки:
• таким способом невозможно найти взаимно уничтожающихся ошибок,
• некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести и т.д.
4.2.4 Стадии тестирования
Исследовательское тестирование – прогон приложения с целью выяснения функций приложения и их реализации для подготовки тестовых сценариев. Первый этап в принятии решения что и ка будет тестироваться. Применяется при недостаточном документировании процесса разработки (отсутствие или неполнота спецификаций, прототипов интерфейса, …)
Smoke test (проверка на дым) — Оставшийся с доисторических времен способ проверки электронного оборудования в процессе переконфигурации или ремонта, который сводится к элементарной подаче напряжения на данный модуль и визуальной проверке, нет ли искрения, дыма или других явных признаков неработоспособности.
В более общем смысле первый прогон программы (после написания или после внесения существенных изменений). Как правило используется для определения готова ли программа для передачи в тестирование и продолжается до 4-8 часов.
Регрессионное тестирование – Повторное использование поднабора тестов в новой версии приложения, чтобы убедиться, что функции, которые работали в предыдущей версии системы, по прежнему работают так, как ожидалось.
Приемочное тестирование – быстрая проверка работоспособности очередного релиза. Является подмножеством функциональных тестов и состоит из типичных пользовательских сценариев, сосредоточенных на основных требованиях к функциональным возможностям. Как правило, это тестирование автоматизируют.
4.2.5 Метод выполнения.
Ручное тестирование – ввод исходных данных и проверка корректности результата производится непосредственно человеком. Слабо применимо для:
• нагрузочного тестирования
• тестирования производительности
Автоматизированное тестирование — ввод исходных данных и проверка корректности результата производится специализированным ПО.
———————————————————————
PS. Я опубликую свое текущее представление о классификации видов тестирования. Только не знаю где и когда. А пока приходите на тренинг. Там фасетная классификация будет рассмотрена подробно.