Тестирование помогает найти ошибку, но не избежать ее. Только хороший процесс разработки в сочетании с различными действиями по верификации и хорошо выполненный проект могут с самого начала воспрепятствовать возникновению ошибок. Система, состоящая из «заплаток», возникших при исправлении ошибок, редко оказывается понятнее системы, которая с самого начала не имела ошибок.
Если разрабатывается крупное программное обеспечение, мы сталкиваемся с проблемой многофункционального тестирования. Иначе говоря, если программы могут выполнять большое число функций да еще в большом числе разных последовательностей, мы должны попытаться оттестировать те из них, которые нам кажутся наиболее вероятными.
Важно, чтобы тестирование проводилось в широких масштабах, было интенсивным, ведь в большой, сложной программе может быть множество скрытых проблем и поворотов. Абстрактный характер программного обеспечения значительно затрудняет возможности увидеть эти проблемы до момента выполнения программы.
Тестирование систем типа V обходится очень дорого. Для тестирования системы диспетчеризации авиаперевозок в месте проведения тестирования в Атлантик-Сити, шт. Нью-Джерси, были собраны:
1) более 90 диспетчеров для работы с системой;
2) более 50 «пилотов», частично занятых местных сотрудников, имитирующих «полет» с помощью специальной аппаратуры, отсюда данные передавались на имитаторы радиолокаторов;
3) более 50 наблюдателей и советников;
4) более 50 работников вычислительного центра, обеспечивающих постоянную готовность программ и проч.
В распоряжении советников и диспетчеров имелись рукописи размером с большие телефонные справочники, в которых для каждого пульта (дисплея), каждой клавиатуры, печатающего и коммуникационного устройства секунда за секундой расписывалось все, что должно быть выполнено, показано на экране и т. д.
Тестирование длилось несколько недель со средней занятостью 250 человек в день. Но — и это «но» существенно — тестирование не закончено и до сих пор. Моделирующая система никоим образом не может дать той интенсивности, какую дает использование в реальной ситуации.
Число различных ветвей в этих больших программах и число возможных комбинаций состояний входных сигналов, данных, вычислений и взаимодействий настолько велико, что даже за 100 лет использования мы сможем начать выполнять лишь несколько процентов из всех возможных ветвей. Даже после нескольких лет реальной работы в программах могут сохраняться ошибки. Было известно, что в программах управления посадкой на Луну, написанных в Хьюстоне, есть почти 100 ошибок, но ни одна из них не была существенной.
Один высокопоставленный чиновник недавно даже приказал применить против некоторых системных программистов меры дисциплинарного взыскания, поскольку они твердили, что им никогда не удастся выловить все ошибки в большой системе программ. Конечно же, они не смогут этого сделать. Тот, кто продолжает вести разговоры о больших системах программ, свободных от ошибок, не понимает в программном обеспечении ничего.
После каждого теста системы диспетчерского контроля все расхождения, отмеченные в регистрационных книгах — «признак АА 222 не зажегся, хотя шум был слышен в 8:14:03 9 июля 1972 года», — проверялись, изучались, исследовались, создавались группы для определения причин. Относилось ли это к программированию? К аппаратуре? Методике? Может быть, это ошибка пользователя — может быть, диспетчер № 48 ввел неправильное число? Может быть, нарушена связь между машиной и системой отображения?
В течение нескольких месяцев в Атлантик-Сити была проведена целая серия проверок системы воздушного контроля. После завершения тестирования программы были поставлены в один из двадцати диспетчерских центров страны, и система работала там более восьми месяцев с полуночи до 8 ч. утра.
Только после этого, после исправления многих ошибок, после продолжительного тестирования, система стала использоваться во время тяжелых многочасовых дежурств в одном из центров.
Такой медленный изнурительный процесс необходим. Раньше мы уже говорили, что логическая сложность 600 тыс. строк программы была очень высока, а последствия ошибок были весьма тяжелыми.
Надежное программное обеспечение — неверный термин
Программное обеспечение не может ломаться! Оно может быть неправильным с самого начала, каким-то образом пройдя через тестирование, но сломаться, выйти из строя так, как это бывает с физическими устройствами, оно не может. Мир, для которого создавались программы, может измениться и потребовать чего-нибудь нового или другого (введен новый налог), но сломаться программа не может!
И все же люди говорят о «надежном программном обеспечении». Термин этот только наносит вред, он способствует неправильному пониманию природы программного обеспечения. Нам следует пользоваться выражениями «правильное обеспечение» или «высококачественное обеспечение». Это такое обеспечение, которое хорошо спроектировано, хорошо реализовано, хорошо оттестировано.
Устойчивым (робастным) может быть названо обеспечение, построенное так, что оно продолжает работать даже тогда, когда остальные части системы начинают действовать не так, как это планировалось. Когда вводится буква L там, где ожидалась цифра 1, программы не останавливаются, они начинают выяснять: «Вы ввели букву L, не хотели ли вы нажать клавишу 1? Эта процедура не рассчитана на ввод букв». Можно употреблять и термин «безошибочное обеспечение», но он имеет смысл только по отношению к небольшим программам.
Тестирование с возвратом
Как и все, что связано с вычислительной техникой, алгоритм тестирования целиком и полностью зависит от того задания, которое нужно выполнить, будь оно тривиальным или до крайности сложным.
Рис. 5.48. Система программного обеспечения для составления платежных ведомостей.
Для проверки программы в 100 строк, которая вычисляет мой годовой доход, мне нужно составить всего несколько — вряд ли больше полудюжины — вариантов теста.
Для проверки программы размером в 1 млн. строк, предназначенной для управления ракетой, мне потребуются сотня или около этого помощников, целый год времени, ракетный полигон и огромное количество всяческой аппаратуры.
Давайте рассмотрим относительно простой пример — систему формирования платежных ведомостей, и на нем попытаемся понять идею тестирования с возвратом. Если разбить эту систему на составные части, получится нечто вроде рис. 5.48.
Рис. 5.49 Тестирование сверху вниз.
Рис. 5.50. Тестирование системы программного обеспечения.
Все эти программы достаточно независимы, но все поставляют данные друг для друга. Изменения в программе вычисления выплаты, возникающие, например, из-за нового профсоюзного договора, должны быть проверены в совокупности не только с программой контроля выписанных чеков, но также с программой вычисления даты, с программой налогообложения и т. д. (См. рис. 5.49.) То, что программа правильно работает совместно с программой контроля чеков, не означает, что она будет верно работать вместе с другими программами. Необходимо выполнить несколько тестирований.
И наконец, нужно выполнить общесистемный тест (рис. 5.50) со всеми подпрограммами.
Даже если изменения вносятся только в одну программу, повторному тестированию подлежит вся система. Этот процесс называется тестированием с возвратом. Проверять работу только измененной подпрограммы недостаточно. Недостаточно полное тестирование такого рода повышает вероятность неудач.
