Тестирование программных средств
ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения
Функциональное тестирование
Software and systems engineering. Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1. Информация об изменениях к настоящему стандарту публикуется в ежегодном по состоянию на 1 января текущего года информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра замены или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет www. Международная организация по стандартизации ИСО и Международная электротехническая комиссия МЭК образуют специализированную систему для всемирной стандартизации. Национальные органы по стандартизации, которые являются членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, созданные соответствующей организацией для определенных областей технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в сферах, представляющих взаимный интерес. Другие международные правительственные и неправительственные организации, связанные с ИСО и МЭК, также принимают участие в работе по разработке стандартов. Документы стандартов Института Инженеров по Электротехнике и Радиоэлектронике ИИЭР разработаны в сообществах и комитетах по координации стандартов ИИЭР, входящих в состав бюро стандартов ассоциации стандартов ИИЭР. ИИЭР разрабатывает свои стандарты на основе одобренного Американским национальным институтом стандартов консенсусного процесса разработки, который для достижения конечного результата объединяет различные точки зрения и интересы добровольцев. Добровольцы не обязательно являются сотрудниками института и работают на безвозмездной основе. При том, что ИИЭР курирует процесс и устанавливает правила обеспечения справедливости в консенсусном процессе разработки, ИИЭР не проводит независимые оценку, испытание или проверку точности какой-либо информации, входящей в состав своих стандартов. Основная задача совместного технического комитета состоит в подготовке международных стандартов. Проекты международных стандартов, принятые совместным техническим комитетом, распространяются среди национальных органов по стандартизации для вынесения решения. Следует обратить внимание на то, что при внедрении настоящего стандарта может потребоваться использование предмета, защищенного патентными правами. При публикации настоящего стандарта не рассматривались вопросы существования или соответствия каких-либо связанных со стандартом патентных прав. Пользователи настоящего стандарта должны учитывать то, что определение действия каких-либо патентных прав и риска нарушения таких прав полностью лежит на их собственной ответственности. Дополнительная информация может быть получена в ИСО или ассоциации стандартов ИИЭР. Тестирование программного обеспечения" состоит из следующих частей: Понятия и определения; - Часть 2. Процессы тестирования; - Часть 3. Документация тестирования; - Часть 4. Существование множества различных типов программного обеспечения, организаций программного обеспечения и методологий общеизвестно. Предметные области программного обеспечения включают в себя информационные технологии ИТ , персональные ПК , встроенные, мобильные, научные компьютеры и многие другие категории. Разнообразие организаций программного обеспечения простирается от малого до большого размера, от локальных до глобальных, от коммерческих до сервис-ориентированных. Методология программного обеспечения включает различные подходы: Все эти и другие факторы оказывают влияние на тестирование программного обеспечения. Настоящая серия стандартов предназначена для поддержки тестирования в разных контекстах. В настоящем стандарте представлены общие понятия тестирования программного обеспечения. Описывается роль тестирования программного обеспечения в организационном контексте и контексте проекта. Тестирование программного обеспечения рассматривается в контексте общего жизненного цикла программного обеспечения. Представлен способ, который позволяет устанавливать процессы и подпроцессы тестирования программного обеспечения для определенных элементов тестирования или с определенными целями. Рассматривается, как тестирование программного обеспечения вписывается в различные модели жизненного цикла. Демонстрируется использование различных методов планирования тестирования, а также то, как может быть использована автоматизация для поддержки тестирования. Обсуждается роль тестирования в управлении дефектами. Приложение А описывает роль тестирования в более широкой предметной области верификации и валидации. Приложение В представляет краткое введение в метрики, используемые для мониторинга и управления тестированием. Приложение С содержит ряд примеров, показывающих, как применить настоящий стандарт в различных моделях жизненного цикла. Приложение D предоставляет примеры подпроцессов тестирования в деталях. Приложение Е предоставляет дополнительную информацию о ролях и обязанностях, с которыми обычно имеют дело группы тестирования и независимые тестеры. В конце стандарта представлен элемент "Библиография". Тестирование - это основной подход к обработке рисков в разработке программного обеспечения. Этот стандарт определяет подход к тестированию, базирующийся на рисках. Тестирование на базе рисков - это рекомендуемый подход к разработке стратегии и менеджмента тестирования, который позволяет расставлять приоритеты и акценты в тестировании. В настоящем стандарте представлены определения и понятия тестирования программного обеспечения. Настоящий стандарт носит информативный характер и не требует какого-либо соответствия. Настоящий стандарт не требует каких-либо нормативных ссылок. Стандарты и документы, полезные для применения и интерпретации настоящего стандарта, перечислены в элементе "Библиография". В этом разделе представлены только термины, критически важные для понимания этих стандартов. Представление полного списка терминов тестирования не является целью данного раздела. Он доступен на веб-сайте: Тип тестирования удобства использования, предназначенный для оценки степени возможности управления элементом тестирования пользователями с самыми разными характеристиками и способностями. Совокупность поведения или условий элемента тестирования, или совокупность условий, связанных данных или тестовой среды, полученные в результате выполнения теста. Пример - Вывод на аппаратные средства, изменения в данных, отчеты и отправленные информационные сообщения. Тип тестирования надежности, который измеряет степень состояния системы, до которой в случае отказа может быть произведено восстановление из резервной копии при указанных параметрах времени, стоимости, полноты и точности. Тип тестирования уровня производительности для оценки уровня, при котором с увеличением нагрузки числа пользователей, транзакций, элементов данных и т. Тип тестирования, который измеряет степень того, насколько удовлетворительно элемент тестирования может функционировать параллельно с другими независимыми продуктами в общей среде сосуществование и, по мере необходимости, обменивается информацией с другими системами или компонентами функциональная совместимость. Тип оператора выбора одного из двух или более возможных результатов для определения выбора конкретного набора действий. Тестирование, при котором требуется выполнение элемента тестирования. Тип тестирования уровня производительности для определения того, может ли элемент тестирования постоянно выдерживать требуемую загрузку в течение установленного периода времени. Подмножество области значений переменной или совокупности переменных внутри элемента тестирования или на его интерфейсах такое, что можно обоснованно ожидать того, что все значения подмножества будут обработаны элементом тестирования подобным образом то есть они могут считаться "эквивалентными". Доля идентифицированных разделов эквивалентности элемента тестирования, которая покрывается набором тестов. Примечание - В большинстве случаев идентификация разделов эквивалентности субъективна особенно в разбиении "недопустимых" разделов ; таким образом, окончательный подсчет числа разделов эквивалентности для элемента тестирования может быть невозможен. Метод проектирования тестирования, при котором контрольные примеры разработаны таким образом, чтобы проверить разделы эквивалентности с помощью одного или более представительных элементов каждого раздела. Метод проектирования тестирования, в котором контрольные примеры получены на основе знаний тестера о прошлых отказах или общих знаний о видах отказа. Примечание - Соответствующие знания могут исходить из личного опыта или могут быть получены, например, из базы данных дефектов или "таксономии ошибок". Характерное предсказанное поведение элемента тестирования при указанных условиях на основе его спецификации или другого источника. Тестирование, основанное на опыте, при котором тестер спонтанно разрабатывает и выполняет тестирования на основе существующих соответствующих знаний тестера, предшествующих исследований элемента тестирования включая и результаты предыдущих тестирований и эвристических "эмпирических правил" для общего поведения программного обеспечения и типов отказа. Примечание - Исследовательское тестирование направлено на выявление скрытых свойств включая и скрытое поведение , которые сами по себе, с одной стороны, вполне возможно, безобидны, но, с другой стороны, могут повлиять на другие свойства тестируемого программного обеспечения и тем увеличить риск того, что программное обеспечение перестанет работать. Совокупность, в которую входят тестовые условия проверяемого элемента и могут быть включены риски, требования, функции, модели и т. Примечание - Это может быть набор всех функций элемента полный набор его функций или подмножество, определенное для конкретной цели совокупность функциональных возможностей и т. Документация по инциденту о его проявлении, природе и состоянии. Тип тестирования переносимости для оценки того, могут ли должным образом элемент тестирования или совокупность элементов тестирования быть установлены во всех указанных средах. Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при ожидаемых условиях переменной загрузки, обычно для ожидаемых условий низкого, типичного и пикового использования. Тип тестирования, проводимого для оценки степени эффективности и продуктивности возможных изменений элемента тестирования. Руководящий документ, в котором описаны назначение, цели, полная предметная область применения тестирования в организации и определено, почему выполняется тестирование и что ожидается получить в результате. Примечание - В общем случае для конкретного контекста предпочтительно иметь Организационную Политику Тестирования максимально короткой. Это может быть набор всех функций элемента полный набор его функций или подмножество, определенное для конкретной цели совокупность функциональных возможностей и т. Процесс тестирования для разработки и управления организационными спецификациями тестирования. Документ, в котором представлена информация о тестировании для организации, то есть информация, которая не специфична для проекта. Пример - Наиболее общими примерами Организационной Спецификации Тестирования являются Организационная Политика Тестирования и Организационная Стратегия Тестирования. Документ, в котором изложены универсальные требования к тестированиям, которые будут выполняться для всех проектов организации, а также подробности того, как должно производиться тестирование. Правила решения, используемые для определения того, прошли ли тестирование элемент тестирования или функция элемента тестирования или перестали работать после тестирования. Тип тестирования, проводимого для оценки степени, в которой элемент тестирования выполняет свои определенные функции при заданных ограничениях времени и других ресурсах. Тип тестирования, проводимого для оценки простоты переноса элемента тестирования из одних аппаратных средств или программной среды в другие, включая уровень его изменений, необходимых для выполнения в средах различных типов. Тип тестирования функциональной пригодности, проводимый для определения того, отвечают ли требованиям пользователя и обеспечивают ли цель их применения процедурные инструкции по взаимодействию с элементом тестирования или по использованию его выходных данных. Риск того, что продукт может иметь дефект в некотором определенном аспекте его функций, качества или структуры. Риск, относящийся к менеджменту проекта. Пример - Отсутствие укомплектования персоналом, строгие крайние сроки, изменения требований. Тестирование после изменений элемента тестирования или его рабочей среды для определения того, происходят ли регрессивные отказы. Примечание - Достаточное количество регрессионных тестов зависит от тестируемого элемента и от изменений этого элемента или его рабочей среды. Тип тестирования, проводимый для оценки возможности элемента тестирования выполнять свои требуемые функции, включая оценку частоты, с которой происходят отказы при использовании в установленных условиях в течение заданного периода времени. Повторное выполнение контрольных примеров, для которых ранее был получен результат "сбоя" для оценки эффективности произведенных корректирующих действий. Примечание - Используется также термин "тестирование подтверждения". Тестирование, для которого менеджмент, выбор, расстановка приоритетов и использование действий и ресурсов тестирования преднамеренно основаны на базе проанализированных рисков соответствующих типов и уровней. Класс методик проектирования тестирования, при которых разрабатываются тестирования для выполнения конкретных сценариев. Примечание - Сценарий может быть историей пользователя, примером использования, операционным понятием или последовательностью событий, с которыми программное обеспечение может встретиться и т. Динамическое тестирование, в котором действия тестера предписаны записанными в контрольном примере инструкциями. Примечание - Этот термин обычно применяется для тестирования, выполняемого вручную, а не для выполнения автоматизированного сценария. Тип тестирования, проводимый для оценки степени защищенности элемента тестирования и связанных с ним данных и информации от доступа посторонних лиц или систем для использования, чтения или изменения их при том, что доверенным лицам или системам доступ к ним обеспечивается. Тестирование, основным базисом которого являются внешние вводы и выводы элемента тестирования, обычно на основе спецификации, а не ее реализация в исходном коде или исполнимом программном обеспечении. Примечание - Синонимами тестирования на основе являются тестирование методом "черного ящика" и тестирование закрытого ящика. Процент совокупности всех исполнимых операторов элемента тестирования, которые покрываются набором тестов. Метод проектирования тестирования, при котором создаются контрольные примеры для выполнения отдельных операторов элемента тестирования. Тестирование, при котором элемент тестирования анализируется с использованием совокупности критериев качества или других свойств без выполнения кода. Пример - Ревизия, статический анализ. Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при условиях загрузки, выше ожидаемой или указанной в требованиях к производительности, или при доступности ресурсов, ниже минимальной, указанной в требованиях. Динамическое тестирование, для которого тесты являются результатом анализа структуры элемента тестирования. Критерии, используемые для того, чтобы временно остановить все или часть тестирующих действий. Свод знаний, используемых в качестве базы проекта тестирования и контрольных примеров. Примечание - Базис тестирования может иметь форму документов, таких как спецификация требований, спецификация проекта или спецификация модуля, но может также представлять собой недокументированное понимание требуемого поведения. Совокупность предварительных условий контрольного примера, входов включая действия, где это применимо и ожидаемых результатов, разработанных для управления выполнением элемента тестирования для достижения целей тестирования, включая корректную реализацию, идентификацию ошибок, проверку качества и получение другой значимой информации. Документация ряда одного или большего количества контрольных примеров. Процесс менеджмента тестирования, необходимый для обеспечения доступности полезных активов тестирования для дальнейшего использования, обеспечения удовлетворительного состояния тестовых сред, гарантии документирования и передачи соответствующим заинтересованным сторонам результатов тестирования. Отчет, в котором представлена сводка выполненного тестирования. Примечание - Иногда также называют сводным отчетом тестирования. Тестируемый аспект компонента или системы, такой как функция, транзакция, возможность, атрибут качества или структурный элемент, идентифицированные как базис тестирования. Примечание - Тестовые условия могут быть использованы для получения элементов покрытия или же могут сами по себе образовывать элементы покрытия. Степень, выраженная в процентах, в которой специфицированные элементы тестового покрытия были проверены контрольным примером или контрольными примерами. Атрибут или комбинация атрибутов, которые являются производными одного или более тестовых условий, полученными посредством методики проектирования тестирования, которая позволяет оценить основательность выполнения теста. Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования. Примечание - Тестовые данные могут храниться в тестируемом продукте например, в массивах, плоских файлах или базе данных или могут быть доступны из внешних источников, или предоставлены такими источниками, как другие системы, другие компоненты системы, устройства или операторский персонал. Документ, описывающий состояние каждого требования к тестовым данным. Процесс тестирования для получения и определения контрольных примеров и процедур тестирования. Документ, определяющий функции, которые будут проверены, и соответствующие тестовые условия. Действия, понятия, процессы и шаблоны, необходимые для создания модели тестирования, которая используется при определении тестовых условий элемента тестирования, для получения соответствующих элементов тестового покрытия, а далее для разработки или выбора контрольных примеров. Различные средства, аппаратное и программное обеспечение, встроенное микропрограммное обеспечение, процедуры и документация, предназначенные или используемые для выполнения тестирования программного обеспечения. Примечание - Тестовая среда может содержать в себе другие среды, необходимые для выполнения конкретных подпроцессов тестирования например, тестовая среда объекта, среда теста производительности и т. Документ, описывающий выполнение всех требований к тестовой среде. Описание необходимых свойств тестовой среды. Процесс динамического тестирования для установки и поддержания требуемой тестовой среды. Процесс выполнения теста на элементе тестирования, приводящий к фактическим результатам. Документ, в который записываются детали выполнения одной или более процедур тестирования. Процесс динамического тестирования для выполнения процедур тестирования, созданных в процессе разработки и реализации тестирования в подготовленной тестовой среде, и записи результатов. Процесс динамического тестирования для создания отчетов для соответствующих заинтересованных сторон о проблемах, требующих дальнейших действий, которые были идентифицированы во время процесса выполнения теста. Рабочий продукт, который является объектом тестирования. Пример - Система, элемент программного обеспечения, документ требований, спецификация проекта, руководство пользователя. Конкретная реализация подпроцесса тестирования. Пример - Как подпроцессы тестирования можно рассматривать следующие общие уровни тестирования: Примечание - Синонимом уровня тестирования является фаза тестирования. Планирование, составление графика, оценка, мониторинг, отчетность, управление и выполнение действий по тестированию. Процесс тестирования, содержащий подпроцессы, необходимые для менеджмента проекта тестирования. Процесс менеджмента тестирования для обеспечения соответствия выполнения тестирования плану тестирования и организационным спецификациям тестирования. Определенная реализация подпроцесса тестирования. Подробное описание требуемых целей тестирования, средств и расписания их достижения, предназначенное для координации тестирующих действий для отдельного элемента тестирования или совокупности элементов тестирования. Процесс менеджмента тестирования, используемый для выполнения планирования тестирования и разработки планов тестирования. Примечание - Методики тестирования иногда называются подходом к тестированию. Последовательность контрольных примеров в порядке выполнения и любые связанные действия, которые могут потребоваться, чтобы установить начальные предпосылки и успешно выполнить завершающие действия после окончания тестирования. Примечание - Процедуры тестирования включают в себя подробные инструкции для выполнения одного или более набора контрольных примеров, выбранных для последовательного выполнения, а также для установки общих исходных условий, обеспечения входа и оценки фактического результата для каждого выбранного контрольного примера. Документ, определяющий одну или более процедур тестирования, представляющих собой наборы контрольных примеров, которые будут выполняться с определенной целью. Спецификацию процедуры тестирования для автоматизированного тестового прогона обычно называют сценарием тестирования. Обеспечивает информацию о качестве программного продукта, зачастую состоит из множества действий, сгруппированных в один или несколько подпроцессов тестирования. Пример - Процесс тестирования для определенного проекта может состоять из множества подпроцессов, например подпроцесса тестирования системы, подпроцесса планирования тестирования часть большего процесса менеджмента тестирования или подпроцесса статического тестирования. Индикатор того, прошел ли определенный контрольный пример успешно или нет, то есть соответствует ли фактический результат элемента тестирования ожидаемому результату или наблюдались отклонения. Спецификация процедуры тестирования для ручного или автоматизированного тестирования. Один или совокупность нескольких контрольных примеров с общими ограничениями на их выполнение. Пример - Определенная тестовая среда, специализированные знания проблемной области или определенная цель. Подробная документация проекта тестирования, контрольных примеров и процедур тестирования для конкретного элемента тестирования. Примечание - Спецификация тестирования может быть представлена одним документом, набором документов или другими способами, например записями базы данных и документами. Отчет, предоставляющий информацию о состоянии тестирования, которое выполняется в указанный отчетный период. Часть Плана Тестирования, в которой описан подход к тестированию определенного проекта тестирования или процессам и подпроцессам тестирования. Процессы менеджмента тестирования и процессы динамического и статического тестирования, используемые для выполнения определенного уровня тестирования например, тестирование системы, приемочные испытания или определенного типа тестирования например, тестирование удобства использования, тестирование производительности обычно в контексте полного процесса тестирования для проекта тестирования. Примечание - В подпроцесс тестирования могут быть включены один или несколько типов тестирования. Обычно, в зависимости от используемой модели жизненного цикла, подпроцессы тестирования также называют фазами тестирования, уровнями тестирования, этапами тестирования или задачами тестирования. Документ, электронная таблица или другой автоматизированный инструмент, используемые для идентификации в документации и программном обеспечении связанных элементов, таких как требования соответствующего тестирования. Совокупность тестирующих действий, которая фокусируется на определенных показателях качества. Примечание - Тип тестирования может быть выполнен одиночным подпроцессом тестирования или несколькими подпроцессами тестирования например, тестирование производительности, выполненное в ходе подпроцесса покомпонентного тестирования и также выполненное в ходе подпроцесса тестирования системы. Примеры - Тестирование защищенности, функциональное тестирование, тестирование удобства использования и тестирование производительности. Примечание - Действия тестирования могут включать в себя планирование, подготовку, выполнение, создание отчетов и менеджмент, поскольку все они направлены на тестирование. Артефакты, произведенные во время процесса тестирования, требуемые для планирования, разработки и выполнения тестирования. Примечание - В средства тестирования могут входить документация, сценарии, входные данные, ожидаемые результаты, файлы, базы данных, среда и любое дополнительное программное обеспечение или утилиты, используемые в ходе тестирования. Динамическое тестирование, в котором действия тестера определены инструкциями, записанными в контрольном примере. Тип тестирования уровня производительности, проводимого для оценки способности элемента тестирования обработать определенные объемы данных обычно равных или близких к максимальным указанным потенциальным возможностям с точки зрения потенциальных возможностей пропускной способности, емкости памяти или того и другого. Необходимость тестирования программного обеспечения может быть продиктована следующими условиями: Общеизвестно, что создать совершенное программное обеспечение невозможно. Поэтому прежде чем программное обеспечение будет передано пользователям, его необходимо протестировать, чтобы в производстве программного обеспечения снизить риск ошибок, оказывающих негативное влияние на его функционирование. В равной степени необходимо обеспечить качественное выполнение тестирования программного обеспечения. Ошибки или допущенные дефекты обычно имеют место и неизбежны. Опечатка или ошибка, сделанная человеком, приводит к возникновению дефекта в продукте, над которым человек работает например, спецификация требований или компонент программного обеспечения. Дефект не оказывает влияния на функционирование программного обеспечения до тех пор, пока он не будет обнаружен при эксплуатации программного обеспечения. Однако если дефект обнаружен в реальных условиях, когда продукт уже сдан в эксплуатацию, то это может привести к тому, что продукт не будет удовлетворять законным потребностям пользователя. Последствия программной ошибки для пользователя могут быть серьезны. Динамическое тестирование является необходимым, но не достаточным условием, чтобы обеспечить приемлемую уверенность в том, что программное обеспечение будет функционировать, как задумано. В сочетании с эффективными действиями динамического тестирования необходимо произвести дополнительные действия статического тестирования, такие как экспертная оценка и статический анализ. Основными целями тестирования являются: Вышеупомянутая информация может использоваться в нескольких целях, включая: Качество продукта имеет много аспектов, включая соответствие спецификациям, отсутствие дефектов и удовлетворение продукта требованиям пользователей. Тестирование программного обеспечения должно быть направлено на предоставление информации о программном продукте и нахождение максимально возможного числа дефектов на возможно ранних этапах процесса разработки при заданных ограничениях стоимости и графика разработки. Основные положения тестирования заключаются в следующем: В настоящем стандарте и во многих областях промышленности такое тестирование называют статическим тестированием, хотя в других стандартах например, в ИИЭР оно может называться анализом, пошаговым разбором или проверкой. Для статического тестирования настоящий стандарт подтверждает и определяет роль тестера в этих действиях, даже если они могут быть выполнены другими группами в рамках проекта или определены другими стандартами, не относящимися к тестированию. Это связано с тем, что действия статического тестирования считаются крайне важными для полного тестирования жизненного цикла и, как показала практика, выполнение тестирования критически важно для раннего обнаружения дефектов, снижения полной стоимости проекта и обеспечения лучшего удовлетворения требования графика; - статическое тестирование может также включать в себя использование инструментов статического анализа, которые находят дефекты в коде или документах без выполнения кода например, компилятор, цикломатический анализатор сложности или анализатор защищенности кода ; - динамическое тестирование представляет собой нечто большее, чем "просто" выполнение исполнимых элементов тестирования, сюда входят также как действия подготовки, так и последующие действия. В частности, рассматривается тестирование программного обеспечения, которое является основным действием при верификации и валидации. Настоящий стандарт ориентирован только на тестирование и в нем не рассматриваются другие действия валидации и верификации например, анализ валидации и верификации, формальные методы. Для обеспечения полной валидации и верификации продукта организация в составе своей комплексной технической программы должна использовать настоящий стандарт совместно с другими стандартами. Иерархия действий верификации и валидации приводится в приложении А. Тестеры должны осознать, что исчерпывающее тестирование невозможно и что тестирующие действия должны быть направлены на возможно лучшее выполнение задач тестирования для элемента тестирования. Тестирование на базе рисков - это подход, при котором риск используется для координации усилий тестирования. Тестирование на базе рисков рассматривается в 5. Хотя эвристика и может использоваться для разрешения проблем, в отдельных случаях она ненадежна в том смысле, что может не решить задачу или решить ее только частично. На эвристике основывается значительная часть тестирований систем и программного обеспечения. Например, эвристика полезна при создании модели тестируемой системы, однако она не может моделировать систему в полной мере, и поэтому дефекты в системе не могут быть выявлены даже при том, что тестирование кажется полным. Признание того, что метод тестирования может быть ненадежен, позволяет снизить риск неэффективной стратегии тестирования, используя несколько стратегий тестирования. Компании, вовлеченные в разработку или приобретение программных продуктов, заинтересованы в разработке и использовании эффективных, действенных и повторимых процессов. Для осуществления этого компании разрабатывают полноценный набор процессов жизненного цикла программного обеспечения, используемых в проектах выполняемых ими разработок. Настоящий стандарт предназначен как для использования в организации в целом, так и для применения в отдельных проектах. Организация может принять настоящий стандарт и дополнить его по мере необходимости дополнительными процедурами, методами, инструментами и политиками. Конкретный проект разработки программного обеспечения или системы, выполняемый организацией, как правило, соответствует процессам организации, а не соответствует напрямую настоящему стандарту. В отдельных случаях проект может выполняться организацией, которая не располагает надлежащей совокупностью процессов организации. Такой проект может непосредственно применить положения настоящего стандарта. Для любой производящей программное обеспечение организации, будь ею многонациональная организация с тысячью тестеров или компания из одного человека, обязательства по тестированию программного обеспечения должен нести высший уровень организационного менеджмента, будь то генеральный директор, открытый руководящий комитет или начальник отдела. Желательно, чтобы эти обязательства были заложены в Организационную Политику Тестирования и в одну или более Организационные Стратегии Тестирования, служащие основой для всех выполняемых в организации видов тестирования программного обеспечения. Политики Тестирования и Организационные Стратегии Тестирования обычно присутствуют в наиболее развитых организациях. В организациях менее зрелых тестирование может выполняться и выполняется без формальных политик тестирования и организационных стратегий тестирования, но такая практика не обеспечивает обоснованности тестирования в организации и, как правило, показывает меньшую эффективность и результативность тестирования, выполняемого в проектах. Тестирование программного обеспечения выполняется как управляемый контекстом процесс. Это означает, что процесс нужно планировать, контролировать и им нужно управлять. Контекстом тестирования может быть как проект разработки в пределах от многочисленного, многолетнего формального проекта разработки до неофициальной разработки, требующей нескольких часов работы одного человека , так и текущее сопровождение функционирующей системы. Необходимо отметить некоторые положения контекста тестирования: Накопленный опыт отрасли показывает, что ни одна стратегия тестирования, ни один план, метод или процесс не будут работать во всех ситуациях. Следовательно, организации и проекты должны адаптироваться и совершенствоваться в деталях тестирования, опираясь на стандарты, такие как настоящий стандарт. Полный план проекта должен включать в себя анализ тестирующих действий, которые будут выполняться как часть проекта. В Плане Тестирования Проекта должны быть отражены как Организационная Политика Тестирования и Организационная Стратегия Тестирования, так и отклонения от этих организационных руководств. Кроме того, в плане должны быть учтены ограничения, заданные в полном плане проекта. План Тестирования Проекта включает в себя стратегию тестирования проекта и специфичные, используемые для выработки стратегии решения проекта включая предположения. Основной элемент планирования тестирования - это оценка различных нужд тестирования и балансировка ресурсов между различными тестированиями. План тестирования фиксирует результат этого анализа. В соответствии с настоящим стандартом в основу метода определения потребностей тестирования закладывается риск см. Для всего проекта тестирование осуществляется часто через некоторое множество подпроцессов тестирования, каждый из которых может иметь соответствующий План Тестирования План Подпроцесса Тестирования, например План Тестирования Системы или План Теста Производительности , включающий в себя как стратегию подпроцесса тестирования, согласованную со стратегией тестирования проекта, так и специфические детали подпроцесса тестирования. На рисунке 1 показано, как тестирование вписывается в иерархический контекст. Тестирование базируется на статусе регулирования, присущем организации если регулирование имеет место. Упомянутый контекст состоит из законов, инструкций и промышленных стандартов. В соответствии с нормативной ситуацией организация разрабатывает необходимые политики и процедуры, требуемые для успешной работы. Организационная Политика Тестирования работает на этом уровне. Каждый проект организации реализуется для соответствия некоторому требованию или возможности, которые идентифицированы организацией. Контекст проекта помогает определить, какую модель жизненного цикла выбрать. На этом уровне на основе контекста проекта и модели жизненного цикла определяется стратегия тестирования. План проекта и стратегия тестирования формируют базу для Плана Тестирования Проекта. План Тестирования Проекта описывает общую стратегию тестирования и процессы тестирования, которые будут использоваться. Он устанавливает контекст тестирования проекта, определяя цели, методы, ресурсы и расписание. Кроме того, он идентифицирует применимые подпроцессы тестирования например, тестирование системы, тестирование производительности. Идентифицированные подпроцессы далее расписываются в плане тестирования подпроцесса например, План Тестирования Системы, План Теста Производительности. План тестирования также определяет надлежащий метод проектирования тестирования статическое или динамическое , необходимый для выполнения подпроцесса тестирования, требуемого конкретным планом. Более подробно методы проектирования тестирования описаны в 5. Рисунок 1 - Иерархическая схема тестирования. Каждый план тестирования подпроцесса может относиться более чем к одному уровню тестирования например, план тестирования защищенности может относиться к нескольким уровням тестирования , а кроме того, может относиться к более чем одному типу тестирования например, План Тестирования Системы, который относится к тестированию функциональности и тестированию производительности на уровне тестирования системы. План тестирования подпроцесса также определяет стратегию выполнения теста например, по сценарию, без сценария или смесь того и другого. План тестирования включает в себя стратегию тестирования см. Стратегии тестирования настраиваются на конкретный контекст проекта тестирования. Каждый план тестирования и стратегия будет уникален, отличаясь от других: Планирование и выбор этих аспектов начинаются на ранней стадии проекта и будут продолжаться в течение жизненного цикла тестирования, влияя как фактор на изменение риска. Следует ожидать, что многие части плана и стратегии тестирования изменятся, хотя изменения будут, очевидно, в пределах ограничений проекта, организации или регулирующих норм. Рисунок показывает реализацию общих подпроцессов тестирования на определенных уровнях тестирования и в соответствии с типом тестирования. Общий подпроцесс тестирования может быть реализован: То есть каждый уровень тестирования представляет собой определенное приложение общего подпроцесса тестирования например, фаза покомпонентного тестирования, уровень приемочного испытания ;. Рисунок 2 - Взаимосвязи между общим подпроцессом тестирования, уровнями тестирования и типами тестирования. То есть каждый тип тестирования представляет собой определенное приложение общего подпроцесса тестирования например, тестирование производительности, тестирование удобства использования ; - подпроцесс тестирования, соответствующий уровню тестирования, может включать в себя больше одного подпроцесса разного типа тестирования например, функциональный и тестирование производительности являются частями тестирования системы ; - процесс тестирования проекта может состоять из последовательности подпроцессов тестирования например, тестирование компонента, интеграционное тестирование, тестирование системы и подпроцессы тестирования приемочных испытаний. Каждый тип тестирования ориентирован на один определенный показатель качества. Более подробно связи между типами тестирования и показателями качества рассматриваются в 5. Модель процесса начинается с организационного управления спецификациями тестирования высокого уровня организационными спецификациями , такими как Организационная Политика Тестирования и Организационная Стратегия Тестирования. Средний уровень показывает менеджмент тестирования менеджмент тестирования проекта, менеджмент фазы тестирования, менеджмент типа тестирования , в то время как нижний уровень определяет множество процессов тестирования, используемых в динамическом тестировании. Трехуровневая модель процесса показана на рисунке 3. Рисунок 3 - Многоуровневая связь процессов тестирования. Политика Тестирования выражает в бизнес-терминах ожидания менеджмента организации и подход к тестированию программного обеспечения. Она ориентирована на руководителей и старших менеджеров, хотя и может быть полезна для каждого, кто связан с тестированием. Политика Тестирования также руководит предпочтительным направлением и динамикой формирования и выполнения Организационной Стратегии Тестирования и процессов тестирования организации. Создание, реализация и поддержка Организационной Политики Тестирования определяется Организационным Процессом Тестирования. Организационная Стратегия Тестирования выражает требования и ограничения для процессов менеджмента тестирования и процессов динамического тестирования, которые должны удовлетворяться для всех выполненных в организации проектов, если они не слишком отличаются по характеру и когда может быть сформулировано несколько Организационных Стратегий Тестирования. Стратегия согласована с Организационной Политикой Тестирования и определяет, как должно быть выполнено тестирование. Создание, реализация и поддержка Организационной Стратегии Тестирования также определяется Организационным Процессом Тестирования. Менеджмент выполняемого тестирования определяется Процессами Менеджмента Тестирования. На основе анализа идентифицированных рисков и ограничений проекта и с учетом Организационной Стратегии Тестирования разрабатывается связанная с проектом стратегия тестирования. Эта стратегия разрабатывается с точки зрения определения необходимого статического и динамического тестирования, укомплектованности персоналом, баланса заданных ограничений ресурсы и время с предопределенными охватом и качеством результатов намеченного для выполнения тестирования. Все это записывается в План Тестирования Проекта. Для того чтобы обеспечивать запланированное продвижение тестирования и гарантию соответствующей обработки рисков во время выполнения тестирования, необходимо осуществлять мониторинг. Если в ходе тестирования потребуется внести какие-либо изменения в тестирующие действия, то соответствующему процессу или подпроцессу тестирования должны быть переданы управляющие директивы. Отчеты о Ходе Тестирования могут создаваться регулярно для информирования заинтересованных сторон о прогрессе тестирования в течение всего периода мониторинга и управления. Полный результат тестирования проекта оформляется в виде Отчета Завершения Тестирования Проекта. Процессы Менеджмента Тестирования показаны на рисунке 4. Рисунок 4 - Процессы Менеджмента Тестирования. Полное тестирование проекта обычно разбивается на меньшие подпроцессы тестирования например, тестирование компонентов, тестирование системы, тестирование удобства использования, тестирование производительности , и ими нужно управлять, их нужно выполнять и о них нужно информировать так же, как в случае тестирования полного проекта. Процессы Менеджмента Тестирования также применимы к подпроцессам тестирования. Примерами планов подпроцессов тестирования являются План Тестирования Системы, План Приемочного Испытания или План Теста Производительности. В подпроцессы тестирования может входить как статическое тестирование, так и динамическое тестирование. Процессы статического тестирования описаны в других опубликованных стандартах, например ИИЭР Рисунок 5 - Процессы динамического тестирования. Программное обеспечение имеет ожидаемый жизненный цикл от начальной его концепции до возможного прекращения его использования. Тестирование программного обеспечения имеет место в более широком контексте разработки и сопровождения программного обеспечения. Пример жизненного цикла системы показан на рисунке 6. Рисунок 6 - Пример жизненного цикла программного обеспечения. Жизненный цикл программного обеспечения обычно состоит из нескольких жизненных подциклов. На рисунке 6 показан жизненный цикл программного обеспечения, зачастую состоящий из одного или более жизненных циклов разработки и одного или более жизненных циклов эксплуатации. Период времени от концепции до первоначальной версии известен как жизненный цикл разработки, который является частью жизненного цикла программного обеспечения. Жизненный цикл разработки управляется и контролируется в проекте разработки. Полный текст документа будет доступен вам, как только оплата будет подтверждена. После подтверждения оплаты, страница будет автоматически обновлена , обычно это занимает не более нескольких минут. Приносим извинения за вынужденное неудобство. Если денежные средства были списаны, но текст оплаченного документа предоставлен не был, обратитесь к нам за помощью: В настоящее время мы ожидаем подтверждения оплаты от платежной системы. Обычно подтверждение платежа занимает не более нескольких минут. Попробуйте обновить страницу для повторной проверки. Если процедура оплаты на сайте платежной системы не была завершена, денежные средства с вашего счета списаны НЕ будут и подтверждения оплаты мы не получим. В этом случае вы можете повторить покупку документа с помощью кнопки справа. Платеж не был завершен из-за технической ошибки, денежные средства с вашего счета списаны не были. Попробуйте подождать несколько минут и повторить платеж еще раз. Если ошибка повторяется, напишите нам на spp cntd. Введение 1 Область применения 2 Соответствие 3 Нормативные ссылки 4 Термины и определения. Понятия и определения Название документа: Понятия и определения Номер документа: ГОСТ Р Принявший орган: Стандартинформ, год Дата принятия: Concepts and definitions ОКС Примечания 1 Организационная Стратегия Тестирования согласована с Организационной Политикой Тестирования. Примечания 1 Тестирование на основе структуры не ограничено использованием на уровне компонентов, а может использоваться на всех уровнях, например при покрытии пункта меню, как части тестирования системы. Примечания 1 Для подпроцесса тестирования, для которого он предназначен, контрольный пример - это самый низкий уровень входа тестирования то есть контрольные примеры не состоят из других контрольных примеров. Примечания 1 В проект может входить более одного плана тестирования, например может быть план тестирования проекта также именуемый основным планом тестирования , который охватывает все тестирующие действия для проекта, а более подробная информация об определенных действиях тестирования может быть определена в одном или более планах подпроцессов тестирования то есть план тестирования системы или план теста производительности. Примечания 1 Контрольные примеры в наборе тестов перечислены в порядке, требуемом в процедуре тестирования. Примечания 1 Стратегия тестирования - это производная от Организационной Стратегии Тестирования. Примечания 1 Также известна как матрица перекрестных ссылок верификации, матрица проверки требований, таблица верификации требований и др. Рисунок 1 - Иерархическая схема тестирования Рисунок 1 - Иерархическая схема тестирования Каждый план тестирования подпроцесса может относиться более чем к одному уровню тестирования например, план тестирования защищенности может относиться к нескольким уровням тестирования , а кроме того, может относиться к более чем одному типу тестирования например, План Тестирования Системы, который относится к тестированию функциональности и тестированию производительности на уровне тестирования системы. То есть каждый уровень тестирования представляет собой определенное приложение общего подпроцесса тестирования например, фаза покомпонентного тестирования, уровень приемочного испытания ; Рисунок 2 - Взаимосвязи между общим подпроцессом тестирования, уровнями тестирования и типами тестирования Рисунок 2 - Взаимосвязи между общим подпроцессом тестирования, уровнями тестирования и типами тестирования - как тестирование определенного типа. Рисунок 3 - Многоуровневая связь процессов тестирования Рисунок 3 - Многоуровневая связь процессов тестирования Политика Тестирования выражает в бизнес-терминах ожидания менеджмента организации и подход к тестированию программного обеспечения. Рисунок 4 - Процессы Менеджмента Тестирования Рисунок 4 - Процессы Менеджмента Тестирования Полное тестирование проекта обычно разбивается на меньшие подпроцессы тестирования например, тестирование компонентов, тестирование системы, тестирование удобства использования, тестирование производительности , и ими нужно управлять, их нужно выполнять и о них нужно информировать так же, как в случае тестирования полного проекта. Рисунок 6 - Пример жизненного цикла программного обеспечения Рисунок 6 - Пример жизненного цикла программного обеспечения Жизненный цикл программного обеспечения обычно состоит из нескольких жизненных подциклов. Идет завершение процесса оплаты. Произошла ошибка Платеж не был завершен из-за технической ошибки, денежные средства с вашего счета списаны не были. Электронным кошельком Через интернет-банк Банковской картой В терминале Сотовые операторы Другие способы E-mail: Важные документы ТТК, ППР, КТП Классификаторы Комментарии, статьи, консультации Картотека международных стандартов: Федеральное законодательство Региональное законодательство Образцы документов Все формы отчетности Законодательство в вопросах и ответах.
Любая программа может содержать в себе ошибки. Компилятор способен выявлять только синтаксические ошибки , но не способен отслеживать семантику. Большинство ошибок проявляется в ходе работы программы, при этом они могут возникать не всегда, а лишь при определенных условиях. Таким образом, успешная компиляция программы и выполнение этой программы в одних и тех же условиях не гарантируют отсутствие ошибок. Для выявления ошибок в программах ЖЦ разработки ПО предусматривает процесс тестирования, который является достаточно трудоемким и занимает больше времени, чем кодирование. Тестируемое ПО обычно называют SUT - Software Under Test. Цель тестирования - не убедиться в безошибочной работоспособности программы, а наоборот - найти ошибки. Поэтому в первую очередь возникает вопрос: Заметим, что к этому моменту программа уже представляет собой выполнимый процессором набор команд, то есть с точки зрения процессора она корректна. Даже если при каких-то условиях программа аварийно завершает свое выполнение или "портит" другие процессы, сразу нельзя сказать, что это ошибка в программе - возможно, так было задумано. Таким образом, ошибки необходимо рассматривать с точки зрения пользователя, основываясь на дополнительной информации, то есть неком описании того, что должна делать программа это же описание может включать в себя требование о том, чтобы программа никогда не завершалась аварийно и др. При рассмотрении вопросов анализа программного кода порой удобнее применять ранее рассмотренную в разделе 1 модель жизненного цикла. Ее часто называют V-образной из-за расположения блоков на рисунке рис. Нисходящая левая ветвь модели отражает поэтапную последовательность преобразования одних программных документов в другие: SYS - системных требований в SRD - требования к программному обеспечению, проектированию и формированию DDD - описания архитектуры системы и, наконец, разработке CODE - кода программ. Восходящая правая ветвь отражает процесс верификации разработанного программного обеспечения. На первом этапе путем тестирования производится модульная верификация MV , при которой поведение исполняемого программного кода проверяется на соответствие его DDD -описанию. Это наиболее трудоемкая и скрупулезная часть исследования. Она часто требует написания драйверов - моделей модулей, вызывающих процедуры тестируемого модуля, и заглушек - моделей процедур других модулей, вызываемых из тестируемого. Часто в MV отдельно выделяют процесс тестирования межмодульных связей, описанных в DDD. На втором этапе производится комплексная верификация CV реализованного программного обеспечения по отношению к требованиям. Наконец, производится комплексная интеграция CI и проверка всей системы: При грамотном процессе разработки уже на этапах нисходящей ветви для каждого требования определяется, на каком уровне верификации должна будет проводиться проверка его соблюдения. При этом следует исходить из предположения, что ошибки всегда есть. Тестирование можно считать успешным, если найдены ошибки, а не наоборот. В достаточно сложном ПО все ошибки могут не обнаруживаться даже после длительного тестирования, однако чем тщательнее ведется тестирование, тем меньше ошибок остается и тем менее вероятно возникновение невыявленных ошибок [ 6 ]. Тестирование обычно проводится снизу вверх, то есть сначала тести-руются отдельные функции, затем целые модули и далее проводится комплексное тестирование всей программы или комплекса программ. В каждом тестовом примере производится выполнение тестируемого программного элемента SUT при заданных Input - условиях и входных данных и проверяются все Output - выходные данные на соответствия заданным значениям. Тестовый пример набор должен включать в себя как минимум:. Кроме указанных данных удобно, если каждый тестовый пример имеет дополнительно:. Для проведения тестирования разрабатывается программа-драйвер тест , выполняющая все тестовые примеры и сравнивающая выходные значения с ожидаемыми. В результате выполнения теста получается не только общий результат - есть или нет ошибки, но еще и список пройденных и непройденных тестовых примеров, который помогает локализовать ошибки в SUT. Для упрощения локализации ошибок и последующей модификации тест-плана нужно, чтобы тестовые примеры были независимы друг от друга, то есть чтобы каждый последующий тестовый пример никак не использовал результаты работы предыдущего. Для этого необходимо провести установки всех начальных условий перед выполнением каждого тестового примера. Основная проблема тестирования ПО заключается в том, что проверить программу при всех возможных условиях функционирования в большинстве случаев невозможно. Это происходит либо в силу ограниченности ресурсов, либо в силу бесконечного количества возможных условий. Если же учесть, что машина оперирует невсеми этими числами, а различает только 10 знаков после запятой то есть множество чисел в интервале дискретно, минимальное отличие двух чисел 0, , то для проверки всех комбинаций из заданного диапазона понадобится степени тестовых примера, что является достаточно большим числом для такой простой функции. Если проверяются не все возможные комбинации входных условий, то тестирование является неполным. В основном для сложных программ тестирование является неполным, но даже неполное тестирование может выявить большинство ошибок, если выработать грамотную стратегию их поиска. Часто используют метод деления входных значений на области эквивалентности, так чтобы внутри каждой области для всех значений программа "вела себя" похоже. Тогда при написании тестовых примеров рассматриваются все значения на границах областей и по одному произвольному значению из каждой области области определяются для каждого входного параметра. Этот подход называют методом трех точек. Такие точки называют критическими точками, в них тестируемая функция может менять свое поведение или потенциально вести себя особо. Конечно, при таком подходе возможно, что какие-то ошибки останутся, но вероятность этого будет невелика и зависит от выбора критических точек. Функции, выполняющие различные сравнения, могут неверно их проводить, поэтому имеет смысл проверять их работу в непосредственной близости к критическим точкам. Для этого берутся значения, отстоящие от критических точек на величину дискретизации значений. Этот подход называют методом пяти точек. Иная сторона тестирования связана с типизацией переменных, при помощи которых задаются входные данные. Зачастую реакция функции на такое число не будет даже описана. Однако существуют приложения, чье поведение критично даже при передаче им входных значений, выходящих за пределы допустимых например, авиационные программы, программы управления ядерными реакторами. В этом случае подразумевается, что программа должна вести себя корректно, то есть не "зависнуть", не "повесить" систему, хотя выходное значение предсказать нельзя. Тестовые примеры, проверяющие поведение программы, в таких случаях, называются тестами на устойчивость robustness. Если при тестировании методом пяти точек проверять еще и значения, выходящие за пределы допустимых диапазонов, то такой метод будет называться методом семи точек. В примере функции умножения двух чисел кроме значений ; ; ,; -0,; 0,0; 0,; ,0; ,; для каждого входа следует взять, например, еще значения и , Как уже было сказано, для тестирования ПО необходимо обладать информацией о том, что оно должно делать. Это может быть либо подробное описание требования , либо просто сам код программы в этом случае подразумевается, что программа должна работать корректно, не "портить память", не завершаться аварийно, не мешать другим процессам. В зависимости от исходной информации о ПО различают два подхода к тестированию - тестирование по требованиям и тестирование по коду. Мы ищем курсы, покупаем и публикуем их для вас бесплатно. Учеба Академии Учителя Рейтинг Вопросы Магазин. Курсы Школа Высшее образование Мини-МБА Профессиональная переподготовка Повышение квалификации Сертификации. Информация Глоссарий Дипломы Вопросы и ответы Студенты Рейтинг выпускников Мнения Литература Учебные программы. Основы разработки программного обеспечения на примере языка С. Программист , Системный архитектор. Тестирование может показать лишь наличие ошибок, но не их отсутствие. Казахстан, Экибастуз, Экибастузский Инженерно-технический Институт, Пользовательское соглашение Политика конфиденциальности Реклама на сайте Напишите нам.
Увольнение с постоянного контракта в испании
Расписание молодежного чемпионата мира 2016
При какой температуре запекать соленое тесто
Георгиевская лента канзаши броши своими руками
Росбанк в хабаровске адреса