Правило обеспечения наглядности логической структуры.

1. Используются дополнительные пробелы для выделения составных частей операторов.

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

3. Всегда надо использовать ()-ки для пояснения структуры записываемых выражений.

a*b/c*d*e/f

(a*b*d*e)/(c*f)

4. Надо использовать отступы для выявления структуры составных и вложенных операторов.

 

5. Нисходящее программирование.

Предполагается поэтапная разработка программы начиная с модулей верхнего и кончая модулями нижних уровней иерархии. Исходные тексты верхних модулей появляются при неполной проработке структуры программы на нижних уровнях иерархии. Последовательность разработки: см. пример-рисунок

A-B-C-D-B1-B2-C1-D1-D2-D3

Преимущества нисходящего программирования:

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

2. В процессе проектирования вскрываются противоречия и трудности, которые могли остаться незамеченными долгое время.

3. Нисходящее программирование может быть совмещено с выполнением отладки программы нисходящим методом.

 

Методы проверки программ:

1. Статическая проверка.

Анализ программы без её выполнения на ЭВМ. Здесь проверяется программа или проектное решение, если проверка проводится до стадии рабочего проекта. В результате составляется описание обнаруженных несоответствий в программе или между программой и принятыми стандартами и соглашениями.

2. Динамическая проверка.

Разработка и выполнение на ЭВМ наборов текстовых данных с целью обнаружения ошибок, включает в себя 3-и этапа:

1. Разработка тестов.

2. Использование программы или моделирование использования.

3. Анализ полученных результатов.

Тестирование программного обеспечения.

(динамическая проверка)

 

Тестирование – выполнение программы с целью найти ошибки. Процесс тестирования можно поделить на этапы:

Тестирование элементов.

Цель: индивидуальная проверка каждого модуля. Используется стратегия белого ящика.

Тестирование интеграций.

Цель: тестирование сборки модулей в программную систему. Используется стратегия чёрного ящика.

Тестирование правильности.

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

Системное тестирование.

Цель: проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализацию всех системных функций.

 

Тестирование элементов.

Объект тестирования – наименьшая единица проектирования программной системы – модуль. Тестированию подвергаются:

ü интерфейс модуля;

ü внутренние структуры данных;

ü независимые пути;

ü пути обработки ошибок;

ü граничные условия.

 

Наиболее общие ошибки в вычислениях:

ü не правильный или не понятный приоритет арифметических операций;

ü смешанная форма операций;

ü некорректная инициализация;

ü несогласованность в представлении точности;

ü некорректное символическое представление выражения.

Источники ошибок сравнения и не правильных потоков управления.

1. Сравнение различных типов данных.

2. Некорректные логические операции и приоритетность.

3. Ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной.

4. Некорректное сравнение переменных.

5. Не правильное прекращение цикла.

6. Отказ в выходе при отклонении в итерации.

7. Не правильное изменение переменных цикла.

Тестирование интеграций.

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

Категории ошибок интерфейса:

­ потеря данных при прохождении через интерфейс;

­ отсутствие в модуле необходимой ссылки;

­ неблагоприятное влияние одного модуля на другой;

­ подфункции при объединении не образуют требуемую главную функцию;

­ отдельные допустимые неточности при интеграции выходят за допустимый уровень;

­ проблемы при работе с глобальными структурами данных.

Существует 2 варианта тестирования, поддерживающих процесс интеграции:

Ø нисходящее;

Ø восходящее.

Нисходящее тестирование интеграций.

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

М1

М4

М6

М8

М5

М3

М2

М7

 

М1-М2-М5-М6-М8…– в глубину;

М1-М2-М3-М4-М5…– в ширину.

 

 

Возможные шаги процесса нисходящей интеграции:

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

2. Одна из заглушек заменяется реальным модулем. Модуль выбирается поиском в ширину или в глубину.

3. После подключения каждого модуля и установки на нём заглушек проводится набор тестов, проверяющих полученную структуру.

4. Если в модуле-драйвере уже нет заглушек, производится смена модуля-драйвера поиском в ширину или в глубину.

5. Возврат к п.2 до тех пор, пока не будет построена целая структура.

Достоинство:

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

Недостаток:

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

 

Восходящие тестирования интеграций.

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

 

Шаги методики восходящей интеграции:

1. Модули нижнего уровня объединяются в кластеры (несколько модулей, т.е. в группы), выполняющие определенные программные подфункции.

2. Для координации вводов-выводов тестового варианта имеется драйвер, управляющий тестированием кластеров.

3. Тестируется кластер.

4. Драйверы удаляются, а кластеры объединяются в структуру движениями вверх.

Мс

Ма

Мb

D3

D2

D1

кластер 1

кластер 2

кластер 3

 

Сравнение нисходящего и восходящего тестирования.

Нисходящее тестирование основной недостаток: необходимость заглушек и связанных с ними трудностей.

Достоинство: возможность раннего тестирования главных управляющих функций.

 

Восходящее тестирование основной недостаток: система не существует как объект до тех пор, пока не будет добавлен последний модуль.

Достоинство: упрощается разработка тестовых вариантов, отсутствуют заглушки.

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

Признаки критического модуля:

1. Реализует несколько требований к программной системе.

2. Имеет высокий уровень управления (находится достаточно высоко в программной структуре).

3. Имеет высокую сложность или склонность к ошибкам.

4. Имеет определенные требования производительности обработки.

Такие модули должны тестироваться как можно раньше. К ним должны применяться регрессивное тестирование (повторение выполненных тестов в полном или частичном объёме).

 

 

Тестирование правильности.

Цель: подтвердить, что функция, описанная спецификации требований к программной системе соответствует ожиданиям заказчика.

Используется метод чёрного ящика. Важнейшим элементом является проверка конфигурации программной системы.

Конфигурацией программной системы называют совокупность всех элементов информации, вырабатываемых в процессе конструирования программной системы (ПС).

Базовые элементы конфигурации ПС:

1. Системная спецификация.

2. План программного проекта.

3. Спецификация требований к ПС.

4. Предварительное руководство пользователя.

5. Спецификация проектирования.

6. Листинги исходных тестов программ.

7. План и методика тестирования, тестовые варианты и полученные результаты.

8. Руководства по работе и инсталляции.

9. Exe-код выполняемой программы.

10. Описание базы данных.

11. Руководство пользователя по настройке.

12. Документы сопровождения, отчёты о проблемах ПС, запросы сопровождения, отчёты о конструкторских изменениях.

13. Стандарты и методики конструирования.

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

Альфа-тестирование проводится заказчиком в организации разработчика. Исполнитель фиксирует все выявленные заказчиком ошибки и проблемы использования.

Бетта-тестирование проводится конечным пользователем в организации заказчиков. Это реальное ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бетта-тестирование проводится в течение фиксированного срока (примерно - год).

 

Системное тестирование.

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

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

Для защиты от обвинений разработчик программного элемента должен:

1. Предусмотреть средства обработки ошибок, которые тестируют все вводы информации от других элементов системы.

2. Провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса ПС.

3. Записать результаты тестов, чтобы использовать их как доказательства невиновности в случае указания причины.

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

В конечном итоге тесты должны проверять, что все элементы правильно объединены и выполняют назначенные функции.