Ручно тестирање је процес тестирања софтвера у којем се тестни случајеви извршавају ручно без употребе било каквог аутоматизованог алата. Сви тест случајеви које тестер изводи ручно у складу са перспективом крајњег корисника. Он осигурава да ли апликација ради, као што је наведено у документу са захтевима или не. Тестни случајеви су планирани и имплементирани да би се завршило скоро 100 посто софтверске апликације. Извештаји о тестним случајевима се такође генеришу ручно.

Ручно тестирање је један од најосновнијих процеса тестирања јер може да пронађе и видљиве и скривене недостатке софтвера. Разлика између очекиваног излаза и излаза, коју даје софтвер, дефинише се као дефект. Програмер је исправио недостатке и предао га тестеру на поновно тестирање.

Ручно тестирање је обавезно за сваки новоразвијени софтвер пре аутоматског тестирања. Ово тестирање захтева велике напоре и време, али даје гаранцију софтвера без грешака. Ручно тестирање захтева познавање техника ручног тестирања, али не и било каквог аутоматског алата за тестирање.

Ручно тестирање је неопходно јер је један од тестирање софтвера основа је '100% аутоматизација није могућа.'

Зашто нам је потребно ручно тестирање

Кад год се апликација појави на тржишту, а нестабилна је или има грешку или проблеме или ствара проблем док је крајњи корисници користе.

Ако не желимо да се суочимо са оваквим проблемима, потребно је да извршимо једну рунду тестирања да би апликација била слободна и стабилна и испоручила квалитетан производ клијенту, јер ако је апликација без грешака, крајњи корисник лакше ће користити апликацију.

Ако тест инжењер ради ручно тестирање, он/она може да тестира апликацију из перспективе крајњег корисника и да се боље упозна са производом, што им помаже да напишу исправне тестне случајеве апликације и дају брзе повратне информације о апликацији.

Врсте ручног тестирања

Постоје различите методе које се користе за ручно тестирање. Свака техника се користи у складу са својим критеријумима тестирања. Типови ручног тестирања су дати у наставку:

• Тестирање беле кутије
• Тестирање црне кутије
• Граи Бок Тестинг

Тестирање беле кутије

Тестирање беле кутије врши програмер, где проверавају сваки ред кода пре него што га дају Тест инжењеру. Пошто је код програмера видљив током тестирања, због тога је познат и као тестирање беле кутије.

За више информација о тестирању беле кутије, погледајте везу у наставку:

хттпс://ввв.јаватпоинт.цом/вхите-бок-тестинг

Тестирање црне кутије

Тестирање црне кутије врши Тест инжењер, где може проверити функционалност апликације или софтвера према потребама купца/клијента. У овом случају, код није видљив док се врши тестирање; зато је познато као тестирање црне кутије.

За више информација о тестирању црне кутије, погледајте везу у наставку:

хттпс://ввв.јаватпоинт.цом/блацк-бок-тестинг

Тестирање сиве кутије

Тестирање сиве кутије је комбинација тестирања беле кутије и црне кутије. Може га извести особа која је знала и кодирање и тестирање. А ако једна особа обавља белу кутију, као и тестирање црне кутије за апликацију, познато је као тестирање сиве кутије.

Да бисте добили више детаља о тестирању сиве кутије, погледајте везу у наставку:

хттпс://ввв.јаватпоинт.цом/греи-бок-тестинг

Како извршити ручно тестирање

• Прво, тестер посматра све документе који се односе на софтвер, да би одабрао области тестирања.
• Тестер анализира документацију са захтевима како би покрио све захтеве које је навео купац.
• Тестер развија тест случајеве према документу са захтевима.
• Сви тест случајеви се извршавају ручно коришћењем тестирања црне кутије и тестирања беле кутије.
• Ако је дошло до грешака, тим за тестирање обавештава развојни тим.
• Развојни тим поправља грешке и предаје софтвер тиму за тестирање на поновно тестирање.

Процес израде софтвера

• Када се захтев прикупи, он ће обезбедити два различита тима за развој и тестирање.
• Након што добије захтев, заинтересовани програмер ће почети да пише код.
• А у међувремену, инжењер за тестирање разуме захтев и припрема потребне документе, до сада програмер може да доврши код и похрани у Алат Цонтрол Версион .
• Након тога, код се мења у корисничком интерфејсу, а овим променама управља један посебан тим, који је познат као изгради тим .
• Овај тим за изградњу ће узети код и почети да компајлира и компресује код уз помоћ алата за прављење. Када добијемо неки излаз, излаз иде у зип датотеку, која је позната као Буилд (апликација или софтвер). Сваки Буилд ће имати неки јединствени број као што је (Б001, Б002).
• Тада ће ова конкретна верзија бити инсталирана на тест серверу. Након тога, тест инжењер ће приступити овом тест серверу уз помоћ Тест УРЛ-а и започети тестирање апликације.
• Ако тест инжењер открије било какву грешку, он/она ће бити пријављен дотичном програмеру.
• Затим ће програмер репродуковати грешку на тест серверу и поправити грешку и поново сачувати код у алату Цонтрол верзија, и инсталираће нову ажурирану датотеку и уклонити стару датотеку; овај процес се наставља све док не добијемо стабилну верзију.
• Када добијемо стабилну верзију, она ће бити предата купцу.

Напомена1

• Када прикупимо датотеку из алатке Цонтрол верзија, користићемо алатку за прављење да компајлирамо код са језика високог нивоа у језик на нивоу машине. Након компилације, ако ће се величина датотеке повећати, па ћемо ту датотеку компримовати и бачити на тест сервер.
• Овај процес врши Изградите тим , програмер (ако тим за изградњу није ту, програмер то може да уради) или тест провод (ако тим за прављење директно управља зип-ом и инсталира апликацију на тест сервер и обавести тест инжењера).
• Генерално, не можемо добити нову верзију за сваку грешку; у супротном, већина времена ће бити изгубљена само у креирању конструкција.

Ноте 2

Изградите тим

Главни посао тима за прављење је креирање апликације или Буилд и претварање језика високог нивоа у језик ниског нивоа.

Буилд

То је софтвер који се користи за претварање кода у формат апликације. И састоји се од неког скупа функција и исправки грешака које се предају тест инжењеру у сврхе тестирања док не постане стабилан.

Алат за контролу верзије

То је софтвер или апликација која се користи у следеће сврхе:

• У овом алату можемо да сачувамо различите врсте датотека.
• Увек је обезбеђен јер приступамо датотеци из алата користећи исте акредитиве за пријаву.
• Примарни циљ алата је праћење промена учињених за постојеће датотеке.

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

Погледајмо један пример да бисмо разумели како да изградимо рад процеса на стварним сценаријима:

Чим тест инжењер добије грешку, послаће је програмерима и треба им неко време да анализирају; након тога, он/она само поправља грешку (Инжењер за тестирање не може дати колекцију грешака).

Програмер одлучује колико грешака може да поправи у складу са њиховим временом. И тест инжењер одлучује коју грешку прво треба поправити у складу са њиховим потребама јер тест инжењери не могу приуштити да престану са тестирањем.

А тест инжењер који добија пошту, они могу да знају само коју грешку је исправио списак исправки грешака .

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

Напомена3

Тест циклус

Тестни циклус је временско трајање које је тест инжењеру дато да тестира сваки Буилд.

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

Грешке које се налазе у једној верзији и могу се поправити у било којој будућој верзији, што зависи од захтева тест инжењера. Свака нова верзија је модификована верзија старе, а ове модификације могу бити исправке грешака или додавање неких нових функција.

Колико често смо добијали нову верзију

У почетку смо добијали недељне верзије, али у последњој фази тестирања, када је апликација постајала стабилна, добијали смо нову верзију једном у 3 дана, два дана или такође дневно.

Колико градива добијамо

Ако узмемо у обзир једну годину трајања било ког пројекта, добили смо 22-26 градња.

Када добијемо исправке грешака

Генерално, разумемо исправке грешака тек након што је циклус тестирања завршен, или је колекција грешака поправљена у једној верзији, а примопредаја у следећој.

Предности ручног тестирања

• Не захтева знање програмирања док се користи метода црне кутије.
• Користи се за тестирање динамички променљивих ГУИ дизајна.
• Тестер је у интеракцији са софтвером као прави корисник тако да може да открије проблеме употребљивости и корисничког интерфејса.
• Осигурава да је софтвер сто посто без грешака.
• То је исплативо.
• Лако за учење за нове тестере.

Недостаци ручног тестирања

• То захтева велики број људских ресурса.
• То је веома дуготрајно.
• Тестер развија тест случајеве на основу својих вештина и искуства. Нема доказа да су покрили све функције или не.
• Тест случајеви се не могу поново користити. Потребно је развити посебне тестне случајеве за сваки нови софтвер.
• Не пружа тестирање свих аспеката тестирања.
• Пошто два тима раде заједно, понекад је тешко разумети мотиве једни других, то може довести у заблуду процес.

Ручни алати за тестирање

У ручном тестирању, различитим типовима тестирања као што су јединица, интеграција, безбедност, перформансе и праћење грешака, имамо различите алате као што су Јира, Бугзилла, Мантис, Зап, НУнит, Тесси, ЛоадРуннер, Цитрус, СонарКубе, итд. тржиште. Неки од алата су отвореног кода, а неки су комерцијални.

За више информација о алатима за тестирање, погледајте везу у наставку:

хттпс://ввв.јаватпоинт.цом/софтваре-тестинг-тоолс

Хајде да их разумемо једног по једног:

колико 0 у милијарду

ЛоадРуннер

То је најчешће коришћени алати за тестирање перформанси. ЛоадРуннер се углавном користи за подршку тестирању перформанси за широк спектар процедура, броја приступа и окружења апликација.

Главна сврха извршавања алата ЛоадРуннер је да се брзо класификују најчешћи извори проблема са перформансама.

Карактеристике ЛоадРуннер-а

• Алат ЛоадРуннер садржи н-број апликација, што смањује време за разумевање и описивање извештаја.
• Можемо добити детаљне извештаје о тестирању перформанси помоћу алата ЛоадРуннер.
• То ће смањити трошкове тестирања дистрибуираног оптерећења и такође понудити оперативни алат за праћење примене.

Цитрус

Цитрус је алат за тестирање интеграције, који је најчешће коришћени оквир за тестирање. Написано је у Јава програмирање Језик. Углавном се користи за тражење и одговарање на страни сервера и клијента и валидацију КСМЛ ЈСОН датотека.

Да би се извршило тестирање случаја употребе од краја до краја, цитрус подржава неколико ХТТП, ЈМС и СОАП протокола.

Карактеристике цитруса

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

• Користи се за слање и примање порука.
• Цитрус је доступан и као опен-соурце и као лиценциран на тржишту.
• Пружа јефтино решење.
• Ми можемо да аутентификујемо базу података помоћу алата за цитрусе.
• Он ће описати редослед порука, понудити план тестирања и документовати покривеност тестом.
• Креира поруку и проверава одговоре.

ЗАП

ЗАП је скенер безбедности веб апликација отвореног кода. То је за Зед Аттацк Проки . Као и неки други алати, такође је написано у ЈАВА програмски језик . То је најефикасније Отворите Пројекти безбедности веб апликација [ОВАСП].

Карактеристике ЗАП-а

јава спојити стрингове

• Подржава многе оперативне системе као што су Виндовс, Линук, ОС Кс.
• Има архитектуру засновану на додацима.
• Садржи онлајн тржиште које нам омогућава да додамо нове или ажуриране функције.
• ЗАП-ов ГУИ контролни панел је једноставан за коришћење.

Калуђерица

НУнит је један од најчешће коришћених алата за тестирање јединица. То је алатка отвореног кода и првенствено потиче од ЈУнит .

Потпуно је написано у Ц# програмски језик и погодан за све .Нет језици .

Другим речима, можемо рећи да је НУнит алат у потпуности редизајниран како би постао предност многих квалитета .Нет језика. На пример:

Способности у вези са рефлексијом. Остали прилагођени атрибути.

Карактеристике НУнит-а

• Омогућава тврдње као статичку методу класе предности.
• Одржава тестове засноване на подацима.
• Подржава неколико платформи, као што су .НЕТ цоре Ксамарин мобиле, Силверлигхт и ефикасан оквир.
• Способност НУнит-а нам помаже да извршимо тестове истовремено.
• Користи покретач конзоле за учитавање и извршавање тестова.

ЈИРА

Алат за праћење грешака који се најчешће користи је ЈИРА , што је алатка отвореног кода. Користи се за праћење грешака, управљање пројектима и праћење проблема.

У овом алату можемо лако да пратимо све врсте грешака или дефеката у вези са софтвером које су произвели тест инжењери.

Карактеристике ЈИРА

• То је алат који штеди време.
• Јира се користи за праћење недостатака и проблема.
• Користи се за успостављање задатака документације.
• Јира је веома користан алат за праћење побољшања наше документације.

Да бисте добили потпуне информације о Јира алату, погледајте доњу везу: хттпс://ввв.јаватпоинт.цом/јира-туториал.

СонарКубе

Још један алат за тестирање ручног тестирања је СонарКубе, који побољшава наш радни ток континуираним квалитетом кода и безбедношћу кода. Флексибилан је уз употребу додатака.

У потпуности је написан у програмском језику ЈАВА. Нуди потпуно аутоматизовану евалуацију и интеграцију са Ант, Мавен, Градле, МСБуилд и алатима за константну интеграцију. СонарКубе има могућност снимања историје метрика и даје графикон еволуције.

Карактеристике Сонаркубе-а

Испод су неке од значајних карактеристика алата СонарКубе:

• Подржава неколико програмских језика као што су Ц, Ц++, Питхон, ЈАВА, ХТМЛ, ЦСС, ВБ.НЕТ, ПХП, ЦОБОЛ, ПЛ/СКЛ, итд.
• Под ГНУ-овом мањом општом јавном лиценцом, Сонаркубе је бесплатно доступан.
• СонарКубе је повезан са неким важним спољним алатима као што су ГитХуб, Ацтиве Дирецтори, ЛДАП и други.
• СонарКубе се спојио са развојним окружењима Висуал Студио, Ецлипсе и ИнтеллиЈ ИДЕА због СонарЛинт додаци.

ЈМетер

ЈМетер је алатка отвореног кода која се користи за тестирање перформанси и статичких и динамичких ресурса и динамичких веб апликација.

Потпуно је дизајниран на ЈАВА апликацији за учитавање понашања функционалног теста и мерење перформанси апликације.

Олакшава корисницима или програмерима да користе изворни код за развој других апликација.

Карактеристике ЈМетера

Испод су неке од основних карактеристика ЈМетер-а:

• Независан је од платформе, који прихвата ЈВМ лике Виндовс, Мац и Линук, итд.
• Подржава кориснички прилагођен ГУИ, који је интерактиван и једноставан.
• Невероватно је прошириво учитавање теста перформанси на више типова сервера.

За више информација о ЈМетер-у, погледајте везу испод:

хттпс://ввв.јаватпоинт.цом/јметер-туториал.

Са Бугзом

Још један алат за праћење грешака који се користи у ручном тестирању је Са Бугзом .

Многе организације га најчешће користе за праћење различитих грешака у апликацији.

Бугзилла је алатка отвореног кода која помаже купцу и клијенту да прате недостатке. Бугзилла се такође сматра алатом за управљање тестовима јер у овом случају лако можемо да повежемо друге алате за управљање тест случајевима као што су АЛМ, Центар за квалитет, итд.

Карактеристике Бугзиле

Бугзилла има неке додатне функције које нам помажу да лако пријавимо грешку:

• Подржава различите оперативне системе као што су Виндовс, Линук и Мац.
• Уз помоћ Бугзиле можемо навести грешку у неколико формата.
• Корисничка подешавања могу да мере обавештења е-поштом.
• Бугзилла има напредне могућности претраживања.

богомољка

Мантис је систем за праћење грешака заснован на вебу. МанитсБТ је скраћеница за Мантис Буг Трацкер . Користи се за праћење софтверских недостатака и изводи се у ПХП програмском језику. Такође је алат отвореног кода.

Карактеристике Мантис

Неке од стандардних карактеристика одређеног алата су следеће:

• Уз помоћ овог алата, имамо приступ претраживању целог текста.
• Ревизијски трагови промена унесених у проблеме.
• Обезбеђује интеграцију система контроле ревизије.
• Контрола ревизије текстуалних поља и белешки

Да бисте добили више детаља о алатима за праћење грешака, погледајте следећу везу: хттпс://ввв.јаватпоинт.цом/дефецт-ор-буг-трацкинг-тоол .

Тесси

Још један алат за тестирање интеграције је Тесси , који се користи за обављање интеграције и јединичног тестирања за уграђени софтвер. Такође нам помаже да откријемо покривеност кода софтвера или апликације.

Може лако да управља целокупном организацијом тестирања, укључујући пословне потребе, управљање тестирањем, количину покривености и следљивост.

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

• Уређивач интерфејса теста (ТИЕ)
• Уређивач тестних података (ТДЕ)
• Радни простор.

Карактеристике ТЕССИ

Стандардне карактеристике ТЕССИ-а су следеће:

• Он производи извештај теста за резултате извршења теста.
• Подржава различите програмске језике као што су Ц и Ц++.
• Тесси се користи за процену интерфејса функције и описује променљиву коју користи та функција.

За више информација о алатима за тестирање интеграције, погледајте следећу везу: хттпс://ввв.јаватпоинт.цом/интегратион-тестинг-тоолс.

Преглед

У овом чланку смо видели детаљне информације о Ручно тестирање, које укључује дефиницију ручног тестирања, потребу ручног тестирања, врсту ручног тестирања, алате за ручно тестирање, процес ручног тестирања и неке важне предности и недостатке истог.

Коначно, можемо рећи да је то процес у коме тест инжењер треба да буде веома упоран, иновативан и да реагује.

У ручном тестирању, тест инжењер треба да размишља и изводи као тумачење крајњег корисника.

Да би спровео ручно тестирање, тест инжењеру су потребне продуктивне вештине и машта. И морају да размисле о више ситуација или сценарија да би тестирали одређену апликацију.

Иако тренутно можемо тестирати скоро све апликације уз помоћ аутоматског тестирања, и даље је неопходно ручно тестирање јер је оно основа тестирања софтвера.