Меню

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

key successful unit testing how developers test their own code

Опитайте Нашия Инструмент За Премахване На Проблемите

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

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

Кой знае, че в бъдеще някои от вас може дори да преминат към тестване на бяла кутия и да използват тези техники за валидиране и подобряване на кода!

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

Какво ще научите:

Какво е единично тестване?

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

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

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

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

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

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

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

Значение на писането на единични тестове

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

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

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

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

Методи за единично тестване

Може да се извърши по 2 начина:

  1. Ръчно тестване
  2. Автоматизирано тестване

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

Факт е, че 100% от автоматизацията не е възможна и по този начин винаги ще има някакво ниво на ръчно тестване.

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

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

Техники в рамките на единично тестване

# 1) Тестване на бяла кутия:

най-доброто безплатно сканиране и ремонт на компютър

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

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

# 2) Тестване на черна кутия:

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

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

# 3) Тестване на сива кутия:

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

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

Тестването на сива кутия обхваща следните видове тестове:

  • Матрично тестване.
  • Тестване на образец.
  • Тестване на ортогонален шаблон.
  • Тестване на регресия.

Предимства на единичното тестване

  1. Процесът става гъвкав: За да добавим нови функции или функции към съществуващия софтуер, трябва да направим промени в стария код. Но смяната на нещата с вече тествания код може да бъде както рискова, така и скъпа.
  2. Качеството на кода се подобрява: Качеството на кода се подобрява автоматично, когато се направи модулно тестване. Грешките, идентифицирани по време на това тестване, са отстранени, преди да бъдат изпратени за фазата на тестване на интеграцията. Резултат от стабилен дизайн и разработка, тъй като разработчиците пишат тестови случаи, като първо разбират спецификациите.
  3. Открива грешки рано: Докато разработчиците изпълняват модулни тестове, те откриват грешки в началото на жизнения цикъл на разработката на софтуер и ги отстраняват. Това включва недостатъци или липсващи части в спецификацията, както и грешки в изпълнението на програмиста.
  4. По-лесни промени и опростени интеграции: Извършването на модулно тестване улеснява разработчика да преструктурира кода, да прави промени и да поддържа кода. Той също така прави тестването на кода след интеграция много по-лесно. Коригирането на проблем в Unit Testing може да поправи много други проблеми, възникващи в по-късните етапи на разработка и тестване
  5. Наличност на документация: Разработчиците, които разглеждат функционалността на по-късен етап, могат да се обърнат към документацията за тестване на модули и могат лесно да намерят интерфейс за модулна проверка и да коригират или работят бързо и лесно.
  6. Лесен процес за отстраняване на грешки: Помага за опростяване на процеса на отстраняване на грешки. Ако тестът се провали на някакъв етап, кодът трябва да бъде отстранен, или в противен случай процесът може да бъде продължен без никакви пречки.
  7. По-ниска цена: Когато грешките бъдат открити и отстранени по време на модулното тестване, разходите и времето за разработка се намаляват. Без това тестване, ако същите грешки бъдат открити на по-късен етап след интегрирането на кода, става по-трудно да се проследи и разреши, което го прави по-скъпо и увеличава времето за разработка.
  8. Пълнотата на кода може да бъде демонстрирана с помощта на модулни тестове: Това е по-полезно в гъвкавия процес. Тестерите не получават функционалните компилации за тестване, докато интеграцията не завърши. Попълването на кода не може да бъде оправдано с показване, че сте написали и проверили кода. Но стартирането на Unit тестове може да демонстрира пълнота на кода.
  9. Спестява време за разработка: Попълването на кода може да отнеме повече време, но поради по-малко грешки при тестването на системата и приемането може да се спести цялостно време за разработка.
  10. Покритие на кода може да се измери

Цикъл на единично тестване

Цикъл на единично тестване

(изображение източник )

Какво прави добрия единичен тест?

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

Как да напиша добри Unit Tests?

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

Рамки за единично тестване

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

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

  1. Java framework - JUnit
  2. PHP рамка - PHPUnit
  3. C ++ рамки - UnitTest ++ и Google C ++
  4. .NET framework - NUnit
  5. Python рамка - py.test

Заблуди и истини

  • Отнема повече време за писане на код с тестови случаи на Unit и ние нямаме време за това - В действителност това би спестило времето ви за разработка в дългосрочен план.
  • Единичното тестване ще открие всички грешки - няма, тъй като целта на модулния тест не е да открие грешки, а да разработи стабилни софтуерни компоненти, които ще имат по-малко дефекти в по-късните етапи на SDLC.
  • 100% покритие на кода означава 100% покритие на теста - Това не гарантира, че кодът е без грешки.

Как да приемате единично тестване?

Добро единично тестване може да се извърши в 3 основни части.

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

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

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

Най-добри практики

За да създадете най-добрия код по време на това тестване, вземете под внимание следните точки:

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

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

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

Заключение

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

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

Вашите коментари са най-добре дошли!
Като тестер на черна кутия, какви са вашите наблюдения относно Unit Testing във вашия екип? Някой има ли по-добра идея за успешно тестване на единици?

Препоръчително четене

^