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

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

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

Драйверы усыновления [ править ]

В 2010-х годах программное обеспечение стало ключевым отличием бизнеса. [5] В результате организации теперь ожидают, что команды разработчиков программного обеспечения будут предоставлять больше и более инновационного программного обеспечения в рамках более коротких циклов поставки. [6] [7] Чтобы удовлетворить эти требования, команды обратились к бережливым подходам, таким как Agile , DevOps и Continuous Delivery , чтобы попытаться ускорить жизненный цикл разработки систем (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]

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

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

Проблемы / препятствия [ править ]

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

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

Непрерывное тестирование против автоматического тестирования [ править ]

Цель непрерывного тестирования - применить «экстремальную автоматизацию» к стабильной, производственной тестовой среде. Автоматизация важна для непрерывного тестирования. [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]

  • Лидеры: Eggplant , SmartBear Software , Tricentis
  • Претенденты: IBM , Micro Focus
  • Провидцы: Broadcom , Parasoft
  • Нишевые игроки: froglogic , Ranorex , Worksoft

In 2020, Forrester Research evaluated 15 tools that met their criteria for enterprise-grade test functional automation tools.[30] Forrester determined 26 criteria based on past research, user needs, and expert interviews, then evaluated products versus that criteria based on vendor responses to Forrester questions, vendor product demonstrations, and customer interviews. Forrester required tools to have cross-browser, mobile, UI, and API testing capabilities. The results of the 2020 Forrester wave are:[30]

  • Leaders: ACCELQ, Eggplant, Parasoft, Tricentis
  • Strong performers: Broadcom, IBM, Mabl, Micro Focus, Perforce, Sauce Labs, SmartBear Software
  • Contenders: Cyara, Expiretest, Worksoft
  • Challengers: Ranorex

See also[edit]

  • Continuous delivery
  • Continuous integration
  • DevOps
  • Release management
  • Service virtualization
  • Software testing
  • Test automation

Further reading[edit]

  • Ariola, Wayne; Dunlop, Cynthia (2014). Continuous Testing. CreateSpace. ISBN 978-1494859756.
  • Gruver, Gary; Mouser, Tommy (2015). Leading the Transformation: Applying Agile and DevOps Principles at Scale. IT Revolution Press. ISBN 978-1942788010.
  • Whittaker, James; Arbon, Jason; Carollo, Jeff (2012). How Google Tests Software. Addison-Wesley Professional. ISBN 978-0321803023.
  • Humble, Jez; Farley, David (2010). Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation. Addison-Wesley Professional. ISBN 978-0-321-60191-9.

References[edit]

  1. ^ a b c d e f g h i Part of the Pipeline: Why Continuous Testing Is Essential, by Adam Auerbach, TechWell Insights August 2015
  2. ^ a b c d e f The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola, by Cameron Philipp-Edmonds, Stickyminds December 2015
  3. ^ Saff, D.; Ernst, M.D. (20 Nov 2003). Reducing wasted development time via continuous testing. 14th International Symposium on Software Reliability Engineering, 2003. Denver, CO, USA: IEEE. pp. 281–292. ISBN 0-7695-2007-3. ISSRE 2003. Archived from the original on 1 August 2016. doi:10.1109/ISSRE.2003.1251050
  4. ^ a b c d e f g h i j k DevOps: Are You Pushing Bugs to Clients Faster, by Wayne Ariola and Cynthia Dunlop, PNSQC October 2015
  5. ^ a b c d DevOps and QA: What’s the real cost of quality?, by Ericka Chickowski, DevOps.com June 2015
  6. ^ a b c The Importance of Shifting Right in DevOps, by Bob Aiello, CM Crossroads December 2014
  7. ^ a b Kinks persist in Continuous Workflows, by Lisa Morgan, SD Times September 2014
  8. ^ Continuous Testing: Think Different, by Ian Davis, Visual Studio Magazine September 2011
  9. ^ a b c d e f Testing in a Continuous Delivery World, by Rob Marvin, SD Times June 2014
  10. ^ a b c d e f Shift Left and Put Quality First, by Adam Auerbach, TechWell Insights October 2014
  11. ^ a b c The Forrester Wave™ Evaluation Of Functional Test Automation (FTA) Is Out And It's All About Going Beyond GUI Testing, by Diego Lo Giudice, Forrester Research April 23, 2015
  12. ^ a b Continuous Development Brings Changes for Software Testers, by Amy Reichert, SearchSoftwareQuality September 2014
  13. ^ a b c Zeichick’s Take: Forget 'Continuous Integration'—the Buzzword is now 'Continuous Testing', by Alan Zeichick, SD Times February 2014
  14. ^ Buy the Wrong Software? A Fix Can Cost $700,000 A Conversation with voke’s Theresa Lanowitz, by Dom Nicastro , CMS Wire October 2014
  15. ^ Jones, Capers; Bonsignour, Olivier (2011). The Economics of Software Quality. Addison-Wesley Professional. ISBN 978-0132582209.
  16. ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 73. ISBN 978-0-470-04212-0.
  17. ^ a b Theresa Lanowitz Talks Extreme Test Automation at STAREAST 2014, by Beth Romanik, TechWell Insights May 2014
  18. ^ Guest View: What’s keeping you from Continuous?, by Noel Wurst, SD Times November 2015
  19. ^ Manage the Business Risks of Application Development with Continuous Testing, by Wayne Ariola, CM Crossroads September 2014
  20. ^ a b The Power of Continuous Performance Testing, by Don Prather, Stickyminds August 2015
  21. ^ Practices for DevOps and Continuous Delivery, by Ben Linders, InfoQ July 2015
  22. ^ Produce Better Software by Using a Layered Testing Strategy, by Sean Kenefick, Gartner January 7, 2014
  23. ^ Cohn, Mike (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional. p. 312. ISBN 978-0321579362.
  24. ^ a b Experiences from Continuous Testing at Siemens Healthcare, by Ben Linders, InfoQ February 2015
  25. ^ DevOps- Not a Market, but a Tool-Centric Philosophy That Supports a Continuous Delivery Value Chain, by Laurie F. Wurster, Ronni J. Colville, Jim Duggan, Gartner February, 2015
  26. ^ Keep your Software Healthy During Agile Development, by Adrian Bridgwater, ComputerWeekly November 2013
  27. ^ Extreme automation, meet the pre-production life cycle, by Alexandra Weber Morales, SD Times January 2014
  28. ^ Continuous Integration (original version), by Martin Fowler, DevOps.com September 2000
  29. ^ Magic Quadrant for Software Test Automation, Gartner, November 25, 2019
  30. ^ a b "The Forrester Wave: Continuous Functional Test Automation Suites, Q2 2020". Forrester. 2020-06-18. Retrieved 2020-10-16. CS1 maint: discouraged parameter (link)