гост. 19621_ГОСТ Р 56920_Определения (1). Системная и программная инженерия
 Скачать 0.52 Mb.
|
|
В.1 Метрики и показатели Основная цель тестирования заключается в предоставлении информации, необходимой для управления рисками. Чтобы контролировать и управлять тестированием, а также предоставлять своевременную информацию заинтересованным сторонам, необходимы эффективные измерения процесса тестирования. Для измерения процесса тестирования нужно определить, какая информация должна быть предоставлена, как ее получить и как она должна быть представлена. Таким образом, для всех действий тестирования необходимо определить и использовать метрики, а также предоставить показатели измерений, как для продуктов, так и для процессов. Некоторые примеры метрик, которые могут использоваться в тестировании: - остаточный риск; число смягченных рисков/число идентифицированных рисков; - накопленные открытые и закрытые дефекты; число выявленных за день дефектов по сравнению с числом устраненных за день дефектов; - прогресс контрольных примеров; число выполненных контрольных примеров/число запланированных для выполнения контрольных примеров; - процент обнаружения дефектов; число дефектов, выявленных в тестировании/общее числе* выявленных дефектов (в целом). ________________ * Текст документа соответствует оригиналу. - Примечание изготовителя базы данных. Приложение С (справочное). Тестирование в различных моделях жизненного цикла Приложение С (справочное) С.1 Общие сведения Это приложение дает примеры того, как тестирование может вписаться в различные модели жизненного цикла разработки программного обеспечения. Для каждого конкретного проекта идентифицируются необходимые этапы разработки и/или действий, что и определяет, как относительно друг друга они будут выполняться в течение жизненного цикла разработки. Совокупность этапов разработки и их взаимосвязь называют "моделью жизненного цикла разработки" или "моделью жизненного цикла". В течение многих лет в индустрии программного обеспечения используется ряд моделей жизненного цикла. Типичными моделями жизненного цикла являются (список неисчерпывающий): - динамичная; - эволюционная; - последовательная (т.е. каскадная модель). Выполняемые во время разработки действия примерно одни и те же для всех моделей жизненного цикла; основные различия заключаются в определении предметов действий, количестве, характере подготавливаемой документации и частоте, с которой они повторяются в течение жизненного цикла разработки. Примечание - Стандартизация различных моделей жизненного цикла не является целью настоящего стандарта, в намерения которого входит оказание поддержки тем, кто реализует эти жизненные циклы, в создании условий для тестирования. С.2 Динамичная разработка и тестирование С.2.1 Принципы динамичной разработки Динамичная разработка обычно соответствует нижеперечисленным принципам: - разработка по этапам - результатом каждого цикла являются полезные и применимые продукты; - цикличность разработки - в ходе разработки допускается развитие требований (то есть изменение и добавление); - разработка ориентирована на людей - опора на качество проектной группы (например, разработчиков и тестеров), а не на точно определенные процессы; обеспечение самоуправления быстрой и динамичной команды; ежедневное взаимодействие группы разработчиков с бизнес-заинтересованными сторонами; - инженерно-техническое совершенство - достигается посредством дисциплинированного подхода к разработке, интеграции и тестированию продуктов. Существует множество методик и схем динамичной разработки, включая: Экстремальное программирование (ХР), Scrum, Crystal, Kanban и Feature-Driven Development. В то время как все они используют различные подходы, они следуют принципам динамичной разработки, изложенным в манифесте динамичной разработки (Agile Manifesto, см. http//:agilemanifesto.org/). Поскольку в рамках настоящего стандарта невозможно рассмотреть его использование при реализации всех методов и схем динамичной разработки, то в качестве примера в настоящем стандарте будет использована схема метода Scrum. Метод Scrum не является методологией разработки (то есть он не предлагает лучших методов описания требований или записи кода), а определен как схема менеджмента проектов, в которой разработчиками используется динамичная методология (часто используется ХР). Проект Scrum состоит из множества итераций, называемых спринтами. Результатом каждого спринта обычно является новая функциональность, которая может быть предоставлена пользователям, как показано на рисунке С.1. Подобная новая функциональность может представлять собой улучшение предшествующей функциональности или дополнение ее новыми возможностями. Продолжительность каждого спринта обычно составляет от одной до четырех недель. Зачастую количество спринтов в начале проекта неизвестно, поскольку в начале типичных динамичных проектах требования не определены полностью. В ходе проекта требования развиваются. Требования потребителя собираются в Портфеле Продукта обычно в виде истории пользователей. Модель процесса тестирования, определенная в настоящем стандарте, применима для тестирования, производимого в проектах, выполняемых соответственно модели динамичной разработки. С.2.2 Менеджмент тестирования в динамичной разработке Организационная Стратегия Тестирования должна отражать факт соответствия разработки модели динамичной разработки. В организации, где разработка выполняется с использованием в различных проектах разных моделей разработки, в том числе и динамичной, как правило, имеется определенная Организационная Стратегия Тестирования для динамичной разработки. Организационная Стратегия Тестирования проектов для динамичной разработки должна использовать специфические понятия динамичной разработки, такие как "портфель продукта", "спринт", "ежедневная встреча", но помимо этого содержание любой Организационной Стратегии Тестирования зависит, прежде всего, от профиля рисков для соответствующих проектов и продуктов (несмотря на это, тип используемой модели разработки может создать дополнительные типы риска, которые также должны быть учтены в Стратегии Тестирования). Рисунок С.1 - Проект Scrum в качестве примера жизненного цикла проекта (динамичная разработка)  Рисунок С.1 - Проект Scrum в качестве примера жизненного цикла проекта (динамичная разработка) Проектом динамичной разработки часто управляет менеджер проектов, а спринты продвигаются мастером Scrum (эти роли выполняются одним и тем же человеком). Менеджмент тестирования в динамичном проекте осуществляется как интегрированная часть управления портфелем продукта, конкретными спринтами и ежедневными встречами. В начале разработки спринта команда Scrum и потребитель (владелец продукта) приходят к соглашению, какие из историй пользователя из портфеля продукта должны быть реализованы в этом спринте. Отобранные истории включаются в портфель спринта. Затем команда разрабатывает план спринта, планируя разработку и тестирующие действия и присваивая роли и обязанности членам команды. Динамичная разработка осуществляется посредством тех же общих процессов, присущих любой разработке и тестированию продукта, как это показано на примере спринта Scrum на рисунке С.2. Результат спринта демонстрируется потребителю на презентации спринта, где у команды есть возможность показать заинтересованным сторонам, что они создали. Заключительное действие в спринте - это ретроспектива спринта, в ходе которой команды рассматривают, насколько хорошо спринт выполнен, и определяют, где и какие улучшения для будущих спринтов можно сделать, то есть совершенствование процессов встроено в структуру Scrum. В ходе спринта в начале каждого дня проводятся ежедневные встречи Scrum, на которых отмечается, что было сделано и делается в этот день, а также с какими проблемами может столкнуться команда. Эти встречи позволяют мастеру Scrum определить, какие препятствия необходимо преодолеть, чтобы обеспечить наиболее эффективно максимальный прогресс команды. Ключевыми факторами в динамичном проекте являются управление риском дефектов регрессии (поскольку каждый спринт основывается на предыдущих спринтах) и управление изменяющейся природой требований и их влиянием на артефакты тестирования. Обычно для управления риском регрессии используется автоматизация тестирования, а для управления влиянием отсутствия подробных требований может быть применено исследовательское тестирование. С.2.3 Подпроцессы тестирования в динамичной разработке Действия тестирования являются неотъемлемой частью проекта динамичной разработки. Как показано на рисунке С.2, тестирование выполняется на постоянной основе всюду по ходу спринта. Подпроцессы тестирования могут быть определены и выполняться с использованием процессов, представленных в настоящем стандарте, для тестирования историй пользователя и развития разрабатываемой системы. Рисунок С.2 - Пример динамичного жизненного цикла спринта  Рисунок С.2 - Пример динамичного жизненного цикла спринта Типичными методиками тестирования, используемыми командой спринта, являются: - разработка через тестирование (TDD); это разработка, в которой тесты для кода разрабатываются перед разработкой кода. Тесты базируются на пользовательской истории и могут быть разработаны совместно тестером и разработчиком. Такие тестирования обычно реализуются с использованием автоматизированных инструментов покомпонентного тестирования, что позволяет рассматривать разработку через тестирование как форму программирования; - тестирование автоматизированных сборок и непрерывная интеграция; это случай, когда система постоянно обновляется и регрессивно тестируется по мере регистрации кода. Используется для обеспечения своевременной идентификации и коррекции проблем регрессии и интеграции; - тестирование всех показателей качества системы (то есть как функциональных, так и нефункциональных). Выполняется на основании историй пользователя и всех существующих требований высокого уровня. Тестирование системы обычно сопровождается приемочными испытаниями, в которых должны участвовать конечные пользователи для гарантии того, что обеспеченная функциональность удовлетворяет их потребности; - регрессионное тестирование, как правило, требуется для того, чтобы определить отсутствие у любых изменений в текущем спринте неблагоприятных побочных эффектов на существующие функции и возможности продукта. В конце "идеального" спринта функции готовы к употреблению пользователями; это означает, что все вышеупомянутое тестирование выполняется в спринте, как показано на рисунке С.2. На практике многие проекты считаются слишком трудными, что приводит к принятию компромиссных вариантов, таких как выполнение тестирования параллельным действием со смещением или выполнение тестирования в специализированном фокусируемом на тестировании спринте. С.3 Последовательная разработка и тестирование С.3.1 Последовательные принципы разработки Последовательные модели жизненного цикла возникли ранее других и широко используются в настоящее время. Базовая (оригинальная) последовательная модель известна как каскадная модель и представляет собой упорядоченную последовательность этапов разработки, предшествующих фазе тестирования, с заключительной операционной фазой в конце. Последовательная модель жизненного цикла характеризуется отсутствием явного повторения фаз за исключением тех случаев, когда абсолютная необходимость повторения продиктована обратной связью от последующих фаз. Модель процесса тестирования, определенная в настоящем стандарте, может быть применена к тестированию разработки, соответствующей последовательной модели жизненного цикла. С.3.2 Менеджмент тестирования в последовательной разработке В Организационной Стратегии Тестирования должно быть отражено, что разработка соответствует последовательной модели разработки. В ведущей разработку организации, если там используется сочетание разных моделей разработки для различных проектов, включая последовательную, обычно существует одна или несколько конкретных организационных стратегии тестирования для используемых моделей разработки. Организационная Стратегия Тестирования должна использовать терминологию, применяемую в соответствующем типе проекта, в противном случае, содержание Организационной Стратегии Тестирования будет зависеть от соответствующего профиля риска для проектов и продуктов, а не от типа используемой модели разработки. Последовательный проект управляется менеджером проекта. Для большинства проектов также определены роли менеджера по развитию и менеджера по тестированию. В зависимости от размера проекта эти роли могут выполняться различными людьми или несколько ролей могут выполняться одним и тем же человеком. Планы последовательной разработки создаются для всего проекта, хотя в ходе проекта они должны развиваться. Проекты последовательной разработки могут быть относительно велики, и в начале проекта детальное планирование всего проекта может быть невозможно. Необходима также и разработка Плана Тестирования Проекта. Этот план обычно оформляется в виде отдельного документа, но может быть и частью общего плана проекта. Возможна разработка отдельных планов подпроцессов тестирования при условии, что выполнение этих подпроцессов тестирования предусмотрено Планом Тестирования Проекта. В последовательной разработке планы обычно документируются формально. С.3.3 Подпроцессы тестирования в последовательной разработке Подпроцессы тестирования, определенные для эволюционной разработки в С.3, имеют также большое значение для тестирования в последовательном проекте, хотя они выполняются только один раз (один проход через последовательную модель разработки). Рисунок С.3 - Пример подпроцесса тестирования в последовательном жизненном цикле разработки  Рисунок С.3 - Пример подпроцесса тестирования в последовательном жизненном цикле разработки Следует обратить внимание на то, что рисунок С.3 выполнен не в масштабе - относительный размер показанных подпроцессов тестирования не соответствует фактическим размерам подпроцессов тестирования с точки зрения, например, затраченных времени, усилий или средств. Определяются тестирование Архитектуры, тестирование Детального Проектирования и тестирование Исходного Кода. Для каждого из них соответствующий этап разработки может быть закончен на основе результатов завершения тестирования, то есть после того, как все детально разработанные элементы были проверены индивидуально. Фаза кодирования включает в себя два различных подпроцесса тестирования. Первым из них является подпроцесс тестирования исходного кода, представляющий собой статическое тестирование исходного кода, а вторым - покомпонентное тестирование, то есть динамическое тестирование исполнимого или интерпретируемого кода. Эти подпроцессы тестирования могут использоваться совместно, и динамическое тестирование компонента может зависеть от успешного статического тестирования исходного кода. Конечным результатом фазы интеграции является завершенная система. На этом этапе может начинаться выполнение действий тестирования системы, предполагая, что они уже были запланированы и подготовлены на основе требований. Подпроцессы тестирования, показанные здесь в качестве примера, описаны далее в приложении Е. С.4 Эволюционная разработка и тестирование С.4.1 Эволюционные принципы разработки Эволюционная разработка основывается на двух основных принципах: итерации и инкрементной разработке. Итерация позволяет разработчикам создавать систему в виде совокупности более мелких частей и для улучшения следующей итерации использовать обратную связь, как от разработанного продукта, так и от методов разработки. Итерация по сравнению с традиционными последовательными циклами позволяет раньше рассмотреть более высокие риски, обеспечивая таким образом возможность увеличения время их анализа. При инкрементной разработке результаты каждой итерации предоставляются потребителю, означая, что в каждой из поставок серии пользователи получают систему с увеличивающейся функциональностью. Итерация состоит из всех или некоторых стандартных действий разработки. В случае если результат итерации будет поставлен пользователям, итерация должна включать в себя фазу приемки, в противном случае фаза приемки выполняется только в последней итерации. На рисунке С.3 показан последовательный жизненный цикл разработки. Эволюционный жизненный цикл разработки может быть представлен как множество дискретных последовательных жизненных циклов, каждый из которых добавляет разработанной системе дополнительную функциональность. Модель процесса тестирования, определенная в настоящем стандарте, может быть применена к тестированию разработки, соответствующей эволюционной модели разработки. |