модульное тестирование. Модульное тестирование. Модульное тестирование. Типы, инструменты
Скачать 19.27 Kb.
|
Модульное тестирование. Типы, инструменты. Что такое модульное тестирование? Зачем оно нужно? Примеры, подходы, стратегия и методологии... В этой статье вы найдете следующую информацию: Что такое модульное (Unit) тестирование? Зачем оно нужно? Как его провести? Методы модульного тестирования Разработка через тестирование (TDD) Преимущества модульного тестирования Недостатки модульного тестирования Рекомендации по модульному тестированию Что такое модульное тестирование? Модульное тестирование (Unit Testing)– это тип тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения. Его цель заключается в том, чтобы проверить, что каждая единица программного кода работает должным образом. Данный вид тестирование выполняется разработчиками на этапе кодирования приложения. Модульные тесты изолируют часть кода и проверяют его работоспособность. Единицей для измерения может служить отдельная функция, метод, процедура, модуль или объект. В моделях разработки SDLC, STLC, V Model модульное тестирование – это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование – это метод тестирования WhiteBox, который обычно выполняется разработчиком. На деле же из-за нехватки времени или халатности разработчиков, иногда модульное тестирование приходится проводить QA инженерам. Зачем нужно модульное тестирование? Отсутствие модульного тестирования при написании кода значительно увеличивает уровень дефектов при дальнейшем (интеграционном, системном, и приемочном) тестировании. Качественное модульное тестирование на этапе разработки экономит время, а, следовательно, в конечном итоге, и деньги. Модульное тестирование Unit Testing Интеграционное тестирование Integration Testing Системное тестирование System Testing Приемочное тестирование Acceptance Testing Модульные тесты позволяют исправить ошибки на ранних этапах разработки и снизить затраты. Это помогает разработчикам лучше понимать кодовую базу проекта и позволяет им быстрее и проще вносить изменения в продукт. Хорошие юнит-тесты служат проектной документацией. Модульные тесты помогают с миграцией кода. Просто переносите код и тесты в новый проект и изменяете код, пока тесты не запустятся снова. Как сделать модульное тестирование Модульное тестирование делится на ручное и автоматизированное. И хотя программная инженерия не выделяет превосходство одного над другим, чаще, все-таки, используется автоматизированное. При ручном модульном тестировании, как правило используется пошаговая инструкция. Алгоритм же автоматизированного заключается в следующем: Разработчик записывает в приложение единицу кода, чтобы протестировать ее. После: они комментируют и, наконец, удаляют тестовый код при развертывании приложения. Разработчик может изолировать единицу кода для более качественного тестирования. Эта практика подразумевает копирование кода в собственную среду тестирования. Изоляция кода помогает выявить ненужные зависимости между тестируемым кодом и другими модулями или пространствами данных в продукте. Кодер обычно использует UnitTest Framework для разработки автоматизированных тестовых случаев. Используя инфраструктуру автоматизации, разработчик задает критерии теста для проверки корректного выполнения кода, и в процессе выполнения тестовых случаев регистрирует неудачные. Многие фреймворки автоматически отмечают и сообщают, о неудачных тестах и могут остановить последующее тестирование, опираясь на серьезность сбоя. Алгоритм модульного тестирования: Создание тестовых случаев Просмотр / переработка Базовая линия Выполнение тестовых случаев. Методы модульного тестирования Ниже перечислены методы покрытия кода: Заявление покрытия Охват решений Охват филиала Состояние покрытия Покрытие конечного автомата Пример модульного тестирования: фиктивные объекты Модульное тестирование основывается на создании фиктивных объектов для тестирования фрагментов кода, которые еще не являются частью законченного приложения. Подставные объекты заполняют недостающие части программы. Например, у вас может быть функция, которая нуждается в переменных или объектах, которые еще не созданы. В модульном тестировании они будут учитываться в форме фиктивных объектов, созданных исключительно для целей модульного тестирования, выполненного в этом разделе кода. Разработка через тестирование (TDD) Модульное тестирование в TDD включает в себя широкое использование платформ тестирования. Каркас модульного тестирования используется для создания автоматизированных модульных тестов. Структуры модульного тестирования не являются уникальными для TDD, но они необходимы для него. Ниже некоторые преимущества TDD: Тесты написаны перед кодом Можно положиться на тестирование фреймворков Все классы в приложениях протестированы Быстрая и простая интеграция Преимущество модульного тестирования Разработчики, желающие узнать, какие функциональные возможности предоставляет модуль и как его использовать, могут взглянуть на модульные тесты, чтобы получить общее представление об API модуля. Модульное тестирование позволяет программисту выполнить рефакторинг кода на этапе регрессионного тестирования и убедиться, что модуль все еще работает правильно. Процедура заключается в написании контрольных примеров для всех функций и методов, чтобы в случае, если изменение вызвало ошибку, его можно было быстро идентифицировать и исправить. Можем тестировать части проекта, не дожидаясь завершения других. Недостатки модульного тестирования Не выявит всех ошибок. Невозможно оценить все пути выполнения даже в самых тривиальных программах. Модульное тестирование по своей природе ориентировано на единицу кода. Следовательно, он не может отловить ошибки интеграции или ошибки системного уровня. Используйте модульное тестирование в сочетании с другими видами тестирования. Рекомендации по модульному тестированию Модульные тесты должны быть независимыми. В случае каких-либо улучшений или изменений в требованиях, тестовые случаи не должны меняться. Тестируйте только один модуль за раз. Следуйте четким и последовательным соглашениям об именах для ваших модульных тестов В случае изменения кода в каком-либо модуле убедитесь, что для модуля имеется соответствующий тестовый пример, и модуль проходит тестирование перед изменением реализации. Пофиксите все выявленные баги перед переходом к следующему этапу, как минимум в модели разработки SDLC. Примите подход «тест, как ваш код». Чем больше кода вы пишете без тестирования, тем больше сценариев вам придется проверять на наличие ошибок в дальнейшем. |