| |
| |
| 3.22, pavlinux (ok), 23:23, 12/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > #!/bin/bash
Это не нечто подобное, это ничто не подобное. :)
А комплексное тестирование придумали ещё тогда,
когда перемножили матрицу и её же обратную матрицу (хрен знает, может и раньше).
| | |
|
|
| 1.2, esc (?), 11:31, 12/10/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
интересная штуковина, правильно мыслят. удачи разрабитчикам!
| | |
| 1.3, Odity (?), 12:13, 12/10/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
Фух, вот это дух захватывает. Молодцы. Не зря я на нем с 9.0 версии сижу. Реально правильно мыслят перцы. Конечно кому что нравится:кто то и в байтах и cmd хочет разбираться,кто то и одной мышью любит поработать.ОДно только не понимаю...что же делать с новым Гномом??? 2.32 так и оставаться сидеть?
| | |
| 1.4, Ptomaine (?), 12:19, 12/10/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Сначала build-studio, теперь openQA. Радуют ребята. Большое человеческое спасибо!
| | |
| |
| 2.14, Nxx (ok), 17:17, 12/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Build Service и Studio - это разные продукты. Build Service - opensource, а у Studio исходники закрыты.
| | |
| |
| 3.16, Аноним (-), 17:29, 12/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
Берите KIWI и создавайте свою студию. Это только оболочка над KIWI
| | |
|
|
| 1.5, Crank (??), 12:36, 12/10/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Вот это здравый подход к вопросу. Для того чтобы выпускать качественный продукт, не обязательно иметь самую большую базу разработчиков, тестировщиков и пользователей. Автоматизация рутины освобождает время для работы над настоящими инновациями.
| | |
| 1.6, Аноним (-), 12:51, 12/10/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе - бессмысленно потраченное время. С тем же успехом можно тестировать работу сети (скорость, стабильность) гоняя "еженощно" ping.
| | |
| |
| 2.15, Nxx (ok), 17:18, 12/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе - бессмысленно
> потраченное время. С тем же успехом можно тестировать работу сети (скорость,
> стабильность) гоняя "еженощно" ping.
Дистрибутив не только из ядра состоит.
| | |
| |
| 3.26, Аноним (-), 11:39, 13/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
"позволяющий в полностью автоматическом режиме проводить всестороннее тестирование работоспособности различных компонентов дистрибутивов, от таких стадий как работа загрузчика, инициализация и загрузка ядра"
| | |
|
| 2.17, Avator (ok), 19:13, 12/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Вы бы хоть новость прочли целиком. Предполагается что ОС запускается в виртуалке.
И получается своеобразный Unit-тест framework для дистрибутивов. Это же замечательно.
| | |
| |
| 3.24, Аноним (-), 10:47, 13/10/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Я прочёл целиком, и, видимо, в отличие от вас уже много лет увлекаюсь осдевом (OS DEV = OS development), понимая КАК загружается и работает ОС снизу доверху. А потому понимаю что именно было сделано.
Запуск в эмуляторе - это НЕ тест, и с этого начинается осдев. То что идеально работает под эмулятором может вообще не запуститься на реальном железе. Вдобавок если были внесены изменения, то первейший тест - проверка того что это работает. Для примера могу указать идеализированность возвращаемых BIOS'ом таблиц (часто реальный BIOS возвращает такую херню что волосы дыбом), некорректная работа таймеров, отсутствие задержек при обращении к аппаратуре, некорректная работа многопроцессорных (SMP) систем, и т.д. Тот же "inc [rbx]" на SMP-системе в эмуляторе работать будет, а на реальном железе будет периодически сбоить.
Unit-тестирование для осдева бесполезно. Сегодня у вас менеджер памяти основан на битовой карте, завтра на L1, послезавтра на красно-чёрных деревьях. Разработайте универсальный тест - не сможете. Сам факт того что менеджер выделил память это не тест. Через неделю добавили пару новых флагов для ускорения красно-чёрного дерева - и ваш старый тест уже опять негодится. Unit-тестирование работает только для функционального программирования, когда все параметры на входе и выходе и цель в проверки неизменности выхода при фиксированном входе. В осдеве это не так.
Хотите Unit-тестирование в осдеве - смотрите в сторону браузерных ОС на php и пр. скриптовых языках.
В текущем виде описываемый инструмент для меня бесполезен. И чем больше будет ОС, тем более бесполезным он будет становится.
| | |
|
| 2.21, Michael Shigorin (ok), 20:51, 12/10/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе -
А при чём тут реальное железо? Инсталятор может разваливаться и на виртуальном.
| | |
| |
| 3.25, Аноним (-), 10:54, 13/10/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Сравнение скриншотов эмулятора как проверка работоспособности на реальном железе -
> А при чём тут реальное железо? Инсталятор может разваливаться и на
> виртуальном.
"позволяющий в полностью автоматическом режиме проводить всестороннее тестирование работоспособности различных компонентов дистрибутивов, от таких стадий как работа загрузчика, инициализация и загрузка ядра"
А по-вашему для "всестороннего тестирования работоспособности загрузчика в полностью автоматическом режиме" достаточно сравнить скриншоты загрузки на эмуляторе? Странные у вас понятия... Очень странные...
| | |
|
|
| 1.10, Аноним (-), 14:40, 12/10/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Неважно как реализована текущая (первая и поэтому экспериментальная), важно что тенденция верная. Что не нравится в новости - так это долбаный пиар. Извините, но вот это чушь: "...в полностью автоматическом режиме проводить ВСЕСТОРОННЕЕ тестирование работоспособности различных компонентов дистрибутивов." ВСЕСТОРОНЕЕ тестирование ядра Linux невозможно сейчас, не то что различных компонентов дистрибутивов (ядро включено). Гнать метлой поганых маркетологов. Они, как всегда, глуповатые и их методы давно уныли.
| | |
| 1.11, xandry (?), 14:41, 12/10/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Объясните, пожалуйста, допустим у меня проблемы во взаимодействии ядра с каким-то железом и всё в логи падаёт, всё ясно. Как тестирование ОС из виртуальной машины об этом узнает?
| | |
| |
| 2.12, Аноним (-), 15:34, 12/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
Никак. Оно проверяет то, что это впринципе способно запуститься.
| | |
| 2.18, Avator (ok), 19:14, 12/10/2011 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Объясните, пожалуйста, допустим у меня проблемы во взаимодействии ядра с каким-то железом
> и всё в логи падаёт, всё ясно. Как тестирование ОС из
> виртуальной машины об этом узнает?
Никак, очевидно же что идея framework'а не в тестировании совместимости с железом.
| | |
|
|
