Jump to content

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

(Перенаправлено из тестовой среды )

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

Общие подходы

[ редактировать ]

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

Другие подходы

[ редактировать ]

Тестирование на основе моделей

[ редактировать ]

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

Регрессионное тестирование

[ редактировать ]

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

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

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

Методологии

[ редактировать ]

Разработка через тестирование

[ редактировать ]

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

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

[ редактировать ]

Непрерывное тестирование — это процесс выполнения автоматических тестов в рамках конвейера доставки программного обеспечения для получения немедленной информации о бизнес-рисках, связанных с кандидатом на выпуск программного обеспечения. [11] [12] При непрерывном тестировании объем тестирования простирается от проверки восходящих требований или пользовательских историй до оценки системных требований, связанных с общими бизнес-целями. [13]

Соображения

[ редактировать ]

Факторы, которые следует учитывать при принятии решения о внедрении автоматизации тестирования

[ редактировать ]

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

Эффект плато

[ редактировать ]

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

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

[ редактировать ]

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

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

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

[ редактировать ]

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

Инженер-испытатель

[ редактировать ]

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

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

[ редактировать ]

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

Уровни устройства, сервиса и пользовательского интерфейса

[ редактировать ]
Пирамида автоматизации тестирования, предложенная Майком Коном [16]
  • Будучи прочной основой, модульное тестирование обеспечивает надежность программных продуктов. Тестирование отдельных частей кода упрощает написание и запуск тестов. Разработчики пишут модульные тесты как часть каждой истории и интегрируют их с CI. [17]
  • Уровень сервиса относится к тестированию сервисов приложения отдельно от его пользовательского интерфейса. Эти сервисы — это все, что приложение делает в ответ на некоторый ввод или набор входных данных.
  • На верхнем уровне у нас есть тестирование пользовательского интерфейса , в котором меньше тестов из-за различных атрибутов, усложняющих его выполнение, например, из-за нестабильности тестов, когда небольшое изменение в пользовательском интерфейсе может сломать множество тестов и усложнить обслуживание. усилие. [16] [18]

Единичный, интеграционный и сквозной уровни

[ редактировать ]
Треугольная диаграмма, изображающая «пирамиду тестирования» Google. Прогрессирует от самого маленького раздела «E2E» вверху к «Интеграции» посередине и к самому большому разделу «Подразделение» внизу.
Пирамида тестирования Google [19]

Одна из концепций пирамиды тестирования включает модульные, интеграционные и сквозные модульные тесты. Согласно блогу тестирования Google , модульные тесты должны составлять большую часть вашей стратегии тестирования, с меньшим количеством интеграционных тестов и лишь небольшим количеством сквозных тестов. [19]

  • Модульные тесты. Это тесты, которые проверяют отдельные компоненты или единицы кода изолированно. Они быстрые, надежные и изолируют сбои в небольших фрагментах кода.
  • Интеграционные тесты. Эти тесты проверяют, как разные блоки кода работают вместе. Хотя отдельные блоки могут нормально функционировать самостоятельно, интеграционные тесты гарантируют их слаженную работу.
  • Сквозные тесты. Они тестируют систему в целом, моделируя реальные сценарии использования. Это самые медленные и сложные тесты.

Рамочный подход в автоматизации

[ редактировать ]

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

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

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

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

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

Структура тестирования отвечает за: [20]

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

Фреймворки модульного тестирования

[ редактировать ]

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

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

[ редактировать ]

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

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

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

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

Интерфейсный движок

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

Тестирование на основе данных

[ редактировать ]
Тестирование, управляемое данными (DDT), также известное как тестирование на основе таблиц или параметризованное тестирование, представляет собой методологию тестирования программного обеспечения , которая используется при тестировании компьютерного программного обеспечения для описания тестирования, проводимого с использованием таблицы условий непосредственно в качестве тестовых входных данных и проверяемых выходных данных, как а также процесс, в котором настройки и контроль тестовой среды не запрограммированы жестко. [22] [23] В простейшей форме тестер предоставляет входные данные из строки таблицы и ожидает выходные данные, которые встречаются в той же строке. Таблица обычно содержит значения, которые соответствуют входным пространствам границ или разделов. В методологии управления тестовая конфигурация «считывается» из базы данных.

Модульное тестирование

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

Тестирование по ключевым словам

[ редактировать ]
Тестирование на основе ключевых слов , также известное как тестирование на основе слов-действий (не путать с тестированием на основе действий), представляет собой методологию тестирования программного обеспечения, подходящую как для ручного , так и для автоматического тестирования . Этот метод отделяет документацию тестовых примеров , включая используемые данные и функциональные возможности, от предписаний способа выполнения тестовых примеров. В результате процесс создания теста разделяется на два отдельных этапа: этап проектирования и разработки и этап выполнения. Подэтап проектирования охватывает анализ и оценку требований , а также анализ, определение и популяцию данных.

Гибридное тестирование

[ редактировать ]
Гибридное тестирование — это то, во что большинство фреймворков развиваются/развиваются с течением времени и в рамках нескольких проектов. Наиболее успешные среды автоматизации обычно охватывают как грамматику, так и правописание, а также ввод информации. Это позволяет сверять предоставленную информацию с существующей и подтвержденной информацией. Это помогает предотвратить публикацию ложной или вводящей в заблуждение информации. Однако он по-прежнему позволяет другим публиковать новую и актуальную информацию в существующих сообщениях, что повышает полезность и актуальность сайта. Тем не менее, ни одна система не идеальна, и она может не всегда соответствовать этому стандарту по всем предметам, но будет улучшаться по мере увеличения объема вводимых ресурсов и расширения использования.

Тестирование на основе моделей

[ редактировать ]
Общие настройки тестирования на основе модели
Тестирование на основе моделей — это применение проектирования на основе моделей для проектирования и, при необходимости, также выполнения артефактов для тестирования программного обеспечения или системы . Модели можно использовать для представления желаемого поведения тестируемой системы (SUT) или для представления стратегий тестирования и тестовой среды. На рисунке справа изображен первый подход.

Развитие, основанное на поведении

[ редактировать ]
Разработка, управляемая поведением (BDD), включает в себя наименование тестов программного обеспечения с использованием языка предметной области для описания поведения кода .

См. также

[ редактировать ]
  1. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 74. ИСБН  978-0-470-04212-0 .
  2. ^ О'Коннор, Рори В.; Аккая, Марие Умай; Кеманечи, Керем; Йылмаз, Мурат; Пот, Александр; Месснарц, Ричард (15 октября 2015 г.). Улучшение процессов систем, программного обеспечения и услуг: 22-я Европейская конференция EuroSPI 2015, Анкара, Турция, 30 сентября — 2 октября 2015 г. Материалы . Спрингер. ISBN  978-3-319-24647-5 .
  3. ^ Материалы 5-й Международной конференции по тестированию и валидации программного обеспечения (ICST). Центр разработки программного обеспечения в Хагенберге. «Разработка тестов: извлеченные уроки и практические последствия» . doi : 10.1109/IEESTD.2008.4578383 . ISBN .  978-0-7381-5746-7 .
  4. ^ API-интерфейсы тестирования защищают приложения и репутацию , Эми Райхерт, SearchSoftwareQuality, март 2015 г.
  5. ^ Все о тестировании API: интервью с Джонатаном Купером , Кэмерон Филипп-Эдмондс, Stickyminds, 19 августа 2014 г.
  6. ^ Производите лучшее программное обеспечение, используя стратегию многоуровневого тестирования , Шон Кенефик, Gartner, 7 января 2014 г.
  7. ^ Безголовое тестирование с помощью браузеров; https://docs.travis-ci.com/user/gui-and-headless-browsers/
  8. ^ Безголовое тестирование с PhantomJS; http://phantomjs.org/headless-testing.html
  9. ^ Автоматизированное тестирование пользовательского интерфейса; https://www.devbridge.com/articles/automated-user-interface-testing/
  10. ^ Водде, Бас; Коскела, Лассе (2007). «Изучение разработки через тестирование путем подсчета строк». Программное обеспечение IEEE . 24 (3): 74–79. дои : 10.1109/ms.2007.80 . S2CID   30671391 .
  11. ^ Часть конвейера: почему важно непрерывное тестирование , Адам Ауэрбах, TechWell Insights, август 2015 г.
  12. ^ Взаимосвязь между риском и непрерывным тестированием: интервью с Уэйном Ариолой , Кэмерон Филипп-Эдмондс, Stickyminds, декабрь 2015 г.
  13. ^ DevOps: вы быстрее сообщаете клиентам об ошибках , Уэйн Ариола и Синтия Данлоп, PNSQC, октябрь 2015 г.
  14. ^ Брайан Марик. «Когда тест следует автоматизировать?» . StickyMinds.com . Проверено 20 августа 2009 г.
  15. ^ Гаруси, Вахид; Мянтюля, Мика В. (01 августа 2016 г.). «Когда и что автоматизировать при тестировании программного обеспечения? Многосторонний обзор литературы». Информационные и программные технологии . 76 : 92–117. дои : 10.1016/j.infsof.2016.04.015 .
  16. ^ Перейти обратно: а б с Майк Кон (2010). Успех в Agile . Райна Хробак. ISBN  978-0-321-57936-2 .
  17. ^ «Полномасштабное тестирование Гаятри Мохана» . www. ThoughtWorks.com . Проверено 13 сентября 2022 г.
  18. ^ Пирамида практических испытаний , Хэм Воке
  19. ^ Перейти обратно: а б «Просто скажите нет большему количеству сквозных тестов» . Блог Google по тестированию . Проверено 11 февраля 2023 г.
  20. ^ «Встреча Selenium, 20 апреля 2010 г., Элизабет Хендриксон, посвященная Robot Framework 1of2» . Ютуб . 28 апреля 2010 года . Проверено 26 сентября 2010 г.
  21. ^ Перейти обратно: а б с «Завоевание: интерфейс для проектирования автоматизации тестирования» (PDF) . Архивировано из оригинала (PDF) 26 апреля 2012 г. Проверено 11 декабря 2011 г.
  22. ^ "golang/go TableDrivenTests" . Гитхаб .
  23. ^ «Руководство пользователя JUnit 5» . junit.org .
  24. ^ ДЕСАИ, САНДИП; ШРИВАСТАВА, АБХИШЕК (30 января 2016 г.). ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: Практический подход (на арабском языке). PHI Learning Pvt. ООО ISBN  978-81-203-5226-1 .

Общие ссылки

[ редактировать ]


Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: d9535555a42c360782f4ced89921717c__1720505580
URL1:https://arc.ask3.ru/arc/aa/d9/7c/d9535555a42c360782f4ced89921717c.html
Заголовок, (Title) документа по адресу, URL1:
Test automation - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)