Проектирование модулей приложений

Проектирование процесса тестирования модулей приложений

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

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

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

• Автономные тесты (тесты модулей).
• Тесты связей модулей.
• Системный тест для приложения базы данных в целом.
• Приемо-сдаточные испытания (которые может проводить заказчик).
• Тесты производительности.

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

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

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

Рассмотрим подход, который основан на модели проектной группы Модель MSF версии 3.1, предлагаемой компанией Microsoft. В этой методике предусмотрен так называемый ролевой кластер "Тестирование".

Задача ролевого кластера "Тестирование" (test) - одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Обнаружение и устранение дефектов может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта. Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом - как для проектной команды, так и для заказчика.

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

1. Планирование тестов:
   • разработка методологии и плана тестирования;
   • участие в установлении стандарта качества (quality bar);
   • разработка спецификаций тестов.
2. Разработка тестов:
   • разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов;
   • проведение тестов с целью определения состояния проекта;
   • управление билдами (manage the build process).
3. Отчетность о тестах:
   • доведение до сведения проектной группы информации о качестве продукта;
   • мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.

Планирование тестов. Данная область компетенции (планирование тестов - test planning) ролевого кластера "Тестирование" формулирует методологию нахождения и урегулирования проблем качества продукта.

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

Существенная часть работы данной области компетенции заключается в участии в выработке требуемого уровня качества (quality bar) продукта. Эта деятельность включает в себя предоставление проектной группе метрик контроля качества и критериев успешности решения.

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

Разработка тестов. Эта область компетенции (разработка тестов - test engineering) ответственна за предусмотренные планом тестирования мероприятия, направленные на нахождение и урегулирование всех проблем качества создаваемого продукта. В их числе - работа по созданию и поддержке тестовых сценариев (test cases), разработка средств, скриптов и документации процесса тестирования, управление ежедневными билдами (daily builds), проведение на них тестов с целью четкого определения уровня завершенности продукта.

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

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

Таким образом, при разработке стратегии (или общего плана тестирования) проектировщик должен опираться на принятые в организации стандарты разработки систем. Если он опирается в своей работе на использование модели проектной группы MSF, то должен формулировать пункты стратегии тестирования в соответствии с вышеизложенными требованиями по организации работы ролевого кластера "Тестирование".

В заключение раздела рассмотрим некоторые практические рекомендации проектировщикам базы данных при разработки стратегии тестирования.

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

Стратегия тестирования должна отвечать на следующие вопросы:

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

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

Из стратегии тестирования органично выписывается план тестирования. Шаблоны планов тестирования, предлагаемые различными методологиями, зачастую прямо включают одним из разделов описание стратегии тестирования или же включают описание стратегии в пункты плана, отвечающие за тестирование конкретных частей функционала. К примеру, шаблон методологии Rational Unified Process определяет стратегию тестирования как самый большой раздел плана тестирования.

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

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

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

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

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

Клиент: 50 тестов на работу с данными (ввод форм, расчет данных на основе данных, хранимых в словарях, поиск данных, редактирование словарей и т.п.), 10 тестов на работу с печатными формами (формирование периодов выборок, выбор типов отчетов, печать или экспорт в предопределенный список форматов и т.д.). Пусть для тестирования работы с системой требуется еще 5 тестов. Для проверки функциональности, связанной с самой операционной системой, потребуется (5 + 10)*2 = 30 тестовых прогонов. Будем считать, что 50 тестовых прогонов будет достаточно для проверки логики работы с данными. Итог - 80 тестовых прогонов для тестирования клиента системы.

Объединим в рамках рассматриваемого примера тестирование функциональности сервера приложений и базы данных. Пусть сервер приложения реализует 20 команд по обработке данных и пользовательских сессий (без учета работы с системными пулами соединений, функций сжатия передаваемого по сети трафика и т.п.). Сервер баз данных реализует 10 системных операций по архивации данных, построению статистики использования отчетов и еще несколько подобных операций. Общий смысл заключается в том, что мы имеем конечный набор тестируемых операций, и так как конфигурации определены заранее, можем говорить о конечном наборе тестов, которые необходимо выполнить, чтобы проверить работоспособность серверного функционала системы. Итог - 30 тестов на серверной стороне. Заметим, что в данном примере мы не затрагиваем нагрузочную составляющую тестирования: речь идет только о функциональном тестировании.

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

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

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

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

Литература: [9], [17], [18], [19], [22], [30], [33], [45].