Повторяемость тестирования

8.1. Задачи и цели обеспечения повторяемости тестирования при промышленной разработке программного обеспечения

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

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

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

В общем случае повторное выполнение тестов может завершиться одним из трех способов.

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

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

Процесс, включающий в себя повторное выполнение тестов, называют регрессионным тестированием. Регрессионное тестирование включает в себя следующие стадии:

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

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

8.2. Предусловия для выполнения теста, настройка тестового окружения, оптимизация последовательностей тестовых примеров

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

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

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

Эта информация обычно отсутствует в тест-планах, однако требуемое для выполнения тестов состояние тестового окружения необходимо учитывать при разработке тестовых примеров.

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

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

Для проверки следующих требований:

необходимы как минимум три тестовых примера со следующими сценариями:

Тестовый пример 1
   1.  Включить систему в режиме FACTORY_SETTINGS.
   2.  Проверить, что настройки имеют значения по умолчанию 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

Тестовый пример 2
   1.  Включить систему в режиме FACTORY_SETTINGS.
   2.  Перезагрузить систему (вызвать ее старт в режиме COLD_START).
   3.  Проверить, что настройки имеют значения по умолчанию
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

Тестовый пример 3
   1.  Включить систему в режиме FACTORY_SETTINGS.
   2.  Изменить значения настроек системы (в реальном тест-плане 
       здесь должны быть установлены конкретные значения переменных).
   3.  Перезагрузить систему (вызвать ее старт в режиме COLD_START).
   4.  Проверить, что настройки имеют последние введенные значения
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

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

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

Тестовый пример 1
   1.  Включить систему в режиме FACTORY_SETTINGS
   2.  Проверить, что настройки имеют значения по умолчанию 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

Тестовый пример 2
   1.  Перезагрузить систему (вызвать ее старт в режиме COLD_START)
   2.  Проверить, что настройки имеют значения по умолчанию 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

Тестовый пример 3
   1.  Изменить значения настроек системы
   2.  Перезагрузить систему (вызвать ее старт в режиме COLD_START)
   3.  Проверить, что настройки имеют последние введенные значения 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

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

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

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

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

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

Первоначальные установки тестового окружения
   Установить значение флага Флаг_Система_Стартовала = FALSE

Тестовый пример 1
   1.  Включить систему в режиме FACTORY_SETTINGS
   2.  Установить значение флага Флаг_Система_Стартовала = TRUE 
   3.  Проверить, что настройки имеют значения по умолчанию 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

Тестовый пример 2
   1.  Проверить, что флаг Флаг_Система_Стартовала = TRUE, иначе 
       прервать тестирование с выдачей диагностического сообщения
   2.  Перезагрузить систему (вызвать ее старт в режиме COLD_START)
   3.  Проверить, что настройки имеют значения по умолчанию 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

Тестовый пример 3
   1.  Проверить, что флаг Флаг_Система_Стартовала = TRUE, иначе 
        прервать тестирование с выдачей диагностического сообщения
   2.  Изменить значения настроек системы (в реальном тест-плане здесь 
       должны быть установлены конкретные значения переменных)
   3.  Перезагрузить систему (вызвать ее старт в режиме COLD_START)
   4.  Проверить, что настройки имеют последние введенные значения 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

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

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

8.3. Зависимость между тестовыми примерами, настройки по умолчанию для тестовых примеров и их групп

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

Тестовые примеры из предыдущего раздела можно разбить на две группы:

Тестирование старта системы: тестовый пример 1
Тестирование перезагрузки системы: тестовые примеры 2-3

Разбиение тестовых примеров на группы удобно и с точки зрения установки начального состояния тестового окружения для выполнения тестов - так, перед выполнением группы тестов можно инициализировать значения переменных или состояние системы, необходимое для выполнения всей группы. Например, если система работает в двух режимах - нормальном и сервисном, то перед выполнением группы тестов для нормального режима работы системы устанавливать нормальный режим, а перед выполнением тестов для сервисного режима - сервисный. Такие установки называются настройками группы тестов по умолчанию ( group defaults, test group defaults ).

Перед выполнением каждого тестового примера может потребоваться установка одних и тех же переменных в одни и те же значения. Для того, чтобы не дублировать эти установки в описании каждого тестового примера, в тест-плане можно определить настройки по умолчанию для каждого теста ( test case defaults ), например, следующим образом:

Первоначальные установки тестового окружения
   Установить значение флага Флаг_Система_Стартовала = FALSE

Настройки по умолчанию для группы:
   Установить сервисный режим работы системы 
Настройки по умолчанию для тестового примера:
   Обнулить значения выходных переменных тестового окружения, 
   в котором сохраняются настройки системы

Группа 1: Тестирование старта системы (режим FACTORY_SETTINGS)

Тестовый пример 1
   1.  Включить систему в режиме FACTORY_SETTINGS
   2.  Установить значение флага Флаг_Система_Стартовала = TRUE 
   3.  Проверить, что настройки имеют значения по умолчанию (в реальном 
       тест-плане здесь должны быть проверки конкретных значений переменных)

Группа 2: Тестирование перезагрузки системы (режим COLD_START)

Тестовый пример 2
   1.  Проверить, что флаг Флаг_Система_Стартовала = TRUE, иначе 
       прервать тестирование с выдачей диагностического сообщения
   2.  Перезагрузить систему (вызвать ее старт в режиме COLD_START)
   3.  Проверить, что настройки имеют значения по умолчанию 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

Тестовый пример 3
   1.  Проверить, что флаг Флаг_Система_Стартовала = TRUE, иначе 
       прервать тестирование с выдачей диагностического сообщения
   2.  Изменить значения настроек системы 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).
   3.  Перезагрузить систему (вызвать ее старт в режиме COLD_START)
   4.  Проверить, что настройки имеют последние введенные значения 
     (в реальном тест-плане здесь должны быть проверки 
      конкретных значений переменных).

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

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

Пример предусмотренной тестовой зависимости был рассмотрен в предыдущем разделе - корректность выполнения тестов определялась порядком их выполнения. Такая тестовая зависимость требует документирования и сопровождения, как и сами описания тестовых примеров. Существует два вида документирования тестовых зависимостей:

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

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