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

Test automation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платформа и Операционные системы независимость
Возможность управления данными (входные данные, выходные данные, Метаданные)
Отчетность по настройке (БД База данных Доступ, Crystal Reports)
Легкая отладка и ведение журнала
Управление версиями дружественный - минимальные двоичные файлы
Расширяемый и настраиваемый (открытый API чтобы иметь возможность интегрироваться с другими инструментами)
Общий драйвер (например, в экосистеме разработки Java это означает Муравей или же Maven и популярные Иды). Это позволяет интегрировать тесты с разработчиками. рабочие процессы.
Поддержка автоматических тестовых запусков для интеграции с процессами сборки и пакетными запусками. Непрерывная интеграция серверы требуют этого.
Уведомления по электронной почте вроде сообщения возврата
Поддержка распределенной среды выполнения (распределенная испытательный стенд)
Распределенная поддержка приложений (распределенная SUT)

Смотрите также

внешняя ссылка

[1] Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: передовой опыт управления программным обеспечением. Пресса компьютерного общества Wiley-IEEE. п. 74. ISBN 978-0-470-04212-0.

[2] Материалы 5-й Международной конференции по тестированию и валидации программного обеспечения (ICST). Центр компетенции в области программного обеспечения Хагенберг. "Дизайн тестов: извлеченные уроки и практическое применение. Дои:10.1109 / IEEESTD.2008.4578383. ISBN 978-0-7381-5746-7.

[3] Брайан Марик. "Когда следует автоматизировать тест?". StickyMinds.com. Получено 2009-08-20.

[4] Гаруси, Вахид; Мянтюля, Мика В. (01.08.2016). «Когда и что автоматизировать при тестировании программного обеспечения? Многоголосый обзор литературы». Информационные и программные технологии. 76: 92–117. Дои:10.1016 / j.infsof.2016.04.015.

[Learning_TDD-5] Водде, Бас; Коскела, Лассе (2007). «Обучение разработке, основанной на тестировании, путем подсчета строк». Программное обеспечение IEEE. 24 (3): 74–79. Дои:10.1109 / мс.2007.80. S2CID 30671391.

[reichart1-6] API тестирования защищает приложения и репутацию, Эми Райхерт, SearchSoftwareQuality, март 2015 г.

[stickyminds-7] Все о тестировании API: интервью с Джонатаном Купером, Кэмерон Филипп-Эдмондс, Stickyminds, 19 августа 2014 г.

[8] Создавайте лучшее программное обеспечение, используя стратегию многоуровневого тестирования, автор: Шон Кенефик, Gartner 7 января 2014 г.

[essential-9] Часть конвейера: почему так важно непрерывное тестирование, Адам Ауэрбах, TechWell Insights, август 2015 г.

[stickym-10] Взаимосвязь между риском и непрерывным тестированием: интервью с Уэйном Ариолой, Кэмерон Филипп-Эдмондс, Stickyminds, декабрь 2015 г.

[pnsqc-11] DevOps: вы быстрее сообщаете клиентам ошибки, Уэйн Ариола и Синтия Данлоп, PNSQC, октябрь 2015 г.

[12] Безголовое тестирование с браузерами; https://docs.travis-ci.com/user/gui-and-headless-browsers/

[Headless_Testing_with_Browsers-13] Безголовое тестирование с PhantomJS;http://phantomjs.org/headless-testing.html

[14] Автоматизированное тестирование пользовательского интерфейса; https://www.devbridge.com/articles/automated-user-interface-testing/

[:0-15] а ^б ^c Майк Кон (2010). Успех с Agile. Райна Хробак. ISBN 978-0-321-57936-2.

[16] Пирамида практических испытаний, Хэм Воке

[17] «Встреча Selenium, 20 апреля 2010 г., Элизабет Хендриксон о Robot Framework 1 из 2». Получено 2010-09-26.

[Interface-18] а ^б ^c "Conquest: интерфейс для проектирования автоматизации тестирования" (PDF). Получено 2011-12-11.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

Navigation