что такое регрессия в программировании

Регрессионное тестирование на Scrum-проектах: руководство по проведению

Согласно отчету The State of Agile Report («О развитии методологии Agile»), 95% опрошенных компаний разрабатывают программное обеспечение по Agile.

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

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

В этой статье мы ответим на эти вопросы, а также расскажем о том, как проводить регрессионное тестирование на Scrum-проектах и уверенно преодолевать возникающие сложности.

Регрессионное тестирование в Scrum-среде

Регрессионные проверки играют одну из ключевых ролей в тестировании полного цикла и помогают добиваться следующих целей:

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

ускорять доставку решения на рынок, уменьшая время прогона тестов за счет автоматизации;

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

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

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

Топ-5 распространенных проблем и способы их преоделения

При проведении регрессионного тестирования на Scrum-проектах важно сфокусироваться на двух аспектах.

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

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

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

Но даже при должном понимании влияния изменившихся функций на приложение в целом и объема автоматизации, Scrum-команды могут столкнуться с рядом сложностей. Давайте перечислим их и рассмотрим, как можно решить.

Возрастающий объем регрессии

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

Недостаточная коммуникация между участниками проекта

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

Поддержка тестовых сценариев

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

Частые доработки функциональности

Смоделируем ситуацию: на проекте возникли непредвиденные и объемные изменения в требованиях к функциональности продукта. Еще и в конце спринта. Что делать? Да, сроки имеют значение, но важно позаботиться о качестве и оценить, сколько времени займет перезапуск тестов с учетом входной информации, чтобы расширить спринт и перенести дату релиза.

Ложноположительные результаты тестов

Причина может заключаться в некорректной разработке автоматизированного тест-кейса. Исключить подобную вероятность поможет валидация инженером по функциональному тестированию, который проходит тест-кейс по шагам и проверяет соответствие ожидаемому результату. Кроме того, в спринтах стоит закладывать время на интуитивное (ad hoc) и исследовательское (exploratory) тестирование, чтобы максимально расширить тестовое покрытие.

Тестируем регрессию на Scrum-проекте: о чем важно помнить

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

Что еще нужно учитывать? Предлагаем рассмотреть 5 шагов, от которых напрямую зависит результативность регрессионного тестирования.

1. Подготовить план тестирования

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

2. Создать доску регрессии

Все задачи, над которыми работают QA-инженеры Scrum-команды, располагаются на доске в порядке сверху вниз по приоритетности в зависимости от возможных рисков, важности для клиента и ряда других факторов. Переставляя элементы на доске, команда всегда будет понимать актуальность задач и сможет планировать свое время так, чтобы укладываться в сроки.

3. Анализировать отчеты о дефектах

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

4. Добавить исследовательское тестирование

С его помощью инженеры по тестированию по-новому взглянут на проект, расширят тестовое покрытие и обнаружат дефекты, которые могли бы оказать сильное влияние на конечного пользователя разрабатываемого продукта.

5. Настроить модель коммуникации на проекте

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

Заключение

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

В ходе регрессионного тестирования на Scrum-проектах команды сталкиваются с рядом сложностей, которые можно решить благодаря:

обеспечению непрерывной коммуникации между участниками проекта;

поддержке документации в актуальном состоянии;

расширению спринта в случае внесения изменений в функциональность перед релизом;

валидации автоматизированных тест-кейсов.

Чтобы эффективно организовать процесс тестирования, важно:

создать план выполнения регрессии;

использовать доску регрессии;

тщательнее работать над ошибками;

не забывать о преимуществах исследовательского тестирования;

обеспечить открытое взаимодействие между участниками проекта на всех уровнях.

Подобный подход поможет гарантировать качество и стабильность ПО, несмотря на непрерывные доработки, и обеспечить слаженную работу Scrum-команд.

Источник

Регрессионное тестирование — это что, где и зачем оно используется?

Регрессионное тестирование — это дополнительный способ проверить программу, которая раньше уже прошла удачное тестирование. Регрессионное тестирование проводят в том случае, когда в уже протестированной программе были выполнены какие-либо изменения или исправления ошибок. Его цель — выявить и удостовериться, что внесенные в программ у изменения никак не коснулись тех частей программ, которые остались без изменений.

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

Когда проводят регрессионное тестирование

Преимущества и недостатки регрессионного тестирования

В качестве преимуществ можно отметить:

В качестве недостатков можно отметить:

Заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Базовые принципы машинного обучения на примере линейной регрессии

Здравствуйте, коллеги! Это блог открытой русскоговорящей дата саентологической ложи. Нас уже легион, точнее 2500+ человек в слаке. За полтора года мы нагенерили 800к+ сообщений (ради этого слак выделил нам корпоративный аккаунт). Наши люди есть везде и, может, даже в вашей организации. Если вы интересуетесь машинным обучением, но по каким-то причинам не знаете про Open Data Science, то возможно вы в курсе мероприятий, которые организовывает сообщество. Самым масштабным из них является DataFest, который проходил недавно в офисе Mail.Ru Group, за два дня его посетило 1700 человек. Мы растем, наши ложи открываются в городах России, а также в Нью-Йорке, Дубае и даже во Львове, да, мы не воюем, а иногда даже и употребляем горячительные напитки вместе. И да, мы некоммерческая организация, наша цель — просвещение. Мы делаем все ради искусства. (пс: на фотографии вы можете наблюдать заседание ложи в одном из тайных храмов в Москве).

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

Формализмы

Машинное обучение — это подраздел искусственного интеллекта, в котором изучаются алгоритмы, способные обучаться без прямого программирования того, что нужно изучать. Линейная регрессия является типичным представителем алгоритмов машинного обучения. Для начала ответим на вопрос «а что вообще значит обучаться?». Ответ на этот вопрос мы возьмем из книги 1997 года (стоит отметить, что оглавление этой книги не сильно отличается от современных книг по машинному обучению).

Говорят, что программа обучается на опыте относительно класса задач в смысле меры качества , если при решении задачи качество, измеряемое мерой , возрастает при демонстрации нового опыта .

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

У нас есть задача, данные и способ оценки программы/модели. Давайте определим, что такое модель, и что значит обучить модель. Предиктивная модель – это параметрическое семейство функций (семейство гипотез):

Получается, что алгоритм обучения — это отображение из набора данных в пространство гипотез. Обычно процесс обучения с учителем состоит из двух шагов:

Но, к сожалению, такой интеграл не посчитать, т.к. распределение неизвестно, иначе и задачи не было бы. Но мы можем посчитать эмпирическую оценку риска, как среднее значение функции стоимости:

Тогда, согласно принципу минимизации эмпирического риска, мы должны выбрать такую гипотезу , которая минимизирует :

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

Линейная регрессия

Эмпирический риск (функция стоимости) принимает форму среднеквадратичной ошибки:

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

приравняем к нулю и найдем решение в явном виде:

Поздравляю, дамы и господа, мы только что с вами вывели алгоритм машинного обучения. Реализуем же этот алгоритм. Начнем с датасета, состоящего всего из одного признака. Будем брать случайную точку на синусе и добавлять к ней шум — таким образом получим целевую переменную; признаком в этом случае будет координата :

А теперь реализуем алгоритм обучения, используя магию NumPy:

Как мы видим, линия не очень-то совпадает с настоящей кривой. Среднеквадратичная ошибка равна 0.26704 условных единиц. Очевидно, что если бы вместо линии мы использовали кривую третьего порядка, то результат был бы куда лучше. И, на самом деле, с помощью линейной регрессии мы можем обучать нелинейные модели.

Полиномиальная регрессия

Если заранее предрассчитать все степени признаков, то задача опять сводится к описанному выше алгоритму — методу наименьших квадратов. Попробуем отрисовать графики нескольких полиномов разных степеней.

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

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

Вернемся к полиному 13-ой степени, с ним явно что-то не так. По идее, мы ожидаем, что полином 13-ой степени будет описывать тренировочный набор данных еще лучше, но результат показывает, что это не так. Из курса линейной алгебры мы помним, что обратная матрица существует только для несингулярных матриц, т.е. тех, у которых нет линейной зависимости колонок или строк. В методе наименьших квадратов нам необходимо инвертировать следующую матрицу: . Для тестирования на линейную зависимость или мультиколлинеарность можно использовать число обусловленности матрицы. Один из способов оценки этого числа для матриц — это отношение модуля максимального собственного числа матрицы к модулю минимального собственного числа. Большое число обусловленности матрицы, или же наличие одного или нескольких собственных чисел близких к нулю свидетельствует о наличии мультиколлинеарности (или нечеткой мультиколлиниарности, когда ). Такие матрицы называются слабо обусловленными, а задача — некорректно поставленной. При инвертировании такой матрицы, решения имеют большую дисперсию. Это проявляется в том, что при небольшом изменении начальной матрицы, инвертированные будут сильно отличаться друг от друга. На практике это всплывет тогда, когда к 1000 семплов, вы добавите всего один, а решение МНК будет совсем другим. Посмотрим на собственные числа полученной матрицы, нас там ждет сюрприз:

Все так, numpy вернул два комплекснозначных собственных значения, что идет вразрез с теорией. Для симметричных и положительно определенных матриц (каковой и является матрица ) все собственные значения должны быть действительные. Возможно, это произошло из-за того, что при работе с большими числами матрица стала слегка несимметричной, но это не точно ¯\_(ツ)_/¯. Если вы вдруг найдете причину такого поведения нумпая, пожалуйста, напишите в комменте.

UPDATE (один из членов ложи по имени Андрей Оськин, с ником в слаке skoffer, без аккаунта на хабре, подсказывает):

Есть только одно замечание — не надо пользоваться формулой `(X^T X^<-1>) X^T` для вычисления коэффициентов линейной регрессии. Проблема с расходящимися значениями хорошо известна и на практике используют `QR` или `SVD`.

Ну, то есть вот такой кусок кода даст вполне приличный результат:

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

Регуляризация

Новая функция стоимости примет вид:

Вычислим производную по параметрам:

И найдем решение в явном виде:

Для такой матрицы число обусловленности будет равно: , где — это собственные числа матрицы. Таким образом, увеличивая параметр регуляризации мы уменьшаем число обусловленности, а обусловленность задачи улучшается.

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

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

регуляризация

Тогда задача примет вид:

Посчитаем производную по параметрам модели (надеюсь уважаемые господа не будут пинать меня, за то, что я вжух и взял производную по модулю):

К сожалению, такая задача не имеет решения в явном виде. Для поиска хорошего приближенного решения мы воспользуемся методом градиентного спуска, тогда формула обновления весов примет вид:

а в задаче появляется еще один гиперпараметр , отвечающий за скорость спуска, его в машинном обучении называют скоростью обучения (learning rate).
Запрограммировать такой алгоритм не составит труда, но нас ждет еще один сюрприз:

Получим такую вот эволюцию ошибки:

Даже при такой небольшой скорости обучения, ошибка все равно растет и очень даже стремительно. Причина в том, что каждый признак измеряется в разных масштабах, от небольших чисел у полиномиальных признаков 1-2 степени, до огромных при 12-13 степени. Для того чтобы итеративный процесс сошелся, необходимо либо выбрать экстремально мелкую скорость обучения, либо каким-то образом нормализовать признаки. Применим следующее преобразование к признакам и попробуем запустить процесс еще раз:

Такое преобразование называется стандартизацией, распределение каждого признака теперь имеет нулевое матожидание и единичную дисперсию.

Все стало сильно лучше.

Нарисуем теперь все графики:

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

Описанный способ построения регрессии называется LASSO регрессия. Очень хотелось бы думать, что дядька на коне бросает веревку и ворует коэффициенты, а на их месте остается нуль. Но нет, LASSO = least absolute shrinkage and selection operator.

Байесовская интерпретация линейной регрессии

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

В то время как в байесовом подходе интересуются апостериорным распределением:

Часто получается так, что интеграл, полученный в результате байесового вывода, крайне нетривиален (в случае линейной регрессии это, к счастью, не так), и тогда нужна точечная оценка. Тогда мы интересуемся максимумом апостериорного распределения (MAP = maximum a posteriori):

Давайте сравним ML и MAP гипотезы для линейной регрессии, это даст нам четкое понимание смысла регуляризаций. Будем считать, что все объекты из обучающей выборки были взяты из общей популяции независимо и равномерно распределенно. Это позволит нам записать совместную вероятность данных (правдоподобие) в виде:

А также будем считать, что целевая переменная подчиняется следующему закону:

Т.е. верное значение целевой переменной складывается из значения детерминированной линейной функции и некоторой непрогнозируемой случайной ошибки, с нулевым матожиданием и некоторой дисперсией. Тогда, мы можем записать правдоподобие данных как:

удобнее будет прологарифмировать это выражение:

И внезапно мы увидим, что оценка, полученная методом максимального правдоподобия, – это то же самое, что и оценка, полученная методом наименьших квадратов. Сгенерируем новый набор данных большего размера, найдем ML решение и визуализируем его.

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

Найдем MAP оценку параметров линейной регрессии, для этого придется задать какое-нибудь априорное распределение на параметры модели. Пусть для начала это будет опять нормальное распределение: .

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

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

Естественно мы можем наложить и другое априорное распределение на параметры модели, например распределение Лапласа, тогда получим то же самое, что и при регуляризации.

Тогда апостериорное распределение примет вид:

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

И на самом деле два описанных регуляризатора — это частные случаи наложения обобщенного нормального распределения в качестве априорного распределения на параметры линейной регрессии:

Или же мы можем смотреть на эти регуляризаторы с точки зрения ограничения нормы, как в предыдущей части:

Заключение

Здесь вы найдете jupyter notebook со всем вышеописанным и несколькими бонусами. Отдельное спасибо тем, кто осилил этот текст до конца.

Желающим копнуть эту тему глубже, рекомендую:

Источник