Тестирование программы как белого ящика

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

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

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

Монолитное (модульное) тестирование.

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

Выводы:

1. Монолитное тестирование требует больших затрат труда.

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

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

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

5. При монолитном - меньше расход машинного времени.

Категории тестов системных испытаний. Принципы тестирования. Ручное и автоматическое тестирование.

Категории тестов системных испытаний.

1. Тестирование удобства использования. Сравниваются цели с содержанием пользовательской документации.

2. Тестирование на предельных объемах.

3. Тестирование на предельных нагрузках. Означает поступление пикового объема данных в течение короткого интервала времени.

4. Тестирование удобства эксплуатации:

• Справка

• Значимость входных сообщений программы

• Понятна ли диагностика ошибок

• Единообразие стиля пользовательских интерфейсов

• Содержит ли система опции, число которых чрезмерно или использование которых маловероятно

• Выдает ли система какие-либо подтверждения на все входные сообщения

1. Тестирование защиты (от несанкционированного доступа).

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

3. Тестирование требований к памяти.

4. Тестирование конфигураций оборудования.

5. Тестирование удобства установки (настройки, инсталляции).

6. Тестирование надежности.

7. Тестирование восстановления.

8. Тестирование удобства обслуживания.

9. Тестирование документации.

10. Тестирование процедур.

11. Выполнение проверки системы непрограммистами.

Принципы тестирования.

1. Тестирование - это процесс выполнения программ с целью обнаружения ошибок.

2. Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.

3. Удачным считается тест, который обнаруживает еще не выявленную ошибку.

4. Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора.

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

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

7. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она того, чего не должна делать.

8. Тестирование - это процесс творческий.

Методы ручного тестирования:

1. Инспекции исходного текста.

2. Сквозные просмотры.

3. Проверка за столом.

Автоматические средства тестирования:

1. Профилировщик.

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

3. Компаратор.

4. Тестовый драйвер.

5. Пакет подпрограмм, вставляемых в рабочую программу.

Компаратор - это программа, считывающая 2 файла, сравнивающая их и печатающая различающиеся элементы. Профилировщики дают информацию о том, какие операторы и сколько раз выполнялись. Они позволяют накапливать статистические данные о работе тестируемой программы. Тестовый драйвер - это программа, пересылающая нужные данные на вход тестируемого модуля и накапливающая выходные данные. Самопроверкой называется проверка результатов тестирования самой тестируемой программой.

14) Отладка.

Отладка программы

Отладка, как мы уже говорили, бывает двух видов:

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

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

Отладка - это процесс локализации и исправления ошибок в программе.

Принципы отладки

Принципы локализации ошибок:

• Большинство ошибок обнаруживается вообще без запуска программы - просто внимательным просматриванием текста.

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

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

• Экспериментирования типа "а что будет, если изменить плюс на минус" - нужно избегать всеми силами. Обычно это не дает результатов, а только больше запутывает процесс отладки, да еще и добавляет новые ошибки.

Принципы исправления ошибок еще больше похожи на законы Мерфи:

• Там, где найдена одна ошибка, возможно, есть и другие.

• Вероятность, что ошибка найдена правильно, никогда не равна ста процентам.

• Наша задача - найти саму ошибку, а не ее симптом.

Это утверждение хочется пояснить. Если программа упорно выдает результат 0,1 вместо эталонного нуля, простым округлением вопрос не решить. Если результат получается отрицательным вместо эталонного положительного, бесполезно брать его по модулю - мы получим вместо решения задачи ерунду с подгонкой.

• Исправляя одну ошибку, очень легко внести в программу еще парочку. "Наведенные" ошибки - настоящий бич отладки.

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