В этой статье мы рассмотрим статическое и динамическое тестирование, а также основные различия между ними.
Тестирование – это процессы верификации и валидации. Без этих процессов оно не будет полным.
В сегодняшней статье мы изучим статическое тестирование. Его также называют верификацией. Еще мы узнаем, что означает его аналог – динамическое тестирование ( или же процесс валидации) и разберем ключевые различия между этими двумя методами.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Статическое и динамическое тестирование
Динамическое тестирование – это когда вы работаете с реальной системой (а не с каким-то артефактом или моделью, представляющей систему), предоставляете входные данные, получаете выходные данные и сравниваете последние с ожидаемым поведением. Это практическая работа с системой с целью поиска дефектов.
В ходе этого процесса мы поймем, почему следующие два распространенных заблуждения о тестировании не соответствуют действительности:
- Тестирование – это деятельность, которая выполняется на последнем этапе разработки.
- Оно выполняется только тестировщиками.
Давайте начнем с краткого ознакомления с 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».