Бихте ли някога летели със самолет, който не е тестван? Разбира се, че не. Би било опасно и безотговорно решение. Същото мнение важи и за разработката на софтуер. Писането на код е лесно, но да се уверите, че работи по предназначение? Не толкова. Повечето тестове са последваща мисъл. За да добави нова функция към приложение, програмистът създава стотици редове код, последван от няколко бегли теста. Този подход „тестване по-късно“ има различни недостатъци. За щастие има лекарство: разработка, управлявана от тестове.
ТЕСТВАНЕТО ПО-КЪСНО Е ЛОША ИДЕЯ
- Програмистите не получават обратна връзка, когато пишат функция, ако няма тестове. Те няма да знаят дали тяхната техника е пълна загуба на време, докато не завършат разработката.
- Тестовете, които програмистите пишат след създаването на функция, обикновено са недостатъчни и лишени от въображение. Казано по друг начин, вместо да идентифицират потенциални проблеми, които могат да възникнат при крайни сценарии, те проверяват само достатъчно, за да знаят, че работи според очакванията.
- Програмистите ще се изкушат да закърпят основната актуализация в приложението, вместо да преработват съществуващата структура на приложението, което ще доведе до раздуване на кодовата база. Те избягват преструктуриране, защото се страхуват да не нарушат други функции.
НАЙ-ДОБРИЯТ НАЧИН ЗА ТЕСТВАНЕ
Основната концепция на процеса на разработка на софтуер, известна като разработка, управлявана от тестове (TDD), е първо да напишете тестовете. TDD променя процеса на кодиране, като предоставя незабавна обратна връзка, в допълнение към насърчаването на пълното покритие на теста. Можете бързо да определите какво работи и какво не с вашето тестване, което вече е налице. Това ви позволява да експериментирате с различни техники. Експериментирането води до учене, а ученето води до подобрен код. Освен това това е просто по-приятен процес.
ВИДОВЕ ИЗПИТВАНИЯ
Единични тестове — Тестове Единичното тестване е компонент от процеса на разработка на софтуер, при който малки части от приложение, известни още като единици, се оценяват независимо за функционалност. Единичното тестване може да се извърши ръчно, но често е автоматизирано в проекти Agile и DevOps
Интеграционни тестове — Фазата на софтуерното тестване, известна като интеграционно тестване, комбинира и тества много софтуерни модули като цяло. Това се случва преди функционалното тестване и тестването след модула.
Функционални тестове — Софтуерът се проверява по време на фазата на функционално тестване, за да се провери дали отговаря на всички бизнес изисквания и има цялата необходима функционалност, за да може програмата да се използва от крайния потребител без проблеми.
Регресионни тестове — Регресионното тестване гарантира, че софтуерът, произведен за по-ранни издания, продължава да функционира правилно след промени, които могат да включват софтуерни подобрения, съответствие с нормативните изисквания, корекции на грешки и др.
Тестове за приемане — При тестване за приемане системата се оценява, за да се види дали крайният потребител ще я намери за задоволителна. Целите на този тест са да се определи дали планът отговаря на бизнес изискванията и да се определи дали е готов за внедряване в производство.
За подробно ръководство за писане на тестови случаи вижте връзките по-долу. Приятно кодиране!
