Ръчно тестване на софтуера. Тестове по време на разработка на софтуер

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

Ръчното тестване е част от процеса на тестване по време на фазата на контрол на качеството на процеса на разработка на софтуер. Извършва се от тестери или обикновени потребители чрез симулиране на възможни потребителски сценарии за действие.

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

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

Примерен фрагмент от процедурата

1. Дайте три различни цели числа като вход;
2. Изпълнение на теста;
3. Проверете дали полученият резултат съответства на таблицата [линк към документ1], като вземете предвид измененията [линк към документ2];
4. Уверете се, че предоставената придружаваща информация е разбираема и правилна.

В тази процедура тестерът използва допълнителни документи и собственото си разбиране за това каква придружаваща информация се счита за „разбираема и правилна“. Успехът от използването на процедурен подход се постига, ако тестерът разбира ясно всички точки на процедурата. Например, параграф 1 от горната процедура не уточнява от кой диапазон трябва да бъдат посочени три цели числа и не описва допълнително кои числа се считат за „различни“.

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

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

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

Сравнение на подхода за ръчно и автоматизирано тестване

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

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

Огледи и обходи

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

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

Инспекционната среща е разделена на две части:

1. От програмиста се иска да опише логиката на програмата. По време на разговора възникват въпроси с цел установяване на грешка. Практиката показва, че дори самото четене на вашата програма на ученици изглежда ефективен метод за откриване на грешки и много грешки се откриват от самия програмист, а не от други членове на групата.
2. Програмата се анализира спрямо списък с въпроси, за да се идентифицират исторически често срещани програмни грешки. Участниците в него трябва да съсредоточат вниманието си върху намирането на грешки, а не върху коригирането им. Коригирането на грешки се извършва от програмиста след срещата за проверка. Списъкът с грешки се анализира и категоризира, което позволява да бъде подобрен, за да се подобри ефективността на бъдещите проверки. Можете да поддържате запис на видовете грешки, въз основа на които трябва да се извърши допълнително обучение на програмист в слаби места. Процесът на проверка, в допълнение към основната си цел, изпълнява редица полезни функции. Резултатите от проверката позволяват на програмиста да види грешките, които е направил, и го насърчават да се учи от собствените си грешки, като обикновено му дават възможност да оцени своя стил на програмиране и избор на алгоритми и методи за тестване. Останалите участници придобиват опит, като наблюдават грешките и стила на програмиране на други програмисти. Инспекцията е начин за ранно идентифициране на най-податливите на грешки части от програмата, което ви позволява да се съсредоточите върху тези части по време на тестване.

Гледането от край до край е набор от процедури и методи за откриване на грешки, извършвани от група хора, преглеждащи програмния текст. Методът има много прилики с процеса на проверка, но техните процедури са малко по-различни и използва различни методи за откриване на грешки. Обходът се провежда като непрекъсната сесия и групата се състои от 3–5 души. Процедурата се различава от тази на срещата за проверка по това, че участниците „играят ролята на компютър“. Таблата предлагат малък брой писмени тестове, които представляват набори от входове и очаквани резултати за програма или модул. Тестовите данни се обработват в съответствие с логиката на програмата, състоянието на програмата и стойностите на променливите се проследяват на хартия или дъска. Самите тестове не играят критична роля, а служат като средство за първоначално разбиране на програмата и основа за въпроси към програмиста относно логиката на дизайна и приетите предположения.

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

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

• Метод на черната кутия
• Метод на бялата кутия
• Метод на сивата кутия

Метод на черната кутия.

Терминът „черна кутия“ е споменат за първи път от психиатъра W. R. Ashby в книгата му „Въведение в кибернетиката“ през 1959 г. Той пише, че методът на черната кутия позволява да се изследва поведението на система, абстрахирайки се от нейната вътрешна структура.

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

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

• · Грешки в интерфейса.
• · Липсващи или неправилно внедрени функции.
• · Недостатъчна производителност на системата или грешки в поведението.
• · Неправилни структури на данните или лоша организация на достъпа до външни бази данни.

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

Метод на бялата кутия.

Както подсказва името, този метод на тестване е противоположен на метода на черната кутия. Този метод на тестване се основава на анализ на вътрешната структура на системата.

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

Метод на сивата кутия.

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

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

Ad-hoc тестване

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

Лицето, провеждащо ad-hoc тестване, има добро разбиране на работния процес на приложението, докато се опитва да намери дефекти и да хакне ОТ. Специални тестове са предназначени за откриване на дефекти, които не са открити в съществуващи тестови случаи.

Тестване за приемане

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

Какво е тестване за приемане в Agile?

Тестване на достъпността

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

Гъвкаво тестване

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

API тестване

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

Автоматизирано тестване

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

Тестване по двойки

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

Бета тестване

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

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

Тестването на черна кутия е вид софтуерно тестване, при което от тестващите не се изисква да познават кодирането или вътрешната структура на софтуера. Методът за тестване на черната кутия се основава на тестване ОТс различни входове и сравняване на резултатите с очакваните.

Тестване за обратна съвместимост

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

Ограничено тестване

Граничното тестване е вид тестване, базирано на концепцията за „натрупване на грешки на граници“. Тестването се извършва чрез щателно тестване на дефекти при гранични стойности. Ако полето приема стойност от 1 до 100, тогава се извършва тестване за стойности 0, 1, 2, 99, 100 и 101.

Метод за изпитване на Големия взрив

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

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

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

Тестване на клонове

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

Тестване за съвместимост на браузъра

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

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

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

Тестване на компоненти

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

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

Тестването на покритието на условията е техника за тестване, използвана по време на модулно тестване, при което разработчикът тества всички условия като if, if-else, case и т.н. в тествания кодов модул.

Динамично тестване

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

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

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

Тестване от край до край

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

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

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

Еквивалентен дял

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

Функционално тестване

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

Fuzz тестване

Fuzz тестването или fuzzing е техника за тестване на софтуер, която включва тестване с неочаквани или произволни входове. Софтуерът се тества за грешки или съобщения за грешки, които се появяват поради грешки при въвеждане на данни.

Тестване на GUI

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

Тестване на стъклена кутия

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

Горила тестване (хаотично тестване)

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

Тестване на благоприятен път

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

Интеграционно тестване

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

Тестване на интерфейса

Тестването на интерфейса е необходимо, когато софтуерът осигурява поддръжка за един или повече интерфейси като „графичен потребителски интерфейс“, „интерфейс на командния ред“ или „интерфейс за програмиране на приложения“, за да взаимодействат със своите потребители или друг софтуер. Интерфейсите осигуряват среда за софтуера, за да приеме въвеждане от потребителя и да предостави изход на потребителя. Подходът за тестване на интерфейс зависи от типа интерфейс, който се тества, като GUI или API или CLI.

Тестване за интернационализация

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

Тестване на базата на ключови думи

Базираното на ключови думи тестване е по-скоро автоматизиран подход към тестването на софтуера, отколкото вид самото тестване. Тестването, базирано на ключови думи, е известно като тестване, базирано на дейност или тестване, базирано на таблици.

Стрес тестване

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

Тестване за локализация

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

Отрицателен тест

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

Нефункционално тестване

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

Тестване по двойки

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

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

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

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

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

Регресионно тестване

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

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

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

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

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

Изпитване на дим (изпитване на дим)

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

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

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

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

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

Тестване на скалируемост

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

Тест за стабилност

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

Статично тестване

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

Стрес тестване

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

Тестване на системата

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

Стрес тестване

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

Тестване на системна интеграция

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

Единично тестване

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

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

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

Тестване за приемане от потребителя

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

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

Това е нефункционален тип тестване, извършвано от екип от инженери по производителност. Обемното тестване е вид тестване на производителността. Извършва се обемно тестване, за да се тества надеждността на софтуера при работа с различни размери данни, които се получават и обработват от софтуера. Например, ако ще тествате Microsoft Word, тогава тестът за размера ще бъде да видите дали MS Word може да отваря, записва и работи с файлове с различни размери (от 10 до 100 MB).

Тестване на уязвимости

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

Тестване на бяла кутия

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

Бих искал да отбележа, че нашите ще ви помогнат да се запознаете с тези методи за тестване.

Запишете се сега или заявете обаждане с безплатна консултация!

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

Жизненият цикъл на разработка на софтуер е процедурен процес в разработката на софтуерен продукт. Този процес се осъществява в поредица от стъпки, които обясняват цялостната идея зад разработването на софтуерен продукт.

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

1. Планиране
2. Анализ
3. Дизайн
4. Разработване на софтуер
5. Внедряване
6. Разгръщане
7. Поддръжка

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

Въведение в софтуерното тестване

грешка:грешка или грешка е човешко действие, което води до грешен или неправилен резултат.

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

Отказ:това е разликата между действителните и очакваните резултати.

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

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

1. Откриване на дефекти
2. Спечелете увереност и предоставете информация за нивата на качество
3. Предотвратяване на дефекти

Обхват на софтуерното тестване

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

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

Ключови понятия

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

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

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

Проверка и валидиране:Тестването на софтуера се извършва, като се имат предвид тези два фактора.

1. Проверка: Проверява дали даден продукт е проектиран в съответствие със спецификацията.
2. Валидиране: Проверява дали продуктът отговаря на изискванията на клиента.

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

Видове тестване на софтуер

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

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

Инструкции за тестов скрипт:

• Черна кутия (черна кутия) тестване
• Тестване на бялата кутия
• Тестване на сивата кутия

Нивата на тестване на жизнения цикъл на софтуера включват:

• Единично тестване
• Интеграционно тестване
• Тестване на системата
• Тестване за приемане (алфа тестване и бета тестване)

Други видове софтуерни тестове са:

• Функционално тестване
• Тестване на производителността (тестване на натоварване и стрес тестване)
• Изпитване на дим
• Санитарно изпитване (проверка за последователност)
• Регресионно тестване
• Тестване за възстановяване.
• Тестване на използваемостта
• Тестване за съвместимост
• Тестване на конфигурацията
• Проучвателно изпитване

Автоматизирано тестване

Ръчното тестване е трудоемък процес. Автоматизацията на тестовете включва автоматизиране на ръчен процес. Автоматизирането на тестовете е процес на писане на компютърна програма под формата на скриптове за тестване, което обикновено се извършва ръчно. Някои популярни инструменти за автоматизация са Winrunner, Quick Test Professional (QTP), LoadRunner, SilkTest, Rational Robot и т.н. Инструментите за автоматизация също включват сервизни инструменти като TestDirector и много други.

Методологии за тестване на софтуер

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

• Каскаден модел
• V Модел
• Спирален модел
• Рационален унифициран процес
• Гъвкави модели
• Бързо разработване на приложения

Тествайте артефакти

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

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

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

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

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

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

Тестова група:Това е колекция от тестови случаи.

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

Процесът на тестване на софтуера се извършва в следната последователност, за да се открият недостатъци в системния софтуер:

1. Създаване на тестов план
2. Дизайн на тестов случай
3. Описание на тестовите случаи
4. Преглед на тестови случаи
5. Изпълнение на теста
6. Проучване на резултатите от теста
7. Съставяне на окончателния преглед

По-долу са някои примери за тестване:

Тестване на софтуер за влизане в системната страница:

мишена:потребителят трябва да може да отиде на началната страница.

Предпоставки:

1. Софтуерът трябва да е съвместим с операционната система.
2. Трябва да се появи страницата за въвеждане на вход.
3. Текстовите полета за потребителско име и парола трябва да са налични с подходящи етикети.
4. Трябва да има бутони „Вход“ и „Отказ“ със съответните надписи.

Тест 1

Име на теста:проверка на изискванията за потребителски интерфейс.

Стъпки/Действия:Потребителят сканира страницата, за да види дали включва потребителското име и паролата в текстовите полета със съответните етикети. Освен това бутоните „Вход“ и „Отказ“ трябва да са достъпни с подходящи етикети.

Очаквани резултати:екранът показва потребителския интерфейс според изискванията на потребителя.

Тест 2

Име на теста:Текстовото поле за потребителския идентификатор трябва: 1) да позволява само азбучни знаци (a до z и от A до Z), 2) да не позволява специални знаци като ("$", "#","!","~ ","*",...), 3) не позволяват цифрови знаци (0-9).

Стъпки/Действия: 1) Потребителят въвежда числа в текстовото поле. 2) Потребителят въвежда буквено-цифрови данни в текстовото поле.

Очаквани резултати: i) Показва се съобщение за грешка за числови данни. 2) текстът се приема, когато потребителят въведе азбучни данни в текстовото поле.

Тест 3

Име на теста:Проверка на функционалността на текстовото поле за парола: 1) Текстовото поле за парола трябва да приема шест или повече знака. 2) данните трябва да се показват в криптирана форма.

Стъпки/Действия: 1) Потребителят въвежда само два знака в текстовото поле на паролата. 2) Потребителят въвежда повече от шест знака в текстовото поле на паролата. 3) Потребителят проверява дали данните се показват в криптирана форма.

Очаквани резултати:Когато потребителят въведе по-малко от шест знака в текстовото поле за парола, се показва съобщение за грешка. Системата приема данни, когато потребителят въведе повече от шест знака в текстовото поле на паролата. Системата показва данните в криптирана форма.

Тест 4

Име на теста:проверка на функционалността на бутона „Вход“.

Стъпки/Действия: 1) Потребителят проверява дали бутонът „Вход“ е активиран или деактивиран. 2) Потребителят кликва върху бутона „Вход“ и изчаква да види главната страница на приложението.

Очаквани резултати: 1) системата показва бутона „Вход“. 2) Системата пренасочва потребителя към главната страница на приложението веднага щом щракне върху бутона „Вход“.

Тест 5

Име на теста:проверка на функционалността на бутона „Отказ“.

Стъпки/Действия: 1) Потребителят проверява дали бутонът Отказ е активиран или деактивиран. 2) Потребителят проверява дали текстовите полета за потребителско име и парола са нулирани, когато се щракне върху бутона Отказ.

Очаквани резултати: 1) Системата показва бутоните „Отказ“. 2) Системата нулира текстовите полета за потребителско име и парола, когато потребителят щракне върху бутона Отказ.

Техники за отстраняване на неизправности при тестване на софтуер

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

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

Софтуерна метрика

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

Софтуерните показатели ще ви помогнат да избегнете клопки като:

1. Надвишаване на разходите
2. Определяне на източника на проблема
3. Изясняване на целите

Ще даде отговори на въпроси като:

1. Каква е оценката на всеки процес на дейност?
2. Какво е качеството на разработения код?
3. Как можете да подобрите слабия код?

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

Някои общи софтуерни показатели са:

• Покритие на кода
• Цикломатична сложност
• Кохезия
• Връзка
• Функция за точков анализ
• преднина
• Източник на редове код
• Грешка в редовете на кода

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

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

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

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

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

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

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

Откъде да започнем организирането на процеса на тестване?

Идентифицирам 11 основни критерия при организиране на процеса на тестване:

1. Цели и обхват на тестването
2. Екип
3. контрол
4. Комуникация и взаимодействие
5. Методика на тестване
6. Процесна документация
7. Управление на рисковете
8. Измерване на процеса
9. Инструменти
10. Тестови среди
11. Подобряване на процеса

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

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

• Защо имаме нужда от тестване?
• Какво трябва да тестваме?
• Какви процеси трябва да бъдат формализирани или създадени?
• Как и какво да тестваме?

Едва след като получим отговори на тези въпроси, можем да започнем да преминаваме към стандартите.

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

• ISO 29119
• IEEE 829\1008
• TPI Next&TMap
• ISTQB

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

Всеки ИТ процес трябва винаги да отговаря на нуждите на бизнеса!

Ще анализираме основните критерии за изграждане на процес на тестване.

Цели и обхват на тестването

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

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

Говорейки за зоната за тестване, трябва да разберем отлично какво точно трябва да тестваме. Това могат да бъдат системи, компоненти, бизнес процеси. За да разберете това, просто трябва да отговорите на два въпроса:

• Какво трябва да се тества?
• Какво ще тестваме?

Често това, което трябва да се тества, и това, което ще тестваме, могат да се различават значително. Зависи от възможностите на вашия процес на тестване. „Какво е необходимо“ често се диктува от бизнеса и ръководството, така че добрият мениджър трябва винаги да разбира „какво е необходимо“ за тестване. Както се казва: „Два заека гониш, нито единия няма да хванеш“, така е и тук. Винаги е по-добре да тествате качествено това, което всъщност можете да тествате с екипа си, отколкото да се хванете за всичко, което бизнесът поиска, и да не свършите нищо навреме и дори да пропуснете критични дефекти.

Екип и управление

Екипът е най-важният компонент на процеса на тестване. Без екип вие като лидер няма да направите нищо. Често има няколко подхода за формиране на екип:

Инструменти и инфраструктура

Какъв е процесът на тестване без инструменти? Това се оказва ръчен труд в името на ръчния труд :) Мисля, че много от вас често са чували за писане на тестови случаи в Word документи, за изграждане на графики и диаграми в Excel. Но защо да хабим усилия, ако пазарът ни предлага готови продукти за управление на тестове, като HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr и много други.
Ето защо, ако сте започнали да организирате процеса на тестване, направете този процес удобен и ефективен. Пишете тестови случаи в удобни форми на готови продукти, интегрирайте инструменти със система за управление на задачи, персонализирайте и т.н.

Когато избирате инструмент, винаги трябва да разбирате:

• Какви задачи планирате да изпълнявате?
• Какъв е вашият бюджет за инструменти?

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

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

• Система за управление на дефекти и задачи (може да бъде включена в системата за управление на тестовете)
• Помощни инструменти (за екранни снимки, записване на логове, работа с бази данни, SOUP UI за XML и др.)
• Инструменти за автоматизация ( , Selenium и др.)
• Системи за управление на знания (на wiki engine)

Сега да поговорим за инфраструктурата. В настоящия контекст на моята история имам предвид тестови среди.

В почти всяка организация, особено ако организацията е голяма и не разработва мобилни приложения за play market, ще ви трябва тестова среда(и) за тестване. Капацитетът и обемът на системната интеграция в тестови среди може да варира в зависимост от обема на тестване.

Като стандарт идентифицирам следните типове тестови среди:

• Среда за разработка (може ли да се класифицира като тестова среда?, но все пак)
• Среда за тестване на системата (една или повече системи могат да бъдат разгърнати, компонент, не изисква сериозно захранване)
• Интеграционна среда (пълна интеграционна среда за тестване на функционалността на цялостни бизнес процеси)
• Околна среда (основното изискване е мощността да съответства на бойната верига)
• ProdLike/PreProd среда (среда за отстраняване на грешки в готова тествана компилация, провеждане на инсталационно тестване)

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

Подобряване на процеса

Много често казвам фразата, че „Всеки процес, независимо какъв, винаги трябва да се подобрява постоянно“, на което много често чувам „Защо, нашият процес вече работи добре“.

Но това не е вярно. Защо трябва постоянно да подобряваме процеса на тестване:

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

2. IT секторът непрекъснато се развива. Идват нови технологии и подходи, които винаги ни позволяват да подобряваме процеса на тестване.

Както се казва, няма граници за съвършенството!

Е, как да се подобри е стандартният цикъл на Деминг.

Планирано – Направено – Анализирано – Коригирано

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