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

Использование специального программного обеспечения для контроля выполнения и анализа тестов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разновидность этого типа инструмента предназначена для тестирования веб-сайтов. Здесь «интерфейсом» является веб-страница. Однако такой фреймворк использует совершенно другие методы, поскольку он отображает HTML и прослушивает события DOM вместо событий операционной системы. Для этой цели обычно используются браузеры Headless или решения на основе 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 для интеграции с другими инструментами)
Common Driver (например, в экосистеме разработки Java это Ant или Maven и популярные IDE ). Это позволяет интегрировать тесты с рабочими процессами разработчиков .
Поддержка неконтролируемых тестовых запусков для интеграции с процессами сборки и пакетными запусками. Этого требуют серверы непрерывной интеграции .
Уведомления по электронной почте, такие как сообщения о недоставке
Поддержка распределенной среды выполнения (распределенный испытательный стенд )
Поддержка распределенных приложений (распределенная SUT )

Роли

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

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

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

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

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

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

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

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

Уровни подразделения, интеграции и сквозного уровня

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общая настройка тестирования на основе модели

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

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

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

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

Ссылки

^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики в управлении программным обеспечением . Wiley-IEEE Computer Society Press. стр. 74. ISBN 978-0-470-04212-0.
^ O'Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (15.10.2015). Улучшение процессов в системах, программном обеспечении и услугах: 22-я европейская конференция, EuroSPI 2015, Анкара, Турция, 30 сентября — 2 октября 2015 г. Труды. Springer. ISBN 978-3-319-24647-5.
^ Труды 5-й Международной конференции по тестированию и валидации программного обеспечения (ICST). Центр компетенции по программному обеспечению Хагенберг. "Проектирование тестов: извлеченные уроки и практические последствия . doi :10.1109/IEEESTD.2008.4578383. ISBN 978-0-7381-5746-7.
^ Тестирование API защищает приложения и репутацию, Эми Райхерт, SearchSoftwareQuality, март 2015 г.
^ Все о тестировании API: интервью с Джонатаном Купером, Кэмерон Филипп-Эдмондс, Stickyminds, 19 августа 2014 г.
^ « Создание лучшего программного обеспечения с использованием многоуровневой стратегии тестирования», Шон Кенефик, Gartner, 7 января 2014 г.
^ Тестирование Headless с помощью браузеров; 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 Software . 24 (3): 74–79 . doi :10.1109/ms.2007.80. S2CID 30671391.
^ Часть конвейера: почему непрерывное тестирование необходимо, Адам Ауэрбах, TechWell Insights, август 2015 г.
^ Связь между риском и непрерывным тестированием: интервью с Уэйном Ариолой, Кэмерон Филипп-Эдмондс, Stickyminds, декабрь 2015 г.
^ DevOps: быстрее ли вы передаете ошибки клиентам, Уэйн Ариола и Синтия Данлоп, PNSQC, октябрь 2015 г.
^ Брайан Марик. «Когда следует автоматизировать тест?». StickyMinds.com . Получено 20 августа 2009 г.
^ Гаруси, Вахид; Мянтюля, Мика В. (2016-08-01). «Когда и что автоматизировать в тестировании программного обеспечения? Многосторонний обзор литературы». Информационные и программные технологии . 76 : 92–117 . doi :10.1016/j.infsof.2016.04.015.
^ abc Майк Кон (2010). Успех с Agile . Райна Хробак. ISBN 978-0-321-57936-2.
^ "Полное тестирование стека Гаятри Мохан". www.thoughtworks.com . Получено 2022-09-13 .
^ Пирамида практического теста, Хэм Воке
^ ab "Просто скажите "нет" большему количеству сквозных тестов". Блог Google Testing . Получено 11.02.2023 .
^ "Selenium Meet-Up 4/20/2010 Элизабет Хендриксон на Robot Framework 1of2". YouTube . 28 апреля 2010 . Получено 2010-09-26 .
^ abc "Conquest: Interface for Test Automation Design" (PDF) . Архивировано из оригинала (PDF) 2012-04-26 . Получено 2011-12-11 .
^ "golang/go TableDrivenTests". GitHub .
^ "Руководство пользователя JUnit 5". junit.org .
^ ДЕСАИ, САНДИП; ШРИВАСТАВА, АБИШЕК (2016-01-30). ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: Практический подход (на арабском языке). PHI Learning Pvt. Ltd. ISBN 978-81-203-5226-1.

Общие ссылки

Эльфрида Дастин и др. (1999). Автоматизированное тестирование программного обеспечения . Эддисон Уэсли. ISBN 978-0-201-43287-9.
Эльфрида Дастин и др. (2009). Внедрение автоматизированного тестирования программного обеспечения . Эддисон Уэсли. ISBN 978-0-321-58051-1.
Марк Фьюстер и Дороти Грэм (1999). Автоматизация тестирования программного обеспечения . ACM Press/Addison-Wesley. ISBN 978-0-201-33140-0.
Роман Савенков: Как стать тестировщиком ПО. Roman Savenkov Consulting, 2008, ISBN 978-0-615-23372-7
Хун Чжу и др. (2008). AST '08: Труды 3-го международного семинара по автоматизации тестирования программного обеспечения. ACM Press. doi : 10.1145/1370042. ISBN 978-1-60558-030-2.
Mosley, Daniel J.; Posey, Bruce (2002). Just Enough Software Test Automation . Prentice Hall Professional. ISBN 978-0130084682.
Хейс, Линда Г., «Справочник по автоматизированному тестированию», Институт тестирования программного обеспечения, 2-е издание, март 2004 г.
Канер, Джем, «Архитектуры автоматизации тестирования», архив 26.01.2021 на Wayback Machine , август 2000 г.

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

[2] O'Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (15.10.2015). Улучшение процессов в системах, программном обеспечении и услугах: 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.

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

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

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

[7] Тестирование Headless с помощью браузеров; https://docs.travis-ci.com/user/gui-and-headless-browsers/

[Headless_Testing_with_Browsers-8] Тестирование без головы с помощью PhantomJS;http://phantomjs.org/headless-testing.html

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

[Learning_TDD-10] Водде, Бас; Коскела, Лассе (2007). «Изучение разработки на основе тестирования путем подсчета строк». IEEE Software . 24 (3): 74–79 . doi :10.1109/ms.2007.80. S2CID 30671391.

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

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

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

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

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

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

[17] "Полное тестирование стека Гаятри Мохан". www.thoughtworks.com . Получено 2022-09-13 .

[18] Пирамида практического теста, Хэм Воке

[:1-19] "Просто скажите "нет" большему количеству сквозных тестов". Блог Google Testing . Получено 11.02.2023 .

[20] "Selenium Meet-Up 4/20/2010 Элизабет Хендриксон на Robot Framework 1of2". YouTube . 28 апреля 2010 . Получено 2010-09-26 .

[Interface-21] "Conquest: Interface for Test Automation Design" (PDF) . Архивировано из оригинала (PDF) 2012-04-26 . Получено 2011-12-11 .

[22] "golang/go TableDrivenTests". GitHub .

[23] "Руководство пользователя JUnit 5". junit.org .

[24] ДЕСАИ, САНДИП; ШРИВАСТАВА, АБИШЕК (2016-01-30). ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: Практический подход (на арабском языке). PHI Learning Pvt. Ltd. ISBN 978-81-203-5226-1.