- •В ходе работы над проектом по созданию любой сложной программной системы создается большое
- •Поскольку верификация программной системы (в оптимистичном случае) выполняется в течение всего жизненного цикла
- •Перед началом верификации менеджером тестирования (test manager) создается документ, называемый планом верификации (или
- •В данном документе также определяются требования собственно к тестовой документации – тест-требованиям, тест-
- •На основании тест-требований разработчиками тестов (test developers) создаются тест-планы – документы, которые содержат
- •По несоответствиям создаются отчеты о проблемах – документы, которые направляются на анализ в
- •Форматы различных тестовых документов описаны в стандартах IEEE 1012 [14] и IEEE 829
- •Стратегия и планы верификации
- •Для каждого этапа определяется:
- •Согласно разделу 4 стандарта IEEE 829 [15] основная задача плана тестирования как документа
- ••идентификатор плана тестирования и номер его версии, который позволяет однозначно находить нужный план
- ••критерий успешности/неуспешности прохождения тестов
- •• требования к среде тестирования – данный раздел описывает требования к аппаратным и
- •Стратегия и планы тестирования несколько отличаются от другой документации, относящейся к процессу тестирования.
- •Тест-требования
- •Тест-требования, написанные в рамках структурного подхода пишутся на основании описания архитектуры системы и
- •Свойства тест- требований
- •Тест-требования, написанные в рамках функционального подхода обычно разделяют на следующие группы:
- •Как правило, одному системному или функциональному требованию соответствует минимум одно тест-требование. Если совокупность
- •Примером не верифицируемого требования может служить следующее «требование»:
- •Без четкого определения критериев интуитивной понятности, проверить такое требование при помощи написания тестовых
- •При большом количестве тест-требований и частых их изменениях может возникнуть ситуация, в которой
- •Тест-планы
- •Критерием качества тест-плана является покрытие (выполнение) всех требований к проверке правильности функционирования программной
- •Структура тест-плана может соответствовать структуре тест- требований или следовать логике внешнего поведения системы.
- •В состав тест-плана рекомендуется дополнительно включать пункты, служащие для проверки ветвей программы, не
- •Возможные формы подготовки тест-планов
- •Для автоматизированного тестирования сценарий теста может записываться на каком-либо формальном языке, в этом
- •И, наконец, третьей формой представления тестовых примеров является определение примеров в виде конечного
- •Сценарии
- •Подразумевается, что действия сценария должны быть описаны таким образом, чтобы их мог воспроизвести
- •Как можно видеть, такая форма представления действительно неудобна для автоматизации тестирования и предназначена
И, наконец, третьей формой представления тестовых примеров является определение примеров в виде конечного автомата. Такая форма представления используется при тестировании протоколов связи или при тестировании программных модулей, взаимодействие которых с внешним миром производится при помощи обмена сообщениями по заранее заданному интерфейсу. Модуль при этом может быть представлен как конечный автомат с набором состояний, а тест-план будет состоять из двух частей – описания переходов между состояниями и их параметров и тестовых примеров, в которых задается маршрут перехода между состояниями, параметры переходов и ожидаемые значения. Такое представление тест-плана может быть пригодно как для ручного, так и для автоматизированного тестирования.
Сценарии
Представление сценариев, удобное для ручного тестирования – тест-план в виде текстового документа, в котором каждый тестовый пример представляет один раздел. Для каждого тестового примера в этот документ записывается следующая информация:
•идентификатор;
•описание теста и его цель;
•ссылки на тестируемую часть системы;
•ссылки на используемую проектную окументацию, в частности тест- требования;
•перечисление действий сценария;
•ожидаемая реакция системы на каждый пункт сценария.
Подразумевается, что действия сценария должны быть описаны таким образом, чтобы их мог воспроизвести человек с практически любым уровнем подготовки.
Описание ожидаемой реакции системы должно также быть записано таким образом, чтобы можно было однозначно судить о том – соответствует реакция ожидаемой или нет.
Так, неудачной ожидаемой реакцией при ручном тестировании была бы запись
Сообщение «Загрузка» пропадает через приемлемое время
Степень приемлемости здесь будет зависеть от терпеливости тестировщика, и обеспечить повторяемость тестирования будет затруднительно. Более удачной формой описания той же самой ожидаемой реакции будет
Сообщение «Загрузка» исчезает с экрана не более, чем через 10 секунд после появления.
Как можно видеть, такая форма представления действительно неудобна для автоматизации тестирования и предназначена исключительно для ручного тестирования. Иногда такие тест-планы совмещают с отчетами о проведении тестирования, добавляя в таблицу описания сценария третью и четвертые колонки – «Реальный результат» и «Соответствует», в который заносятся реальная реакция системы и указание на совпадение/несовпадение результатов соответственно. В конце описания каждого тестового примера добавляется графа «Пройден/не пройден», в которую заносится информация о том, пройден ли тестовый пример в целом. В конце всего тест-плана совмещенного с отчетом помещается графа «Тестовых примеров пройдено/всего», в которую заносится число пройденных тестовых примеров и общее их число.
