Тип дефекта (deect type):

Элемент систематизации дефектов. Систематизация дефектов

осуществляется на основе различных факторов, включающих в себя (но не ограничивающихся перечисленными):

1. Фаза или этап разработки, во время которого дефект был создан. Например: ошибка

2. спецификации или ошибка программирования.

3. Характеристика дефектов. Например: ошибка завышения или занижения на единицу

4. Некорректность. Например: некорректный относительный оператор, ошибка синтаксиса языка.

5. программирования, некорректное присвоение.

6. Проблемы производительности. Например: чрезмерное время выполнения, недостаточная

7. доступность.

тип отказа (ailure mode): Физическое или функциональное проявление типа отказа. Например, система в состоянии отказа может быть охарактеризирована медленным выполнением операций, неправильным выводом или полным прерыванием выполнения. [IEEE 610]

тип риска (risk type): Набор рисков, сгруппированных по одному или нескольким общим факторам, таким как атрибут качества, причина, местонахождение, или потенциальные последствия риска. Определенный набор типов рисков относится к тому типу тестирования, который может смягчить (или проконтролировать) данный тип риска. Например, риск неправильного понимания взаимодействия с пользователем может быть смягчен при помощи тестирования практичности.

тип тестирования (test type): Группа процессов тестирования, направленных на тестирование компонента или системы с определенной целью, например, функциональное тестирование,

тестирование практичности, регрессионное тестирование и т.д. Один и тот же тип тестирования может встречаться в одном или нескольких уровнях тестирования или фазах тестирования. [TMap]

типовое программное обеспечение (standard sotware): См. готовое программное обеспечение.

точка входа (entry point): Выполняемый оператор или шаг обработки данных, определяющий точку, с которой данный процесс должен стартовать.

точка выхода (exit point): Выполняемый оператор или шаг обработки данных, определяющий точку, в которой данный процесс должен останавливаться.

точность (accuracy): Способность программного продукта обеспечивать правильные или

согласованные результаты или действия с необходимым уровнем точности. [ISO 9126] См. также функциональность.

транзакционный анализ (анализ сделок) (transactional analysis): Анализ транзакций (сделок) между людьми и их разумом; транзакция (сделка) определяется как стимул плюс ответ. Транзакции (сделки) происходят между людьми и между эго-состояниями личностных сегментов внутри разума одного человека.

трассируемость (traceability):

Способность идентифицировать связанные объекты в документации и программном обеспечении, например, требования со связанными с ними тестами. См. горизонтальная трассируемость, вертикальная трассируемость.

требование (requirement): Условия или возможности, необходимые пользователю для решения определенных задач или достижения определенных целей, которые должны быть достигнуты для выполнения контракта, стандартов, спецификации, или других формальных документов. [IEEE 610]

требования возобновления (resumption requirements): Определенный комплекс тестовых мероприятий, который должен быть повторен при возобновлении тестирования после приостановки. [IEEE 829]

У

указатель (pointer): Объект, описывающий местонахождение другого объекта. Например, объект, определяющий адрес следующей записи о сотруднике в очереди обработки. [IEEE 610]

управление дефектами (deect management): Процесс распознавания, исследования, принятия действий и устранения дефектов. Он включает в себя фиксирование дефектов, их классификацию и выявления последствий. [IEEE 1044]

управление изменениями (change management):

· структурный подход к изменению индивидуумов, команд и организаций от текущего состояния к желаемому будущему состоянию.

· контролируемый путь воздействия на результат или предполагаемые изменения продукта или услуги.

уровень целостности программного продукта (sotware integrity level): Уровень, на котором программный продукт соответствует набору определенных на основе пожеланий заказчика программных и/или производных от программных характеристик (программная сложность, оценка рисков, уровень безопасности, уровень защищенности, желаемая производительность, надежность или стоимость, и т.д.), призванных отразить важность программного продукта для заказчика.

уровневый план тестирования (level test plan): План тестирования, обычно относящийся к одному уровню тестирования. См. также план тестирования.

условие (condition): Логическое выражение, которое может принимать значения Истина или Ложь, например A>B. См. такжетестирование условий.

условие ветви (branch condition): См. условие.

Усовершенствование процессов (process improvement):

Программа действий, нацеленная на улучшение производительности и зрелости организационных процессов, и результат такой программы. [CMMI]