metoda_2013

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Процедуры управления проектом по методологии PMI

Определение требований к проекту

Постановка чётких и достижимых целей

Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости

Адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров)

Процедуры управления проектом по методологии PRINCE2

Начало проекта (SU).

Запуск проекта (IP).

Планирование проекта (PL).

Управление проектом (DP).

Контроль стадий (CS).

Контроль границ стадий (SB).

Управление производством продукта (MP).

Завершение проекта (CP).

Классическая форма Тройственной Ограниченности

Тройственная

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

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

160

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

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

Подходы

Предположение о неограниченности ресурсов, критичен только срок выполнения. Метод PERT, Метод критического пути

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

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

Предположение о высоких рисках проекта. Метод Инновационные проекты (стартапы)

Варианты нейтральных (сбалансированных) подходов:

Акцент на взаимодействие исполнителей. Метод PRINCE2

Акцент на взаимодействие процессов. Метод Process-based management

34. Принципы тестирования. Философия тестирования.

На этот этап (тестирование) приходится около 50% общей стоимости разработки программного обеспечения.

Тестирование - это процесс выполнения программы с целью обнаружения в ней ошибок.

161

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Цель тестирования - распознать дефекты в объекте тестирования и увеличить вероятность того, что он при любых обстоятельствах будет работать в соответствии с установленными требованиями.

Разберемся, а что представляет из себя дефект? Дефекты бывают внешние и внутренние. Отказ (наблюдаемый дефект,bug)– это внешнее проявление внутреннего изъяна.

У Майерса сформулированы основные принципы организации тестирования:

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

2)следует по возможности избегать тестирования программы ее

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

3)по тем же соображениям организация - разработчик программного обеспечения не должна “единолично” его тестировать;

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

5)необходимо тщательно подбирать тест не только для

правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);

6)при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать;

7)следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика);

8)тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки (в частности, следует выделять для тестирования достаточные временные и материальные ресурсы);

9)следует учитывать так называемый “принцип скопления

ошибок”: вероятность наличия не обнаруженных ошибок в

162

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части; 10) следует всегда помнить, что тестирование - творческий

процесс, а не относиться к нему как к рутинному занятию.

Существует два основных вида тестирования : функциональное и структурное.

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

2)При структурном тестировании программа рассматривается как “белый ящик”. Происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы (ее управляющем графе).

Но даже если предположить, что удалось достичь полного структурного тестирования некоторой программы, в ней, тем не менее, могут содержаться ошибки, т.к. 1) программа может не соответствовать своей внешней спецификации, что в частности, может привести к тому, что в ее управляющем графе окажутся пропущенными некоторые необходимые пути; 2) не будут

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

В тестирование многомодульных программных комплексов можно выделить четыре этапа:

1)тестирование отдельных модулей;

2)совместное тестирование модулей;

3)тестирование функций программного комплекса;

4)тестирование всего комплекса в целом.

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

Рассмотрим типы тестирования по качествам продукта

-Функциональное тестирование – соответствие внешним спецификациям

-Тестирование usability – в Gamedev сюда относиться играбельность и захватываемость.

-Тестирование производительности – быстрота отклика системы и ее производильность (например, количество FPS)

163

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

-Конфигурационное тестирование – совместимость с разл. типами оборуд-я и ПО.

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

Какие требования предъявляются к рядовым тестировщикам?

-Умение устно и письменно излагать проблему

-Способность предугадать, где находятся ошибки

-Способность одновременного выполнения нескольких задач

-Навыки работы по расписанию

-Умение работать в условиях давления

-Наблюдательность, внимательность к деталям

-Способность представить себя на месте другого

-Умение читать и писать спецификации

Полное тестирование практически невозможно. Если так то возникает логический вопрос, когда прекращать тестирования, какой уровень качества считать достаточным. Этот вопрос считается основным вопросом тестирования. Существует множества вариантов ответов на этот вопрос, один из них перед вами: Тестирование следует продолжать до тех пор, пока затраты на обнаружение и исправление дефектов НИЖЕ, чем будущие потери от сбоев продукта при его эксплуатации (Тим Комен, Мартин Пол)

Другими словами важно определить, что достигнут достаточно хороший уровень качества.

Философия тестирования: стремиться к более высокому качеству продукта, находить все возможные дефекты.{Качество} = {Удовлетворенность заказчика} = {Ценность} / {Cтоимость} (формула из неофиц. источника, придумал некто на форуме)

35. Уровни тестирования. Этапы тестирования.

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

164

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Уровни тестирования

Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Обычно компонентное (модульное) тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking System).

Один из наиболее эффективных подходов к компонентному (модульному) тестированию - это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-driven development) или подход тестирования вначале (test first approach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор пока все тесты не будут успешными.

Разница между компонентным и модульным тестированием

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

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

Уровни интеграционного тестирования:

165

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Компонентный интеграционный уровень (Component Integration testing)

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

Системный интеграционный уровень (System Integration Testing)

Проверяется взаимодействие между разными системами после проведения системного тестирования.

Подходы к интеграционному тестированию:

Снизу вверх (Bottom Up Integration)

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

Сверху вниз (Top Down Integration)

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

Большой взрыв ("Big Bang" Integration)

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

166

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям. Основной задачей системного тестирования является проверка как

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

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

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфатестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

167

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Можно выделить два подхода к системному тестированию:

на базе требований (requirements based)

Для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.

на базе случаев использования (use case based)

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

Приемочное тестирование или Приемо-сдаточное испытание

(Acceptance Testing) - формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

определения удовлетворяет ли система приемочным критериям;

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

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

Решение о проведении приемочного тестирования

принимается, когда:

продукт достиг необходимого уровня качества;

заказчик ознакомлен с Планом Приемочных Работ

(Product Acceptance Plan) или иным документом, где

168

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

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

Методы тестирования

Метод черного ящика – тестирование без знания реализации

Метод белого ящика – тестирование на основе кода

Тестирование моделей - объект тестирования - не сама система, а ее модель, спроектированная формальными средствами.

Анализ программного кода (инспекции) – ручной анализ программного кода на корректность, называемый также просмотрами или инспекциями кода.

Этапы тестирования

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

2.Планирование тестирования: создается план тестирования.

3.Разработка тестов: создаются тестовые сценарии, тесты данных, тестовые скрипты, которые будут использоваться при тестировании программного обеспечения.

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

5.Тестовые отчет: после проведенных тестов, тестеры подсчитывают метрики и создают финальный отчет об их тестах и сообщают, действительно ли протестированный продукт готов к выпуску.

169