гост. 19621_ГОСТ Р 56920_Определения (1). Системная и программная инженерия
 Скачать 0.52 Mb.
|
|
С.4.2 Менеджмент тестирования в эволюционной разработке В Организационной Стратегии Тестирования должно быть отражено, что разработка соответствует эволюционной модели разработки. В ведущей разработку организации, использующей сочетание разных моделей разработки для различных проектов, включая эволюционную, обычно существует одна или несколько конкретных организационных стратегий тестирования для используемых моделей разработки. Организационная Стратегия Тестирования должна использовать терминологию, используемую соответствующим типом проекта, но помимо этого содержание любой Организационной Стратегии Тестирования зависит прежде всего от профиля рисков для соответствующих проектов и продуктов (несмотря на то, что тип используемой модели разработки может создать дополнительные типы риска, которые также должны быть учтены в Стратегии Тестирования). Эволюционный проект управляется менеджером проекта. Для большинства проектов определены роли менеджера по развитию и менеджера по тестированию. В зависимости от размера проекта эти роли могут выполняться разными людьми или же несколько ролей могут выполняться одним и тем же человеком. В эволюционной разработке планы создаются как для всего проекта, так и для каждой итерации. План Тестирования Проекта оформляется в виде отдельного документа, однако он может быть и частью общего плана проекта. Для определения тестирования итерации может быть разработан меньший план тестирования итерации. В эволюционной разработке планы могут быть документированы более или менее формально, но, как правило, они поддерживаются инструментами документирования и/или планирования. Планы Тестирования итераций и связанные с ними планы подпроцессов тестирования часто используются повторно с необходимыми от итерации к итерации коррекциями. Прогресс тестирования контролируется в ходе итерации, необходимые корректирующие действия предпринимаются на постоянной основе и доводятся до заинтересованных сторон в обновленных Планах Тестирования. С.4.3 Подпроцессы тестирования в эволюционной разработке В ходе каждой итерации могут быть проверены как рабочие продукты, так и завершенная система. Подпроцессы тестирования могут быть определены и выполняться с использованием процессов, представленных в настоящем стандарте, для тестирования исполнимых рабочих продуктов и производимой системы. Первый этап разработки в этом примере - инженерия требований, где определяются бизнес-требования, функциональные/нефункциональные и системные требования. На рисунке С.3 во избежание загромождения картины показан только подпроцесс тестирования, связанный с первой фазой (фазой тестирования требований). Тестирование требований, поскольку они определены, можно рассматривать как подпроцесс, состоящий из статического тестирования. Формальность этого подпроцесса тестирования зависит от профиля риска для продукта, но поскольку требования являются основой выполнения итераций, то методика проектирования статического тестирования должна быть выбрана более формально. Подобные подпроцессы тестирования могут быть определены для двух стадий проектирования, а также для этапа кодирования. В примере модели разработки, показанном на рисунке С.3, в подпроцессы тестирования входят: - тестирование архитектуры; - тестирование детального проектирования; - тестирование исходного кода. Эти подпроцессы тестирования обычно сопровождают большую часть соответствующего этапа разработки, концентрируются на одном типе элемента тестирования, например требованиях, и включают в себя различные способы проверки элемента тестирования, например пошаговый разбор и технический анализ. Подпроцесс тестирования требований не будет завершен до тех пор, пока согласно плану подпроцесса тестирования не будут проверены все представленные требования. Завершение подпроцесса, как правило, является более или менее формальным признаком завершения этапа инженерии требований, однако это зависит от результата подпроцесса тестирования требований. Таким же образом, не будут завершены подпроцессы тестирования проекта и исходного кода до тех пор, пока согласно плану подпроцесса тестирования не будут проверены все разработанные элементы тестирования, а соответствующий этап разработки будет зависеть от результатов подпроцесса тестирования. На рисунке С.3 показан подпроцесс приемочного испытания. Действия планирования и подготовки в подпроцессе приемочного испытания могут быть начаты, как только риск существенного изменения в требованиях для данной итерации снизится до степени, оправдывающей запуск подпроцесса тестирования. Проект тестирования будет выявлять дефекты в требованиях и таким образом вносить свой вклад в информационное представление требований. Подобные подпроцессы тестирования могут быть определены и для других этапов разработки, где возможно динамическое тестирование. В примере модели разработки, показанном на рисунке С.3, в состав подпроцессов могли бы входить следующие подобные подпроцессу приемки подпроцессы: - покомпонентное тестирование; - интеграционное тестирование; - тестирование системы. В примере на рисунке С.3 показано также тестирование производительности. В зависимости от профиля риска для системы можно определить конкретные подпроцессы тестирования для покрытия определенных категорий требований или определенных областей системы, определяемых требованиями. Такие конкретные подпроцессы тестирования могут выполняться на многих этапах разработки, а следовательно, могут иметь множество элементов тестирования и связанных с ними базисов тестирования, обязанностей по тестированию, методов, сред, целей тестирования, критериев завершения и планов. Однако в рассмотренном примере подпроцесс тестирования фокусируется только на требованиях к производительности и то, как они описываются, разрабатываются и реализуются в системе. Все вышеперечисленные типы тестирования могут быть выполнены для каждой последующей итерации. В связи с постоянным расширением возможностей продукта для каждой итерации необходимо описанное выше всеобъемлющее регрессионное тестирование. Для каждой итерации должен быть определен подпроцесс регрессионного тестирования. Подпроцесс регрессионного тестирования может включать в себя регрессионное тестирование всех элементов, расширяемых в итерации, включая требования, проект, исходный код и систему, или же выбор элементов может быть сделан в зависимости от профиля риска. Для обеспечения большей динамичности в регрессионном тестировании от итерации к итерации можно для каждого типа элемента определить конкретный подпроцесс регрессионного тестирования. Приложение D (справочное). Примеры подпроцессов тестирования в деталях Приложение D (справочное) D.1 Общие сведения В данном приложении приводятся примеры подпроцессов тестирования. Здесь приводится всего лишь несколько примеров в отличие от конкретного проекта тестирования, где могут потребоваться другие определенные подпроцессы. Примеры подпроцессов тестирования: - приемочные испытания; - тестирование детального проектирования; - интеграционное тестирование; - тестирование производительности; - регрессионное тестирование; - повторное тестирование; - тестирование истории; - тестирование системы; - покомпонентное тестирование. Следует обратить внимание на то, что регрессионное тестирование и повторное тестирование включены как конкретные подпроцессы тестирования. В определенных случаях они могут входить в состав любого другого подпроцесса. В описание каждого подпроцесса тестирования входят: - цель подпроцесса тестирования; - запланированный состав подпроцесса тестирования - статические и/или процессы динамического тестирования, которые будут выполняться. Для каждого процесса статического или динамического тестирования, запланированного в составе подпроцесса тестирования, описание включает: - цель тестирования; - элемент(ы) тестирования; - базис тестирования; - применимые процессы тестирования; - предлагаемую методику (методики) проектирования тестирования, если это применимо. Следует обратить внимание на то, что представленные примеры являются всего лишь примерами. В каждой фактической ситуации выбор должен осуществляться в соответствии с профилем риска для продукта. D.2 Подпроцесс приемочного испытания Этот пример представляет подпроцесс тестирования, связанный с фазой приемки жизненного цикла разработки.
Динамическое тестирование 1. Генеральная репетиция
Разработка и реализация контрольных примеров могут быть начаты по достижении стабильности требований пользователя. Хотя перед приемочными испытаниями предполагается, что система работает, большинство организаций перед окончательной официальной презентацией системы в присутствии потребителя подготавливает и выполняет тестирование, известное под названием "Генеральная репетиция". При этом могут быть запланированы повторное тестирование и процессы регрессионного тестирования для устранения каких-либо "последних" дефектов, выявленных в результате этого тестирования. Динамическое тестирование 2. Презентация
После заключительной "Генеральной репетиции" необходимо привести тестовую среду в исходное состоянии*, иначе выполнение теста будет происходить соответственно процедурам и среде, подготовленным в ходе "Генеральной репетиции". ________________ * Текст документа соответствует оригиналу. - Примечание изготовителя базы данных. D.3 Подпроцесс тестирования детального проектирования Этот пример представляет подпроцесс тестирования, связанный с фазой детального проектирования жизненного цикла разработки.
В фазе детального проектирования в соответствии с архитектурой разрабатываются отдельные элементы проекта. Каждый из них может быть подвергнут статическому тестированию посредством определенного для этого подпроцесса тестирования. Таким образом, объектами планирования статического тестирования могут быть элементы тестирования, определенные как конкретные элементы детального проектирования. Подпроцесс тестирования детального проектирования завершается только тогда, когда завершатся все запланированные тестирования (или в зависимости от обстоятельств фиксируется отказ). Статическое тестирование 1. Документация элемента детального проектирования
Статическое тестирование 2. Удобство использования элемента детального проектирования
Статическое тестирование 3. Полнота элемента детального проектирования
D.4 Подпроцесс интеграционного тестирования Этот пример представляет подпроцесс тестирования, связанный с фазой интеграции в жизненном цикле разработки, когда компоненты (протестированные) постепенно интегрируются. Во время фазы интеграции интегрируются два из множества произведенных подобных элементов тестирования. Динамическое тестирование в данном случае является общим и может быть выполнено для двух любых интегрируемых компонентов, начиная от самых первых двух интегрируемых компонентов до тех пор, пока последние два компонента не интегрированы в полную систему. Подпроцесс интеграционного теста завершается только тогда, когда завершатся все запланированные тестирования (или в зависимости от обстоятельств фиксируется отказ). Возможны различные уровни интеграции. Это может быть интеграция компонентов на исходном коде в больший компонент, образующий завершенную полную систему, интеграция подсистем разных типов (аппаратных средств, программного обеспечения, данных, учебных материалов и т.д.) в одну полную систему или интеграция полноценных систем, объединяющая их в больший компонент, входящий в завершенную систему систем. Везде принципы одинаковы, хотя формальность зависит от профиля риска.
|