В този раздел ще разберем различните видове софтуерни тестове, които могат да се използват по време на жизнения цикъл на разработката на софтуер.
Както знаем, софтуерно тестване е процес на анализиране на функционалността на приложението според предпоставките на клиента.
Ако искаме да сме сигурни, че нашият софтуер е без грешки или стабилен, трябва да извършим различните видове софтуерни тестове, защото тестването е единственият метод, който прави нашето приложение без грешки.
Различните видове софтуерно тестване
Категоризирането на софтуерното тестване е част от различни тестови дейности, като напр тестова стратегия, тестови резултати, дефинирана тестова цел и др . А софтуерното тестване е изпълнението на софтуера за откриване на дефекти.
Целта на наличието на тип тестване е да се потвърди AUT (Приложението се тества).
За да започнем тестването, трябва да имаме a изискване, готово за приложение, налични необходими ресурси . За да поддържаме отчетност, трябва да възложим съответен модул на различни тестови инженери.
Тестването на софтуера е разделено главно на две части, които са както следва:
Какво е ръчно тестване?
Тестването на всеки софтуер или приложение според нуждите на клиента без използване на инструмент за автоматизация е известно като ръчно тестване .
С други думи, можем да кажем, че това е процедура на проверка и валидиране . Ръчното тестване се използва за проверка на поведението на приложение или софтуер в противоречие със спецификацията на изискванията.
Ние не изискваме никакви точни познания за който и да е инструмент за тестване, за да изпълним ръчните тестови случаи. Можем лесно да подготвим тестовия документ, докато извършваме ръчно тестване на всяко приложение.
За да получите подробна информация относно ръчното тестване, щракнете върху следната връзка: https://www.javatpoint.com/manual-testing.
Класификация на ръчното тестване
При софтуерното тестване ръчното тестване може да бъде допълнително класифицирано в три различни вида тестове , които са както следва:
За по-добро разбиране нека ги видим един по един:
Тестване на бяла кутия
При тестване в бяла кутия разработчикът ще инспектира всеки ред код, преди да го предаде на екипа за тестване или на заинтересованите инженери за тестване.
Впоследствие кодът е забележим за разработчиците по време на тестването; затова този процес е известен като WBT (тестване на бяла кутия) .
С други думи, можем да кажем, че разработчик ще изпълни пълното тестване на бялата кутия за конкретния софтуер и ще изпрати конкретното приложение на екипа за тестване.
Целта на прилагането на тестването на бялата кутия е да се подчертае потокът от входове и изходи през софтуера и да се подобри сигурността на приложението.
Тестването на бялата кутия е известно още като тестване на отворена кутия, тестване на стъклена кутия, структурно тестване, тестване на прозрачна кутия и тестване на прозрачна кутия .
За да получите по-задълбочени познания относно тестването с бели кутии, вижте връзката по-долу: https://www.javatpoint.com/white-box-testing.
Тестване на черна кутия
Друг вид ръчно тестване е тестване в черна кутия . При това тестване тестовият инженер ще анализира софтуера спрямо изискванията, ще идентифицира дефектите или грешката и ще го изпрати обратно на екипа за разработка.
След това разработчиците ще поправят тези дефекти, ще направят един кръг от тестване на Бялата кутия и ще го изпратят на екипа за тестване.
Тук коригирането на грешките означава, че дефектът е разрешен и конкретната функция работи според даденото изискване.
Основната цел на прилагането на тестването на черната кутия е да се уточнят бизнес нуждите или изискванията на клиента.
С други думи, можем да кажем, че тестването на черна кутия е процес на проверка на функционалността на дадено приложение според изискванията на клиента. Изходният код не се вижда при това тестване; затова е известен като тестване в черна кутия .
За повече информация относно тестването на черна кутия вижте връзката по-долу: https://www.javatpoint.com/black-box-testing.
Видове тестване на черна кутия
Тестването на черната кутия допълнително се категоризира в две части, които са обсъдени по-долу:
Функционално тестване
Тестовият инженер ще проверява систематично всички компоненти спрямо спецификациите на изискванията, известни като функционално тестване . Функционалното тестване е известно още като Тестване на компоненти .
При функционалното тестване всички компоненти се тестват чрез даване на стойност, дефиниране на изхода и валидиране на действителния изход с очакваната стойност.
Функционалното тестване е част от тестването на черна кутия, тъй като набляга върху изискванията на приложението, а не върху действителния код. Тестовият инженер трябва да тества само програмата вместо системата.
За да получите подробна информация относно функционалното тестване, вижте връзката по-долу: https://www.javatpoint.com/functional-testing .
Видове функционални тестове
Точно както друг вид тестване е разделено на няколко части, функционалното тестване също се класифицира в различни категории.
Разнообразното видове функционално тестване съдържат следното:
Сега, нека ги разберем един по един:
1. Единично тестване
Единичното тестване е първото ниво на функционално тестване, за да се тества всеки софтуер. При това тестовият инженер ще тества независимо модула на дадено приложение или ще тества цялата функционалност на модула единица тестване .
Основната цел на изпълнението на тестването на модула е да се потвърдят компонентите на модула с тяхната производителност. Тук единица се дефинира като единична тествана функция на софтуер или приложение. И се проверява през цялата определена фаза на разработка на приложение.
Щракнете върху връзката по-долу, за да получите пълната информация относно тестването на единици: https://www.javatpoint.com/unit-testing.
2. Интеграционно тестване
След като успешно внедрим модулното тестване, ще преминем към интеграционно тестване. Това е второто ниво на функционално тестване, където тестваме потока от данни между зависимите модули или интерфейсът между две функции се нарича интеграционно тестване .
Целта на изпълнението на интеграционното тестване е да се тества точността на израза между всеки модул.
Видове интеграционни тестове
Интеграционното тестване също е допълнително разделено на следните части:
Инкрементално интеграционно тестване
Винаги, когато има ясна връзка между модулите, ние преминаваме към поетапно тестване на интеграцията. Да предположим, че вземаме два модула и анализираме потока от данни между тях дали работят добре или не.
Ако тези модули работят добре, тогава можем да добавим още един модул и да тестваме отново. И можем да продължим със същия процес, за да постигнем по-добри резултати.
С други думи, можем да кажем, че постепенното добавяне на модулите и тестването на потока от данни между модулите е известно като Инкрементално интеграционно тестване .
Видове инкрементално интеграционно тестване
Постепенното интеграционно тестване може допълнително да се класифицира в две части, които са както следва:
Нека видим кратко представяне на тези типове интеграционно тестване:
1. Тестване на постепенна интеграция отгоре надолу
При този подход ние ще добавяме модулите стъпка по стъпка или постепенно и ще тестваме потока от данни между тях. Трябва да гарантираме, че модулите, които добавяме, са дете на по-ранните .
2. Постепенно интеграционно тестване отдолу нагоре
При подхода отдолу нагоре ще добавяме модулите постепенно и ще проверяваме потока от данни между модулите. И също така се уверете, че модулът, който добавяме, е родител на по-ранните .
Неинкрементално интеграционно тестване/Метод на Големия взрив
Винаги, когато потокът от данни е сложен и е много трудно да се класифицират родител и дете, ние ще използваме подхода за неинкрементална интеграция. Неинкременталният метод е известен още като методът на Големия взрив .
За да получите пълна информация относно интеграционното тестване и неговия тип, вижте следната връзка: https://www.javatpoint.com/integration-testing.
3. Тестване на системата
Всеки път, когато приключим с модулното и интеграционното тестване, можем да продължим със системното тестване.
При системното тестване тестовата среда е паралелна на производствената среда. Известен е още като от край до край тестване.
При този тип тестване ще преминем всеки атрибут на софтуера и ще тестваме дали крайната функция работи според бизнес изискванията. И анализ на софтуерния продукт като цялостна система.
Щракнете върху връзката по-долу, за да получите пълната информация за системното тестване: https://www.javatpoint.com/system-testing.
Нефункционално тестване
Следващата част от тестването на черната кутия е нефункционално тестване . Предоставя подробна информация за производителността на софтуерния продукт и използваните технологии.
Нефункционалното тестване ще ни помогне да минимизираме риска от производство и свързаните с това разходи за софтуера.
Нефункционалното тестване е комбинация от производителност, натоварване, стрес, използваемост и тестване за съвместимост .
За повече информация относно нефункционалното тестване вижте следната връзка: https://www.javatpoint.com/non-functional-testing.
Видове нефункционални тестове
Нефункционално тестване, категоризирано в различни части на тестване, които ще обсъдим допълнително:
1. Тестване на производителността
При тестване на производителността тестващият инженер ще тества работата на дадено приложение чрез прилагане на известно натоварване.
При този тип нефункционално тестване, тестовият инженер ще се съсредоточи само върху няколко аспекта, като напр Време за реакция, натоварване, мащабируемост и стабилност на софтуера или приложението.
Класификация на тестовете за ефективност
Тестването на производителността включва различните видове тестове, които са както следва:
Докато изпълняваме теста за производителност, ние ще приложим известно натоварване върху конкретното приложение, за да проверим производителността на приложението, известно като тестване на натоварването . Тук товарът може да бъде по-малък или равен на желания товар.
Това ще ни помогне да открием най-големия работен обем на софтуера и тесните места.
За да получите пълната информация, свързана с тестването на натоварване, вижте връзката по-долу:
https://www.javatpoint.com/load-testing.
Използва се за анализиране на удобството за потребителя и устойчивостта на софтуера извън общите функционални ограничения.
Основно стрес тестовете се използват за критичен софтуер, но могат да се използват и за всички видове софтуерни приложения.
Препратка към връзката по-долу за задълбочени познания относно стрес тестването: https://www.javatpoint.com/stress-testing.
За анализ производителността на приложението чрез подобряване или намаляване на натоварването в определени баланси е известна като тестване за скалируемост .
При тестване за мащабируемост можем също да проверим система, процеси или способност на базата данни за задоволяване на възходяща нужда. И в това, Тестови случаи са проектирани и изпълнени ефективно.
Кликнете върху следната връзка, за да получите подробна информация, свързана с теста за скалируемост:
https://www.javatpoint.com/scalability-testing.
Тестването за стабилност е процедура, при която оценяваме производителността на приложението чрез прилагане на натоварване за точно време.
Той основно проверява проблемите с постоянството на приложението и ефективността на разработен продукт. При този вид тестване можем бързо да открием дефекта на системата дори в стресова ситуация.
За да получите подробна информация относно теста за стабилност, вижте връзката по-долу:
https://www.javatpoint.com/stability-testing.
2. Тестване на използваемостта
Друг вид на нефункционално тестване е тестване на използваемостта . При тестване за използваемост ние ще анализираме удобството на потребителя на дадено приложение и ще открием грешките в интерфейса на крайния потребител на софтуера.
Ето, терминът удобство за потребителя дефинира следните аспекти на приложението:
- Приложението трябва да е лесно за разбиране, което означава, че всички функции трябва да са видими за крайните потребители.
- Изгледът и усещането на приложението трябва да са добри, което означава, че приложението трябва да изглежда приятно и да кара крайния потребител да го използва.
За повече информация относно тестването на използваемостта можем да се обърнем към следната връзка:
https://www.javatpoint.com/usability-testing.
3. Тестване за съвместимост
При тестване за съвместимост ще проверим функционалността на дадено приложение в специфични хардуерни и софтуерни среди. Само след като приложението е функционално стабилно, отиваме тестване за съвместимост .
Тук, софтуер означава, че можем да тестваме приложението на различни операционни системи и други браузъри, и хардуер означава, че можем да тестваме приложението на различни размери.
За да получите задълбочени познания относно тестването за съвместимост, вижте връзката по-долу:
инсталиране на факла
https://www.javatpoint.com/compatibility-testing .
Тестване на сивата кутия
Друга част от ръчно тестване е Тестване на сивата кутия . Това е сътрудничество при тестване на черна и бяла кутия .
Тъй като тестването на сивата кутия включва достъп до вътрешно кодиране за проектиране на тестови случаи. Тестването на сивата кутия се извършва от лице, което познава кодирането, както и тестването.
С други думи, можем да кажем, че ако екип от един човек направи и двете тестване на бяла кутия и черна кутия , смята се тестване на сивата кутия .
За да получите подробна информация за тестването на сивата кутия, можем да направим справка с връзката по-долу:
https://www.javatpoint.com/grey-box-testing.
Тестване на автоматизацията
Най-важната част от тестването на софтуера е автоматизираното тестване. Той използва специфични инструменти за автоматизиране на тестови случаи за ръчен дизайн без човешка намеса.
Автоматизираното тестване е най-добрият начин за подобряване на ефективността, производителността и покритието на софтуерното тестване.
Използва се за повторно изпълнение на тестовите сценарии, които са изпълнени ръчно, бързо и многократно.
С други думи, можем да кажем, че всеки път, когато тестваме приложение с помощта на някои инструменти, е известно като автоматизирано тестване .
Ще преминем към автоматизирано тестване, когато различни версии или няколко цикъла на регресия преминат към приложението или софтуера. Не можем да напишем тестовия скрипт или да извършим автоматизираното тестване, без да разбираме езика за програмиране.
За повече информация относно автоматизираното тестване можем да направим справка с връзката по-долу:
https://www.javatpoint.com/automation-testing.
Някои други видове софтуерно тестване
В софтуерното тестване имаме и някои други типове тестове, които не са част от горепосочените тестове, но тези тестове са задължителни при тестване на всеки софтуер или приложение.
Нека разберем тези видове тестове един по един:
в тестване на дим , ние ще тестваме основните и критични характеристики на дадено приложение, преди да направим един кръг от дълбоко и строго тестване.
Или преди проверка на всички възможни положителни и отрицателни стойности е известен като тестване на дим . Анализирането на работния процес на основните и основните функции на приложението е основната цел на извършването на теста за дим.
За повече информация относно тестването на дим вижте следната връзка:
https://www.javatpoint.com/smoke-testing.
Тестване за вменяемост
Използва се, за да се гарантира, че всички грешки са коригирани и че не възникват допълнителни проблеми поради тези промени. Тестването за разум е без сценарий, което означава, че не можем да го документираме. Той проверява коректността на новодобавените функции и компоненти.
За да получите подробна информация относно теста за здравина, можем да се обърнем към връзката по-долу:
https://www.javatpoint.com/sanity-testing.
Регресионно тестване
Регресионното тестване е най-често използваният тип софтуерно тестване. Ето, терминът регресия означава, че трябва да тестваме отново тези части от незасегнато приложение.
Регресионното тестване е най-подходящото тестване за инструменти за автоматизация. Според вида на проекта и достъпността на ресурсите, регресионното тестване може да бъде подобно на Повторно тестване .
Всеки път, когато грешка бъде коригирана от разработчиците и след това тестването на другите функции на приложенията, които могат да бъдат симулирани поради коригирането на грешка, е известно като регресионно тестване .
С други думи, можем да кажем, че всеки път, когато има нова версия за даден проект, тогава можем да извършим регресионно тестване и поради нова функция може да повлияе на старите функции в по-ранните версии.
За да получите задълбочени познания, свързани с регресионното тестване, вижте връзката по-долу:
https://www.javatpoint.com/regression-testing .
Тестване за приемане от потребителя
Тестването за приемане от потребителя (UAT) се извършва от индивидуален екип, известен като експерт по домейн/клиент или клиент. И познаването на приложението преди приемането на крайния продукт се нарича като тестване за приемане от потребителя .
При тестване за приемане от потребителите ние анализираме бизнес сценариите и сценариите в реално време в отделната среда, наречена UAT среда . В това тестване ще тестваме приложението преди UAI за одобрение от клиента.
За повече информация относно тестването за приемане от потребителя, щракнете върху връзката по-долу:
https://www.javatpoint.com/acceptance-testing.
Проучвателно изпитване
Винаги, когато изискването липсва, се изисква ранна итерация и екипът за тестване разполага с опитни тестери, когато имаме критично приложение. Нов тестов инженер влезе в екипа, след което отиваме за проучвателно тестване .
За да изпълним проучвателното тестване, първо ще преминем през приложението по всички възможни начини, ще направим тестов документ, ще разберем потока на приложението и след това ще тестваме приложението.
Кликнете върху следната връзка, за да получите пълната информация за проучвателното тестване:
https://www.javatpoint.com/exploratory-testing.
Adhoc тестване
Тестването на приложението на случаен принцип, веднага щом изграждането е в проверената последователност, е известно като Adhoc тестване .
Нарича се още Тестване на маймуни и тестове на горили . При Adhoc тестване ще проверим приложението в противоречие с изискванията на клиента; затова е известен още като отрицателен тест .
Когато крайният потребител използва приложението случайно и той/тя може да открие грешка. Все пак специализираният тестов инженер използва софтуера старателно, така че той/тя може да не идентифицира подобно откриване.
Препраща към следното, за да получите подробна информация за Adhoc тестване:
https://www.javatpoint.com/adhoc-testing.
Тестване на сигурността
Това е съществена част от тестването на софтуера, използвана за определяне на слабостите, рисковете или заплахите в софтуерното приложение.
Извършването на тестове за сигурност ще ни помогне да избегнем неприятните атаки от външни лица и ще гарантираме сигурността на нашите софтуерни приложения.
С други думи, можем да кажем, че тестването за сигурност се използва главно, за да се определи дали данните ще бъдат безопасни и ще издържат работния процес на софтуера.
За да получите пълните подробности относно тестването на сигурността, вижте връзката по-долу: https://www.javatpoint.com/security-testing.
Тестване на глобализацията
Друг вид софтуерно тестване е Тестване на глобализацията. Тестването за глобализация се използва за проверка на разработения софтуер за множество езици или не. Ето, думите глобализация означава осветяване на приложението или софтуера за различни езици.
Тестването за глобализация се използва, за да се гарантира, че приложението ще поддържа множество езици и множество функции.
В настоящите сценарии можем да видим подобрението в няколко технологии, тъй като приложенията са подготвени за глобално използване.
Обърнете се към следната връзка, за да получите пълната информация, свързана с тестването на глобализацията:
https://www.javatpoint.com/globalization-testing.
Заключение
В урока обсъдихме различни видове тестване на софтуер. Но все още има списък с повече от 100 категории тестове. Всеки вид тестване обаче не се използва във всички видове проекти.
Обсъдихме най-често използваните видове тестване на софтуер като тестване на черна кутия, тестване на бяла кутия, функционално тестване, нефункционално тестване, регресионно тестване, Adhoc тестване и др. .
Освен това има алтернативни класификации или процеси, използвани в различни организации, но общата концепция е сходна навсякъде.
Тези типове тестове, процеси и подходи за изпълнение продължават да се променят, когато проектът, изискванията и обхватът се променят.