Регламент тестирования — различия между версиями

Материал из Rosalab Wiki
Перейти к: навигация, поиск
(Классификация обновлений по степени опасности)
(Расширенное тестирование)
(не показано 45 промежуточных версий 2 участников)
Строка 2: Строка 2:
  
 
=== Политика ===
 
=== Политика ===
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.
+
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях.  
  
 
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.
 
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.
Строка 14: Строка 14:
 
</blockquote>
 
</blockquote>
  
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.
+
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.
  
 
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.
 
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.
;1: Обновления сетевых компонентов: NetworkManager, драйверов wifi и сетевых карт, сетевых скриптов и системы сетевой инициализации. Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим
+
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей.
;2: Обновления системы обновлений. '''rpm, urpmi, wget, curl, aria''' без этих компонент, как и без сети, обновления получить затруднительно. Однако, можно вручную поставить пакет и проконсультироваться на форуме, потому класс опасности ниже, чем для сетевых пакетов
+
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений. Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление.  
;3: Обновления графических компонент и скриптов — X-ов, DE, графических библиотек, драйверов, '''perl, python''' — то, без чего не загрузится графика. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий
+
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий
 
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.
 
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.
 
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.
 
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.
Строка 26: Строка 26:
 
==== Задача ====
 
==== Задача ====
 
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.
 
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.
+
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.
 
+
  
 
==== Общие положения ====
 
==== Общие положения ====
Строка 36: Строка 35:
  
 
==== Срок тестирования ====
 
==== Срок тестирования ====
* Срок тестирования пакета — '''одна неделя''', для сложных пакетов, отправляемых на дополнительное тестирование, срок тестирования зависит от срока дополнительного тестирования.
+
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов'''.
+
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' (за возможным исключением выходных и праздничных дней).
 +
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.
  
 
=== Процедура тестирования ===
 
=== Процедура тестирования ===
Строка 43: Строка 43:
 
==== Требования к запросу на обновление ====
 
==== Требования к запросу на обновление ====
 
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.
 
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).
+
# Пакет должен быть собран в общедоступном репозитории на ABF (не <tt>_personal</tt>).
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).
+
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые платформой архитектуры
 
# Описание обновления должно содержать все изменения, которые нужно протестировать.
 
# Описание обновления должно содержать все изменения, которые нужно протестировать.
При несоответствии запроса на обновление этим требованиям запрос отклоняется.
+
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.
 +
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.
  
 
==== Тестирование установки пакетов ====
 
==== Тестирование установки пакетов ====
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt>
+
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>sudo dnf distrosync</tt>  
 
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.
 
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.
 
## Репозиторий подключается как репозиторий с обновлениями.
 
## Репозиторий подключается как репозиторий с обновлениями.
## Из графического режима запускается стандартная процедура обновления.
+
## Запускается стандартная процедура обновления.
 
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.
 
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.
 
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.
 
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.
 
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.
 
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.
  
При ошибке установки запрос на тестирование отклоняется.
+
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.
  
==== Тестирование на устойчивость системы ====
+
==== Тестирование на функционирование и устойчивость системы после обновления ====
* Применяется при пересборках библиотек или пакетов без внесения изменений, или для изменений связанных с безопасностью.
+
При тестировании системы проверяется:
* Входит как начальный этап в любое другое тестирование.
+
 
+
При тестировании системы на устойчивость проверяется
+
 
# Стабильность и внешний вид обновленной системы после перезагрузки.
 
# Стабильность и внешний вид обновленной системы после перезагрузки.
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста браузера http://peacekeeper.futuremark.com
+
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html
 
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.
 
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.
# Ошибки непрерывного роста файлов <tt>.xsession-errors</tt> и <tt>messages</tt>.
+
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.
# Работа URPMI — дальнейшее обновление пакетов.
+
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)
# Установка и удаление dkms-модулей.
+
# Работа менеджера обновлений — дальнейшее обновление пакетов.
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.
+
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)
 +
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере
 +
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима
 +
# Работа системы поиска по содержимому офисных файлов
 +
 
 +
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария.
 +
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.
  
 
==== Тестирование запуска и работы связанных с обновлением приложений ====
 
==== Тестирование запуска и работы связанных с обновлением приложений ====
 
Проверяются:
 
Проверяются:
 
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.
 
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).
+
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>sudo dnf erase </tt> (для установленных в системе программ) или <tt>sudo dnf repoquery --whatrequires</tt> (для всех программ из подключенных репозиториев).
 +
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/
 +
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>sudo dnf repoquery --whatrequires <названиепакета></tt>
 
# Регрессии в локализации графического интерфейса и страниц справки.
 
# Регрессии в локализации графического интерфейса и страниц справки.
# Для тестирования браузеров в дополнение к http://peacekeeper.futuremark.com применяются.
+
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.
## Тест htmp5 https://html5test.com/  (сравнить результат до и после обновления, не должно быть регресса)
+
## Тест html5 https://html5test.com/  (сравнить результат до и после обновления, не должно быть регресса)
 
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com
 
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com
 
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0  https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru
 
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0  https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru
Строка 84: Строка 90:
 
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/  
 
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/  
 
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]
 
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]
 
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt>
 
 
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html
 
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html
 
## Тестирование печати
 
## Тестирование печати
 
## Тестирование установки браузера по-умолчанию из настроек
 
## Тестирование установки браузера по-умолчанию из настроек
  
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.
+
В случае:
 +
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. 
 +
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.
 +
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за функциональность пакета и может заблокировать обновление при её регрессии
 +
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.
  
 
==== Тестирование изменений ====
 
==== Тестирование изменений ====
Строка 106: Строка 114:
 
==== Расширенное тестирование ====
 
==== Расширенное тестирование ====
 
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям.  
 
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям.  
# В течение недели все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing
+
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing
# В пятницу на форуме и в сообществе вконтакте объявляется "пятничное тестирование", к нему выпускается бюллетень с полным списком обновлений и методикой их тестирования.
+
# В пятницу, руководитель QA:
# В понедельник подводятся результаты тестирования и протестированные пакеты публикуются в репозитории
+
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''sudo dnf distrosync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию
 +
## Проверяет, дошли ли обновления до зеркал
 +
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами
 +
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость
 +
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.
 +
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)
  
 
=== Завершение тестирования ===
 
=== Завершение тестирования ===
  
 
==== Положительный результат тестирования ====
 
==== Положительный результат тестирования ====
# По окончании тестрования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:
+
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:
 
## Название пакета с исходниками (src.rpm).
 
## Название пакета с исходниками (src.rpm).
 
## Версию пакета.
 
## Версию пакета.
 
## Отчет о тестировании (advisory).
 
## Отчет о тестировании (advisory).
 
## Надпись «QA verified».
 
## Надпись «QA verified».
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится соответствующий «?»).
+
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).
# Если тестирование secure не нужно, пакет отправляется на публикацию (взводится соответствующий «?»).
+
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.
+
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или команды <tt>sudo dnf distrosync</tt>
  
 
==== Отрицательный результат тестирования ====
 
==== Отрицательный результат тестирования ====

Версия 14:46, 11 января 2022


Политика

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

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

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

Классификация обновлений по степени опасности

Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк

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

0
Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, systemd, glibc, dracut, grub, bash и прочие основные вещи, если удалить которые система не загрузится даже в консоли.
1
Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей.
2
Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений. Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление.
3
Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, perl, python — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий
4
Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — gimp, inkscape, audacity, vlc, kdenive, opera, chromium-browser, skype.
5
Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.
6
Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.

Задача

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

Общие положения

  • Запрос на обновление пишется в багзилле
  • Все сообщения пишутся на английском языке.
  • Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.
  • Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774

Срок тестирования

  • Срок тестирования пакета — одна неделя, за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.
  • Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет Highest Critical, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение 48 часов (за возможным исключением выходных и праздничных дней).
  • Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.

Процедура тестирования

Требования к запросу на обновление

  1. QA Team тестирует пакеты-кандидаты на добавление в репозитории main/updates, non-free/updates и restricted/updates.
  2. Пакет должен быть собран в общедоступном репозитории на ABF (не _personal).
  3. Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые платформой архитектуры
  4. Описание обновления должно содержать все изменения, которые нужно протестировать.

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

Тестирование установки пакетов

  1. Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском sudo dnf distrosync
  2. Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.
    1. Репозиторий подключается как репозиторий с обновлениями.
    2. Запускается стандартная процедура обновления.
  3. Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.
  4. Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.
  5. Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.

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

Тестирование на функционирование и устойчивость системы после обновления

При тестировании системы проверяется:

  1. Стабильность и внешний вид обновленной системы после перезагрузки.
  2. Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html
  3. Ошибки загрузки демонов, например, с помощью systemctl | grep failed.
  4. Ошибки непрерывного роста файла .xsession-errors.
  5. Журнал ошибок, командами journalctl -b |grep fail и journalctl -b |grep error (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)
  6. Работа менеджера обновлений — дальнейшее обновление пакетов.
  7. Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)
  8. Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере
  9. Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима
  10. Работа системы поиска по содержимому офисных файлов

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

Тестирование запуска и работы связанных с обновлением приложений

Проверяются:

  1. Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.
  2. Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью sudo dnf erase (для установленных в системе программ) или sudo dnf repoquery --whatrequires (для всех программ из подключенных репозиториев).
  3. Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/
  4. Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой sudo dnf repoquery --whatrequires <названиепакета>
  5. Регрессии в локализации графического интерфейса и страниц справки.
  6. Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.
    1. Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)
    2. Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com
    3. Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru
    4. xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и
    5. Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/
    6. Воспроизведение видео с youtube
    7. Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html
    8. Тестирование печати
    9. Тестирование установки браузера по-умолчанию из настроек

В случае:

  1. нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление.
  2. отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.
  3. если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за функциональность пакета и может заблокировать обновление при её регрессии
  4. нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.

Тестирование изменений

  • Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.

Включает себя

  1. Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.
  2. Воспроизведение измененных обновлений особенностей по их описанию.

Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.

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

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

  1. Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям.
  2. В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing
  3. В пятницу, руководитель QA:
    1. Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы sudo dnf distrosync с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию
    2. Проверяет, дошли ли обновления до зеркал
    3. Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами
    4. Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость
    5. На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.
  4. В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)

Завершение тестирования

Положительный результат тестирования

  1. По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:
    1. Название пакета с исходниками (src.rpm).
    2. Версию пакета.
    3. Отчет о тестировании (advisory).
    4. Надпись «QA verified».
  2. Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).
  3. Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).
  4. В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или команды sudo dnf distrosync

Отрицательный результат тестирования

  1. При отклонении пакета ставится индикатор отклонения QA «-»,
  2. В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».
  3. При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».