(Total Quality Management):
Общеорганизационный подход к управлению, сосредоточенный на качестве, основанный на вовлечении всех сотрудников организации и направленный на долгосрочный успех посредством удовлетворенности клиентов, и выгоды для всех членов организации и общества. Общее управление качеством включает планирование, организацию, руководство, контроль и проверку удовлетворенности. [ISO 8402]
объект тестирования (test object): Компонент или система, которые должны быть протестированы. См. элемент тестирования.
объемное тестирование (volume testing): Тестирование, при котором система испытывается на больших объемах данных. См. тестирование использования ресурсов.
ожидаемый исход (expected outcome):
См. ожидаемый результат.
ожидаемый результат (expected result):
Поведение компонента или системы при установленных условиях, которое определенно спецификацией или другими источниками.
оператор (statement): Сущность языка программирования, обычно являющаяся минимальным неделимым исполняемым блоком.
оператор исходного кода (source statement):
См. оператор.
определение данных (d deinition): Выполняемый оператор, где переменной присваивается значение.
определение рисков (risk identiication): Процесс идентификации рисков с использованием таких методик как мозговой штурм, контрольные списки и история отказов.
оракул (oracle): См. тестовый предсказатель.
ортогональный массив (orthogonal array): Двумерный массив, построенный со специальными математическими свойствами такими, что при выборе двух любых столбцов массива, каждому члену массива соответствует пара комбинаций.
оснащение средствами контроля (instrumentation): Вставка дополнительного кода в программу для сбора информации о поведении программы во время выполнения. Например, для измерения покрытия кода.
отказ (ailure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата.
отклонение (deviation): Cм. инцидент.
отладка (debugging): Процесс поиска, анализа, и устранения причин отказов в программном обеспечении.
отладчик (debugger): См. инструмент отладки.
отображение причинно-следственных связей (cause-eect graphing): Разработка тестов методом черного ящика, при котором тестовые сценарии разрабатываются на основе диаграмм причинно-следственных связей.
отчет о дефекте (deect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]
отчет о передаче элемента тестирования (test item transmittal report): См. сопроводительная записка.
отчет о помехе (bug report): См. отчет о дефекте.
отчет о проблеме (problem report): См. отчет о дефекте.
отчет о тестировании (test report):
См. итоговый отчет о тестировании.
отчет о ходе тестирования (test progress report): Документ, подводящий итог задачам и результатам, составляемый с определенной периодичностью с целью сравнения прогресса тестирования с базовой версией (например, с исходным планом тестирования) и извещения о рисках и альтернативах, требующих решения руководства.
отчет об отклонении (deviation report):
Cм. отчет по инциденту.
отчет об оценке (assessment report): Документ, суммирующий результаты оценки, например, заключения, рекомендации и полученные данные.
См. также оценка процесса.
отчет по инциденту (incident report):
Документ, описывающий событие, которое произошло,
например, во время тестирования, и которое необходимо исследовать. [ IEEE 829]
отчет по инциденту программного обеспечения (sotware test incident report): См. отчет по инциденту.
ОУК (TQM): См. общее управление качеством.
оценка (evaluation): См. тестирование.
оценка затрат на тестирование (test estimation): Рассчитанная аппроксимация результатов, связанных с различными аспектами тестирования (например, затраченные усилия, дата завершения, связанные затраты, число тестовых сценариев, и т.д.), результаты которой могут использоваться даже когда входные данные неполные, неопределенные или неточные.
оценка по трем точкам (three point estimation): Метод оценки затрат на тестирование с использованием трех значений для «лучшего случая», «худшего случая», «наиболее вероятного случая» при работе с оцениваемой сущностью с целью вывести уровень определенности, связанный с результирующей оценкой.
оценка процесса (process assessment): Упорядоченная оценка организации процесса разработки ПО на основе к эталонной модели. [ISO 15504]
оценка риска (risk assessment): Процесс оценки определенного риска проекта или продукта с целью определить его уровень. Обычно состоит из назначения рейтинга вероятности и влияния с последующим сбором этих рейтингов в единый рейтинг приоритетов. См. также риск проекта, риск продукта, риск, влияние риска, уровень риска, вероятность риска.
оценка функциональности (unctionality testing):
Процесс тестирования для определения функциональных возможностей программного продукта.
оценочная ведомость (scorecard): Представление прогресса суммарных измерений производительности по отношению к реализации долгосрочных целей. Оценочная ведомость содержит измерения производительности за время или на конец определенного интервала. См. также карта сбалансированных показателей, сводная таблица.
оценочная таблица (scorecard): См. оценочная ведомость.
ошибка (error): Действие человека, которое приводит к неправильному результату. [IEEE 610]
П
память (storage): См. использование ресурсов.
пара «определение-использование» (deinition-use pair): Ассоциация определений переменных и их последующего использования. Переменные используются, например, для вычислений (например, умножение) или указания пути выполнения (в качестве предиката).
парное программирование (pair programming): Подход к разработке программного обеспечения, при котором код (при разработке или тестировании) пишется двумя программистами за одним компьютером. По сути это подразумевает непрекращающиеся рецензии кода.
парное тестирование (pair testing): Два человека (двое тестировщиков, разработчик и тестировщик, или конечный пользователь и тестировщик), работающих вместе над поиском дефектов. Обычно они работают за одним компьютером, в течение работы, передавая управление друг другу.
первопричина (root cause): Источник дефекта, при удалении которого частота подобных дефектов сокращается, или же подобные дефекты исчезают полностью.
передовой опыт (best practice):
Лучший или инновационный метод, который может улучшить производительность организации в заданных условиях, обычно признается как «лучший» другими подобными организациями.
переменная (variable): Элемент памяти, доступный для программного продукта через его имя.
переносимость (portability): Легкость, с которой программный продукт может быть перенесен из одной аппаратного или программного окружения в другое.
[ISO 9126]
переполнение буфера (buer overlow): Отказ доступа к памяти вследствие попытки процесса сохранить данные, превосходящие ограничения фиксированной длины буфера, приводящий к перезаписыванию соседних областей памяти или вызыванию исключения переполнения. См. также буфер.
переход состояний (state transition): Переход между двумя состояниями компонентам или системы.
план рецензирования (review plan): Документ, описывающий подход, требуемые ресурсы и график проведения запланированного рецензирования. Среди прочего он определяет: документы и код, подлежащий рецензированию; предполагаемые типы рецензирования; участники и критерии входа и выхода, применимые к формальным видам рецензирования и обоснование их выбора. Является документированным процессом плана рецензии.
план совершенствования процесса тестирования (test improvement plan): План достижения организационного совершенствования процесса испытаний, основанный на глубоком понимании сильных и слабых сторон корпоративных процессов и активов тестирования. [Согласно CMMI]
план тестирования (test plan): Документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств. [IEEE 829]
план тестирования проекта (project test plan):
См. главный план тестирования.
план фазы тестирования (phase test plan): План тестирования, обычно описывающий одну фазу тестирования. См. план тестирования.
планирование тестирования (test planning): Работа по составлению и поддержанию актуальности плана тестирования.
плотность дефектов (deect density): Количество дефектов, обнаруженных в компоненте или системе, поделенное на размер компонента или системы (выраженный в стандартных единицах измерения, например строках кода, числе классов или функций).
плотность недочетов (ault density):
См. плотность дефектов.
поведение (behavior): Отклик компонента или системы на набор входных значений и предусловий.
поведение во времени (time behavior):
См. производительность.
повторное тестирование (re-testing): Тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
подветвь (subpath): Последовательность исполняемых операторов в коде компонента.
подсев недочетов (ault seeding): Процесс намеренного внесения дефектов в дополнение к тем, что уже существуют в компоненте или в системе, для целей отслеживания уровня обнаружения и устранения, а также оценивания количества оставшихся в системе дефектов. Подсев недочетов обычно является частью процесса тестирования разработки и может применяться на любом уровне тестирования (компонентном, интеграционном или системном). [IEEE 610]
подсев ошибок (error seeding): См. подсев недочетов.
подтверждающее тестирование (conirmation testing): См. повторное тестирование.
подход к тестированию (test approach): Реализация стратегии тестирования для определенного проекта. Обычно включает в себя заключения, сделанные на основе цели (тестирования) проекта и анализе рисков, стартовые точки процесса тестирования, применяемые методики разработки тестов, критерии выхода, типы тестирования, которые должны быть произведены.
покер планирования (planning poker): Метод оценки трудозатрат, основанный на всеобщем одобрении. Обычно используется для оценки затрат или относительного объема пользовательских историй в гибких методологиях разработки программного обеспечения. Является вариантом «широкополосного предсказателя» с использованием колоды карт со значениями, представляющими число квантов, которыми оценивается работа. См. также гибкие методики разработки, широкополосный предсказатель.
покрытие (coverage): Уровень, выражаемый в процентах, на который определенный элемент покрытия был проверен набором тестов.
покрытие LCSAJ (LCSAJ coverage): Процент [LCSAJs] компонента, которые были проверены набором тестов. 100% покрытие [LCSAJ] предполагает 100% покрытие альтернатив.
покрытие N переходов (N-switch coverage): Процент последовательностей N+1 переходов, выполненных набором тестов.
покрытие альтернатив (decision coverage): Процент результатов альтернативы, который был проверен набором тестов. Стопроцентное покрытие решений подразумевает стопроцентное покрытие ветвей и стопроцентное покрытие операторов.
покрытие ветвей (branch coverage): Процент ветвей, которые были выполнены набором тестов. 100% покрытие ветвей подразумевает 100% покрытие альтернатив и 100% покрытие операторов.
покрытие граничных значений (boundary value coverage): Процент граничных значений, который был проверен набором тестов.
покрытие кода (code coverage): Метод анализа, определяющий, какие части программного обеспечения были проверены (покрыты) набором тестов, а какие нет, например, покрытие операторов, покрытие альтернатив или покрытие условий.
покрытие комбинаций условий (condition combination coverage): См. покрытие множественных условий.
покрытие комбинаций условий ветвей (branch condition combination coverage): См. покрытие множественных условий.
покрытие множественных условий (multiple condition coverage): Процент комбинаций всех исходов одиночных условий в рамках одного оператора, который был проверен набором тестов. Стопроцентное покрытие множественных условий означает стопроцентное модифицированное покрытие условий альтернатив.
покрытие операторов (statement coverage): Процентное отношение операторов, исполняемых набором тестов, к их общему количеству.
покрытие определений условий (condition determination coverage): См. модифицированное покрытие условия альтернативы.
покрытие потока данных (d low coverage): Процент пар «определение-использование», который был проверен набором тестов.
покрытие путей (path coverage): Процент путей, которые были пройдены в процессе выполнения набора тестов. 100% покрытие путей обеспечивает 100% покрытие LCSAJ.
покрытие условий (condition coverage): Процент исходов условий, которые были проверены набором тестов. 100% покрытие условий требует, чтобы каждое отдельное условие в каждом выражении решения было проверено как «Истина» и «Ложь».
покрытие условий альтернатив (decision condition coverage): Процент всех исходов условий и покрытий альтернатив, который был проверен набором тестов. Стопроцентное покрытие условий решения подразумевает стопроцентное покрытие условий и стопроцентное покрытие альтернатив.
покрытие условий ветвей (branch condition coverage): См. покрытие условий.
покрытие эквивалентного разбиения (equivalence partition coverage): Процент эквивалентных областей, который был проверен набором тестов.
политика тестирования (test policy): Документ высокого уровня, описывающий принципы, подход и основные цели организации в отношении тестирования.
полное тестирование (complete testing):
См. исчерпывающее тестирование.
пользовательская история (user story):
Высокоуровневое пользовательское или бизнес-требование, обычно использующееся в гибких методологиях разработки программного обеспечения. Обычно состоит из одного или нескольких предложений на разговорном или формальном языке, описывающих функциональность, необходимую пользователю, любые нефункциональные требования и включающих в себя критерии приемки.
См. также гибкая методология разработки программного обеспечения, требование.
пользовательский тест (user test):
Тест, во время которого реальные пользователи включаются в процесс оценки практичности компонента или системы.
пользовательское приёмочное тестирование (user acceptance testing): См. приёмочное тестирование.
пользовательское тестирование на основе сценариев (user scenario testing): См. тестирование по сценариям использования.
предусловие (precondition): Условия окружения и состояния, которые должны быть выполнены перед началом выполнения определенного теста или процедуры тестирования.
привлекательность (ractiveness): Способность программного продукта быть привлекательным для пользователя. [ISO 9126] См. также практичность.
приёмка (acceptance): См. приёмочное тестирование.
приемлемость (suitability): Способность программного продукта предоставлять подходящий функционал для определенных задач и целей конечного пользователя.
[ISO 9126] См. функциональность.
приёмочное тестирование (acceptance testing): Формальное тестирование по отношению к потребностям, требованиям и бизнес процессам пользователя, проводимое с целью определения соответствия системы критериям приёмки и дать возможность пользователям, заказчикам или иным авторизированым лицам определить, принимать систему или нет. [Согласно IEEE 610]
приоритет (priority): Степень важности, присваиваемая объекту. Например, дефекту.
приспособляемость (adaptability):
Способность программного продукта быть адаптированным к различным заданным окружениям без применения действий или средств, кроме тех, которые предназначены для этих целей для данного программного продукта.
См. также переносимость.
причина тестирования (test objective): Причина или цель разработки и выполнения теста.
причинно-следственная диаграмма (cause-eect diagram): Графическое представление, используемое для организации и отображения взаимосвязей различных возможных первопричин проблемы. Возможные причины возникновения реального или потенциального дефекта или отказа организованы в категории и подкатегории в горизонтальную древовидную структуру, с (потенциальным) дефектом или отказом в качестве корневого узла.
причинный анализ (causal analysis): Анализ дефектов для определения их первопричины. [CMMI]
проблема (problem): См. дефект.
проведение функционального разреза (operational proiling): Процесс разработки и реализации функционального разреза. См. также функциональный разрез.
проверенный (exercised): Можно сказать, что программный элемент был проверен тестовым сценарием, если входные данные приводят к выполнению этого элемента, например, такого как оператор, альтернатива или иной структурный элемент.
проверяющий (checker): См. рецензент.
прогон теста (test run): Выполнение теста на определенной версии объекта тестирования.
программная атака (sotware ack): См. атака.
программное обеспечение (sotware): Компьютерные программы, алгоритмы и, зачастую, документация и данные, относящиеся к функционированию компьютерной системы. [IEEE 610]
программный измеритель (program instrumenter): См. измеритель.
проект (project): Уникальный набор координируемых и контролируемых задач с датами начала и окончания, предпринимаемый для достижения цели в соответствии с определенными требованиями, включающими в себя ограничения по времени, стоимости и ресурсам. [ISO 9000]
проектирование теста (test design):
См. спецификация проектирования теста.