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

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

Политика

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

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

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

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

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

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

0

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

1

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

2

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

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. Пакет должен быть собран в общедоступном репозитории (не _personal).
3. Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (i586 и x64).
4. Описание обновления должно содержать все изменения, которые нужно протестировать.

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

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

1. Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском urpm-reposync из пакета urpm-tools
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. Работа URPMI — дальнейшее обновление пакетов.
7. Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)
8. Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере
9. Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима
10. Работа системы поиска по содержимому офисных файлов

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

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

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

1. Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.
2. Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью urpme (для установленных в системе программ) или urpmq --whatrequires (для всех программ из подключенных репозиториев).
3. Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/
4. Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой urpmq --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. Работа флэша на примере игры Растения против зомби и [1]
   8. Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html
   9. Тестирование печати
   10. Тестирование установки браузера по-умолчанию из настроек

В случае:

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. Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы urpm-reposync с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию
   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. В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты urpm-reposync из urpm-repotools.

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

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