Намедни сменил педали на контактные. Будет как минимум - весело.
Если кому интересно, то брал самое дефолтное:
Wellgo WPD-801:
и Tempesta Rhyno:
Все вместе 4200 рублей.
По ощущениям от первых полутора часов езды:
- выше скорость - движения и уставания, хех.
- уже падал. И еще буду.
- принудительная правильная постановка ноги на педаль
- распрыжка всем велосипедом, уиии!
Поехали:
Слайд 100
Работа Weyker'а была совершенно проигнорирована академическим сообществом производителей ПО. Потребовалось 18 лет для того, чтоб Doug Hoffman прошел через те же самые проблемы и озвучил их на конференции практиков тестирования ПО. Их челюсти упали, когда они увидели эту диаграмму.
Когда мы проводим тест, мы определяем вход и наблюдаем за выходом. Мы можем определить столько входных данных, сколько хотим, включая конфигурацию системы, точно так же, как и данные, которые мы скармливаем программе.
Но мы всегда оставляем некоторые вещи неопределенными. Когда в последний раз вы описывали в кейсе программы, которые в это время уже есть в памяти компьютера? Или сколько было у компьютера свободной памяти и места на жестком диске? Или в какой час дня или день месяца. Обычно это не имеет значения. Но не всегда. В этом одна из ключевых причин существования сложновоспроизводимых багов. Баг зависит от чего-то, что мы не знали и что мы не меняли.
Вдобавок, мы наблюдаем не за всем выходом. Представьте программу, которая складывает числа 2 и 3. Она возвращает 5, как и должна. Она пройдет тест? Наверное. Но ей требуется 6 часов, чтоб вернуть результат. Это приемлемо? Как часто вы измеряете время, за которое программа возвращает результат? Многие автоматические тесты слепы в этом отношении.
Содержимое слайда:
Если кому интересно, то брал самое дефолтное:
Wellgo WPD-801:
По ощущениям от первых полутора часов езды:
- выше скорость - движения и уставания, хех.
- уже падал. И еще буду.
- принудительная правильная постановка ноги на педаль
- распрыжка всем велосипедом, уиии!
Поехали:
Слайд 100
Работа Weyker'а была совершенно проигнорирована академическим сообществом производителей ПО. Потребовалось 18 лет для того, чтоб Doug Hoffman прошел через те же самые проблемы и озвучил их на конференции практиков тестирования ПО. Их челюсти упали, когда они увидели эту диаграмму.
Когда мы проводим тест, мы определяем вход и наблюдаем за выходом. Мы можем определить столько входных данных, сколько хотим, включая конфигурацию системы, точно так же, как и данные, которые мы скармливаем программе.
Но мы всегда оставляем некоторые вещи неопределенными. Когда в последний раз вы описывали в кейсе программы, которые в это время уже есть в памяти компьютера? Или сколько было у компьютера свободной памяти и места на жестком диске? Или в какой час дня или день месяца. Обычно это не имеет значения. Но не всегда. В этом одна из ключевых причин существования сложновоспроизводимых багов. Баг зависит от чего-то, что мы не знали и что мы не меняли.
Вдобавок, мы наблюдаем не за всем выходом. Представьте программу, которая складывает числа 2 и 3. Она возвращает 5, как и должна. Она пройдет тест? Наверное. Но ей требуется 6 часов, чтоб вернуть результат. Это приемлемо? Как часто вы измеряете время, за которое программа возвращает результат? Многие автоматические тесты слепы в этом отношении.
Содержимое слайда:
Комментариев нет:
Отправить комментарий