Непрерывное тестирование - Википедия - Continuous testing

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Для непрерывного тестирования объем тестирования простирается от проверки снизу вверх. требования или же пользовательские истории к оценке Системные Требования связаны со всеобъемлющими бизнес-целями.[4]

Драйверы усыновления

В 2010-х годах программное обеспечение стало ключевым отличием бизнеса.[5] В результате организации теперь ожидают, что команды разработчиков программного обеспечения будут предоставлять все больше и больше инновационного программного обеспечения в рамках более коротких циклов поставки.[6][7] Чтобы удовлетворить эти требования, команды обратились к худой подходы, такие как Гибкий, DevOps, и Непрерывная доставка, чтобы попытаться ускорить жизненный цикл разработки систем (SDLC).[8] После ускорения других аспектов конвейера доставки команды обычно обнаруживают, что их процесс тестирования не позволяет им достичь ожидаемых преимуществ от инициативы по ускорению SDLC.[9] Тестирование и общий процесс качества остаются проблематичными по нескольким ключевым причинам.[10]

  • Традиционные процессы тестирования слишком медленны. Продолжительность итерации изменилась с месяцев до недель или дней с ростом популярности Agile, DevOps и Continuous Delivery. Традиционные методы тестирования, которые в значительной степени полагаются на ручное тестирование и автоматизированные тесты графического интерфейса, требующие частого обновления, не успевают за ними.[9][11] На этом этапе организации склонны осознавать необходимость расширения своих усилий по автоматизации тестирования.[1][12]
  • Даже после того, как к существующему процессу тестирования добавлена ​​дополнительная автоматизация, менеджерам все еще не хватает адекватного понимания уровня риска, связанного с приложением в любой данный момент времени.[2] Понимание этих рисков имеет решающее значение для принятия быстрых решений, связанных с процессами непрерывной доставки.[13] Если тесты разрабатываются без понимания того, что бизнес считает приемлемым уровнем риска, можно получить релиз-кандидат, который проходит все доступные тесты, но который руководители бизнеса не сочтут готовым к выпуску.[14] Чтобы результаты тестирования точно указывали, соответствует ли каждый выпуск-кандидат ожиданиям бизнеса, подход к разработке тестов должен основываться на терпимости бизнеса к рискам, связанным с безопасностью, производительностью, надежностью и соответствием требованиям.[5] Помимо модульных тестов, которые проверяют код на очень детальном восходящем уровне, существует потребность в более широком наборе тестов, чтобы обеспечить нисходящую оценку бизнес-рисков кандидата на выпуск.[4]
  • Даже если тестирование автоматизировано и тесты эффективно измеряют уровень бизнес-риска, команды без скоординированного непрерывного процесса обеспечения качества, как правило, испытывают проблемы с удовлетворением бизнес-ожиданий в рамках сегодняшних циклов сжатой доставки.[4] Было показано, что попытка устранить риски в конце каждой итерации значительно медленнее и требует больше ресурсов, чем повышение качества продукта с помощью таких стратегий предотвращения дефектов, как тестирование разработки.[15][16]

Организации применяют непрерывное тестирование, потому что они осознают, что эти проблемы не позволяют им предоставлять качественное программное обеспечение с желаемой скоростью. Они осознают растущую важность программного обеспечения, а также растущую стоимость программного сбоя, и они больше не хотят идти на компромисс между временем, объемом и качеством.[2][17][18]

Цели и преимущества

Цель непрерывного тестирования - обеспечить быструю и непрерывную обратную связь об уровне бизнес-риска в последней сборке или выпуске-кандидате.[2] Затем эту информацию можно использовать, чтобы определить, готово ли программное обеспечение к работе по конвейеру доставки в любой момент времени.[1][5][13][19]

Поскольку тестирование начинается рано и выполняется постоянно, риски приложений обнаруживаются вскоре после их появления.[6] После этого группы разработчиков могут предотвратить переход этих проблем на следующий этап SDLC. Это сокращает время и усилия, которые необходимо затратить на поиск и устранение дефектов. В результате можно увеличить скорость и частоту предоставления качественного программного обеспечения (программное обеспечение, которое соответствует ожиданиям приемлемого уровня риска), а также уменьшить технический долг.[4][10][20]

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

Кроме того, когда команды непрерывно выполняют широкий набор непрерывных тестов в рамках SDLC, они накапливают метрики, касающиеся качества процесса, а также состояния программного обеспечения. Полученные метрики можно использовать для повторного изучения и оптимизации самого процесса, включая эффективность этих тестов. Эта информация может использоваться для создания обратной связи, которая помогает командам постепенно улучшать процесс.[4][10] Частые измерения, тесная обратная связь и постоянное улучшение - ключевые принципы DevOps.[21]

Объем тестирования

Непрерывное тестирование включает в себя проверку обоих функциональные требования и нефункциональные требования.

Для тестирования функциональных требований (функциональное тестирование ), Непрерывное тестирование часто включает модульные тесты, API тестирование, интеграционное тестирование, и системное тестирование. Для тестирования нефункциональных требований (нефункциональное тестирование - чтобы определить, соответствует ли приложение ожиданиям в отношении производительности, безопасности, соответствия и т. д.), оно включает такие практики, как статический анализ кода, тестирование безопасности, тестирование производительности, так далее.[9][20] Тесты должны быть разработаны так, чтобы обеспечивать как можно более раннее обнаружение (или предотвращение) рисков, которые наиболее важны для бизнеса или организации, выпускающей программное обеспечение.[6]

Команды часто обнаруживают, что для обеспечения непрерывной работы набора тестов и эффективной оценки уровня риска необходимо сместить акцент с тестирования графического интерфейса пользователя на тестирование API, поскольку 1) API-интерфейсы («уровень транзакций») считаются наиболее стабильным интерфейсом. к тестируемой системе, и 2) тесты графического интерфейса требуют значительной переделки, чтобы успевать за частыми изменениями, типичными для процессов ускоренного выпуска; тесты на уровне API менее хрупкие и их легче поддерживать.[11][22][23]

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

В идеале все тесты выполняются во всех непроизводственных тестовые среды. Чтобы гарантировать точность и согласованность, тестирование следует проводить в максимально полной производственной среде. Стратегии повышения стабильности тестовой среды включают программное обеспечение виртуализации (для зависимостей, которые ваша организация может контролировать и создавать имидж), виртуализацию служб (для зависимостей, выходящих за рамки вашего контроля или неподходящих для создания образов) и управление тестовыми данными.[1][4][10][25]

Общие практики

  • Тестирование должно осуществляться совместно разработчиками, QA и Операции - согласованы с приоритетами отрасль производства - в рамках скоординированного непрерывного процесса обеспечения качества.[1][4][10][17][26]
  • Тесты должны быть логически разбиты на компоненты, инкрементными и повторяемыми; результаты должны быть детерминированными и значимыми.[1][4]
  • Все тесты необходимо запускать в какой-то момент конвейера сборки, но не все тесты нужно запускать все время.[1][9]
  • Устраните ограничения тестовых данных и среды, чтобы тесты могли выполняться постоянно и согласованно в рабочих средах.[1][4][9]
  • Чтобы свести к минимуму ложные срабатывания, минимизировать обслуживание тестов и более эффективно проверять варианты использования в современных системах с многоуровневой архитектурой, команды должны уделять особое внимание: API тестирование над GUI тестирование.[4][11][12]

Проблемы / препятствия

Поскольку современные приложения сильно распределены, тестовые наборы, которые их проверяют, обычно требуют доступа к зависимостям, которые не всегда доступны для тестирования (например, сторонние сервисы, мэйнфреймы, которые доступны для тестирования только в ограниченном объеме или в неудобное время и т. Д. Более того, с растущим внедрением гибких и параллельных процессов разработки для сквозных функциональных тестов обычным явлением является требование доступа к зависимостям, которые все еще развиваются или еще не реализованы. Эту проблему можно решить, используя виртуализация услуг для имитации взаимодействия тестируемого приложения (AUT) с отсутствующими или недоступными зависимостями. Его также можно использовать для обеспечения согласованности данных, производительности и поведения при различных прогонах тестов.[1][7][10]

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

Непрерывное тестирование vs автоматическое тестирование

Цель непрерывного тестирования - применить «экстремальную автоматизацию» к стабильной, производственной тестовой среде. Автоматизация важна для непрерывного тестирования.[27] Но автоматическое тестирование - это не то же самое, что непрерывное тестирование.[4]

Автоматическое тестирование включает в себя автоматизированное выполнение на основе CI любого набора тестов, накопленных командой.[требуется разъяснение ] Переход от автоматизированного тестирования к непрерывному включает в себя выполнение набора тестов, специально разработанных для оценки бизнес-рисков, связанных с кандидатом на выпуск, и регулярного выполнения этих тестов в контексте стабильной, производственной тестовой среды. Некоторые различия между автоматическим и непрерывным тестированием:

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

Предшественники

С 1990-х гг. Непрерывная разработка через тестирование был использован для предоставления программистам быстрой обратной связи о том, а) правильно ли работает добавленный ими код и б) непреднамеренно изменен или нарушен существующий функционал. Это тестирование, которое было ключевым компонентом Экстремальное программирование, включает в себя автоматическое выполнение модульных тестов (а иногда и приемочных тестов или дымовых тестов) в рамках автоматизированной сборки, часто много раз в день. Эти тесты написаны до реализации; прохождение тестов свидетельствует об успешной реализации.[13][28]

Инструменты непрерывного тестирования

Исследовательские фирмы Forrester Research и Gartner сделали непрерывное тестирование главным приоритетом в своих ежегодных оценках средств автоматизации тестирования. Gartner опубликовала обновленную версию исследования в 2019 году.

Gartner провела оценку 10 инструментов, соответствующих их критериям для средств автоматизации тестирования корпоративного уровня. Оценка включала запросы клиентов Gartner, опросы пользователей инструментов, ответы поставщиков на вопросы Gartner, демонстрации продуктов поставщиков. Gartner требовались инструменты для поддержки собственного тестирования настольных приложений Windows и тестирования Android или iOS, а также поддержки трех из следующего: адаптивные веб-приложения, мобильные приложения, пакетные приложения, API / веб-сервисы. Результаты исследования Magic Quadrant за 2019 год:[29]

В 2020 году Forrester Research провела оценку 15 инструментов, соответствующих их критериям функциональной автоматизации тестирования корпоративного уровня.[30] Компания Forrester определила 26 критериев на основе прошлых исследований, потребностей пользователей и интервью с экспертами, а затем оценила продукты по этим критериям на основе ответов поставщиков на вопросы Forrester, демонстраций продуктов поставщиков и интервью с клиентами. Forrester требовались инструменты для кроссбраузерного, мобильного тестирования, тестирования пользовательского интерфейса и API. Результаты Forrester wave 2020 года:[30]

  • Лидеры: ACCELQ, Eggplant, Parasoft, Tricentis
  • Сильные исполнители: Broadcom, IBM, Mabl, Micro Focus, Волей случая, Соус Лаборатории, Программное обеспечение SmartBear
  • Претенденты: Cyara, Expiretest, Worksoft
  • Претенденты: Ранорекс

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

дальнейшее чтение

  • Ариола, Уэйн; Данлоп, Синтия (2014). Непрерывное тестирование. CreateSpace. ISBN  978-1494859756.
  • Грувер, Гэри; Мышелов, Томми (2015). Лидерство в трансформации: масштабное применение принципов Agile и DevOps. IT Revolution Press. ISBN  978-1942788010.
  • Уиттакер, Джеймс; Арбон, Джейсон; Каролло, Джефф (2012). Как Google тестирует программное обеспечение. Эддисон-Уэсли Профессионал. ISBN  978-0321803023.
  • Скромный, Джез; Фарли, Дэвид (2010). Непрерывная доставка: надежные выпуски программного обеспечения за счет автоматизации сборки, тестирования и развертывания. Эддисон-Уэсли Профессионал. ISBN  978-0-321-60191-9.

Рекомендации

  1. ^ а б c d е ж грамм час я Часть конвейера: почему так важно непрерывное тестирование, Адам Ауэрбах, TechWell Insights, август 2015 г.
  2. ^ а б c d е ж Взаимосвязь между риском и непрерывным тестированием: интервью с Уэйном Ариолой, Кэмерон Филипп-Эдмондс, Stickyminds, декабрь 2015 г.
  3. ^ Saff, D .; Эрнст, доктор медицины (20 ноября 2003 г.). Сокращение потерь времени на разработку за счет непрерывного тестирования. 14-й Международный симпозиум по проектированию надежности программного обеспечения, 2003 г. Денвер, Колорадо, США: IEEE. С. 281–292. ISBN  0-7695-2007-3. ISSRE 2003. Архивировано с оригинал 1 августа 2016 г. Дои:10.1109 / ISSRE.2003.1251050
  4. ^ а б c d е ж грамм час я j k DevOps: вы быстрее сообщаете клиентам ошибки, Уэйн Ариола и Синтия Данлоп, PNSQC, октябрь 2015 г.
  5. ^ а б c d DevOps и QA: какова реальная цена качества?, Эрика Чиковски, DevOps.com, июнь 2015 г.
  6. ^ а б c Важность сдвига в DevOps, Боб Айелло, CM Crossroads, декабрь 2014 г.
  7. ^ а б Изломы сохраняются в непрерывных рабочих процессах, Лиза Морган, SD Times, сентябрь 2014 г.
  8. ^ Непрерывное тестирование: думайте иначе, Ян Дэвис, Visual Studio Magazine, сентябрь 2011 г.
  9. ^ а б c d е ж Тестирование в мире непрерывной доставки, Роб Марвин, SD Times, июнь 2014 г.
  10. ^ а б c d е ж Сдвиг влево и поставь качество на первое место, Адам Ауэрбах, TechWell Insights, октябрь 2014 г.
  11. ^ а б c Оценка автоматизации функционального тестирования (FTA) Forrester Wave ™ вышла, и все дело в том, чтобы выйти за рамки тестирования графического интерфейса пользователя, Диего Ло Джудиче, Forrester Research 23 апреля 2015 г.
  12. ^ а б Непрерывная разработка приносит изменения для тестировщиков программного обеспечения, Эми Райхерт, SearchSoftwareQuality, сентябрь 2014 г.
  13. ^ а б c Комментарий Зейчика: забудьте о «непрерывной интеграции» - теперь модным словом стало «непрерывное тестирование»., Алан Зейчик, SD Times, февраль 2014 г.
  14. ^ Купить не то ПО? Исправление может стоить 700 000 долларов за разговор с Терезой Лановиц из voke, Дом Никастро, CMS Wire Октябрь 2014 г.
  15. ^ Джонс, Каперс; Бонсиньур, Оливье (2011). Экономика качества программного обеспечения. Эддисон-Уэсли Профессионал. ISBN  978-0132582209.
  16. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: передовой опыт управления программным обеспечением. Пресса компьютерного общества Wiley-IEEE. п. 73. ISBN  978-0-470-04212-0.
  17. ^ а б Тереза ​​Лановиц рассказывает об экстремальной автоматизации тестирования на STAREAST 2014, Бет Романик, TechWell Insights, май 2014 г.
  18. ^ Гостевой вид: что мешает вам работать в непрерывном режиме?, Ноэль Вурст, SD Times, ноябрь 2015 г.
  19. ^ Управляйте бизнес-рисками разработки приложений с помощью непрерывного тестирования, Уэйн Ариола, CM Crossroads, сентябрь 2014 г.
  20. ^ а б Сила непрерывного тестирования производительности, Дон Пратер, Stickyminds, август 2015 г.
  21. ^ Практики DevOps и непрерывной доставки, Бен Линдерс, InfoQ, июль 2015 г.
  22. ^ Создавайте лучшее программное обеспечение, используя стратегию многоуровневого тестирования, автор: Шон Кенефик, Gartner 7 января 2014 г.
  23. ^ Кон, Майк (2009). Успех с Agile: разработка программного обеспечения с использованием Scrum. Эддисон-Уэсли Профессионал. п.312. ISBN  978-0321579362.
  24. ^ а б Опыт непрерывного тестирования в компании Siemens Healthcare, Бен Линдерс, InfoQ, февраль 2015 г.
  25. ^ DevOps - не рынок, а философия, ориентированная на инструменты, которая поддерживает непрерывную цепочку создания стоимости, Лори Ф. Вурстер, Ронни Дж. Колвилл, Джим Дагган, Gartner Февраль 2015 г.
  26. ^ Поддерживайте работоспособность программного обеспечения во время гибкой разработки, Адриан Бриджуотер, ComputerWeekly, ноябрь 2013 г.
  27. ^ Экстремальная автоматизация, соответствует предварительному жизненному циклу, Александра Вебер Моралес, SD Times, январь 2014 г.
  28. ^ Непрерывная интеграция (исходная версия), Мартин Фаулер, DevOps.com, сентябрь 2000 г.
  29. ^ Магический квадрант автоматизации тестирования программного обеспечения, Gartner, 25 ноября 2019 г.
  30. ^ а б «Forrester Wave: пакеты автоматизации непрерывного функционального тестирования, второй квартал 2020 года». Форрестер. 2020-06-18. Получено 2020-10-16.