Какие существуют уровни тестирующих программ

Еще одна классификация видов тестирования основана на том уровне детализации работ проекта, на который оно нацелено. Эти же разновидности тестирования можно связать с фазой жизненного цикла, на которой они выполняются.

Модульное тестирование(Unit-testing) — уровень тестирования, на котором тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. На этом уровне применяются методы «белого ящика». В современных проектах модульное тестирование («юнит-тестинг») осуществляется разработчиками.

Модульное тестирование предназначено для проверки правильности отдельных модулей, вне зависимости от их окружения. При этом проверяется, что если модуль получает на вход данные, удовлетворяющие определенным критериям корректности, то и результаты его корректны. Для описания критериев корректности входных и выходных данных часто используют программные контракты — предусловия, описывающие для каждой операции, на каких входных данных она предназначена работать, постусловия, описывающие для каждой операции, как должны соотноситься входные данные с возвращаемыми ею результатами, и инварианты, определяющие критерии целостности внутренних данных модуля.

Модульное , интеграционное, системное, приемочное тестирование/ Урок 10 / Тестировщик с нуля

Основной недостаток модульного тестирования состоит в том, что проводить его можно, только когда проверяемый элемент программы уже разработан. Снизить влияние этого ограничения можно, подготавливая тесты (а это — наиболее трудоемкая часть тестирования) на основе требований заранее, когда исходного кода еще нет. Подход опережающей разработки тестов с успехом используется, например, в рамках XP.

Модульное тестирование является важной составной частью отладочного тестирования, выполняемого разработчиками для отладки написанного ими кода.

Интеграционное тестирование(Integration testing) – уровень тестирования, на котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования (юнит-тесты для модулей должны быть выполнены и найденные ошибки исправлены).

Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования.

При этом проверяется, что в ходе совместной работы модули обмениваются данными и вызовами операций, не нарушая взаимных ограничений на такое взаимодействие, например, предусловий вызываемых операций.

Интеграционное тестирование выполняется разработчиками используется при отладке, но на более позднем этапе разработки.

Системное тестирование(System testing)- это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования «чёрного ящика», и, тем самым, не требует знаний о внутреннем устройстве системы.

Уровни тестирования. Интеграционное, Системное, Приемочное | Курс тестирование ПО. Урок 12 | QA Labs

Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием пользовательского интерфейса (или через пользовательский интерфейс), проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями этого вида тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI). Системное тестирование выполняется инженерами по тестированию.

Приемочное тестирование(Acceptance testing)- это тестирование готового продукта конечными пользователями на реальном окружении, в котором будет функционировать тестируемое приложение. Приемочные тесты разрабатываются пользователями, обычно, в виде сценариев. Для того, чтобы найти больше ошибок рекомендуется планировать не только системное тестирование и приемочное, но и модульное и интеграционное.

Рис.14. Уровни тестирования

Статическое тестирование (Static testing) – тестирование, в ходе которого тестируемая программа (код) не выполняется (запускается). Анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами.

Примеры статического тестирования:

Сквозные просмотры (Walkthroughs)

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

Динамическое тестирование (Dynamic testing)– тестирование, в ходе которого тестируемая программа (код) выполняется (запускается).

Альфа-тестирование— тестирование в процессе разработки

Бета-тестирование— тестирование выполняется пользователями (end-users)

Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки. Данный вид тестирования не может быть заранее спланирован.

Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения.

После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования.

Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов.

Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты.

«Смок-тест» (Smoke Testing, «дымовое тестирование») в тестировании означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

Первое свое применение этот термин получил у печников, которые, собрав печь, закрывали все заглушки, затапливали её и смотрели, чтобы дым шёл только из положенных мест.

Повторное «рождение» термина произошло в радиоэлектронике. Подключив в первый раз собранное устройство к источнику питания, радиолюбитель, пристально разглядывая каждый участок печатной платы, проводит так называемый «Smoke Test» — наблюдает, задымится или нет, потому что очень часто из-за досадных ошибок, допущенных при монтаже схемы, она оказывалась неработоспособна и отдельные её части выходили из строя из-за перегрева (часто с выделением дыма).

5.1.3 Виды тестирования

Функциональное тестирование(functional testing)

• каждое функциональное требование транслируется в тест-кейсы (используя техники «черного ящика») для того, чтобы проверить, что система функционирует в точности, как и описано в спецификации (функциональных требованиях к системе)

• проверяем, все ли функциональные требования действительно закодированыреализованы.

• продемонстрировать, что система удовлетворяет критериям производительности при заданных условиях
• измерить, какая часть системы является причиной «плохой» производительности системы
• измерить время реакции на действие пользователя, время отклика на запрос, и т.д.

• тестирование операционных характеристик приложения в условиях ограниченных ресурсов (например, скорость, память, место на диске и т.д.)
• проверить, что система в стрессовых условиях не прекращает свою работу некорректным образом (без сохранения копии базы данных, вывода сообщения пользователям и т.п.)

• применяется для анализа работы информационных систем на различных уровнях нагрузки.
• основным понятием нагрузочного тестирования является «виртуальный пользователь». Управляя числом виртуальных пользователей, тестировщик управляет нагрузкой на систему .
• определяем, при какой максимальной нагрузке (максимальном количестве пользователей) система способна функционирвать в соответствии с требованиями к производительности
• HP LoadRunner

1. Речь модератора и респондента;
2. Выражение лица респондента (снимается на видеокамеру);
3. Изображение экрана компьютера, с которым работает респондент;
4. Различные события, происходящие на компьютере, связанные с действиями пользователя:

• Перемещение курсора и нажатия на клавиши мыши;
• Использование клавиатуры;
• Переходы между экранами (браузера или другой программы).

• тестирование графического интерфейса пользователя для того, чтобы убедиться, что он соответствует принятым стандартам и их требованиям.

• проверяем, как приложение обрабатывает ввод с клавиатуры и «мышки» и как отображаются элементы графического интерфейса (текст, кнопки, меню, списки и прочие элементы).

• попытки узнать пароль с помощью внешних средств;
• атака системы с помощью специальных утилит, анализирующих защиты;
• подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);
• целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;
• просмотр несекретных данных в надежде найти ключ для входа в систему.

• проверяем функционирует ли система как ожидается под разными языковыми локализациями операционных систем

• проверить, что приложение совместимо с определенными конфигурациями оборудования, операционными системами, базами данных, браузерами, и т.д.

Источник: studfile.net

Подробнее про пирамиду тестирования

Пирамида тестирования, также часто говорят уровни тестирования, это группировка тестов по уровню детализации и их назначению. Эту абстракцию придумал Майк Кон и описал в книге «Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum).

Пирамиду разбивают на 4 уровня (снизу вверх), например, по ISTQB (см. wiki):

• модульное тестирование (юнит);
• интеграционное тестирование;
• системное тестирования;
• приемочное тестирование.

Но можно встретить варианты, где 3 уровня (см. в блоге semaphore). В этой модели объединяют интеграционный и системный уровни:

• модульное тестирование (юнит);
• интеграционное тестирование (включает в себя системное);
• приемочное тестирование.

Можно сказать, что разработка ПО — это движение по пирамиде снизу вверх. Важно отметить:

1. Тест(ручной, на высоких уровнях, или автотест, на низких уровнях), должен быть на том же уровне, что и тестируемый объект. Например, модульный тест (проверяющий функции, классы, объекты и т.п.) должен быть на компонентном уровне. Это неправильно, если на приемочном уровне запускается тест, который проверят минимальную единицу кода.
2. Тесты уровнем выше не проверяютлогику тестов уровнем/уровнями ниже.
3. Чем выше тесты уровнем, тем они:

• сложней в реализации, и соответственно, дороже в реализации;
• важнее для бизнеса и критичней для пользователей;
• замедляют скорость прохождения тестовых наборов, например, регресса.

Компонентный уровень

Чаще всего называют юнит тестированием. Реже называют модульным тестированием. На этом уровне тестируют атомарные части кода. Это могут быть классы, функции или методы классов.

Пример: твоя компания разрабатывает приложение «Калькулятор», которое умеет складывать и вычитать. Каждая операция это одна функция. Проверка каждой функции, которая не зависит от других, является юнит тестированием.

Юнит тесты находят ошибки на фундаментальных уровнях, их легче разрабатывать и поддерживать. Важное преимущество модульных тестов в том, что они быстрые и при изменении кода позволяют быстро провести регресс (убедиться, что новый код не сломал старые части кода).

Тест на компонентном уровне:

1. Всегда автоматизируют.
2. Модульных тестов всегда больше, чем тестов с других уровней.
3. Юнит тесты выполняются быстрее всех и требуют меньше ресурсов.
4. Практически всегда компонентные тесты не зависят от других модулей (на то они и юнит тесты) и UI системы.

В 99% разработкой модульных тестов занимается разработчик, при нахождении ошибки на этом уровне не создается баг-репортов. Разработчик находит баг, правит, запускает и проверяет (абстрактно говоря это разработка через тестирование) и так по новой, пока тест не будет пройден успешно.

На модульном уровне разработчик (или автотестер) использует метод белого ящика. Он знает что принимает и отдает минимальная единица кода, и как она работает.

Интеграционный уровень

Проверят взаимосвязь компоненты, которую проверяли на модульном уровне, с другой или другими компонентами, а также интеграцию компоненты с системой (проверка работы с ОС, сервисами и службами, базами данных, железом и т.д.). Часто в английских статьях называют service test или API test.

В случае с интеграционными тестами редко когда требуется наличие UI, чтобы его проверить. Компоненты ПО или системы взаимодействуют с тестируемым модулем с помощью интерфейсов. Тут начинается участие тестирования. Это проверки API, работы сервисов (проверка логов на сервере, записи в БД) и т.п.

Строго говоря на модульном уровне тестирование тоже участвует. Возможно помогает проектировать тесты или во время регресса смотрит за прогоном этих тестов, и если что-то падает, то принимает меры.

Отдельно отмечу, что в интеграционном тестировании, выполняются как функциональные (проверка по ТЗ), так и нефункциональные проверки (нагрузка на связку компонент). На этом уровне используется либо серый, либо черный ящик.

В интеграционном тестировании есть 3 основных способа тестирования (представь, что каждый модуль может состоять еще из более мелких частей):

• Снизу вверх (Bottom Up Integration): все мелкие части модуля собираются в один модуль и тестируются. Далее собираются следующие мелкие модули в один большой и тестируется с предыдущим и т.д. Например, функция публикации фото в соц. профиле состоит из 2 модулей: загрузчик и публикатор. Загрузчик, в свою очередь, состоит из модуля компрессии и отправки на сервер. Публикатор состоит из верификатора (проверяет подлинность) и управления доступом к фотографии. В интеграционном тестировании соберем модули загрузчика и проверим, потом соберем модули публикатора, проверим и протестируем взаимодействие загрузчика и публикатор.
• Сверху вниз (Top Down Integration): сначала проверяем работу крупных модулей, спускаясь ниже добавляем модули уровнем ниже. На этапе проверки уровней выше данные, необходимые от уровней ниже, симулируются.Например, проверяем работу загрузчика и публикатора. Руками (создаем функцию-заглушку) передаем от загрузчика публикатору фото, которое якобы было обработано компрессором.
• Большой взрыв («Big Bang» Integration): собираем все реализованные модули всех уровней, интегрируем в систему и тестируем. Если что-то не работает или недоработали, то фиксим или дорабатываем.

Системный уровень

О системном уровне говорили в интеграционном. Тут отметить только то, что:

1. Системный уровень проверят взаимодействие тестируемого ПО с системой по функциональным и нефункциональным требованиям.
2. Важно тестировать на максимально приближенном окружении, которое будет у конечного пользователя.

Тест-кейсы на этом уровне подготавливаются:

1. По требованиям.
2. По возможным способам использования ПО.

На системном уровне выявляются такие дефекты, как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д.

На этом уровне используют черный ящик. Интеграционный уровень позволяет верифицировать требования (проверить соответствие ПО прописанным требованиям).

Приемочное тестирование

Также часто называют E2E тестами (End-2-End) или сквозными. На этом уровне происходит валидация требований (проверка работы ПО в целом, не только по прописанным требованиям, что проверили на системном уровне).

Проверка требований производится на наборе приемочных тестов. Они разрабатываются на основе требований и возможных способах использования ПО.

Отмечу, что приемочные тесты проводят, когда (1) продукт достиг необходимо уровня качества и (2) заказчик ПО ознакомлен с планом приемки (в нем описан набор сценариев и тестов, дата проведения и т.п.).

Приемку проводит либо внутреннее тестирование (необязательно тестировщики) или внешнее тестирование (сам заказчик и необязательно тестировщик).

Важно помнить, что E2E тесты автоматизируются сложнее, дольше, стоят дороже, сложнее поддерживаются и трудно выполняются при регрессе. Значит таких тестов должно быть меньше.

В заключении

Хочу отметить, что переходят от уровня к уровню может приходить понимание то ли мы делаем. Возникают вопросы к требованиям, появляются доработки — это нормально.

Приглашаю читать мой блог в телеграмме «Тестировщик» 🙂

Дополнительные материалы

1. The Testing Pyramid: How to Structure Your Test Suite
2. Автоматизация и пирамида тестов
3. The Practical Test Pyramid

Источник: habr.com

Основы тестирования. Виды тестирования по критерию уровня

Существует множество видов тестирования. И в них иногда очень легко заблудиться. Поэтому с этой статьи мы с вами начинаем разбираться в видах тестирования.

Что за уровни тестирования? Что тестируется на каждом из них? Какие у них цели? Разберем в статье.

Чтобы было проще разбираться во всех терминах, давайте упростим изучение и разобьем виды тестирования на две составляющие:
1. Уровни тестирования
2. Типы тестирования

Причем, различные типы тестирования могут выполняться на разных уровнях тестирования. Зрительно это можно представить следующим образом:

В первую очередь рассмотрим уровни тестирования. Выделяют 4 основных уровня тестирования:
1. Компонентное/модульное тестирование (Component/Unit Testing).
2. Интеграционное тестирование (Integration Testing).
3. Системное тестирование (System Testing).
4. Приемочное тестирование (Acceptance Testing).

Каждый уровень тестирования направлен на определенную часть программы и выполняет свои цели.

Компонентное/модульное тестирование

Этот вид тестирования выполняется на самой ранней стадии разработки программы — во время написания кода. Обычно его выполняет сам программист, который пишет код. Следовательно, ошибки, в большинстве случаев, исправляются сразу же и не попадают к специалистам по тестированию.

Как видно из названия, модульное тестирование направлено на тестирование отдельных модулей и компонентов программы, которые изолированы от других модулей и компонентов. Поэтому его стоит совмещать с другими видами тестирования, сам по себе он малоэффективен.

Для этого уровня тестирования характерно несколько целей:
1. Проверка компонента на соответствие требованиям,
2. Обнаружение ошибок в компоненте,
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

С помощью компонентного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта. К сожалению, этот уровень тестирования требует большой ответственности и ресурсов со стороны разработки, и в большинстве случаев на него нет времени. Поэтому, такое тестирование редко используется в компаниях.

Интеграционное тестирование

Интеграционное тестирование необходимо для того ,чтобы тестировать взаимосвязь между чем-либо.

В общем случае различают два вида интеграционного тестирования:

— Компонентное интеграционное тестирование. Как видно из названия, оно необходимо для того, чтобы протестировать работу модулей в связке друг с другом.

— Системноеинтеграционное тестирование. Если с предыдущим уровнем тестирования все понятно, то с системным интеграционным тестирование все несколько сложнее. Этот уровень необходим для тестирования систем друг с другом.

Давайте рассмотрим на примере. Предположим мы разрабатываем игру для смартфона. Сама игра является системой, которую необходимо протестировать. Кроме этого, есть еще сервисы, которые взаимодействуют с игрой и такое взаимодействие тоже должно быть проверено. Таких сервисов достаточно много, хотя на первый взгляд их трудно заметить.

Каждый из них является системой, которая интегрируется в нашу игру.Например, игра может поддерживать социальную сеть Facebook, чтобы можно было играть с друзьями. В этом случае, необходимо протестировать корректно ли работает вход в социальную игру через нашу игру, можем ли мы видеть список друзей и т.д.

Для этого уровня тестирования также характерно несколько целей:
1. Проверка интерфейсов на соответствие требованиям.
2. Обнаружение ошибок в интерфейсах.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

С помощью интеграционного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.

Системное тестирование

Системное тестирование — это тестирование еще более высокого уровня. Напомню, что на компонентном тестировании мы тестируем отдельные модули, а на интеграционном — связь между компонентами. При системном тестировании наша задача уже состоит в том, чтобы убедиться в корректности работы в целом всей системы. Программа в этом случае должна быть максимально приближена к конечному результату. А наше внимание должно быть сосредоточено на общем поведении системы с точки зрения конечных пользователей.

Для этого уровня тестирования также характерно несколькоцелей:
1. Проверка системы на соответствие требованиям.
2. Обнаружение ошибок в системе.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

С помощью системного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.

Приемочное тестирование

Приемочное тестирование — наиболее высокий уровень тестирования. Оно, также как и системное тестирование, необходимо для проверки работы программы в целом.

Тут также смещаются цели тестирования. Ошибок на этом этапе уже не должно быть. Скорее наоборот, программа должна быть максимально рабочей и пригодной для использования. Если на данном этапе обнаруживается критичные дефекты, то есть большая вероятность того, программа была плохо протестирована на предыдущих уровнях.

Этот уровень тестирования используется для подтверждения готовности продукта и проводится преимущественно в самом конце цикла разработки программы.

У приемочного тестирования есть также несколько целей:
1. Показать, что программа завершена и готова к использованию так, как от нее ожидалось.
2. Проверить, что работа программы соответствует установленному ТЗ или требованиям.

Также, на этом уровне тестирования мы показываем уверенность в качестве системы.

По версии ISTQB существует несколько форм приемочного тестирования:
1. Пользовательское приемочное тестирование.
2. Эксплуатационное приемочное тестирование.
3. Контрактное и нормативное приемочное тестирование.
4. Альфа- и Бета-тестирование.

Пользовательское приемочное тестирование предназначено для проверки программы, как если бы ее использовал конечный пользователь. В этом случае мы должны убедиться, что все функции и части работают так, как задумывалось в требованиях. Если вернуться к примеру с программой по поиску такси, то мы должны быть уверены, что такси вызывается корректно, можно оплачивать поездку через программу, оставлять отзывы, отменять вызов и так далее.

С другой стороны стоит эксплуатационное приемочное тестирование. Его отличие заключается в том, что мы проводим тестирование не с позиции пользователей, а с позиции тех, кто будет поддерживать работу программы. Наша задача — убедиться в работоспособности таких аспектов, как:
1. Возможность резервного копирования и восстановления данных.
2. Установка, удаление и обновление программы.
3. Восстановление после полного падения системы.
4. Управление пользователями.
5. Возможность сопровождения (обслуживания).
6. Возможность загрузки и миграции данных.
7. Отсутствия уязвимостей.
8. Хорошая производительность.

Если программа разрабатывается у сторонней компании, то иногда заключается контракт, в котором оговорены условия приемки. Проверка на соответствие таким критериям проводится при контрактном приемочном тестировании.

Альфа- и Бета- тестирование используется, когда есть необходимость в получении обратной связи от пользователей. Поэтому именно они участвуют в таких проверках. Отличие альфа-тестирования от бета-тестирования заключается в том, что альфа-тестирование проводится внутри компании на потенциальных пользователях, а бета-тестирование проводится в ограниченном кругу конечных пользователей программы.
Такое часто распространено в играх. Игрокам сначала показывается бета версия игры, а через некоторое время игра выходит в релиз и становится доступной для всех.

Для наглядности все уровни тестирования можно представить следующим образом:

В реальной жизни рисунок может быть и другой формы, например, прямоугольник или перевернутая пирамида.

Источник: sedtest-school.ru