Схема BG051PO001-4.3.05 „Развитие на професионалното образование и обучение в сътрудничество с работодателите” Договор: BG051PO001-4.3.05 – 0022 Име на проект: „Образователни паркове за развитие на професионално знание и компетенции в областта на...
О
ПЕРАТИВНА
ПРОГРАМА
„РАЗВИТИЕ НА ЧОВЕШКИТЕ РЕСУРСИ” 2007-2013
МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА
Схема BG051PO001-4.3.05 „Развитие на професионалното образование и обучение в сътрудничество с работодателите”
Инвестира във вашето бъдеще!
Договор: BG051PO001-4.3.05 – 0022
Име на проект: „Образователни паркове за развитие на професионално знание и компетенции в областта на компютърните технологии и системи в колаборация с IT сектора“
Бенефициент:
Професионална гимназия по компютърни
технологии и системи –
гр. Правец
ДЕЙНОСТ 6.
Разработване
на електронно съдържание за специализираните
професионални курсове,
заложени за професионално обучение в
4
образователни парка
Отчетен
период: 01.04.2014
г. – 30.04.2014
г.
ДИСЦИПЛИНА: ТЕХНОЛОГИЯ НА ПРОГРАМИРАНЕТО
Тема 5. Тестване и настройка. Класификация на видовете тестуване в зависимост от средата, в която се провежда. Контролно тестуване (verification testing). Изпитателно тестуване (validation testing). Атестационно тестуване (certification testing).
Софтуерно осигуряване на качеството (на английски: Software Quality Assurance, SQA) състои от средства за наблюдение на процесите на софтуерното инженерство, както и методите, използвани за осигуряване на качеството. Методите, чрез които това се постига, са много и варират, като могат да включват осигуряване на съответствието с изискванията на един или повече стандарти като тези от групата ISO 9000 или модели като CMMI.
Според терминологията на IEEE качеството на софтуера като понятие се дефинира в две насоки:
степента, в която дадена система, компонент или процес отговаря на определените изисквания
степента, в която дадена система, компонент или процес отговаря на клиентските (потребителски) потребности или очаквания.
История
Разделението на термините "отстраняване на грешки" и "тестване" (изпитване) първоначално е представено от Glenford J. Xxxxx през 1979 г. Той е смятал, че успешен тест е този, който успее да открие бъг. Софтуерната общност искала да се разделят тези две фундаментални дейности и така Xxxx Xxxxxxxx и Xxxxxxx X. Hetzel класифицират през 1988 г. фазите и целите на софтуерното тестване, разделяйки ги на следните етапи:
До 1956 г. - дотогава тестването било асоциирано с дебъгването и не се правила разлика между двата термина
1957–1978 г. - период на демонстрациите, когато тестването и дебъгването били изтъквани
1979–1982 г. - "унищожителен" период, когато главната цел била да се откриват грешки
1983–1987 г. - този период е класифициран като период на оценка. Представя се терминът измерване на качеството.
1988–2000 г. - период на предотвратяване - тогава тестовете трябвало да покажат, че софтуерът покрива нужните критерии, засичат се грешки и се предотвратяват бъдещи такива.
Ролята на тестването при разработката на софтуер
Основната цел на тестването е да се засекат максимален брой софтуерни дефекти, които впоследствие да се коригират. Тестването не гарантира, че крайният продукт ще функционира правилно във всякакви условия, но може да установи конкретно в кои случаи има проблем. Процесът за установяване на проблем често преминава през преглед на сорс-кода на програмата, както и стартирането й в различни среди.
Всеки софтуерен продукт има целева аудитория.
Пример: софтуер, разработен за видео игри, е коренно различен от софтуер за банкова дейност.
Ето защо, когато една компания инвестира в софтуерен продукт, нужно е да се установи дали той е подходящ за целевата аудитория, купувачите или другите заинтересовани страни. Тестването на софтуера е процес, който се опитва да направи тази оценка.
Най-общо ролята на тестването може да се разграничи на:
редуциране риска от проблеми
намаляване в дългосрочен план на разходите, свързани с грешки
допринасяне за качеството на софтуера
помага за постигане на съответствие със стандартите:
договорни или законови изисквания
промишлени стандарти
Други ползи от тестването са:
тестването може да увеличи доверието в качеството на софтуера, ако установи незначителни или никакви грешки;
при наличието на дефекти качеството на продукта се увеличава при отстраняването на дефектите;
извлечените поуки от предишни грешки подобряват бъдещите резултати.
Тестване
Тестването като понятие може да се дефинира в две насоки:
процес на изпитване на софтуера – за установяване дали са покрити посочените изисквания и за откриване на грешки
процес на анализиране на софтуерен продукт – за откриване на разликите между съществуващите и необходимите условия (т.е. „бъгове”) и за оценка на функциите на продукта.
Основни документи, използвани в процеса на тестването:
Тест-стратегия – задава общи цели на фирмено ниво. Например: определя се програма за автоматичното тестване, видове тестване и други.
Тест-план - дефинира цялостната стратегия на тестването за даден проект; изготвя се от тест-мениджъра.
Тест-мениджърът определя екипите и взаимоотношенията между тях, както и разпределението на задачите за дадения проект.
От друга страна тестването може да се определи като процесът на работа на дадена система или компонент при специфични условия, при което резултатите се наблюдават или записват и се дава оценка на някои страни на системата или компонента.
Методи на тестване
Софтуерните методи за тест традиционно се разделят на White Box и Black Box тестване. Тези два метода се използват за описване на подхода на QA инженерите при проектиране на тестовете.
White Box тества вътрешната структура или работата на програмата, но не и нейната функционалност. Въпреки че този метод на изпитване може да разкрие много грешки или проблеми, той не може да открие неимплементирани части или липсващи изисквания в кода.
Техниките, използвани в White Box Test, включват:
API testing (програмен интерфейс на приложения) - тестване на приложение, използващо публичния и частния APIs.
Code coverage - създаване на тестове, за да се отговаря на някои критерии за код покритие (например: създава се тест, за да се изпълни програмата поне веднъж)
Fault injection methods - умишлено се въвеждат грешки, за да се прецени ефективността на изпитване
Mutation testing methods
Static testing methods
Black Box разглежда функционалността, без тестващият QA инженер да знае дали е правилна имплементацията. Тестващият е наясно само с това, което програмата е трябвало да направи, а не как го прави. Black Box тестове имат за цел да тестват функционалността на софтуера в съответствие със зададените изисквания. Това ниво на изпитване обикновено изисква задълбочени тестове. След това се проверява дали за даден вход изходната стойност (или поведение) е: "е" или: "не е" същата като очакваната стойност, определена в теста.
Съществува и трети метод на тестване:
Grey-Box включва познаване на вътрешните структури от данни и алгоритми. Тестващият не се изисква да има пълен достъп до изходния код на софтуера. Използва се, когато има тест на два интегрирани модула с код, писани от различни разработчици.
Седем принципа на тестването
Тестването показва наличието на дефекти – т.е. тестването не доказва липсата на дефекти
Изчерпателно тестване е невъзможно – според ресурсите (време, хардуер и т.н.) се избират подходящите тестове
Ранно тестване – тестването трябва да започне колкото се може на по-ранен етап – спестяват се време и разходи
Групиране на грешките – обикновено малък брой модули съдържат по-големият процент дефекти
"Пестицид" парадокса – повтарящите се тестове губят своята ефективност, което налага постоянната промяна на тестовете
Тестването зависи от контекста на софтуера – различният софтуер се тества по различен начин, например един сайт за електронна търговия се тества по съвсем различен начин от софтуер за авиацията
Заблудата „липса на грешки” – дори да бъдат намерени и отстранени грешките в софтуера, това не означава, че софтуерът ще бъде използваем и ще отговаря на нуждите на клиента
Основни етапи и дейности
Планиране и контрол
Избиране на условията за тестването
Проектиране и изпълнение на случаите за тестване
Проверка на резултатите
Оценяване на критериите за изход от програмата
Докладване за процеса на тестване и състоянието на тестваната система
Финализиране или завършване на заключителните действия
Основни цели при тестването
Намиране на дефекти, грешки и бъгове
Натрупване на увереност относно нивото на качеството
Предоставяне на информация за вземане на решения
Предпазва от бъдещи дефекти
Видове тестване
Инсталационно тестване - показва дали системата е правилно инсталирана спрямо клиентския хардуер.
Тест за съвместимост - тества се дали продуктът е съвместим със средата, в която ще се ползва. Проверява се дали няма да има конфликт с някоя друга програма, инсталирана на системата.
"Разумно тестване" и "Пушачен тест" - разумното тестване определя дали може да се пристъпи към по-нататъшно тестване. Пушачния тест се използва, за да се намери дали има сериозни софтуерни проблеми преди по-нататъшни действия.
Регресивно тестване - показва дали има съществуващи бъгове при добавянето на нов код. Ако програмата допреди е работила коректно и изведнъж започнат да се появяват проблеми, се използва регресивното тестване за откриване на проблема.
Приемно тестване - извършва се от клиента, на негова машина. Xxxxxxx използва Пушачен тест, за да открие дали има някакви несъответствия в софтуера, спрямо неговите изисквания.
Алфа тестване - сформира се отбор от Quality Assurance представяйки си, че са крайния клиент. Това е първичен тест, след който следва Бета тестване.
Бета тестване - използва се след Алфа тестването. Софтуера се предоставя на лица извън програмния отбор, за да може да се вземе фийдбек и от тях.
Функциониращо срещу нефункциониращо тестване - функциониращото тестване се използва, когато дадена операция има конкретен резултат. Тества се дали резултата отговаря на документацията на софтуера. Нефункциониращото тестване се използва в случаи, когато програмата има непредвидимо поведение.
Разрушително тестване - използва се, за да се види, дали програмата работи коректно в условия на грешка. Умишлено се причинява грешка, след което се наблюдава поведението на софтуера.
Тестване на изпълнението - тества се скоростта на изпълнение в конкретна среда. Работи се с големи по обем данни, също се симулира работа в стресова среда.
Потребителско тестване - тества се дали интерфейса на програмата е достатъчно разбираем.
Тестване за достъпност - използва се, за да се провери дали всякакви среди са подходящи за програмата и дали всеки потребител би могъл да ползва програмата.
Тест по сигурността - важен тест, който предотвратява бъдещи опити за злонамерени действия срещу програмата. Много важен тест, когато се работи с поверителна информация.
Интернационализация и локализация - тест, който проверява дали софтуера би работил нормално в различна часова зона, на друг език (без да има превод, само с псевдо локализация)
Развиващ тест - използва се още преди софтуера да се предостави на QA за тест. Премахват се множество грешки, оправят се синхронизации - по този начин QA имат по-малко работа, така се спестяват време и разходи.
Разлика между дебъгване и тестване
Тестване - дейност, която първоначално открива грешки в софтуера
Дебъгване - дейност при разработването на софтуера, която анализира и премахва причините за грешките
Автоматизирано тестване
Чрез софтуера за автоматизирано тестване се проверяват за бъгове множество еднотипни задачи. Използвайки такъв софтуер се намалява времето и усилията за тестване. Недостатъците на този софтуер са невъзможността на автоматизираната програма да оцени удобството за потребителя и откриването само на бъгове включени за тестване.
Selenium е javascript базиран софтуер за тестване на уеб приложения. Тестовете които използва Selenium могат да бъдат на езиците C#, PHP, Java, Ruby, Python, Perl, Javascript. Selenium софтуерът има различни разновидности(Selenium WebDriver, Selenium Grid, Selenium Remote Control, Selenium IDE). Selenium IDE например се инсталира като приставка и работи използвайки браузъра Mozilla Firefox. Selenium Grid дава възможността за тестване под различни браузъри и операционни системи.
Списък на по-известните програми за автоматизирано тестване
|
Създадена от |
Последна версия |
||
Xxxxxxxx Xxxxxxx & AutoIt Team |
3.3.8.1 |
|||
1.0.2 |
||||
2012 |
||||
7.1, Jun 2012 |
||||
v20111026 |
||||
11.5 |
||||
8.3.0 |
||||
National Instruments |
2011 |
|||
Maveryx |
1.3.1 |
|||
12.1 |
||||
Quality First Software GmbH |
3.5.2 |
|||
Ranorex GmbH |
4.0.5 |
|||
IBM Rational |
2003 |
|||
2.7.5 |
||||
2.33.0 |
||||
|
|
X 1.0 |
||
|
14.0 |
|||
|
9.5 |
|||
|
9.1 |
|||
|
8.0 |
|||
|
Micro Focus |
6.3 |
||
|
Telerik |
2012 |
||
|
PikeTec GmbH |
4.2 |
||
|
TRICENTIS Technology & Consulting |
7.5.0 |
||
|
2012 |
|||
|
3.0 |
|||
Софтуерното тестване е процес на изследване и проучване на софтуер, с цел получаване на информация за качеството на продукта и услугата, която се изпитва. Процесите на софтуерното тестване са неразделна част от софтуерното инженерство и осигуряване на качеството на софтуера.
Съществуващите засега методи на тестване на софтуер не позволяват еднозначно и напълно да се видят, проявят и установят всички дефекти и правилното функциониране на една програма, така че методите на тестване работят в рамките на формалния процес на проверка върху изследвания или разработвания софтуер.
Тестването на софтуер е изследване, което се прави с цел да се даде информация на всички заинтересовани страни за качеството на продукта или услугата. То трябва да даде обективна и безпристрастна оценка на софтуера, която да позволи на бизнеса да прецени и разбере рисковете от употребата му. Техниките за тестване могат да включват изпълнение на програмата с цел откриването на грешки (бъгове). Тестването на софтуер може да се разглежда като процес на валидация и верификация, че дадена компютърна програма/приложение/продукт:
Отговарят на изискванията, залегнали при неговия проект и разработка
Работи според очакванията
Може да се въведе в употреба при тези си параметри
Отговаря на нуждите на всички заинтересувани страни
Тестването на софтуера, в зависимост от избрания метод на тестване, може да се проведе по всяко време в процеса на разработка. В традиционния случай повечето тестове се провеждат след като изискванията са формулирани и етапът на писане на код е приключил. За сравнение, при гъвкавия подход на разработка, тестването е продължителен процес, който обхваща целия период на разработката, а не една отделна фаза накрая. Методологията на тестване е в пряка зависимост от метода на разработка.
Процесът на тестване не може да открие всички грешки в даден софтуер, поради тяхното разнообразие. Вместо това, той прави сравнения, служещи за съпоставка на състоянието и поведението на продукта. Създават се „оракули“ – принципи или механизми за разпознаване на проблеми. Те може да са във формата на:
Спецификации
Договори
Еталонни продукти (benchmarking)
Стари версии на същия продукт
Заявки за очаквани ползи
Клиентски очаквания
Приложими стандарти
Приложими закони
Други критерии, поставени от самите разработчици
Основната цел на тестовете е да се открият софтуерни дефекти с цел тяхното отстраняване. Тестването не може да установи дали продуктът ще действа нормално при всички обстоятелства, а по-скоро при какви обстоятелства спира да действа нормално. Обхватът на тестовете може да включва проверка на самия код, неговата работа в различни среди и при различни условия, както и допълнителни аспекти: прави ли това, което се очаква и изисква от него. В съвременната индустрия често компанията, която извършва тестовете, е различна от компанията разработчик. Провеждащият тестовете има различни роли и резултатите от тестовете могат да окажат влияние върху модела и процеса на разработка.
Всеки софтуер има целева група клиенти. Например потребителите на игри се различават в изискванията и очакванията си от потребителите на банков софтуер. Следователно всяка организация, която разработва софтуер, се стреми да прецени дали продуктът им ще се приеме от крайните потребители, купувачите, инвеститорите и други заинтересовани страни. Тестването на софтуера се стреми да помогне с тази оценка.
Грешки и дефекти
Не всички дефекти са породени от грешки в кода. Един чест източник на скъпоструващи дефекти е „разминаване в изискванията“, което води до пропуски в работата на разработчиците. То може да се прояви на не-оперативно ниво (не засяга сериозно работата на продукта) – например:
Трудно тестване
Невъзможност да поеме нарастващ обем работа (невъзможност за разширение/подобрение)
Трудна поддръжка
Трудна навигация
Непостоянно представяне/работа
Проблеми със сигурността
Софтуерните дефекти често се появяват в следната последователност. Разработчик допуска грешка (error), която довежда до дефект (defect, fault, bug) в изходния код (source code). Ако този дефект се изпълни, програмата в дадена ситуация ще даде грешен резултат, което може да предизвика срив (failure). Не всички дефекти задължително предизвикват срив. Например дефектите в неизползван/мъртъв код (dead code) няма да имат никакъв ефект. Един дефект може да се превърне в срив при промяна на обстоятелствата. Примери за подобна промяна са нова машина (хардуерен проблем), промяна във входните данни (софтуерен проблем) или съвместната работа на дадената програма с друг софтуер (комуникационен проблем). Един дефект може да доведе до различни по причина сривове.
Обхват на тестовете
Фундаменталният проблем на тестването на софтуер е невъзможността да се тестват всички възможни входни данни, комбинации от условия и изисквания. Това означава, че разнообразието от дефекти в един софтуер е безкрайно голямо и колкото по-рядко се проявяват те, толкова по-трудно е да се открият чрез тестове. Още повече, че не-операционните аспекти на софтуера (как трябва да бъде, а не какво трябва да прави) са често доста субективни.
Пример: Според разработчика даденият софтуер се очаква да обслужва не повече от десет хиляди потребители, докато инвеститорът иска продукт с капацитет поне сто хиляди потребители.
Софтуерните разработчици не могат да тестват абсолютно всичко, но те могат да използват комбинирани тестове, за да си осигурят покритието, което им трябва. Комбинираните тестове позволяват да се постигне по-голямо покритие с по-малко тестове. В зависимост от това дали се търси скорост или дълбочина на тестово проникване може да се използват комбинирани тестове за изграждане на структурирани вариации от тестове.
Икономическо отражение
Според проучване на Американския национален институт за стандартизация и технологии (NIST) от 2002 година, „софтуерните грешки костват на САЩ близо 59.5 милиарда долара годишно“. Над една трета от тези загуби могат да се избегнат, ако се прилага по-добро тестване на софтуера.
Общоприето е, че колкото по-рано се открие даден дефект, толкова по-евтино е да се отстрани. Съществуват различни изследвания за това xxxxx ще струва отстраняването на даден дефект в зависимост от етапа на разработка, на който е възникнал, спрямо момента, в който е открит. Пример: Дефект, възникнал при определяне на изискванията, ще струва 10-100 пъти повече да се отстрани на етап продукт в продажба, отколкото ако е бил открит още при възникването си.
Политики за поетапно пускане в продажба и облачните технологии биха намалили подобни загуби, защото не се изисква изтегляне на продукт от продажба и бракуване на физически носители.
Роля
До осемдесетте години на 20 век тестването на софтуера се е извършвало от „софтуерни тестъри“, като този термин се използвал общо за всеки специалист извършващ дейността. След това тестването на софтуер се е обособило в отделна професия. В различни периоди и в зависимост от различните цели на тези специалисти са се обособили различни роли: мениджър, водещ на тест екип, анализатор на тестове, разработчик на тестове, тестър (извършващ тестовете), разработчик на автоматични тестове и администратор на тестове.
История
Отделянето на дебъгването (debugging – намиране и отстраняване на дефекти, бъгове) от тестването на софтуер е първоначално представено от Xxxxxxxx Xx. Майерс през 1979 г. Въпреки, че неговото внимание е насочено към тестове, целящи срив („успешен тест е този, който намери бъг“), става ясно, че по това време сред програмистите нараства желанието да се отделят фундаментални дейности по разработката (като „дебъгването“) от чистата верификация (виж т.11.1).
През 1988 Xxxx Xxxxxxxx и Xxxxx Xxxxxx класифицират фазите и целите на тестването на софтуер през годините:
До 1956 – Насочено към дебъгване
1957–1978 – Насочено към демонстрация (че софтуерът работи според изискванията)
1979–1982 – Насочено към предизвикване на срив (теорията на Xxxxxx)
1983–1987 – Насочено към оценка
1988–2000 – Насочено към превенция
Методи за тестване
Статични и динамични тестове
Има много начини за тестване на софтуер. Статичните методи са:
Ревю – разработчика или негов колега минава през целия код и следи за грешки
Представяне – разработчика представя кода пред заинтересуваните страни или негови колеги и те задават въпроси
Инспекция – специалист (често външен за проекта) преглежда методично кода и пише доклад / отчет.
За динамични се считат методи, които изискват кодът да се изпълни, програмата да се натовари с предварително подготвени тестови данни или сценарии. В практиката статичните методи често се прескачат за сметка на динамичните.
Методи, които разчитат само на преглед на кода, са статични, а тези, които изискват да се види и неговата работа, са динамични.
Динамичните тестове могат да започнат преди програмата да е на 100% завършена, като тогава говорим за тестове на отделните градивни единици – например функции и методи. Някои типични техники за това са употребата на драйвери (drivers) или работа в режим на дебъгване.
Статичните методи са свързани с верификация (verification), а динамичните с валидация (validation). Виж т.11.1.
Принципът на кутията
Методите за тестване на софтуер традиционно се разделят на две групи – метод на отворената кутия (на английски: white-box) и метод на затворената кутия (на английски: black-box). Основната разлика идва от фокуса на разработчика – дали се интересува повече как работи софтуерът или дали работи според изискванията. От тук и аналогията:
Отворена кутия – виждаме какво се случва вътре и гледаме само навътре
Затворена кутия – виждаме само какво влиза и излиза, без да ни интересува какво се случва вътре в кутията
Отворена кутия
Методът на отворената кутия (известен още като clear box testing, glass box testing, transparent box testing, и structural testing) е метод за тестване на софтуер, който тества вътрешните структури или начина на действие на приложението, но не и неговата функционалност (за разлика от затворената кутия). Той се основава на вътрешния изглед на системата, както и на уменията за програмиране на този, който тества. Специалистът, който тества, избира входни данни, за да проследи обработката им от системата и определя съответните резултати. Това е аналогично на тестването „възли в схема“ (in-circuit testing, ICT).
Методът на отворената кутия може да се прилага на ниво модул (unit), на интеграционно и системно ниво, но обикновено се прави на ниво модул. Един от начините е тестване на пътя (на английски: path testing). Може да се тества път в рамките на модула, път между отделни модули по време на интеграция, както и между подсистемите по време на тестване на системно ниво. Въпреки че този метод може да разкрие много грешки или проблеми, той не може да открие неизпълнени части на спецификацията или липсващи изисквания.
Методът на отворената кутия включва:
Тестове на системата за контрол
Тестове на системата за пренос на данни
Тестове на разклоненията
Тестове на пътищата
Statement coverage
Decision coverage
Преглед
Методът на отворената кутия работи на ниво изходен код за предотвратяване на всякакви скрити грешки по-късно. Тестовете използват техниките за тестване, посочени по-горе, както и промяната на обсега условие/решение. Методът използва тези техники като насоки за създаване на среда без грешки чрез проучване на всякакъв чуплив код. Те изпълняват всеки видим път на изходния код, като целият смисъл на тестването е да се узнае коя линия на кода се изпълнява и да се определи какъв трябва да бъде правилният изход.
Нива
Тестване на отделните градивни единици (unit testing). Методът на отворената кутия (white-box) е част от тестването на отделните градивни единици, за да се гарантира, че кодът работи според очакванията и в процеса на интегриране ще работим с предварително тестван код. White-box тестване на този етап осигурява, че всички дефекти, ще се открият възможно най-рано и спомага за откриването на дефекти на следващите етапи по метода на изключването (ако отделните единици работят, то проблема е в интеграцията).
Тестове на интеграционно ниво (integration testing). Методът на отворената кутия (white-box) на това ниво се използва за тестване на взаимодействието на един интерфейс с друг. На ниво отделните градивни единици е проверено, че всеки код работи правилно в изолирана среда. Интеграцията изследва правилността на поведението в отворена среда чрез използване на White-box тестване за всякакви взаимодействия на интерфейси, които са известни на програмиста.
Регресивни тестове (regression testing). Методът на отворената кутия (white-box) по време на регресивните тестове се заключва в употребата на вече доказани white-box тестове от предните етапи. Регресивните тестове се провеждат при съществена промяна на кода и имат за цел да осигурят, че новият код няма да доведе до грешки в стария код или в интеграцията с него.
Основна процедура
Основната процедура на White-box тестването включва разбирането на изходния код, което изисква способности на високо ниво, за да може да се тества правилно и пълно. Програмистът трябва да има широки познания за приложението, да знае какви тестовете да създаде, така че всеки видим път да бъде тестван. Когато изходният код е разбран, може да се анализира за тестване. Това са трите основни стъпки, които се правят при white-box тестването, с цел създаване на тестовете:
Вход, включва различни видове условия, функционални спецификации, подробно проектиране на документи, подходящ изходен код, сигурност на спецификациите. Това е подготвителния етап на white-box тестването за оформление на цялата основна информация.
Обработване, включва извършване на анализ на риска, за насочване на целия процес на тестване, подходящ план на теста, тестване и съобщаване на резултатите. Това е фазата на изграждане на тестовете, в уверение на това, че приложението преминава през щателна проверка дадените резултати се записват.
Изход, изготвяне на окончателен доклад, който обхваща всички по-горе подготовки и резултати.
Предимства
White-box тестването е един от двата най-мащабни метода за тестване, използвани днес. Той има три предимства:
Знанията за изходния код са от полза за задълбочено тестване
Оптимизация на кода, разкриват се скрити грешки и може да се премахнат евентуални дефекти.
Дава възможност на програмиста за самоанализ, защото разработчиците внимателно описват всяка нова имплементация.
Недостатъци
Въпреки, че white-box тестването има много предимства, то не е съвършено и има някои недостатъци:
White-box тестването е сложно, защото, за да може да се тества всеки важен аспект на програмата, трябва да имате големи познания за програмата. White-box тестването изисква програмист с високо ниво на познания, поради сложността на нивото на тестване, което трябва да се направи.
В някои случаи, не е възможно да се тества всяко едно възможно състояние на приложението и някои състояния остават неизпитани.
Тестове за проникване
При тестовете за проникване white-box тестването обяснява методологията, където „white hat hacker“ има пълни познания по системата, която е атакувана. Целта на white-box теста за проникване е да симулира злонамерен хакер, който има познания и евентуално основните пълномощия за целевата система.
Затворена кутия (Black-Box)
Тестването тип затворена/черна кутия разглежда софтуера като „черна кутия“, изучавайки функционалността без каквито и да са познания за вътрешното устройство. Човекът, който извършва теста, е само наясно какво би трябвало дадения софтуер да върши, но не и как го прави. Тестването тип черна кутия включва: еквивалентно разпределение (equivalence partitioning), анализ на граничните стойности (boundary value analysis), таблици за промяна на състоянието (state transition tables), тестване на таблиците за взимане на решение (decision table testing), стрес тестване (fuzz testing), тестване базирано на модел (model-based testing), тестване за определени ценарии (use case testing), изследователско тестване (exploratory testing) и тестване основаващо се на спецификацията (specification-based testing).
Тестването основаващо се на спецификация цели да тества функционалността на софтуера като се придържа към зададени изисквания. Това ниво на тестване обикновено изисква да се зададат конкретни и обстойни тестови случаи на тестера, който от своя страна може да потвърди за зададен вход. Изходната информация (или поведение) е или не е както се очаква от зададените тестови случаи. Въпросните тестови случаи се сформират на база спецификациите и изискванията, т. е. въз основа на това за какво е предназначена дадено приложение. То използва описване на външността на софтуера, включително спецификации, които комбинира, за да изгради конкретни тестови случаи. Тези тестове могат да са функционални или нефункционални, въпреки, че обикновено са функционални.
Тестването основаващо се на спецификация може да бъде необходимо за гарантирането на правилната функционалност, но не е достатъчно, за да предпази от сложни или високо-рискови ситуации.
Едно от преимуществата на техниката на черната кутия, че познания по програмиране на са необходими. Каквито и пристрастия да са имали програмистите, най-вероятно тестера може да има различни и може да наблегне на различни аспекти от функционалността. От друга страна, тестването тип черна кутия се счита за „разходка в тъмен лабиринт без фенерче“, защото тестерите не изследват сорс кода. Има случаи, когато тестерите правят много тестове да проверят нещо, което може да се провери само с един тест или пък да оставят някои части от програмата нетествани.
Този метод на тестване може да бъде приложен на всички нива от софтуерното тестване: компонентно (unit), интеграционно (integration), системно (system) и крайно/приемно (acceptance). Той обикновено обхваща по-голямата част, ако не и цялата от тестването на високите нива, но също така доминира и при звеновото тестване.
Визуално тестване (онагледяване на тестовете)
Целта на визуалното тестване е да осигури на разработчиците възможността да изследват какво се случва в момент на софтуерен проблем, като предоставят информация по такъв начин, че разработчиците да могат лесно да намерят информацията, която им е необходима.
В същността на визуалното тестване е идеята, че показвайки на някого проблема (или пълното спиране), вместо простото му описване, е много по информативно и ясно за разбиране. Затова и визуалното тестване изисква записване на целия тестови процес, като записва всичко, което се появява на тестовата система във видео формат. Изходните видеота са допълнени с видео на самия тестер в реално време, както и допълнителен аудио коментар от негова страна.
Визуалното тестване има редица преимущества. Качеството на комуникация е невероятно подобрена, защото тестерите могат да покажат проблема (както и събитията, които водят до него) на разработчиците, сравнено само с простото описване на проблема, както и нуждата да се пресъздадат всички проблеми в програмата, които могат да спрат да се проявяват в много от случаите. Разработчиците ще имат всички данни, които са им необходими за дадения проблем и могат да се фокусират изцяло върху причинителите на грешката и как би могло тя да бъде отстранена.
Визуалното тестване и особено подходящо за среди, които използват методи на постоянна връзка (agile methods) в тяхната разработка на софтуер, тъй като методите с постоянна връзка изискват силна комуникация между тестерите и разработчиците, както и сътрудничество между членовете на малките екипи.
Специфичното тестване (ad hoc testing) и изследователското тестване са важни методологии за проверка на цялостта на софтуера, защото изискват по-малко време за подготовка и изпълнение и въпреки това важните бъгове могат да бъдат открити бързо. При специфичното тестване, където тестването се извършва по импровизиран начин, визуалното записване на самия тест е изключително важно.
Визуалното тестване намира широко приложение при възприемането на клиентите и тестването на използваемостта, защото теста може да бъде използван от много различни хора занимаващи се в процеса на разработка. За клиента е лесно да предостави обратна връзка, както и детайлен доклад за бъговете. За потребителите на програмата, визуалното тестване може да запише всички действия от екрана на потребителя, както и техния глас и видео, за да предостави пълна картина за момента на настъпване на дадения проблем.
Частично отворена кутия (Grey-box)
Тестване тип частично отворена/сива кутия изисква да се има знание за вътрешното устройство на структурите от данни и за алгоритмите с цел на съставянето на тестовете, докато самите тестове се изпълняват на ниво потребители или черна кутия. Не е необходимо тестерите да имат пълен достъп до сорс кода на софтуера. Изменянето на входната информация и форматирането на изходната, не се води за сива кутия, защото входа и изхода са видимо извън „черната кутия“, която представлява системата, която се тества. Това разграничаване е особено важно когато провеждаме интегриращи тестове между два модула код, написани от различни разработчици, където само интерфейсите са предоставени за тестове.
Все пак тестове, които изискват изменяне на информация от съвкупностите с данни, като например бази данни или лог файлове, се класифицират като сива кутия, тъй като при нормални операции потребителите не могат да променят информация от въпросните съвкупности на данни. Тестването тип сива кутия може също така да имплементира в себе си проектирането с обратна връзка (reverse engineering) с цел да определи например гранични стойности или съобщения за грешка.
Като се знае основната концепция за това как работи софтуерът, тестерите правят по-добре информирани тестови избори, докато тестват софтуера отвън. Обикновено на тестерите ползващи сива кутия им е позволено да задават изолирани тестови среди, които предоставят достъп до базите данни. Тестерът може да наблюдава състоянието на даден продукт по време на тестването и извършване на конкретни действия, като изпълняване на SQL заявки към базата данни, последвани от изпълняване на заявки, които потвърждават, че очакваните промени са се изпълнили. Тестването тип сива кутия осъществява интелигентни тестови сценарии, основаващи се на ограничена информация. Това особено се отнася за работата с типовете данни, обработка на изключения и така нататък.
Изготвил:….......
инж. Xxxxxxx Xxxxxx
16