Версия 3 (от 9 июля 2014 года) Подготовлен Glossary Working Party
 Скачать 0.93 Mb.
|
|
тестовая ситуация (test situation): См. тестовое условие. тестовое обеспечение (testware): Артефакты, создаваемые во время процесса тестирования и требующиеся для планирования, разработки и выполнения тестов. Например: документация, сценарии, входы, ожидаемые результаты, процедуры установки и удаления, файлы, базы данных, окружение и любое другое дополнительное программное обеспечение или инструменты, используемые в тестировании. [Fewster and Graham] тестовое окружение (test environment): Окружение, включающее в себя аппаратное обеспечение, измерительную аппаратуру, имитаторы, программный инструментарий и прочие инструменты, необходимые для проведения теста. [IEEE 610] тестовое покрытие (test coverage): См. покрытие. тестовое сравнение (test comparison): Процесс выявления разницы между реальными результатами, выдаваемыми исследуемым компонентом или системой, и ожидаемым результатом теста. Тестовое сравнение может производиться как во время выполнения теста (динамическое сравнение), или же по окончании выполнения теста. тестовое требования (test requirement): См. тестовое условие. тестовое условие (test condition): Объект или событие в компоненте или системе, которое должно быть проверено одним или несколькими тестовыми наборами. Например: функция, транзакция, свойство, атрибут качества или структурный элемент. F ATM F F F ATT F F 62 тестовые данные (test data): Данные, которые существуют (например, в базе данных) на начало выполнения теста и влияют на работу, или же испытывают влияние со стороны тестируемой системы или компонента. тестовый генератор (test generator): См. инструмент подготовки тестовых данных. тестовый драйвер (test driver): См. драйвер. тестовый инцидент (test incident): См. инцидент. тестовый компаратор (test comparator): Инструмент тестирования, осуществляющий автоматическое сравнение реального и ожидаемого результата. тестовый отчет по инциденту (test incident report): См. отчет по инциденту. тестовый предсказатель (test oracle): Источник, при помощи которого можно определить ожидаемые результаты для сравнения с реальными результатами, выдаваемыми тестируемой системой. В роли тестового предсказателя могут выступать уже имеющаяся система (для эталонного тестирования), руководство пользователя, профессиональные знания специалиста, однако им не может быть программный код. [Adrion] тестовый стенд (test bed, test rig): См. тестовое окружение. тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610] тестовый сценарий высокого уровня (high level test case): Тестовый сценарий без конкретных (уровня реализации) значений входных данных и ожидаемых результатов. Использует логические операторы, а экземпляры реальных значений еще не определены и/или доступны. См. также тестовый сценарий низкого уровня. тестовый сценарий низкого уровня (low level test case): Тестовый сценарий с конкретными (уровня реализации) значениями входных данных и ожидаемых результатов. Логические операторы из тестовых сценариев высокого уровня заменяются реальными значениями, которые соответствуют целям этих логических операторов. См. также тестовые сценарии высокого уровня. тестопригодные требования (testable requirements): Требования, выраженные в терминах, допускающих начало работы над разработкой тестов (и, впоследствии, над тестовыми сценариями) и выполнение тестов для определения соответствия заявленным требованиям. [IEEE 610] технический анализ (technical review): Обсуждение, имеющее целью выработать единый подход к техническому процессу, и проводимое равноправными участниками. [Gilb and Graham], [IEEE 1028] См. равноправный анализ. ATA ATA F ATM F ATM F F F-AT 63 тип дефекта (defect type): Элемент систематизации дефектов. Систематизация дефектов осуществляется на основе различных факторов, включающих в себя (но не ограничивающихся перечисленными): • Фаза или этап разработки, во время которого дефект был создан. Например: ошибка спецификации или ошибка программирования. • Характеризация дефектов. Например: ошибка завышения или занижения на единицу • Некорректность. Например: некорректный относительный оператор, ошибка синтаксиса языка программирования, некорректное присвоение. • Проблемы производительности. Например: чрезмерное время выполнения, недостаточная доступность. тип отказа (failure mode): Физическое или функциональное проявление типа отказа. Например, система в состоянии отказа может быть охарактеризирована медленным выполнением операций, неправильным выводом или полным прерыванием выполнения. [IEEE 610] тип риска (risk type): Набор рисков, сгруппированных по одному или нескольким общим факторам, таким как атрибут качества, причина, местонахождение, или потенциальные последствия риска. Определенный набор типов рисков относится к тому типу тестирования, который может смягчить (или проконтролировать) данный тип риска. Например, риск неправильного понимания взаимодействия с пользователем может быть смягчен при помощи тестирования практичности. тип тестирования (test type): Группа процессов тестирования, направленных на тестирование компонента или системы с определенной целью, например, функциональное тестирование, тестирование практичности,регрессионное тестирование и т.д. Один и тот же тип тестирования может встречаться в одном или нескольких уровнях тестирования или фазах тестирования. [TMap] типовое программное обеспечение (standard software): См. готовое программное обеспечение. точка входа (entry point): Выполняемый оператор или шаг обработки данных, определяющий точку, с которой данный процесс должен стартовать. точка выхода (exit point): Выполняемый оператор или шаг обработки данных, определяющий точку, в которой данный процесс должен останавливаться. точность (accuracy): Способность программного продукта обеспечивать правильные или согласованные результаты или действия с необходимым уровнем точности. [ISO 9126] См. также функциональность. транзакционный анализ (анализ сделок) (transactional analysis): Анализ транзакций (сделок) между людьми и их разумом; транзакция (сделка) определяется как стимул плюс ответ. Транзакции (сделки) происходят между людьми и между эго-состояниями личностных сегментов внутри разума одного человека. трассируемость (traceability): Способность идентифицировать связанные объекты в документации и программном обеспечении, например, требования со связанными с ними тестами. См. горизонтальная трассируемость, вертикальная трассируемость. F EITP 64 требование (requirement): Условия или возможности, необходимые пользователю для решения определенных задач или достижения определенных целей, которые должны быть достигнуты для выполнения контракта, стандартов, спецификации, или других формальных документов. [IEEE 610] требования возобновления (resumption requirements): Определенный комплекс тестовых мероприятий, который должен быть повторен при возобновлении тестирования после приостановки. [IEEE 829] У указатель (pointer): Объект, описывающий местонахождение другого объекта. Например, объект, определяющий адрес следующей записи о сотруднике в очереди обработки. [IEEE 610] управление дефектами (defect management): Процесс распознавания, исследования, принятия действий и устранения дефектов. Он включает в себя фиксирование дефектов, их классификацию и выявления последствий. [IEEE 1044] управление изменениями (change management): (1) структурный подход к изменению индивидуумов, команд и организаций от текущего состояния к желаемому будущему состоянию. (2) контролируемый путь воздействия на результат или предполагаемые изменения продукта или услуги. См. также управление конфигурацией. управление инцидентами (incident management): Процесс распознавания, исследования, принятия действий и устранения инцидентов. Включает в себя регистрацию инцидентов, их классификацию и определение влияния. [IEEE 1044] управление конфигурацией (configuration management): Наука, применяющая техническое и административное руководство и контроль для: идентификации и документирования функциональных и физических характеристик элемента конфигурации, контроля изменений этих характеристик, записи и отчетности о состоянии процесса внедрения изменений, а также проверки совместимости с заданными требованиями. [IEEE 610] управление проблемами (problem management): См. управление дефектами. управление продуктовыми рисками (Product RISk MAnagement): См. PRISMA. управление рисками (risk management): Систематическое использование процедур и практик с целью идентификации, анализа, определения приоритетов и контроля рисков. управление тестированием (test management): Планирование, оценка, мониторинг и контроль тестовых активностей, обычно выполняемые руководителем тестирования. управление тестированием на основе сеансов (session-based test management): Метод измерения и управления тестированием на основе сеансов, например, исследовательским тестированием. EITP F F F ATM ATA ATM F-AT 65 управление тестовыми данными (test data management): Процесс анализа требований к тестовым данным, разработки структуры тестовых данных, создание и поддержка тестовых данных. управленческое рецензирование (management review): Систематическая оценка процесса приобретения, поддержки, разработки, эксплуатации или сопровождения программного обеспечения, выполняемая руководством или от лица руководства, контролирующего ход работ, определяющего состояние планов и графиков, подтверждающего требования и их место в системе, или оценивающего эффективность управленческих подходов для достижения целей. [IEEE 610, IEEE 1028] уровень зрелости (maturity level): Степень совершенствования процессов через стандартный набор областей процесса, в которых все цели в наборе достигаемы. [TMMi] уровень отказа (failure rate): Отношение количества отказов данной категории к заданной единице измерения, т.е. Отказ в единицу времени, количество отказов в транзакциях, количество отказов к количеству запусков. [IEEE 610] уровень риска (risk level): Важность риска определяется по его характеристикам: влияние и вероятность. Уровень риска может быть использован для определения интерсивности тестирования. Уровень риска может быть выражен как качественно (например: высокий, средний, низкий), так и количественно. уровень тестирования (test level): Объединенная и совместно управляемая группа задач тестирования. Уровень тестирования связан с областями ответственности в проекте. Примерами уровней тестирования могут служить компонентное тестирование, интеграционное тестирование, системное тестирование и приёмочное тестирование. [TMap] уровень целостности программного продукта (software integrity level): Уровень, на котором программный продукт соответствует набору определенных на основе пожеланий заказчика программных и/или производных от программных характеристик (программная сложность, оценка рисков, уровень безопасности, уровень защищенности, желаемая производительность, надежность или стоимость, и т.д.), призванных отразить важность программного продукта для заказчика. уровневый план тестирования (level test plan): План тестирования, обычно относящийся к одному уровню тестирования. См. также план тестирования. ускользнувший дефект (escaped defect): Дефект, не обнаруженный на предыдущем уровне тестирования, которое должно было выявить подобный тип дефектов. См. также процент выявления дефектов (Defect Detection Percentage (DDP)) условие (condition): Логическое выражение, которое может принимать значения Истина или Ложь, например A>B. См. также тестирование условий. условие ветви (branch condition): См. условие. усовершенствование процессов (process improvement): Программа действий, нацеленная на улучшение производительности и зрелости организационных процессов, и результат такой программы. [CMMI] F ATM ATM EITP ATM ATA ATT F ATM EITP 66 устанавливаемость (installability): Способность программного обеспечения быть установленным в определенном окружении. [ISO 9126]. См. также переносимость. установочное тестирование (installability testing): Процесс тестирования устанавливаемости программного продукта. См. также тестирование переносимости. устойчивость (robustness): Уровень, до которого компонент или система может функционировать корректно при наличии некорректных входных данных или функционирования в стрессовых условиях. [IEEE 610] См. также устойчивость к ошибкам, устойчивость к недочетам. устойчивость к ошибкам (error tolerance): Способность системы или компонента продолжать нормально функционировать, несмотря на присутствие неправильных входных данных. [IEEE 610] устойчивость к недочетам (fault tolerance): Способность программного продукта поддерживать определённый уровень производительности в случае программных недочетов (дефектов) или нарушении установленного интерфейса взаимодействия. [ISO 9126] См. также надежность, устойчивость. утечка памяти (memory leak): Отказ доступа к памяти, вызванный дефектом в программной логике выделения динамической памяти, являющийся причиной невозможности освободить выделенную память после того, как программа закончила ее использовать, и в конечном счете приводящий к отказу программы и/или иных параллельных процессов из-за недостатка памяти. учет статусов (status accounting): Составная часть управления конфигурациями, заключающаяся в сохранении и предоставлении отчетов по информации, необходимой для эффективного управления конфигурациями. Эта информация включает в себя перечень утвержденных идентификаторов конфигурации, статусы предложенных изменений конфигурации, и статусы реализации утвержденных изменений. [IEEE 610] Ф фаза выполнения тестов (test execution phase): Период в цикле разработки программного обеспечения, во время которого программный продукт или его компоненты запускаются, и программный продукт оценивается с точки зрения выполнения предъявленных к нему требований. [IEEE 610] фаза тестирования (test phase): Определенный набор задач, объединенных в контролируемую фазу проекта, например, выполняемые активности уровня тестирования. [Gerrard] фазовая локализация (phase containment): Процент дефектов, которые были исправлены в той же фазе разработки программного обеспечения, в которой они были найдены. фактический исход (actual outcome): См. фактический результат. фактический результат (actual result): Наблюдаемое или генерируемое поведение компонента или системы во время тестирования. ATT ATT T ATA ATM ATT 67 формальное рецензирование (formal review): Рецензирование, характеризирующиеся задокументированными процедурами и требованиями, например, инспекция. функциональная интеграция (functional integration): Подход к интеграции, который объединяет компоненты или системы для получения как можно раньше начальной рабочей функциональности. См. также интеграционное тестирование. функциональное тестирование (functional testing): Тестирование, основанное на анализе спецификации функциональности компонента или системы. См. также тестирование методом черного ящика. функциональное требование (functional requirement): Требование, определяющее функцию, которую компонент или система должны выполнять. [IEEE 610] функциональность (functionality): Способность программного продукта обеспечивать функции, которые соответствуют установленным и предполагаемым потребностям, при использованни ПО в определенных условиях. [ISO 9126] функциональный разрез (operational profile): Представление особого множества задач, выполняемых компонентом или системой, возможно опирающихся на поведение пользователя при взаимодействии с компонентом или системой, с указанием вероятности их появления. Описываемые задачи чаще логические, нежели физические, и могут выполняться на разных машинах в независимые периоды времени. Х хаотическое тестирование (monkey testing): Тестирование случайным выбором из большого диапазона входов, случайным нажатием кнопок, без соотнесения с тем, как в реальности будет использоваться система. характеристики качества программного обеспечения (software quality characteristic): См. атрибуты качества. характеристики программного обеспечения (software product characteristic): См. атрибуты качества. Ц ЦВМ (GQM): См. Цель-Вопрос-Метрика. целостность (consistency): Уровень однородности, стандартизированности и отсутствия противоречивости в документах или частях компонента или системы. [IEEE 610] цель тестирования (test target): Набор критериев выхода. Цель-Вопрос-Метрика (Goal Question Metric): Подход к измерению программного обеспечения с использованием трехуровневой модели: F F F EITP EITP ETM ATT |