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

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

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

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

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

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

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

При тестировании происходит целеустремленный поиск слабых мест, а для этого нужно проштудировать всю систему. Это хорошая тренировка. В течение многих лет мы замечаем, что люди, начинавшие с тестирования, становятся проектировщиками и руководителями новейших систем. Мы всегда преднамеренно поручаем тестирование очень способным молодым программистам, поскольку знаем, что уклонение от тестирования при реальном использовании приведет систему к краху. Лучше потерпеть крах до реального использования!

Тестирующая организация должна быть независимой, насколько это только возможно, ее отчеты должны направляться по цепочке руководства как можно выше. Если руководитель тестирования подчинен руководителю разработки, сразу начнут сказываться человеческие слабости — руководитель группы тестирования может сильно волноваться, критикуя систему, ведь критикуемым окажется его начальник.

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

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

В работе по проверке программного обеспечения мы можем следовать следующим ориентирам.

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

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

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

При тестировании следует обращать внимание на граничные случаи, это необходимо, чтобы убедиться, что система работоспособна во всем диапазоне, для которого она проектировалась. При тестировании необходимо вводить в систему неправильные данные, исследуя затем полученные результаты.

Медленно развивающиеся процессы следует тестировать с помощью длительных прогонов (24 ч.).

Люди не очень-то любят составлять документацию на созданную ими продукцию. В то же время документация — это самое важное из того, что они должны сделать! Некий превосходный программист спроектировал и написал программу определения орбитальных характеристик спутника. Он первым закончил программирование, все работало правильно, память попусту не тратилась. Программа была написана на Фортране и занимала около 4 страниц плотного фортрановского текста. Он знал свою программу вдоль и поперек. Через 3 мес. его попросили добавить к своей программе несколько функций. Он достал документацию и принялся ее изучать. Три или четыре дня он пытался понять, что же происходит в его программе! А ведь он ее сам написал! Сколько бы сил он потратил, если бы это была чужая программа! А теперь представьте, что документации не было.

С такой проблемой часто приходится сталкиваться тем, кто занимается продолжающейся разработкой программ. Вместо того чтобы начинать с изучения требований к программе и ее проекта, им слишком часто достается участь детективов и археологов. «Какая была форма — структура — план — путь?» Почему «они» сделали «это»? После этого начинаются исправления, исключения, добавления. Понятно, что чем более четкий оставлен след, тем проще задача, тем лучше результаты.

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

Документация нам нужна для того, чтобы:

1) напомнить тем, кто создал эту программу, о том, как она устроена;

2) показать тем, кто придет после нас, как устроена программа, каков ее алгоритм.