Для чего необходимо обновлять программы

Emma McGowan 2 фев 2021

Emma McGowan , 2 фев 2021

Регулярное обновление программ и системы требует времени, но оно того стоит.

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

Однажды вы уже случайно нажали эту кнопку. В результате вам на целый час пришлось отвлечься от работы, пока компьютер устанавливал новую версию операционной системы. Помня об этом случае, вы нажимаете кнопку «Напомнить позже».

Затем все повторяется. «Позже». Снова. И снова.

Вы продолжаете нажимать эту кнопку, пока уведомление загадочным образом не перестанет появляться. «Наконец-то!» — думаете вы. Но отсутствие этого уведомления вовсе не означает, что потребность в обновлении отпала. И этот апдейт может оказаться последним рубежом вашей защиты от кибератак.

Как и зачем обновлять приложения на смартфон. Андройд!

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

Антивирусная прав ДА! TM

• добавить в избранное

Зачем нужно устанавливать регулярные обновления программ

Прочитали: 7146 Комментариев: 12 Рейтинг: 27

27 апреля 2022

Многие разработчики ПО практически ежедневно выпускают обновления своих продуктов. При этом пользователи зачастую не понимают, зачем нужно так много обновлений — «с виду же всё и так нормально работает». Тем временем на это есть веские причины, порой мы и сами советуем не затягивать с обновлениями. В сегодняшнем выпуске «Антивирусной правды» рассказываем, почему обновления появляются так часто и зачем их устанавливать.

Слишком частые обновления нужны для безопасности устройства

Для чего и каким образом мы тестируем обновление

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

Зачем обновлять приложения

Чем обычно бывают недовольны пользователи?

• приложение после обновления не работает совсем. Например, оно попросту не знает, что делать с данными в старом формате;
• бонусы, скидки, сохраненки пользователя (игры, магазины, кафе) были утеряны;
• не работает новая фича, ради которой заявлено обновление;
• новая фича работает, зато отвалилась какая-то из старых;

Что мы выпускаем и что надо обновлять

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

Продукт состоит из нескольких частей, в этой статье рассмотрим сервер анализа и хранения инцидентов InfoWatch Traffic Monitor. Продукт работает на ОС семейства Linux, имеет свою базу данных. Офицер безопасности для работы использует веб-консоль. На данный момент поддерживается два разных дистрибутива Linux и две БД. Система может быть установлена несколькими способами: all-in-one, когда все компоненты на одной машине; и распределенная установка, когда компоненты системы существуют на разных физических машинах.

Помимо заявленного функционала системы, мы должны гарантировать обновление с мажорных версий N-1 и N-2 до N, а также обновление со всех минорных версий — патчей и хотфиксов каждой из версий. Это обусловлено тем, что у наших клиентов зачастую довольно сложная ИТ-инфраструктура, обновление может занять продолжительное время, поэтому важно ограничить количество обновлений, не проводить их слишком часто, избегая простоев в работе.

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

• пользовательские данные не утеряны
• старые фичи не сломаны
• новые фичи доступны для использования

Рассмотрим пример с нашей таблицей обновлений при выпуске мажорной версии 3. Для версии 1.0.0 было выпущено два патча и три хотфикса, а для версии 2.0.0 было два хотфикса.

1.0.0 2.0.0 3.0.0

1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

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

Каждый наш релиз содержит некоторое число серьезных (с точки зрения влияния на продукт) фич. Могут меняться способы настройки системы, дорабатываться системы анализа, дополняться новыми данными инциденты, изменяться версия окружений, например, версия ОС или БД и т.п.

Исторически сложилось.

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

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

• Тестирование обновлений каждый раз занимало разное время. Чаще время выделялось по остаточному принципу, так как тестировалось обновление, когда продукт уже стабилизирован и перед выпуском остаются последние штрихи.
• Иногда забывались какие-то окружения.
• По сути, мы обновляли продукт с пустой базой и настройками по умолчанию и, далее начинался регресс. Учитывая, что времени выделялось немного, была вероятность, что тестировщик после обновления может «закопаться» в какой-то один функционал и проверить только его.

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

В итоге из отчета о тестировании обновления нельзя было точно понять, какие проверки были проведены, на каких значениях и т.д.

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

Что-то пошло не так

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

В такой ситуации текущий процесс нас уже не удовлетворял. Что-то надо было менять.
Мы начали с формулировки проблем, которые по нашему мнению мешали нам тестировать обновление более качественно. По результатам обсуждений сформировался следующий список проблем:

• Недостаточно информации об изменениях в текущей версии;
• Недостаточное знание системы, недостаточно информации о системе;
• Тестирование обновления превращается в регресс, что, по сути, является избыточным тестированием, но качество не повышает;
• Производится тестирование функционала, а не объектов системы и операций над ними;
• Непонятная отчетность;
• Процесс непрозрачен. Как оцениваем задачу? Какие проверки делаем? Какие окружения покрываем? С каких версий обновляемся?

Решение

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

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

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

В новом подходе мы используем комбинацию проверок над объектами системы (неизменяемыми и изменяющимися в ходе обновления) + smoke-проверки функционала (как старого, так и нового или измененного старого).

Для обновления будет выбран самый сложный вариант установки системы — распределенная установка. Для всех ОС и БД. Более простые варианты опустить как частные случаи.

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

• БД;
• Web (frontend, backend);
• Linux-компоненты

Тестирование обновления превращается в регресс. Производится тестирование функционала, а не объектов системы и операций над ними. Будем тестировать обновление по тест-кейсам в виде smoke-тестов функционала + проверки данных.

Непонятная отчетность. Покрытие и результаты можно взять из тест-кейсов.

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

Новый процесс

В результате мы выстроили довольно эффективный процесс.

Тестирование мы разделили на несколько этапов, что дало еще больше незапланированных бонусов, о которых ниже:

1. Подготовка.
2. Проводим анализ изменений в системе, подготовленный совместно с аналитиками и разработчиками на предмет изменяющихся областей.
3. В соответствии с результатами анализа составляем список подготавливаемых для тестирования обновления объектов системы.
4. Для каждого объекта системы определяется необходимый набор состояний, статусов и параметров.
5. Создаем стенды с необходимой (обновляемой) версией продукта.
6. На стендах создаем объекты, определенные выше.
7. Делаем снапшот стенда (это позволяет повторно использовать уже подготовленные данные раз за разом).
8. Изменяем или создаем smoke-тесты для проверки функционала, проверяемого после обновления.

Итого по завершении этапа подготовки у нас готовы:

• статьи с описанием подготовленных сущностей;
• наполненные этими сущностями стенды со старой версией продукта в требуемых конфигурациях (БД, ОС, способ установки, версия);
• тесты, использующие в качестве тестовых данных сущности из статей.

• Производим обновление подготовленного стенда на новую выпускаемую версию продукта.

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

Плюсы и минусы подхода

Своего мы добились, а именно:

1. Процесс стал прозрачным. Мы знаем, что тестируем, как, сколько времени это займет, и какие артефакты будут на выходе. Мы получили объективные критерии, по которым можно было давать свой вердикт о рабочем или нерабочем обновлении продукта.
2. Отчеты стали наглядными. Наличие тест-кейсов и отчет о результатах их прохождения дали возможность быстро отчитываться перед проектным менеджером и техническим директором о качестве созданной сборки.
3. Большее и более понятное покрытие, чем при исследовательском подходе.
4. Теперь мы тестируем изменение в данных и функционале. Благодаря отзывчивости аналитиков и разработчиков мы с высокой степенью точности можем сказать, что менялось в системе и где есть риск поймать дефект.