Статическое и динамическое тестирование

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

Тестирование – это процессы верификации и валидации. Без этих процессов оно не будет полным.

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Статическое и динамическое тестирование

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

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

  1. Тестирование – это деятельность, которая выполняется на последнем этапе разработки.
  2. Оно выполняется только тестировщиками.

Давайте начнем с краткого ознакомления с V-моделью разработки:

v-модель
  • В левой части V-модели находятся все те действия, которые не выполняются командой QA.
  • С правой стороны у нас прописаны разные действия, об одной части которых заботится команда разработчиков, о второй — тестировщики, а о третьей — пользователи.

Начнем со сбора требований. Он выполняется бизнес-аналитиком и другими руководителями более высокого уровня – выходным документом этого этапа является документ с бизнес-требованиями.

Следующий этап – проектирование системы. Проектирование системы – это этап, на котором бизнес-требования переводятся в функциональные требования в FRD (Functional requirements document – документ с функциональными требованиями).

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

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

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

Давайте теперь рассмотрим следующие моменты на основе этого же примера:

  • Как определить, что это требование невозможно реализовать и, следовательно, невозможно протестировать (другими словами, неосуществимо)? У нас есть сайт банка, мы задаем логин и пароль – и потом понимаем, что это невозможно? Нет, мы просто основываемся на нашем документе с требованиями и, конечно, на здравом деловом смысле.
  • Тестируем ли мы это требование? Конечно, но исключительно на основе теоретического, концептуального смысла, а не на реальном тестируемом приложении.
  • Какова физическая форма этого тестирования? -Простое чтение или формальный обзор документов или еще более формальный анализ выполнимости бизнес-требований.

Возвращаясь к нашим заблуждениям:

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

Методы статического тестирования:

Подводя итог, можно сказать, что статическое тестирование – это вид тестирования ПО, в которой используются следующие проверки:

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

Цитируя CSTE CBOK: “Верификация отвечает на вопрос: “Построили ли мы правильную систему?”, в то время как валидация отвечает на вопрос: “Построили ли мы систему правильно?”.

Ниже перечислены все действия статического тестирования, которые происходят в левой части V-модели.

Этап SDLCРезультатДействующие лица
Сбор бизнес-требованийДокумент с бизнес-требованиями
Разработка системных требованийДокумент с функциональными требованиямиРазработчики, технические команды
Разработка технических требованийДокумент с результатами технического проектированияКоманды разработчиков, технических специалистов
Реализация (код)КодКоманда разработчиков, технические команды

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

В правой части V-модели находятся процессы валидации.

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

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

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

Можно ли сказать, что в правой части V-модели вообще нет верификации? Ответ: нет.

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

При использовании V-модели разработки:

  • Тесты и код проверяются разработчиками на этапах модульного/интеграционного тестирования.
  • Системные тесты проходят экспертную оценку во время документирования и после завершения проверяются командой разработчиков и бизнес-аналитиком.
  • Заготовленные заранее тест-кейсы проходят проверку командой QA и пользователями.

Статическое тестирование и динамическое тестирование

Давайте теперь разберемся в различиях между этими двумя важными методами тестирования:

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

Заключение

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

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

Перевод статьи Swati S «Static Testing And Dynamic Testing: What Are The Differences».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *