Методи за тестване на софтуер и да ги сравните. Изпитателен метод на изпитване "черна кутия" и метода на "бяла кутия"

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

методи

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

Методите за проверка (изпитване) програми могат да бъдат разделени в статичен и динамичен.

Първите включват неофициално, мониторинг и технически преглед, проверка, стъпка по стъпка анализ, одит, както и анализ на статично потока от данни и управление.

Динамични методи са:

1. Бялата кутия изпитване. Това е подробно проучване на вътрешната логика и структурата на програмата. Необходимо е да се познаване на изходния код.
2. тестване Черната кутия. Тази техника не изисква никакви познания за вътрешната работа на приложението. Ние считаме, че само най-основните аспекти на системата, които не са свързани или са свързани с някои от нейната вътрешна логическа структура.
3. Грей метод кутия. Той съчетава две предишни подходи. Отстраняване на грешки с ограничени познания за вътрешното функциониране на заявлението се комбинира с познаването на основните аспекти на системата.

прозрачен тестване

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

Тестване на програми от бяла кутия има следните предимства:

• Тя позволява да се открие грешка в тайния код чрез премахване на ненужните линии;
• използването на странични ефекти;
• максимално покритие се постига чрез написването на тест скрипт.

недостатъци:

• процес с висока цена, което изисква специалистите дебъгер;
• много пътища остават неизследвани защото щателна проверка на всички възможни скрити грешки е много сложен;
• някои от кода ще бъде приет незабелязано.

Бялата кутия изпитване понякога се нарича чрез тестване с прозрачно или отворена кутия, структурни, логически тестове, въз основа на изходния код, и логика архитектура.

Основните сортове:

1) тестване за контрол на потока - структурна стратегия се използва моделът на потока програмно управление и като благоприятно по-прости начини за малко по-сложна;

2) Клонът е предназначен за изучаване грешки всеки вариант (вярно или невярно) на всеки оператор на контрол, който включва комбиниран разтвор;

3) изпитване на главния път, който позволява на тестера за установяване на логическа сложност мярка процесуално проект за изолиране базов набор от изпълнение пътеки;

4) проверка на потока от данни - контрол на потока стратегия на изследване от анотациите на брои информация за рекламата и да използвате променливи в програмата;

5) цикли на изпитване - напълно фокусиран върху правилното функциониране на циклични процеси.

поведенчески грешки

тестване Черната кутия третира софтуера като "черна кутия" - информация за вътрешната работа на програмата не се броят, и се проверява само основните аспекти на системата. В този случай, тестера трябва да знае, архитектурата на системата, без достъп до изходния код.

Предимствата на този подход:

• ефективност за голям код сегмент;
• облекчаване на възприятието тестер;
• потребител перспектива е ясно разграничена от перспективите за програмисти (програмист и тестер са независими един от друг);
• по-бързото създаване на тест.

Тестване на софтуер метод черна кутия има следните недостатъци:

• наистина извършва определен брой тестови случаи, в резултат на ограничено покритие;
• Липсата на ясна спецификация трудно да се разработят тестови скриптове;
• ниска ефективност.

Други имена за тази технология - поведенчески, непрозрачна, функционално тестване и начин за отстраняване на грешки от затворена кутия.

В тази категория може да включва следните техники за софтуерно тестване:

1), еквивалентни на преграда, която може да намали набор от тестови данни като данни вход софтуерен модул се разбиват на отделни части;

2) анализ граница стойност фокусира върху проверката на границите или екстремни гранични стойности - минимум, максимум и типични стойности на грешка;

3) грапавини - използван за осъществяване на търсенето чрез въвеждане на грешки или повреден poluiskazhennyh данни в автоматичен или полуавтоматичен режим;

4) брой на причинно-следствената връзка - техника на базата на създаване на графики и за определяне на връзката между действието и неговите причини: идентичност, отрицание, логически ИЛИ и логическа И - четирите основни символи, експресиращи връзката между причина и ефект;

5) Проверка на ортогонални масиви прилага за проблеми с относително малка площ над входа на възможността за изчерпателни изследвания;

6) изпитване на всички двойки - техника, където набор от тестови стойности включва всички възможни двукомпонентни комбинации от всяка двойка входни параметри;

7) за отстраняване на грешки на преходите - техника, полезна за проверка на състоянието на машината, както и да се придвижвате през GUI потребителя.

тестване Черната кутия: Примери

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

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

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

Колко тестове трябва да се направи, за да се покажат всички възможни стойности за 4 прозореца флаг и областта еднократно, настройте времето в секунди? На пръв поглед изчисление е проста: 4 полета с две възможни състояния - 24 = 16, който трябва да бъде умножена по броя на възможните позиции 00-99, т.е. 1600 възможни тестове.

Все пак, това изчисление не е наред: можем да определим, че полето на две точки може да съдържа едно пространство, т.е. тя се състои от две букви и позиции и може да включва букви, цифри, специални знаци, интервал и т.н. Така, ако .... система е 16-битов компютър, включете 216 = 65 536 по един за всяка позиция в получените 4294967296 тестови случаи, които трябва да се умножи по 16 комбинации от флагове, които дават общо 68719476 736. Ако те изпълняват в един тест за секунда, общата CONT olzhitelnost тестване е 2 177.5 години. За 32 или 64-битови системи, продължителността още повече.

Ето защо е необходимо да се намали този период до приемливо ниво. По този начин, методите трябва да се прилагат за намаляване на броя на тестовете без намаляване на обхвата на тестване.

Еквивалентност разделяне

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

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

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

Например, в (1 / х) ^1/2 с три поредици от данни, три еквивалентни дял:

1. Всички положителни числа ще се третират по същия начин и трябва да дадат правилните резултати.

2. Всички отрицателни числа се обработват по същия начин, със същия резултат. Това не е вярно, защото в основата на отрицателно число е въображаем.

3. Нулева ще бъдат обработени отделно и да даде "деление на нула" за грешка. Това е раздел с една стойност.

По този начин, ние виждаме три отделни секции, едната от които е намалена до една стойност. Има един "правилен" раздел, което дава надеждни резултати, и две "неправилно" с неправилни резултати.

анализ на границата стойност

Обработка на границата на еквивалентната разделяне може да се направи по-различно от очакваното. Изследване на гранични стойности - добре известен метод за анализ на поведението на софтуера в тези области. Тази техника позволява да се идентифицират такива грешки:

• неправилна употреба на релационна оператори (<,>, =, ≠, ≥, ≤);
• единична грешка;
• проблеми в цикли и повторения,
• грешни типове или размер на променливи, използвани за съхранение на информация;
• изкуствени ограничения, свързани с типове данни и променливи.

полупрозрачни тестване

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

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

• архитектурен модел;
• Unified Modeling Language (UML);
• държавен модел (краен автомат).

В метода на сивото поле за разработване на тестови случаи учи модули в бели инженерни кодове и действителното изпитване се провежда върху интерфейсите на черните програми технологии.

Тези методи за изпитване имат следните предимства:

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

недостатъци:

• изпитването покритие е ограничено, тъй като няма достъп до изходния код;
• сложността на дефектите по разпределени приложения;
• много начини да останат неизследвани;
• ако разработчик на софтуер стартира теста, а след това по-нататъшно разследване може да бъде прекомерно.

Друго име за техниките сивото поле - полупрозрачни отстраняване на грешки.

Тази категория включва такива методи за изпитване:

1) ортогонална матрица - използването на подмножество от всички възможни комбинации;

2) матрица грешки при използване на състоянието на данните на програмата;

3) регресивен извършена проверка на новите промени в софтуера;

4) тест шаблон, който анализира дизайна и архитектурата на една добра кандидатура.

Сравнение на техники софтуерното тестване

Използването на динамични методи води до комбинаторна експлозия на броя на тестовете, които трябва да бъдат разработени, внедрена и извършена. Всяка техника трябва да се използва прагматично, като неговите ограничения предвид.

Единственият истински метод не съществува, има само такива, които са по-подходящи за конкретния контекст. Високо строителство да ни позволи да се намери безполезни или зловреден код, но те са сложни и не са приложими за големи програми. Методи, базирани на спецификациите - единствените, които са в състояние да идентифицират липсващия код, но те не могат да се идентифицират аутсайдер. Някои техники са по-подходящи за конкретен ниво тест, тип грешка или контекст, отколкото други.

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

аспект	Методът на черната кутия	Грей метод кутия	метод бяла кутия
Наличие на информация за състава на програмата	Изследва само основните аспекти на	Частичен познания за вътрешната структура на програмата	Пълен достъп до изходния код
Степен на фрагментация на програмата	ниско	централен	високо
Кой произвежда отстраняване на грешки?	Крайни потребители, тестери и разработчици	Крайни потребители, разработчици и дебъгерите	Разработчици и тестери
база	Изследването е въз основа на външни аварийни ситуации.	база данни диаграми, диаграми на потока данни, състоянието на вътрешния знания на алгоритъма и архитектура	Вътрешният устройството е напълно наясно
Степента на покритие	По-малко изчерпателен и изисква минимално време	централен	Потенциално най-изчерпателните. Отнемащ много време
Данни и вътрешните граници	Debug само чрез опити и грешки	Може ли да се провери домейни от данни и вътрешните граници, ако те са известни	Най-добрите домейни данни тест и вътрешните граници
Подходящо алгоритъм тестване	не	не	да

автоматизация

Автоматизирани методи за тестване на софтуер е много опростяват процеса на проверка, независимо от техническата среда и контекста на. Те се използват в два случая:

1) за автоматизиране на досадните, повтарящи се или щателен задачи, като например сравнение на файлове до няколко хиляди редове, за да се освободи време за концентрация на тестера по-важни точки;

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

Инструментите могат да се класифицират по различни начини. Следващото деление се основава на задачите, които те подкрепят:

• управление на тест, който включва поддръжка за управление на проекти, версии, конфигурации, анализ на риска, проследяване на тестове, грешки, дефекти и инструменти за отчитане;
• изисквания за управление, която включва изискванията за съхранение и спецификациите, ги проверява за пълнота и неяснота, техния приоритет и проследяването на всеки тест;
• критичен преглед и статичен анализ, включително и контрол на потока, както и задачите, запис и съхранение на коментари, откриване дефект и планирани връзки за управление на корекции на контролни списъци и правила, проследяване комуникация изходните документи и код статичен анализ за откриване на дефекти, за гарантиране спазването на стандартите на писане код, анализ на структури и зависимости, изчисляване на метрични параметри на кода и архитектура. В допълнение, използват компилатори, анализатори, генератори и отношения на препратки;
• моделиране, който включва инструменти за моделиране на поведението на бизнеса и да тестват моделите;
• развитие тест осигурява генерирането на данни се очаква въз основа на условията и на потребителския интерфейс модели и код, успяват да се създават или променят файлове и бази данни, съобщения, проверка на данни въз основа на правилата за управление, статистически анализ на условията и рисковете;
• критично, като въведете данните чрез графичен потребителски интерфейс, API, на командния ред с помощта на контролите, за да ви помогне да идентифицирате успешни и неуспешни тестове;
• подкрепа за отстраняване на грешки на околната среда, която ви позволява да замени липсващия хардуера или софтуера, в т. ч. Симулация оборудване въз основа на подмножество на определените крайни емулатори изход, мобилни телефони и мрежово оборудване, околната среда за проверка на езици, операционни системи и хардуер , като замества липсващите компоненти водача, фиктивен модули и т.н., както и средства за улавяне и модифициране на операционната система изисква от ограничаване CPU симулация, RAM, ROM, или мрежа .;
• .. Сравнение на файлове с данни, бази данни, проверка на очакваните резултати по време на и след изпитването е пълна, вкл динамичен и сравнение на партида, Автоматична "оракули";
• покритие измерване за локализиране на течове памет и неправилна система оценка на неговото поведение контрол при симулирани приложения товар за генериране на натоварване, бази данни, мрежи или сървъри в реалистичен сценарий за растежа на измерване, анализ и проверка на доклад системни ресурси;
• сигурност;
• тестване за производителност, натоварване и динамичен анализ;
• други инструменти, в т. ч. за проверка на правописа и синтаксиса, сигурността на мрежата, на наличието на всички страници от уебсайтове и други.

перспектива

С променящите се тенденции в софтуерната индустрия, процесът на отстраняване на грешки е и подлежи на промяна. Има нови методи за тестване на софтуер, като например услуги orientirovannae архитектура (SOA), безжични технологии, мобилни услуги, и така нататък. Д., откриват нови начини за тестване на софтуер. Някои от промените, които се очаква в сектора през следващите няколко години, са изброени по-долу:

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

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