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

редактировать
Использование специального программного обеспечения (отдельно от того, что тестируется) для управления выполнением тестов и сравнения фактических результатов с прогнозируемыми

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

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

  • Тестирование графического интерфейса пользователя. Среда тестирования, которая генерирует пользовательский интерфейс события, такие как нажатия клавиш и щелчки мыши, и наблюдает за изменениями, которые приводят к пользовательскому интерфейсу, чтобы проверить правильность наблюдаемого поведения программы.
  • Тестирование на основе API. Платформа тестирования, использующая программный интерфейс к приложению для проверки тестируемого поведения. Обычно тестирование, управляемое API, полностью обходит пользовательский интерфейс приложения. Это также может быть тестирование общедоступных (обычно) интерфейсов к классам, модулям или библиотекам, которые тестируются с различными входными аргументами для проверки правильности возвращаемых результатов.

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

Что автоматизировать, когда автоматизировать или даже действительно ли автоматизация нужна, - вот важные решения, которые должна принять команда тестирования (или разработки). Многосторонний обзор литературы 52 практикующих специалистов и 26 академических источников показал, что при принятии решения об автоматизации тестирования следует учитывать пять основных факторов: 1) Тестируемая система (SUT), 2) типы и количество тестов, 3) инструмент тестирования, 4) человеческие и организационные темы и 5) сквозные факторы. Наиболее частыми индивидуальными факторами, выявленными в ходе исследования, были: необходимость регрессионного тестирования, экономические факторы и зрелость SUT.

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

Автоматизация тестирования, в основном с использованием модульного тестирования, является ключевой особенностью экстремального программирования и гибкой разработки программного обеспечения, где она известна как разработка через тестирование. (TDD) или разработка с предварительным тестированием. Модульные тесты могут быть написаны для определения функциональности до написания кода. Однако эти модульные тесты развиваются и расширяются по мере продвижения кода, обнаружения проблем и рефакторинга кода. Код считается завершенным только после прохождения всех тестов для всех требуемых функций. Сторонники утверждают, что он производит программное обеспечение, которое является более надежным и менее дорогостоящим, чем код, тестируемый вручную. Он считается более надежным, потому что охват кода лучше, и потому, что он выполняется постоянно во время разработки, а не один раз в конце цикла разработки водопад. Разработчик обнаруживает дефекты сразу после внесения изменений, когда их исправлять дешевле всего. Наконец, рефакторинг кода безопаснее при модульном тестировании; преобразование кода в более простую форму с меньшим дублированием кода, но с эквивалентным поведением, с гораздо меньшей вероятностью приведет к появлению новых дефектов, когда отрефакторный код покрывается модульными тестами.

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

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

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

Инструменты автоматизации тестирования могут быть дорогими и обычно используются в сочетании с ручным тестированием. Автоматизацию тестирования можно сделать рентабельной в долгосрочной перспективе, особенно при многократном использовании в регрессионном тестировании. Хорошим кандидатом на автоматизацию тестирования является тестовый пример для общего потока приложения, поскольку он должен выполняться (регрессионное тестирование) каждый раз, когда в приложение вносятся улучшения. Автоматизация тестирования снижает трудозатраты, связанные с ручным тестированием. Ручные усилия необходимы для разработки и поддержки автоматических проверок, а также для анализа результатов тестирования.

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

Содержание

  • 1 Тестирование на основе API
  • 2 Непрерывное тестирование
  • 3 Тестирование графического интерфейса пользователя (GUI)
  • 4 Тестирование на разных уровнях
    • 4.1 Уровни:
  • 5 Подход к автоматизации
    • 5.1 Интерфейс автоматизации тестирования
    • 5.2 Механизм интерфейса
    • 5.3 Репозиторий объектов
  • 6 Определение границ между средой автоматизации и инструментом тестирования
  • 7 Что тестировать
  • 8 См. Также
  • 9 Ссылки
    • 9.1 Общие ссылки
  • 10 Внешние ссылки

Тестирование на основе API

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

Непрерывное тестирование

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

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

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

Вариант этого типа инструмента предназначен для тестирования веб-сайтов. Здесь «интерфейс» - это веб-страница. Однако в такой структуре используются совершенно другие методы, поскольку она отображает HTML и прослушивает события DOM вместо событий операционной системы. Безголовые браузеры или решения, основанные на Selenium Web Driver, обычно используются для этой цели.

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

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

Тестирование на разных уровнях

Пирамида автоматизации тестирования, предложенная Майком Коном

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

Уровни:

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

Подход к автоматизации в рамках концепции

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

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

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

Обычно используются различные фреймворки / методы написания сценариев:

  1. Линейный (процедурный код, возможно, сгенерированный такими инструментами, как те, которые используют запись и воспроизведение)
  2. Структурированный (использует управляющие структуры - обычно 'если -else ',' switch ',' for ',' while ', условия / инструкции)
  3. Управляемые данными (данные сохраняются вне тестов в базе данных, электронной таблице или другом механизме)
  4. Ключевое слово- управляемый
  5. Гибридный (используются два или более шаблонов, приведенных выше)
  6. Фреймворк для гибкой автоматизации

Фреймворк тестирования отвечает за:

  1. определение формата, в котором выражаются ожидания
  2. создание механизма для подключения или управления тестируемым приложением
  3. выполнение тестов
  4. отчет о результатах

интерфейс автоматизации тестирования

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

Модель интерфейса автоматизации тестирования

Интерфейс автоматизации тестирования состоит из следующих основных модулей:

  • Интерфейсный движок
  • Интерфейсная среда
  • Репозиторий объектов

Механизм интерфейса

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

Репозиторий объектов

Репозитории объектов - это набор данных объектов пользовательского интерфейса / приложения, записанных инструментом тестирования при исследовании тестируемого приложения.

Определение границ между платформой автоматизации и инструментом тестирования

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

Существуют различные типы каркасов. Они классифицируются на основе компонента автоматизации, который они используют. Это:

  1. Тестирование на основе данных
  2. Тестирование на основе модульности
  3. Тестирование на основе ключевых слов
  4. Гибридное тестирование
  5. Тестирование на основе модели
  6. Тестирование на основе кода
  7. Разработка на основе поведения

Что тестировать

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

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

  • Платформа и OS независимость
  • Возможность управления данными (входные данные, выходные данные, Метаданные )
  • Настройка отчетов (DB Data Base Access, Crystal Reports )
  • Простая отладка и ведение журнала
  • Контроль версий удобство - минимум двоичных файлов
  • Расширяемость и настройка (откройте API для возможности интеграции с другими инструментами)
  • Общий драйвер (например, в экосистеме разработки Java это означает Ant или Maven и популярные IDE ). Это позволяет тестам интегрироваться с рабочими процессами разработчиков.
  • Поддержка автоматических тестовых запусков для интеграции с процессами сборки и пакетными запусками. Непрерывная интеграция серверов требует этого.
  • Уведомления по электронной почте, такие как рикошеты
  • Поддержка среды распределенного выполнения (распределенная испытательная площадка )
  • Поддержка распределенных приложений (распределенная SUT )

См. Также

Ссылки

Общие ссылки

Внешние ссылки

Последняя правка сделана 2021-06-10 02:35:28
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте