Структура тестовых сценариев

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

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

• Добавление, изменение, удаление (самая очевидная комбинация)
• Добавление, удаление, изменение
• Добавление, удаление, Добавление, удаление, ...
• Добавление, добавление, добавление, ...

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

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

Методика записи сценариев

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

• С помощью клавиши TAB
• С помощью клавиши мыши
• С помощью клавиш быстрого доступа

У каждого из этих вариантов разная устойчивость к изменениям. Например, после вставки нового поля между двумя другими перестанет работать вариант с TAB. После переназначения клавиш быстрого доступа перестанет работать третий вариант. Если способ определения поля, указываемого мышью, будет изменяться, то и второй метод не подходит. Некоторые инструменты автоматизации тестирования позволяют идентифицировать поля более надежными способами, например, по имени объекта, присваиваемого инструментов разработки (PowerBuilder, SQLWindows или Visual Basic). В этом случае тестовые сценарии будут продолжать работать после внесения небольших изменений в тестируемое ПО (как-то: изменение расположения элементов, текста меток, оформления и т.д.)

Ориентация тестов на данные

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

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

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

Обработка ошибок

Тестовые сценарии выполняются последовательно. Ветвление в явной форме не поддерживается. Для явной обработки ошибок в сценариях необходима дополнительная логика. Например:

• Переход к другим сценариям.
• Вызов сценария, устраняющего возможные последствия ошибки.
• Выход из сценария и запуск следующего.
• Выход из сценария, перезапуск тестируемого ПО и продолжение с места последней ошибки.

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

Синхронизация и планирование сценариев

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

InputFile$ = "TIME.DAT"
Open InputFile$ For Input As 1
Input #1, StartTime$
Close #1
Do While TimeValue(StartTime$) > Time
   DoEvents
Loop
[запуск сценария]

В этом примере время запуска задается в файле. Это позволяет изменять время без надобности разбираться в сценарии. Время сохраняется в переменной StartTime$. Цикл Do While выполняется до наступления заданного времени. Благодаря оператору DoEvents процессорное время может расходоваться на фоновые задачи. Без этого оператора система не реагировала бы на действия пользователя до наступления времени запуска.

Тестирование и отладка тестовых сценариев

При выполнении тестовых сценариев на том же ПО, на котором они были записаны, ошибок (в самих сценариях) возникать не должно. Среда и ПО такие же, как и во время записи. Однако при их смене тест может стать работать некорректно. Для выявления таких возможных неполадок перед использованием сценариев для реального тестирования нужно тестировать их самих. Далее рассматриваются два вида неполадок:

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

Разница во времени записи и воспроизведения может привести к неполадкам. Запись сценария происходит медленнее, чем выполнение. Иногда это может привести к тому, что ПО просто не будет успевать выполнять команды сценария. Для избежания этого можно вставлять в сценарии операторы ожидания.