Часть I. Процесс быстрого тестирования. Как отмечалось ранее, для удобства выполнения тесты можно и далее разбивать на тестовые случаи

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

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

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

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

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

Следует отметить, по меньшей мере, один дополнительный признак хорошо спроектированного тестового случая — он не должен быть избыточным. Оптималь­ ный рабочий график тестирования требует, чтобы вы выполнили объем тестирова­ ния, достаточный для обнаружения всех неисправностей перед поставкой программ­ ного продукта заказчику, но вы не должны тратить время на прогон избыточных тес­ тов. В рассмотренном выше примере вы не должны тратить время на отображение на экране названия штата для каждого известного почтового индекса, если эта функция не критична для бизнес-операций заказчика. Если с отображением на экране почто­ вых индексов связана крупная неприятность, наверняка потребуется потратить вре­ мя на тестирование функции отображения. Кроме того, следует задуматься над во­ просами автоматизации этой утомительной задачи. Но если это свойство реализуется из соображений удобства, возможно, потребуется лишь проверить какой-нибудь до­ пустимый и несколько недопустимых индексов, дабы подтвердить правильность ба­ зовых функциональных свойств. Эта тема обсуждается в разделе " Разбиение на экви­ валентные классы" далее в этой главе, а также в главе 10.

Резюмируя, можно утверждать, что с тестовым случаем должны быть связаны сле­ дующие признаки:

• Он должен обладать высокой вероятностью обнаружения дефекта.

• Он должен быть воспроизводимым.

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

• Он не должен быть избыточным.

Разработка детализированных методик тестирования

Детализированные методики тестирования могут быть разработаны на основе про­ ектов тестов. Уровень детализации методик тестирования, представленных в пись­ менном виде, зависит от квалификации и знаний исполнителей, которые выполняют прогон тестов. Вы планируете привлечь к выполнению системного испытания про­ граммного продукта исполнителей, мало знакомых с этим продуктом? Если это так, то они должны пройти определенную подготовку, а методика тестирования должна быть четко сформулирована с тем, чтобы они выполняли корректные тестовые дей­ ствия. В случае, когда тестировщики обладают подробными знаниями программного продукта, методика тестирования может быть менее детализированной. Решение относительно того, каким должен быть уровень детализации методик тестирования, имеет большое значение, ибо можно напрасно потратить время на описание излиш­ них подробностей для подготовленного пользователя. С другой стороны, напрасно потратить время можно и на обучение неподготовленных тестировщиков тому, как