Задача по разработке - небольшая часть деятельности разработчика, связанная с требованием к качеству или сценарием. В результате реализации задачи по разработке к системе добавляется новая функция. После завершения задачи по разработке необходимо провести тестирование модулей, обзор кода и его анализ, интеграцию кода и регистрацию его в базе кода. Затем сценарий или требование к качеству передается на тестирование.
| Оценка задачи по разработке | Оцените длительность задачи по разработке |
|---|---|
| Создание или изменение теста модуля | Определите тип теста модуля |
| Написание программы | Выберите компонент |
| Анализ кода | Определите правила приложения |
| Выполнение теста модуля | Выберите тест модуля из набора |
| Рефакторинг кода | Определите сложность |
| Обзор кода | Проверьте правильность имен |
| Интеграция изменений | Проверьте зависимости |
Оценка стоимости задачи по разработке помогает ограничить набор реализуемых функций, определить расписание и распределить приоритеты. Оценку всех задач по разработке и решение всех связанных с этим проблем необходимо выполнить до совещания по планированию итерации. Если общая стоимость задач по разработке превышает затраты на итерацию, задача должна быть отложена или переназначена. После утверждения задачи за ее оценку отвечает разработчик.
| Оценка на основе опыта | Проводите оценку с учетом времени выполнения аналогичных задач |
|---|---|
| Балансировка загрузки | Если в результате оценки выясняется, что объем работ превышает возможный уровень для итерации, совместно с менеджером проекта попробуйте перераспределить загрузку или перенести задачу на другую итерацию |
| Детализация задачи | Рассмотрите задачу по разработке с учетом других подобных задач, а также требований к качеству и сценариев, для которых еще не назначены задачи по разработке. Создайте для них задачи |
| Определите способы интеграции | Совместно с другими участниками группы разработки выработайте четкую картину |
Создайте код, определите измененные области, напишите тесты модулей, проведите обзор кода и внесите в него необходимые изменения, в завершение зарегистрируйте код на сервере управления версиями. Вам также может потребоваться выполнить отладку, рефакторинг и использовать промежуточные версии исходного кода. После того как код написан, необходимо выполнить его обзор и убедиться, что его качество соответствует требованиям и принятым стандартам. Созданный код не должен оказывать вредных побочных эффектов на другие части приложения.
| Выбор компонента для кода | Сопоставьте задачу с компонентом, в котором реализуется соответствующая функциональность |
|---|---|
| Создание новых классов или методов | С помощью диаграммы классов создайте классы, необходимые для реализации данной функциональности |
| Реализация алгоритма метода | Извлеките существующие классы, которые нужно изменить, из системы управления версиями |
Анализ кода - это процесс проверки обычного или управляемого кода .NET на предмет соответствия руководящим принципам по разработке. Для управляемого кода .NET в процессе анализа проверяется соответствие генерируемых сборок рекомендациям Microsoft .NET Framework Design Guide-lines. Предлагается автоматическая проверка сборок на наличие более чем 200 видов дефектов, таких как нарушение соглашений по именованию, ошибки в конструкции библиотек, а также проблемы локализации, безопасности и производительности. Задача анализа кода при работе с новыми базами кода - обеспечить отсутствие дефектов. Для существующих баз с большим числом правил формирования предупреждений цель состоит в минимизации числа предупреждений в каждой категории.
| Определение приемлемых правил | Выберите приемлемые правила для данной категории приложений |
|---|---|
| Обеспечение отсутствия дефектов | Проверьте код на соответствие правилам |
| Уменьшение числа дефектов по категориям | Для существующих баз кода с большим числом проблем с соответствием правилам определите базовые показатели уровня проблем. При использовании автоматизации, определите число предупреждений в существующей базе кода |
Задача по разработке базы данных - это деятельность разработчика, связанная с требованием к качеству или сценарием. В результате реализации задачи по разработке базы данных к системе добавляется новая функция. После завершения этой задачи необходимо провести тестирование модулей, обзор кода и его анализ, интеграцию кода и регистрацию его в существующей базе кода. Затем сценарий или требование к качеству передается на тестирование. Описанный здесь изолированный
| Оценка задачи по разработке базы данных | Проанализируйте поставленную задачу |
|---|---|
| Обновите локальную среду проекта | Извлеките из системы управления версиями требуемую версию проекта базы данных |
| Кодирование | Создайте новые или обновите существующие объекты схемы |
| Выполнение теста модуля | Определите тип теста модуля базы данных |
| Рефакторинг кода | Определите сложность |
| Обзор кода | Проверьте правильность имен |
| Интеграция изменений | Проверьте зависимости |
Оценка стоимости задач по разработке базы данных помогает ограничить набор реализуемых функций, определить расписание и распределить приоритеты. Оценка всех задач по разработке базы данных выполняется на совещании по планированию итерации. Если общая стоимость задач по разработке превышает затраты на итерацию, задача должна быть отложена или переназначена. Менеджер проекта и бизнес-аналитик определяют приоритеты задач и откладывают выполнение наименее приоритетных из них. После утверждения задачи за ее оценку отвечает разработчик. Прежде чем приступать к оценке задачи по разработке базы данных, разработчик баз данных должен пересмотреть назначенную ему задачу, разобраться в требованиях и обсудить оценку с другими разработчиками баз данных. В результате все разработчики будут иметь единое представление о задаче.
| Анализ поставленной задачи | Найдите связанный с поставленной задачей описатель |
|---|---|
| Детализация задачи | Рассмотрите задачу по разработке с учетом других подобных задач, а также требований к качеству и сценариев, для которых еще не назначены задачи по разработке. Создайте для них задачи |
| Оценка на основе опыта | Проводите оценку с учетом времени выполнения аналогичных задач |
| Балансировка загрузки | Менеджер проекта и бизнес-аналитик определяют приоритеты задач и откладывают выполнение наименее приоритетных из них. Если в результате оценки выясняется, что объем работ превышает возможный уровень для итерации, совместно с менеджером проекта попробуйте изменить приоритеты и перераспределить загрузку |
| Определите способы интеграции | Совместно с другими участниками группы разработки выработайте четкую картину |
Прежде чем начать разработку, нужно настроить среду разработки локальной базы данных. Сначала необходимо извлечь из системы управления исходным кодом нужную версию проекта. Этот проект надо собрать и развернуть на изолированном сервере (
| Извлеките из системы управления версиями требуемую версию проекта базы данных | Определите версию проекта базы данных, с которым вы хотите синхронизироваться |
|---|---|
| Определение изолированного сервера | Выберите сервер баз данных, который вы будете использовать в качестве "песочницы" |
| Компоновка проекта базы данных | Убедитесь, что параметры проекта баз данных настроены на изолированный сервер |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
Следующий шаг - собственно написание кода для задачи по разработке базы данных. Это означает обновление существующих объектов схемы базы данных или создание новых. После реализации очередного пакета изменений его нужно развернуть на изолированном сервере для тестирования.
| Создание новых или обновление существующих объектов схемы | При необходимости создайте новые объекты схемы |
|---|---|
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
С помощью теста модуля проверяется корректность реализации определенного программного компонента. Выполнение тестов модулей при разработке снижает число дефектов, обнаруживаемых на этапе тестирования, и позволяет бороться с регрессом - появлением новых дефектов при исправлении уже выявленных дефектов или при добавлении новых функций. Тесты модулей не являются тестами функций или взаимодействия; их единственное назначение - проверка автономной работы фрагмента кода. Разработчики должны убедиться, что существующие тесты модулей проходят после написания нового кода. Тестирование должно проводиться на протяжении всего проекта - от реализации архитектурных основ в начале до внесения дополнений в конце проекта. При этом все разновидности тестов единообразно выполняются и выявляют дефекты. При тестировании модулей баз данных необходимо перед написанием тестов модулей создать или обновить план генерирования данных, чтобы при тестировании имелись необходимые тестовые данные.
| Определение типа теста модуля | Определите типы разрабатываемых тестов модулей базы данных. Тесты правильной работы ( positive ) проверяют код в нормальном режиме и контролируют корректность результатов. Тесты неправильной работы ( negative ) умышленно некорректно используют код и проверяют его устойчивость и адекватность обработки ошибок |
|---|---|
| Создание или изменение плана генерации тестовых данных | Если плана генерации тестовых данных не существует, создайте его |
| Создание или изменение теста модуля базы данных | Напишите новые тесты модулей для проверки объектов схемы |
| Выполнение теста модуля базы данных | Убедитесь в правильной настройке параметров выполнения теста модуля базы данных |
| Анализ результатов теста | Если тест модуля не прошел по той причине, что был неверным, исправьте его и снова выполните |
| Отладка кода | Исправьте ошибки в программе, относящейся к задаче |
| Выполнение тестов модуля приложения | При итеративной разработке базы данных иногда целесообразно выполнять тесты модулей приложения совместно с тестами модулей базы данных. Поскольку приложение зачастую очень интенсивно обращается к данным, изменения в базе данных могут повлиять на прикладной слой, если их не принимать во внимание. Совместное выполнение тестов приложения и базы данных даст уверенность в том, что проблемы будут замечены заблаговременно |
В процессе рефакторинга кода
| Определение сложности | При добавлении новых функций обратите внимание на те части программы, структура которых стала более сложной |
|---|---|
| Применение рефакторинга | При рефакторинге вносите за раз одно изменение. Измените код и все ссылки на измененную область |
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
| Выполнение тестов модуля базы данных | Выполните тесты модуля, чтобы убедиться в |
Обзор кода применяется для выявления областей, с которыми могут возникнуть проблемы в процессе дальнейшей разработки или тестирования. Обзор кода также дает возможность узнать мнения других разработчиков о рассматриваемом коде. Обзоры кода позволяют участникам, работающим в той же области, следовать прецедентам, созданным предыдущими разработчиками. В таких партнерских встречах требуется присутствие второго знающего коллеги, с которым разработчик должен рассмотреть все изменения, прежде чем зарегистрировать код в системе управления версиями.
| Проверка правильности имен | Имена объектов схемы базы данных должны отражать назначение соответствующих сущностей |
|---|---|
| Проверка адекватности кода | Рассматриваемый код должен соответствовать задаче, для которой он написан. Допустимы только такие изменения кода, которые добавляют или изменяют функции системы |
| | Повторяющийся код должен быть собран в общих функциях |
| Внесение изменений по результатам обзора | Внесите все изменения, запланированные в результате обзора |
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
| Выполнение тестов модуля базы данных | Выполните тесты модуля и убедитесь в отсутствии регресса |
Чтобы приложение было устойчивым и согласованным, необходимо организовать интеграцию изменений в код. Когда код состоит из небольших изменений, каждое из которых соответствует задаче по разработке или исправлению дефекта, его проще поддерживать в стабильном состоянии. Легче найти и изолировать потенциальную проблему. Для состояния сценария или требования к качеству устанавливается значение Resolved (Обработан) и описатель назначается тестировщику.
| Проверка зависимостей | Если задача зависит от других задач, которые еще не завершены, дождитесь, когда они будут интегрированы в систему |
|---|---|
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
| Тестирование и интегрирование других задач по разработке баз данных | Проверьте, что вносимые вами изменения, связанные с исправлением дефекта, реализацией части сценария или требования к качеству, нормально работают совместно с уже интегрированными изменениями |
| Регистрация пакета изменений | Зарегистрируйте измененный код в системе управления версиями исходного кода. Если тест реализован или выполнен не полностью, сохраните весь код как промежуточную версию (shelveset). В противном случае установите признак решенной задачи. В результате описателю будет сопоставлен новый пакет изменений |
| Завершение задачи | Установите для описателя признак Resolved (Обработан) и назначьте сценарий одному из тех тестировщиков, которые писали |
Задача
| Определение подхода к тестированию | Определите контекст проекта |
|---|---|
| Создание теста производительности | Определите назначение теста |
| Создание теста безопасности | Изучите точки входа |
| Создание стрессового теста | Спроектируйте тест |
| Создание нагрузочного теста | Определите назначение нагрузочного теста |
| Выбор и запуск | Выберите, какой тест запускать |
| Документирование дефекта | Идентифицируйте дефект |
| Выполнение исследовательских тестов | Установите продолжительность сеанса |
Подход к тестированию - это документ, определяющий стратегию создания и выполнения тестов. В нем также определены стандарты качества для поставляемого продукта. Подход к тестированию служит отправной точкой для планирования тестов в начале проекта, но продолжает существовать и меняться по ходу проекта. Подход должен описывать различные методики, например тесты, как ручные, так и автоматические. Формулирование подхода к тестированию включает определение контекста теста и его конечной цели (или целей), а также выбор подходящих методик, с учетом целей и в контексте проекта. Перед началом очередной итерации данный документ нужно слегка корректировать, отражая цели тестирования в предстоящей итерации и добавляя описание используемых тестовых данных.
| Определите контекст проекта | Определите риски проекта, а также пользователей, на которых может сказаться их воздействие. Найдите особые ситуации, которые могут повлиять на уровень необходимого тестирования. Например, действующие в предметной области нормы могут влиять на направления тестирования |
|---|---|
| Определение цели теста | Определите цели проекта, достижению которых будет способствовать тест |
| Оценка возможных методов тестирования | Рассмотрите различные инструментальные средства для тестирования |
| Определение показателей тестирования | Совместно с разработчиками определите реалистические пороговые значения, которые будут критериями прохождения теста. Это обязательный показатель |
С помощью теста производительности определяется время реакции приложения и проверяется соответствие требованиям к качеству.
| Определение назначения теста | Необходимо четко сформулировать назначение теста. Например, с помощью теста проверяется отсутствие существенных различий во времени отклика системы для пользователей с различными способами подключения к Интернету |
|---|---|
| Описание конфигурации теста | Определите конфигурацию теста |
| Проектирование теста | Систематизируйте тестируемые события и соответствующие им сценарии. Разделите сценарии на области, критичные и не критичные к производительности. Совместно с архитектором постройте модель производительности, которая будет основой для кодирования |
| Документирование этапов тестирования | Выделите и опишите этапы тестирования, чтобы тестировщики могли единообразно выполнять и интерпретировать тесты. Ошибки на этом шаге могут привести к неверной оценке производительности. Везде, где это возможно, автоматизируйте создание тестовых заданий |
Тесты безопасности или испытания на проникновение (
| Изучение точек входа | Определите точки входа системы и ее функциональных блоков для защиты внутренних объектов. Используйте сведения из модели угроз для определения возможных направлений атак |
|---|---|
| Идентификация проблем | Напишите |
| Использование слабостей защиты | Добавьте |
Стресс-тесты позволяют определить предельные возможности приложения. С их помощью выясняют верхнюю границу, перейдя которую приложение не обеспечивает приемлемого уровня реактивности и полностью прекращает работу. Например, можно дать приложению высокую нагрузку и посмотреть, нет ли утечек памяти и нормально ли освобождаются объекты сборщиком мусора.
Стресс-тесты должны проводиться в каждой итерации. Они являются разновидностью тестов производительности и позволяют проверять экстремальные условия работы приложения, например, когда нагрузка превышает типичную или длится дольше обычного. Стресс-тесты позволяют спрогнозировать
| Определение назначения теста | Назначение стресс-теста должно быть четко сформулировано, наряду с описанием конкретных параметров и условий, таких как предельные значения |
|---|---|
| Проектирование автоматизированного теста | Систематизируйте особенности тестовой среды, условия тестирования, включая предпосылки, число виртуальных пользователей, сценарий и ресурсы. Разберитесь с распределением действий и сценариев |
| Создание теста | Задокументируйте выполняемые пользователем действия. Добавьте проверку корректности получаемых результатов в стрессовых условиях. Чтобы тесты были динамичными, используйте привязку к данным - обращение к таким источникам данных, как SQL Server, Microsoft Excel или Microsoft Access |
Нагрузочный тест является разновидностью теста производительности. Нагрузочные тесты позволяют проверить соответствие приложения требованиям к качеству в условиях нагрузки. С их помощью измеряется производительность приложения в типичных сценариях работы пользователей. Нагрузочные тесты позволяют спрогнозировать
| Определение назначения теста | Назначение нагрузочного теста должно быть четко сформулировано, наряду с описанием конкретных параметров и условий, таких как допустимый диапазон значений |
|---|---|
| Проектирование автоматизированного теста | Систематизируйте особенности тестовой среды, условия тестирования, включая предпосылки, число виртуальных пользователей, сценарий и ресурсы. Разберитесь с распределением действий и сценариев |
| Создание теста | Задокументируйте выполняемые пользователем действия. Добавьте проверку корректности получаемых результатов в стрессовых условиях. Чтобы тесты были динамичными, используйте привязку к данным - обращение к таким источникам данных, как SQL Server, Microsoft Excel или Microsoft Access |
Самый важный момент в тестировании - это собственно выполнение тестов соответствующей сборки. Результаты тестов могут быть совершенно разными: от успешного завершения до полного выхода системы из строя. Нельзя забывать фиксировать результаты тестов в описателе соответствующего сценария или требования к качеству.
| Определение запускаемого теста | Определите тесты, которые нужно выполнить, и присвойте им приоритеты на основе сведений в описателе задачи тестирования, общего плана тестирования и положений документа, определяющего подходы к тестированию |
|---|---|
| Определение конфигурации теста | Установите и настройте тестовую конфигурацию, включая аппаратные средства, программы и тестовые данные |
| Получение сборки | Извлеките сборку из |
| Выполнение теста | Выберите папку с тестом сценария или требования к качеству |
| Анализ результатов теста | Свяжите с результатами теста проверенный сценарий или требование к качеству |
| Закрытие описателя | Если все тесты из задачи тестирования выполнены, закройте описатель данной задачи |
Прежде чем создавать описатель нового дефекта, проверьте, не регистрировалась ли прежде подобная проблема. В противном случае, зафиксируйте все подробности в системе отслеживания дефектов. Необходимо описать последовательность воссоздания проблемы, после чего, в процессе классификации, ей будет назначен приоритет. Опишите дефект как можно подробней - это поможет специалистам определить оптимальный путь его устранения. Каждому открытому дефекту должен быть назначен владелец.
| Проверка повторения дефекта | Прежде чем создавать описатель нового дефекта, проверьте, нет ли описания аналогичного дефекта в базе данных |
|---|---|
| Описание дефекта | Если аналогов у дефекта нет и он может быть воспроизведен, выполните последовательность действий, приводящую к его появлению и подробно обрисуйте происходящее в описателе |
| Назначение дефекта | Определите основную область проблемы. Если затрагивается несколько областей, выберите одну |
Исследовательское тестирование - это способ проверки продукта без определенного набора тестов. Для исследовательского тестирования подходят многие эвристические методы. Среди них - использование собирательных образов, прилагательные и наречия, анализ переменных, поиск диапазона и тестирование различных состояний.
Представленный в данном руководстве эвристический метод описывает, как продукт тестируется с точки зрения собирательного образа с целью сбора новых требований. Для проведения подобного тестирования представьте собирательный образ и выполняйте функции системы, пытаясь достичь определенной цели. Если вы обнаружите новые потенциальные цели или выясните, что существующие функции не удовлетворяют требованиям собирательного образа, добавьте новые или измените существующие сценарии. Ограничивайте сеансы исследовательского тестирования двумя часами.
| Установка продолжительности сеанса | Продолжительность сеанса исследовательского тестирования не должна быть меньше получаса и больше двух часов |
|---|---|
| Удовлетворение потребностей собирательного образа | Выберите собирательный образ из опубликованного списка персонажей |
| Обнаружение новых целей | Проанализируйте трудности, с которыми сталкивается собирательный образ. Если преодолеть их очень сложно, откройте новый дефект или добавьте в список сценариев новый сценарий или требование к качеству |
Типичный сценарий включает как задачи тестирования, так и задачи по разработке. Эти задачи назначаются тестировщикам, которые разрабатывают и прогоняют
| Определение подхода к тестированию | Определите контекст проекта |
|---|---|
| Создание проверочного теста | Определите область тестирования и среду |
| Выбор и запуск | Выберите, какой тест запускать |
| Документирование дефекта | Идентифицируйте дефект |
| Выполнение исследовательских тестов | Установите продолжительность сеанса |
Проверочными тестами исследуют соответствие реализованных функций требованиям сценариев. При проверочном тестировании приложение рассматривается как "черный ящик" и особое внимание уделяется конечным пользователям. Проверочные тесты не должны быть завязаны на проектные решения. Для написания проверочных тестов исследуйте трудности, которые возникнут в различных ситуациях. Не все трудности указаны в сценариях. При проектировании и написании тестовых сценариев для проверочных тестов специалисты рассматривают ситуации, которые могут иметь место в реальной жизни.
| Определение области тестирования и среды | Выделите область, в которой должен выполняться тест. Тесты итерации - это набор автоматических тестовых заданий, запускаемых после проверочных тестов сборки. При этом прохождение этих тестов не означает работоспособность сборки. Заметим, что только автоматические тесты могут быть тестами итерации |
|---|---|
| Выяснение подробностей выполнения теста | Определите тестовые данные, необходимые для |
| Создание тестовых заданий | Создайте для сценария папку с тестами, если ее еще нет |
Операции по созданию проекта базы данных включают в себя разработку первоначального проекта базы данных для использования командой разработчиков. В рамках основного процесса создается автономное представление разрабатываемой базы данных, которое доступно всей команде посредством системы управления исходным кодом. Создание такого проекта позволяет вести независимую итеративную разработку базы данных одновременно несколькими разработчиками в стиле, который уменьшает риски при внесении изменений. Эта операция состоит из таких действий, как создание, конфигурирование и тестирование проекта базы данных.
Зачастую бывает нужно создать управляемую среду разработки для уже существующей базы данных. В этом случае необходимо дополнительное действие - импорт рабочей базы данных в новый проект. Выполнить это можно, только обладая определенными правами в рабочей базе данных, а потому данную задачу стоит поручить администратору базы данных, который обладает необходимыми правами доступа. Мастер проекта базы данных ( Database Project Wizard ) полезен при выполнении действий, описанных ниже, он упрощает создание проекта базы данных. После его завершения, однако, может потребоваться дополнительное конфигурирование.
| Создание проекта базы данных | Изучите поставленную задачу |
|---|---|
| Импорт существующей базы данных | Импортируйте схему существующей базы данных в проект базы данных |
| Установка параметров сборки и развертывания | Укажите сервер, где будет производиться разработка |
| Изменение сгенерированных сценариев | Откорректируйте сценарии, выполняемые перед развертыванием |
| Проверка проекта базы данных | Выполните сборку проекта базы данных |
| Размещение проекта базы данных в службе управления исходным кодом | Поместите проект базы данных в систему управления исходным кодом |
Первым шагом в этой операции является создание проекта базы данных на основе подходящего шаблона. Кроме того, должны быть заданы различные параметры проекта базы данных, поскольку от этого зависит дальнейшая жизнь проекта.
| Изучение поставленной задачи | Просмотрите описатели задач, поставленных перед вами |
|---|---|
| Создание проекта новой базы данных | Решите, какой тип проекта вам нужен - SQL Server 2000 или SQL Server 2005 |
| Конфигурирование свойств проекта | Решите, как будет организован проект базы данных - по типам объектов или схемой |
| Установка необязательных параметров | Сконфигурируйте необязательные параметры базы данных, включая SET-параметры |
Зачастую бывает нужно создать проект базы данных на основе уже существующей базы путем импорта ее схемы. Это позволяет импортировать схему определения объектов и добавить их к автономному проекту базы данных, размещенному в файловой системе, тем самым предоставляя возможность менять их локально внутри проекта.
| Импорт существующей базы данных в новый проект | Укажите соединение с базой данных, из которой будет производиться импорт схемы данных, а также укажите учетную запись с необходимыми полномочиями в ней |
|---|
В течение всего времени разработки базы данных, разработчики будут постоянно, на итеративной основе собирать и разворачивать проект базы данных на своих локальных серверах. Именно поэтому так важно во время первоначального конфигурирования проекта настроить параметры для сборки и установки, задаваемые по умолчанию, которые бы наилучшим образом подходили для среды разработки.
| Выбор сервера, на котором будет производиться тестирование | Это должен быть локальный сервер баз данных, предназначенный для тестирования итеративных изменений |
|---|---|
| Настройка параметров установки | Решите, будет ли база данных при каждой установке автоматически создаваться с нуля, либо на ней будут разворачиваться только выполненные изменения |
Проект базы данных ограничен ее уровнем, а потому не поддерживает напрямую объекты уровня сервера, да и некоторые объекты схемы данных также не поддерживаются проектом напрямую. Однако все эти объекты легко могут быть добавлены в сценарии, запускаемые до и после развертывания базы данных. Поэтому следует при создании проекта внести необходимые изменения в сценарии, добавив туда нужные объекты и выражения SQL.
| Изменение сценария, запускаемого перед установкой | В этот сценарий добавьте учетные записи сервера, тем самым задав соответствие между пользователями и учетными записями |
|---|---|
| Изменение сценария, запускаемого после установки | В этом сценарии выполните настройку прав доступа к объектам схемы, так чтобы они создавались сразу с необходимыми разрешениями: запрет, разрешение или отзыв прав |
После выполнения всех необходимых настроек проекта следует собрать и развернуть его на локальном сервере, чтобы убедиться в его готовности. Это очень важный шаг, помогающий выявить в сценариях пропущенные или неверно заданные
| Сборка проекта базы данных | Выполните сборку проекта базы данных |
|---|---|
| Установка проекта базы данных на локальном сервере для проверки | Установите проект базы данных на локальном сервере |
После проверки проект базы данных можно разместить в службе управления исходным кодом, чтобы он был доступен всей команде.
| Регистрация проекта в службе управления исходным кодом | Убедитесь, что служба управления исходным кодом сконфигурирована правильно |
|---|---|
| Публикация проекта в службе управления исходным кодом | Поместите проект в службу управления исход ным кодом и присвойте этому действию описатель |
| Описатель завершения создания проекта | Завершите задачу по созданию проекта базы данных и назначьте ее менеджеру проекта |
Каждый проект базы данных в конце концов должен быть развернут в рабочей среде. В развертывании проекта базы данных описывается, как администратор баз данных может превратить это в управляемый и предсказуемый процесс. Он заключается в получении правильной версии проекта базы данных и проверке его путем построения сборки, установки и выполнения набора тестов модулей. Администратор баз данных должен понять, какие изменения нужно внести в сгенерированные сценарии. И, наконец, сценарий создания базы данных должен быть запущен на рабочем сервере с последующей проверкой базы данных.
| Синхронизация проекта базы данных | Изучите назначенную вам задачу по развертыванию базы данных |
|---|---|
| Проверка сборки | Выполните сборку проекта |
| Выполнение тестирования модулей базы данных | Выполните тестирование модулей базы данных |
| Анализ изменений | В службе управления исходным кодом просмотрите историю изменений, выполненных после последней установки |
| Разработка сценария создания базы данных | Определите соединение к базе данных, где будет выполняться установка, а также необходимые свойства создания |
| Резервное копирование рабочей базы данных | Создайте резервную копию рабочей базы данных |
| Развертывание на тестовом сервере | Выполните сценарий создания базы данных на тестовом сервере, сконфигурированном как рабочий сервер |
| Установка базы данных | Выполните сценарий создания базы данных на рабочем сервере |
Перед развертыванием администратору баз данных следует синхронизировать локальную базу данных с требуемой версией.
| Изучение поставленной задачи в рамках работ по развертыванию | Просмотрите описатель задачи, поставленной перед вами в рамках работ по развертыванию |
|---|---|
| Синхронизация проекта базы данных с требуемой версией | Определите версию, с которой будет синхронизирован проект базы данных |
Перед установкой проекта базы данных на рабочий сервер его важно сначала собрать и установить на локальном сервере, чтобы проверить качество сборки.
| Сборка проекта базы данных | Выполните сборку проекта |
|---|---|
| Установка проекта базы данных на тестовый сервер | Разверните проект базы данных на локальном тестовом сервере |
Перед установкой необходимо выполнить набор тестов модулей проекта базы данных, чтобы убедиться в отсутствии внесенных в него дефектов.
| Выполнение тестирования модулей базы данных | Убедитесь в правильном конфигурировании исполняемых тестов модулей |
|---|---|
| Анализ результатов тестирования | Если тесты завершились неудачно по причине содержащихся в них ошибок, создайте описание дефекта и передайте его владельцу теста модуля для изучения и исправления |
Администратору баз данных важно точно понимать, какие изменения предполагается передавать на сервер баз данных. Определить их он может либо просмотром на сервисе управления исходным кодом истории изменений с момента предыдущей установки, либо сравнением схем данных между рабочей и развертываемой базой данных.
| Просмотр истории изменений с момента предыдущей установки при помощи службы управления исходным кодом | Воспользуйтесь историей службы управления исходным кодом для просмотра всех изменений, выполненных после последней установки проекта базы данных |
|---|---|
| Сравнение схемы данных для анализа различий между рабочим сервером и проектом | Создайте сеанс сравнения схем баз данных для выявления различий между базой данных на рабочем сервере и проектом |
| Просмотр файла | Просмотрите файл |
Сценарий создания базы данных должен быть сгенерирован и при необходимости изменен. В качестве места установки в проекте указывается рабочий сервер. Затем генерируется сценарий. Для учета специфических особенностей окружения в полученный сценарий могут быть внесены изменения. Эти изменения могут включать команды переноса данных.
| Задание соединения к серверу, на котором будет выполняться создание, а также задание дополнительных параметров | Сконфигурируйте параметры проекта базы данных, задав соединение к серверу, где будет создаваться база данных, а также связанные с этим свойства |
|---|---|
| Генерация сценария создания базы данных | Сгенерируйте сценарий создания базы данных |
| Изменение сценария создания базы данных | Просмотрите полученный сценарий создания базы данных и убедитесь, что он выполняет ожидаемые действия, необходимые для синхронизации исходного проекта с рабочей базой данных |
Перед развертыванием базы данных необходимо сделать резервную копию существующей базы данных. Это чрезвычайно важно, так как дает возможность вернуть базу данных в исходное состояние в случае каких-либо ошибок.
| Создание резервной копии рабочей базы данных | Непосредственно перед развертыванием создайте полную резервную копию рабочей базы данных, используя стандартные технологии резервирования, применяемые в вашей организации |
|---|
Перед установкой на рабочий сервер можно выполнить необязательный шаг - протестировать развертывание на тестовом сервере, имеющем аналогичную конфигурацию. При этом выполняются все действия, которые будут выполняться при реальном развертывании - запуск сценариев и проверка их результатов.
| Выполнение на тестовом сервере сценариев развертывания | Перед установкой на рабочий сервер запустите сценарии развертывания в редакторе T-SQL на тестовом сервере, чтобы убедиться в их успешности |
|---|---|
| Сравнение схем данных для проверки развертывания | Создайте сеанс сравнения схем данных для просмотра различий между базой данных проекта и базой данных на тестовом сервере |
Теперь все готово для установки базы данных на рабочем сервере. Установка выполняется запуском на сервере сценария создания базы данных с последующей проверкой результатов.
| Запуск сценария создания базы данных на рабочем сервере | Используя редактор T-SQL, выполните сценарий создания базы данных на рабочем сервере |
|---|---|
| Сравнение схем данных для проверки развертывания | Создайте сеанс сравнения схем данных для просмотра различий между базой данных проекта и рабочей базой данных |
| Закрытие описателя установки | Отметьте задачу установки как выполненную |
Задача по разработке - небольшая часть деятельности разработчика, связанная с требованием к качеству или сценарием. В результате реализации задачи по разработке к системе добавляется новая функция. После завершения задачи по разработке необходимо провести тестирование модулей, обзор кода и его анализ, интеграцию кода и регистрацию его в базе кода. Затем сценарий или требование к качеству передается на тестирование.
| Оценка задачи по разработке | Оцените длительность задачи по разработке |
|---|---|
| Создание или изменение теста модуля | Определите тип теста модуля |
| Написание программы | Выберите компонент |
| Анализ кода | Определите правила приложения |
| Выполнение теста модуля | Выберите тест модуля из набора |
| Рефакторинг кода | Определите сложность |
| Обзор кода | Проверьте правильность имен |
| Интеграция изменений | Проверьте зависимости |
Оценка стоимости задачи по разработке помогает ограничить набор реализуемых функций, определить расписание и распределить приоритеты. Оценку всех задач по разработке и решение всех связанных с этим проблем необходимо выполнить до совещания по планированию итерации. Если общая стоимость задач по разработке превышает затраты на итерацию, задача должна быть отложена или переназначена. После утверждения задачи за ее оценку отвечает разработчик.
| Оценка на основе опыта | Проводите оценку с учетом времени выполнения аналогичных задач |
|---|---|
| Балансировка загрузки | Если в результате оценки выясняется, что объем работ превышает возможный уровень для итерации, совместно с менеджером проекта попробуйте перераспределить загрузку или перенести задачу на другую итерацию |
| Детализация задачи | Рассмотрите задачу по разработке с учетом других подобных задач, а также требований к качеству и сценариев, для которых еще не назначены задачи по разработке. Создайте для них задачи |
| Определите способы интеграции | Совместно с другими участниками группы разработки выработайте четкую картину |
Создайте код, определите измененные области, напишите тесты модулей, проведите обзор кода и внесите в него необходимые изменения, в завершение зарегистрируйте код на сервере управления версиями. Вам также может потребоваться выполнить отладку, рефакторинг и использовать промежуточные версии исходного кода. После того как код написан, необходимо выполнить его обзор и убедиться, что его качество соответствует требованиям и принятым стандартам. Созданный код не должен оказывать вредных побочных эффектов на другие части приложения.
| Выбор компонента для кода | Сопоставьте задачу с компонентом, в котором реализуется соответствующая функциональность |
|---|---|
| Создание новых классов или методов | С помощью диаграммы классов создайте классы, необходимые для реализации данной функциональности |
| Реализация алгоритма метода | Извлеките существующие классы, которые нужно изменить, из системы управления версиями |
Анализ кода - это процесс проверки обычного или управляемого кода .NET на предмет соответствия руководящим принципам по разработке. Для управляемого кода .NET в процессе анализа проверяется соответствие генерируемых сборок рекомендациям Microsoft .NET Framework Design Guide-lines. Предлагается автоматическая проверка сборок на наличие более чем 200 видов дефектов, таких как нарушение соглашений по именованию, ошибки в конструкции библиотек, а также проблемы локализации, безопасности и производительности. Задача анализа кода при работе с новыми базами кода - обеспечить отсутствие дефектов. Для существующих баз с большим числом правил формирования предупреждений цель состоит в минимизации числа предупреждений в каждой категории.
| Определение приемлемых правил | Выберите приемлемые правила для данной категории приложений |
|---|---|
| Обеспечение отсутствия дефектов | Проверьте код на соответствие правилам |
| Уменьшение числа дефектов по категориям | Для существующих баз кода с большим числом проблем с соответствием правилам определите базовые показатели уровня проблем. При использовании автоматизации, определите число предупреждений в существующей базе кода |
Задача по разработке базы данных - это деятельность разработчика, связанная с требованием к качеству или сценарием. В результате реализации задачи по разработке базы данных к системе добавляется новая функция. После завершения этой задачи необходимо провести тестирование модулей, обзор кода и его анализ, интеграцию кода и регистрацию его в существующей базе кода. Затем сценарий или требование к качеству передается на тестирование. Описанный здесь изолированный
| Оценка задачи по разработке базы данных | Проанализируйте поставленную задачу |
|---|---|
| Обновите локальную среду проекта | Извлеките из системы управления версиями требуемую версию проекта базы данных |
| Кодирование | Создайте новые или обновите существующие объекты схемы |
| Выполнение теста модуля | Определите тип теста модуля базы данных |
| Рефакторинг кода | Определите сложность |
| Обзор кода | Проверьте правильность имен |
| Интеграция изменений | Проверьте зависимости |
Оценка стоимости задач по разработке базы данных помогает ограничить набор реализуемых функций, определить расписание и распределить приоритеты. Оценка всех задач по разработке базы данных выполняется на совещании по планированию итерации. Если общая стоимость задач по разработке превышает затраты на итерацию, задача должна быть отложена или переназначена. Менеджер проекта и бизнес-аналитик определяют приоритеты задач и откладывают выполнение наименее приоритетных из них. После утверждения задачи за ее оценку отвечает разработчик. Прежде чем приступать к оценке задачи по разработке базы данных, разработчик баз данных должен пересмотреть назначенную ему задачу, разобраться в требованиях и обсудить оценку с другими разработчиками баз данных. В результате все разработчики будут иметь единое представление о задаче.
| Анализ поставленной задачи | Найдите связанный с поставленной задачей описатель |
|---|---|
| Детализация задачи | Рассмотрите задачу по разработке с учетом других подобных задач, а также требований к качеству и сценариев, для которых еще не назначены задачи по разработке. Создайте для них задачи |
| Оценка на основе опыта | Проводите оценку с учетом времени выполнения аналогичных задач |
| Балансировка загрузки | Менеджер проекта и бизнес-аналитик определяют приоритеты задач и откладывают выполнение наименее приоритетных из них. Если в результате оценки выясняется, что объем работ превышает возможный уровень для итерации, совместно с менеджером проекта попробуйте изменить приоритеты и перераспределить загрузку |
| Определите способы интеграции | Совместно с другими участниками группы разработки выработайте четкую картину |
Прежде чем начать разработку, нужно настроить среду разработки локальной базы данных. Сначала необходимо извлечь из системы управления исходным кодом нужную версию проекта. Этот проект надо собрать и развернуть на изолированном сервере (
| Извлеките из системы управления версиями требуемую версию проекта базы данных | Определите версию проекта базы данных, с которым вы хотите синхронизироваться |
|---|---|
| Определение изолированного сервера | Выберите сервер баз данных, который вы будете использовать в качестве "песочницы" |
| Компоновка проекта базы данных | Убедитесь, что параметры проекта баз данных настроены на изолированный сервер |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
Следующий шаг - собственно написание кода для задачи по разработке базы данных. Это означает обновление существующих объектов схемы базы данных или создание новых. После реализации очередного пакета изменений его нужно развернуть на изолированном сервере для тестирования.
| Создание новых или обновление существующих объектов схемы | При необходимости создайте новые объекты схемы |
|---|---|
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
С помощью теста модуля проверяется корректность реализации определенного программного компонента. Выполнение тестов модулей при разработке снижает число дефектов, обнаруживаемых на этапе тестирования, и позволяет бороться с регрессом - появлением новых дефектов при исправлении уже выявленных дефектов или при добавлении новых функций. Тесты модулей не являются тестами функций или взаимодействия; их единственное назначение - проверка автономной работы фрагмента кода. Разработчики должны убедиться, что существующие тесты модулей проходят после написания нового кода. Тестирование должно проводиться на протяжении всего проекта - от реализации архитектурных основ в начале до внесения дополнений в конце проекта. При этом все разновидности тестов единообразно выполняются и выявляют дефекты. При тестировании модулей баз данных необходимо перед написанием тестов модулей создать или обновить план генерирования данных, чтобы при тестировании имелись необходимые тестовые данные.
| Определение типа теста модуля | Определите типы разрабатываемых тестов модулей базы данных. Тесты правильной работы ( positive ) проверяют код в нормальном режиме и контролируют корректность результатов. Тесты неправильной работы ( negative ) умышленно некорректно используют код и проверяют его устойчивость и адекватность обработки ошибок |
|---|---|
| Создание или изменение плана генерации тестовых данных | Если плана генерации тестовых данных не существует, создайте его |
| Создание или изменение теста модуля базы данных | Напишите новые тесты модулей для проверки объектов схемы |
| Выполнение теста модуля базы данных | Убедитесь в правильной настройке параметров выполнения теста модуля базы данных |
| Анализ результатов теста | Если тест модуля не прошел по той причине, что был неверным, исправьте его и снова выполните |
| Отладка кода | Исправьте ошибки в программе, относящейся к задаче |
| Выполнение тестов модуля приложения | При итеративной разработке базы данных иногда целесообразно выполнять тесты модулей приложения совместно с тестами модулей базы данных. Поскольку приложение зачастую очень интенсивно обращается к данным, изменения в базе данных могут повлиять на прикладной слой, если их не принимать во внимание. Совместное выполнение тестов приложения и базы данных даст уверенность в том, что проблемы будут замечены заблаговременно |
В процессе рефакторинга кода
| Определение сложности | При добавлении новых функций обратите внимание на те части программы, структура которых стала более сложной |
|---|---|
| Применение рефакторинга | При рефакторинге вносите за раз одно изменение. Измените код и все ссылки на измененную область |
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
| Выполнение тестов модуля базы данных | Выполните тесты модуля, чтобы убедиться в |
Обзор кода применяется для выявления областей, с которыми могут возникнуть проблемы в процессе дальнейшей разработки или тестирования. Обзор кода также дает возможность узнать мнения других разработчиков о рассматриваемом коде. Обзоры кода позволяют участникам, работающим в той же области, следовать прецедентам, созданным предыдущими разработчиками. В таких партнерских встречах требуется присутствие второго знающего коллеги, с которым разработчик должен рассмотреть все изменения, прежде чем зарегистрировать код в системе управления версиями.
| Проверка правильности имен | Имена объектов схемы базы данных должны отражать назначение соответствующих сущностей |
|---|---|
| Проверка адекватности кода | Рассматриваемый код должен соответствовать задаче, для которой он написан. Допустимы только такие изменения кода, которые добавляют или изменяют функции системы |
| | Повторяющийся код должен быть собран в общих функциях |
| Внесение изменений по результатам обзора | Внесите все изменения, запланированные в результате обзора |
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
| Выполнение тестов модуля базы данных | Выполните тесты модуля и убедитесь в отсутствии регресса |
Чтобы приложение было устойчивым и согласованным, необходимо организовать интеграцию изменений в код. Когда код состоит из небольших изменений, каждое из которых соответствует задаче по разработке или исправлению дефекта, его проще поддерживать в стабильном состоянии. Легче найти и изолировать потенциальную проблему. Для состояния сценария или требования к качеству устанавливается значение Resolved (Обработан) и описатель назначается тестировщику.
| Проверка зависимостей | Если задача зависит от других задач, которые еще не завершены, дождитесь, когда они будут интегрированы в систему |
|---|---|
| Сборка проекта базы данных | Соберите проект базы данных |
| Развертывание проекта баз данных на изолированном сервере | Разверните проект баз данных на изолированном сервере |
| Тестирование и интегрирование других задач по разработке баз данных | Проверьте, что вносимые вами изменения, связанные с исправлением дефекта, реализацией части сценария или требования к качеству, нормально работают совместно с уже интегрированными изменениями |
| Регистрация пакета изменений | Зарегистрируйте измененный код в системе управления версиями исходного кода. Если тест реализован или выполнен не полностью, сохраните весь код как промежуточную версию (shelveset). В противном случае установите признак решенной задачи. В результате описателю будет сопоставлен новый пакет изменений |
| Завершение задачи | Установите для описателя признак Resolved (Обработан) и назначьте сценарий одному из тех тестировщиков, которые писали |
Задача
| Определение подхода к тестированию | Определите контекст проекта |
|---|---|
| Создание теста производительности | Определите назначение теста |
| Создание теста безопасности | Изучите точки входа |
| Создание стрессового теста | Спроектируйте тест |
| Создание нагрузочного теста | Определите назначение нагрузочного теста |
| Выбор и запуск | Выберите, какой тест запускать |
| Документирование дефекта | Идентифицируйте дефект |
| Выполнение исследовательских тестов | Установите продолжительность сеанса |
Подход к тестированию - это документ, определяющий стратегию создания и выполнения тестов. В нем также определены стандарты качества для поставляемого продукта. Подход к тестированию служит отправной точкой для планирования тестов в начале проекта, но продолжает существовать и меняться по ходу проекта. Подход должен описывать различные методики, например тесты, как ручные, так и автоматические. Формулирование подхода к тестированию включает определение контекста теста и его конечной цели (или целей), а также выбор подходящих методик, с учетом целей и в контексте проекта. Перед началом очередной итерации данный документ нужно слегка корректировать, отражая цели тестирования в предстоящей итерации и добавляя описание используемых тестовых данных.
| Определите контекст проекта | Определите риски проекта, а также пользователей, на которых может сказаться их воздействие. Найдите особые ситуации, которые могут повлиять на уровень необходимого тестирования. Например, действующие в предметной области нормы могут влиять на направления тестирования |
|---|---|
| Определение цели теста | Определите цели проекта, достижению которых будет способствовать тест |
| Оценка возможных методов тестирования | Рассмотрите различные инструментальные средства для тестирования |
| Определение показателей тестирования | Совместно с разработчиками определите реалистические пороговые значения, которые будут критериями прохождения теста. Это обязательный показатель |
С помощью теста производительности определяется время реакции приложения и проверяется соответствие требованиям к качеству.
| Определение назначения теста | Необходимо четко сформулировать назначение теста. Например, с помощью теста проверяется отсутствие существенных различий во времени отклика системы для пользователей с различными способами подключения к Интернету |
|---|---|
| Описание конфигурации теста | Определите конфигурацию теста |
| Проектирование теста | Систематизируйте тестируемые события и соответствующие им сценарии. Разделите сценарии на области, критичные и не критичные к производительности. Совместно с архитектором постройте модель производительности, которая будет основой для кодирования |
| Документирование этапов тестирования | Выделите и опишите этапы тестирования, чтобы тестировщики могли единообразно выполнять и интерпретировать тесты. Ошибки на этом шаге могут привести к неверной оценке производительности. Везде, где это возможно, автоматизируйте создание тестовых заданий |
Тесты безопасности или испытания на проникновение (
| Изучение точек входа | Определите точки входа системы и ее функциональных блоков для защиты внутренних объектов. Используйте сведения из модели угроз для определения возможных направлений атак |
|---|---|
| Идентификация проблем | Напишите |
| Использование слабостей защиты | Добавьте |
Стресс-тесты позволяют определить предельные возможности приложения. С их помощью выясняют верхнюю границу, перейдя которую приложение не обеспечивает приемлемого уровня реактивности и полностью прекращает работу. Например, можно дать приложению высокую нагрузку и посмотреть, нет ли утечек памяти и нормально ли освобождаются объекты сборщиком мусора.
Стресс-тесты должны проводиться в каждой итерации. Они являются разновидностью тестов производительности и позволяют проверять экстремальные условия работы приложения, например, когда нагрузка превышает типичную или длится дольше обычного. Стресс-тесты позволяют спрогнозировать
| Определение назначения теста | Назначение стресс-теста должно быть четко сформулировано, наряду с описанием конкретных параметров и условий, таких как предельные значения |
|---|---|
| Проектирование автоматизированного теста | Систематизируйте особенности тестовой среды, условия тестирования, включая предпосылки, число виртуальных пользователей, сценарий и ресурсы. Разберитесь с распределением действий и сценариев |
| Создание теста | Задокументируйте выполняемые пользователем действия. Добавьте проверку корректности получаемых результатов в стрессовых условиях. Чтобы тесты были динамичными, используйте привязку к данным - обращение к таким источникам данных, как SQL Server, Microsoft Excel или Microsoft Access |
Нагрузочный тест является разновидностью теста производительности. Нагрузочные тесты позволяют проверить соответствие приложения требованиям к качеству в условиях нагрузки. С их помощью измеряется производительность приложения в типичных сценариях работы пользователей. Нагрузочные тесты позволяют спрогнозировать
| Определение назначения теста | Назначение нагрузочного теста должно быть четко сформулировано, наряду с описанием конкретных параметров и условий, таких как допустимый диапазон значений |
|---|---|
| Проектирование автоматизированного теста | Систематизируйте особенности тестовой среды, условия тестирования, включая предпосылки, число виртуальных пользователей, сценарий и ресурсы. Разберитесь с распределением действий и сценариев |
| Создание теста | Задокументируйте выполняемые пользователем действия. Добавьте проверку корректности получаемых результатов в стрессовых условиях. Чтобы тесты были динамичными, используйте привязку к данным - обращение к таким источникам данных, как SQL Server, Microsoft Excel или Microsoft Access |
Самый важный момент в тестировании - это собственно выполнение тестов соответствующей сборки. Результаты тестов могут быть совершенно разными: от успешного завершения до полного выхода системы из строя. Нельзя забывать фиксировать результаты тестов в описателе соответствующего сценария или требования к качеству.
| Определение запускаемого теста | Определите тесты, которые нужно выполнить, и присвойте им приоритеты на основе сведений в описателе задачи тестирования, общего плана тестирования и положений документа, определяющего подходы к тестированию |
|---|---|
| Определение конфигурации теста | Установите и настройте тестовую конфигурацию, включая аппаратные средства, программы и тестовые данные |
| Получение сборки | Извлеките сборку из |
| Выполнение теста | Выберите папку с тестом сценария или требования к качеству |
| Анализ результатов теста | Свяжите с результатами теста проверенный сценарий или требование к качеству |
| Закрытие описателя | Если все тесты из задачи тестирования выполнены, закройте описатель данной задачи |
Прежде чем создавать описатель нового дефекта, проверьте, не регистрировалась ли прежде подобная проблема. В противном случае, зафиксируйте все подробности в системе отслеживания дефектов. Необходимо описать последовательность воссоздания проблемы, после чего, в процессе классификации, ей будет назначен приоритет. Опишите дефект как можно подробней - это поможет специалистам определить оптимальный путь его устранения. Каждому открытому дефекту должен быть назначен владелец.
| Проверка повторения дефекта | Прежде чем создавать описатель нового дефекта, проверьте, нет ли описания аналогичного дефекта в базе данных |
|---|---|
| Описание дефекта | Если аналогов у дефекта нет и он может быть воспроизведен, выполните последовательность действий, приводящую к его появлению и подробно обрисуйте происходящее в описателе |
| Назначение дефекта | Определите основную область проблемы. Если затрагивается несколько областей, выберите одну |
Исследовательское тестирование - это способ проверки продукта без определенного набора тестов. Для исследовательского тестирования подходят многие эвристические методы. Среди них - использование собирательных образов, прилагательные и наречия, анализ переменных, поиск диапазона и тестирование различных состояний.
Представленный в данном руководстве эвристический метод описывает, как продукт тестируется с точки зрения собирательного образа с целью сбора новых требований. Для проведения подобного тестирования представьте собирательный образ и выполняйте функции системы, пытаясь достичь определенной цели. Если вы обнаружите новые потенциальные цели или выясните, что существующие функции не удовлетворяют требованиям собирательного образа, добавьте новые или измените существующие сценарии. Ограничивайте сеансы исследовательского тестирования двумя часами.
| Установка продолжительности сеанса | Продолжительность сеанса исследовательского тестирования не должна быть меньше получаса и больше двух часов |
|---|---|
| Удовлетворение потребностей собирательного образа | Выберите собирательный образ из опубликованного списка персонажей |
| Обнаружение новых целей | Проанализируйте трудности, с которыми сталкивается собирательный образ. Если преодолеть их очень сложно, откройте новый дефект или добавьте в список сценариев новый сценарий или требование к качеству |
Типичный сценарий включает как задачи тестирования, так и задачи по разработке. Эти задачи назначаются тестировщикам, которые разрабатывают и прогоняют
| Определение подхода к тестированию | Определите контекст проекта |
|---|---|
| Создание проверочного теста | Определите область тестирования и среду |
| Выбор и запуск | Выберите, какой тест запускать |
| Документирование дефекта | Идентифицируйте дефект |
| Выполнение исследовательских тестов | Установите продолжительность сеанса |
Проверочными тестами исследуют соответствие реализованных функций требованиям сценариев. При проверочном тестировании приложение рассматривается как "черный ящик" и особое внимание уделяется конечным пользователям. Проверочные тесты не должны быть завязаны на проектные решения. Для написания проверочных тестов исследуйте трудности, которые возникнут в различных ситуациях. Не все трудности указаны в сценариях. При проектировании и написании тестовых сценариев для проверочных тестов специалисты рассматривают ситуации, которые могут иметь место в реальной жизни.
| Определение области тестирования и среды | Выделите область, в которой должен выполняться тест. Тесты итерации - это набор автоматических тестовых заданий, запускаемых после проверочных тестов сборки. При этом прохождение этих тестов не означает работоспособность сборки. Заметим, что только автоматические тесты могут быть тестами итерации |
|---|---|
| Выяснение подробностей выполнения теста | Определите тестовые данные, необходимые для |
| Создание тестовых заданий | Создайте для сценария папку с тестами, если ее еще нет |
Операции по созданию проекта базы данных включают в себя разработку первоначального проекта базы данных для использования командой разработчиков. В рамках основного процесса создается автономное представление разрабатываемой базы данных, которое доступно всей команде посредством системы управления исходным кодом. Создание такого проекта позволяет вести независимую итеративную разработку базы данных одновременно несколькими разработчиками в стиле, который уменьшает риски при внесении изменений. Эта операция состоит из таких действий, как создание, конфигурирование и тестирование проекта базы данных.
Зачастую бывает нужно создать управляемую среду разработки для уже существующей базы данных. В этом случае необходимо дополнительное действие - импорт рабочей базы данных в новый проект. Выполнить это можно, только обладая определенными правами в рабочей базе данных, а потому данную задачу стоит поручить администратору базы данных, который обладает необходимыми правами доступа. Мастер проекта базы данных ( Database Project Wizard ) полезен при выполнении действий, описанных ниже, он упрощает создание проекта базы данных. После его завершения, однако, может потребоваться дополнительное конфигурирование.
| Создание проекта базы данных | Изучите поставленную задачу |
|---|---|
| Импорт существующей базы данных | Импортируйте схему существующей базы данных в проект базы данных |
| Установка параметров сборки и развертывания | Укажите сервер, где будет производиться разработка |
| Изменение сгенерированных сценариев | Откорректируйте сценарии, выполняемые перед развертыванием |
| Проверка проекта базы данных | Выполните сборку проекта базы данных |
| Размещение проекта базы данных в службе управления исходным кодом | Поместите проект базы данных в систему управления исходным кодом |
Первым шагом в этой операции является создание проекта базы данных на основе подходящего шаблона. Кроме того, должны быть заданы различные параметры проекта базы данных, поскольку от этого зависит дальнейшая жизнь проекта.
| Изучение поставленной задачи | Просмотрите описатели задач, поставленных перед вами |
|---|---|
| Создание проекта новой базы данных | Решите, какой тип проекта вам нужен - SQL Server 2000 или SQL Server 2005 |
| Конфигурирование свойств проекта | Решите, как будет организован проект базы данных - по типам объектов или схемой |
| Установка необязательных параметров | Сконфигурируйте необязательные параметры базы данных, включая SET-параметры |
Зачастую бывает нужно создать проект базы данных на основе уже существующей базы путем импорта ее схемы. Это позволяет импортировать схему определения объектов и добавить их к автономному проекту базы данных, размещенному в файловой системе, тем самым предоставляя возможность менять их локально внутри проекта.
| Импорт существующей базы данных в новый проект | Укажите соединение с базой данных, из которой будет производиться импорт схемы данных, а также укажите учетную запись с необходимыми полномочиями в ней |
|---|
В течение всего времени разработки базы данных, разработчики будут постоянно, на итеративной основе собирать и разворачивать проект базы данных на своих локальных серверах. Именно поэтому так важно во время первоначального конфигурирования проекта настроить параметры для сборки и установки, задаваемые по умолчанию, которые бы наилучшим образом подходили для среды разработки.
| Выбор сервера, на котором будет производиться тестирование | Это должен быть локальный сервер баз данных, предназначенный для тестирования итеративных изменений |
|---|---|
| Настройка параметров установки | Решите, будет ли база данных при каждой установке автоматически создаваться с нуля, либо на ней будут разворачиваться только выполненные изменения |
Проект базы данных ограничен ее уровнем, а потому не поддерживает напрямую объекты уровня сервера, да и некоторые объекты схемы данных также не поддерживаются проектом напрямую. Однако все эти объекты легко могут быть добавлены в сценарии, запускаемые до и после развертывания базы данных. Поэтому следует при создании проекта внести необходимые изменения в сценарии, добавив туда нужные объекты и выражения SQL.
| Изменение сценария, запускаемого перед установкой | В этот сценарий добавьте учетные записи сервера, тем самым задав соответствие между пользователями и учетными записями |
|---|---|
| Изменение сценария, запускаемого после установки | В этом сценарии выполните настройку прав доступа к объектам схемы, так чтобы они создавались сразу с необходимыми разрешениями: запрет, разрешение или отзыв прав |
После выполнения всех необходимых настроек проекта следует собрать и развернуть его на локальном сервере, чтобы убедиться в его готовности. Это очень важный шаг, помогающий выявить в сценариях пропущенные или неверно заданные
| Сборка проекта базы данных | Выполните сборку проекта базы данных |
|---|---|
| Установка проекта базы данных на локальном сервере для проверки | Установите проект базы данных на локальном сервере |
После проверки проект базы данных можно разместить в службе управления исходным кодом, чтобы он был доступен всей команде.
| Регистрация проекта в службе управления исходным кодом | Убедитесь, что служба управления исходным кодом сконфигурирована правильно |
|---|---|
| Публикация проекта в службе управления исходным кодом | Поместите проект в службу управления исход ным кодом и присвойте этому действию описатель |
| Описатель завершения создания проекта | Завершите задачу по созданию проекта базы данных и назначьте ее менеджеру проекта |
Каждый проект базы данных в конце концов должен быть развернут в рабочей среде. В развертывании проекта базы данных описывается, как администратор баз данных может превратить это в управляемый и предсказуемый процесс. Он заключается в получении правильной версии проекта базы данных и проверке его путем построения сборки, установки и выполнения набора тестов модулей. Администратор баз данных должен понять, какие изменения нужно внести в сгенерированные сценарии. И, наконец, сценарий создания базы данных должен быть запущен на рабочем сервере с последующей проверкой базы данных.
| Синхронизация проекта базы данных | Изучите назначенную вам задачу по развертыванию базы данных |
|---|---|
| Проверка сборки | Выполните сборку проекта |
| Выполнение тестирования модулей базы данных | Выполните тестирование модулей базы данных |
| Анализ изменений | В службе управления исходным кодом просмотрите историю изменений, выполненных после последней установки |
| Разработка сценария создания базы данных | Определите соединение к базе данных, где будет выполняться установка, а также необходимые свойства создания |
| Резервное копирование рабочей базы данных | Создайте резервную копию рабочей базы данных |
| Развертывание на тестовом сервере | Выполните сценарий создания базы данных на тестовом сервере, сконфигурированном как рабочий сервер |
| Установка базы данных | Выполните сценарий создания базы данных на рабочем сервере |
Перед развертыванием администратору баз данных следует синхронизировать локальную базу данных с требуемой версией.
| Изучение поставленной задачи в рамках работ по развертыванию | Просмотрите описатель задачи, поставленной перед вами в рамках работ по развертыванию |
|---|---|
| Синхронизация проекта базы данных с требуемой версией | Определите версию, с которой будет синхронизирован проект базы данных |
Перед установкой проекта базы данных на рабочий сервер его важно сначала собрать и установить на локальном сервере, чтобы проверить качество сборки.
| Сборка проекта базы данных | Выполните сборку проекта |
|---|---|
| Установка проекта базы данных на тестовый сервер | Разверните проект базы данных на локальном тестовом сервере |
Перед установкой необходимо выполнить набор тестов модулей проекта базы данных, чтобы убедиться в отсутствии внесенных в него дефектов.
| Выполнение тестирования модулей базы данных | Убедитесь в правильном конфигурировании исполняемых тестов модулей |
|---|---|
| Анализ результатов тестирования | Если тесты завершились неудачно по причине содержащихся в них ошибок, создайте описание дефекта и передайте его владельцу теста модуля для изучения и исправления |
Администратору баз данных важно точно понимать, какие изменения предполагается передавать на сервер баз данных. Определить их он может либо просмотром на сервисе управления исходным кодом истории изменений с момента предыдущей установки, либо сравнением схем данных между рабочей и развертываемой базой данных.
| Просмотр истории изменений с момента предыдущей установки при помощи службы управления исходным кодом | Воспользуйтесь историей службы управления исходным кодом для просмотра всех изменений, выполненных после последней установки проекта базы данных |
|---|---|
| Сравнение схемы данных для анализа различий между рабочим сервером и проектом | Создайте сеанс сравнения схем баз данных для выявления различий между базой данных на рабочем сервере и проектом |
| Просмотр файла | Просмотрите файл |
Сценарий создания базы данных должен быть сгенерирован и при необходимости изменен. В качестве места установки в проекте указывается рабочий сервер. Затем генерируется сценарий. Для учета специфических особенностей окружения в полученный сценарий могут быть внесены изменения. Эти изменения могут включать команды переноса данных.
| Задание соединения к серверу, на котором будет выполняться создание, а также задание дополнительных параметров | Сконфигурируйте параметры проекта базы данных, задав соединение к серверу, где будет создаваться база данных, а также связанные с этим свойства |
|---|---|
| Генерация сценария создания базы данных | Сгенерируйте сценарий создания базы данных |
| Изменение сценария создания базы данных | Просмотрите полученный сценарий создания базы данных и убедитесь, что он выполняет ожидаемые действия, необходимые для синхронизации исходного проекта с рабочей базой данных |
Перед развертыванием базы данных необходимо сделать резервную копию существующей базы данных. Это чрезвычайно важно, так как дает возможность вернуть базу данных в исходное состояние в случае каких-либо ошибок.
| Создание резервной копии рабочей базы данных | Непосредственно перед развертыванием создайте полную резервную копию рабочей базы данных, используя стандартные технологии резервирования, применяемые в вашей организации |
|---|
Перед установкой на рабочий сервер можно выполнить необязательный шаг - протестировать развертывание на тестовом сервере, имеющем аналогичную конфигурацию. При этом выполняются все действия, которые будут выполняться при реальном развертывании - запуск сценариев и проверка их результатов.
| Выполнение на тестовом сервере сценариев развертывания | Перед установкой на рабочий сервер запустите сценарии развертывания в редакторе T-SQL на тестовом сервере, чтобы убедиться в их успешности |
|---|---|
| Сравнение схем данных для проверки развертывания | Создайте сеанс сравнения схем данных для просмотра различий между базой данных проекта и базой данных на тестовом сервере |
Теперь все готово для установки базы данных на рабочем сервере. Установка выполняется запуском на сервере сценария создания базы данных с последующей проверкой результатов.
| Запуск сценария создания базы данных на рабочем сервере | Используя редактор T-SQL, выполните сценарий создания базы данных на рабочем сервере |
|---|---|
| Сравнение схем данных для проверки развертывания | Создайте сеанс сравнения схем данных для просмотра различий между базой данных проекта и рабочей базой данных |
| Закрытие описателя установки | Отметьте задачу установки как выполненную |
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.