Опубликован: 16.02.2010 | Доступ: свободный | Студентов: 1465 / 167 | Оценка: 4.21 / 4.00 | Длительность: 06:28:00
Лекция 4:

Создание сценария

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >

Операция: Создание заметок о выпуске

Заметки о выпуске - это краткий набор сведений, сопровождающий каждый выпуск продукта. В этих заметках собраны требования к среде, описания установки и запуска приложения, новых возможностей, исправленных ошибок, известных дефектов и способов обхода проблем. Из заметок о выпуске пользователь узнает подробности о новой версии.

Документирование выявленных ограничений Опишите требования среды
Операция: Развертывание продукта

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

Создание установочного комплекта Сделайте для продукта установочный комплект, который упростит установку или развертывание приложения
Распространение выпуска Обеспечьте поставку системы потребителям
Устранение дефекта

Наличие дефекта указывает на потенциальную необходимость изменения уже работающей программы. Устранение дефекта не должно оказывать побочного эффекта. Чтобы исправление дефекта не нарушало работающий код, процесс коррекции должен быть методичным и управляемым. Код, измененный при устранении дефекта, необходимо проверить на соответствие правилам кодирования, автономно протестировать, пересмотреть, интегрировать в приложение и зарегистрировать в системе управления версиями. Все это делает ответственный за обработку дефекта участник проектной группы. Если все перечисленные действия не будут выполнены, "исправление" будет хуже исходной проблемы.

Воспроизведение дефекта Руководствуйтесь описанием дефекта
Создание или изменение теста модуля Определите область охвата теста модуля
Определение причины возникновения дефекта Выделите функциональную область
Переназначение дефекта Измените описание дефекта
Выбор стратегии устранения дефекта Проанализируйте обнаруженный дефект
Изменение программы Найдите нужный код
Выполнение теста модуля Выберите тест модуля из коллекции
Рефакторинг кода Определите сложность
Обзор кода Проверьте правильность имен
Интеграция изменений Проверьте зависимости
Операция: Воспроизведение дефекта

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

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

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

Выделение функциональной области Исключите из поиска источников проблемы области кода, не вызывающие подозрения
Трассировка подозрительного кода Используйте визуальные возможности отладчика при поиске дефекта
Анализ системы всеми доступными средствами Кроме трассировки применяйте все доступные средства поиска неисправностей, в том числе от сторонних производителей
Локализуйте проблему Максимально сузьте диапазон поиска дефекта
Анализ кода Если применение отладчика невозможно из соображений производительности или ограниченности ресурсов, проанализируйте исходный текст строка за строкой
Операция: Переназначение дефекта

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

Изменение дескриптора дефекта В бланке документирования дефекта укажите причину переназначения в поле диалога
Изменение владельца Измените сведения о лице, ответственном за обработку дефекта
Операция: Выбор стратегии устранения дефекта

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

Анализ обнаруженного дефекта Определите тип дефекта: проблемы с архитектурой, ресурсами или производительностью
Проблема с архитектурой Определите, на какие архитектурные решения повлияет устранение дефекта
Проблема с ресурсами Определите фрагменты кода, на которые оказано воздействие
Проблема с производительностью Определите, на какие фрагменты кода повлияет устранение дефекта
Операция: Изменение программы

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

Получение нужного кода Найдите все файлы, которые нужно изменить для исправления дефекта
Создание нового кода Для исправления дефекта, возможно, придется написать код в новых файлах
Изменение существующих файлов Для исправления дефекта может потребоваться изменение существующих файлов: добавление или удаление кода
Операция: Создание или изменение теста модуля

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

Определение типа теста модуля Определите типы разрабатываемых тестов модулей. Тесты правильной работы (positive unit tests ) проверяют код в нормальном режиме и контролируют корректность результатов. В тестах неправильной работы ( negative unit tests ) умышленно некорректно используется код и проверяется его устойчивость и адекватность обработки ошибок. Тесты с внесением неисправностей позволяют обнаружить аномалии в обработке ошибок
Создание или изменение теста модуля Для каждой задачи по разработке определите необходимые тесты модулей, которыми можно проверить как можно больше функций. Напишите тест модуля, убедитесь, что он не проходит, напишите или выделите фрагмент кода путем рефакторинга и прогоните тест модуля. Повторите процедуру для всех выбранных тестов модулей
Проверка теста модуля Прогоните тест и убедитесь, что он не проходит для незавершенных фрагментов и проходит для тех элементов, которые работают как требуется
Операция: Выполнение теста модуля

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

Определение подходящих тестов модулей Найдите тест или тесты, позволяющие наиболее адекватно проверить соответствующий элемент программы
Выполнение теста модуля Прогоните тест для кода, который он покрывает
Анализ результатов теста По завершении каждого этапа отметьте его соответствующим образом: Pass (Прошел), Fail (Не прошел), Skip (Пропущен), Warning (Требует внимания) или Blocked (Заблокирован)
Отладка кода Исправьте ошибки в программе, относящейся к задаче
Операция: Рефакторинг кода

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

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

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

Проверка правильности имен Имена классов и методов должны отражать назначение соответствующих фрагментов кода
Проверка адекватности кода Рассматриваемый код должен соответствовать задаче, для которой он написан. Допустимы только такие изменения кода, которые добавляют или изменяют функции системы
Проверка расширяемости Написанный код должен допускать расширяемость (если ставилась такая задача) или возможность повторного использования в других частях системы
Проверка допустимой сложности кода Повторяющийся код должен быть собран в общих функциях
Проверка сложности алгоритма Число возможных ветвей кода должно быть минимальным. Право на существование имеют только явно необходимые ветви
Проверка безопасности кода Проверьте защиту объектов, уровни привилегий и использование данных в точках входа
Внесение изменений по результатам обзора При проверке используйте контрольный список Внесите изменения, намеченные в результате обзора кода, скомпилируйте программу, выполните тесты модулей и выполните анализ кода. Если какие-либо тесты не прошли, выявите ошибки и исправьте код
Операция: Интеграция изменений

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

Проверка зависимостей Если задача зависит от других задач, которые еще не завершены, дождитесь, когда они будут интегрированы в систему
Тестирование и интегрирование других задач по разработке Проверьте, что вносимые вами изменения, связанные с исправлением дефекта, реализацией части сценария или требования к качеству, нормально работают совместно с уже интегрированными изменениями
Регистрация пакета изменений Увеличьте номер в поле "Resolved in Build" (Решено в сборке) для задачи исправления дефекта или в поле "Integration Build" (Сборка с реализацией) для задачи по разработке
Завершение задачи Если описатель, с которым связаны сделанные изменения, представляет сценарий или требование к качеству, а вы не являетесь его владельцем, уведомите владельца о том, что завершили внесение изменений
< Лекция 3 || Лекция 4: 1234 || Лекция 5 >
Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Александр Медов
Александр Медов

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