Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
См. Также: Ручное тестирование
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
  • Компилятор
  • Отладчик
  • Профайлер
  • Дизайнер графического интерфейса
  • Моделирование
  • IDE
  • Автоматизация сборки
  • Автоматизация выпуска
  • Инфраструктура как код
  • Тестирование
Стандарты и свод знаний
  • БАБОК
  • CMMI
  • Стандарты IEEE
  • ISO 9001
  • Стандарты ISO / IEC
  • PMBOK
  • SWEBOK
  • ITIL
  • IREB
Глоссарии
  • Искусственный интеллект
  • Информатика
  • Электротехника и электроника
Контуры
  • План разработки программного обеспечения
  • v
  • т
  • е

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование API [ править ]

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

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

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

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

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

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

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

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

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

Тестирование на разных уровнях [ править ]

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

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

Уровни [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интерфейсный движок [ править ]

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

Хранилище объектов [ править ]

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

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

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

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

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

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

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

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

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

См. Также [ править ]

  • Список инструментов тестирования графического интерфейса пользователя
  • Список инструментов веб-тестирования
  • Непрерывное тестирование
  • Расплывание
  • Безголовый браузер
  • Тестирование программного обеспечения
  • Системное тестирование
  • Модульный тест

Ссылки [ править ]

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

Общие ссылки [ править ]

  • Эльфриде Дастин; и другие. (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). AST '08: Материалы 3-го Международного семинара по автоматизации тестирования программного обеспечения . ACM Press. DOI : 10.1145 / 1370042 . ISBN 978-1-60558-030-2.
  • Мосли, Дэниел Дж .; Поузи, Брюс (2002). Достаточно автоматизации тестирования программного обеспечения . ISBN 978-0130084682.
  • Хейс, Линда Г., «Руководство по автоматизированному тестированию», Институт тестирования программного обеспечения, 2-е издание, март 2004 г.
  • Канер, Джем, " Архитектуры автоматизации тестирования ", август 2000 г.

Внешние ссылки [ править ]

  • Практический опыт автоматизированного тестирования
  • Автоматизация тестирования: повышение ценности для бизнеса
  • Test Automation Snake Oil Джеймса Баха
  • Когда следует автоматизировать тест? Брайан Марик
  • Рекомендации по фреймворку автоматизации тестирования
  • Расширенная автоматизация тестирования
  • Факторы успеха для тестирования , основанного на ключевых словах , Ханс Бувальда
  • Автоматизация, которая учится: заставляем ваш компьютер работать на вас Джереми Кэри-Дресслер
  • Ресурсы по автоматическому тестированию и передовой опыт Джо Колантонио