гост. 19621_ГОСТ Р 56920_Определения (1). Системная и программная инженерия
 Скачать 0.52 Mb.
|
|
5.1.1 Роль тестирования в верификации и валидации В настоящем стандарте рассматриваются только некоторые действия верификации и валидации. В частности, рассматривается тестирование программного обеспечения, которое является основным действием при верификации и валидации. Такие стандарты, как ИСО/МЭК 12207 и ИИЭР 1012, рассматривают и другие действия верификации или валидации. Настоящий стандарт ориентирован только на тестирование и в нем не рассматриваются другие действия валидации и верификации (например, анализ валидации и верификации, формальные методы). Для обеспечения полной валидации и верификации продукта организация в составе своей комплексной технической программы должна использовать настоящий стандарт совместно с другими стандартами. Иерархия действий верификации и валидации приводится в приложении А. 5.1.2 Исчерпывающее тестирование Из-за сложности систем и программного обеспечения не представляется возможным исчерпывающе проверить каждый аспект любого конкретного элемента тестирования. Тестеры должны осознать, что исчерпывающее тестирование невозможно и что тестирующие действия должны быть направлены на возможно лучшее выполнение задач тестирования для элемента тестирования. Тестирование на базе рисков - это подход, при котором риск используется для координации усилий тестирования. Тестирование на базе рисков рассматривается в 5.4. 5.1.3 Тестирование как эвристика Эвристика в технике (и в программной инженерии) - это основанный на опыте метод (метод проб и ошибок), который можно использовать в качестве вспомогательного средства в разрешении проблем и разработках. Хотя эвристика и может использоваться для разрешения проблем, в отдельных случаях она ненадежна в том смысле, что может не решить задачу или решить ее только частично. На эвристике основывается значительная часть тестирований систем и программного обеспечения. Например, эвристика полезна при создании модели тестируемой системы, однако она не может моделировать систему в полной мере, и поэтому дефекты в системе не могут быть выявлены даже при том, что тестирование кажется полным. Признание того, что метод тестирования может быть ненадежен, позволяет снизить риск неэффективной стратегии тестирования, используя несколько стратегий тестирования. 5.2 Тестирование программного обеспечения в организационном контексте и контексте проекта Компании, вовлеченные в разработку или приобретение программных продуктов, заинтересованы в разработке и использовании эффективных, действенных и повторимых процессов. Для осуществления этого компании разрабатывают полноценный набор процессов жизненного цикла программного обеспечения, используемых в проектах выполняемых ими разработок. Настоящий стандарт предназначен как для использования в организации в целом, так и для применения в отдельных проектах. Организация может принять настоящий стандарт и дополнить его по мере необходимости дополнительными процедурами, методами, инструментами и политиками. Конкретный проект разработки программного обеспечения или системы, выполняемый организацией, как правило, соответствует процессам организации, а не соответствует напрямую настоящему стандарту. В отдельных случаях проект может выполняться организацией, которая не располагает надлежащей совокупностью процессов организации. Такой проект может непосредственно применить положения настоящего стандарта. Для любой производящей программное обеспечение организации, будь ею многонациональная организация с тысячью тестеров или компания из одного человека, обязательства по тестированию программного обеспечения должен нести высший уровень организационного менеджмента, будь то генеральный директор, открытый руководящий комитет или начальник отдела. Желательно, чтобы эти обязательства были заложены в Организационную Политику Тестирования и в одну или более Организационные Стратегии Тестирования, служащие основой для всех выполняемых в организации видов тестирования программного обеспечения. Политики Тестирования и Организационные Стратегии Тестирования обычно присутствуют в наиболее развитых организациях. В организациях менее зрелых тестирование может выполняться и выполняется без формальных политик тестирования и организационных стратегий тестирования, но такая практика не обеспечивает обоснованности тестирования в организации и, как правило, показывает меньшую эффективность и результативность тестирования, выполняемого в проектах. Тестирование программного обеспечения выполняется как управляемый контекстом процесс. Это означает, что процесс нужно планировать, контролировать и им нужно управлять. Контекстом тестирования может быть как проект разработки (в пределах от многочисленного, многолетнего формального проекта разработки до неофициальной разработки, требующей нескольких часов работы одного человека), так и текущее сопровождение функционирующей системы. Необходимо отметить некоторые положения контекста тестирования: полный бюджет; требования расписания; риск; организационная культура; ожидания потребителя/пользователя; готовность сред инфраструктуры для тестирования; область применения проекта; критичность проекта и т.д. Накопленный опыт отрасли показывает, что ни одна стратегия тестирования, ни один план, метод или процесс не будут работать во всех ситуациях. Следовательно, организации и проекты должны адаптироваться и совершенствоваться в деталях тестирования, опираясь на стандарты, такие как настоящий стандарт. Полный план проекта должен включать в себя анализ тестирующих действий, которые будут выполняться как часть проекта. В Плане Тестирования Проекта должны быть отражены как Организационная Политика Тестирования и Организационная Стратегия Тестирования, так и отклонения от этих организационных руководств. Кроме того, в плане должны быть учтены ограничения, заданные в полном плане проекта. План Тестирования Проекта включает в себя стратегию тестирования проекта и специфичные, используемые для выработки стратегии решения проекта (включая предположения). Основной элемент планирования тестирования - это оценка различных нужд тестирования и балансировка ресурсов между различными тестированиями. План тестирования фиксирует результат этого анализа. В соответствии с настоящим стандартом в основу метода определения потребностей тестирования закладывается риск (см. 5.4), однако в стратегию также могут быть включены и другие методики тестирования, описанные в 5.6. Для всего проекта тестирование осуществляется часто через некоторое множество подпроцессов тестирования, каждый из которых может иметь соответствующий План Тестирования (План Подпроцесса Тестирования, например План Тестирования Системы или План Теста Производительности), включающий в себя как стратегию подпроцесса тестирования, согласованную со стратегией тестирования проекта, так и специфические детали подпроцесса тестирования. На рисунке 1 показано, как тестирование вписывается в иерархический контекст. Тестирование базируется на статусе регулирования, присущем организации (если регулирование имеет место). Упомянутый контекст состоит из законов, инструкций и промышленных стандартов. В соответствии с нормативной ситуацией организация разрабатывает необходимые политики и процедуры, требуемые для успешной работы. Организационная Политика Тестирования работает на этом уровне. Каждый проект организации реализуется для соответствия некоторому требованию или возможности, которые идентифицированы организацией. Контекст проекта помогает определить, какую модель жизненного цикла выбрать. На этом уровне на основе контекста проекта и модели жизненного цикла определяется стратегия тестирования. План проекта и стратегия тестирования формируют базу для Плана Тестирования Проекта. План Тестирования Проекта описывает общую стратегию тестирования и процессы тестирования, которые будут использоваться. Он устанавливает контекст тестирования проекта, определяя цели, методы, ресурсы и расписание. Кроме того, он идентифицирует применимые подпроцессы тестирования (например, тестирование системы, тестирование производительности). Идентифицированные подпроцессы далее расписываются в плане тестирования подпроцесса (например, План Тестирования Системы, План Теста Производительности). План тестирования также определяет надлежащий метод проектирования тестирования (статическое или динамическое), необходимый для выполнения подпроцесса тестирования, требуемого конкретным планом. Более подробно методы проектирования тестирования описаны в 5.5.6 и ИСО/МЭК/ИИЭР 29119-4. Рисунок 1 - Иерархическая схема тестирования  Рисунок 1 - Иерархическая схема тестирования Каждый план тестирования подпроцесса может относиться более чем к одному уровню тестирования (например, план тестирования защищенности может относиться к нескольким уровням тестирования), а кроме того, может относиться к более чем одному типу тестирования (например, План Тестирования Системы, который относится к тестированию функциональности и тестированию производительности на уровне тестирования системы). План тестирования подпроцесса также определяет стратегию выполнения теста (например, по сценарию, без сценария или смесь того и другого). План тестирования включает в себя стратегию тестирования (см. раздел 6). Стратегии тестирования настраиваются на конкретный контекст проекта тестирования. Стратегии тестирования должны соотноситься конкретными элементами, показанными на рисунке 1 и определенными в других частях серии стандартов ИСО/МЭК/ИИЭР 29119. Каждый план тестирования (и стратегия) будет уникален, отличаясь от других: подпроцессами тестирования, уровнями автоматизации, совокупностью методик проектирования тестирования, критериями завершения теста, их планированием и выделением ресурсов. Планирование и выбор этих аспектов начинаются на ранней стадии проекта и будут продолжаться в течение жизненного цикла тестирования, влияя как фактор на изменение риска. Следует ожидать, что многие части плана и стратегии тестирования изменятся, хотя изменения будут, очевидно, в пределах ограничений проекта, организации или регулирующих норм. Взаимосвязи между общим процессом тестирования, общими подпроцессами тестирования, уровнями/фазами тестирования и типами тестирования более подробно показаны на рисунке 2. Рисунок показывает реализацию общих подпроцессов тестирования на определенных уровнях тестирования и в соответствии с типом тестирования. Общий подпроцесс тестирования может быть реализован: - на уровне или фазе тестирования. То есть каждый уровень тестирования представляет собой определенное приложение общего подпроцесса тестирования (например, фаза покомпонентного тестирования, уровень приемочного испытания); Рисунок 2 - Взаимосвязи между общим подпроцессом тестирования, уровнями тестирования и типами тестирования  Рисунок 2 - Взаимосвязи между общим подпроцессом тестирования, уровнями тестирования и типами тестирования - как тестирование определенного типа. То есть каждый тип тестирования представляет собой определенное приложение общего подпроцесса тестирования (например, тестирование производительности, тестирование удобства использования); - подпроцесс тестирования, соответствующий уровню тестирования, может включать в себя больше одного подпроцесса разного типа тестирования (например, функциональный и тестирование производительности являются частями тестирования системы); - процесс тестирования проекта может состоять из последовательности подпроцессов тестирования (например, тестирование компонента, интеграционное тестирование, тестирование системы и подпроцессы тестирования приемочных испытаний). На рисунке 2 в деталях показаны связи между типами тестирования и показателями качества (как определено в ИСО/МЭК 25010 "Модели качества систем и программного обеспечения"). Каждый тип тестирования ориентирован на один определенный показатель качества. Более подробно связи между типами тестирования и показателями качества рассматриваются в 5.5.3. 5.2.1 Процесс тестирования В настоящем стандарте используется трехуровневая модель процесса, подробно описанная в ИСО/МЭК/ИИЭР 29119-2 и показанная в общем виде на рисунке 3. Модель процесса начинается с организационного управления спецификациями тестирования высокого уровня (организационными спецификациями), такими как Организационная Политика Тестирования и Организационная Стратегия Тестирования. Средний уровень показывает менеджмент тестирования (менеджмент тестирования проекта, менеджмент фазы тестирования, менеджмент типа тестирования), в то время как нижний уровень определяет множество процессов тестирования, используемых в динамическом тестировании. Трехуровневая модель процесса показана на рисунке 3. Рисунок 3 - Многоуровневая связь процессов тестирования  Рисунок 3 - Многоуровневая связь процессов тестирования Политика Тестирования выражает в бизнес-терминах ожидания менеджмента организации и подход к тестированию программного обеспечения. Она ориентирована на руководителей и старших менеджеров, хотя и может быть полезна для каждого, кто связан с тестированием. Политика Тестирования также руководит предпочтительным направлением и динамикой формирования и выполнения Организационной Стратегии Тестирования и процессов тестирования организации. Создание, реализация и поддержка Организационной Политики Тестирования определяется Организационным Процессом Тестирования. Организационная Стратегия Тестирования выражает требования и ограничения для процессов менеджмента тестирования и процессов динамического тестирования, которые должны удовлетворяться для всех выполненных в организации проектов, если они не слишком отличаются по характеру и когда может быть сформулировано несколько Организационных Стратегий Тестирования. Стратегия согласована с Организационной Политикой Тестирования и определяет, как должно быть выполнено тестирование. Создание, реализация и поддержка Организационной Стратегии Тестирования также определяется Организационным Процессом Тестирования. Менеджмент выполняемого тестирования определяется Процессами Менеджмента Тестирования. На основе анализа идентифицированных рисков и ограничений проекта и с учетом Организационной Стратегии Тестирования разрабатывается связанная с проектом стратегия тестирования. Эта стратегия разрабатывается с точки зрения определения необходимого статического и динамического тестирования, укомплектованности персоналом, баланса заданных ограничений (ресурсы и время) с предопределенными охватом и качеством результатов намеченного для выполнения тестирования. Все это записывается в План Тестирования Проекта. Для того чтобы обеспечивать запланированное продвижение тестирования и гарантию соответствующей обработки рисков во время выполнения тестирования, необходимо осуществлять мониторинг. Если в ходе тестирования потребуется внести какие-либо изменения в тестирующие действия, то соответствующему процессу или подпроцессу тестирования должны быть переданы управляющие директивы. Отчеты о Ходе Тестирования могут создаваться регулярно для информирования заинтересованных сторон о прогрессе тестирования в течение всего периода мониторинга и управления. Полный результат тестирования проекта оформляется в виде Отчета Завершения Тестирования Проекта. Процессы Менеджмента Тестирования показаны на рисунке 4. Рисунок 4 - Процессы Менеджмента Тестирования  Рисунок 4 - Процессы Менеджмента Тестирования Полное тестирование проекта обычно разбивается на меньшие подпроцессы тестирования (например, тестирование компонентов, тестирование системы, тестирование удобства использования, тестирование производительности), и ими нужно управлять, их нужно выполнять и о них нужно информировать так же, как в случае тестирования полного проекта. Процессы Менеджмента Тестирования также применимы к подпроцессам тестирования. Примерами планов подпроцессов тестирования являются План Тестирования Системы, План Приемочного Испытания или План Теста Производительности. В подпроцессы тестирования может входить как статическое тестирование, так и динамическое тестирование. Процессы динамического тестирования показаны в общих чертах на рисунке 5 и полностью описаны в ИСО/МЭК/ИИЭР 29119-2. Процессы статического тестирования описаны в других опубликованных стандартах, например ИИЭР 1028. Рисунок 5 - Процессы динамического тестирования  Рисунок 5 - Процессы динамического тестирования Для получения дополнительной информации о любом из процессов тестирования, включая Организационный Процесс Тестирования, Процессы Менеджмента Тестирования и Процесс Динамического Тестирования, следует обратиться к ИСО/МЭК/ИИЭР 29119-2. 5.3 Общие процессы тестирования в жизненном цикле программного обеспечения Программное обеспечение имеет ожидаемый жизненный цикл от начальной его концепции до возможного прекращения его использования. Тестирование программного обеспечения имеет место в более широком контексте разработки и сопровождения программного обеспечения. В 5.3 в качестве примера рассмотрен жизненный цикл разработки программного обеспечения и некоторые связи между его подпроцессами и процессами тестирования. В ИСО/МЭК 12207:2008 подробно рассмотрены жизненные циклы программного обеспечения. В ИСО/МЭК 15288 подробно рассмотрены процессы жизненного цикла системы. Пример жизненного цикла системы показан на рисунке 6. Рисунок 6 - Пример жизненного цикла программного обеспечения  Рисунок 6 - Пример жизненного цикла программного обеспечения Жизненный цикл программного обеспечения обычно состоит из нескольких жизненных подциклов. На рисунке 6 показан жизненный цикл программного обеспечения, зачастую состоящий из одного или более жизненных циклов разработки и одного или более жизненных циклов эксплуатации. Период времени от концепции до первоначальной версии известен как жизненный цикл разработки, который является частью жизненного цикла программного обеспечения. Жизненный цикл разработки управляется и контролируется в проекте разработки. С момента первого запуска система переходит в эксплуатацию (функционирование). Система остается в эксплуатации до момента прекращения использования. Этот период может варьироваться от нескольких часов до нескольких десятилетий. Период функционирования часто состоит из промежутков времени, в течение которых используется определенная версия системы, а в то же время разрабатывается для выпуска новая версия. Разработка любой новой версии должна рассматриваться как самостоятельный проект, что влечет за собой соответствующие требования тестирования. Текущее сопровождение обычно настраивается таким образом, чтобы обеспечить доступность и нормальное функционирование системы. В отдельных случаях возможно тестирование функционирующей системы без соответствующего проекта разработки, например "пробные прогоны" тестов Аварийного Восстановления. В подобных ситуациях также применимы представленные в настоящем стандарте процессы. Тестирование может выполняться для оценки удовлетворения бизнес-требований к приобретаемому программному обеспечению. Основы оценки и тестирования приобретаемого готового коммерческого программного обеспечения (COTS) можно найти в ИСО/МЭК 25051. |