гост. 19621_ГОСТ Р 56920_Определения (1). Системная и программная инженерия
 Скачать 0.52 Mb.
|
|
5.4.3 Использование тестирования на базе рисков в процессах динамического тестирования Профиль рисков используется для осуществления руководства всеми процессами динамического тестирования. В процессе проектирования тестирования риски продукта используются для того, чтобы подсказать тестеру, применение какого метода проектирования тестирования наиболее целесообразно. Он (профиль рисков) может быть использован для определения того, сколько раз необходимо произвести анализ тестирования в ходе процесса проектирования тестирования с приложением больших усилий в областях с более высокими рисками, чем в областях с низким риском. Риск может также быть использован для определения приоритетов наборов функций и, как только они получены, тестовых условий и контрольных примеров. Выполнение динамического тестирования - это деятельность по снижению рисков. Выполнение контрольных примеров снижает риск, поскольку если тест пройден, то и вероятность появления риска обычно ниже и, таким образом, оценка риска снижается. Аналогичным образом, если тест завершился неудачей, то риск может увеличиться. Процесс отчетности об инцидентах тестирования может быть в таких случаях использован для определения того, привел ли неработающий контрольный пример к разрешению проблемы или требуется дальнейшее расследование. 5.5 Подпроцесс тестирования Проект тестирования обычно представляет собой структуру, состоящую из некоторого числа подпроцессов тестирования, опирающихся на стратегию тестирования проекта. Подпроцесс тестирования может быть связан с фазой жизненного цикла программного обеспечения и/или фокусироваться на определенном атрибуте качества. В число подпроцессов тестирования могут быть включены как статическое тестирование, так и динамическое тестирование. Каждый подпроцесс управляется посредством применения к нему процессов менеджмента тестирования. Подпроцесс тестирования начинается с планирования тестирования. Деятельность по мониторингу и управлению тестированием непрерывно осуществляется в ходе всего тестирования, запланированного для подпроцессов тестирования, а в соответствующих случаях информация, полученная из мониторинга, может послужить основанием для пересмотра планирования. Планирование тестирования включает в себя идентификацию цели тестирования, области применения тестирования и рисков, связанных с рассматриваемым подпроцессом тестирования. Результат планирования руководит стратегией подпроцесса тестирования, включая статическое тестирование и динамическое тестирование, запланированные в подпроцессе тестирования. В отдельных случаях то, что обрисовано в общих чертах в стратегии тестирования проекта, может быть использовано непосредственно в стратегии подпроцесса тестирования, но в других случаях необходимы конкретные решения для формирования подпроцесса тестирования на основе определенных рисков, которые должны быть учтены. При определении подпроцесса тестирования важно отметить, какие функции элемента тестирования должны быть проверены, а какие нет. Этим обеспечивается четкость и правильность намерений относительно области применения тестирования. Подпроцесс тестирования, обычно, включает в себя не один раунд динамического тестирования или статического тестирования. В случае если определено только по одному раунду каждого типа тестирования, то может возникнуть необходимость повторить раунд, например, для того, чтобы удовлетворить критериям завершения тестирования. Повторные процессы динамического тестирования обычно называются повторным тестированием и регрессионным тестированием. Повторное тестирование и регрессионное тестирование может быть выполнено для определения того, что изменения, внесенные в рабочий продукт для устранения дефектов, решили проблемы и не привели к возникновению новых дефектов. Дополнительная информация приводится в 5.5.5. Пример общего подпроцесса тестирования показан на рисунке 10. Рисунок 10 - Пример общего подпроцесса тестирования  Рисунок 10 - Пример общего подпроцесса тестирования Число подпроцессов тестирования в проекте тестирования зависит от стратегии тестирования и фаз жизненного цикла, определенных для всего проекта. Оно не зависит от жизненного цикла разработки (то есть последовательный или эволюционный цикл разработки не определяет требуемое число подпроцессов тестирования). Примеры подпроцессов тестирования детально представлены в приложении D. Цель тестирования, элемент тестирования, базис тестирования и риски специфичны для подпроцесса тестирования и определяют выбор тестирующих действий, выполняемых в подпроцессе тестирования, а также применяемые методы проектирования тестирования. Примеры целей тестирования, элементов тестирования, базиса тестирования и методов проектирования тестирования представлены далее. 5.5.1 Цели тестирования Тестирование выполняется, чтобы достигнуть одной и большего числа целей. Цели тестирования, охватываемые настоящим стандартом, включают в себя: - предоставление информации для действий менеджмента рисков; - предоставление информации о качествах продукта; - оценку того, оправдал ли продукт надежды заинтересованной стороны; - оценку того, были ли дефекты корректно устранены без неблагоприятных побочных эффектов; - оценку корректной реализации изменений без неблагоприятных побочных эффектов; - оценку выполнения требований (то есть нормативных, проектных, договорных и т.д.). Тестирование завершается в случае достижения цели тестирования для функции или набора функций. Тип проверяемой функции определяет, какого рода тестирование необходимо. Функции имеют показатели качества, которые должны соответствовать требованиям. Состав показателей качества для функции или набора функций позволяет тестеру определять, какие типы тестирования могут быть использованы для достижения цели тестирования. Вполне вероятно, что лишь некоторые цели тестирования приемлемы для конкретных подпроцессов тестирования или типов элементов тестирования. Определение соответствующих целей тестирования для элемента тестирования может помочь в выборе применения корректных подпроцессов тестирования. Например, при тестировании готового коммерческого продукта цель тестирования для оценки того, что дефекты устранены, не может быть принята, поскольку ожидается, что поставщик уже завершил надежное тестирование для поиска и устранения дефектов. Поэтому в таких условиях уместно использовать подпроцесс приемочных испытаний для достижения цели тестирования, то есть удостовериться в том, что изменения реализованы без неблагоприятных побочных эффектов. 5.5.2 Элемент тестирования Тестирование выполняется на элементе тестирования против того, что ожидается от элемента тестирования. Это ожидание в соответствии с 5.5.4 называется базисом тестирования. Элемент тестирования - это результат действия, такого процесса, как менеджмент, разработка, обслуживание, самого тестирования или другого процесса поддержки. Примеры элементов тестирования включают в себя: - связанные с кодом элементы тестирования: - исполнимый компонент программного обеспечения; - подсистему; - полную систему; - связанные с документацией элементы тестирования: - план, например план проекта, план тестирования или план менеджмента конфигурации; - спецификацию требований; - архитектурный проект; - детальный проект; - исходный код; - руководство, например руководство пользователя или руководство по установке; - спецификации тестирования и процедуры тестирования. Последний элемент вышеприведенного списка означает, что, несмотря на то, что спецификации тестирования и процедуры тестирования разрабатываются тестерами, они также должны быть подвергнуты тестированию (статическому тестированию), поскольку они также могут быть не без дефектов. 5.5.3 Тестирование показателей качества ИСО/МЭК 25010 "Модели качества систем и программных продуктов" определяет модель качества программного обеспечения. Эта модель включает в себя восемь показателей качества, которые определяют атрибуты качества элемента тестирования. Тестирование представляет собой действие, которое измеряет важные показатели качества конкретного элемента тестирования. К этим восьми показателям качества относятся: - функциональная пригодность: степень, с которой продукт или система обеспечивают выполнение функции в соответствии с заявленными и подразумеваемыми потребностями при использовании при указанных условиях; - уровень производительности: производительность относительно суммы использованных при определенных условиях ресурсов; - совместимость: способность продукта, системы или компонента обмениваться информацией с другими продуктами, системами или компонентами и/или выполнять требуемые функции при совместном использовании одних и тех же аппаратных средств или программной среды; - удобство использования: степень, с которой продукт или система могут быть использованы определенными пользователями для достижения конкретных целей с эффективностью, результативностью и удовлетворенностью в заданном контексте использования; - надежность: степень выполнения системой, продуктом или компонентом определенных функций при указанных условиях в течение установленного периода времени; - защищенность: степень защищенности информации и данных, обеспечиваемая продуктом или системой путем ограничения доступа людей, других продуктов или систем к данным в соответствии с типами и уровнями авторизации; - сопровождаемость: результативность и эффективность, с которыми продукт или система могут быть модифицированы предполагаемыми специалистами по обслуживанию; - переносимость: степень простоты эффективного и рационального переноса системы, продукта или компонента из одной среды (аппаратных средств, программного обеспечения, операционных условий или условий использования) в другую. Для проверки показателя качества может потребоваться реализация подпроцесса тестирования. Например, планирование и выполнение тестирования для измерения показателя качества защищенности могут потребовать реализации подпроцесса тестирования защищенности (тестирования защищенности). Каждый из вышеперечисленных показателей качества имеет ряд дочерних характеристик, которые для обеспечения полного представления показателя качества могут быть протестированы. Следует также помнить, что не все показатели качества применимы ко всем системам, например переносимость не может быть важна для одноразовой встроенной системы. Необходимо обратить внимание на то, что приведенный выше перечень показателей качества не всегда является исчерпывающим, в отдельных случаях может потребоваться определение соответствующих дополнительных показателей качества для конкретного элемента тестирования. В практике тестирования принято разделение тестирования на тестирование функционального показателя качества, называемое "функциональным тестированием", и тестирование других показателей качества, называемое "нефункциональным тестированием". Тип тестирования, используемого для определения показателя качества, отличного от функциональной пригодности, обычно называют нефункциональным типом тестирования и к нему можно отнести такие типы тестирования, как нагрузочное тестирование, стрессовое тестирование, тестирование на возможность проникновения, тестирование удобства использования и т.д. При разработке Плана Тестирования менеджер по тестированию должен учесть все показатели качества. Акцент, сделанный на тестирование любого отдельного показателя качества и его дочерних характеристик, возможно, изменится в зависимости от таких аспектов, как: - профиль риска разрабатываемой системы; например, критичное к защищенности приложение может требовать особой надежности; - отрасль промышленности, для которой разрабатывается система; например, банковское приложение может требовать особой защищенности. 5.5.4 Базис тестирования В настоящем стандарте термин "Базис тестирования" использован для совокупности знаний (в любой форме), исходя из которой может планироваться, разрабатываться, прогнозироваться, реализовываться и управляться тестирование элемента. Базис тестирования может включать в себя выбор режима тестирования, критерии успешного/неуспешного прохождения, входы, среду, практики и методики. Помимо прочего, природа базиса тестирования варьируется по фазам жизненного цикла разработки. Примерами базиса тестирования являются: - ожидания по формату и содержанию документации, обычно в форме стандартов и/или контрольных списков; - ожидания потребителя/пользователя по программной системе, новой или уже существующей, обычно спецификаций требований в письменной форме. Они могут быть представлены как функциональные/нефункциональные описания с употреблением глагола "должен", содержащие варианты использования, истории пользователя или другие формы неформально или формально записанные требования. Сюда могут быть включены нормативные требования, которые должны соблюдаться для определенных типов продуктов, например, для критичного к безопасности программного обеспечения для фармацевтической промышленности или для транспортных систем, таких как поезд или самолет; - опыт тестера или экспертов в другой предметной области по работе с функциями, необходимыми пользователям, или с историей продукта; - ожидания по прямым и/или косвенным интерфейсам между компонентами программной системы и/или по сосуществованию компонентов программной системы, обычно в форме проекта архитектуры в виде схем и/или формального письменного определения протокола; - ожидания по реализации компонентов программной системы в коде, обычно в форме детального проекта. Следует обратить внимание на то, что один и тот же элемент может быть элементом тестирования в одном подпроцессе тестирования и базисом тестирования в другом подпроцессе тестирования. Спецификация требований может, например, быть элементом тестирования подпроцесса статического тестирования и базисом тестирования дальнейшего подпроцесса тестирования системы. Требования можно разделить на две основные категории, а именно: - функциональные требования - определение того, что элемент должен сделать согласно показателю качества функциональной пригодности, представленному в ИСО/МЭК 25010 "Модели качества систем и программного обеспечения"; - нефункциональные требования - определение того, как хорошо функциональность должна проявиться и вести себя согласно другим показателям качества, представленным в ИСО/МЭК 25010 "Модели качества систем и программного обеспечения". Нефункциональные требования частично или полностью связаны с функциональностью, и обычно функциональные требования связаны с соответствующими группами нефункциональных требований или с отдельными из них. 5.5.5 Повторное и регрессионное тестирование Повторное тестирование проверяет, исправило ли разрешение инцидента первичную проблему. Повторное тестирование часто выполняется простым повтором контрольного примера, который привел к неожидаемому результату и который в свою очередь привел к идентификации первичной проблемы. Однако для эффективного повторного тестирования могут быть определены и проанализированы новые тестовые условия, а также разработаны новые контрольные примеры. Регрессионное тестирование представляет собой выборочное тестирование ранее протестированной системы или компонента, для того чтобы удостовериться, что изменения не вызвали непреднамеренных побочных эффектов и что система или компонент все еще соответствуют своим исходным требованиям. Цель регрессионного тестирования состоит в том, чтобы установить факт того, что изменения не привели к возникновению дефектов в неизмененных частях системы. При планировании тестирования необходимо учесть как регрессионное тестирование, так и повторное тестирование, поскольку обычно для завершения подпроцесса тестирования требуется и то и другое. Необходимо в графике тестирования предусмотреть время для обоих действий. 5.5.6 Методика проектирования тестирования Существуют методики проектирования тестирования как для статического, так и для динамического тестирования. Цель методики проектирования тестирования заключается в оказании помощи тестерам элементов тестирования в максимально эффективном и продуктивном нахождении дефектов. В статическом тестировании это обычно достигается идентификацией очевидных дефектов ("проблем") в документальных элементах тестирования или аномалий в исходном коде. Динамическое тестирование выявляет дефекты, вызывая отказы исполнимых элементов тестирования. 5.5.6.1 Методы проектирования статического тестирования Статическое тестирование может включать в себя различные действия, например статический анализ кода, анализ прослеживаемости перекрестных ссылок документа, анализ для поиска проблем и предоставления другой информации о программных продуктах. Статическое тестирование является одной из форм тестирования. Оно является частью стратегии тестирования и как таковое попадает в область применения настоящего стандарта. Существуют стандарты, где описаны методы, которые можно использовать для выполнения статического тестирования. В данном разделе рассматривается понятие статического тестирования и его связь с другими стандартами. Методики анализа и процессы, используемые в разработке программного обеспечения, определены в ИИЭР 1028:2008. Действия верификации и валидации описаны в ИИЭР 1012 (см. приложение А). Основная цель любого из методов проектирования статического тестирования состоит в том, чтобы найти дефекты, но у них есть и вторичные цели, например сквозной контроль может использоваться для обмена знаниями, а технический анализ - для достижения консенсуса. Инспекция помимо прочего может служить цели предотвратить будущие дефекты. Выбор типа(ов) методики проектирования статического тестирования в любой конкретной ситуации зависит не столько от типа элемента тестирования, сколько от учитываемых рисков (чем выше риск, тем более формальная методика проектирования статического тестирования рекомендуется) и вторичных целей методики проектирования статического тестирования. Хотя статическое тестирование часто необходимо в рамках выполнения тестирования программного обеспечения проекта или организации, оно рассмотрено только в серии стандартов ИСО/МЭК/ИИЭР 29119 "Тестирование программного обеспечения" (более подробно в настоящем стандарте) и в вышеупомянутых публикациях. Методы и процессы статического тестирования не рассматриваются в других стандартах серии ИСО/МЭК/ИИЭР 29119 "Тестирование программного обеспечения". 5.5.6.2 Методы проектирования динамического тестирования Методы проектирования тестирования для динамического тестирования - это методы идентификации тестовых условий, элементов тестового покрытия и впоследствии контрольных примеров, которые будут выполняться на элементе тестирования. Методы проектирования динамического тестирования классифицированы на три основные категории на основе того, как получаются входные данные для тестирования. Эти категории методов основаны на спецификации, структуре и опыте. В ИСО/МЭК/ИИЭР 29119-4 подробно описан каждый из методов проектирования динамического тестирования. Основанные на спецификации методы проектирования тестирования используются для получения контрольных примеров из базиса тестирования, определяющего ожидаемое поведение элемента тестирования. При использовании этих методов входные данные для тестирования контрольного примера и ожидаемый результат получаются из базиса тестирования. Выбор, какие из основанных на спецификации методов проектирования тестирования использовать в каждой конкретной ситуации, зависит от природы базиса тестирования и/или элемента тестирования, и от присущих рисков. Примерами основанных на спецификации методов проектирования тестирования, охватываемых ИСО/МЭК/ИИЭР 29119-4, являются Анализ Граничных Значений, Тестирование Изменения Состояния и Тестирование Таблицы Решений. Основанные на структуре методы проектирования тестирования используются для получения контрольных примеров из структурной характеристики, например структуры исходного кода или структуры меню. Если эти методы применяются к исходному коду приложения, то ожидаемые результаты для контрольных примеров получаются из базиса тестирования. Выбор, какие из основанных на структуре методов проектирования тестирования использовать в каждом конкретном случае, зависит от природы базиса тестирования и от присущих рисков. Эти методы определены и подробно описаны в ИСО/МЭК/ИИЭР 29119-4 "Методы тестирования". Примерами основанных на структуре методов проектирования тестирования, охватываемых ИСО/МЭК/ИИЭР 29119-4, являются Тестирование Ветвей, Тестирование Условия и Тестирование Потока Данных. 5.6 Методики тестирования |