http://hawkhouse.ru/wp-content/uploads/2017/07/wate234-556.jpg		

Автоматизированное функциональное тестирование: уровни и способы применения

captcha

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

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

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

Определимся с терминами

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

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

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

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

Роль автоматизации в контексте функционального тестирования

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

Мыло ручной работы

Иногда люди охотно доплачивают за ручной труд, однако приобретение программного обеспечения – явно не тот случай

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

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

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

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

Вопрос о том, какой из двух подходов лучше, сразу выдаст далекого от сферы информационных технологий человека. Ответить на него просто невозможно, поскольку модульное и интеграционное тестирование есть две половины одного инструмента. Отдать приоритет одной из этих половин – не самое хорошее решение.

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

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

Классификация по способу тестирования: методы черного и белого ящиков

У специалистов в области информационных технологий в ходу такие понятия, как «тестирование методом черного ящика» и «тестирование методом белого ящика». Что скрывают за собой эти термины?

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

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

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

Под капотом автомобиля

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

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

Эксперт компании Hawk House Integration Алексей Ломаев отмечает:

«Делать выбор в пользу одного из методов совсем не обязательно. Опытный тест-менеджер без труда распределит задачи в рамках проекта между специалистами различного уровня».

О вреде избыточного тестирования

Пренебрегать в процессе работы над продуктом функциональными тестами – недопустимая вольность. Однако чересчур увлекаться этим инструментом также не стоит. Больше – не всегда лучше.

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

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

Заключение

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

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