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

Определение ожидаемых результатов

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

Таблица 4.2. Примеры ожидаемых результатов

Фрагмент тестового случая для программы, которую рассматривается в качестве примера и вычисляет стоимость доставки по почтовому индексу груз с заданным ве­ сом, приводится в таблице 4.2. Шаги методики тестирования пронумерованы в пер­ вом столбце. Краткие описания действий, выполняемых тестировщиком, даны во втором столбце, а исчерпывающие описания ожидаемых результатов находятся в третьем столбце. Предполагается, что в этом примере при проведении испытаний будет использоваться твердая (или интерактивная) копия этой таблицы, в связи с чем в ней предусмотрен четвертый столбец, в котором тестировщик может отмечать ка­ ждый выполненный шаг. В дальнейшем мы покажем, что следует предпринимать в случае, если какой-то тест не проходит. Особое внимание следует обратить на то, чтобы на каждом шаге методики тестирования предоставлялись четкие описания ожидаемых результатов.

Установка и очистка — тестирование из известного состояния

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

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

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

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

Шаблон тестового случая

Все предложения, касающиеся проектирования тестового случая, обсуждавшиеся до сих пор, могут быть сведены в единый шаблон тестового случая. Возможно, возник­ нет желание создать собственный шаблон, тем не менее, стоит обратить внимание на один из вариантов такого шаблона, показанный на рис. 4.2. Тестовые случаи, осно­ ванные на этом шаблоне, можно распечатать для целей неавтоматизированного тес­ тирования, либо за счет организации отображения в браузере их HTML-версий поя­ вится возможность прогона тестов в интерактивном режиме.

Примечания:

- Тест потерпел неудачу на шаге 3.

- При возникновении неисправности выдается код ошибки BR1011.

Рис. 4.2. Пример тестового случая

Основными элементами шаблона тестового случая являются:

• Идентификатор тестового случая — включает номер версии теста.

• Владелец теста — имя или инициалы лица, эксплуатирующего тест (оно может не совпадать с именем автора теста).

• Дата последнего пересмотра — эта информация позволит определить, является ли тест актуальным.

• Наименование теста — описательное имя теста, которое позволяет легко оты­ скать тест и понять его назначение. Применение имен, не несущих смысловой нагрузки, например, " xxxLLL0123.tst", не рекомендуется.

• Местонахождение теста — это полное имя пути, включая сервер.

• Тестируемое техническое требование — это должен быть уникальный иденти­ фикатор, который отображается на документы с техническими требованиями.

• Цель тестирования — краткая и четкая формулировка того, чего должен дос­ тичь данный тест. Более подробная информация изложена выше, в разделе " Определение целей теста".

• Конфигурация средств тестирования — спецификация ввода, спецификация вывода, условия испытаний.

• Настройка на прогон теста— эта процедура подобна методике тестирования. Она предусматривает описание действий, выполняемых тестировщиком, и ожидаемых результатов. Если настройки автоматизированы, это может выгля­ деть как run setupSC03.pl.

• Методика тестирования — описание действий, выполняемых тестировщиком, и ожидаемых результатов.

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

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

Управление конфигурацией тестового случая

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

Управление направлением изменения программного продукта осуществляется благодаря использованию инструментальных средств CM (Configuration Manage­ ment— управление конфигурациями), таких как инструментальные средства CVS (Control Version System — система управления версиями) или ClearCase. С помощью