Джозеф Фокс - Программное обеспечение и его разработка

Как и все, что связано с вычислительной техникой, алгоритм тестирования целиком и полностью зависит от того задания, которое нужно выполнить, будь оно тривиальным или до крайности сложным.

Для проверки программы в 100 строк, которая вычисляет мой годовой доход, мне нужно составить всего несколько — вряд ли больше полудюжины — вариантов теста.

Для проверки программы размером в 1 млн. строк, предназначенной для управления ракетой, мне потребуются сотня или около этого помощников, целый год времени, ракетный полигон и огромное количество всяческой аппаратуры.

Давайте рассмотрим относительно простой пример — систему формирования платежных ведомостей, и на нем попытаемся понять идею тестирования с возвратом. Если разбить эту систему на составные части, получится нечто вроде рис. 5.48.

Все эти программы достаточно независимы, но все поставляют данные друг для друга. Изменения в программе вычисления выплаты, возникающие, например, из-за нового профсоюзного договора, должны быть проверены в совокупности не только с программой контроля выписанных чеков, но также с программой вычисления даты, с программой налогообложения и т. д. (См. рис. 5.49.) То, что программа правильно работает совместно с программой контроля чеков, не означает, что она будет верно работать вместе с другими программами. Необходимо выполнить несколько тестирований.

И наконец, нужно выполнить общесистемный тест (рис. 5.50) со всеми подпрограммами.

Даже если изменения вносятся только в одну программу, повторному тестированию подлежит вся система. Этот процесс называется тестированием с возвратом. Проверять работу только измененной подпрограммы недостаточно. Недостаточно полное тестирование такого рода повышает вероятность неудач.

Не раз после всеобъемлющего тестирования и успешного прохождения всех тестов система на следующее утро уже не работала, потому что руководство проектом не обеспечило ее защиты. В одном крупном проекте, разработки которого проводило одно из отделений фирмы IBM в Австралии, руководители программистских коллективов решили, что они обязаны охранять работающие строки программ. Охрана программ должна проводиться и для больших военных проектов, и для внутрифирменных разработок операционных систем. От кого же? От жуликов? Нет, от чересчур усердных программистов!

Даже после проведения всех дорогостоящих тестов могут найтись рьяные программисты, которые захотят вставить в систему еще одну, последнюю функцию или исправить одну маленькую ошибку в своей подпрограмме и в три часа ночи, без всякого разрешения, прокравшись в машинный зал и схватив основной диск с оттестированной системой, внести туда изменения. И пустят маленький тест для проверки своих исправлений. Этот тест проходит — для их подпрограммы.

А в девять утра «оттестированная» система на ленте или диске будет передана на использование или демонстрацию — и вот в ней начинают обнаруживаться десятки разных отказов во многих других частях. Она не работает! Но еще прошлой ночью все было в порядке! Руководство очень быстро сообразило, что весь возглавляемый им весьма дорогостоящий процесс был нарушен — хотя и без злого умысла, но с ужасными результатами. Главные файлы должны храниться под замком с соблюдением всех мер безопасности.

Для тестирования обычно требуются очень крупные денежные средства. Проведение тестирования требует крупных и дорогих машин и программ. Это могут быть те же самые машины, что использовались и для разработки, но могут быть и другие. Все зависит от того, насколько велика система, является ли она аппаратно-интенсивной или программно-интенсивной. Если система достаточно велика, нам придется использовать для разработки и тестирования разные вычислительные комплексы (см. рис. 5.51).