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

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

методи

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

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

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

Динамичните техники са, както следва:

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

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

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

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

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

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

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

Тестването в бяла кутия понякога се нарича прозрачно или отворено кутийно тестване, структурно, логическо тестване, тестване на базата на източника, архитектура и логика.

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

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

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

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

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

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

Behavioral debugging

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

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

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

Тестовите програми, използващи черни кутии, имат следните недостатъци:

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

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

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

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

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

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

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

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

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

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

Тестване на черна кутия: примери

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

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

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

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

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

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

Еквивалентно разлагане

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

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

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

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

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

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

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

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

Граничен анализ

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

• злоупотреба с релационни оператори (<,>, =, ne-, ge-, le-);
• единични грешки;
• Проблеми в цикъла и повторенията,
• Грешен тип или размер на променливите, използвани за съхраняване на информация;
• изкуствените ограничения, свързани с данните и видовете променливи.

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

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

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

• архитектурен модел;
• Унифициран език за моделиране (UML);
• държавен модел (машина с крайни състояния).

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

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

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

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

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

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

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

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

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

3) регресионен тест, проведен при нови промени в софтуера;

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

Сравнение на методите за тестване на софтуер

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

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

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

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

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

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

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

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

• Управление на тестовете, което включва поддръжка за управление на проекти, версии, конфигурации, анализ на риска, проследяване на тестове, грешки, дефекти и инструменти за отчитане;
• управление на изискванията, което включва съхранение на изисквания и спецификации, тяхната проверка за пълнота и двусмислие, техния приоритет и проследимост на всяко изпитване;
• критичен преглед и статичен анализ, включително и контрол на потока, както и задачите, запис и съхранение на коментари, откриване дефект и планирани връзки за управление на корекции на контролни списъци и правила, проследяване комуникация изходните документи и код статичен анализ за откриване на дефекти, за гарантиране спазването на стандартите на писане код, анализ на структурите и техните зависимости, изчисляване на метрични параметри на код и архитектура. Освен това се използват компилатори, анализатори на връзки и генератори за кръстосани референции;
• Моделиране, което включва инструменти за моделиране на бизнес поведението и тестване на създадените модели;
• Тестовото разработване осигурява генериране на очаквани данни въз основа на потребителски условия и интерфейс, модели и код, като ги управлява, за да създават или променят файлове и бази данни, съобщения, валидиране на данни въз основа на правила за управление, анализ на състоянието на статистиката и рисковете;
• Критично гледане чрез въвеждане на данни чрез графичния потребителски интерфейс, API, командни линии, използващи съпоставители, помагащи за определяне на успешни и неуспешни тестове;
• подкрепа за отстраняване на грешки на околната среда, която ви позволява да замени липсващия хардуера или софтуера, в т. ч. оборудване симулатори основана на определената продукция подгрупата, терминални емулатори, мобилни телефони или мрежово оборудване, тестовата среда за езици, операционни системи и железария чрез замяна на липсващи компоненти с драйвери, модулни модули и т.н., както и инструменти за прихващане и модифициране на заявки за OS, симулиране на ограничения на процесора, RAM, ROM или мрежа;
• сравняване на файлове с данни, бази данни, проверка на очакваните резултати по време и след тестване, включително динамично и периодично сравнение, автоматични "оракули";
• покритие измерване за локализиране на течове памет и неправилна система оценка на неговото поведение контрол при симулирани приложения товар за генериране на натоварване, бази данни, мрежи или сървъри в реалистичен сценарий за растежа на измерване, анализ и проверка на доклад системни ресурси;
• предоставяне на сигурност;
• тестване на резултатите, натоварване и динамичен анализ;
• Други инструменти, включително за проверка на правописа и синтаксис, мрежова сигурност, наличието на всички страници на сайта и др.

перспектива

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

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

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