Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Тестирование программного обеспечения. Фундамен...docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
935.81 Кб
Скачать

Глава 1: Пример серии тестов • 25

Лучше всего подходят для тестирования примеры, лежащие на грани­це представленного классом диапазона значений. Именно на граничных значениях программы сбоят чаще всего. Например, если программа пред­назначена для сложения двузначных чисел, одним из граничных значе­ний, которые она должна правильно обрабатывать, является число 99.

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

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

Волшебной формулы для объединения тестов в группы и определения граничных условий не существует. Это умение приходит только с опы­том. Прочитав программный код, можно найти в нем то, чего при исполь­зовании программы вы не сможете даже предположить. Однако проверять те критические точки, которые можно определить по листингу, — это прежде всего работа программиста. А ваша задача — проанализировать программу с другой точки зрения, чтобы выявить те критические точки, которые программист пропустил. Поэтому классы возможных тестов вам следует выделять, исходя прежде всего из внешнего поведения програм­мы. В результате набор тестов будет отличаться от того, который можно составить по листингу программы, — именно в этом суть вашей задачи.

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

Шаг 3. Проверим допустимые значения и посмотрим, что происходит

Серия тестов, приведенных на рис. 1.4, охватывает только допустимые значения входных данных программы. На следующем этапе тестирования можно создать такую же серию тестов для недопустимых значений. Еще одна серия тестов может быть предназначена для проверки редактирова­ния чисел: вы вводите значение, затем изменяете его и только после это­го нажимаете <Еп1ег>. Однако прежде всего выполните простейшие тесты, приведенные на рис. 1.4.

26 Часть I: Основы

Программу тестируют потому, что она может не работать.

Можно убить уйму времени на разнообразные тесты, подсказанные ва­шей фантазией, а затем обнаружить, что программа не может сложить 2 и 3. Вот результаты теста нашей программы-примера.

• Положительные числа и 0 обрабатываются прекрасно.

• Не работает ни один тест с отрицательными числами. После вво­да второй цифры компьютер просто “зависает”. (Он игнорирует клавиатурный ввод, и его приходится перезапускать.) Вы попробо­вали сложить 9 и -9, чтобы посмотреть, не примет ли программа однозначные отрицательные числа, но после нажатия клавиши <ЕЩег> компьютер “завис”. Очевидно, программа не ожидает от­рицательных чисел.

Шаг 4. Немного тестирования в режиме "свободного полета"

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

В нашем примере вы быстро достигли точки, в которой формальное те­стирование переходит в неформальное, поскольку сбой программы не за­ставил себя ждать. Вероятно, в ней есть какая-то фундаментальная ошибка. Если это так, проект программы следует пересмотреть. Разраба­тывать новые тесты пока нет никакого смысла, поскольку к новой версии они могут просто не подойти. Поэтому, не тратя времени на планирова­ние, можно провести несколько чисто исследовательских экспериментов

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

Всегда записывайте, что вы делаете и что происходит во время исследовательских тестов.

Как видно из рис. 1.5, программа никуда не годится: она “зависает” при малейшей провокации. Вы больше времени тратите на перезапуски компьютера, чем на тестирование.