Верификация программного обеспечения (стр. 18 )

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

       Тестовый пример 2

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

       Тестовый пример 3

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

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

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

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

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

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

Тестирование старта системы: тестовый пример 1

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

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

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

Первоначальные установки тестового окружения

       Установить значение флага Флаг_Система_Стартовала = FALSE

Настройки по умолчанию для группы:

       Установить сервисный режим работы системы

Настройки по умолчанию для тестового примера:

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

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

       

Тестовый пример 1

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

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

       Тестовый пример 2

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

       Тестовый пример 3

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

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

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

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

явное определение допустимого порядка выполнения тестовых примеров; определение допустимого порядка выполнения тестовых примеров при помощи предусловий.

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

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

Документация, сопровождающая процесс верификации и тестирования (лекции 6-8) Технологические процессы верификации и роли в проекте, документация, создаваемая в ходе жизненного цикла проекта, ее назначение

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

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

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

В данном документе также определяются требования собственно к тестовой документации – тест-требованиям, тест-планам, отчетам о выполнении тестирования.

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