Въпрос 9 Нива на тестване от
Единично тестване (единично тестване) - тестване на минималния възможен компонент за тестване, например отделен клас или функция. Единичното тестване често се извършва от разработчиците на софтуер.
Интеграционно тестване – тестват се интерфейси между компоненти, подсистеми. Ако има резерв от време на този етап, тестването се извършва итеративно, с постепенно свързване на следващите подсистеми.
Тестване на системата − Интегрираната система се тества за нейното съответствие с изискванията.
Алфа тестването е имитация на реална работа със системата от разработчици на пълен работен ден или реална работа със системата от потенциални потребители/клиенти. Най-често алфа тестването се извършва на ранен етап от разработването на продукта, но в някои случаи може да се приложи към готов продукт като вътрешно тестване за приемане. Понякога алфа тестването се извършва под дебъгер или с помощта на среда, която помага за бързо идентифициране на открити грешки. Намерените грешки могат да бъдат изпратени на тестери за по-нататъшно проучване в среда, подобна на тази, в която ще се използва софтуерът.
Бета тестване - В някои случаи версия с ограничения (по отношение на функционалност или време за работа) се разпространява на определена група хора, за да се увери, че продуктът съдържа достатъчно малко грешки. Понякога се прави бета тестване, за да се получи обратна връзка за даден продукт от бъдещите му потребители.
Често за безплатен/отворен код етапът на алфа тестване характеризира функционалното съдържание на кода, а бета тестването характеризира етапа на отстраняване на грешки. В същото време, като правило, на всеки етап от развитието междинните резултати от работата са на разположение на финалапотребители.
Въпрос 10 Статично и динамично изпитване
Техниките, описани по-горе - тестване на бяла кутия и тестване на черна кутия - предполагат, че кодът се изпълнява и разликата е само в информацията, която тестерът има. И в двата случая това е динамично тестване.
По време на статичното тестване програмният код не се изпълнява - програмата се анализира въз основа на изходния код, който се чете ръчно или се анализира със специални инструменти. В някои случаи не се анализира изходният код, а междинният код (като байт код или MSIL код).
Статичното тестване също включва изисквания за тестване, спецификации, документация.
Регресионно тестване
След извършване на промени в следващата версия на програмата, регресионните тестове потвърждават, че направените промени не са повлияли на работата на останалата част от функционалността на приложението. Регресионното тестване може да се извърши както ръчно, така и с инструменти за автоматизация на теста.
Тестване на бяла кутия и черна кутия
В професионалната терминология на тестовете изразите „тестване на бяла кутия“ и „тестване на черна кутия“ се отнасят до това дали разработчикът на теста има достъп до изходния код на тествания софтуер или дали тестването се извършва чрез потребителски интерфейс или API, осигурен от тествания модул.
При тестване на бяла кутия (на английски white-box testing, казват също - прозрачна кутия), разработчикът на теста има достъп до изходния код на програмите и може да напише код, който е свързан с библиотеките на тествания софтуер. Това е типично за модулното тестване, при което се тестват само части от системата. Тогарантира, че компонентите на структурата са функционални и стабилни до известна степен. Тестването на бялата кутия използва показатели за покритие на кода.
При тестване на черна кутия тестерът има достъп до софтуера само през същите интерфейси като клиента или потребителя или чрез външни интерфейси, които позволяват на друг компютър или процес да се свърже със системата за тестване. Например, модул за тестване може виртуално да натиска клавиши или бутони на мишката в програмата, която се тества, като използва механизма за комуникация на процеса, с увереността, че всичко върви добре, че тези събития предизвикват същата реакция като реалните натискания на клавиши и бутони на мишката. По правило тестването на черната кутия се извършва с помощта на спецификации или други документи, които описват изискванията към системата. По правило при този тип тестване критерият за покритие се състои от покритие на структурата на входните данни, покритие на изискванията и покритие на модела (при базирано на модел тестване).
При тестване в сива кутия разработчикът на теста има достъп до изходния код, но когато се изпълняват тестове директно, обикновено не се изисква достъп до кода.
Докато „алфа“ и „бета тестване“ се отнасят до етапите преди пускането на даден продукт (и също, имплицитно, до размера на общността за тестване и ограниченията на методите за тестване), тестването с бяла кутия и черна кутия се отнася до начините, по които тестерът постига цел.
Бета тестването обикновено е ограничено до техниките на черната кутия (въпреки че последователна подгрупа от тестери обикновено продължава тестването на бяла кутия успоредно с бета тестването). По този начин терминът "бета тестване" може да показва състоянието на програмата (по-близо до пускане от "алфа") или може да показванякаква група тестери и процеса, извършен от тази група. Така че тестерът може да продължи да работи върху тестването на бяла кутия, въпреки че софтуерът вече е „в бета“ (етап), но в този случай той не е част от „бета тестването“ (група / процес).