Тестване на софтуер

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

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

Обобщение

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

• Отговарят на изискванията, залегнали при неговия проект и разработка
• Работи според очакванията
• Може да се въведе в употреба при тези си параметри
• Отговаря на нуждите на всички заинтересувани страни

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

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

• Спецификации
• Договори
• Еталонни продукти (benchmarking)
• Стари версии на същия продукт
• Заявки за очаквани ползи
• Клиентски очаквания
• Приложими стандарти
• Приложими закони
• Други критерии, поставени от самите разработчици

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

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

Грешки и дефекти

Не всички дефекти са породени от грешки в кода. Един чест източник на скъпоструващи дефекти е „разминаване в изискванията“, което води до пропуски в работата на разработчиците. То може да се прояви на не-оперативно ниво (не засяга сериозно работата на продукта) – например:

• Трудно тестване
• Невъзможност да поеме нарастващ обем работа (невъзможност за разширение/подобрение)
• Трудна поддръжка
• Трудна навигация
• Непостоянно представяне/работа
• Проблеми със сигурността

Софтуерните дефекти често се появяват в следната последователност. Разработчик допуска грешка (error), която довежда до дефект (defect, fault, bug) в изходния код (source code). Ако този дефект се изпълни, програмата в дадена ситуация ще даде грешен резултат, което може да предизвика срив (failure). Не всички дефекти задължително предизвикват срив. Например дефектите в неизползван/мъртъв код (dead code) няма да имат никакъв ефект. Един дефект може да се превърне в срив при промяна на обстоятелствата. Примери за подобна промяна са нова машина (хардуерен проблем), промяна във входните данни (софтуерен проблем) или съвместната работа на дадената програма с друг софтуер (комуникационен проблем). Един дефект може да доведе до различни по причина сривове.

Обхват на тестовете

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

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

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

Икономическо отражение

Според проучване на Националния институт за стандарти и технологии в САЩ от 2002 година, „софтуерните грешки костват на САЩ близо 59.5 милиарда долара годишно“. Над една трета от тези загуби могат да се избегнат, ако се прилага по-добро тестване на софтуера.

Общоприето е, че колкото по-рано се открие даден дефект, толкова по-евтино е да се отстрани. Съществуват различни изследвания за това колко ще струва отстраняването на даден дефект в зависимост от етапа на разработка, на който е възникнал, спрямо момента, в който е открит. Пример: Дефект, възникнал при определяне на изискванията, ще струва 10 – 100 пъти повече да се отстрани на етап продукт в продажба, отколкото ако е бил открит още при възникването си.

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

Комбинации за принос и прекондиции

Разликата на precondition от предварително условие е, в това, че предварителното условие се базира на вече реализирани прекондиции или това са контекстите при AI прогностиката.

Роля

През 20 век тестването на софтуера се извършва предимно от самите програмисти, като по-късно се появява идеята за „софтуерен тестър“ или област за софтуерно тестване, като професионална област, като този термин се използва общо за всеки специалист извършващ дейността. В различни периоди и в зависимост от различните цели на тези специалисти са се обособили различни роли: мениджър, водещ на тест екип, анализатор на тестове, разработчик на тестове, тестър (извършващ тестовете), разработчик на автоматични тестове и системен администратор на тестовите машини. С това тестването на софтуер постепенно се е обособява и като отделна професия, която дори има своите подварианти, различни отдели и т.н.

История

Отделянето на дебъгването (debugging – намиране и отстраняване на дефекти, бъгове) от тестването на софтуер е първоначално представено от Гленфорд Дж. Майерс през 1979 г. Въпреки че неговото внимание е насочено към тестове, целящи срив („успешен тест е този, който намери бъг“), става ясно, че по това време сред програмистите нараства желанието да се отделят фундаментални дейности по разработката (като „дебъгването“) от чистата верификация (виж т.11.1).

През 1988 Дейв Гелперин и Уйлям Хетцел класифицират фазите и целите на тестването на софтуер през годините:

• До 1956 – Насочено към дебъгване
• 1957 – 1978 – Насочено към демонстрация (че софтуерът работи според изискванията)
• 1979 – 1982 – Насочено към предизвикване на срив (теорията на Майерс)
• 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

Преглед

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

Нива

1. Тестване на отделните градивни единици (unit testing). Методът на отворената кутия (white-box) е част от тестването на отделните градивни единици, за да се гарантира, че кодът работи според очакванията и в процеса на интегриране ще работим с предварително тестван код. White-box тестване на този етап осигурява, че всички дефекти, ще се открият възможно най-рано и спомага за откриването на дефекти на следващите етапи по метода на изключването (ако отделните единици работят, то проблема е в интеграцията).
2. Тестове на интеграционно ниво (integration testing). Методът на отворената кутия (white-box) на това ниво се използва за тестване на взаимодействието на един интерфейс с друг. На ниво отделните градивни единици е проверено, че всеки код работи правилно в изолирана среда. Интеграцията изследва правилността на поведението в отворена среда чрез използване на White-box тестване за всякакви взаимодействия на интерфейси, които са известни на програмиста.
3. Регресивни тестове (regression testing). Методът на отворената кутия (white-box) по време на регресивните тестове се заключва в употребата на вече доказани white-box тестове от предните етапи. Регресивните тестове се провеждат при съществена промяна на кода и имат за цел да осигурят, че новият код няма да доведе до грешки в стария код или в интеграцията с него.

Основна процедура

Основната процедура на White-box тестването включва разбирането на изходния код, което изисква способности на високо ниво, за да може да се тества правилно и пълно. Програмистът трябва да има широки познания за приложението, да знае какви тестовете да създаде, така че всеки видим път да бъде тестван. Когато изходният код е разбран, може да се анализира за тестване. Това са трите основни стъпки, които се правят при white-box тестването, с цел създаване на тестовете:

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

Предимства

White-box тестването е един от двата най-мащабни метода за тестване, използвани днес. Той има три предимства:

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

Недостатъци

Въпреки че white-box тестването има много предимства, то не е съвършено и има някои недостатъци:

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

Тестове за проникване

При тестовете за проникване white-box тестването обяснява методологията, където „white hat hacker“ има пълни познания по системата, която е атакувана. Целта на white-box теста за проникване е да симулира злонамерен хакер, който има познания и евентуално основните пълномощия за целевата система.

Затворена кутия (Black-Box)

Black box diagram

Тестването тип затворена/черна кутия разглежда софтуера като „черна кутия“, изучавайки функционалността без каквито и да са познания за вътрешното устройство. Човекът, който извършва теста, е само наясно какво би трябвало дадения софтуер да върши, но не и как го прави. Тестването тип черна кутия включва: еквивалентно разпределение (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 заявки към базата данни, последвани от изпълняване на заявки, които потвърждават, че очакваните промени са се изпълнили. Тестването тип сива кутия осъществява интелигентни тестови сценарии, основаващи се на ограничена информация. Това особено се отнася за работата с типовете данни, обработка на изключения и така нататък.

Нива на тестване

Тестовете често се групират на база това на кой етап от разработката на софтуера се провеждат или върху какво се фокусират. Според SWEBOK (Software Engineering Body of Knowledge), разговорното название на ISO/IEC TR 19759:2005 (международен стандарт за разработка на софтуер), има три нива на тестове:

• На ниво отделни градивни единици (unit)
• На ниво интеграция (integration)
• На ниво цялостна система (system)

Тези нива не са обвързани с конкретен модел за разработка и са по-общи. Други групи тестове се идентифицират според обекта на тестване.

Тестове на ниво отделни градивни единици (unit testing)

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

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

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

В зависимост от очакванията на организацията разработчик, тестовете на ниво градивни единици могат да включват статични методи като анализ на кода, анализ на преноса на данни, анализ на различни статистики (метрики), преглед от други разработчици и други практики за проверка на код.

Тестове на ниво интеграция (Integration testing)

Тестовете на ниво интеграция имат за цел да проверя взаимовръзките и съвместната работа на отделните компоненти, когато са поставени в една среда. Компонентите може да се интегрират на вълни или накуп (известно още като Големият Взрив – „big bang“). Счита се, че варианта на вълни е по-добър, защото позволява новопоявили се дефекти да се открият и отстранят по-бързо преди да се интегрира следващата вълна и дефектите са се мултиплицират.

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

Тестове на системно ниво (System testing)

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

Приемни тестове (Acceptance testing)

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

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

Видове тестове

Инсталационни тестове

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

Тестове за съвместимост

Честа причина за сривове и грешки (реални или предполагаеми) е липсата на съвместимост на софтуера с други приложения, операционната система (или нейната версия), средата и вида устройство, на което се ползва (например едно десктоп приложение, което се инсталира на инфо терминал в гара или се отваря през уеб браузър). Пример за проблемна съвместимост е практиката на разработчиците да създават и тестват софтуер само за последните версии на даден продукт (някой потребители може все още да нямат достъп до него), без да проверят дали техния софтуер може да работи с файлове генерирани от предни версии / модели (MS Word 95 не може да отваря файлове с разширение .docx без допълнителен пач). Това довежда до неочаквания ефект най-новите програми да не работят с по-стари операционни системи или хардуер, което спира разпространението им. За да се избегне подобен проблем често се налага писането на пачове, допълнителни модули или библиотеки, което отнема време и средства.

Регресионно тестване (Regression testing)

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

• непроменените части от системата имат непроменено поведение
• модифицираните части работят както се очаква
• системата като цяло изпълнява изискванията

Регресионното тестване се извършва например след отстраняване на дефекти, при внедряване на системата в нова среда, при замяна на някой компонент или при добавяне на нови функционалности към системата. Важна предпоставка за този тип тестове е анализът на влиянието на промените – т.е. да се определи кои точно области на системата ще бъдат засегнати от промените (affected areas).

Тестове за производителност (Performance testing)

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

При тестовете за натоварване (load testing) се тества производителността на системата при различни натоварвания както и възможността ѝ да продължи да работи нормално при тези условия.

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

Тестове за възстановяване след авария (Recovery testing)

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

Тестове за ползваемост (Usability testing)

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

1. Приспособен ли е потребителският интерфейс към профила (образование, социална среда) на крайния потребител?
2. Предоставя ли програмата съдържателни и смислени изходни данни?
3. При възникнали грешки, системата генерира ли ясни и разбираеми съобщения?
4. Системата генерира ли бързо потвърждение на действията на потребителя? Ако някое действие изисква повече време, за да бъде обработено (което е често срещано, когато се работи на отдалечена система), системата генерира ли съобщение, информиращо потребителя за извършваните операции?
5. Лесно ли се използва системата? Например ако програмата изисква движение през поредица от менюта или опции, връщането в главното меню трябва да става лесно, както и преминаването през различните нива на менюто.

Тестове за сигурност

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

Тестване на документацията (Documentation testing)

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

Най-важните изисквания към документацията на системата са тя да бъде актуална, пълна и стилът ѝ да бъде съобразен със спецификацията и компютърната култура на нейните потребители.

А/Б тестове

Често в уеб приложения се ползва този модел (известен още като случаен контролиран експеримент). На потребителя се предлагат два сайта с напълно идентично съдържание и функционалност, като се внася промяна в един-единствен компонент – създават се версия А и версия Б на сайта. На случаен принцип при зареждане на сайта се избира коя версия да се зареди и се отчитат промени в статистиките на сайта в зависимост от това коя версия се ползва. Най-често с тези тестове се следи как потребителите реагират на дадена промяна.

Пример: Онлайн магазин създава две версии на страницата си за промоции. Следи се коя версия генерира повече продажби, по-дълъг престой на потребителя, повече кликове. Така се отчита кой модел на промоции е по-ефективен от икономическа гледна точка. Значението на този вид тестове е доста голямо, защото за минимални промени в продукта/сайта, може да се генерират големи допълнителни печалби.

Процес на тестване

От горе надолу и от долу нагоре

След като тестването на отделните компоненти на софтуера е завършило, отделните единици се интегрират във функционални групи и се тестват отново. Целта на този тип тестване е да се открият скрити дефекти и несъответствия в интерфейсите между отделните модули, използването на паметта, обмена на информация с базите данни. Могат да се открият и грешки в изчисленията (отклонения в изчисленията, които са били допустими за отделните модули, но които могат да се натрупат до неприемливо ниво в хода на експлоатация на системата). Конкуренцията за едни и същи ресурси в даден момент, както и проблеми с времената (за изпращане и получаване на съобщения, за реакция на системата) не могат да се открият по време на тестването на компонентите, но могат да се идентифицират в този сравнително ранен етап от разработката на софтуера. Интеграционното тестване включва голям набор от дейности – като се започне от тестването на няколко модула и се стигне до тестване на цялата система. Интегрирането на модулите инкрементално (стъпка по стъпка) е систематичен начин за интеграция, чрез който продуктът се „сглобява“ и тества на малки парчета, за да може грешките да се откриват, изолират и редактират по-лесно. Инкременталната интеграция може да се извършва отгоре-надолу (top-down) или отдолу-нагоре (bottomup).

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

Интеграцията по метода „отгоре-надолу“, протича по следния начин:

1. Главният модул се използва като драйвер, а останалите модули, които са директно подчинени на главния, се заместват със стъбове.
2. В зависимост от избрания начин – първо в дълбочина (depth-first) или първо в широчина (breadth-first) – подчинените стъбове се заместват с реалните модули един по един.
3. Тестовете се изпълняват всеки път след като някой модул е добавен.
4. След като тестовете преминат успешно, друг стъб се замества с реален модул.
5. Изпълняват се регресионни тестове, за да се осигури, че не са възникнали грешки в резултат от интеграцията на новия модул.
6. Стъпки от 2 до 5 се повтарят, докато се интегрират всички модули.

При използването на този метод възникват няколко проблема:

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

Другият подход – „отдолу-нагоре“ – се осъществява по следния начин:

1. Интеграцията започва с модулите, които са на най-ниското ниво в йерархията. Те са комбинират в клъстери (clusters), които изпълняват определена подфункция.
2. Създават се драйвери, които ще координират входните и изходните данни на тестовете.
3. Тестват се клъстерите.
4. Драйверите се премахват и клъстерите се комбинират.

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

При „Big bang“ подхода, отделните модули не се интегрират докато не приключи самото им разработване. Интеграцията по метода „Big bang“ е подходяща когато се иска да се спести време. Не се налага допълнителна работа по имплементирането на стъбове и драйвъри. Въпреки това, ако тестовите случаи (test cases) и техните резултати не се отчитат правилно, целият процес на интеграция може да се усложни или дори да не завърши. Много често се налага отделните модули да се разделят наново, за да се установи възникнала грешка. Недостатъците на този подход са доста:

• Дефектите в интерфейсите на компонентите се откриват на много късен етап
• Много е трудно да се изолира даден дефект, тъй като е трудно да се разбере дали е дефект в модула, или в интерфейса
• Съществува голяма вероятност да се пропуснат критични дефекти
• Трудно е да се гарантира, че всички случаи на интеграционно тестване са покрити

Свързани статии

• Софтуерно инженерство
• Тестване по двойки (Pair testing)
• Тест мениджмънт (Test management)
• TestOps

Бележки

Тази страница частично или изцяло представлява превод на страницата Software_Testing и страницата White-box_testing в Уикипедия на английски и английски език. Оригиналните текстове, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за творби, създадени преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналните страници тук и тук, за да видите списъка на техните съавтори. ​ ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.

Библиография

• Meyer, Bertrand (August 2008). "Seven Principles of Software Testing" (PDF). Computer. Vol. 41 no. 8. pp. 99–101. doi:10.1109/MC.2008.306. Retrieved November 21, 2017.