Версия 3 (от 9 июля 2014 года) Подготовлен Glossary Working Party
 Скачать 0.93 Mb.
|
|
недостижимый путь (infeasible path): Путь, который не может быть проверен любым набором возможных входных значений. недочет (fault): См. дефект. F F F ATM ATA F 35 независимость тестирования (independence of testing): Разделение ответственностей, которое позволяет выполнять объективное тестирование. [DO-178b] непрерывное представление (continuous representation): Структурамодели зрелости процессов программного обеспечения, в которой уровни зрелости предусматривают рекомендуемый порядок применения подходов к совершенствованию процессов в заданных областях процессов. [CMMI] непрохождение теста (test fail): См. не пройденный. несоответствие (non-conformity): Невыполнение определенного требования. [ISO 9000] неформальное рецензирование (informal review): Рецензирование, которое не основано на формальной (документированной) процедуре. нефункциональное тестирование (non-functional testing): Тестирование атрибутов компонента или системы, не относящихся к функциональности, то есть надежность, эффективность, практичность, сопровождаемость и переносимость. нефункциональные требования (non-functional requirement): Требования, относящиеся не к функциональности, а к таким аттрибутам как надежность, эффективность, практичность, сопровождаемость и переносимость. нефункциональный метод разработки тестов (non-functional test design techniques): Процедура разработки или выбора тестовых сценариев для нефункционального тестирования, основанная на анализе спецификации компонента или системы в отрыве от его внутренней структуры. См. разработка тестов методом черного ящика. нормативное тестирование (regulation testing): См. тестирование соответствия. О область входных значений (input domain): Набор, из которого могут быть выбраны верные значения. См. также домен. область выходных данных (output domain): Множество, из которого могут быть выбраны допустимые выходные значения. См. также домен. обработка исключений (exception handling): Поведение компонента или системы в случае неправильных входных данных, введенных человеком или от другого компонента или системы, либо из-за внутреннего отказа. общее управление качеством (Total Quality Management): Общеорганизационный подход к управлению, сосредоточенный на качестве, основанный на вовлечении всех сотрудников организации и направленный на долгосрочный успех посредством удовлетворенности клиентов, и выгоды для всех членов организации и общества. Общее управление качеством включает планирование, организацию, руководство, контроль и проверку удовлетворенности. [ISO 8402] EITP F ATM F ATM F EITP 36 объект тестирования (test object): Компонент или система, которые должны быть протестированы. См. элемент тестирования. объемное тестирование (volume testing): Тестирование, при котором система испытывается на больших объемах данных. См. тестирование использования ресурсов. ожидаемый исход (expected outcome): См. ожидаемый результат. ожидаемый результат (expected result): Поведение компонента или системы при установленных условиях, которое определенно спецификацией или другими источниками. оператор (statement): Сущность языка программирования, обычно являющаяся минимальным неделимым исполняемым блоком. оператор исходного кода (source statement): См. оператор. определение данных (data definition): Выполняемый оператор, где переменной присваивается значение. определение рисков (risk identification): Процесс идентификации рисков с использованием таких методик как мозговорй штурм, контрольные списки и история отказов. оракул (oracle): См. тестовый предсказатель. ортогональный массив (orthogonal array): Двумерный массив, построенный со специальными математическими свойствами такими, что при выборе двух любых столбцов массива, каждому члену массива соответствует пара комбинаций. оснащение средствами контроля (instrumentation): Вставка дополнительного кода в программу для сбораинформации о поведении программы во время выполнения. Например, для измерения покрытия кода. отказ (failure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата. [Fenton] отклонение (deviation): Cм. инцидент. отладка (debugging): Процесс поиска, анализа, и устранения причин отказов в программном обеспечении. отладчик (debugger): См. инструмент отладки. отображение причинно-следственных связей (cause-effect graphing): Разработка тестов методом черного ящика, при котором тестовые сценарии разрабатываются на основе диаграмм причинно-следственных связей. [BS 7925/2] отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829] ATA F F ATM ATA ATM ATA 37 отчет о передаче элемента тестирования (test item transmittal report): См. сопроводительная записка. отчет о помехе (bug report): См. отчет о дефекте. отчет о проблеме (problem report): См. отчет о дефекте. отчет о тестировании (test report): См. итоговый отчет о тестировании. отчет о ходе тестирования (test progress report): Документ, подводящий итог задачам и результатам, составляемый с определенной периодичностью с целью сравнения прогресса тестирования с базовой версией (например, с исходным планом тестирования) и извещения о рисках и альтернативах, требующих решения руководства. отчет об отклонении (deviation report): Cм. отчет по инциденту. отчет об оценке (assessment report): Документ, суммирующий результаты оценки, например, заключения, рекомендации и полученные данные. См. также оценка процесса. отчет по инциденту (incident report): Документ, описывающий событие, которое произошло, например, во время тестирования, и которое необходимо исследовать. [ IEEE 829] отчет по инциденту программного обеспечения (software test incident report): См. отчет по инциденту. отчетность тестирования (test reporting): Сбор и анализ данных, предоставляемых тестовыми активностями, с последующим объединением данных в отчет с целью информирования заинтересованных лиц. См. также процесс тестирования. ОУК (TQM): См. общее управление качеством. оценка (evaluation): См. тестирование. оценка затрат на тестирование (test estimation): Рассчитанная аппроксимация результатов, связанных с различными аспектами тестирования (например, затраченные усилия, дата завершения, связанные затраты, число тестовых сценариев, и т.д.), результаты которой могут использоваться даже когда входные данные неполные, неопределенные или неточные. оценка по трем точкам (three point estimation): Метод оценки затрат на тестирование с использованием трех значений для "лучшего случая", "худшего случая", "наиболее вероятного случая" при работе с оцениваемой сущностью с целью вывести уровень определенности, связанный с результирующей оценкой. оценка процесса (process assessment): Упорядоченная оценка организации процесса разработки ПО на основе к эталонной модели. [ISO 15504] оценка риска (risk assessment): Процесс идентификации и последующего анализа определенного риска проекта или продукта с целью определить его уровнь. Обычно состоит из назначения рейтинга вероятности и влияния. См. также риск проекта, риск продукта, риск, влияние риска, уровень риска, вероятность риска. EITP F EITP ATT ATM F-AT ATM EITP 38 оценка функциональности (functionality testing): Процесс тестирования для определения функциональных возможностей программного продукта. оценочная ведомость (scorecard): Представление прогресса суммарных измерений производительности по отношению к реализации долгосрочных целей. Оценочная ведомость содержит измерения производительности за время или на конец определенного интервала. См. также карта сбалансированных показателей, сводная таблица. оценочная таблица (scorecard): См. оценочная ведомость. ошибка (error): Действие человека, которое приводит к неправильному результату. [IEEE 610] П память (storage): См. использование ресурсов. пара "определение-использование" (definition-use pair): Ассоциация определений переменных и их последующего использования. Переменные используются, например, для вычислений (например, умножение) или указания пути выполнения (в качестве предиката). парное программирование (pair programming): Подход к разработке программного обеспечения, при котором код (при разработке или тестировании) пишется двумя программистами за одним компьютером. По сути это подразумевает непрекращающиеся рецензии кода. парное тестирование (pair testing): Два человека (двое тестировщиков, разработчик и тестировщик, или конечный пользователь и тестировщик), работающих вместе над поиском дефектов. Обычно они работают за одним компьютером, в течение работы, передавая управление друг другу. первопричина (root cause): Источник дефекта, при удалении которого частота подобных дефектов сокращается, или же подобные дефекты исчезают полностью. [CMMI] передовой опыт (best practice): Лучший или инновационный метод, который может улучшить производительность организации в заданных условиях, обычно признается как "лучший" другими подобными организациями. переменная (variable): Элемент памяти, доступный для программного продукта через его имя. переносимость (portability): Легкость, с которой программный продукт может быть перенесен из одной аппаратного или программного окружения в другое. [ISO 9126] переполнение буфера (buffer overflow): Отказ доступа к памяти вследствие попытки процесса сохранить данные, превосходящие ограничения фиксированной длины буфера, приводящий к перезаписыванию соседних областей памяти или вызыванию исключения переполнения. См. также буфер. переход состояний (state transition): Переход между двумя состояниями компонентам или системы. ATT F ATM 39 план рецензирования (review plan): Документ, описывающий подход, требуемые ресурсы и график проведения запланированного рецензирования. Среди прочего он определяет: документы и код, подлежащий рецензированию; предполагаемые типы рецензирования; участники и критерии входа и выхода, применимые к формальным видам рецензирования и обоснование их выбора. Является документированным процессом плана рецензирования. план совершенствования процесса тестирования (test improvement plan): План достижения организационного совершенствования процесса испытаний, основанный на глубоком понимании сильных и слабых сторон корпоративных процессов и активов тестирования. [Согласно CMMI] план тестирования (test plan): Документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств. [IEEE 829] план тестирования проекта (project test plan): См. главный план тестирования. план фазы тестирования (phase test plan): План тестирования, обычно описывающий одну фазу тестирования. См. план тестирования. планирование тестирования (test planning): Работа по составлению и поддержанию актуальности плана тестирования. плотность дефектов (defect density): Количество дефектов, обнаруженных в компоненте или системе, поделенное на размер компонента или системы (выраженный в стандартных единицах измерения, например строках кода, числе классов или функций). плотность недочетов (fault density): См. плотность дефектов. поведение (behavior): Отклик компонента или системы на набор входных значений и предусловий. поведение во времени (time behavior): См. производительность. повторное тестирование (re-testing): См. повторное тестирование подветвь (subpath): Последовательность исполняемых операторов в коде компонента. подсев недочетов (fault seeding): Процесс намеренного внесения дефектов в дополнение к тем, что уже существуют в компоненте или в системе, для целей отслеживания уровня обнаружения и устранения, а также оценивания количества оставшихся в системе дефектов. Подсев недочетов обычно является частью процесса тестирования разработки и может применяться на любом уровне тестирования (компонентном, интеграционном или системном). [IEEE 610] подсев ошибок (error seeding): См. подсев недочетов. F F ATM EITP F ATM ATM ATA 40 подтверждающее тестирование (confirmation testing): Тестирование, при котором выполняются тестовые сценарии, которые были не пройдены при последнем запуске, с целью подтвердить успешность исправлений. подход к тестированию (test approach): Реализация стратегии тестирования для определенного проекта. Обычно включает в себя заключения, сделанные на основе цели (тестирования) проекта и анализе рисков, стартовые точки процесса тестирования, применяемые методики разработки тестов, критерии выхода, типы тестирования, которые должны быть произведены. покер планирования (planning poker): Метод оценки трудозатрат, основанный на всеобщем одобрении. Обычно используется для оценки затрат или относительного объема пользовательских историй в гибких методологиях разработки программного обеспечения. Является вариантом "широкополосного предсказателя" с использованием колоды карт со значениями, представляющими число квантов, которыми оценивается работа. См. также гибкие методики разработки, широкополосный предсказатель. покрытие (coverage): Уровень, выражаемый в процентах, на который определенный элемент покрытия был проверен набором тестов. покрытие LCSAJ (LCSAJ coverage): Процент [LCSAJs] компонента, которые были проверены набором тестов. 100% покрытие [LCSAJ] предполагает 100% покрытие альтернатив. покрытие N переходов (N-switch coverage): Процент последовательностей N+1 переходов, выполненных набором тестов. [Chow] покрытие альтернатив (decision coverage): Процент результатов альтернативы, который был проверен набором тестов. Стопроцентное покрытие решений подразумевает стопроцентное покрытие ветвей и стопроцентное покрытие операторов. покрытие ветвей (branch coverage): Процент ветвей, которые были выполнены набором тестов. 100% покрытие ветвей подразумевает 100% покрытие альтернатив и 100% покрытие операторов. покрытие граничных значений (boundary value coverage): Процент граничных значений, который был проверен набором тестов. покрытие кода (code coverage): Метод анализа, определяющий, какие части программного обеспечения были проверены (покрыты) набором тестов, а какие нет, например, покрытие операторов, покрытие альтернатив или покрытие условий. покрытие комбинаций условий (condition combination coverage): См. покрытие множественных условий. покрытие комбинаций условий ветвей (branch condition combination coverage): См. покрытие множественных условий. покрытие множественных условий (multiple condition coverage): Процент комбинаций всех исходов одиночных условий в рамках одного оператора, который был проверен набором тестов. Стопроцентное покрытие множественных условий означает стопроцентное модифицированное покрытие условий альтернатив. F F F ETM F F-AT ATM 41 покрытие операторов (statement coverage): Процентное отношение операторов, исполненяемых набором тестов, к их общему количеству. покрытие определений условий (condition determination coverage): См. модифицированное покрытие условия альтернативы. покрытие потока данных (data flow coverage): Процент пар "определение-использование", который был проверен набором тестов. покрытие путей (path coverage): Процент путей, которые были пройдены в процессе выполнения набора тестов. 100% покрытие путей обеспечивает 100% покрытие LCSAJ. покрытие условий (condition coverage): Процент исходов условий, которые были проверены набором тестов. 100% покрытие условий требует, чтобы каждое отдельное условие в каждом выражении решения было проверено как “Истина” и “Ложь”. покрытие условий альтернатив (decision condition coverage): Процент всех исходов условий и покрытий альтернатив, который был проверен набором тестов. Стопроцентное покрытие условий решения подразумевает стопроцентное покрытие условий и стопроцентное покрытие альтернатив. покрытие условий ветвей (branch condition coverage): См. покрытие условий. покрытие эквивалентного разбиения (equivalence partition coverage): Процент эквивалентных областей, который был проверен набором тестов. политика тестирования (test policy): Документ высокого уровня, описывающий принципы, подход и основные цели организации в отношении тестирования. полное тестирование (complete testing): См. исчерпывающее тестирование. пользовательская история (user story): Высокоуровневое пользовательское или бизнес-требование, обычно использующееся в гибких методологиях разработки программного обеспечения. Обычно состоит из одного или нескольких предложений на разговорном или формальном языке, описывающих функциональность, необходимую пользователю, любые нефункциональные требования и включающих в себя критерии приемки. См. также гибкая методология разработки программного обеспечения, требование. |