Что такое regression testing
Регрессионное тестирование: цели и задачи, условия применения, классификация тестов и методов отбора
Цели и задачи регрессионного тестирования
Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться. Результаты сравнения выборочных методов и метода повторного прогона всех тестов приведены в таблица 11.1.
Повторный прогон всех тестов | Выборочное регрессионное тестирование |
---|---|
Прост в реализации | Требует дополнительных расходов при внедрении |
Дорогостоящий и неэффективный | Способно уменьшать расходы за счет исключения лишних тестов |
Обнаруживает все ошибки, которые были бы найдены при исходном тестировании | Может приводить к пропуску ошибок |
Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
Регресс или регрессив в тестировании
О себе писать не буду (кто я и чем занимаюсь). Моя статья возможно ответит на эти вопросы.
Не могу терпеть эту боль и слышать как неправильно произносят некоторые определения в тестировании.
Да, я — тестировщик. Хотя мои близкие меня постоянно спрашивают — «Ты точно тестировщик? Не похожа!» Очень смешно.
В общем статья сегодня вот о чем. Как правильно говорить — регрессионное или регрессивное тестирование? Как вы сами думаете? Лично я и мои «нормальные» коллеги заняты большую часть времени на работе, проводя регрессионное тестирование. Хм… А может они проводят всё-таки регрессивное тестирование? Пойду-ка спрошу у своих ребят. И вот я в поисках правды провела небольшой опрос среди 20 человек. Опрос легкий с одним вопросом — «привет! ты проводишь регрессивное или регрессионное тестирование?». Большая часть из них сказали «регрессионное», два человека сказали, что это для них одно и тоже, один сказал — «регрессивное». Опроса мне не хватило, и я пошла к знакомой (кандидат филологических наук), спросила про перевод слова «regression». Знакомая сказала, что переводится как регрессия, и скинула скрин вырезки этого перевода из multitran.ru. Оказывается как прилагательное это слово переводится и как «регрессионный», и как «регрессивный».
Недолго думая посмотрела перевод слова «regressive» в этом же сервисе:
После просмотренной информации пришла к выводу, что тому, чем мы занимаемся на работе, больше подходит слово «регрессионное». Поясню. Регрессивный — в моем понимании как в переводе это всё-таки «убывающий» или «уменьшающий» или «действующий в обратном направлении». А регрессионный — «возвращение в исходное или прежнее состояние» или «возврат к более ранней точке развития» (если цитировать предложенные переводы).
Если подойти к этой проблеме с другой более простой стороны и открыть Glossary ISTQB, то при поиске слова «регрессивный» мы ничего не найдем, а при поиске «регрессионный» — найдем определение и несколько совпадений этого слова в других определениях.
Но всё же остаётся проблема — почему некоторые тестировщики говорят «регрессивный»? В этом вопросе мне помогла еще одна моя знакомая, которая недавно читала книгу Романа Савина «Тестирование Dot Com или Пособие по жесткому обращению с багами в интернет-стартапах». Книга очень популярная среди начинающих тестировщиков. Я её тоже в своё время читала. Оказывается в этой книге Савин употребляет слово «регрессивный», как я понимаю вместо «регрессионный». Почему он так делает я не выясняла, но вернулась к своему опросу и вспомнила трех коллег, ответивших «регрессивный». Они — начинающие тестировщики с опытом работы год, меньше года или чуть больше года. Савин по моему мнению поделил тестировщиков не регрессивных и регрессионных!
Регрессионное тестирование
Регрессионное тестирование – это тесты, которые направлены на поиск дефектов в тех участках приложения, которые уже протестированы. Мы в Qualitica делаем это не для того, чтобы окончательно убедиться в отсутствии багов, а для поиска и исправления регрессионных ошибок.
Регрессионные ошибки – это те же дефекты с одной лишь разницей: они появляются не при написании программы, а при добавлении в существующий релиз нового участка программы или при исправлении других багов.
Например, вы сделали приложение для онлайн-знакомств, которое подбирает вам пару, ориентируясь на ваши музыкальные вкусы, род деятельности и тип личности. Но затем, уже после тестирования, решили добавить туда возможность свайпать, как в Tinder. В результате какая-то функция прошлой версии продукта может слететь.
Дополнения, изменения и новые функции могут стать причиной появления новых дефектов в уже протестированном продукте. Поэтому тестировщики проводят регрессионное тестирование, чтобы убедиться: исправление дефектов / обновление релиза не создало новых дефектов в уже проверенном коде.
Регрессионное тестирование включает в себя несколько видов тестов:
Их проводят для проверки и исправления обнаруженного дефекта.
Этот тест содержит принципы smoke-тестирования и тестирования сборки: в рамках тестирования верификации версии мы проверяем работоспособность основного функционала программы в каждой новой сборке.
Нужны, чтобы повторно проверить продукт, который уже написан и был протестирован ранее. Регрессионные тесты проводят по уже существующим тест-кейсам, и неважно, нашли ли в ходе их прохождения дефекты или нет.
Их проводят, когда у вас на руках уже есть новый релиз, но нужно проверить, не “ожили” ли дефекты, которые исправляли еще в старом релизе.
Важно: регрессионное тестирование – это не то же самое, что и повторное. Повторное тестирование – это проверка исправлений, внесенных в конкретный модуль или элемент. В этом главное отличие, ведь регрессионное тестирование направлено на поиск дефектов в целом продукте, где влияние исправления на другой компонент системы является основным направлением.
Как проводят регрессионное тестирование
Чтобы вы понимали, как работает регрессионное тестирование и что из себя представляет, расскажу, как его обычно проводят.
Факты – регрессионное тестирование:
На последнем пункте я остановлюсь и расскажу, что это за направления и в чем специфика каждого.
Три ключевых направления в регрессионном тестировании
Регресс – это тестирование трех основных направлений: дефектов, старых проблем и побочных эффектов.
Это поиск проблем, которые официально были устранены, но есть основания считать, что они до сих пор существуют. В этом случае необходимо проверять все действия с определенным объектом в различных комбинациях. Главное здесь – узнать, действительно ли дефект был устранен, и протестировать механизм, с помощью которого он был выявлен.
Это тестирование ошибок, которые возникли вследствие недавнего изменения кода в одной части приложения. Когда такое происходит, другая часть приложения оказывается нерабочей – полностью или частично. Задача тестировщика – определить все проблемные места.
Для этого подключают автоматизированное тестирование ПО, во время которого тестирование основных функций и задач производится автоматически. Это может быть, например, тестирование запуска, инициализации и выполнения, а также анализа и выдачи результатов.
Автоматизированное тестирование проводит технический специалист, который отвечает за создание, отладку и поддержку в рабочем состоянии тест-скриптов, тестовых наборов и инструментария.
Преимущества и недостатки регрессионного тестирования
К преимуществам регрессионного тестирования можно отнести:
Иными словами, регрессионное тестирование гарантирует, что вы выпустите жизнеспособный, качественный и рабочий релиз, а ваш продукт не потеряет в качестве даже тогда, когда вы начнете добавлять в него новые фичи, функции и опции.
У регрессионного тестирования один недостаток – оно не бывает дешевым, потому что требует много ручного труда. Не все можно автоматизировать, поэтому регрессионное тестирование почти гарантирует вам дополнительные расходы.
Однако это почти всегда необходимые расходы: согласно отчёту World Quality Report 2018, в среднем 26% всего IT-бюджета компаний идет на тестирование. При этом 40–70% этих затрат приходится на регрессионное тестирование. Если перевести проценты в реальные деньги, можно понять, почему регрессионное тестирование стоит каждого рубля, заслуживает внимания и требует продуманной стратегии.
Чтобы эффективно обнаружить все проблемные места, устранить их и обеспечить высокое качество цифрового продукта, нужно выбрать правильный подход и собрать сильную команду тестировщиков.
И у меня для вас хорошие новости – в Qualitica уже сейчас работает команда из 50 профессиональных тестировщиков, которые готовы провести вам регрессионное тестирование по всем стандартам качества. Пишите на hello@qualitica.ru, расскажите о вашем продукте, подключайте нашу команду и выпускайте качественные релизы без дефектов.
Правила обработки персональных данных
1. Персональные данные Посетителя обрабатываются в соответствии с ФЗ «О персональных данных» № 152-ФЗ.
2. При отправке формы обратной связи Посетитель предоставляет следующую информацию: имя, контактный номер телефона, адрес электронной почты.
3. Предоставляя свои персональные данные Владельцу сайта, Посетитель соглашается на их обработку Владельцем сайта, в том числе в целях выполнения Владельцем сайта обязательств перед Посетителем.
4. Под обработкой персональных данных понимается любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (в том числе передачу третьим лицам, не исключая трансграничную передачу, если необходимость в ней возникла в ходе исполнения обязательств), обезличивание, блокирование, удаление, уничтожение персональных данных.
5. Владелец сайта вправе использовать технологию «cookies». «Cookies» не содержат конфиденциальную информацию. Посетитель настоящим дает согласие на сбор, анализ и использование cookies, в том числе третьими лицами для целей формирования статистики и оптимизации рекламных сообщений.
6.Владелец сайта получает информацию об ip-адресе Посетителя. Данная информация не используется для установления личности посетителя.
7.Владелец сайта вправе осуществлять записи телефонных разговоров с Покупателем. При этом Владелец сайта обязуется: предотвращать попытки несанкционированного доступа к информации, полученной в ходе телефонных переговоров, и/или передачу ее третьим лицам, не имеющим непосредственного отношения к взаимодействию между Владельцем сайта и Посетителем, в соответствии с п. 4 ст. 16 Федерального закона «Об информации, информационных технологиях и о защите информации».
Регрессионное тестирование: методики, не связанные с отбором тестов и методики порождения тестов
Интеграционное регрессионное тестирование
Регрессионное тестирование объектно-ориентированных программ
Уменьшение объема тестируемой программы
Еще один путь сокращения затрат на регрессионное тестирование состоит в том, чтобы вместо повторного тестирования (большой) измененной программы с использованием соответственно большого числа тестов доказать, что измененная программа адекватно тестируется с помощью выполнения некоторого (меньшего) числа тестов на остаточной программе. Остаточная программа создается путем использования графа зависимости системы вместо графа потока управления, что позволяет исключить ненужные зависимости между компонентами в пределах одного пути графа потока управления. Так, корректировка какого-либо оператора в идеале должна приводить к необходимости тестировать остаточную программу, состоящую из всех операторов исходной программы, способных повлиять на этот оператор или оказаться в сфере его влияния. Для получения остаточной программы необходимо знать место корректировки (в терминах операторов), а также информационные и управляющие связи в программе. Этот подход работает лучше всего для малых и средних изменений больших программ, где высокая стоимость регрессионного тестирования может заставить вообще отказаться от его проведения. Наличие дешевого метода остаточных программ, обеспечивающего такую же степень покрытия кода, делает регрессионное тестирование успешным даже в таких случаях.
Метод остаточных программ имеет ряд ограничений. В частности, он не работает при переносе программы на машину с другим процессором или объемом памяти. Более того, он может давать неверные результаты и на той же самой машине, если поведение программы зависит от адреса ее начальной загрузки, или если для остаточной программы требуется меньше памяти, чем для измененной, и, соответственно, на остаточной программе проходит тест, который для измененной программы вызвал бы ошибку нехватки памяти. Исследования метода на программах небольшого объема показали, что выполнение меньшего количества тестов на остаточной программе не оправдывает затрат на отбор тестов и уменьшение объема программы. Однако для программ с большими наборами тестов это не так.
Сведения о методике уменьшения объема тестируемой программы приведены в Табл. 13.2.
Регрессионное тестирование: цели и задачи, условия применения, классификация тестов и методов отбора
Виды регрессионного тестирования
Соответственно, определяют два типа регрессионного тестирования : прогрессивное и корректирующее.
Подход к отбору регрессионных тестов может быть активным или консервативным. Активный подход во главу угла ставит уменьшение объема регрессионного тестирования и пренебрегает риском пропустить дефекты. Активный подход применяется для тестирования систем с высокой исходной надежностью, а также в случаях, когда эффект изменений невелик. Консервативный подход требует отбора всех тестов, которые с ненулевой вероятностью могут обнаруживать дефекты. Этот подход позволяет обнаруживать большее количество ошибок, но приводит к созданию более обширных наборов регрессионных тестов.
Управляемое регрессионное тестирование
Предположим, что никакие операторы программы, кроме тех, чье поведение зависит от изменений, не могут неблагоприятно воздействовать на программу. Даже при таком условии существуют некоторые ситуации, требующие особого внимания, например проблема утечки памяти и ей подобные. Ситуации такого рода в разных системах программирования обрабатываются по-разному. Например, язык Java сам по себе включает систему управления памятью. Если же система не контролирует распределение памяти автоматически, мы должны считать, что все операторы работы с памятью также обладают поведением, зависящим от изменений.
Проблема языков типа C и C++, которые допускают произвольные арифметические операции над указателями, состоит в том, что указатели могут нарушать границы областей памяти, на которые они указывают. Это означает, что переменные могут обрабатываться способами, которые не поддаются анализу на уровне исходного кода. Чтобы учесть такие нарушения границ памяти, выдвигаются следующие гипотезы: