software testing terms complete glossary
За да избегна неяснотите в различните условия за тестване на софтуера, прилагам a речник на софтуерното тестване тук.
Всички условия за тестване на софтуера са включени в този речник. Ако смятате, че знаете определението на който и да е термин по-добре от споменатото тук, можете да го използвате Форма за контакти за да ми изпратите определенията. При преглед ще ги включа в този списък с речници.
За да знаете основните дефиниции на софтуерното тестване и осигуряване на качеството, това е най-добрият речник, съставен от Ерик ван Венендаал . Също така за всяка дефиниция има препратка към IEEE или ISO, споменати в скоби.
ДА СЕ
критерии за приемане: Критериите за изход, на които компонентът или системата трябва да отговарят, за да бъдатприети от потребител, клиент или друго упълномощено лице. (IEEE 610)
тестове за приемане: Официално тестване по отношение на нуждите, изискванията и бизнес процесите на потребителя, проведено, за да се определи дали дадена система отговаря или не на критериите за приемане и да даде възможност на потребителя, клиентите или друго упълномощено лице да определят дали да приемат системата или не. (След IEEE 610)
тестване на достъпността: Тестване за определяне на лекотата, с която потребителите с увреждания могат да използват компонент или система. (Джерард)
точност: Способността на софтуерния продукт да предоставя правилните или договорени резултати или ефекти с необходимата степен на точност. (ISO 9126) Вижте също тестване на функционалността.
действителен резултат: Поведението, създадено / наблюдавано, когато се тества компонент или система.
ad hoc тестване: Тестването се извършва неофициално; не се провежда официална подготовка на теста, не се използва призната техника за проектиране на теста, няма очаквания за резултати и произволността ръководи дейността по изпълнение на теста.
адаптивност: Възможността на софтуерния продукт да бъде адаптиран за различни определени среди, без да се прилагат действия или средства, различни от предвидените за тази цел за разглеждания софтуер. (ISO 9126) Вижте също тестване на преносимост.
пъргаво тестване: Тестова практика за проект, използващ гъвкави методологии, като екстремно програмиране (XP), третиране на разработката като клиент на тестване и подчертаване на първоначалната парадигма на дизайна.
алфа тестване: Симулирано или действително оперативно тестване от потенциални потребители / клиенти или независим тестов екип на сайта на разработчиците, но извън организацията за разработка. Алфа тестването често се използва като форма на вътрешно тестване за приемане.
анализируемост: Възможността на софтуерния продукт да бъде диагностициран за недостатъци или причини за неизправности в софтуера или за идентифициране на частите, които трябва да бъдат модифицирани. (ISO 9126) Вижте също тестването за поддръжка.
аномалия: Всяко условие, което се отклонява от очакванията въз основа на спецификации на изискванията, проектни документи, потребителски документи, стандарти и т.н. или от нечие възприятие или опит. Аномалии могат да бъдат открити по време на преглед, тестване, анализ, компилиране или използване на софтуерни продукти или приложима документация, но не само. (IEEE 1044) Вижте също дефект, отклонение, грешка, грешка, повреда, инцидент, проблем.
привлекателност: Способността на софтуерния продукт да бъде привлекателна за потребителя. (ISO 9126)
одит: Независима оценка на софтуерни продукти или процеси за установяване на съответствие със стандарти, насоки, спецификации и / или процедури, базирани на обективни критерии, включително документи, които уточняват:
(1) формата или съдържанието на продуктите, които ще се произвеждат
(2) процесът, по който се произвеждат продуктите
(3) как се измерва съответствието със стандартите или насоките. (IEEE 1028)
одитна пътека: Път, по който първоначалният вход към даден процес (напр. Данни) може да бъде проследен обратно през процеса, като изходът на процеса се приема като отправна точка. Това улеснява анализа на дефектите и позволява извършването на одит на процеса. (След TMap)
автоматизиран тестов софтуер: Тестови софтуер, използван при автоматизирано тестване, като скриптове на инструменти.
наличност: Степента, в която компонентът или системата са експлоатационни и достъпни, когато са необходими за употреба. Често се изразява като процент. (IEEE 610)
Б.
тестване обратно към гръб: Тестване, при което два или повече варианта на компонент или система се изпълняват с едни и същи входове, изходите се сравняват и анализират в случаи на несъответствия. (IEEE 610)
изходно ниво: Спецификация или софтуерен продукт, който е официално прегледан или договорен, който след това служи като основа за по-нататъшно развитие и който може да бъде променен само чрез официален процес за контрол на промените. (След IEEE 610)
основен блок: Поредица от един или повече последователни изпълними изрази, които не съдържат клонове.
набор от основни тестове: Набор от тестови случаи, получени от вътрешната структура или спецификация, за да се гарантира, че е постигнат 100% от определен критерий за покритие.
поведение: Отговорът на компонент или система на набор от входни стойности и предпоставки.
бенчмарк тест: (1) Стандарт, спрямо който могат да се правят измервания или сравнения. (2) Тест, който се използва за сравняване на компоненти или системи помежду си или със стандарт, както е в (1). (След IEEE 610)
софтуер по поръчка: Софтуер, разработен специално за набор от потребители или клиенти. Обратното е готовият софтуер.
най-добри практики: Превъзходен метод или иновативна практика, която допринася за подобрените резултати на дадена организация в даден контекст, обикновено призната за „най-добра“ от други партньорски организации.
бета тестване: Оперативно тестване от потенциални и / или съществуващи потребители / клиенти на външен сайт, който не е ангажиран по друг начин с разработчиците, за да се определи дали даден компонент или система отговаря на нуждите на потребителя / клиента и дали се вписва в бизнес процесите. Бета тестването често се използва като форма на външно тестване за приемане, за да се получи обратна връзка от пазара.
тестване с голям взрив: Тип интеграционно тестване, при което софтуерните елементи, хардуерните елементи или и двата се комбинират наведнъж в компонент или цялостна система, а не на етапи. (След IEEE 610) Вижте също тестване на интеграция.
тестване на черна кутия: Тестване, функционално или нефункционално, без позоваване на вътрешната структура на компонента или системата.
техники за проектиране на тестове за черна кутия: Документирана процедура за извличане и подбор на тестови случаи въз основа на анализ на спецификацията, функционална или нефункционална, на компонент или система без препратка към нейната вътрешна структура.
блокиран тестов случай: Тестово дело, което не може да бъде изпълнено, тъй като не са изпълнени предпоставките за неговото изпълнение.
тестване отдолу нагоре: Постепенен подход към тестовете за интеграция, при които първо се тестват компонентите от най-ниско ниво и след това се използват за улесняване на тестването на компоненти от по-високо ниво. Този процес се повтаря, докато компонентът в горната част на йерархията не бъде тестван. Вижте също тестване за интеграция.
гранична стойност: Входна стойност или изходна стойност, която е на ръба на дял на еквивалентност или на най-малкото нарастващо разстояние от двете страни на ръба, например минималната или максималната стойност на диапазон.
анализ на гранична стойност: Техника за проектиране на тестове за черна кутия, при която тестовите случаи се проектират въз основа на гранични стойности.
покритие на гранична стойност: Процентът на граничните стойности, които са били упражнени от набор от тестове.
клон: Основен блок, който може да бъде избран за изпълнение въз основа на програмна конструкция, в която е наличен един от два или повече алтернативни програмни пътя, напр. случай, скок, отидете на, ifthen- друго.
покритие на клона: Процентът клонове, които са били упражнени от тестов пакет. 100% покритие на клонове предполага както 100% покритие на решенията, така и 100% покритие на извлеченията.
тестване на клонове: Техника за тестване на бяла кутия, при която тестовите случаи са предназначени за изпълнение на клонове.
тестване на бизнес процес: Подход за тестване, при който тестовите случаи са проектирани въз основа на описания и / или познания за бизнес процеси.
° С
Модел на зрелост на възможностите (CMM): Поетапна рамка от пет нива, която описва ключовите елементи на ефективен софтуерен процес. Моделът за зрялост на капацитета обхваща практики за планиране, инженеринг и управление на разработка и поддръжка на софтуер. (CMM)
Интеграция на модел на зрялост на способността (CMMI): Рамка, която описва ключовите елементи на ефективен процес на разработване и поддръжка на продукта. Интеграцията на модела за зрялост на капацитета обхваща практики за планиране, проектиране и управление на разработването и поддръжката на продукта. CMMI е определен наследник на CMM. (CMMI)
инструмент за заснемане / възпроизвеждане: Тип инструмент за изпълнение на теста, при който входните данни се записват по време на ръчно тестване, за да се генерират автоматизирани тестови скриптове, които могат да бъдат изпълнени по-късно (т.е. преиграни). Тези инструменти често се използват за поддържане на автоматизирано тестване на регресия.
СЛУЧАЙ: Съкращение от Computer Aided Software Engineering.
АКЦИОНЕРИ: Съкращение за компютърно подпомагано тестване на софтуер. Вижте също автоматизация на тестовете.
графика причина-следствие: Графично представяне на входове и / или стимули (причини) със свързаните с тях изходи (ефекти), които могат да се използват за проектиране на тестови случаи.
графика причинно-следствена връзка: Техника за проектиране на тестове за черна кутия, при която тестовите случаи са проектирани от графики за причинно-следствени ефекти (BS 7925/2)
сертифициране: Процесът на потвърждаване, че компонент, система или лице отговаря на посочените му изисквания, напр. чрез полагане на изпит.
променливост: Способността на софтуерния продукт да позволява прилагането на определени модификации. (ISO 9126) Вижте също поддръжката.
метод на класификационно дърво: Техника за проектиране на тестове за черна кутия, при която тестовите случаи, описани с помощта на класификационно дърво, са предназначени да изпълняват комбинации от представители на входни и / или изходни домейни. (Грохтман)
покритие на кода: Метод за анализ, който определя кои части от софтуера са изпълнени (обхванати) от тестовия пакет и кои части не са изпълнени, напр. покритие на изявление, покритие на решение или условие.
съжителство: Способността на софтуерния продукт да съществува съвместно с друг независим софтуер в обща среда, споделяща общи ресурси. (ISO 9126) Вижте тестване на преносимост.
сложност: Степента, до която даден компонент или система има дизайн и / или вътрешна структура, която е трудна за разбиране, поддържане и проверка. Вижте също цикломатична сложност.
съответствие: Способността на софтуерния продукт да се придържа към стандарти, конвенции или разпоредби в законите и подобни предписания. (ISO 9126)
тестване за съответствие : Процесът на тестване за определяне на съответствието на компонент или система.
съставна част: Минимален софтуерен елемент, който може да бъде тестван изолирано.
тестване на интеграция на компоненти: Извършено тестване за разкриване на дефекти в интерфейсите и взаимодействие между интегрирани компоненти.
спецификация на компонента: Описание на функцията на компонента от гледна точка на изходните му стойности за определени входни стойности при определени условия и изискваното нефункционално поведение (напр. Използване на ресурсите).
тестване на компоненти: Тестване на отделни софтуерни компоненти. (След IEEE 610)
Съставно състояние: Две или повече единични условия, обединени с помощта на логически оператор (И, ИЛИ или XOR), напр. ‘A> B И C> 1000’.
тестване на паралелността: Тестване, за да се определи как възникването на две или повече дейности в един и същ интервал от време, постигнато или чрез преплитане на дейностите, или чрез едновременно изпълнение, се обработва от компонента или системата. (След IEEE 610)
състояние: Логически израз, който може да бъде оценен като True или False, напр. A> B. Вижте също състояние на теста.
покритие на състоянието: Процентът на резултатите от състоянието, които са били упражнени от набор от тестове. 100% покритие на условията изисква всяко едно условие във всяко изявление за решение да бъде тествано като True и False.
покритие за определяне на състоянието: Процентът на всички резултати от единично състояние, които независимо влияят върху резултата от решението, упражнен от набор от тестови случаи. 100% покритие за определяне на условие предполага 100% покритие на условията за вземане на решение.
тестване за определяне на състоянието: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени да изпълняват единични резултати, които независимо засягат резултата от решението.
тестване на състоянието: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени да изпълняват резултатите от състоянието.
изход от състоянието: Оценката на дадено състояние на True или False.
конфигурация: Съставът на компонент или система, дефиниран от броя, естеството и взаимовръзките на съставните му части.
одит на конфигурацията: Функцията за проверка на съдържанието на библиотеките на конфигурационни елементи, напр. за спазване на стандартите. (IEEE 610)
контрол на конфигурацията: Елемент на управлението на конфигурацията, състоящ се от оценка, координация, одобрение или неодобрение и внедряване на промени в конфигурационни елементи след официално установяване на тяхната идентификация на конфигурацията. (IEEE
610)
идентификация на конфигурацията: Елемент на управлението на конфигурацията, състоящ се от подбор на елементите на конфигурацията за дадена система и записване на техните функционални и физически характеристики в техническата документация. (IEEE 610)
конфигурационен елемент: Съвкупност от хардуер, софтуер или и двете, който е предназначен за управление на конфигурацията и се третира като един обект в процеса на управление на конфигурацията. (IEEE 610)
управление на конфигурацията: Дисциплина, прилагаща техническо и административно ръководство и наблюдение, за да: идентифицира и документира функционалните и физическите характеристики на даден елемент от конфигурацията, контролира промените в тези характеристики, записва и отчита състоянието на обработката и отчитането на промените и проверява съответствието с определени изисквания. (IEEE 610)
последователност: Степента на еднородност, стандартизация и свобода от противоречия между документите или частите на компонент или система. (IEEE 610)
контролен поток: Абстрактно представяне на всички възможни последователности от събития (пътеки) в изпълнението чрез компонент или система.
тестване на преобразуване: Тестване на софтуер, използван за преобразуване на данни от съществуващи системи за използване в заместващи системи.
ЛЮБИЦИ: Съкращение за търговски софтуер извън магазина.
покритие: Степента, изразена като процент, до която определена позиция на покритие е била упражнена от тестов пакет.
анализ на покритието: Измерване на постигнатото покритие към определен елемент на покритие по време на изпълнението на теста, като се позовава на предварително определени критерии, за да се определи дали е необходимо допълнително тестване и ако да, кои тестови случаи са необходими.
елемент на покритие: Обект или свойство, използвани като основа за тестово покритие, напр. еквивалентни дялове или кодови изявления.
инструмент за покритие: Инструмент, който предоставя обективни мерки за това какви структурни елементи, напр. изявления, клонове са упражнени от тестовия пакет.
цикломатична сложност: Броят на независимите пътеки през програма. Цикломатичната сложност се определя като: L - N + 2P, където -L = броят на ръбовете / връзките в графика -N = броят на възлите в графика - P = броят на несвързаните части на графиката (напр. Извикваща графика и подпрограма). (След Маккейб)
д
дефиниция на данни: Изпълним оператор, където на променлива се присвоява стойност.
тестване на данни: Техника за скриптове, която съхранява входните данни за теста и очакваните резултати в таблица или електронна таблица, така че един контролен скрипт може да изпълни всички тестове в таблицата. Тестването, управлявано от данни, често се използва в подкрепа на прилагането на инструменти за изпълнение на тестове като инструменти за улавяне / възпроизвеждане. (Fewster и Graham) Вижте също тестването, управлявано от ключови думи.
поток от данни: Абстрактно представяне на последователността и възможни промени в състоянието на обектите на данни, където състоянието на обекта е всяко от:създаване, използване или унищожаване. (Beizer)
анализ на потока от данни: Форма на статичен анализ, базиран на дефиницията и използването на променливи.
покритие на потока от данни: Процентът на двойките дефиниция-употреба, които са били упражнени от набор от тестови случаи.
тест за поток на данни: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени да изпълняват дефиниция и да използват двойки променливи.
отстраняване на грешки: Процесът на намиране, анализ и отстраняване на причините за грешки в софтуера.
инструмент за отстраняване на грешки: Инструмент, използван от програмистите за възпроизвеждане на грешки, изследване на състоянието на програмите и намиране на съответния дефект. Дебъгърите дават възможност на програмистите да изпълняват програми стъпка по стъпка, да спират дадена програма във всеки програмен оператор и да задават и изследват програмни променливи.
решение: Програмна точка, в която управляващият поток има два или повече алтернативни маршрута. Възел с две или повече връзки към отделни клонове.
покритие на условието за решение: Процентът на всички резултати от състоянието и резултатите от решенията, които са били упражнени от тестов пакет. 100% покритие на условията за решение предполага както 100% покритие на условията, така и 100% покритие на решението.
тестване на условие за решение: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени да изпълняват резултатите от състоянието и резултатите от решенията.
покритие на решението: Процентът на резултатите от решенията, които са били упражнени от набор от тестове. 100% покритие на решения предполага както 100% покритие на клонове, така и 100% покритие на извлеченията.
таблица за решения: Таблица, показваща комбинации от входове и / или стимули (причини) със свързаните с тях изходи и / или действия (ефекти), които могат да се използват за проектиране на тестови случаи.
тестване на таблица за решения: Техники за проектиране на тестове за черна кутия, при които тестовите случаи са предназначени да изпълняват комбинациите от входове и / или стимули (причини), показани в таблица за решения. (Veenendaal)
тестване на решения: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени да изпълняват резултатите от решенията.
резултат от решението: Резултатът от решение (което следователно определя клоновете, които трябва да бъдат взети).
дефект: Недостатък в компонент или система, който може да доведе до това компонентът или системата да не успеят да изпълнят необходимата си функция, напр. неправилно изявление или дефиниция на данни. Дефект, ако се срещне по време на изпълнение, може да причини повреда на компонента или системата.
дефект плътност: Броят на дефектите, идентифицирани в компонент или система, разделен на размера на компонента или системата (изразен в стандартни термини за измерване, напр. Редови кодове, брой класове или функционални точки).
Процент на откриване на дефекти (DDP): броят на дефектите, открити от тестова фаза, разделен на броя, открит от тази фаза на изпитване и всякакви други средства след това.
доклад за дефект: Документ, докладващ за всеки недостатък в компонент или система, който може да причини неизправност на компонента или системата да изпълни необходимата си функция. (След IEEE 829)
управление на дефекти: Процесът на разпознаване, разследване, предприемане на действия и унищожаване на дефекти. Той включва регистриране на дефекти, класифицирането им и идентифициране на въздействието. (След IEEE 1044)
маскиране на дефекти: Събитие, при което един дефект предотвратява откриването на друг. (След IEEE 610)
двойка определение-употреба: Асоциацията на дефиницията на променлива с използването на тази променлива. Променливите употреби включват изчисляване (напр. Умножение) или за насочване на изпълнението на път (използване на „предикат“).
доставка: Всеки (работен) продукт, който трябва да бъде доставен на някой друг, който е авторът на (работния) продукт.
тестване въз основа на дизайн: Подход за тестване, при който тестовите случаи са проектирани въз основа на архитектурата и / или подробен дизайн на компонент или система (например тестове на интерфейси между компоненти или системи).
проверка на бюрото: Тестване на софтуер или спецификация чрез ръчна симулация на неговото изпълнение.
тестване за разработка: Официално или неформално тестване, проведено по време на внедряването на компонент или система, обикновено в среда за разработка от разработчици. (След IEEE 610)
тестване на документация: Тестване на качеството на документацията, напр. ръководство за потребителя или ръководство за инсталиране.
домейн: Комплектът, от който могат да бъдат избрани валидни входни и / или изходни стойности.
водач: Софтуерен компонент или тестов инструмент, който замества компонент, който се грижи за управлението и / или извикването на компонент или система. (След TMap)
динамичен анализ: Процесът на оценка на поведението, напр. производителност на паметта, използване на процесора на система или компонент по време на изпълнение. (След IEEE 610)
динамично сравнение: Сравнение на действителни и очаквани резултати, извършени по време на изпълнението на софтуера, например чрез инструмент за тестово изпълнение.
динамично тестване: Тестване, което включва изпълнението на софтуера на компонент или система.
Е
ефективност: Способността на софтуерния продукт да осигури подходяща производителност спрямо количеството ресурси, използвани при посочените условия. (ISO 9126)
тестване на ефективността: Процесът на тестване за определяне на ефективността на софтуерен продукт.
елементарно сравнително тестване: Техники за проектиране на тестове за черна кутия, при които тестовите случаи са предназначени да изпълняват комбинации от входове, използвайки концепцията за покритие за определяне на условие. (TMap)
съперник: Устройство, компютърна програма или система, която приема същите входове и произвежда същите изходи като дадена система. (IEEE 610) Вижте също симулатора.
критерии за влизане: набор от общи и специфични условия за разрешаване на процеса да върви напред с определена задача, напр. тестова фаза. Целта на критериите за влизане е да се предотврати стартирането на задача, която би довела до повече (пропилени) усилия в сравнение с усилията, необходими за премахване на неуспешните критерии за влизане. (Гилб и Греъм)
входна точка: Първият изпълним израз в рамките на компонент.
как да намеря ключ за мрежова сигурност на рутера
дял за еквивалентност: Част от входен или изходен домейн, за която се приема, че поведението на компонент или система е същото, въз основа на спецификацията.
покритие на еквивалентен дял: Процентът на дяловете за еквивалентност, които са били упражнени от тестов пакет.
разделяне на еквивалентност: Техника за проектиране на тестове за черна кутия, при която тестовите случаи са предназначени да изпълняват представители от дялове на еквивалентност. По принцип тестовите случаи са проектирани да покриват всеки дял поне веднъж.
грешка: Човешко действие, което води до неправилен резултат. (След IEEE 610)
познаване на грешка: Техника за проектиране на тестове, при която опитът на тестера се използва, за да се предвидят какви дефекти могат да присъстват в тествания компонент или система в резултат на допуснати грешки и да се проектират тестове, за да се изложат по-специално.
грешка при засяване: Процесът на умишлено добавяне на известни дефекти към тези, които вече са в компонента или системата с цел наблюдение на скоростта на откриване и отстраняване, и оценка на броя на останалите дефекти. (IEEE 610)
толеранс на грешки: Способността на система или компонент да продължи нормалната работа въпреки наличието на грешни входове. (След IEEE 610).
обработка на изключения: Поведение на компонент или система в отговор на погрешно въвеждане или от човешки потребител, или от друг компонент или система, или на вътрешна повреда.
изпълним оператор: Изявление, което, когато се компилира, се превежда в обектен код и което ще бъде изпълнено процедурно, когато програмата се изпълнява и може да извърши действие върху данни.
упражнява: Казва се, че програмен елемент се упражнява от тестов случай, когато входната стойност причинява изпълнението на този елемент, като например изявление, решение или друг структурен елемент.
изчерпателно тестване: Тестов подход, при който тестовият пакет включва всички комбинации от входни стойности и предпоставки.
критерии за изход: Наборът от общи и специфични условия, съгласувани със заинтересованите страни, за разрешаване на даден процес да бъде официално завършен. Целта на критериите за излизане е да се предотврати дадена задача да се счита за изпълнена, когато все още има неизпълнени части от задачата, които не са завършени. Критериите за изход се използват чрез тестване, за да се докладва и да се планира кога да се спре тестването. (След Гилб и Греъм)
изходна точка: Последният изпълним израз в рамките на компонент.
очакван резултат: Поведението, предвидено от спецификацията или друг източник на компонента или системата при определени условия.
изследователско изпитване: Тестване, където тестерът активно контролира дизайна на тестовете, докато се извършват тези тестове, и използва информацията, получена по време на тестването, за да проектира нови и по-добри тестове. (Бах)
F
неуспех: Счита се, че тестът е неуспешен, ако действителният му резултат не съвпада с очаквания резултат.
неуспех: Действително отклонение на компонента или системата от очакваната доставка, услуга или резултат. (След Фентън)
режим на повреда: Физическата или функционална проява на неуспех. Например, система в режим на отказ може да се характеризира с бавна работа, неправилни изходи или пълно прекратяване на изпълнението.
Анализ на режима на отказ и анализ на ефекта (FMEA): Систематичен подход за идентифициране на риска и анализ на идентифициране на възможни начини на отказ и опит за предотвратяване на тяхното възникване.
процент на неуспех: Съотношението на броя на отказите на дадена категория към дадена мерна единица, напр. откази за единица време, откази за брой транзакции, откази за брой стартирани компютри. (IEEE 610)
толерантност към повреди: Способността на софтуерния продукт да поддържа определено ниво на производителност в случай на софтуерни дефекти (дефекти) или при нарушаване на посочения от него интерфейс. (ISO 9126) Вижте също надеждността.
анализ на дървото на грешки: Метод, използван за анализ на причините за неизправности (дефекти).
възможен път: Път, за който съществува набор от входни стойности и предпоставки, което води до неговото изпълнение.
особеност: Атрибут на компонент или система, посочен или подразбиращ се от документацията за изискванията (например надеждност, използваемост или ограничения за проектиране). (След IEEE 1008)
краен автомат: Изчислителен модел, състоящ се от краен брой състояния и преходи между тези състояния, вероятно с придружаващи действия. (IEEE 610)
официален преглед: Преглед, характеризиращ се с документирани процедури и изисквания, напр. проверка.
замразена основа за изпитване: Тестов документ, който може да бъде изменен само чрез официален процес на контрол на промените. Вижте също изходното ниво.
Анализ на функционална точка (FPA): Метод, целящ да измери размера на функционалността на информационна система. Измерването е независимо от технологията. Това измерване може да се използва като основа за измерване на производителността, оценка на необходимите ресурси и контрол на проекта.
функционална интеграция: Интеграционен подход, който комбинира компонентите или системите с цел получаване на основна функционалност, работеща рано. Вижте също тестване за интеграция.
функционално изискване: Изискване, което определя функция, която компонентът или системата трябва да изпълняват. (IEEE 610)
техника за проектиране на функционален тест: Документирана процедура за извличане и избор на тестови случаи въз основа на анализ на спецификацията на функционалността на компонент или система без препратка към вътрешната му структура. Вижте също техника за проектиране на тестове за черна кутия.
функционално тестване: Тестване въз основа на анализ на спецификацията на функционалността на компонент или система. Вижте също тестване на черна кутия.
функционалност: Способността на софтуерния продукт да предоставя функции, които отговарят на заявените и подразбиращи се нужди, когато софтуерът се използва при определени условия. (ISO 9126)
тестване на функционалността: Процесът на тестване за определяне на функционалността на софтуерен продукт.
G
тестване на стъклена кутия: Вижте тестване на бяла кутия.
З.
евристична оценка: Техника за статично изпитване на използваемост за определяне на съответствието на потребителския интерфейс с признати принципи на използваемост (така наречената „евристика“).
тест от високо ниво: Тест без конкретни (ниво на изпълнение) стойности за входни данни и очаквани резултати.
хоризонтална проследимост: Проследяване на изискванията за ниво на изпитване през слоевете на документацията за изпитване (напр. План за изпитване, спецификация на тестовия проект, спецификация на тестовия случай и спецификация на процедурата за изпитване).
Аз
анализ на въздействието: Оценката на промяната в слоевете на документацията за разработка, тестовата документация и компонентите, за да се приложи дадена промяна на определени изисквания.
модел на постепенно развитие: Жизнен цикъл на разработка, при който проектът е разделен на поредица от стъпки, всеки от които предоставя част от функционалността в общите изисквания на проекта. Изискванията се приоритизират и доставят в приоритетен ред със съответното нарастване. В някои (но не във всички) версии на този модел на жизнения цикъл всеки подпроект следва „мини V-модел“ със собствен фази на проектиране, кодиране и тестване.
допълнително тестване: Тестване, когато компонентите или системите са интегрирани и тествани един или няколко наведнъж, докато всички компоненти или системи бъдат интегрирани и тествани.
инцидент: Всяко събитие, възникнало по време на тестване, което изисква разследване. (След IEEE 1008)
управление на инциденти: Процесът на разпознаване, разследване, предприемане на действия и унищожаване на инциденти. Той включва регистриране на инциденти, класифицирането им и идентифициране на въздействието. (След IEEE 1044)
инструмент за управление на инциденти: Инструмент, който улеснява записването и проследяването на състоянието на инциденти, открити по време на тестване. Те често имат съоръжения, ориентирани към работния поток, за да проследяват и контролират разпределението, коригирането и повторното тестване на инциденти и да предоставят съоръжения за докладване.
доклад за инцидент: Документ, докладващ за всяко събитие, настъпило по време на тестването, което изисква разследване. (След IEEE 829)
независимост: Разделяне на отговорностите, което насърчава извършването на обективно тестване. (След DO-178b)
невъзможен път: Път, който не може да се упражни от който и да е набор от възможни входни стойности.
неформален преглед: Преглед, който не се основава на официална (документирана) процедура.
вход: Променлива (независимо дали се съхранява в компонент или отвън), която се чете от компонент.
входен домейн: Наборът, от който могат да бъдат избрани валидни входни стойности .. Вижте също домейн.
входна стойност: Екземпляр на вход. Вижте също въвеждане.
проверка: Тип преглед, който разчита на визуален преглед на документи за откриване на дефекти, напр. нарушения на стандартите за разработка и несъответствие с документацията от по-високо ниво. Най-официалната техника за преглед и следователно винаги се основава на документирана процедура. (След IEEE 610, IEEE 1028)
инсталируемост: Възможността на софтуерния продукт да бъде инсталиран в определена среда (ISO 9126). Вижте също преносимост.
тестване на инсталируемост: Процесът на тестване на инсталируемостта на софтуерен продукт. Вижте също тестване на преносимост.
ръководство за инсталиране: Приложени инструкции за всеки подходящ носител, който води инсталатора през инсталационния процес. Това може да е ръководство, стъпка по стъпка, съветник за инсталиране или друго подобно описание на процеса.
съветник за инсталиране: Приложен софтуер на всеки подходящ носител, който води инсталатора през инсталационния процес. Той обикновено изпълнява инсталационния процес, предоставя обратна връзка за резултатите от инсталирането и подканва за опции.
инструментариум: Вмъкването на допълнителен код в програмата с цел събиране на информация за поведението на програмата по време на изпълнение.
инструменти: Софтуерен инструмент, използван за извършване на инструментариум.
тест за прием: Специален случай на тест за дим, за да се реши дали компонентът или системата са готови за подробни и допълнителни тестове. Тест за прием обикновено се провежда в началото на фазата на изпълнение на теста.
интеграция: Процесът на комбиниране на компоненти или системи в по-големи възли.
интеграционно тестване: Тестване, извършено за разкриване на дефекти в интерфейсите и във взаимодействията между интегрирани компоненти или системи. Вижте също тестване за интегриране на компоненти, тестване за системна интеграция.
тестване на интерфейса: Тип интеграционен тест, който се занимава с тестване на интерфейсите между компоненти или системи.
оперативна съвместимост: Способността на софтуерния продукт да взаимодейства с един или повече определени компоненти или системи. (След ISO 9126) Вижте също функционалността.
тестване на оперативната съвместимост: Процесът на тестване за определяне на оперативната съвместимост на софтуерен продукт. Вижте също тестване на функционалността.
невалидно тестване: Тестване с използване на входни стойности, които трябва да бъдат отхвърлени от компонента или системата. Вижте също толерантност към грешки.
тестване на изолацията: Тестване на отделни компоненти в изолация от околните компоненти, като околните компоненти се симулират от заглушители и драйвери, ако е необходимо.
ДА СЕ
тестване с ключови думи: Техника за скриптове, която използва файлове с данни, за да съдържа не само тестови данни и очаквани резултати, но и ключови думи, свързани с тестваното приложение. Ключовите думи се интерпретират чрез специални поддържащи скриптове, които се извикват от контролния скрипт за теста. Вижте също тестване на данни.
L
LCSAJ: Линейна кодова последователност и прескачане, състояща се от следните три елемента (конвенционално идентифицирани с номера на редове в списък с изходен код): началото на линейната последователност на изпълними инструкции, края на линейната последователност и целевата линия, към която се контролира поток се прехвърля в края на линейната последователност.
LCSAJ покритие: Процентът на LCSAJs на компонент, които са били упражнени от тестов пакет. 100% покритие на LCSAJ предполага 100% покритие на решенията.
Тестване на LCSAJ: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени за изпълнение на LCSAJ.
ученост: Способността на софтуерния продукт да позволи на потребителя да научи приложението му. (ISO 9126) Вижте също използваемост.
тест за натоварване: Тип тест, занимаващ се с измерване на поведението на компонент или система с нарастващо натоварване, напр. брой паралелни потребители и / или брой транзакции, за да се определи какъв товар може да бъде обработен от компонента или системата.
тест от ниско ниво: Тестов случай с конкретни (ниво на изпълнение) стойности за входни данни и очаквани резултати.
М
поддръжка: Модификация на софтуерен продукт след доставка за коригиране на дефекти, за подобряване на производителността или други атрибути или за адаптиране на продукта към модифицирана среда. (IEEE 1219)
тестване за поддръжка: Тестване на промените в операционната система или въздействието на променена среда върху операционната система.
поддръжка: Лекотата, с която софтуерен продукт може да бъде модифициран, за да коригира дефекти, модифициран, за да отговори на новите изисквания, модифициран, за да улесни бъдещата поддръжка, или адаптиран към променена среда. (ISO 9126)
тестване на поддръжката: Процесът на тестване за определяне на поддръжката на софтуерен продукт.
преглед от ръководството: Систематична оценка на процеса на придобиване, доставка, разработване, експлоатация или поддръжка, извършена от или от името на ръководството, която следи напредъка, определя състоянието на плановете и графиците, потвърждава изискванията и разпределението на наследниците или оценява ефективността на подходите за управление за постигане на годност по предназначение. (След IEEE 610, IEEE 1028)
зрелост: (1) Способността на организацията по отношение на ефективността и ефикасността на нейните процеси и работни практики. Вижте също Модел на зрелост на способността, Тест на зрелост. (2) Способността на софтуерния продукт да избягва повреда в резултат на дефекти в софтуера. (ISO 9126) Вижте също надеждността.
мярка: Номерът или категорията, присвоени на атрибут на обект чрез извършване на измерване (ISO 14598).
измерване: Процесът на присвояване на номер или категория на обект за описване на атрибут на този обект. (ISO 14598)
скала за измерване: Скала, която ограничава типа анализ на данните, който може да се извърши върху нея. (ISO 14598)
изтичане на памет: Дефект в динамичната логика за разпределение на хранилището на програмата, който я кара да не успее да възстанови паметта, след като е приключила с използването й, в крайна сметка причинявайки неуспех на програмата поради липса на памет.
метрика: Скала за измерване и методът, използван за измерване. (ISO 14598)
крайъгълен камък: Точка във времето в проект, в която са определени (междинни) резултати ирезултатите трябва да са готови.
модератор: Лидерът и основното лице, отговорно за проверка или друг процес на преглед.
монитор: Софтуерен инструмент или хардуерно устройство, които работят едновременно с тествания компонент или система и контролира, записва и / или анализира поведението на компонента или системата. (След IEEE 610)
покритие с множество условия: Процентът на комбинациите от всички единични условиярезултати в рамките на едно изявление, които са били упражнени от тестов пакет. 100% кратнопокритие на условието предполага 100% покритие за определяне на състоянието.
тестване на множество състояния: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени да изпълняват комбинации от единични резултати (в рамките на едно твърдение).
анализ на мутация: Метод за определяне на задълбочеността на тестовия набор чрез измерване на степента, до която тестовият пакет може да различи програмата от леки варианти (мутанти) на програмата.
н
Покритие с N-превключвател: Процентът на последователности от N + 1 преходи, които са били упражнени от тестов пакет. (Чау)
Тестване на N-превключвател: Форма на тестване на състоянието на преход, при което тестовите случаи са предназначени да изпълняват всички валидни последователности на N + 1 преходи. (Chow) Вижте също тестване на състоянието на преход.
отрицателно тестване: Тестове, целящи да покажат, че компонент или система не работят. Отрицателното тестване е свързано с поведението на тестерите, а не със специфичен подход на теста или техника на проектиране на теста. (След Beizer).
несъответствие: Неизпълнение на определено изискване. (ISO 9000)
нефункционално изискване: Изискване, което не се отнася до функционалността, а до атрибути като надеждност, ефективност, използваемост, поддръжка и преносимост.
нефункционално тестване: Тестване на атрибутите на компонент или система, които не са свързани с функционалността, напр. надеждност, ефективност, използваемост, поддръжка и преносимост.
техники за проектиране на нефункционални тестове: Методи, използвани за проектиране или избор на тестове за нефункционално тестване.
ИЛИ
готов софтуер: Софтуерен продукт, който е разработен за общия пазар, т.е.за голям брой клиенти, и който се доставя на много клиенти в идентичен формат.
работоспособност: Способността на софтуерния продукт да позволява на потребителя да работи и да го контролира. (ISO 9126) Вижте също използваемост.
оперативна среда: Хардуер и софтуерни продукти, инсталирани на сайтове на потребители или клиенти, където ще се използва тестваният компонент или система. Софтуерът може да включва операционни системи, системи за управление на бази данни и други приложения.
тестване на оперативния профил: Статистическо тестване с помощта на модел на системни операции (задачи с кратка продължителност) и тяхната вероятност за типично използване. (Муса)
оперативно тестване: Тестване, проведено за оценка на компонент или система в нейната оперативна среда. (IEEE 610)
изход: Променлива (независимо дали се съхранява в компонент или извън), която се записва от компонент.
изходен домейн: Комплектът, от който могат да бъдат избрани валидни изходни стойности. Вижте също домейн.
изходна стойност: Екземпляр на изход. Вижте също изхода.
P
програмиране по двойки: Подход за разработване на софтуер, при който редове код (производство и / или тест) на компонент се пишат от двама програмисти, седнали на един компютър. Това по подразбиране означава, че се извършват текущи прегледи на кода в реално време.
тестване на двойки: Двама тестери работят заедно, за да открият дефекти. Обикновено те споделят един компютър и търгуват с него по време на тестване.
Пропуск: Счита се, че тестът е преминал, ако действителният му резултат съвпада с очаквания резултат.
критерии за преминаване / неуспех: Правила за вземане на решения, използвани за определяне дали даден тестов елемент (функция) или функция е преминал или не е преминал тест. (IEEE 829)
път: Последователност от събития, напр. изпълними инструкции на компонент или система от входна точка до изходна точка.
покритие на пътя: Процентът на пътеките, които са били упражнени от тестов пакет. 100% покритие на пътя предполага 100% покритие на LCSAJ.
сенсибилизиращ път: Избор на набор от входни стойности, които да принудят изпълнението на даден път.
тестване на пътя: Техника за тестване на бяла кутия, при която тестовите случаи са проектирани да изпълняват пътеки.
производителност: Степента, до която система или компонент изпълнява определените си функции в рамките на дадени ограничения по отношение на времето за обработка и скоростта на пропускане. (След IEEE 610) Вижте ефективността.
показател за изпълнение: Високо ниво на ефективност и / или ефективност, използвано за насочване и контрол на прогресивното развитие, напр. Процент на откриване на дефекти (DDP) за тестване. (CMMI)
тестване на производителността: Процесът на тестване за определяне на производителността на софтуерен продукт. Вижте тестване на ефективността.
инструмент за тестване на производителността: Инструмент за подпомагане на тестването на производителността, който обикновено има две основни средства: генериране на натоварване и измерване на транзакции. Генерирането на натоварване може да симулира или множество потребители, или големи обеми входни данни. По време на изпълнение се вземат измервания на времето за реакция от избрани транзакции и те се регистрират. Инструментите за тестване на производителността обикновено предоставят отчети въз основа на тестови дневници и графики на натоварване спрямо времето за реакция.
план за фаза на изпитване: План за изпитване, който обикновено се отнася до едно ниво на изпитване.
преносимост: Лекотата, с която софтуерният продукт може да бъде прехвърлен от един хардуер или софтуерна среда в друга. (ISO 9126)
тестване на преносимост: Процесът на тестване за определяне на преносимостта на софтуерен продукт.
следусловие: Условия на околната среда и състоянието, които трябва да бъдат изпълнени след изпълнението на тест или процедура за изпитване.
сравнение след изпълнение: Сравнение на действителните и очакваните резултати, извършено след като софтуерът приключи.
предпоставка: Условия на околната среда и състоянието, които трябва да бъдат изпълнени, преди компонентът или системата да могат да бъдат изпълнени с определен тест или процедура за изпитване.
Приоритет: Нивото на (бизнес) важност, присвоено на даден артикул, напр. дефект.
тест на цикъла на процеса: Техника за проектиране на тестове за черна кутия, при която тестовите случаи са предназначени да изпълняват бизнес процедури и процеси. (TMap)
процес: Набор от взаимосвързани дейности, които трансформират входовете в изходи. (ISO 12207)
проект: Проектът е уникален набор от координирани и контролирани дейности с датите на начало и край, предприети като цел, отговаряща на специфични изисквания, включително ограниченията във времето, разходите и ресурсите. (ISO 9000)
план за тестване на проекта: План за тестване, който обикновено се отнася до множество нива на теста.
псевдослучайно: Поредица, която изглежда случайна, но всъщност се генерира според някаква предварително подредена последователност.
Въпрос:
качество: Степента, до която компонент, система или процес отговаря на определени изисквания и / или нужди и очаквания на потребителя / клиента. (След IEEE 610)
осигуряване на качеството: Част от управлението на качеството, фокусирано върху осигуряването на увереност, че изискванията за качество ще бъдат изпълнени. (ISO 9000)
атрибут за качество: Елемент или характеристика, която влияе върху качеството на артикула. (IEEE 610)
управление на качеството: Координирани дейности за насочване и контрол на организация по отношение на качеството. Насочването и контролът по отношение на качеството обикновено включват установяване на политиката за качество и целите за качество, планиране на качеството, контрол на качеството, осигуряване на качеството и подобряване на качеството. (ISO 9000)
R
произволно тестване: Техника за проектиране на тестове за черна кутия, при които се избират тестови случаи, вероятно с помощта на алгоритъм за псевдослучайно генериране, за да съответства на оперативен профил. Тази техника може да се използва за тестване на нефункционални атрибути като надеждност и производителност.
възстановимост: Способността на софтуерния продукт да възстанови определено ниво на производителност и да възстанови данните, пряко засегнати в случай на повреда. (ISO 9126) Вижте също надеждността.
тестване за възстановяване: Процесът на тестване за определяне на възможността за възстановяване на софтуерен продукт. Вижте също тестване на надеждността.
регресионно тестване: Тестване на предварително тествана програма след модификация, за да се гарантира, че дефектите не са били въведени или открити в непроменени области на софтуера в резултат на направените промени. Извършва се при промяна на софтуера или неговата среда.
бележка освобождаване: Документ, идентифициращ тестови елементи, тяхната конфигурация, текущо състояние и друга информация за доставка, доставена от разработката на тестването и евентуално на други заинтересовани страни, в началото на фазата на изпълнение на теста. (След IEEE 829)
надеждност: Способността на софтуерния продукт да изпълнява необходимите си функции при посочени условия за определен период от време или за определен брой операции. (ISO 9126)
тестване на надеждността: Процесът на тестване за определяне на надеждността на софтуерен продукт.
заменяемост: Възможността на софтуерния продукт да се използва вместо друг определен софтуерен продукт за същата цел в същата среда. (ISO 9126) Вижте също преносимост.
изискване: Условие или способност, необходими на потребителя за решаване на проблем или постигане на цел, която трябва да бъде изпълнена или притежавана от система или системен компонент, за да се изпълни договор, стандарт, спецификация или друг официално наложен документ. (След IEEE 610)
тестване въз основа на изискванията: Подход за тестване, при който тестовите случаи са проектирани въз основа на тестови цели и условия на теста, получени от изискванията, напр. тестове, които упражняват специфични функции или изследват нефункционални атрибути като надеждност или използваемост.
инструмент за управление на изискванията: Инструмент, който поддържа запис на изисквания, атрибути на изискванията (напр. Приоритет, отговорност за знанията) и анотиране и улеснява проследяването чрез слоеве от изисквания и управление на промяната на изискванията. Някои инструменти за управление на изискванията предоставят и средства за статичен анализ, като проверка на последователността и нарушения на предварително дефинираните правила за изисквания.
фаза на изискванията: Периодът от време в жизнения цикъл на софтуера, през който се определят и документират условията за софтуерен продукт. (IEEE 610)
използване на ресурсите: Способността на софтуерния продукт да използва подходящи количества и видове ресурси, например количествата основна и вторична памет, използвани от програмата, и размерите на необходимите временни или препълнени файлове, когато софтуерът изпълнява функцията си при посочени условия. (След ISO 9126) Вижте също ефективността.
тестване на използването на ресурсите: Процесът на тестване за определяне на използването на ресурсите на софтуерен продукт.
резултат: Последицата / резултатът от изпълнението на тест. Той включва изходи към екрани, промени в данни, отчети и изпратени съобщения за комуникация. Вижте също действителен резултат, очакван резултат.
критерии за възобновяване: Тестовите дейности, които трябва да се повторят, когато изпитването се започне отново след спиране. (След IEEE 829)
повторно тестване: Тестване, което изпълнява тестови случаи, които са неуспешни при последното им стартиране, за да се провери успехът на коригиращите действия.
преглед: Оценка на състояние на продукт или проект, за да се установят несъответствия с планираните резултати и да се препоръчат подобрения. Примерите включват преглед на ръководството, неформален преглед, технически преглед, проверка и ръководство. (След IEEE 1028)
рецензент: Лицето, участващо в прегледа, което трябва да идентифицира и опише аномалии в продукта или проекта, който се преглежда. Рецензенти могат да бъдат избрани да представят различни гледни точки и роли в процеса на преглед.
риск: Фактор, който може да доведе до бъдещи негативни последици; обикновено се изразява като въздействие и вероятност.
анализ на риска: Процесът на оценка на идентифицираните рискове за оценка на тяхното въздействие и вероятност за възникване (вероятност).
тестване въз основа на риска: Тестване, ориентирано към проучване и предоставяне на информация за продуктовите рискове. (След Джерард)
контрол на риска: Процесът, чрез който се вземат решения и се прилагат защитни мерки за намаляване на рисковете или поддържане на рискове в рамките на определени нива.
идентифициране на риска: Процесът на идентифициране на рисковете с помощта на техники като мозъчна атака, контролни списъци и история на неуспехите.
управление на риска: Систематично прилагане на процедури и практики към задачите за идентифициране, анализ, определяне на приоритети и контрол на риска.
здравина: Степента, до която компонентът или системата могат да функционират правилно при наличие на невалидни входове или стресиращи условия на околната среда. (IEEE 610) Вижте също толерантност към грешки, толерантност към грешки.
основна причина: Основен фактор, който е причинил несъответствие и евентуално трябва да бъде елиминиран за постоянно чрез подобряване на процеса.
С
безопасност: Способността на софтуерния продукт да постига приемливи нива на риск от увреждане на хора, бизнес, софтуер, собственост или околна среда в определен контекст на употреба. (ISO 9126)
изпитване за безопасност: Процесът на тестване за определяне на безопасността на софтуерен продукт.
мащабируемост: Възможността на софтуерния продукт да бъде надграден, за да побере увеличени натоварвания. (След Джерард)
тестване на мащабируемост: Тестване за определяне на мащабируемостта на софтуерния продукт.
писар: Лицето, което трябва да запише всеки споменат дефект и всякакви предложения за подобрение по време на среща за преглед, във формуляр за регистрация. Писателят трябва да се увери, че регистрационният формуляр е четим и разбираем.
скриптов език: Език за програмиране, на който са написани изпълними скриптове за тест, използван от инструмент за изпълнение на тест (напр. Инструмент за улавяне / повторно възпроизвеждане).
сигурност: Атрибути на софтуерни продукти, които носят способността му да предотвратява неоторизиран достъп, независимо дали случаен или умишлен, до програми и данни. (ISO 9126)
тестване на сигурността: Тестване за определяне на сигурността на софтуерния продукт.
тежест: Степента на въздействие, което дефектът оказва върху развитието или работата на компонент или система. (След IEEE 610)
симулация: Представянето на избрани поведенчески характеристики на една физическа или абстрактна система от друга система. (ISO 2382/1)
симулатор: Устройство, компютърна програма или система, използвани по време на тестване, които се държат или работят като дадена система, когато са снабдени с набор от контролирани входове. (След IEEE 610, DO178b) Вижте също емулатора.
тест за дим: Подмножество от всички дефинирани / планирани тестови случаи, които обхващат основната функционалност на компонент или система, за да се установи, че най-важните функции на дадена програма работят, но не се занимава с по-фини подробности. Ежедневният тест за изграждане и пушене е сред най-добрите практики в индустрията. Вижте също тест за прием.
качество на софтуера: Цялостта на функционалността и характеристиките на софтуерен продукт, които се отнасят до способността му да задоволява заявени или подразбиращи се нужди. (След ISO 9126)
спецификация: Документ, който уточнява, в идеалния случай по пълен, точен и проверим начин, изискванията, дизайна, поведението или други характеристики на компонент или система и често процедурите за определяне дали тези разпоредби са изпълнени. (След IEEE 610)
Техника за проектиране на тестове, базирана на спецификация: Вижте техниката за тестване на черна кутия.
посочен вход: Вход, за който спецификацията предсказва резултат.
стабилност: Способността на софтуерния продукт да избягва неочаквани ефекти от модификации в софтуера. (ISO 9126) Вижте също поддръжката.
диаграма на състоянието: Диаграма, която изобразява състоянията, които даден компонент или система може да приеме, и показва събитията или обстоятелствата, които причиняват и / или са резултат от промяна от едно състояние в друго. (IEEE 610)
държавна таблица: Решетка, показваща получените преходи за всяко състояние, комбинирано с всяко възможно събитие, показваща както валидни, така и невалидни преходи.
държавен преход: Преход между две състояния на компонент или система.
как да напиша регресионни тестови случаи
тестване на държавен преход: Техника за проектиране на тестове за черна кутия, при която тестовите случаи са предназначени да изпълняват валидни и невалидни преходи на състоянието. Вижте също тестване на N-превключвател.
изявление: Обект в език за програмиране, който обикновено е най-малката неделима единица за изпълнение.
покритие на извлечението: Процентът изпълними инструкции, които са били упражнени от тестов пакет.
тестване на изявление: Техника за проектиране на бяла кутия, при която тестовите случаи са предназначени да изпълняват изявления.
статичен анализ: Анализ на софтуерни артефакти, напр. изисквания или код, извършени без изпълнение на тези софтуерни артефакти.
статичен анализатор: Инструмент, който извършва статичен анализ.
анализ на статичен код: Анализ на изходния код на програмата, извършен без изпълнение на този софтуер.
статичен анализатор на код: Инструмент, който извършва статичен анализ на кода. Инструментът проверява изходния код за определени свойства като съответствие със стандартите за кодиране, показатели за качество или аномалии на потока от данни.
статично тестване: Тестване на компонент или система на ниво спецификация или внедряване без изпълнение на този софтуер, напр. рецензии или статичен анализ на код.
статистическо тестване: Техника за проектиране на тестове, при която се използва модел на статистическо разпределение на входа за изграждане на представителни тестови случаи. Вижте също тестване на оперативния профил.
отчитане на състоянието: Елемент от управлението на конфигурацията, състоящ се от запис и докладване на информация, необходима за ефективно управление на конфигурацията. Тази информация включва списък на одобрената идентификация на конфигурацията, състоянието на предложените промени в конфигурацията и състоянието на изпълнение на одобрените промени. (IEEE 610)
Стрес тестване: Изпитване, проведено за оценка на система или компонент в или извън границите на посочените изисквания. (IEEE 610)
структурно покритие: Мерки за покритие въз основа на вътрешната структура на компонента.
техника на конструктивно изпитване: Вижте техниката за тестване на бяла кутия.
мъниче: Скелетно или специално предназначение на софтуерен компонент, използван за разработване или тестване на компонент, който извиква или зависи по друг начин от него. Той замества извикан компонент. (След IEEE 610)
подпът: Поредица от изпълними инструкции в даден компонент.
критерии за спиране: Критериите, използвани за (временно) спиране на всички или част от тестовите дейности върху тестовите елементи. (След IEEE 829)
годност: Способността на софтуерния продукт да предоставя подходящ набор от функции за определени задачи и цели на потребителя. (ISO 9126) Вижте също функционалността.
Инвентаризация за измерване на използваемостта на софтуера (SUMI): Техника за изпитване на използваемост, базирана на въпросник за оценка на използваемостта, напр. удовлетвореност на потребителя от компонент или система. (Veenendaal)
тестване на синтаксис: Техника за проектиране на тестове за черна кутия, при която тестовите случаи се проектират въз основа на дефиницията на входния домейн и / или изходния домейн.
система: Колекция от компоненти, организирани за изпълнение на определена функция или набор от функции. (IEEE 610)
тестване на системната интеграция: Тестване на интеграцията на системи и пакети; тестване на интерфейси към външни организации (напр. електронен обмен на данни, интернет).
системно тестване: Процесът на тестване на интегрирана система, за да се провери дали тя отговаря на определени изисквания. (Hetzel)
т
технически преглед: Дискусионна дейност на партньорска група, която се фокусира върху постигането на консенсус относно техническия подход, който трябва да се предприеме. Техническият преглед е известен и като партньорска проверка. (Гилб и Греъм, IEEE 1028)
тестов подход: Прилагането на тестовата стратегия за конкретен проект. Обикновено включва взетите решения, които следват въз основа на целта на (тестовия) проект и извършената оценка на риска, отправни точки по отношение на тестовия процес, използваните техники за проектиране на теста, критерии за изход и типове тестове, които трябва да бъдат извършени.
автоматизация на тестове: Използването на софтуер за извършване или подпомагане на тестови дейности, напр. управление на тестове, дизайн на теста, изпълнение на теста и проверка на резултатите.
Тестова основа: Всички документи, от които могат да бъдат изведени изискванията на даден компонент или система. Документацията, на която се базират тестовите случаи. Ако документ може да бъде изменен само чрез официална процедура за изменение, тогава тестовата основа се нарича замразена тестова основа. (След TMap)
тестов случай: Набор от входни стойности, предварителни условия за изпълнение, очаквани резултати и последващи условия за изпълнение, разработени за определена цел или условие за изпитване, като например упражняване на определен програмен път или проверка на съответствие с конкретно изискване. (След IEEE 610)
спецификация на тестовия случай: Документ, посочващ набор от тестови случаи (цел, входове, тестови действия, очаквани резултати и предпоставки за изпълнение) за тестова позиция. (След IEEE 829)
тестова харта: Изложение на целите на теста и евентуално тестови идеи. Хартата за изпитване е сред другите, използвани при изследователски тестове. Вижте също изследователски тестове.
тест за сравнение: Тестов инструмент за извършване на автоматизирано сравняване на тестове.
сравнение на теста: Процесът на идентифициране на разликите между действителните резултати, получени от изпитвания компонент или система, и очакваните резултати за изпитване. Тестовото сравнение може да се извърши по време на изпълнението на теста (динамично сравнение) или след изпълнението на теста.
условие за изпитване: Елемент или събитие от компонент или система, които биха могли да бъдат проверени чрез един или повече тестови случаи, напр. функция, транзакция, качествен атрибут или структурен елемент.
данни от теста: Данни, които съществуват (например в база данни) преди изпълнението на тест и които въздействат или са засегнати от тествания компонент или система.
инструмент за подготовка на тестови данни: Тип инструмент за тестване, който позволява да се избират данни от съществуващите бази данни или да се създават, генерират, манипулират и редактират за използване при тестване.
спецификация на тестовия дизайн: Документ, посочващ условията на изпитване (елементи на покритие) за даден предмет на изпитване, подробен подход за изпитване и идентифициране на свързаните с тях тестови случаи на високо ниво. (След IEEE 829)
инструмент за проектиране на тестове: Инструмент, който подпомага дейността на тестовия дизайн чрез генериране на тестови входни данни от спецификация, която може да се съхранява в хранилище на инструменти CASE, напр. инструмент за управление на изискванията или от определени условия за изпитване, държани в самия инструмент.
техника за проектиране на тестове: Метод, използван за извличане или избор на тестови случаи.
тестова среда: Среда, съдържаща хардуер, инструментариум, симулатори, софтуерни инструменти и други поддържащи елементи, необходими за провеждане на тест. (След IEEE 610)
доклад за оценка на теста: Документ, изготвен в края на тестовия процес, обобщаващ всички тестови дейности и резултати. Той също така съдържа оценка на тестовия процес и научените уроци.
изпълнение на теста: Процесът на провеждане на тест от изпитвания компонент или система, даващ действителни резултати.
автоматизация на тестовото изпълнение: Използването на софтуер, напр. инструменти за улавяне / възпроизвеждане, за контрол на изпълнението на тестовете, сравняване на действителните резултати с очакваните резултати, създаване на предварителни условия за тест и други функции за контрол и докладване на теста.
фаза на изпълнение на теста: Периодът от време в жизнения цикъл на разработка на софтуер, през който се изпълняват компонентите на софтуерен продукт и софтуерният продукт се оценява, за да се определи дали изискванията са изпълнени или не. (IEEE 610)
график за изпълнение на теста: Схема за изпълнение на тестови процедури. Процедурите за тестване са включени в графика за изпълнение на теста в техния контекст и в реда, в който трябва да бъдат изпълнени.
техника на изпълнение на теста: Методът, използван за извършване на действителното изпълнение на теста,било ръчно, било автоматизирано.
инструмент за изпълнение на теста: Тип инструмент за тестване, който е в състояние да изпълнява друг софтуер с помощта на автоматизиран тестов скрипт, напр. улавяне / възпроизвеждане. (Фестър и Греъм)
тестов сбруя: Тестова среда, състояща се от заглушители и драйвери, необходими за провеждане на тест.
тестова инфраструктура: Артефактите на организацията, необходими за извършване на тестване, състоящи се от тестови среди, тестови инструменти, офис среда и процедури.
тест елемент: Индивидуалният елемент, който ще се тества. Обикновено има един тестов обект и много тестови елементи. Вижте също тестовия обект.
тест ниво: Група тестови дейности, които се организират и управляват заедно. Тестовото ниво е свързано с отговорностите в даден проект. Примери за тестови нива са тест на компоненти, тест за интеграция, тест на системата и тест за приемане. (След TMap)
дневник на теста: Хронологичен запис на съответните подробности за изпълнението на тестовете. (IEEE 829)
тест регистрация: Процесът на записване на информация за тестове, извършени в тестов дневник.
ръководител на тестове: Лицето, отговорно за тестване и оценка на тестов обект. Лицето, което ръководи, контролира, администрира планове и регулира оценката на тестовия обект.
управление на теста: Планирането, оценката, наблюдението и контролът на тестовите дейности, обикновено извършвани от ръководител на тестове.
Тест на зрелост (TMM): Поетапна рамка от пет нива за подобряване на тестовия процес, свързана с модела за зрялост на способността (CMM), който описва ключовите елементи на ефективен тестов процес.
Подобряване на тестовия процес (TPI): Непрекъсната рамка за подобряване на тестовия процес, която описва ключовите елементи на ефективен тестов процес, особено насочена към тестване на системата и тестове за приемане.
тестов обект: Компонентът или системата, които ще бъдат тествани. Вижте също тестовия елемент.
цел на теста: Причина или цел за проектиране и изпълнение на тест.
тестов оракул: Източник за определяне на очакваните резултати за сравнение с действителния резултат на тествания софтуер. Оракул може да бъде съществуващата система (за еталон), ръководство за потребителя или специализирано знание на дадено лице, но не трябва да бъде кодът. (След Адрион)
индикатор за изпълнение на теста: Показател, като цяло високо ниво, показващ до каква степен е изпълнена определена целева стойност или критерий. Често свързани с цели за подобряване на процеса на изпитване, напр. Процент на откриване на дефекти (DDP).
тестова фаза: Отделен набор от тестови дейности, събрани в управляема фаза на проект, напр. дейностите по изпълнение на тестово ниво. (След Джерард)
план за изпитване: Документ, описващ обхвата, подхода, ресурсите и графика на предвидените тестови дейности. Той идентифицира, наред с други тестови елементи, характеристиките, които ще бъдат тествани, тестовите задачи, кой ще изпълни всяка задача, степента на независимост на тестера, тестовата среда, използваните техники за тестване и техники за измерване и обосновката за техния избор и всички рискове, изискващи планиране на извънредни ситуации. Това е запис на процеса на планиране на теста (След IEEE 829)
планиране на теста: Дейността по създаване или актуализиране на план за изпитване.
политика за тестване: Документ на високо ниво, описващ принципите, подхода и основните цели на организацията по отношение на тестването.
анализ на тест точки (TPA): Метод за оценка на тест, базиран на формула, базиран на анализ на функционална точка. (TMap)
процедура за изпитване: Вижте спецификацията на процедурата за изпитване.
спецификация на процедурата за изпитване: Документ, посочващ последователност от действия за изпълнение на тест. Известен също като тестов скрипт или ръчен тестов скрипт. (След IEEE 829)
процес на изпитване: Основният процес на тестване включва планиране, спецификация, изпълнение, запис и проверка за завършване. (BS 7925/2)
повторяемост на теста: Атрибут на тест, показващ дали се получават едни и същи резултати при всяко изпълнение на теста.
пробно изпълнение: Изпълнение на тест върху определена версия на тестовия обект.
тестов скрипт: Обикновено се използва за означаване на спецификация на процедурата за изпитване, особено автоматизирана.
спецификация на теста: Документ, който се състои от спецификация на тестовия проект, спецификация на тестовия случай и / или спецификация на тестовата процедура.
тестова стратегия: Документ на високо ниво, дефиниращ нивата на теста, които трябва да се извършат, и тестването в рамките на тези нива за програма (един или повече проекти).
тестов пакет: Набор от няколко тестови случая за тестван компонент или система, където условието за последващо изпитване често се използва като предпоставка за следващото.
резюме на теста: Документ, обобщаващ тестовите дейности и резултатите. Той също така съдържа оценка на съответните тестови позиции спрямо критериите за изход.(След IEEE 829)
тест цел: Набор от критерии за изход.
инструмент за тестване: Софтуерен продукт, който поддържа една или повече тестови дейности, като планиране и контрол, спецификация, изграждане на първоначални файлове и данни, изпълнение на теста и анализ на теста. (TMap) Вижте също CAST.
тип тест: Група тестови дейности, насочени към тестване на компонент или система по отношение на един или повече взаимосвързани атрибути на качеството. Типът тест е фокусиран върху конкретна цел на изпитване, т.е. тест за надеждност, тест за използваемост, тест за регресия и т.н., и може да се проведе на едно или повече нива на изпитване или фази на изпитване. (След TMap)
проверимост: Способността на софтуерния продукт да позволява тестване на модифициран софтуер. (ISO 9126) Вижте също поддръжката.
преглед на проверяемостта: Подробна проверка на тестовата основа, за да се определи дали тестовата основа е на адекватно ниво на качество, за да действа като входящ документ за тестовия процес. (След TMap)
проверими изисквания: Степента, до която дадено изискване е посочено по отношение на условия, които позволяват създаването на тестови проекти (и впоследствие тестови случаи) и изпълнение на тестове, за да се определи дали изискванията са изпълнени. (След IEEE 610)
тестер: Технически квалифициран специалист, който участва в тестването на компонент или система.
тестване: Процесът, състоящ се от всички дейности на жизнения цикъл, както статични, така и динамични, свързани с планиране, подготовка и оценка на софтуерни продукти и свързани работни продукти, за да се определи дали те отговарят на определени изисквания, да се демонстрира, че са годни за целта и да се открият дефекти.
тестов софтуер: Артефакти, произведени по време на тестовия процес, необходими за планиране, проектиране и изпълнение на тестове, като документация, скриптове, входове, очаквани резултати, процедури за настройка и изчистване, файлове, бази данни, среда и всеки допълнителен софтуер или помощни програми, използвани в тестване. (След Fewster и Graham)
тестване на нишки: Версия на тестване за интеграция на компоненти, при която прогресивната интеграция на компоненти следва внедряването на подмножества от изискванията, за разлика от интегрирането на компоненти по нива на йерархия.
проследимост: Възможността да се идентифицират свързани елементи в документацията и софтуера, като напримеризисквания със свързани тестове. Вижте също хоризонтална проследимост, вертикална проследимост.
тестване отгоре надолу: Постепенен подход към тестване на интеграция, при който компонентът в горната част на йерархията на компонентите се тества първо, като компонентите от по-ниско ниво се симулират от заглушители. След това тестваните компоненти се използват за тестване на компоненти от по-ниско ниво. Процесът се повтаря, докато компонентите от най-ниското ниво не бъдат тествани.
U
разбираемост: Способността на софтуерния продукт да позволи на потребителя да разбере дали софтуерът е подходящ и как може да се използва за определени задачи и условия на употреба. (ISO 9126) Вижте също използваемост.
недостижим код: Код, който не може да бъде достигнат и следователно е невъзможен за изпълнение.
използваемост: Способността на софтуера да бъде разбран, научен, използван и привлекателен за потребителя, когато се използва при определени условия. (ISO 9126)
тестване на използваемостта: Тестване за определяне на степента, до която софтуерният продукт се разбира, лесен за научаване, лесен за работа и привлекателен за потребителите при определени условия. (След ISO 9126)
тестване на случаи на употреба: Техника за тестване на черна кутия, при която тестовите случаи са предназначени за изпълнение на потребителски сценарии.
потребителски тест: Тест, при който потребителите от реалния живот се включват за оценка на използваемостта на компонент или система.
V
V-модел: Рамка за описание на дейностите по жизнения цикъл на разработката на софтуер от спецификация на изискванията до поддръжка. V-моделът илюстрира как тестовите дейности могат да бъдат интегрирани във всяка фаза от жизнения цикъл на разработката на софтуер.
валидиране: Потвърждение чрез изследване и чрез предоставяне на обективни доказателства, че са изпълнени изискванията за конкретна предвидена употреба или приложение. (ISO 9000)
променлива: Елемент за съхранение в компютър, който е достъпен от софтуерна програма чрез препращане към него чрез име.
проверка: Потвърждение чрез проверка и чрез предоставяне на обективни доказателства, че са изпълнени определени изисквания. (ISO 9000)
вертикална проследимост: Проследяване на изискванията през слоевете на документацията за разработка към компонентите.
обемно тестване: Тестване, където системата е подложена на големи обеми данни. Вижте също тестване на използването на ресурси.
IN
ръководство: Представяне стъпка по стъпка от автора на документ с цел събиране на информация и установяване на общо разбиране за нейното съдържание. (Фрийдман и У.einberg, IEEE 1028)
техника за тестване на бяла кутия: Документирана процедура за извличане и избор на тестови случаи въз основа на анализ на вътрешната структура на компонент или система.
тестване на бяла кутия: Тестване въз основа на анализ на вътрешната структура на компонента или системата.
Широколентов Delphi: Техника за оценка на тестови оценки, която има за цел да направи точна оценка, използвайки колективната мъдрост на членовете на екипа.
Свържи се с мен ако искате да добавите още определения в този речник.
Справка: http://www.istqb.org/downloads/glossary-1.0.pdf
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тестване на софтуер QA Assistant Job
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
- Ръководство за аутсорсинг на QA: Тестване на софтуерни компании за аутсорсинг
- Някои интересни въпроси за интервю за тестване на софтуер
- Обратна връзка и рецензии на курсове за тестване на софтуер