Классификация тестирования по уровням: модульное, интеграционное, системное

Классификация
тестирования по уровням
1.
2.
3.
4.
5.
6.
Модульное тестирование
Интеграционное тестирование
Системное тестирование
Выходное тестирование
Приемочное тестирование
Альфа- и бета-тестирование
Классификация тестирования по
уровням
Существует несколько уровней тестирования,
позволяющих полностью проверить
программный продукт и выявить
максимальное количество ошибок:
модульное, интеграционное, системное,
выходное, приемочное. Каждый уровень
имеет свои цели и компоненты.
Модульное тестирование
Модульное тестирование — это тестирование
программы на уровне отдельно взятых модулей, функций
или классов.
Цель модульного тестирования состоит в выявлении
ошибок в реализации алгоритмов, а также в определении
степени готовности системы к переходу на следующий
уровень разработки и тестирования.
Модульное тестирование проводится по принципу
«белого ящика», т.е. основывается на знании внутренней
структуры программы, и часто включает те или иные
методы анализа покрытия кода.
Модульное тестирование проводится непосредственно
разработчиком программного обеспечения и позволяет
проверять все внутренние структуры и потоки данных в
каждом модуле. Этот вид тестирования является частью
этапа разработки.
Модульное тестирование
На уровне модульного тестирования
проще всего обнаружить дефекты, связанные
с алгоритмическими ошибками и ошибками
кодирования алгоритмов, с использованием
локальных переменных и ресурсов. Ошибки,
связанные с неверной трактовкой данных,
некорректной реализацией интерфейсов,
совместимостью, производительностью и т.п.,
обычно пропускаются на уровне модульного
тестирования и выявляются на более поздних
стадиях тестирования.
Модульное тестирование
Модульное тестирование включает в себя:
• проверку программного кода с
использованием некоторого
инструментального средства для выявления
синтаксических ошибок в программном коде
(синтаксическую проверку);
• проверку кода на соответствие стандартам
кодирования (например, соответствия
оформления программного кода
требованиям организации-разработчика);
• технический обзор программного кода.
Модульное тестирование
При выполнении модульного тестирования можно
использовать технологию либо структурного, либо
функционального тестирования или и ту, и другую.
Структурное тестирование является одним из видов
тестирования «белого ящика». Его главная идея —
правильный выбор тестируемого программного пути.
В противоположность ему функциональное
тестирование относится к категории тестирования
«черного ящика». Каждая функция программы
тестируется путем ввода ее входных данных и анализа
выходных. При этом внутренняя структура программы
учитывается очень редко.
После успешного завершения модульного
тестирования все измененные модули и наборы
тестов сохраняются в базе данных проекта.
Интеграционное тестирование
Интеграционное тестирование проводится
для проверки совместной работы отдельных
модулей и предшествует тестированию всей
системы как единого целого. Интеграционное
тестирование — это тестирование части
системы, состоящей из двух и более модулей.
Основная задача интеграционного тестирования
— поиск ошибок в реализации и интерпретации
интерфейсного взаимодействия между
модулями.
Интеграционное тестирование
Элементами интеграционного тестирования
являются:
• проверка функциональности, т.е. проверка
соответствия отдельных функций, выполняемых
связанными модулями, функциям, заданным в
спецификациях требований;
• проверка наличия и корректности
промежуточных результатов;
• проверка корректности передачи информации
между модулями (проверка интеграции).
Интеграционное тестирование
С технологической точки зрения интеграционное
тестирование представляет собой количественне
развитие модульного, поскольку также, как и
модульное тестирование, оперирует
интерфейсами модулей и подсистем и требует
создания тестового окружения, включая заглушки
на месте отсутствующих модулей. Основная
разница между модульным и интеграционным
тестированием состоит в целях, т.е. в типах
обнаруживаемых дефектов. Это определяет
стратегию выбора входных данных и методов
анализа.
Интеграционное тестирование
Интеграционное тестирование ведется
итерационно, с постепенным подключением
модулей и подсистем. Оно осуществляется
независимым тестировщиком.
Ошибки, выявленные в ходе интеграционного
тестирования, заносятся в базу данных проекта.
Результаты интеграционного тестирования
включаются в отчет о ходе тестирования при
завершении цикла тестирования.
Системное тестирование
Системное тестирование проводится
независимым тестировщиком при условии
успешного завершения интеграционного
тестирования. Системное тестирование
качественно отличается от интеграционного и
модульного уровней, рассматривает
тестируемую систему в целом и оперирует на
уровне пользовательских интерфейсов, в
отличие от последних фаз интеграционного
тестирования, которое оперирует на уровне
интерфейсов модулей.
Системное тестирование
Системное тестирование производится над
проектом в целом с помощью метода
«черного ящика», т.е. структура программы
не имеет никакого значения, для проверки
доступны только входы и выходы, видимые
пользователю. Тестированию подлежат коды
и пользовательская документация.
Системное тестирование
Категории тестов системного тестирования:
• полнота решения функциональных задач;
• корректность использования ресурсов (утечка
памяти, возврат ресурсов);
• оценка производительности;
• эффективность защиты от искажения данных и
некорректных действий;
• проверка инсталляции и конфигурации на
разных платформах;
• корректность документации.
Системное тестирование
Объемы данных, используемых на этом уровне
тестирования, таковы, что более эффективным
подходом является полная или частичная
автоматизация тестирования, что приводит к
необходимости создания гораздо более
сложной тестовой системы, чем система
тестирования, применяемая на уровне
тестирования модулей или их комбинаций.
Выходное тестирование
Выходное тестирование осуществляется с
целью проверки готовности программного
обеспечения для поставки
заказчику/пользователям. Это завершающий
этап тестирования, проводимый
независимым тестировщиком, включающий в
себя проверку на корректность инструкций по
инсталляции, а также проверку
комплектности документации.
Приемочное тестирование
Приемочное тестирование проводится
организацией, отвечающей за инсталляцию,
сопровождение программной системы и
обучение конечного пользователя. Это
последний уровень тестирования, после
которого продукт вводится в эксплуатацию.
Тестирование первых четырех уровней
проводится внутри организации-разработчика, а
приемочное тестирование выполняется
совместно с представителем заказчика.
Альфа-тестирование и бета-тестирование
Существуют еще две разновидности
тестирования, отличающиеся друг от друга
временем исполнения, — альфатестирование и бета-тестирование.
Альфа-тестирование — это реальная
работа с программным обеспечением,
проводимая потенциальными
пользователями или заказчиками, либо
имитация реальной работы разработчиками.
Альфа-тестирование и бета-тестирование
Бета-тестирование — это уже интенсивное
использование почти готовой версии
программного обеспечения с полным
набором запланированных функций.
В отличие от альфа-тестирования,
проводимого силами разработчиков или
тестировщиков, бета-тестирование
предполагает привлечение сторонних
пользователей, которым доступна
упомянутая предварительная версия
продукта (бета-версия).
Альфа-тестирование и бета-тестирование
Кроме того, бета-тестирование может
использоваться в рекламных целях как часть
стратегии продвижения продукта на рынок
(например, бесплатная раздача бета-версий
позволяет привлечь широкое внимание
пользователей к окончательной дорогой версии
продукта), а также для получения
предварительных отзывов о нем от широкого
круга будущих пользователей.
Бета-версия не является финальной версией
продукта, поэтому разработчик не гарантирует
полное отсутствие ошибок, которые могут
нарушить работу компьютера и/или привести к
потере данных.
- это одна из метрик оценки качества
тестирования, представляющая из себя плотность покрытия тестами
требований либо исполняемого кода.
Если рассматривать тестирование как "проверку соответствия между
реальным и ожидаемым поведением программы, осуществляемую на
конечном наборе тестов", то именно этот конечный набор тестов и будет
определять тестовое покрытие:
Чем выше требуемый уровень тестового покрытия, тем больше тестов
будет выбрано, для проверки тестируемых требований или исполняемого
кода.
Для разработки набора тестов, обеспечивающего высокий уровень
покрытия, можно использовать специальные техники тест дизайна.
Существуют следующие подходы к оценке и
измерению тестового покрытия:
• Покрытие требований (Requirements Coverage)оценка покрытия тестами функциональных и
нефункциональных требований к продукту
• Покрытие кода (Code Coverage)- оценка покрытия
исполняемого кода тестами, путем отслеживания
непроверенных в процессе тестирования частей
программного обеспечения.
Покрытие требований (Requirements Coverage)
Расчет тестового покрытия относительно требований
проводится по формуле:
Tcov = (Lcov/Ltotal) * 100% где:
Tcov - тестовое покрытие
Lcov - количество требований, проверяемых тест кейсами
Ltotal - общее количество требований
Для измерения покрытия требований, необходимо проанализировать
требования к продукту и разбить их на пункты.
Опционально каждый пункт связывается с тест-кейсами, проверяющими его.
Покрытие кода (Code Coverage)
Расчет тестового покрытия относительно исполняемого кода
программного обеспечения проводится по формуле:
Tcov = (Ltc/Lcode) * 100% где:
Tcov - тестовое покрытие
Ltc - кол-ва строк кода, покрытых тестами
Lcode - общее кол-во строк кода.
Покрытие требований
требования
•
•
•
•
•
Требование 1
Требование 2
Требование 3
….
Требование
N
Тест-кейсы
•
•
•
•
•
Тест-кейс 1
Тест-кейс 2
Тест-кейс 3
…..
Тест-кейс K
Тест-Дизайн
• Тест-дизайн - один из первоначальных этапов тестирования
программного обеспечения, этап планирования и
проектирования тестов
Цели тест дизайна
• Обеспечить покрытие функционала приложения тестами:
• Тесты должны покрывать весь функционал
• Тестов должно быть минимально достаточно
•
Тест дизайн задачи
•
•
•
•
Проанализировать требования к продукту
Оценить риски возможные при использовании продукта
Написать достаточное минимальное количество тестов
Разграничить тесты на приемочные, критические,
расширенные
Техники тест-дизайна
• Разделение на классы эквивалентности
• Анализ граничных значений
• Таблица принятия решения
• Причина – следствие
• Предугадывание ошибки
Классы эквивалентности
• Класс эквивалентности (equivalence class) — одно или
несколько значений ввода, к которым программное
обеспечение применяет одинаковую логику.
• Анализ классов эквивалентности - это техника, при
которой функционал (часто диапазон возможных
вводимых значений) разделяется на группы
эквивалентных по своему влиянию на систему значений.
Техника анализа граничных
значений
• Граничные значения — это те места, в которых один
класс эквивалентности переходит в другой.
• Граничное тестирование также может включать
тесты, проверяющие поведение системы на входных
данных, выходящих за допустимый диапазон
значений. При этом система должна определённым
(заранее оговоренным) способом обрабатывать такие
ситуации. Например, с помощью исключительной
ситуации или сообщения об ошибке.
Таблица принятия решений
• Это хороший инструмент для фиксирования требований и
описания функциональности приложения.
• Этими таблицами очень удобно описывать бизнес логику
приложения, и в добавок они могут служить отличной
основой для создания тест кейсов.
• В таблицах решений представлен набор условий,
одновременное выполнение которых должно привести к
определённому действию
Таблица решений на примере
Представим, что тестируем приложение для страховой компании. Это
приложение вычисляет скидку на страхование автомобилей,
взаимозависимости от того, был ли водитель хорошим студентом и состоит ли
он в браке
Всего 2 сущности
Причина/следствие
Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод
комбинаций условий (причин), для получения ответа от системы
(Следствие). Например, вы проверяете возможность добавлять
клиента, используя определенную экранную форму. Для этого
вам необходимо будет ввести несколько полей, таких как "Имя",
"Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" эта "Причина". После нажатия кнопки "Добавить", система
добавляет клиента в БД и показывает его номер на экране - это
"Следствие".
Предугадывание ошибки
Предугадывание ошибки (Error Guessing - EG). Это когда
тест аналитик использует свои знания системы и
способность к интерпретации спецификации на предмет
того, чтобы "предугадать" при каких входных условиях
система может выдать ошибку. Например, спецификация
говорит: "пользователь должен ввести код". Тест
аналитик, будет думать: "Что, если я не введу код?", "Что,
если я введу неправильный код? ", и так далее. Это и есть
предугадывание ошибки.