Автоматизированное тестирование

Автоматизированное тестирование – практика, которая сегодня, мягко говоря, на слуху.

Программное обеспечение тестируется на каждом этапе жизненного цикла. И разработчиками на предмет работоспособности кода, и QA-менеджерами на всё на свете. Каждый раз, когда пользователь запускает приложение – фактически, что он проводит тестирование, потому что в результате взаимодействия могут найтись ошибки в работе (к сожалению, не всегда о негативных результатах подобного «теста» можно узнать, если не использовать инструменты для мониторинга). Тестирование повсюду, и это большой объём работы, который можно делать быстрее и с меньшими затратами.

Пример запуска автоматического теста от компании "Факт"

Условно, тестируемое приложение можно разбить на 3 уровня:

• Unit Tests Layer
• Functional Tests Layer (Non-UI)
• GUI Tests Layer

Для обеспечения лучшего качества продукта, рекомендуется автоматизировать все 3 уровня. Рассмотрим более детально стратегию автоматизации тестирования на основе трехуровневой модели:

1. Уровень модульного тестирования (Unit Test layer)

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

2. Уровень функционального тестирование (Functional Test Layer non-ui)

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

3. Уровень тестирования через пользовательский интерфейс (GUI Test Layer)

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

А если сайт доступен, работает быстро, но выводит какую-то ошибку?

Конечно, "подручные" методы проверки — лучше, чем ничего. Но для уверенности нужна более серьезная проверка. Например, для интернет-магазина нужно проверить не только доступность и скорость ответа, но и:

• Авторизацию;
• Добавление случайных товаров в корзину;
• Оформление заказа;
• Работу каталога и фильтрации по нему.

Если тестирование является целью в понимании качества программного обеспечения, то автоматизация – средство для достижения этой цели. Просто забив в поисковик фразу "successful test automation" можно найти множество разнообразных рекомендаций по выбору инструментов автоматизации тестов для веб-приложений. За прошедшие несколько лет Selenium приобрел фантастическую популярность. Если сказать, что Selenium - это библиотека или фреймворк - это определение будет неполным. Selenium - это набор инструментов для автоматизации тестирования веб приложений:

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

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

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

• Все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор». Тестировщик не пропустит тест по неосторожности и ничего не напутает в результатах. Это одновременно является и недостатком, так как тестировщик, выполняя тест вручную, может обратить внимание на некоторые детали и, проведя несколько дополнительных операций, найти дефект. Скрипт этого сделать не может;
• Чем чаще изменяется приложение, тем выше затраты на их поддержку. Однако, когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную;
• Автоматически рассылаемые и сохраняемые отчеты о результатах тестирования;
• Во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время (этот метод предпочтительнее, так как нагрузка на локальные сети ночью снижена);
• Автоматический скрипт может пропускать мелкие ошибки на проверку которых он не запрограммирован. Это могут быть неточности в позиционировании окон, ошибки в надписях, которые не проверяются, ошибки контролов и форм с которыми не осуществляется взаимодействие во время выполнения скрипта.

Стоит помнить:

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