Автоматизация тестирования
| Часть серии о |
| Разработка программного обеспечения |
|---|
 | Эта статья включает список общих ссылок , но в ней отсутствуют достаточные соответствующие встроенные цитаты . ( февраль 2009 г. ) |
В тестировании программного обеспечения автоматизация тестирования — это использование программного обеспечения отдельно от тестируемого программного обеспечения для управления выполнением тестов и сравнения фактических результатов с прогнозируемыми результатами. [1] Автоматизация тестирования может автоматизировать некоторые повторяющиеся, но необходимые задачи в уже существующем формализованном процессе тестирования или выполнить дополнительное тестирование, которое было бы сложно выполнить вручную. Автоматизация тестирования имеет решающее значение для непрерывной поставки и непрерывного тестирования . [2]
Общие подходы
[ редактировать ]Существует множество подходов к автоматизации тестирования, однако ниже приведены общие широко используемые подходы:
- Тестирование графического пользовательского интерфейса . Платформа тестирования, которая генерирует события пользовательского интерфейса, такие как нажатия клавиш и щелчки мыши, и наблюдает за изменениями, которые приводят к пользовательскому интерфейсу, чтобы проверить правильность наблюдаемого поведения программы.
- Тестирование на основе API . Платформа тестирования, использующая программный интерфейс приложения для проверки тестируемого поведения. Обычно тестирование на основе API полностью обходит пользовательский интерфейс приложения. Это также может быть тестирование общедоступных (обычно) интерфейсов классов, модулей или библиотек, которые проверяются с использованием различных входных аргументов для проверки правильности возвращаемых результатов.
Другие подходы
[ редактировать ]Тестирование на основе моделей
[ редактировать ]Одним из способов автоматического создания тестовых примеров является тестирование на основе модели с использованием модели системы для создания тестовых примеров, но продолжаются исследования различных альтернативных методологий для этого. [ нужна ссылка ] В некоторых случаях подход, основанный на моделях, позволяет нетехническим пользователям создавать автоматизированные бизнес-тестовые примеры на простом английском языке, так что для их настройки для нескольких операционных систем, браузеров и интеллектуальных устройств не требуется никакого программирования. [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]
Эффект плато
[ редактировать ]Хотя возможность повторного использования автоматизированных тестов ценится компаниями-разработчиками программного обеспечения, это свойство также можно рассматривать как недостаток. Это приводит к так называемому «парадоксу пестицидов» , когда многократно выполняемые скрипты перестают обнаруживать ошибки, выходящие за рамки их рамок. В таких случаях ручное тестирование может быть лучшим вложением средств. Эта неоднозначность еще раз приводит к выводу, что решение об автоматизации тестирования должно приниматься индивидуально, учитывая требования и особенности проекта.
Что протестировать
[ редактировать ]Инструменты тестирования могут помочь автоматизировать такие задачи, как установка продукта, создание тестовых данных, взаимодействие с графическим пользовательским интерфейсом, обнаружение проблем (рассмотрим агенты синтаксического анализа или опроса, оснащенные тестовыми оракулами ), регистрацию дефектов и т. д. без обязательной сквозной автоматизации тестов. .
Думая об автоматизации тестирования, необходимо продолжать удовлетворять популярные требования:
- платформы и ОС Независимость от
- Возможность управления данными (входные данные, выходные данные, метаданные )
- Отчеты о настройке ( доступ к базе данных БД , Crystal Reports )
- Простая отладка и протоколирование
- Удобство контроля версий – минимальное количество двоичных файлов.
- Расширяемость и настройка (открытые API для возможности интеграции с другими инструментами)
- Общий драйвер (например, в экосистеме разработки Java это означает Ant или Maven и популярные IDE ). разработчиков Это позволяет тестам интегрироваться с рабочими процессами .
- Поддержка автоматических тестовых запусков для интеграции с процессами сборки и пакетными запусками. непрерывной интеграции . Этого требуют серверы
- Уведомления по электронной почте, такие как сообщения о недоставке
- Поддержка распределенной среды выполнения (распределенный испытательный стенд )
- Поддержка распределенных приложений (распределенная SUT )
Роли
[ редактировать ]Инструменты автоматизации тестирования
[ редактировать ]Инструменты автоматизации тестирования могут быть дорогими и обычно используются в сочетании с ручным тестированием. Автоматизация тестирования может стать экономически эффективной в долгосрочной перспективе, особенно при многократном использовании в регрессионном тестировании . Хорошим кандидатом на автоматизацию тестирования является тестовый пример для общего потока приложения, поскольку его необходимо выполнять (регрессионное тестирование) каждый раз, когда в приложении вносятся улучшения. Автоматизация тестирования сокращает усилия, связанные с ручным тестированием. Для разработки и поддержки автоматических проверок, а также для анализа результатов испытаний необходимы ручные усилия.
Инженер-испытатель
[ редактировать ]При автоматизированном тестировании инженер по тестированию или специалист по обеспечению качества программного обеспечения должен обладать способностью кодировать программное обеспечение, поскольку тестовые примеры записываются в форме исходного кода, который при запуске выдает выходные данные в соответствии с утверждениями , которые являются его частью. Некоторые инструменты автоматизации тестирования позволяют создавать тесты с помощью ключевых слов вместо кодирования, что не требует программирования.
Тестирование на разных уровнях
[ редактировать ]Стратегией определения количества тестов для автоматизации является пирамида автоматизации тестирования. Эта стратегия предлагает написать три типа тестов с разной степенью детализации. Чем выше уровень, тем меньше нужно писать тестов. [16]
Уровни устройства, сервиса и пользовательского интерфейса
[ редактировать ]
- Будучи прочной основой, модульное тестирование обеспечивает надежность программных продуктов. Тестирование отдельных частей кода упрощает написание и запуск тестов. Разработчики пишут модульные тесты как часть каждой истории и интегрируют их с CI. [17]
- Уровень сервиса относится к тестированию сервисов приложения отдельно от его пользовательского интерфейса. Эти сервисы — это все, что приложение делает в ответ на некоторый ввод или набор входных данных.
- На верхнем уровне у нас есть тестирование пользовательского интерфейса , в котором меньше тестов из-за различных атрибутов, усложняющих его выполнение, например, из-за нестабильности тестов, когда небольшое изменение в пользовательском интерфейсе может сломать множество тестов и усложнить обслуживание. усилие. [16] [18]
Единичный, интеграционный и сквозной уровни
[ редактировать ]
Одна из концепций пирамиды тестирования включает модульные, интеграционные и сквозные модульные тесты. Согласно блогу тестирования Google , модульные тесты должны составлять большую часть вашей стратегии тестирования, с меньшим количеством интеграционных тестов и лишь небольшим количеством сквозных тестов. [19]
- Модульные тесты. Это тесты, которые проверяют отдельные компоненты или единицы кода изолированно. Они быстрые, надежные и изолируют сбои в небольших фрагментах кода.
- Интеграционные тесты. Эти тесты проверяют, как разные блоки кода работают вместе. Хотя отдельные блоки могут нормально функционировать самостоятельно, интеграционные тесты гарантируют их слаженную работу.
- Сквозные тесты. Они тестируют систему в целом, моделируя реальные сценарии использования. Это самые медленные и сложные тесты.
Рамочный подход в автоматизации
[ редактировать ]Фреймворк автоматизации тестирования — это интегрированная система, задающая правила автоматизации конкретного продукта. Эта система объединяет библиотеки функций, источники тестовых данных, детали объектов и различные модули многократного использования. Эти компоненты действуют как небольшие строительные блоки, которые необходимо собрать для представления бизнес-процесса. Платформа обеспечивает основу для автоматизации тестирования и упрощает процесс автоматизации.
Основным преимуществом системы предположений , концепций и инструментов, обеспечивающих поддержку автоматизированного тестирования программного обеспечения, является низкая стоимость обслуживания . внесены изменения Если в какой-либо тестовый пример , то необходимо обновить только файл тестового сценария, а сценарий драйвера и сценарий запуска останутся прежними. В идеале нет необходимости обновлять скрипты в случае изменений в приложении.
Выбор правильной структуры/методики написания сценариев помогает снизить затраты. Затраты, связанные с написанием тестовых сценариев, связаны с усилиями по разработке и обслуживанию. Подход к написанию сценариев, используемый при автоматизации тестирования, влияет на затраты.
Обычно используются различные методы фреймворка/сценариев:
- Линейный (процедурный код, возможно, созданный с помощью инструментов, подобных тем, которые используют запись и воспроизведение)
- Структурированный (использует управляющие структуры — обычно условия/операторы «if-else», «switch», «for», «пока»)
- Управляемый данными (данные сохраняются вне тестов в базе данных, электронной таблице или другом механизме)
- На основе ключевых слов
- Гибридный (используются два или более шаблонов, указанных выше)
- Гибкая система автоматизации
Структура тестирования отвечает за: [20]
- определение формата выражения ожиданий
- создание механизма для подключения или управления тестируемым приложением
- выполнение тестов
- отчет о результатах
Фреймворки модульного тестирования
[ редактировать ]Растущая тенденция в разработке программного обеспечения — использование платформ модульного тестирования , таких как платформы xUnit (например, JUnit и NUnit ), которые позволяют выполнять модульные тесты, чтобы определить, ли различные разделы кода действуют ожидаемым образом при различных обстоятельствах. Тестовые случаи описывают тесты, которые необходимо запустить в программе, чтобы убедиться, что программа работает должным образом.
Интерфейс автоматизации тестирования
[ редактировать ]Интерфейсы автоматизации тестирования — это платформы, которые предоставляют единое рабочее пространство для включения нескольких инструментов тестирования и платформ для системного/интеграционного тестирования тестируемого приложения. Цель интерфейса автоматизации тестирования — упростить процесс сопоставления тестов с бизнес-критериями, не мешая этому процессу написанию кода. Ожидается, что интерфейс автоматизации тестирования повысит эффективность и гибкость поддержки тестовых сценариев. [21]
Интерфейс автоматизации тестирования состоит из следующих основных модулей:
- Механизм интерфейса
- Интерфейсная среда
- Репозиторий объектов
Интерфейсный движок
[ редактировать ]Механизмы интерфейса построены на основе среды интерфейса. Интерфейсный движок состоит из парсера и средства запуска тестов. Синтаксический анализатор предназначен для анализа объектных файлов, поступающих из репозитория объектов, на язык сценариев, специфичный для теста. Средство запуска тестов выполняет тестовые сценарии, используя тестовую программу . [21]
Репозиторий объектов
[ редактировать ]Репозитории объектов — это набор данных объектов пользовательского интерфейса/приложения, записанных инструментом тестирования во время изучения тестируемого приложения. [21]
Определение границ между средой автоматизации и инструментом тестирования
[ редактировать ]Инструменты специально разработаны для определенной среды тестирования, такой как Windows, инструменты веб-автоматизации и т. д. Инструменты служат движущей силой процесса автоматизации. Однако среда автоматизации — это не инструмент для выполнения конкретной задачи, а скорее инфраструктура, обеспечивающая решение, при котором различные инструменты могут выполнять свою работу унифицированным образом. Это обеспечивает общую платформу для инженера по автоматизации.
Существуют различные типы фреймворков. Они классифицируются в зависимости от используемого компонента автоматизации. Это:
- Тестирование на основе данных
- Модульное тестирование
- Тестирование по ключевым словам
- Гибридное тестирование
- Тестирование на основе моделей
- Тестирование на основе кода
- Развитие, основанное на поведении
Тестирование на основе данных
[ редактировать ]Модульное тестирование
[ редактировать ]Тестирование по ключевым словам
[ редактировать ]Гибридное тестирование
[ редактировать ]Тестирование на основе моделей
[ редактировать ]
Развитие, основанное на поведении
[ редактировать ]См. также
[ редактировать ]- Сравнение инструментов тестирования графического интерфейса
- Список инструментов веб-тестирования
- Непрерывное тестирование
- Фаззинг
- Безголовый браузер
- Тестирование программного обеспечения
- Тестирование системы
- Юнит-тест
Ссылки
[ редактировать ]- ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 74. ИСБН 978-0-470-04212-0 .
- ^ О'Коннор, Рори В.; Аккая, Марие Умай; Кеманечи, Керем; Йылмаз, Мурат; Пот, Александр; Месснарц, Ричард (15 октября 2015 г.). Улучшение процессов систем, программного обеспечения и услуг: 22-я Европейская конференция EuroSPI 2015, Анкара, Турция, 30 сентября — 2 октября 2015 г. Материалы . Спрингер. ISBN 978-3-319-24647-5 .
- ^ Материалы 5-й Международной конференции по тестированию и валидации программного обеспечения (ICST). Центр разработки программного обеспечения в Хагенберге. «Разработка тестов: извлеченные уроки и практические последствия» . doi : 10.1109/IEESTD.2008.4578383 . ISBN . 978-0-7381-5746-7 .
- ^ API-интерфейсы тестирования защищают приложения и репутацию , Эми Райхерт, SearchSoftwareQuality, март 2015 г.
- ^ Все о тестировании API: интервью с Джонатаном Купером , Кэмерон Филипп-Эдмондс, Stickyminds, 19 августа 2014 г.
- ^ Производите лучшее программное обеспечение, используя стратегию многоуровневого тестирования , Шон Кенефик, Gartner, 7 января 2014 г.
- ^ Безголовое тестирование с помощью браузеров; https://docs.travis-ci.com/user/gui-and-headless-browsers/
- ^ Безголовое тестирование с PhantomJS; http://phantomjs.org/headless-testing.html
- ^ Автоматизированное тестирование пользовательского интерфейса; https://www.devbridge.com/articles/automated-user-interface-testing/
- ^ Водде, Бас; Коскела, Лассе (2007). «Изучение разработки через тестирование путем подсчета строк». Программное обеспечение IEEE . 24 (3): 74–79. дои : 10.1109/ms.2007.80 . S2CID 30671391 .
- ^ Часть конвейера: почему важно непрерывное тестирование , Адам Ауэрбах, TechWell Insights, август 2015 г.
- ^ Взаимосвязь между риском и непрерывным тестированием: интервью с Уэйном Ариолой , Кэмерон Филипп-Эдмондс, Stickyminds, декабрь 2015 г.
- ^ DevOps: вы быстрее сообщаете клиентам об ошибках , Уэйн Ариола и Синтия Данлоп, PNSQC, октябрь 2015 г.
- ^ Брайан Марик. «Когда тест следует автоматизировать?» . StickyMinds.com . Проверено 20 августа 2009 г.
- ^ Гаруси, Вахид; Мянтюля, Мика В. (01 августа 2016 г.). «Когда и что автоматизировать при тестировании программного обеспечения? Многосторонний обзор литературы». Информационные и программные технологии . 76 : 92–117. дои : 10.1016/j.infsof.2016.04.015 .
- ^ Перейти обратно: а б с Майк Кон (2010). Успех в Agile . Райна Хробак. ISBN 978-0-321-57936-2 .
- ^ «Полномасштабное тестирование Гаятри Мохана» . www. ThoughtWorks.com . Проверено 13 сентября 2022 г.
- ^ Пирамида практических испытаний , Хэм Воке
- ^ Перейти обратно: а б «Просто скажите нет большему количеству сквозных тестов» . Блог Google по тестированию . Проверено 11 февраля 2023 г.
- ^ «Встреча Selenium, 20 апреля 2010 г., Элизабет Хендриксон, посвященная Robot Framework 1of2» . Ютуб . 28 апреля 2010 года . Проверено 26 сентября 2010 г.
- ^ Перейти обратно: а б с «Завоевание: интерфейс для проектирования автоматизации тестирования» (PDF) . Архивировано из оригинала (PDF) 26 апреля 2012 г. Проверено 11 декабря 2011 г.
- ^ "golang/go TableDrivenTests" . Гитхаб .
- ^ «Руководство пользователя JUnit 5» . junit.org .
- ^ ДЕСАИ, САНДИП; ШРИВАСТАВА, АБХИШЕК (30 января 2016 г.). ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: Практический подход (на арабском языке). PHI Learning Pvt. ООО ISBN 978-81-203-5226-1 .
Общие ссылки
[ редактировать ]- Эльфрида Дастин; и др. (1999). Автоматизированное тестирование программного обеспечения . Эддисон Уэсли. ISBN 978-0-201-43287-9 .
- Эльфрида Дастин; и др. (2009). Внедрение автоматизированного тестирования программного обеспечения . Эддисон Уэсли. ISBN 978-0-321-58051-1 .
- Марк Фьюстер и Дороти Грэм (1999). Автоматизация тестирования программного обеспечения . ACM Press/Эддисон-Уэсли. ISBN 978-0-201-33140-0 .
- Роман Савенков: Как стать тестировщиком программного обеспечения. Роман Савенков Консалтинг, 2008 г., ISBN 978-0-615-23372-7
- Хун Чжу; и др. (2008). АСТ '08: Материалы 3-го международного семинара по автоматизации тестирования программного обеспечения . АКМ Пресс. дои : 10.1145/1370042 . ISBN 978-1-60558-030-2 .
- Мосли, Дэниел Дж.; Поузи, Брюс (2002). Достаточно автоматизации тестирования программного обеспечения . Прентис Холл Профессионал. ISBN 978-0130084682 .
- Хейс, Линда Г., «Справочник по автоматизированному тестированию», Институт тестирования программного обеспечения, 2-е издание, март 2004 г.
- Канер, Джем, « Архитектуры автоматизации тестирования, архивировано 26 января 2021 г. в Wayback Machine », август 2000 г.