ЗНАЙ ИНТУИТ, Лекция, Критерииизбор на тестове

Функционални критерии (клас II)

Функционалният критерий е най-важният критерий за тестване за софтуерната индустрия. Той осигурява на първо място контрол на степента на изпълнение на изискванията на клиента в софтуерния продукт. Тъй като изискванията са формулирани за продукта като цяло, те отразяват взаимодействието на тестваното приложение с околната среда. При функционалното тестване се използва предимно моделът на "черната кутия". Проблемът на функционалното тестване е преди всичко трудоемкостта; Факт е, че документите, определящи изискванията за софтуерен продукт (Спецификация на софтуерните изисквания, Функционална спецификация и т.н.), обикновено са доста обемни, но съответната проверка трябва да бъде изчерпателна.

По-долу са определени видове функционални критерии.

Тестови спецификации- набор от тестове в съвкупността трябва да гарантира, че всеки тестов елемент е тестван поне веднъж.

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

Тестване на класове входни данни- наборът от тестове като цяло трябва да гарантира, че представител на всеки клас входни данни е проверен поне веднъж.

При създаване на тестове, класовете входни данни се съпоставят с режимите на използване на тествания компонент или подсистемата на приложението, което значително намалява опциите за итерация, които се вземат предвид при разработването на тестови пакети. Трябва да се отбележи, че в съответствие с критерия за размера на входните променливи (например различни файлове - източници на входни данни), ние сме принудени да прилагамемощни тестови пакети. Всъщност, заедно с ограниченията върху стойностите на входните данни, има ограничения върху стойностите на входните данни във всички възможни комбинации, включително проверка на отговорите на системата при появата на грешки в стойностите или структурите на входните данни. Отчитането на това разнообразие е трудоемък процес, което създава трудности при прилагането на критерия

Правила за тестване- набор от тестове в съвкупността трябва да осигури проверката на всяко правило, ако входните и изходните стойности са описани от набор от правила на някаква граматика.

Трябва да се отбележи, че граматиката трябва да е достатъчно проста, така че сложността на разработването на съответния набор от тестове да е реална (вписва се в крайните срокове и персонала от специалисти, определени за изпълнение на фазата на тестване)

Тестване на изходни класове- наборът от тестове в съвкупността трябва да предоставя тест за представител на всеки изходен клас, при условие че изходите са предварително класифицирани и индивидуалните класове резултати вземат предвид, наред с други неща, ограниченията върху ресурсите или времето (изчакване).

При създаване на тестове изходните класове се съпоставят с режимите на използване на тествания компонент или подсистема, което значително намалява опциите за итерация, които се вземат предвид при разработването на тестови случаи.

Функционално тестване- набор от тестове в съвкупността трябва да гарантира, че всяко действие, изпълнено от тествания модул, се проверява поне веднъж.

Много популярен в практиката критерий, който обаче не осигурява покритие на частта от функционалността на тествания компонент, свързана със структурни и поведенчески свойства, чието описание не е концентрирано в отделни функции (т.е. описанието е разпръснато върху компонента).

Критерият за функционално изпитване съчетава отчасти характеристиките на структурните и функционалните критерии. Базиран е на модела на "прозрачна кутия", където не само входовете и изходите на тествания компонент са изрично посочени, но също и съставът и структурата на използваните методи (функции, процедури) и класове.

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

В този случай всички комбинации от последователни условия трябва да бъдат потвърдени, а условията на противоречия трябва да бъдат открити и елиминирани.

Пример за прилагане на функционални тестови критерии за разработване на тестов пакет въз основа на критерия за класове входни данни

Нека бъде разработен следният фрагмент от спецификацията на изискванията за решаване на проблема с тестването на системата „Система за управление на автоматизиран комплекс за съхранение на лагери“ (вижте Приложение 1, FS):

  1. Проучете състоянието на склада (извикайте функцията GetStoreStat). Добавете записа „СИСТЕМА: Заявен статус на СКЛАД“ към регистъра на съобщенията. В зависимост от получената стойност изпълнете следните действия:
  2. Получен складов статус = 32. Лагер е пристигнал в складовия приемен контейнер. Системата трябва:
  1. Добавете записа "СКЛАД: СТАТУС НА СКЛАДА = 32" към регистъра на съобщенията.
  2. Вземете параметрите на входящия лагер от терминала за лагер (трябва да се извика функцията GetRollerPar).
  3. Добавете записа „СИСТЕМА: Заявени са параметри на лагера“ към регистъра на съобщенията.
  4. В зависимост от стойността, върната от функцията GetRollerPar, трябва да се извършат следните действия (таблица 3.2):
Таблица 3.2. Действия върху резултатите от функцияGetRollerParСтойността, върната от функцията GetRollerPar, системни действия.01.
.
  1. Добавете командата GetR - "GET FROM THE RECEIVER TO THE CELL" на първо място
  2. Добавяне на запис към регистъра на съобщенията "BEARING TERMINAL: 0 - параметрите са върнати"
Добавяне на запис към регистъра на съобщенията „КЛЕМА ЗА ЛАЗЕР: 1 - няма данни“
.
Таблица 3.3. Действия върху резултатите от функцията GetAxleParСтойност, върната от функцията GetAxlePar Системни действия.1.
.
Добавете запис към регистъра на съобщенията "AXIS TERMINAL: 1 - няма данни"
.

Нека дефинираме класовете входни данни за параметъра - складово състояние:

  1. Състояние на склада = 0 (правилно).
  2. Състояние на склада = 4 (правилно).
  3. Състояние на склада = 16 (правилно).
  4. Състояние на склада = 32 (правилно).
  5. Състояние на склада = всяка друга стойност (невалидна).

Сега разгледайте тестовите случаи:

Тестов случай 1 (обхваща клас 4):

Състояние на околната среда (вход - X):

Състояние на склад - 32.

Очаквана последователност от събития (изход - Y):

Системата изисква статуса на склада (извиквайки функцията GetStoreStat) и получава 32

Тестов случай 2 (обхваща клас 5):

Състояние на околната среда (вход - X):

Състояние на склада - 12dfga.

Очаквана последователност от събития (изход - Y):

Системата изисква статуса на склада (извиквайки функцията GetStoreStat ) и според елемента на спецификацията, ако стойността на състоянието на склада е неправилна, съобщението "СКЛАД: ГРЕШКА: Недефиниран статус" се добавя към дневника.