Регламент тестирования

Ссылки сюда (2) →

Политика

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

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

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

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

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

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

0

Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, systemd, glibc, dracut, grub, bash и прочие основные вещи, если удалить которые система не загрузится даже в консоли.

1

Обновления сетевых компонентов: NetworkManager, драйверов wifi и сетевых карт, сетевых скриптов и системы сетевой инициализации. Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим.

2

Обновления системы обновлений. rpm, urpmi, wget, curl, aria без этих компонент, как и без сети, обновления получить затруднительно. Однако, можно вручную поставить пакет и проконсультироваться на форуме, потому класс опасности ниже, чем для сетевых пакетов

3

Обновления графических компонент и скриптов — X-ов, DE, графических библиотек, драйверов, 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

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

• Срок тестирования пакета — одна неделя, для сложных пакетов, отправляемых на дополнительное тестирование, срок тестирования зависит от срока дополнительного тестирования.
• Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет Highest Critical, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение 48 часов.

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

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

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

При несоответствии запроса на обновление этим требованиям запрос отклоняется.

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

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

При ошибке установки запрос на тестирование отклоняется.

Тестирование на устойчивость системы

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

При тестировании системы на устойчивость проверяется

1. Стабильность и внешний вид обновленной системы после перезагрузки.
2. Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста браузера http://peacekeeper.futuremark.com
3. Ошибки загрузки демонов, например, с помощью systemctl | grep failed.
4. Ошибки непрерывного роста файлов .xsession-errors и messages.
5. Работа URPMI — дальнейшее обновление пакетов.
6. Установка и удаление dkms-модулей.
7. Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.

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

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

1. Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.
2. Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью urpme (для установленных в системе программ) или urpmq --whatrequires (для всех программ из подключенных репозиториев).
3. Регрессии в локализации графического интерфейса и страниц справки.
4. Для тестирования браузеров в дополнение к http://peacekeeper.futuremark.com применяются.
   1. Тест htmp5 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. Работа флэша на примере игры Растения против зомби и [1]
   8. Работу java с помощью icedtea-web и демок пакета java-1.8-openjdk-demo
   9. Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html
   10. Тестирование печати
   11. Тестирование установки браузера по-умолчанию из настроек

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

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

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

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

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

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

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

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

1. Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям.
2. В течение недели все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing
3. В пятницу на форуме и в сообществе вконтакте объявляется "пятничное тестирование", к нему выпускается бюллетень с полным списком обновлений и методикой их тестирования.
4. В понедельник подводятся результаты тестирования и протестированные пакеты публикуются в репозитории

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

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

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

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

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