Регрессионное тестирование
| Часть серии о |
| Разработка программного обеспечения |
|---|
Регрессионное тестирование (редко нерегрессионное тестирование) [1] ) повторно запускает функциональные и нефункциональные тесты, чтобы гарантировать, что ранее разработанное и протестированное программное обеспечение после внесения изменений продолжает работать ожидаемым образом. [2] В противном случае это будет называться регрессией .
Изменения, которые могут потребовать регрессионного тестирования, включают исправления ошибок , улучшения программного обеспечения, изменения конфигурации и даже замену электронных компонентов ( аппаратного обеспечения ). [3] Поскольку наборы регрессионных тестов имеют тенденцию расширяться с каждым обнаруженным дефектом, часто используется автоматизация тестирования. Очевидным исключением является регрессионное тестирование графических интерфейсов , которое обычно необходимо выполнять вручную. Иногда анализ влияния изменений выполняется для определения подходящего подмножества тестов ( нерегрессионный анализ). [4] ).
Предыстория [ править ]
Поскольку программное обеспечение обновляется, изменяется или повторно используется на модифицированной цели, появление новых ошибок и/или повторное появление старых ошибок является довольно распространенным явлением.
Иногда повторное появление происходит из-за того, что исправление теряется из-за плохих методов контроля версий (или из-за простой человеческой ошибки в управлении версиями). Часто исправление проблемы будет « хрупким », поскольку оно устраняет проблему в узком случае, когда она впервые наблюдалась, но не в более общих случаях, которые могут возникнуть в течение срока службы программного обеспечения. Часто исправление проблемы в одной области непреднамеренно приводит к программной ошибке в другой области.
Может случиться так, что при перепроектировании функции некоторые из тех же ошибок, которые были допущены в исходной реализации функции, также встречаются и при редизайне. В большинстве случаев разработки программного обеспечения считается хорошей практикой кодирования , когда ошибка обнаружена и исправлена, записать тест, выявляющий ошибку, и регулярно запускать этот тест после последующих изменений в программе. [5]
Хотя это можно сделать с помощью процедур ручного тестирования с использованием методов программирования, часто это делается с использованием инструментов автоматического тестирования . [6] Такой набор тестов выполнять все случаи регрессионного тестирования содержит программные инструменты, которые позволяют среде тестирования автоматически ; во многих проектах есть автоматизированные системы непрерывной интеграции , позволяющие повторно запускать все регрессионные тесты через определенные промежутки времени и сообщать о любых сбоях (которые могут означать регрессию или устаревший тест). [7]
Распространенной стратегией является запуск такой системы после каждой успешной компиляции (для небольших проектов), каждый вечер или раз в неделю. Эти стратегии можно автоматизировать с помощью внешнего инструмента.
Регрессионное тестирование является неотъемлемой частью метода разработки программного обеспечения экстремального программирования . В этом методе проектная документация заменяется обширным, повторяемым и автоматизированным тестированием всего пакета программного обеспечения на каждом этапе процесса разработки программного обеспечения . Регрессионное тестирование проводится после завершения функционального тестирования, чтобы убедиться, что другие функции работают.
В корпоративном мире регрессионное тестирование традиционно проводится группой обеспечения качества программного обеспечения после завершения работы командой разработчиков. Однако устранение дефектов, обнаруженных на этом этапе, обходится дороже всего. Эта проблема решается благодаря развитию модульного тестирования . Хотя разработчики всегда писали тестовые сценарии как часть цикла разработки, эти тестовые сценарии обычно представляли собой либо функциональные тесты , либо модульные тесты , которые проверяют только запланированные результаты. Тестирование разработчика вынуждает разработчика сосредоточиться на модульном тестировании и включать как положительные, так и отрицательные тестовые примеры. [8]
Техники [ править ]
Различные методы регрессионного тестирования:
Повторно протестировать все [ править ]
Этот метод проверяет все тестовые примеры текущей программы на предмет ее целостности. Хотя это дорого, поскольку необходимо повторно запускать все случаи, это гарантирует отсутствие ошибок из-за измененного кода. [9]
Выбор регрессионного теста [ править ]
В отличие от метода «Повторное тестирование всего» этот метод запускает часть набора тестов (из-за стоимости повторного тестирования всего), если стоимость выбора части набора тестов меньше, чем метод «Повторное тестирование всего». [9]
Приоритизация тестовых случаев [ править ]
Расставьте приоритеты тестовых примеров, чтобы повысить скорость обнаружения ошибок в наборе тестов. Методы определения приоритетов тестовых сценариев планируют тестовые сценарии таким образом, чтобы тестовые сценарии с более высоким приоритетом выполнялись раньше тестовых случаев с более низким приоритетом. [9]
Типы приоритезации тест-кейсов [ править ]
- Общая расстановка приоритетов. Расставьте приоритеты тестовых примеров, которые будут полезны в последующих версиях.
- Приоритизация для конкретной версии. Расставьте приоритеты тестовых примеров по отношению к конкретной версии программного обеспечения.
Гибрид [ править ]
Этот метод представляет собой гибрид выбора регрессионного теста и определения приоритетов тестовых примеров. [9]
Преимущества и недостатки [ править ]
Регрессионное тестирование проводится при внесении изменений в существующий функционал программного обеспечения или при исправлении ошибок в программном обеспечении. Регрессионное тестирование может быть достигнуто с помощью нескольких подходов; Если применяется подход «тестировать все» , это дает уверенность в том, что изменения, внесенные в программное обеспечение, не повлияли на существующие функциональные возможности, которые остаются неизменными. [10]
При гибкой разработке программного обеспечения , где жизненные циклы разработки программного обеспечения очень короткие, ресурсы ограничены, а изменения в программном обеспечении происходят очень часто, регрессионное тестирование может привести к большому количеству ненужных накладных расходов . [10]
В среде разработки программного обеспечения, которая имеет тенденцию использовать компоненты «черного ящика» сторонних производителей, проведение регрессионного тестирования может оказаться затруднительным, поскольку любое изменение в стороннем компоненте может помешать работе остальной части системы (и проведению регрессионного тестирования на стороннем компьютере). партийный компонент сложен, поскольку это неизвестная сущность). [10]
Использует [ править ]
Регрессионное тестирование можно использовать не только для проверки правильности программы, но часто также для отслеживания качества ее результатов. [11] Например, при разработке компилятора регрессионное тестирование может отслеживать размер кода и время, необходимое для компиляции и выполнения вариантов набора тестов.
Кроме того, вследствие появления новых ошибок обслуживание программ требует гораздо большего объема системного тестирования на каждый написанный оператор, чем любое другое программирование. Теоретически, после каждого исправления необходимо запустить всю серию тестовых случаев, ранее запущенных в отношении системы, чтобы убедиться, что она не была повреждена каким-либо непонятным образом. На практике такое регрессионное тестирование действительно должно приближаться к этой теоретической идее, и оно очень дорогостоящее.
- Фред Брукс , Мифический человеко-месяц , с. 122
Регрессионные тесты можно разделить на функциональные тесты или модульные тесты . Функциональные тесты проверяют всю программу с различными входными данными. Модульные тесты проверяют отдельные функции, подпрограммы или методы объекта. Как инструменты функционального тестирования, так и инструменты модульного тестирования, как правило, автоматизированы и часто представляют собой сторонние продукты, не входящие в комплект компилятора. Функциональный тест может представлять собой серию входных данных программы, возможно, даже с использованием автоматического механизма управления движениями и щелчками мыши. Модульный тест может представлять собой набор отдельных функций внутри самого кода или уровень драйвера, который связывается с кодом без изменения тестируемого кода.
См. также [ править ]
Ссылки [ править ]
- ^ Пецце, Мауро; Янг, Михал (2008). Тестирование и анализ программного обеспечения: процесс, принципы и методы . Уайли.
Действия по тестированию, направленные на решение проблем регрессии, называются (не)регрессионным тестированием. Обычно «не» опускается.
- ^ Басу, Анирбан (2015). Обеспечение качества программного обеспечения, тестирование и метрики . Обучение PHI. ISBN 978-81-203-5068-7 .
- ^ Комитет Национального исследовательского совета по старению авионики в военных самолетах: Старение авионики в военных самолетах . The National Academies Press, 2001, стр. 2: «Каждый цикл обновления технологий требует регрессионного тестирования».
- ^ Буланже, Жан-Луи (2015). Стандарты CENELEC 50128 и IEC 62279 . Уайли. ISBN 978-1119122487 .
- ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 73. ИСБН 978-0-470-04212-0 .
- ^ Автоматизируйте регрессионные тесты, когда это возможно , Автоматическое тестирование: избранные лучшие практики, Эльфрида Дастин, Safari Books Online
- ^ даВейга, Нада (6 февраля 2008 г.). «Изменяйте код без страха: используйте систему безопасности регрессии» . Журнал доктора Добба .
- ^ Дадни, Билл (08 декабря 2004 г.). «Тестирование для разработчиков уже на подходе: интервью с Альберто Савойей и Кентом Беком» . Проверено 29 ноября 2007 г.
- ^ Перейти обратно: а б с д Дуггал, Гаурав; Сури, Бхарти (29 марта 2008 г.). Понимание методов регрессионного тестирования . Национальная конференция по вызовам и возможностям. Манди Гобиндгарх, Пенджаб, Индия. CiteSeerX 10.1.1.460.5875 .
- ^ Перейти обратно: а б с Ю, С.; Харман, М. (2010). «Минимизация, выбор и расстановка приоритетов регрессионного тестирования: опрос». Тестирование, проверка и надежность программного обеспечения . 22 (2): 67–120. дои : 10.1002/stvr.430 .
- ^ Колава, Адам . «Регрессионное тестирование, программист программисту» . Врокс .