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

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

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

Ръчното тестване е от съществено значение, защото един от софтуерно тестване основите са „100% автоматизация не е възможна“.

Защо имаме нужда от ръчно тестване

Всеки път, когато дадено приложение излезе на пазара и е нестабилно или има грешка или проблеми, или създава проблем, докато крайните потребители го използват.

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

Ако тестовият инженер извършва ръчно тестване, той/тя може да тества приложението от гледна точка на крайния потребител и да се запознае по-добре с продукта, което им помага да напишат правилните тестови случаи на приложението и да дадат бърза обратна връзка за приложението.

Видове ръчно тестване

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

• Тестване на бяла кутия
• Тестване на черна кутия
• Тестване на сивата кутия

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

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

За повече информация относно тестването на бялата кутия вижте връзката по-долу:

https://www.javatpoint.com/white-box-testing

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

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

За повече информация относно тестването на черна кутия вижте връзката по-долу:

https://www.javatpoint.com/black-box-testing

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

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

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

https://www.javatpoint.com/grey-box-testing

Как да извършите ръчно тестване

• Първо, тестерът наблюдава всички документи, свързани със софтуера, за да избере области за тестване.
• Тестерът анализира документите с изисквания, за да покрие всички изисквания, заявени от клиента.
• Тестерът разработва тестовите случаи според документа с изискванията.
• Всички тестови случаи се изпълняват ръчно чрез тестване на черна кутия и тестване на бяла кутия.
• Ако възникнат грешки, екипът за тестване информира екипа за разработка.
• Екипът за разработка поправя грешки и предава софтуера на екипа за тестване за повторен тест.

Процес на изграждане на софтуер

• След като изискването бъде събрано, то ще бъде предоставено на двата различни екипа за разработка и тестване.
• След като получи изискването, съответният разработчик ще започне да пише кода.
• И междувременно тестовият инженер разбира изискването и подготвя необходимите документи, до момента разработчикът може да завърши кода и да го съхранява в Инструмент за контролна версия .
• След това кодът се променя в потребителския интерфейс и тези промени се обработват от отделен екип, който е известен като изградете екип .
• Този екип за изграждане ще вземе кода и ще започне да компилира и компресира кода с помощта на инструмент за изграждане. След като получим някакъв изход, изходът отива в zip файла, който е известен като Изграждане (приложение или софтуер). Всяка компилация ще има някакъв уникален номер като (B001, B002).
• След това тази конкретна компилация ще бъде инсталирана в тестовия сървър. След това тестовият инженер ще получи достъп до този тестов сървър с помощта на тестовия URL адрес и ще започне да тества приложението.
• Ако тестовият инженер открие някаква грешка, той/тя ще бъде докладван на съответния разработчик.
• След това разработчикът ще възпроизведе грешката в тестовия сървър и ще поправи грешката и отново ще съхрани кода в инструмента за контролна версия и той ще инсталира новия актуализиран файл и ще премахне стария файл; този процес продължава, докато получим стабилната компилация.
• След като получим стабилната компилация, тя ще бъде предадена на клиента.

Бележка1

• След като съберем файла от инструмента за контролна версия, ще използваме инструмента за изграждане, за да компилираме кода от език на високо ниво в език на машинно ниво. След компилирането, ако размерът на файла ще се увеличи, ние ще компресираме този конкретен файл и ще го изхвърлим в тестовия сървър.
• Този процес се извършва от Изградете екип , разработчик (ако екипът за изграждане не е там, програмист може да го направи) или тестов проводник (ако екипът за изграждане директно обработва zip файла и инсталира приложението на тестовия сървър и информира тестовия инженер).
• Като цяло, не можем да получим нова компилация за всеки бъг; в противен случай по-голямата част от времето ще бъде загубено само в създаване на компилации.

Бележка 2

Изградете екип

Основната работа на екипа за изграждане е да създаде приложението или компилацията и да преобразува езика от високо ниво в език от ниско ниво.

Изграждане

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

Инструмент за контрол на версията

Това е софтуер или приложение, което се използва за следната цел:

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

Пример за процес на изграждане

Нека видим един пример, за да разберем как да изградим процес на работа в реалните сценарии:

Веднага след като тестовият инженер получи бъга, той ще го изпрати на разработчиците и те се нуждаят от известно време за анализ; след това той/тя само поправя грешката (тестовият инженер не може да даде колекция от грешки).

Разработчикът решава колко бъгове може да коригира според времето си. И тестовият инженер решава коя грешка трябва да бъде поправена първо според техните нужди, защото тестовите инженери не могат да си позволят да спрат тестването.

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

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

Бележка3

Тестови цикъл

Тестовият цикъл е времевата продължителност, дадена на тестовия инженер за тестване на всяка компилация.

Разлики между двете конструкции

Грешките, открити в една компилация и могат да бъдат коригирани във всяка бъдеща компилация, което зависи от изискванията на тестовия инженер. Всяка нова компилация е модифицирана версия на старата и тези модификации могат да бъдат корекции на грешки или добавяне на някои нови функции.

Колко често получавахме новата версия

В началото получавахме седмични компилации, но в последния етап на тестване, когато приложението ставаше стабилно, получавахме новата компилация веднъж на 3 дни, два дни или също всеки ден.

Колко компилации получаваме

Ако вземем предвид една година от продължителността на всеки проект, имаме 22-26 компилации.

Когато получим корекции на грешки

Като цяло разбираме корекциите на грешки само след като тестовият цикъл е завършен или колекцията от грешки е коригирана в една компилация и предаването в следващите компилации.

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

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

Недостатъци на ръчното тестване

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

Инструменти за ръчно тестване

При ръчно тестване, различни типове тестване като единица, интеграция, сигурност, производителност и проследяване на грешки, имаме различни инструменти като Jira, Bugzilla, Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube и др., налични в пазар. Някои от инструментите са с отворен код, а други са комерсиални.

За повече информация относно инструментите за тестване вижте връзката по-долу:

https://www.javatpoint.com/software-testing-tools

Нека ги разберем един по един:

LoadRunner

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

Основната цел на изпълнението на инструмента LoadRunner е бързо да класифицира най-честите източници на проблеми с производителността.

Характеристики на LoadRunner

• Инструментът LoadRunner съдържа n-броя приложения, което намалява времето за разбиране и описание на отчетите.
• Можем да получим изчерпателни доклади от тестове за производителност, като използваме инструмента LoadRunner.
• Това ще намали разходите за тестване на разпределено натоварване и също така ще предложи оперативен инструмент за проследяване на внедряването.

Цитрус

Citrus е инструмент за тестване на интеграция, който е най-често използваната тестова рамка. Написано е в Java програмиране език. Използва се най-вече за заявка и отговор на сървърна и клиентска страна и валидиране на XML JSON файлове.

За да извърши тестването на случаите на използване от край до край, citrus поддържа няколко HTTP, JMS и SOAP протокола.

Характеристики на цитрусите

Следват някои от важните характеристики на инструмента Citrus:

• Използва се за изпращане и получаване на съобщения.
• Citrus се предлага както с отворен код, така и с лиценз на пазара.
• Той предоставя решение с ниска цена.
• Можем да удостоверим базата данни с помощта на инструмента за цитруси.
• Той ще опише последователността от съобщения, ще предложи тестовия план и ще документира тестовото покритие.
• Той създава съобщението и проверява отговорите.

ЗАП

ZAP е скенер за сигурност на уеб приложения с отворен код. Това означава Zed Attack Proxy . Точно като някои други инструменти, това също е написано в Език за програмиране JAVA . Той е най-ефективен Отворете Проекти за сигурност на уеб приложения [OWASP].

Характеристики на ZAP

• Поддържа много операционни системи като Windows, Linux, OS X.
• Има архитектура, базирана на плъгини.
• Той съдържа онлайн пазар, който ни позволява да добавяме нови или актуализирани функции.
• GUI контролният панел на ZAP е лесен за използване.

Монахиня

NUnit е един от най-често използваните инструменти за модулно тестване. Това е инструмент с отворен код и основно произлиза от JUnit .

Беше изцяло написано в Език за програмиране C# и подходящ за всички .Net езици .

С други думи, можем да кажем, че инструментът NUnit е изцяло преработен, за да се превърне в предимството на много езикови качества на .Net. Например:

Възможности, свързани с отражение. Други персонализирани атрибути.

Характеристики на NUnit

• Той позволява твърденията като статичен метод на класа на предимство.
• Той поддържа тестовете, базирани на данни.
• Той поддържа няколко платформи, като .NET core Xamarin mobile, Silverlight и ефективна рамка.
• Способността на NUnit ни помага да изпълняваме тестовете едновременно.
• Той използва конзолен бегач за зареждане и изпълнение на тестовете.

JIRA

Най-често използваният инструмент за проследяване на грешки е JIRA , който е инструмент с отворен код. Използва се за проследяване на грешки, управление на проекти и проследяване на проблеми.

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

Характеристики на JIRA

• Това е инструмент за спестяване на време.
• Jira се използва за проследяване на дефектите и проблемите.
• Използва се за установяване на документационни задачи.
• Jira е много полезен инструмент за проследяване на подобряването на нашата документация.

За да получите пълна информация за инструмента Jira, вижте връзката по-долу: https://www.javatpoint.com/jira-tutorial.

SonarQube

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

Написан е изцяло на езика за програмиране JAVA. Той предлага напълно автоматизирана оценка и интеграция с Ant, Maven, Gradle, MSBuild и инструменти за постоянна интеграция. SonarQube има способността да записва история на показателите и дава графика на еволюцията.

Характеристики на Sonarqube

По-долу са някои от важните характеристики на инструмента SonarQube:

• Поддържа няколко езика за програмиране като C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL и др.
• Съгласно GNU Lesser General Public License, Sonarqube е свободно достъпен.
• SonarQube е партньор на някои важни външни инструменти като GitHub, Active Directory, LDAP и други.
• SonarQube се обедини със средите за разработка на Visual Studio, Eclipse и IntelliJ IDEA поради SonarLint плъгини.

JMeter

JMeter е инструмент с отворен код, който се използва за тестване на производителността на статични и динамични ресурси и динамични уеб приложения.

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

Улеснява потребителите или разработчиците да използват изходния код за разработката на други приложения.

Характеристики на JMeter

По-долу са някои от основните характеристики на JMeter:

• Той е независим от платформата, който приема JVM като Windows, Mac и Linux и др.
• Той поддържа удобен за потребителя GUI, който е интерактивен и ясен.
• Зареждането на теста за производителност в множество типове сървъри е невероятно разширимо.

За повече информация относно JMeter вижте връзката по-долу:

https://www.javatpoint.com/jmeter-tutorial.

С Бъгз

Друг инструмент за проследяване на грешки, използван при ръчно тестване, е С Бъгз .

Той е най-широко използван от много организации за проследяване на различните грешки на приложението.

Bugzilla е инструмент с отворен код, който помага на клиента и клиента да следят дефектите. Bugzilla също се счита за инструмент за управление на тестове, тъй като в него можем лесно да свържем други инструменти за управление на тестови случаи, като ALM, Център за качество и др.

Характеристики на Bugzilla

Bugzilla има някои допълнителни функции, които ни помагат лесно да докладваме грешката:

• Поддържа различни операционни системи като Windows, Linux и Mac.
• С помощта на Bugzilla можем да изброим грешка в няколко формата.
• Потребителските предпочитания могат да измерват известията по имейл.
• Bugzilla има разширени възможности за търсене.

Богомолка

Mantis е уеб базирана система за проследяване на грешки. ManitsBT означава Mantis Bug Tracker . Използва се за проследяване на софтуерните дефекти и се изпълнява на езика за програмиране PHP. Освен това е инструмент с отворен код.

Характеристики на Mantis

Някои от стандартните функции на конкретния инструмент са следните:

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

За да получите повече подробности относно инструментите за проследяване на грешки, вижте следната връзка: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Теси

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

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

Tessy съдържа три основни функции, които са както следва:

• Редактор на тестов интерфейс (TIE)
• Редактор на тестови данни (TDE)
• Работно пространство.

Характеристики на TESSY

Стандартните характеристики на TESSY са следните:

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

За повече информация относно инструментите за тестване на интеграция вижте следната връзка: https://www.javatpoint.com/integration-testing-tools.

Преглед

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

симетрична разлика

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

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

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

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