Если пытаться извлечь из тестирования большой системы типа V хотя бы минимальную пользу, оно становится весьма дорогостоящим. С помощью тестирования нельзя плохую программу превратить в хорошую, ее можно только улучшить.
При тестировании следует обращать внимание на граничные случаи, это необходимо, чтобы убедиться, что система работоспособна во всем диапазоне, для которого она проектировалась. При тестировании необходимо вводить в систему неправильные данные, исследуя затем полученные результаты.
Медленно развивающиеся процессы следует тестировать с помощью длительных прогонов (24 ч.).
Люди не очень-то любят составлять документацию на созданную ими продукцию. В то же время документация — это самое важное из того, что они должны сделать! Некий превосходный программист спроектировал и написал программу определения орбитальных характеристик спутника. Он первым закончил программирование, все работало правильно, память попусту не тратилась. Программа была написана на Фортране и занимала около 4 страниц плотного фортрановского текста. Он знал свою программу вдоль и поперек. Через 3 мес. его попросили добавить к своей программе несколько функций. Он достал документацию и принялся ее изучать. Три или четыре дня он пытался понять, что же происходит в его программе! А ведь он ее сам написал! Сколько бы сил он потратил, если бы это была чужая программа! А теперь представьте, что документации не было.
С такой проблемой часто приходится сталкиваться тем, кто занимается продолжающейся разработкой программ. Вместо того чтобы начинать с изучения требований к программе и ее проекта, им слишком часто достается участь детективов и археологов. «Какая была форма — структура — план — путь?» Почему «они» сделали «это»? После этого начинаются исправления, исключения, добавления. Понятно, что чем более четкий оставлен след, тем проще задача, тем лучше результаты.
Наверное, наиболее распространенная в мире история о программировании — это рассказ о том, что программа работает, но ни один человек не знает, как это происходит, поскольку программист давно ушел, а документации нет. Эту историю часто рассказывают, потому что это весьма обычная ситуация.
Документация нам нужна для того, чтобы:
1) напомнить тем, кто создал эту программу, о том, как она устроена;
2) показать тем, кто придет после нас, как устроена программа, каков ее алгоритм.
Многие новые технологии программирования позволяют получать самодокументированные программы, значительно снижая усилия, необходимые для документирования.
Под документацией мы подразумеваем не тексты рабочей (машинной) программы. Недостаточно также и текстов исходной программы. Документация, подготавливаемая для фазы продолжающейся разработки, должна содержать:
1) хорошо прокомментированный текст программы;
2) схемы, иллюстрирующие проект, и словесное их описание;
3) структурированные словесные описания или схемы процессов, причем первое более предпочтительно;
4) описания данных.
Без всего этого программисту, которому предстоит модифицировать существующую программу, придется решать сложнейшую задачу по определению того, что было сделано до него.
Такие описания и читать и понимать легче, чем блок-схемы. Снабженный подробными приложениями, грамотно оформленный, разделенный на модули текст описания усваивается особенно легко, ведь и общая структура текста, и используемые в нем термины вполне понятны любому. Структурированное словесное описание это не программа, но эти понятия близки.
PROCEDURE: PWARN $ display warning message
INPUTS:
LOTMP — time to retry after overtemp condition
LEMI — time to retry after EMI condition
LACT — printer queue overflow flag
OUTPUTS:
none
IF LACT set THEN
IF NOR less than TQR (space unavailable) THEN
clear LACT
set LCODE to 134
call procedure POPMG to display operator message
ENDIF
ENDIF
DO-WHILE LACTX is 0 thru 1
IF EMI is set and CSRTC is greater than or equal to LEMI(LACTX) THEN
set LCODE to 321
call procedure POPMG to display warning message
store the new retry time in LEMI
increment retry counter LRCTR
IF LRCTR greater than or equal 3 THEN