Автоматизированное тестирование программного обеспечения

Автоматизированное тестирование программного обеспечения

Автоматизированное тестирование программного обеспечения (Software Automation Testing) - это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.

Инструмент для автоматизированного тестирования (Automation Test Tool) - это программное обеспечение, посредством которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест скриптов.

Тест Скрипт(Test Script) - это набор инструкций, для автоматической проверки определенной части программного обеспечения.

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

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

Зачем нужно автоматизировать?

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

Преимущества автоматизации тестирования:

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

Недостатки автоматизации тестирования:

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

Что нужно автоматизировать?

Где лучше применять автоматизацию:

  1. Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД)
  2. Часто используемая функциональность, риски от ошибок в которой достаточно высоки. Автоматизировав проверку критической функциональности, можно гарантировать быстрое нахождение ошибок, а значит и быстрое их решение.
  3. Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей. Автоматизировать заполнение полей различными данными и их проверку после сохранения)
  4. Валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации)
  5. Длинные end-to-end сценарии
  6. Проверка данных, требующих точных математических расчетов
  7. Проверка правильности поиска данных

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

  • Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции - Create / Read / Update / Delete).

Пример: создание,удаление, просмотр и изменение данных о пользователе.

  • Типовые сценарии использования приложения, либо отдельные действия.

Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Это так называемый end-to-end сценарий, который проверяет совокупность действий. Мы предлагаем вам использовать именно такие сценарии, так как они позволяют вернуть систему в состояние, максимально близкое к исходному, а значит – минимально влияющее на другие тесты.

  • Интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную.

Пример: система создает некоторый xml файл, структуру которого необходимо проверить.

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

Как автоматизировать?

В данном разделе рассмотрим аспекты, влияющие на выбор инструмента автоматизации тестирования.

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

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

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

Выбор инструмента автоматизации тестирования

Выбор инструмента зачастую зависит от объекта тестирования и требований к тестовым сценариям, т.к. инструменты тестирования не могут поддерживать абсолютно все технологии, используемые при разработке приложений. То есть, выбор инструмента сводится к банальному методу проб и ошибок. В итоге, нередко мы выбираем несколько инструментов для тестирования функций приложения. Например, GUI мы проверяем по средствам Mercury WinRunner бэкенд процессы - используя java based test tools или другие инструменты.

Три уровня автоматизации тестирования

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

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

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

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

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

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

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

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

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

Архитектура Автоматических Тестов (Test Tools Architecture)

Для удобства наложения автоматизированных тестов, на уже имеющиеся тест кейсы, структура тест скриптов должна быть аналогична структуре тестового случая - Precondition, Steps Post Condition.

Получаем правило, что каждый тест скрипт должен иметь:

  • Precondition
  • Steps (Test)
  • Post Condition

Перечислим основные функции скрипта:

  1. Precondition
    • Инициализация приложения (например, открытие главной страницы, вход под тестовым пользователем, переход в необходимую часть приложения и подведение системы к состоянию пригодному для тестирования)
    • Инициализация тестовых данных
  2. Steps
    • Непосредственное проведение теста
    • Занесение данных о результате теста, с обязательным сохранением причин провала и шагов, по которым проходил тест
  3. Post Condition
    • Удаление, созданных в процессе выполнения скрипта, ненужных тестовых данных
    • Корректное завершение работы приложения

Рекомендуется также создать общую библиотеку по обработке ошибок и исключительных ситуаций. Например:

  • PreConditionException
  • TestCaseException
  • PostConditionException

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

Стратегия использования автоматизированных тестов

Чтобы автоматизация тестирования дала нужные плоды, а именно сократила время на тестирование ПО, предлагается следующее:

  1. Написанием тестов должны заниматься «специально обученные люди» - специалисты по автоматизированному тестированию(Software Automation Testers). После написания, тесты передаются команде ручного тестирования, которая уже осуществляет их ежедневный запуск и анализ результатов. Тем самым автоматизированные тесты также проходят тестирование, и в результате увеличивается их надежность и жизнеспособность.
  2. Написанные и отлаженные тесты также могут передаваться команде разработки, для отладки новых версий.
  3. Команде разработки рекомендуется осуществлять ежедневную сборку, с прогоном всех написанных тестов на всех уровнях автоматизации тестирования. И только после того, как новая версия начинает удовлетворять критериям качества, осуществлять установку новой версии на QA платформу.

Написание и подход к автоматизации тестирования зависит от процесса разработки приложения. Взяв за основу RUP (Rational Unified Process), описанный на страницах блога ПроТестинг, могу предложить следующую процедуру, разбитую на фазы:

  • Inception phase – выбор инструмента автоматизации, в зависимости от которого решается будут ли использоваться уже готовые наработки (фреймворки) или же все будет написано с нуля.
  • Elaboration phase – написание тестов на основную архитектуру (в дальнейшем эти тесты будут использоваться для приема билда – Build Verification Tests)
  • Construction phase – более детальная автоматизация: критическая функциональность, проверка регрессий, end-to-end сценарии
  • Transition phase – подготовка тестов к передаче заказчику (если это требуется)