Автоматизация выполнения тестов

Стандартный глоссарий терминов, используемых в тестировании программного обеспечения

Источник — International Software Testing Qualifications Board (ISTQB)

А

Абстрактный тестовый сценарий

(abstract test case): См. тестовый сценарий высокого уровня.

автоматизация выполнения тестов

(test execution automation): Использование программного обеспечения (например, средств захвата/воспроизведения) для контроля выполнения тестов, сравнения полученных результатов с эталонными, установки предусловий тестов и других функций контроля тестирования и организации отчетов.

автоматизация тестирования (test automation):

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

автоматизированное тестирование (scripted testing):

Выполнение тестов, реализуемое при помощи заранее записанной последовательности тестов.

автоматизированное тестовое обеспечение (automated testware): Тестовое обеспечение, используемое в автоматизированном тестировании, например, инструментальные сценарии.

автоматизированный сценарий тестирования (test script): Обычно используется как синоним спецификации процедуры тестирования, как правило, автоматизированной.

активация путей (path sensitizing): Составление набора входных значений для обеспечения выполнение определенного пути.

актор (actor): Пользователь, или же любое другое действующее лицо или система, взаимодействующая определенным образом с тестируемой системой.

альтернатива (decision): Точка программы, в которой управление имеет два или более альтернативных путей. Узел с двумя или более связями для разделения ветвей.

альфа-тестирование (alpha testing): Моделируемое или действительное эксплуатационное

тестирование потенциальными пользователями/заказчиками или независимой командой тестирования на стороне разработчиков, но вне разрабатывающей организации. Альфа- тестирование часто применяется к коробочному программному обеспечению в качестве внутреннего приёмочного тестирования.

анализ влияния (impact analysis): Оценка изменений в документации разработки и тестирования, а также компонентов с целью внесения данных изменений в определенные требования.

анализ граничных значений (boundary value analysis): Разработка тестов методом черного ящика, при котором тестовые сценарии проектируются на основании граничных значений. См. также граничное значение.

анализ дерева недочетов (TA) (ault Tree Analysis (TA)): Метод, используемый для анализа причин недочетов (дефектов). Методика визуально моделирует для вскрытия специфических недочетов то, как логические связи между отказами, человеческими ошибками и внешними событиями могут сочетаться.

анализ доменов (domain analysis): Методика разработки тестов, относящаяся к методу черного ящика, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно. Методика базируется и обобщает методы эквивалентного разбиения и анализа граничных значений. См. также анализ граничных значений, эквивалентное разбиение.

анализ мутаций (mutation analysis): Метод определения законченности набора тестов путем измерения степени, с которой набор тестов может отличить программу от ее незначительных вариаций.

анализ Парето (Pareto analysis): Статистическая техника предположений, используемая для выбора ограниченного числа факторов, оказывающих значительный итоговый эффект. С точки зрения качества, основное число проблем (80%) вызваны несколькими причинами (20%).

 

анализ первопричины (root cause analysis): Анализ, направленный на идентификацию первопричин дефектов. При применении мер к устранению первопричины, можно надеяться на минимизацию частоты появления дефектов определенного типа.

анализ покрытия (coverage analysis): Измерение достигнутого покрытия по отношению к заданному элементу покрытия во время выполнения теста в соответствии с предопределенными критериями. Позволяет определить, необходимо ли дополнительное тестирование, и если да, то какие тестовые сценарии нужны.

анализ потока данных (d low analysis): Вид статического анализа, основанный на определении и использовании переменных.

анализ потока управления (control low analysis): Вид статического анализа, основанный на представлении уникальных путей (последовательностей событий) в процессе выполнения компонента или системы. Анализ потока управления оценивает целостность структур потока управления, выявляя возможные аномалии потока управления, такие как закрытые циклы или логически недостижимые шаги.

анализ причинно-следственных связей (cause-eect analysis): См. отображение причинно­следственных связей.

анализ рисков (risk analysis): Процесс оценки идентифицированных рисков для вычисления их вероятности и влияния.

анализ факторов опасности (hazard analysis): Метод, используемый для характеристики элементов риска. Результат анализа случайности определяют методы, используемые в разработке и тестировании системы. См. также анализ рисков.

анализ тестируемости (testability review): Детальная проверка базиса тестирования с целью определения, является ли он достаточно качественным, чтобы выступать в роли первоисточника для процесса тестирования.

анализ тестовых точек (TPA) (Test Point Analysis (TPA)): Метод оценки затрат на тестирование на основе формулы, основанный на анализе функциональных точек.

 

анализ типов отказов и эффекта (MEA) (ailure Mode and Eect Analysis (MEA)): Систематический подход для определения и анализа рисков идентификации возможных типов отказов и попытка их предотвращения. См. также анализ типов отказов, эффекта и критичности (MECA)

анализ типов отказов, эффекта и критичности (MECA) (ailure Mode, Eect and Criticality Analysis (MECA)):

Расширение MEA; в дополнение к основному MEA, включает анализ критичности, используемый для отображения вероятности типов отказов по отношению к критичности их последствий. Результат отражает тип отказа с относительно высокой вероятностью и критичностью последствий, позволяя предпринять корректирующие действия там, где они будут иметь наибольшую ценность. См. также анализ типов отказов и эффекта.

анализ типов отказов, эффекта и критичности программного обеспечения (Sotware ailure Mode Eect, and Criticality Analysis(SMECA)): См. анализ типов отказов, эффекта и критичности (MECA).

анализ функциональных точек (unction Point Analysis (PA)): Метод, помогающий при оценке размера функциональности информационной системы. Оценка не зависит от технологии. Оценка может быть использована как основа оценки производительности, расчета необходимых ресурсов и контроля проекта.

анализ типов отказов и эффектов программного обеспечения (Sotware ailure Mode and Eect Analysis (SMEA)): См. анализ типов отказов и эффектов (MEA)

анализ дерева недочетов программного обеспечения (Sotware ault Tree Analysis (STA)): См. анализ дерева недочетов (TA)

анализатор (analyzer): См. статический анализатор.

анализатор кода (code analyzer): См. статический анализатор кода.

анализируемость (analyzability): Способность программного продукта быть проверенным на отсутствие отказов или их причин, а также определение частей ПО, которые нужно проверить вследствие изменений. [ISO 9126] См. также сопровождаемость.

аналитический отчет о тестировании (test evaluation report): Документ, создаваемый в конце процесса тестирования и подводящий итог тестовым активностям и результатам. Также в нем содержится оценка процесса тестирования и полученный опыт.

аналитическое тестирование (analytical testing): Тестирование, основанное на системном анализе продуктовых рисков, требований и т.д.

аномалия (anomaly): Любое состояние, которое не соответствует ожиданиям, основанным на чьем- либо восприятии или опыте, или же спецификации требований, проектной документации, пользовательской документации, стандартах и т.п. Аномалии могут быть найдены во время (но не только) рецензирования, тестирования, анализа, сборки или использования программных продуктов или соответствующей документации [IEEE1044] См. также помеха, дефект, отклонение, ошибка, недочет, отказ, инцидент, проблема.

анти-паттерн (anti-pern): Повторяемое действие, процесс, структура или повторно используемое решение, изначально кажущееся полезным и часто используемое, однако оказывающееся на практике неэффективным и(или) контрпродуктивным.

анти-регрессионное тестирование (regression-averse testing): Тестирование, использующее

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

архитектор тестов (test architect):

1. Человек, предоставляющий рекомендации и стратегические направления для организации тестирования и его связи с остальными областями.

2. Человек, определяющий метод структурирования тестирования данной системы, включая такие аспекты как инструменты тестирования и управление тестовыми данными.

 

 

ассоциативная карта (mind-map): Схема, использующаяся для представления слов, идей, задач или других предметов, связанных и расположенных вокруг центрального ключевого слова или идеи. Ассоциативные карты используются для создания, визуализации, структурирования и классификации идей, как помощь в учебе, для организации и решения проблем, как помощь в принятии решений, и записи.

атака (ack): Направленная и нацеленная попытка оценить качество, главным образом надежность, объекта тестирования за счет попыток вызвать определенные отказы. См. также негативное тестирование.

атака на недочеты (ault ack): См. атака.

атака через посредника (man in the middle ack):

Перехват, эмуляция и/или изменение и последующее перенаправление коммуникаций (например, транзакций по кредитной карте) третьей стороной таким образом, что пользователь остается в неведении относительно присутствия данной третьей стороны.

атомарное условие (atomic condition): Условие, над которым невозможно провести дальнейшую декомпозицию, т.е. условие, не содержащее два или более одинарных условий, объединенных логическими оператороми (И, ИЛИ, Исключающее ИЛИ).

АТТ (TPA): См. анализ тестовых точек.

аттрибут качества: свойство или характеристика, влияющая на качество объекта. [IEEE 610]

аудит (audit): Независимая оценка программных продуктов или процессов с целью установления соответствия стандартам, рекомендациям, спецификациям и/или процедурам, основанным на объективных критериях, включающих документы, которые определяют: 1. форму или содержание продуктов для производства; 2. процесс, согласно которому продукты будут произведены; 3. как будет измеряться соответствие стандартам или рекомендациям. [IEEE 1028]

аудит конфигурации (coniguration auditing): Функция проверки состава библиотек элементов конфигурации, например на соответствие стандартам. [IEEE 610]

 

 

Б

базис тестирования (test basis): Документ, на основании которого определяются требования к компоненту или системе. Документация, на которой базируются тестовые сценарии. Если правка данного документа может быть осуществлена только в процессе формальной процедуры внесения изменения, то такой базис тестирования называется замороженным базисом тестирования.

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

базовый блок (basic block): Последовательность одной или более упорядоченных выполняемых операторов, которые не содержат ветвей. Примечание: узел на графе потока управления представляет собой базовый блок.

базовый набор тестов (basis test set): Набор тестовых сценариев полученных на основании внутренней структуры компонента или спецификации, предназначенный для убеждения в 100% достижении заданных критериев покрытия.

безопасность (saety): Способность программного продукта при использовании оговоренным образом оставаться в рамках приемлемого риска причинения вреда здоровью, бизнесу, программам, собственности или окружающей среде. [ISO 9126]

бета-тестирование (beta testing):

Эксплуатационное тестирование потенциальными и/или

существующими клиентами/заказчиками на внешней стороне никак не связанными с разработчиками, с целью определения действительно ли компонент или система удовлетворяет требованиям клиента/заказчика и вписывается в бизнес-процессы. Бета-тестирование часто проводится как форма внешнего приёмочного тестирования готового программного обеспечения для того чтобы получить отзывы рынка.

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

В

валидация (validation): Доказанное объективными результатами исследования подтверждение того, что требования для ожидаемого конкретного использования приложения были выполнены. [ISO 9000]

ведущий аудитор (lead assessor): Человек, возглавляющий аудит. В некоторых случаях, например CMMi и TMMi, для проведения формальных оценок ведущий аудитор должен быть аккредитован и формально обучен.

ведущий специалист по тестированию (test leader): См. руководитель тестирования

верификация (veriication): Доказанное объективными результатами исследования подтверждение

того, что определенные требования были выполнены. [ISO 9000]

вероятность риска (risk likelihood): Оценочная вероятность реализации риска.

вертикальная трассируемость (vertical traceability):

Отслеживание требований через уровни разработки к компонентам.

ветвь (branch): Базовый блок, который может быть выбран для выполнения, основываясь на логической структуре программы, в которой доступен один из двух или более альтернативных путей, например, case, jump, go to, i then-else.

веха (milestone): Точка в течение времени проекта, к которой заранее определенные (промежуточные) поставки и результаты должны быть готовы.

влияние риска (risk impact): Последствия, которые проявятся в случае реализации риска.

внесение недочетов (ault injection):

Процесс сознательного внесения дефектов в систему с целью определить, может ли система определить дефект и, возможно, восстановиться после его обнаружения. Внесение недочетов призвано эмулировать отказы, которые могут произойти во время эксплуатации. См. также устойчивость к недочетам.

внешнее стороннее тестирование (outsourced testing):

Тестирование, производимое людьми, не находящимися в одном месте с командой разработки и не являющимися сотрудниками одной компании.

 

возможность взаимодействия (interoperability):

Способность программного продукта взаимодействовать с одним или более заданными компонентами или системами [ISO 9126].

См. также функциональность.

воспроизводимость теста (test reproduceability): Атрибут теста, показывающий, что результаты теста одинаковы при каждом выполнении этого теста.

восстанавливаемость (recoverability):

Способность программного продукта восстанавливать требуемый уровень работоспособности и рабочие данные, пострадавшие в результате ошибки. [ISO 9126]

Также см. надежность.

Восходящее тестирование

(bottom - up testing):

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

См. также интеграционное тестирование.

встроенная итеративная модель разработки (embedded iterative development model): Подмодель жизненного цикла разработки, применяющая итеративный подход к детализированному дизайну, программированию и тестированию внутри глобальной последовательной модели. В данном случае высокоуровневые спецификации дизайна подготавливаются и утверждаются для проекта в целом, однако конкретная детализация дизайна, разработки программного кода и тестирования осуществляется внутри циклов.

вход (input): Переменная (хранимая внутри или вне компонента), считываемая компонентом.

входное значение (input value): Экземпляр входа.

См. также вход.

входной тест (intake test): Специальный тип теста «на дым» для принятия решения, готов ли компонент или система готова для дальнейшего детального тестирования. Обычно начинается в начале фазы тестирования.

См. также тест «на дым».

 

входные данные теста (test input): Данные, получаемые объектом тестирования из внешнего источника во время проведения тестирования. В роли внешнего источника может выступать оборудование, программное обеспечение или человек.

выборочное тестирование (random testing): Разработка тестов методом черного ящика, при котором тестовые сценарии выбираются для соответствия функциональному разрезу, обычно с помощью алгоритма псевдослучайного выбора. Этот метод может использоваться для тестирования таких нефункциональных атрибутов, как надежность и производительность.

выполнение теста (test execution): Процесс запуска теста на исследуемом компоненте или системе, приводящий к реальным результатам.

выполнимый путь (easible path): Путь, для которого существует набор входных значений и предусловий, позволяющих ему быть выполненным.

выполняемый оператор (executable statement):

Оператор, который при компиляции переводится в объект кода, и который будет выполнен процедурно при выполнении программы, а также может выполнять операции над данными.

выходное значение (output value): Экземпляр выходных данных. См. также выходные данные

выходные данные (output): Переменная (хранимая внутри компонента или вне его), выданная компонентом.

Г

гибкая методология разработки программного обеспечения (agile sotware development):

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

гибкое тестирование (agile testing): Способ тестирования для проектов, использующих гибкие методологии разработки программного обеспечения, включающий такие техники и методы, как экстремальное программирование, и рассматривающий процесс разработки как потребителя процесса тестирования и делающий упор на парадигму раннего тестирования. См. также разработка на основе тестов.

гиперссылка (hyperlink): Указатель на веб-странице, ведущий на другие веб-страницы.

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

горизонтальная трассируемость (horizontal traceability): Трассировка требований к уровню тестирования по отношению к уровням документации (например, план тестирования, спецификация проектирования теста, спецификация тестовых сценариев и спецификация процедуры тестирования или автоматизированный сценарий тестирования).

готовое программное обеспечение (o-the-shel sotware):

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

ГПТ (TPG): см. группа процесса тестирования.

граничное значение (boundary value): Входное значение или выходные данные, которое находится на грани эквивалентной области или на наименьшем расстоянии от обеих сторон грани, например, минимальное или максимальное значение области.

граф вызовов (call graph): Абстрактное представление вызовов связей между подпрограммами в программе.

граф потока управления (control low graph): Абстрактное представление всех возможных последовательностей событий (путей) в процессе выполнения компонента или системы.

график тестирования (test schedule): Список задач, действий или событий в процессе тестирования, определяющий даты и/или время их начала и завершения, и их взаимозависимости.

группа контроля изменений (change control board):

См. группа контроля конфигурации.

группа контроля конфигурации (coniguration control board (CCB)):

Группа людей, ответственных за оценку и утверждение или неутверждение предложенных изменений в элементах конфигурации, а также за обеспечение внесения предложенных изменений. [IEEE 610]

 

группа процесса тестирования (Test Process Group):

Группа специалистов (по тестированию), которые содействуют определению, техническому обслуживанию и совершенствованию процессов тестирования, используемых в организации. [Согласно CMMI]

группа сортировки дефектов (deect triage committee):

См. группа управления дефектами.

группа управления дефектами (deect management committee): Универсальная группа

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

грязное тестирование (dirty testing):

См. негативное тестирование.

Д

действия (модель IDEAL) (acting (IDEAL)): Фаза в модели IDEAL, в рамках которой разработанные усовершенствования осуществляются и разворачиваются внутри всей организации. Фаза действий состоит из: создания решения, пилотное\тестовое решение, усовершенствование решения и выполнение решения. См. также модель IDEAL.

дерево классификации (classiication tree): Дерево, показывающее иерархично упорядоченные эквивалентные области, которое используется для разработки тестовых сценариев в методе дерева классификации. См. также метод дерева классификации.

дефект (deect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы.

диагностика (модель IDEAL) (diagnosing (IDEAL)): Фаза модели IDEAL, в которой определяется текущее состояние и то, в котором хочется быть. Фаза диагностирования включает следующие действия: охарактеризовать текущее и желаемое состояния, дать рекомендаций. См. также модель IDEAL.

 

диаграмма №икавы (Ishikawa diagram):

См. причинно-следственная диаграмма.

диаграмма причинно-следственных связей (cause-eect graph): Графическое представление входных данных и/или сигналов (причин) и связанных выходных данных (следствий), которое может быть использовано для разработки тестовых сценариев.

диаграмма состояний (state diagram): Диаграмма, иллюстрирующая состояния, которые может принимать компонент или система, и показывающая ситуации или события, приводящие к переходу из одного состояния в другое. [IEEE 610]

диаграмма-елочка (ishbone diagram):

См. причинно-следственная диаграмма.

дикий указатель (wild pointer): Указатель, указывающий к точке, находящийся вне диапазона, определенного для указателя или не существующей. См. указатель.

динамический анализ (dynamic analysis): Процесс оценки поведения, например производительности памяти, загрузки ЦПУ системы или компонента во время выполнения. [IEEE 610]

динамическое сравнение (dynamic comparison):

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

динамическое тестирование (dynamic testing):

Тестирование, проводимое во время выполнения программного обеспечения, компонента или системы.

директор по тестированию (test director): Руководитель высшего звена, управляющий руководителями тестирования. См. также руководитель тестирования.

доверительный интервал (conidence interval):

В управлении проектными рисками — промежуток времени, в течении которого должно быть произведены корректирующие действия, чтобы оставаться эффективными с точки зрения уменьшения влияния риска.

домен (domain): Набор, из которого могут быть выбраны корректные входные и/или выходные данные.

доступность (availability): Уровень готовности и доступности компонента или системы при необходимости их использования. Часто выражается в процентах. [IEEE 610]

 

драйвер (driver): Компонент программного обеспечения или средство тестирования, которое заменяет компонент, обеспечивающий управление и/или вызов компонента или системы.

Е

ежедневная сборка (daily build): Действия, в ходе которых система ежедневно (обычно ночью) компилируется и собирается целиком, так что целостная система доступна в любое время, включая все последние изменения.

Ж

жизненный цикл модели (liecycle model): Разбиение жизни продукта или проекта на фазы. [CMMI]

См. также жизненный цикл программного обеспечения.

жизненный цикл программного обеспечения (sotware liecycle): Период времени, начинающийся с момента появления концепции программного обеспечения и заканчивающийся тогда, когда дальнейшее использование программного обеспечения невозможно. Жизненный цикл программного обеспечения обычно включает в себя следующие этапы: концепт, описание требований, дизайн, реализация, тестирование, инсталляция и наладка, эксплуатация и поддержка и, иногда, этап вывода из эксплуатации. Данные фазы могут накладываться друг на друга или проводиться итерационно.

З

заблокированный тестовый сценарий (blocked test case): Тестовый сценарий, который не может быть выполнен вследствие невыполнения предусловий.

завершение тестирования (test closure):

Во время фазы завершения тестирования собираются данные обо всех завершенных процессах с целью объединения опыта, тестового обеспечения, фактов и чисел. Фаза завершения тестирования состоит из архивирования тестового обеспечения и оценки процесса тестирования, включающей в себя подготовку аналитического отчета о тестировании.

См. также процесс тестирования.

заглушка (stub): Минимальная или специализированная реализация программного компонента. Использующаяся для подмены компонента, от которого зависит разработка или тестирование другого компонента системы. [IEEE 610]

 

заданные входные данные (speciied input): Входные данные, для которых результат описывается спецификацией.

заказное программное обеспечение (bespoke sotware, custom sotware): Программное

обеспечение, разработанное специально для группы пользователей или заказчиков. Противоположность — готовое программное обеспечение.

заказной инструмент (custom tool): Инструментарий разработки программного обеспечения, разработанный специально для группы пользователей или заказчиков.

закорачивание (short-circuiting): Методика языка программирования или интерпретатора для оценки комплексных условий, при которых одна часть логического оператора может быть опущена, если второй части достаточно для определения итогового результата.

заменяемость (replaceability): Способность программного продукта к использованию его вместо другого программного продукта для тех же самых целей и в том же самом окружении [ISO 9126] См. также: переносимость.

замороженный базис тестирования (rozen test basis):

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

запись теста (test recording):

См. протоколирование тестирования.

защищенность (security): Свойства программного продукта, отражающие его способность не допускать неавторизированный доступ, случайный или умышленный, к программам и данным. См. функциональность.

значение цикломатической сложности (cyclomatic number): См. цикломатическая сложность.

зрелость (maturity):

1. Уровень эффективности корпоративных процессов и методик конкретной организации. См. также интегрированная модель зрелости процессов программного обеспечения, интегрированная модель зрелости тестирования.

2. Возможность программного продукта избегать отказа как результата дефектов в программном обеспечении. [ISO 9126] См. также надежность.

 

И

идентификация конфигурации (coniguration identiication):

Элемент управления конфигурацией, состоящий из выбора элементов конфигурации для системы и фиксирования их функциональных и физических характеристик в технической документации. [IEEE 610]

изменяемость (changeability): Способность программного продукта быть измененным определенным образом при необходимости. [ISO 9126]. См. также сопровождаемость.

измерение (measurement): Процесс присвоения числа или категории сущности для описания атрибута этой сущности. [ISO14598]

измеритель (instrumenter): Программный инструмент для оснащения средствами контроля.

изоляционное тестирование (isolation testing):

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

изучаемость (learnability): Способность программного продукта быть изученным пользователем для работы с этим приложением. [ISO 9126] См. также практичность.

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

См. также модель IDEAL.

именованный тестовый сценарий (concrete test case): См. тестовый сценарий низкого уровня.

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

имитация (simulation): Моделирование выбранных поведенческих характеристик одной физической или теоретической системы другой системой. [ISO 2382/1]

индикатор (indicator): Измерение, которое может быть использовано для оценки или предсказания другого измерения. [ISO14598]

 

 

индикатор производительности(perormance indicator):

Высокоуровневая метрика эффективности и/или производительности, использующаяся для направления и контроля прогрессивной разработки. Например, смещение сроков для разработки программного обеспечения. [CMMI]

индикатор производительности тестов (test perormance indicator): Высокоуровневая метрика эффективности и/или продуктивности, использующаяся для управления и контроля при поэтапной разработке тестов, например, процент выявления дефектов.

инициирование (модель IDEAL) (Initiating (IDEAL)):

Фаза модели IDEAL, в которой закладывается фундамент для успешных попыток по улучшению. Фаза инициирования включает следующие действия: установка контекста, построение спонсорства и устава инфраструктуры. См. также модель IDEAL.

инкрементная модель разработки (incremental development model):

Модель жизненного цикла разработки, в которой проект разделен на серию приращений, каждое из которых добавляет часть функциональности в общих требованиях проекта. Требования приоритизированы и внедряются в порядке приоритетов. В некоторых (но не во всех) версиях этой модели жизненного цикла каждый подпроект следует «мини V-модели» со своими собственными фазами проектирования, кодирования и тестирования.

инкрементное тестирование (incremental testing):

Тестирование, при котором компоненты или системы интегрируются и тестируются по одному или вместе до тех пор, пока все компоненты или системы не интегрированы и не протестированы.

инспектор (inspector): См. рецензент.

инспекция (inspection): Тип равноправного анализа, основанный на визуальной проверке документов для поиска ошибок. Например, нарушение стандартов разработки и несоответствие документации более высокого уровня. Наиболее формальная методика рецензирования и поэтому всегда основывается на документированной процедуре. [IEEE 610, IEEE1028]. См. также равноправный анализ.

 

инструмент выполнения тестов (test execution tool):

Инструмент, который позволяет исполнять другое программное обеспечение с использованием автоматического сценария тестирования, например — захват/воспроизведение.

инструмент динамического анализа (dynamic analysis tool): Инструмент, обеспечивающий информацией о состоянии кода программного обеспечения во время его выполнения. Эти инструменты наиболее часто используются для поиска пустых указателей, проверки вычислений указателя, а также для отслеживания распределения, использования и освобождения памяти и определения утечек памяти.

инструмент записи/воспроизведения (record/playback tool):

См. инструмент захвата/воспроизведения.

инструмент захвата/воспроизведения (capture/playback tool):

Инструмент выполнения тестов, в котором входная информация записывается во время ручного тестирования с целью создания автоматизированного сценария тестирования, который может быть выполнен позже (т.е., повторен). Эти средства часто используют для поддержки автоматизированного регрессионного тестирования.

инструмент захвата/повтора (capture/replay tool):

См. инструмент захвата/воспроизведения.

инструмент защиты (security tool):

Инструмент, обеспечивающий защиту приложения.

инструмент измерения покрытия (coverage measurement tool): См. инструмент покрытия.

инструмент моделирования (modeling tool):

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

инструмент мониторинга (monitoring tool):

См. монитор.

инструмент нагрузочного тестирования (load testing tool): Инструмент для поддержки нагрузочного тестирования, способный эмулировать увеличивающуюся нагрузку (число одновременных пользователей и/или транзакций во время определенного промежутка времени). См. также инструмент тестирования производительности.

инструмент отладки (debugging tool): Инструмент, используемый программистами для воспроизведения отказов, исследования состояния программ и поиска соответствующего дефекта. Отладчики позволяют программистам исполнять программу пошагово для останова на любом операторе программы и для установки и проверки программных переменных.

инструмент отслеживания дефектов (deect tracking tool): См. инструмент управления дефектами.

инструмент отслеживания помех (bug tracking tool): См. инструмент управления дефектами.

Поделиться: