Описание тестируемой системы и ее окружения. Планирование тестирования

Планирование тестирования

Процесс тестирования

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

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

Планирование тестирования

Как было отмечено выше, процесс тестирования тесно связан с процессом разработки. Соответственно планирование тестирования тоже зависит от выбранной модели разработки. Однако вне зависимости от модели разработки при планировании тестирования необходимо ответить на пять вопросов, определяющих этот процесс:

Кто будет тестировать и на каких этапах?

Разработчики продукта, независимая группа тестировщиков или совместно?

Какие компоненты надо тестировать?

Будут ли подвергнуты тестированию все компоненты программного продукта или только компоненты, которые угрожают наибольшими потерями для всего проекта?

Когда надо тестировать?

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

Как надо тестировать?

Будет ли тестирование сосредоточено только на проверке того, что данный продукт должен выполнять, или также на том, как это реализовано?

В каком объеме тестировать?

Как определить, в достаточном ли объеме выполнено тестирование, или как распределить ограниченные ресурсы, выделенные под тестирование?

Кто будет тестировать?

Разработчик - это роль, для которой характерны виды деятельности, ориентированные на создание программного продукта (ПП). Тестировщик - это роль, для которой характерны виды деятельности, ориентированные на улучшение/обеспечение качества программного продукта. Эта роль предусматривает выбор тестов, необходимых для конкретных целей, построение тестов, выполнение тестов и оценку результатов. Конкретный исполнитель проекта может выступать как в роли разработчика, так и в роли тестировщика. Момент начала тестирования в проекте можно регулировать (рис. 1.2).

Рис. 1.2. Кто тестирует

В рамках данного практикума студенту предназначена роль тестировщика.

Какие компоненты надо тестировать?

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

Рис. 1.3. Что тестировать

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

Когда надо тестировать?

Компоненты можно тестировать на завершающем этапе, когда они будут интегрированы в единый выполняемый модуль. Частота тестирования определяется различными соображениями. Можно проводить тестирование каждый день, учитывая тот факт, что чем раньше выявлена проблема, тем легче и дешевле ее решение. Можно тестировать программный компонент по мере завершения его разработки (рис. 1.4). Частое тестирование компонентов несколько замедляет ранние этапы разработки, однако сопряженные с этим потери с лихвой восполняются за счет меньшего числа проблем на более поздних этапах разработки проекта, когда отдельные модули объединяются в более крупные компоненты системы.

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

Рис. 1.4. Когда тестировать

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