Разработчики проекта openSUSE представили (http://news.opensuse.org/2011/10/11/opensuse-announces-first.../) новый открытый тестовый фреймворк openQA (http://openqa.opensuse.org/), позволяющий в полностью автоматическом режиме проводить всестороннее тестирование работоспособности различных компонентов дистрибутивов, от таких стадий как работа загрузчика, инициализация и загрузка ядра, до проверки отдельных графических приложений, таких как Firefox и LibreOffice. Пакет не ограничен поддержкой openSUSE и может использоваться для тестирования Fedora, Ubuntu, Debian, FreeBSD и даже OpenIndiana. Код openQA полностью открыт и распространяется в рамках лицензии GPLv2.
В основе openQA лежат две независимые подсистемы: тестовый пакет OS-autoinst (http://www.os-autoinst.org/) и реализация управляющего web-интерфейса (http://openqa.opensuse.org/). OS-autoinst является изначально многоплатформенным приложением, позволяющим протестировать любую систему, которая может быть...URL: http://news.opensuse.org/2011/10/11/opensuse-announces-first.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=32017
блестяще! команда suse - как всегда - на высоте
Кому интересно, нечто подобное было реализовано Антоном Бояршиновым для автотестирования альтовского Lite 4.0.2 три с лишним года тому:http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-p...
Но это не была инфраструктура, хотя некоторое обобщение далее воспоследовало (tests.d/dvd/).
Молодцы немцы, если довели до логического завершения ;-)
> #!/bin/bashЭто не нечто подобное, это ничто не подобное. :)
А комплексное тестирование придумали ещё тогда,
когда перемножили матрицу и её же обратную матрицу (хрен знает, может и раньше).
интересная штуковина, правильно мыслят. удачи разрабитчикам!
Фух, вот это дух захватывает. Молодцы. Не зря я на нем с 9.0 версии сижу. Реально правильно мыслят перцы. Конечно кому что нравится:кто то и в байтах и cmd хочет разбираться,кто то и одной мышью любит поработать.ОДно только не понимаю...что же делать с новым Гномом??? 2.32 так и оставаться сидеть?
Сначала build-studio, теперь openQA. Радуют ребята. Большое человеческое спасибо!
Build Service и Studio - это разные продукты. Build Service - opensource, а у Studio исходники закрыты.
Берите KIWI и создавайте свою студию. Это только оболочка над KIWI
Вот это здравый подход к вопросу. Для того чтобы выпускать качественный продукт, не обязательно иметь самую большую базу разработчиков, тестировщиков и пользователей. Автоматизация рутины освобождает время для работы над настоящими инновациями.
> Автоматизация рутины освобождает время для работы над настоящими инновациями.Эти мысли тоже водится и поближе ;-)
http://ftp.linux.kiev.ua/pub/conference/2011/reports/vlasenk...
http://ftp.linux.kiev.ua/pub/conference/2011/video/s5-2-univ...
Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе - бессмысленно потраченное время. С тем же успехом можно тестировать работу сети (скорость, стабильность) гоняя "еженощно" ping.
> Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе - бессмысленно
> потраченное время. С тем же успехом можно тестировать работу сети (скорость,
> стабильность) гоняя "еженощно" ping.Дистрибутив не только из ядра состоит.
"позволяющий в полностью автоматическом режиме проводить всестороннее тестирование работоспособности различных компонентов дистрибутивов, от таких стадий как работа загрузчика, инициализация и загрузка ядра"
Вы бы хоть новость прочли целиком. Предполагается что ОС запускается в виртуалке.
И получается своеобразный Unit-тест framework для дистрибутивов. Это же замечательно.
Я прочёл целиком, и, видимо, в отличие от вас уже много лет увлекаюсь осдевом (OS DEV = OS development), понимая КАК загружается и работает ОС снизу доверху. А потому понимаю что именно было сделано.Запуск в эмуляторе - это НЕ тест, и с этого начинается осдев. То что идеально работает под эмулятором может вообще не запуститься на реальном железе. Вдобавок если были внесены изменения, то первейший тест - проверка того что это работает. Для примера могу указать идеализированность возвращаемых BIOS'ом таблиц (часто реальный BIOS возвращает такую херню что волосы дыбом), некорректная работа таймеров, отсутствие задержек при обращении к аппаратуре, некорректная работа многопроцессорных (SMP) систем, и т.д. Тот же "inc [rbx]" на SMP-системе в эмуляторе работать будет, а на реальном железе будет периодически сбоить.
Unit-тестирование для осдева бесполезно. Сегодня у вас менеджер памяти основан на битовой карте, завтра на L1, послезавтра на красно-чёрных деревьях. Разработайте универсальный тест - не сможете. Сам факт того что менеджер выделил память это не тест. Через неделю добавили пару новых флагов для ускорения красно-чёрного дерева - и ваш старый тест уже опять негодится. Unit-тестирование работает только для функционального программирования, когда все параметры на входе и выходе и цель в проверки неизменности выхода при фиксированном входе. В осдеве это не так.
Хотите Unit-тестирование в осдеве - смотрите в сторону браузерных ОС на php и пр. скриптовых языках.
В текущем виде описываемый инструмент для меня бесполезен. И чем больше будет ОС, тем более бесполезным он будет становится.
> Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе -А при чём тут реальное железо? Инсталятор может разваливаться и на виртуальном.
>> Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе -
> А при чём тут реальное железо? Инсталятор может разваливаться и на
> виртуальном."позволяющий в полностью автоматическом режиме проводить всестороннее тестирование работоспособности различных компонентов дистрибутивов, от таких стадий как работа загрузчика, инициализация и загрузка ядра"
А по-вашему для "всестороннего тестирования работоспособности загрузчика в полностью автоматическом режиме" достаточно сравнить скриншоты загрузки на эмуляторе? Странные у вас понятия... Очень странные...
Спасибо SUSE! Пользуюсь её продуктами. Доволен. Хорошо сделаны.
+1
После просмотра тучи дистрибутивов выбор пал на убунту и сусь.
Выбрал ОпенСусь.
Неважно как реализована текущая (первая и поэтому экспериментальная), важно что тенденция верная. Что не нравится в новости - так это долбаный пиар. Извините, но вот это чушь: "...в полностью автоматическом режиме проводить ВСЕСТОРОННЕЕ тестирование работоспособности различных компонентов дистрибутивов." ВСЕСТОРОНЕЕ тестирование ядра Linux невозможно сейчас, не то что различных компонентов дистрибутивов (ядро включено). Гнать метлой поганых маркетологов. Они, как всегда, глуповатые и их методы давно уныли.
Объясните, пожалуйста, допустим у меня проблемы во взаимодействии ядра с каким-то железом и всё в логи падаёт, всё ясно. Как тестирование ОС из виртуальной машины об этом узнает?
Никак. Оно проверяет то, что это впринципе способно запуститься.
> Объясните, пожалуйста, допустим у меня проблемы во взаимодействии ядра с каким-то железом
> и всё в логи падаёт, всё ясно. Как тестирование ОС из
> виртуальной машины об этом узнает?Никак, очевидно же что идея framework'а не в тестировании совместимости с железом.
Виртуальное железо не глючит.
Если не глючит реальное! :)