Читать «Эффект плато. Как преодолеть застой и двигаться дальше» онлайн - страница 29

Помните ли вы о «проблеме 2000 года»? Возможно, что лично вы были на какой-то безумной вечеринке, когда год на календаре изменился с 1999-го на 2000-й, однако некоторые ученые-компьютерщики провели эту ночь в подвалах своих домов с запасами продуктов питания. Они сильно беспокоились о том, что произойдет со старыми компьютерными системами (работающими в банках и компаниях, занимающихся организацией воздушного трафика), когда двузначное описание года (99) внезапно изменится на 00. К счастью, миллениум не привел к апокалипсису. Однако этого нельзя было сказать о развлекательной системе, которой пользовался Хью в самолете.

Почему число 127 настолько важно для некоторых программ? Подобно числу 10 для наших пальцев, оно считается пограничным значением. Обычная математика говорит нам, что результат сложения 1 и 127 (1 + 127) должен быть равен 128. Однако порой в компьютерной математике результат оказывается равным минус 128, то есть минимальному значению, которое могут удерживать бинарные переключатели. Иными словами, это все равно что выпрямленный палец, означающий 11, однако выглядящий как один.

Как только Хью увидел число 127 на экране самолетной развлекательной системы, он понял, что у него есть отличный шанс вызвать целочисленное переполнение системы. Затем, исключительно в интересах науки, он нажал кнопку «+» еще один раз. Внезапно на экране на какой-то момент показалось число 128, а затем экран погас.

Тут же выключился экран сидевшего рядом с ним пассажира.

Погасли экраны и у пассажиров перед ним и за ним.

Через секунду выключилась вся развлекательная система в самолете.

После нескольких минут ворчания некоторых пассажиров бесстрастный бортпроводник перегрузил систему, и все вернулось к нормальному состоянию. А Хью приземлился с новыми знаниями о «Тетрисе» (и числе 127).

Как мог производитель упустить из виду эту проблему?

Вполне возможно, что игра тестировалась тысячи раз, а потом и использовалась десятки тысяч раз, и проблема не проявилась. Однако она существовала, причем всегда. Мы, как люди, написавшие немало программ, вполне понимаем, почему традиционные методы тестирования программ не замечали эту проблему. Тестеры склонны идти по пути, прописанному в документе, называемом спецификацией. В этих документах обычно пишется что-то типа «При входном значении системы, равном A, мы ожидаем получить результат B». Затем проводятся тесты, предполагающие ввод A и проверку, появляется ли на выходе B. Зачастую такие тесты кодифицируются для того, чтобы их можно было проводить почти автоматически. К примеру, для ввода A инструкция выглядит как «Нажмите маленькую кнопку со значком принтера», а исход B был описан как «Из принтера должно выйти несколько листов бумаги с напечатанным на них документом». Существует также тестирование в свободной форме, часто называемое исследовательским, при котором тестеры думают и действуют как обычные пользователи. Привычные пути работы тестеров проводят к тому, что они упускают из виду редко встречающиеся, но потенциально разрушительные проблемы. В случае развлекательной системы на борту самолета типичный пользователь должен был ограничиться нажатием огромных кнопок «+» и «−» на экране, однако оказалось, что система содержит ужасную ошибку, способную остановить всю работу.