Защо програмистите имат нужда от тестване?
Следващите няколко нива ще бъдат посветени на тестване по начина, по който програмистите се нуждаят от него . Но първо, нека разберем Howво е тестването и защо е необходимо.
По отношение на софтуера можем да кажем, че задачата на тестването е да се провери дали програмата:
- прави Howвото трябва
- не прави това, което не трябва да прави
Втората точка, между другото, е не по-малко важна от първата, но повече за това по-късно.
Да започнем с първата точка. Какво означава "програмата прави това, което трябва да прави"?
Първо, някой трябва да направи списък на всички случаи на използване на програмата. Второ, те трябва да опишат How трябва да работи програмата, How трябва да се държи потребителят и Howви резултати се очакват. Не можете да продължите по-нататък.
Веднага щом написахме „How трябва да се държи потребителят“, цялата идея за писане на добра documentация се разпадна. Хората не са машини, освен това хората много често се държат със софтуера Howто си искат . Никой не започва запознаването си с технологията, като изучава инструкциите. Това е факт.
Следователно получаваме нов факт: особеността на софтуера е, че има много различни сценарии на работа. Някои от тях са очевидни, други могат да бъдат documentирани, трети могат да се предположат, трети могат да се досетят, а останалите 50% дори няма да ви хрумнат.
От гледна точка на програмист, повечето грешки изобщо не са грешки. Грешка е, когато една програма не работи Howто трябва or Howто се очаква. И има много ситуации, когато не е ясно How трябва да работи програмата or сценарии, които си противоречат ...
Има безкраен брой сценарии и винаги ще има случаи в продукта, когато програмата не се държи според очакванията (програмистът е написал codeа само за няколко дузини сценарии). Следователно може да се твърди, че във всяка програма винаги има грешки и всеки продукт може да се подобрява безкрайно .
След това всичко се свежда до целесъобразността. Първо програмистът коригира най-големите грешки, след това по-малките и т.н. И накрая, идва етап, когато собственикът на продукта смята, че е икономически неизгодно да продължи да работи върху него.
Но обратно към грешките, които всички разпознават като грешки: програмата очевидно прави нещо нередно, падна, счупи нещо и т.н. Такива грешки могат условно да бъдат разделени на 3 категории: големи, средни и малки.
И много често се случва програмистът да работи върху коригирането на средни or дори малки грешки, въпреки че все още има много по-сериозни проблеми в проекта. Той просто не ги е намерил , така че работи върху най-големите, за които знае.
Следователно във всеки проект трябва да има тестери. Тези хора специално се научават да гледат на продукта от различни ъгли. Така можете да видите повече сценарии на програмата. Тяхната задача е да намират грешки и да ги записват (за да не намират една и съща грешка няколко пъти).
Тестването е процес, насочен към намиране на грешки. Тези грешки трябва да бъдат намерени, описани и приоритизирани. Едва след приоритизирането на грешките можем да говорим за ефективен процес на подобряване на софтуера.
Не забравяйте, че първата стъпка към разрешаването на проблем е да признаете, че има проблем . Не можете да поправите грешка, за която не знаете.
Автоматизация на тестовете
Мисля, че всички се съгласихме, че тестването е важно, така че нека погледнем тестването като програмисти. Как програмистите гледат на тестването? Програмистите автоматизират работата на други хора. Последната професия, която ще изчезне, ще бъде професията програмист.
Ние автоматизираме всички процеси, които срещаме. Така че тестването трябва да бъде автоматизирано. И How да автоматизираме търсенето на грешки? Кратък отговор: не. Но тук отново на помощ ни идва фактът, че сме програмисти.
Процесът на разработка на софтуер се състои от постоянни промени в него. просто в процеса на непрекъснато пequalsе на промени програмистите много често развалят нещо, което доскоро е работило добре.
И тестерите, instead of да търсят нови грешки, са принудени непрекъснато да проверяват дали сме счупor нещо, което работи добре от дълго време. Така нареченото регресионно тестване. Именно този тип тестове могат и трябва да бъдат автоматизирани.
Тук целият софтуер може да бъде разделен на две части:
- програмата взаимодейства с човека
- програма взаимодейства с друга програма
Първият вариант е по-труден за автоматизиране, той изисква специални автоматични тестери, те се наричат още QA Automation or Software Test Engineer.
Но вторият вариант може и трябва да бъде автоматизиран независимо. Ако имате софтуер, който:
- работи добре
- вече тествано
- реализирани като отделен модул or логически блок
- не планира промяна
- други модули or програми зависят от него
- функционалната повреда струва скъпо
Препоръчвам да отделите време да напишете тестове за него, които улавят ключови аспекти от текущата му функционалност. Би било разумно да отделите 5% от работното си време за това or 1 ден на месец.
Няма нужда да пишете тестове заради самите тестове.
Никой няма да подкрепи вашите тестове. Нито другите програмисти, нито себе си. Никой не го прави. 99% от всички писмени тестове са изоставени и/or деактивирани. Ако не можете да пишете тестове - не пишете. Пишете само ако абсолютно не можете без тях.
Видове тестове
Всеки програмист, ако не е преминал специално обучение, ще може да каже със собствените си думи Howво е тестване: проверка дали програмата прави това, което трябва. Професионалистите в тази област обаче разграничават цели области (видове) тестване.
Всички тестове наистина се въртят около надеждността и достъпността на софтуера, но за да разберем по-добре посоката на тестване, нека да разгледаме няколко примера.
Да приемем, че тествате типичен онлайн магазин. След това областите на тестване могат да бъдат разделени на следните видове: тестване на производителността, функционално тестване, интеграционно тестване и тестване на единици.
Ако собственикът на сайта реши да стартира сериозна рекламна кампания, тогава много потребители ще дойдат на сайта едновременно. Възможно е сайтът да не падне, но някои от секциите му да работят бавно or дори да спрат да работят.
За да предотвратите това, трябва предварително да идентифицирате подобни проблеми и да предприемете стъпки за тяхното отстраняване. Това се прави с помощта на тестване на натоварването or също се нарича тестване на производителността.
Може също така да искате да тествате How работи вашият backend API и да тествате всяка негова функция: регистрация, влизане, добавяне в кошницата, обработка на плащане, запис в базата данни и т.н. Всичко трябва да работи според ТЗ. В този случай трябва да извършите функционално тестване .
Вашият онлайн магазин най-вероятно е интегриран с услуги на трети страни: изпращане на писма и SMS, платежни системи, онлайн чатове за поддръжка, събиране на обратна връзка от потребители, рекламни системи и т.н. За да сте сигурни, че всичко това работи по преднаmeaning, трябва да тествате интеграцията .
И накрая, сложните продукти често се разделят на независими модули. От такива модули можете да сглобите крайния продукт, като от конструктор. Ако разработвате такъв модул or взаимодействате с такива модули, тогава ще трябва да направите модулно тестване .
Обобщавайки, можем да кажем, че функционалното тестване е необходимо за тестване на всяка отделна функция на сайта. Интеграция - за тестване на взаимодействието на големи модули и системи на вашия продукт. Модулен - за тестване на отделен модул, добре, тестване на производителността - за проверка на работата на вашия сайт под натоварване.
Може да има дори повече видове тестване: колкото по-сложен е продуктът, толкова повече аспекти от неговото развитие трябва да бъдат контролирани.