Термины относится к Программе Базового уровня ISTQB. Foundation syllabus. Первые 50 терминов.

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

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

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

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

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

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

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

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

Атака на недочеты (fault attack): См. атака.

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

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

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

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

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

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

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

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

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

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

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

Вертикальная трассируемость (vertical traceability): Отслеживание требований через уровни разработки к компонентам.

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

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

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

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

Внешнее стороннее тестирование (outsourced testing): Тестирование, производимое людьми, не находящимися в одном месте с командой разработки и не являющимися сотрудниками одной компании.

Возможность взаимодействия (interoperability): Способность программного продукта взаимодействовать с одним или более заданными компонентами или системами См. также функциональность.

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

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

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

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

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

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

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

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

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

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

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

Динамическое тестирование (dynamic testing): Тестирование, проводимое во время выполнения программного обеспечения, компонента или системы.

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

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

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

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

Заказное программное обеспечение (bespoke software, custom software): Программное обеспечение, разработанное специально для группы пользователей или заказчиков. Противоположность - готовое программное обеспечение.

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

Инкрементное тестирование (incremental testing): Тестирование, при котором компоненты или системы интегрируются и тестируются по одному или вместе до тех пор, пока все компоненты или системы не интегрированы и не протестированы.

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

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

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

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

Чтобы просмотреть или добавить комментарий, выполните вход Чтобы просмотреть или добавить комментарий, выполните вход