Версия 3 (от 9 июля 2014 года) Подготовлен Glossary Working Party
 Скачать 0.93 Mb.
|
|
автоматизация выполнения тестов (test execution automation): Использование программного обеспечения (например, средств захвата/воспроизведения) для контроля выполнения тестов, сравнения полученных результатов с эталонными, установки предусловий тестов и других функций контроля тестирования и организации отчетов. автоматизация тестирования (test automation): Использование программного обеспечения для осуществления или помощи в проведении определенных тестовых процессов, например, управление тестированием, проектирование тестов, выполнение тестов и проверка результатов. автоматизированное тестирование (scripted testing): Выполнение тестов, реализуемое при помощи заранее записанной последовательности тестов. автоматизированное тестовое обеспечение (automated testware): Тестовое обеспечение, используемое в автоматизированном тестировании, например, инструментальные сценарии. автоматизированный сценарий тестирования (test script): Обычно используется как синоним спецификации процедуры тестирования, как правило, автоматизированной. активация путей (path sensitizing): Составление набора входных значений для обеспечения выполнение определенного пути. актор (actor): Пользователь, или же любое другое действующее лицо или система, взаимодействующая определенным образом с тестируемой системой. альтернатива (decision): Точка программы, в которой управление имеет два или более альтернативных путей. Узел с двумя или более связями для разделения ветвей. F ATM ATM EITP ATM EITP F ATA F-AT F-AT 10 альфа-тестирование (alpha testing): Моделируемое или действительное эксплуатационное тестирование потенциальными пользователями/заказчиками или независимой командой тестирования на стороне разработчиков, но вне разрабатывающей организации. Альфа- тестирование часто применяется к коробочному программному обеспечению в качестве внутреннего приёмочного тестирования. анализ влияния (impact analysis): Оценка изменений в документации разработки и тестирования, а также компонентов с целью внесения данных изменений в определенные требования. анализ граничных значений (boundary value analysis): Разработка тестов методом черного ящика, при котором тестовые сценарии проектируются на основании граничных значений. См. также граничное значение. анализ дерева недочетов (FTA) (Fault Tree Analysis (FTA)): Метод, используемый для анализа причин недочетов (дефектов). Методика визуально моделирует для вскрытия специфических недочетов то, как логические связи между отказами, человеческими ошибками и внешними событиями могут сочетаться. анализ дерева недочетов программного обеспечения (Software Fault Tree Analysis (SFTA)): См. анализ дерева недочетов (FTA) анализ доменов (domain analysis): Методика разработки тестов, относящаяся к методу черного ящика, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно. Методика базируется и обобщает методы эквивалентного разбиения и анализа граничных значений. См. также анализ граничных значений, эквивалентное разбиение. анализ мутаций (mutation analysis): Метод определения законченности набора тестов путем измерения степени, с которой набор тестов может отличить программу от ее незначительных вариаций. анализ Парето (Pareto analysis): Статистическая техника предположений, используемая для выбора ограниченного числа факторов, оказывающих значительный итоговый эффект. С точки зрения качества, основное число проблем (80%) вызваны несколькими причинами (20%) анализ первопричины (root cause analysis): Анализ, направленный на идентификацию первопричин дефектов. При применении мер к устранению первопричины, можно надеяться на минимизацию частоты появления дефектов определенного типа. анализ покрытия (coverage analysis): Измерение достигнутого покрытия по отношению к заданному элементу покрытия во время выполнения теста в соответствии с предопределенными критериями. Позволяет определить, необходимо ли дополнительное тестирование, и если да, то какие тестовые сценарии нужны. анализ потока данных (data flow analysis): Вид статического анализа, основанный на определении и использовании переменных. анализ потока управления (control flow analysis): Вид статического анализа, основанный на представлении уникальных путей (последовательностей событий) в процессе выполнения компонента или системы. Анализ потока управления оценивает целостность структур потока F F ATA ATT ATT ATA EITP F EITP ATA 11 управления, выявляя возможные аномалии потока управления, такие как закрытые циклы или логически недостижимые шаги. анализ причинно-следственных связей (cause-effect analysis): См. отображение причинно- следственных связей. анализ рисков (risk analysis): Процесс оценки идентифицированных рисков проекта или продукта для вычисления их уровня, обычно через оценку вероятности и влияния анализ тестирования (test analysis): Процесс анализа базиса тестирования и определения целей тестирования. анализ тестируемости (testability review): Детальная проверка базиса тестирования с целью определения, является ли он достаточно качественным, чтобы выступать в роли первоисточника для процесса тестирования. [TMap] анализ тестовых точек (TPA) (Test Point Analysis (TPA)): Метод оценки затрат на тестирование на основе формулы, основанный на анализе функциональных точек. [TMap] анализ типов отказов и эффекта (FMEA) (Failure Mode and Effect Analysis (FMEA)): Систематический подход для определения и анализа рисков идентификации возможных типов отказов и попытка их предотвращения. См. также анализ типов отказов, эффекта и критичности (FMECA) анализ типов отказов, эффекта и критичности (FMECA) (Failure Mode, Effect and Criticality Analysis (FMECA)): Расширение FMEA; в дополнение к основному FMEA, включает анализ критичности, используемый для отображения вероятности типов отказов по отношению к критичности их последствий. Результат отражает тип отказа с относительно высокой вероятностью и критичностью последствий, позволяя предпринять корректирующие действия там, где они будут иметь наибольшую ценность. См. также анализ типов отказов и эффекта. анализ типов отказов, эффекта и критичности программного обеспечения (Software Failure Mode Effect, and Criticality Analysis (SFMECA)): См. анализ типов отказов, эффекта и критичности (FMECA). анализ функциональных точек (FРA) (Function Point Analysis (FPA)): Метод, помогающий при оценке размера функциональности информационной системы. Оценка не зависит от технологии. Оценка может быть использована как основа оценки производительности, расчета необходимых ресурсов и контроля проекта. анализ типов отказов и эффектов программного обеспечения (Software Failure Mode and Effect Analysis (SFMEA)): См. анализ типов отказов и эффектов (FMEA) анализ факторов опасности (hazard analysis): Метод, используемый для характеристики элементов риска. Результат анализа случайности определяют методы, используемые в разработке и тестировании системы. См. также анализ рисков. анализатор (analyzer): См. статический анализатор. анализатор кода (code analyzer): См. статический анализатор кода. EITP ATM ATA ATT 12 анализируемость (analyzability): Способность программного продукта быть проверенным на отсутствие отказов или их причин, а также определение частей ПО, которые нужно проверить вследствии изменений. [ISO 9126] См. также сопровождаемость. аналитический отчет о тестировании (test evaluation report): Документ, создаваемый в конце процесса тестирования и подводящий итог тестовым активностям и результатам. Также в нем содержится оценка процесса тестирования и полученный опыт. аналитическое тестирование (analytical testing): Тестирование, основанное на системном анализе продуктовых рисков, требований и т.д. аномалия (anomaly): Любое состояние, которое не соответствует ожиданиям, основанным на чьем- либо восприятии или опыте, или же спецификации требований, проектной документации, пользовательской документации, стандартах и т.п. Аномалии могут быть найдены во время (но не только) рецензирования, тестирования, анализа, сборки или использования программных продуктов или соответствующей документации [IEEE1044] См. также помеха, дефект, отклонение, ошибка, недочет, отказ, инцидент, проблема. анти-паттерн (anti-pattern): Повторяемое действие, процесс, структура или повторно используемое решение, изначально кажущееся полезным и часто используемое, однако оказывающееся на практике неэффективным и(или) контрпродуктивным. анти-регрессионное тестирование (regression-averse testing): Тестирование, использующее различные методологии с целью контролировать риск регрессии, например, с помощью разработки повторно используемого тестового обеспечения и активной автоматизации тестов на одном или нескольких уровнях тестирования. архитектор тестов (test architect): 1. Человек, предоставляющий рекомендации и стратегические направления для организации тестирования и его связи с остальными областями. 2. Человек, определяющий метод структурирования тестирования данной системы, включая такие аспекты как инструменты тестирования и управление тестовыми данными. ассоциативная карта (mind-map): Схема, использующаяся для представления слов, идей, задач или других предметов, связанных и расположенных вокруг центрального ключевого слова или идеи. Ассоциативные карты используются для создания, визуализации, структурирования и классификации идей, как помощь в учебе, для организации и решения проблем, как помощь в принятии решений, и записи. атака (attack): Направленная и нацеленная попытка оценить качество, главным образом надежность, объекта тестирования за счет попыток вызвать определенные отказы. См. также негативное тестирование. атака на недочеты (fault attack): См. атака. атака через посредника (man in the middle attack): Перехват, эмуляция и/или изменение и последующее перенаправление коммуникаций (например, транзакций по кредитной карте) третьей стороной таким образом, что пользователь остается в неведении относительно присутствия данной третьей стороны. ETM ATT ETM ATT F F EITP ETM ETM 13 атомарное условие (atomic condition): Условие, над которым невозможно провести дальнейшую декомпозицию, т.е. условие, не содержащее два или более одинарных условий, объединенных логическими оператороми (И, ИЛИ, Исключающее ИЛИ). АТТ (TPA): См. анализ тестовых точек. аттрибут качества: свойство или характеристика, влияющая на качество объекта. [IEEE 610] аудит (audit): Независимая оценка программных продуктов или процессов с целью установления соответствия стандартам, рекомендациям, спецификациям и/или процедурам, основанным на объективных критериях, включающих документы, которые определяют: 1. форму или содержание продуктов для производства; 2. процесс, согласно которому продукты будут произведены; 3. как будет измеряться соответствие стандартам или рекомендациям. [IEEE 1028] аудит конфигурации (configuration auditing): Функция проверки состава библиотек элементов конфигурации, например на соответствие стандартам. [IEEE 610] Б базис тестирования (test basis): Документ, на основании которого определяются требования к компоненту или системе. Документация, на которой базируются тестовые сценарии. Если правка данного документа может быть осуществлена только в процессе формальной процедуры внесения изменения, то такой базис тестирования называется замороженным базисом тестирования. [TMap] базовая версия (baseline): Спецификация или программный продукт, который был формально отрецензирован или согласован, впоследствии используется как базовая версия для дальнейшей разработки, и который может быть изменен только в процессе формального контроля процесса измененй. [согласно IEEE 610] базовый блок (basic block): Последовательность одной или более упорядоченных выполняемых операторов, которые не содержат ветвей. Примечание: узел на графе потока управления представляет собой базовый блок. базовый набор тестов (basis test set): Набор тестовых сценариев полученных на основании внутренней структуры компонента или спецификации, предназначенный для убеждения в 100% достижении заданных критериев покрытия. безопасность (safety): Способность программного продукта при использовании оговоренным образом оставаться в рамках приемлемого риска причинения вреда здоровью, бизнесу, программам, собственности или окружающей среде. [ISO 9126] бета-тестирование (beta testing): Эксплутационное тестирование потенциальными и/или существующими клиентами/заказчиками на внешней стороне никак не связанными с разработчиками, с целью определения действительно ли компонент или система удовлетворяет требованиям клиента/заказчика и вписывается в бизнес-процессы. Бета-тестирование часто проводится как форма внешнего приёмочного тестирования готового программного обеспечения для того чтобы получить отзывы рынка. ATT ATM F F F-AT 14 буфер (buffer): Устройство или область памяти, используемые для временного хранения данных с целью компенсации разницы в скорости потока данных, времени или частоты событий, или объемов данных, которые могут быть обработаны устройствами или процессами, участвующими в передаче или использовании данных. [Согласно IEEE 610] В валидация (validation): Доказанное объективными результатами исследования подтверждение того, что требования для ожидаемого конкретного использования приложения были выполнены. [ISO 9000] ведущий аудитор (lead assessor): Человек, возглавляющий аудит. В некоторых случаях, например CMMi и TMMi, для проведения формальных оцениваний ведущий аудитор должен быть аккредитован и формально обучен. ведущий специалист по тестированию (test leader): См. руководитель тестирования верификация (verification): Доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены. [ISO 9000] вероятность риска (risk likelihood): Оценочная вероятность реализации риска. вертикальная трассируемость (vertical traceability): Отслеживание требований через уровни разработки к компонентам. ветвь (branch): Базовый блок, который может быть выбран для выполнения, основываясь на логической структуре программы, в которой доступен один из двух или более альтернативных путей, например, case, jump, go to, if then-else. веха (milestone): Точка в течение времени проекта, к которой заранее определенные (промежуточные) поставки и результаты должны быть готовы. влияние риска (risk impact): Последствия, которые проявятся в случае реализации риска. внесение недочетов (fault injection): Процесс сознательного внесения дефектов в систему с целью определить, может ли система определить дефект и, возможно, восстановиться после его обнаружения. Внесение недочетов призвано эмулировать отказы, которые могут произойти во время эксплуатации. См. также устойчивость к недочетам. внешнее стороннее тестирование (outsourced testing): Тестирование, производимое людьми, не находящимися в одном месте с командой разработки и не являющимися сотрудниками одной компании. возможность взаимодействия (interoperability): Способность программного продукта взаимодействовать с одним или более заданными компонентами или системами [ISO 9126] См. также функциональность. EITP F F 15 воспроизводимость теста (test reproduceability): Атрибут теста, показывающий, что результаты теста одинаковы при каждом выполнении этого теста. восстанавливаемость (recoverability): Способность программного продукта восстанавливать требуемый уровень работоспособности и рабочие данные, пострадавшие в результате ошибки. [ISO 9126] Также см. надежность. восходящее тестирование (bottom-up testing): Последовательный подход к интеграционному тестированию, при котором компоненты нижнего уровня тестируются первыми и потом используются для облегчения тестирования компонентов более высокого уровня. Этот процесс повторяется до тех пор, пока компонент на самом верху иерархии не будет протестирован. См. также интеграционное тестирование. встроенная итеративная модель разработки (embedded iterative development model): Подмодель жизненного цикла разработки, применяющая итеративный подход к детализированному дизайну, программированию и тестированию внутри глобальной последовательной модели. В данном случае высокоуровневые спецификации дизайна подготавливаются и утверждаются для проекта в целом, однако конкретная детализация дизайна, разработки программного кода и тестирования осуществляется внутри циклов. вход (input): Переменная (хранимая внутри или вне компонента), считываемая компонентом. входное значение (input value): Экземпляр входа. См. также вход. входной тест (intake test): Специальный тип теста "на дым" для принятия решения, готов ли компонент или система готова для дальнейшего детального тестирования. Обычно начинается в начале фазы тестирования. См. также тест "на дым". входные данные теста (test input): Данные, получаемые объектом тестирования из внешнего источника во время проведения тестирования. В роли внешнего источника может выступать оборудование, программное обеспечение или человек. выборочное тестирование (random testing): Разработка тестов методом черного ящика, при котором тестовые сценарии выбираются для соответствия функциональному разрезу, обычно с помощью алгоритма псевдослучайного выбора. Этот метод может использоваться для тестирования таких нефункциональных атрибутов, как надежность и производительность. |