Меню

Какво е тестване на софтуер? 100+ безплатни ръководства за ръчно тестване

what is software testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Пълно ръководство за тестване на софтуер със 100+ ръководства за ръчно тестване с дефиниция на тестване, типове, методи и подробности за процеса:

Какво е тестване на софтуер?

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

Какво е ръчно тестване?

Ръчното тестване е процес, при който сравнявате поведението на разработена част от кода (софтуер, модул, API, функция и т.н.) с очакваното поведение (Изисквания).

Какво ще научите:

Списък на ръководствата за ръчно тестване на софтуер

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

Тази поредица от уроци ще обогати вашите знания и от своя страна ще подобри вашите умения за тестване.

Практикувайте ръчно тестване от край до край Безплатно обучение по проект на живо:

Урок # 1: Основи на ръчно тестване на софтуер
Урок # 2: Въведение в проекта на живо
Урок № 3: Тестово писане на сценарий
Урок № 4: Напишете документ за план за изпитване от нулата
Урок № 5: Писане на тестови случаи от SRS документ
Урок # 6: Изпълнение на теста
Урок № 7: Проследяване на грешки и тестово изписване
Урок № 8: Курс за тестване на софтуер

Тестване на жизнения цикъл на софтуера:

Урок # 1: STLC

Уеб тестване:

Урок # 1: Тестване на уеб приложения
Урок # 2: Тестване на различни браузъри

Управление на тестови случаи:

как да получите бързи книги безплатно

Урок # 1: Тестови случаи
Урок # 2: Примерен шаблон за тест
Урок № 3: Матрица за проследяване на изискванията (RTM)
Урок № 4: Тестово покритие
Урок № 5: Тестово управление на данни

Тестово управление:

Урок # 1: Тестова стратегия
Урок # 2: Шаблон на тестовия план
Урок № 3: Тестова оценка
Урок № 4: Инструменти за управление на тестове
Урок № 5: Урок за HP ALM
Урок # 6: Джира
Урок № 7: Урок за TestLink

Технически тестове:

Урок # 1: Използвайте тестване на случаи
Урок # 2: Тестване на държавния преход
Урок № 3: Анализ на гранична стойност
Урок № 4: Разделяне на еквивалентност
Урок № 5: Методологии за тестване на софтуер
Урок # 6: Agile Методология

Управление на дефекти:

Урок # 1: Жизнен цикъл на бъгове
Урок # 2: Отчитане на грешки
Урок № 3: Приоритет на дефектите
Урок № 4: Урок за Bugzilla

Функционално тестване

Урок # 1: Единично тестване
Урок # 2: Проверка на здравия разум и дим
Урок № 3: Тестване на регресия
Урок № 4: Тестване на системата
Урок № 5: Изпитване за приемане
Урок # 6: Интеграционно тестване
Урок № 7: Тестване за приемане от потребителя на UAT

Нефункционално тестване:

Урок # 1: Нефункционално тестване
Урок # 2: Тестване на производителността
Урок № 3: Тестване на сигурността
Урок № 4: Тестване на сигурността на уеб приложения
Урок № 5: Тестване на използваемостта
Урок # 6: Тестване на съвместимост
Урок № 7: Тестване на инсталацията
Урок № 8: Тестване на документация

Видове тестване на софтуер:

Урок # 1: Видове тестване
Урок №2 : Тестване на черна кутия
Урок № 3: Тестване на база данни
Урок № 4: Тестване от край до край
Урок № 5: Изследователско тестване
Урок # 6: Допълнително тестване
Урок № 7: Тестване на достъпността
Урок № 8: Отрицателно тестване
Урок № 9: Backend тестване
Урок № 10: Алфа тестване
Урок # 11: Бета тестване
Урок # 12: Алфа срещу бета тестване
Урок № 13: Гама тестване
Урок # 14: ERP тестване
Урок # 15: Статично и динамично тестване
Урок # 16: Adhoc тестване
Урок # 17: Тестване за локализация и интернационализация
Урок # 18: Тестване за автоматизация
Урок № 19: Тестване на бяла кутия

Кариера на тестване на софтуер:

Урок # 1: Избор на кариера за тестване на софтуер
Урок # 2: Как да получите работа за тестване на QA - Пълно ръководство
Урок № 3: Опции за кариера за тестери
Урок № 4: Превключвател за тестване на софтуер, който не е ИТ
Урок № 5: Започнете вашата кариера за ръчно тестване
Урок # 6: Уроци, научени от 10 години на тестване
Урок № 7: Оцеляване и напредък в областта на тестване

Подготовка за интервю:

Урок # 1: Подготовка за възобновяване на качеството
Урок # 2: Въпроси за интервю за ръчно тестване
Урок № 3: Въпроси за интервю за тестване на автоматизация
Урок № 4: Въпроси за QA интервю
Урок № 5: Обработвайте всяко интервю за работа
Урок # 6: Вземете тестваща работа като по-свеж

Тестване на приложение за различен домейн:

Урок №1 : Тестване на банкови приложения
Урок # 2: Тестване на приложения за здравни грижи
Урок № 3: Тестване на платежния шлюз
Урок № 4: Система за пробни точки на продажба (POS)
Урок № 5: Тестване на уебсайтове за електронна търговия

Тестване на QA сертифициране:

Урок # 1: Ръководство за сертифициране на софтуерно тестване
Урок # 2: Ръководство за сертифициране на CSTE
Урок № 3: CSQA Ръководство за сертифициране
Урок № 4: Ръководство за ISTQB
Урок № 5: ISTQB Advanced

Разширени теми за ръчно тестване:

Урок # 1: Цикломатична сложност
Урок # 2: Тестване на миграцията
Урок № 3: Тестване в облак
Урок № 4: ETL тестване
Урок № 5: Показатели за тестване на софтуер
Урок # 6: Уеб услуги

Пригответе се да разгледате първия урок от тази поредица за ръчно тестване !!!

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

Ръчното тестване е процес, при който сравнявате поведението на разработена част от кода (софтуер, модул, API, функция и т.н.) с очакваното поведение (Изисквания).

И как ще разберете какво е очакваното поведение?

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

конвертирате YouTube в wav файл безплатно

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

Понякога това може да е пропуснато изискване (непълно изискване) или имплицитно изискване (нещо, което не се нуждае от отделно споменаване, но трябва да бъде изпълнено) и трябва да тествате и за това.

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

Нека погледнем в дълбочина:

Първо, нека разберем факта - Независимо дали сравнявате тестването на софтуерно приложение или нещо друго (да кажем превозно средство), концепцията остава същата. Подходът, инструментите и приоритетите могат да се различават, но основната цел си остава ЕДНА и съща и е ПРОСТО, т.е. сравняване на действителното поведение с очакваното поведение.

Второ - Тестването е като отношение или мислене, което трябва да идва отвътре. Умения могат да се научат, но вие ще станете успешен тестер само когато имате няколко качества в себе си по подразбиране. Когато казвам, че уменията за тестване могат да се научат, имам предвид целенасочено и формално образование около процеса на тестване на софтуера.

Но какви са качествата на успешния тестер? Можете да прочетете за тях на връзката по-долу:

Прочетете го тук => Качества на високоефективните тестери

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

За тези, които нямат време да разгледат статията, ето резюме:

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

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

Защо се изисква ръчно тестване?

Знаете ли кое е най-хубавото в това да бъдете тестер, и това също ръчен тестер?

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

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

Надявам се, че сте преминали през статията, която препоръчах в предишния раздел (т.е. качествата на високоефективните тестери). Ако отговорът е „да“, тогава ще знаете, че тестването се счита за мисловен процес и колко успешен ще бъдете като изпитател, зависи изцяло от качествата, които притежавате като човек.

Нека видим този прост поток:

  • Правиш нещо ( извършват действия ), докато го наблюдавате с някакво намерение (в сравнение с очакваното). Сега вашето наблюдение умения и дисциплина за изпълнение на нещата се появява тук.
  • Voila! Какво беше това? Забелязахте нещо. Забелязахте го, защото давахте перфектно внимание към детайлите пред теб. Няма да го пуснете, защото сте любопитен . Това не беше във вашия план да се случи нещо неочаквано / странно, вие ще го забележите и ще го разследвате допълнително. Но сега го правите. Можете да го пуснете. Но не бива да го пускате.
  • Щастливи сте, разбрахте причината, стъпките и сценария. Сега вие ще съобщите това правилно и конструктивно на екипа за разработка и другите заинтересовани страни във вашия екип. Може да го направите чрез някакъв инструмент за проследяване на дефекти или устно, но трябва да сте сигурни, че сте комуникирайки го конструктивно .
  • Ами сега! Ами ако го направя по този начин? Какво ще стане, ако въведа правилно цяло число като вход, но с водещи бели интервали? Какво ако? … Какво ако? … Какво ако? Не свършва лесно, не трябва да свършва лесно. Ти ще Представете си много ситуации и сценарии и наистина ще се изкушите да ги изпълните и вие.

Диаграмата, дадена по-долу, представя живота на тестера:

Живот на тестер

Прочетете още веднъж гореспоменатите четири точки, посочени по-горе. Забелязахте ли, че го държа много кратко, но все пак подчерта най-богатата част от това да съм ръчен тестер? И забелязахте ли дръзкото открояване над няколко думи? Това са точно най-важните качества, от които се нуждае ръчен тестер.

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

В SDLC при всяка методология за развитие малко неща винаги остават постоянни. Като тестер ще консумирате изискванията, ще ги конвертирате в Тестови сценарии / Тестови случаи. След това ще изпълните тези тестови случаи или ще ги автоматизирате директно (знам, че няколко компании го правят).

Когато го автоматизирате, фокусът ви е постоянен, което автоматизира написаните стъпки.

Да се ​​върнем към официалната част, т.е.изпълнението на тестовите случаи, написани ръчно.

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

Изображението, дадено по-долу, показва как е опростено писането на Test Case:

Опростено писане на тестови казуси

Попълвам формуляр и приключих с попълването на първото поле. Прекалено ме мързи да отида мишката да измести фокуса към следващото поле. Натиснах клавиша ‘tab’. Приключих и с попълването на следващото и последното поле, сега трябва да натисна бутона Submit, фокусът все още е върху последното поле.

Ами сега, случайно натиснах клавиша ‘Enter’. Нека проверя какво се е случило. ИЛИ има бутон за изпращане, ще щракна два пъти върху него. Не съм доволен. Щраквам го няколко пъти, твърде бързо.

Забеляза ли? Има толкова много възможни действия на потребителя, както замислени, така и непредвидени.

Няма да успеете да напишете всички тестови случаи, които покриват на 100% заявлението, което сте тествали. Това трябва да се случи по изследователски начин.

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

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

Поне от днес няма софтуер, който да мисли като човешки ум, да наблюдава като човешко око, да задава въпроси и да отговаря като човек и след това да извършва предвидени и непредвидени действия. Дори да се случи такова нещо, чий ум, мисли и око ще имитира? Твоя или моя? Ние, хората, също не сме с едно и също право. Всички сме различни. Тогава?

Необходимост от ръчно тестване, когато има автоматизация:

Тестовете за автоматизация имат своя дял от славата в наши дни и ще имат още повече през следващите години, но просто не могат да заменят ръчното QA тестване (прочетете човешко / изследователско тестване).

Сигурно сте чували преди… Не автоматизирате тестването, а автоматизирате проверката ’. Това изречение говори много за това къде стои ръчното QA тестване с автоматизирано тестване. Много големи имена по света са писали и говорили по тази тема, така че няма да наблягам много на това.

Автоматизацията не може да замени тестването на хора, защото:

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

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

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

Отделно бележка, дори ако това наистина се случи след няколкостотин години, картината, която мога да си представя, е тази на страшен свят със сигурност. Възраст на трансформаторите. :)

= >> Препоръчително четене - Най-добрите компании за ръчно тестване на услуги

Как автоматизацията допълва ръчното тестване?

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

През повечето време разполагането на все повече и повече работна сила не помага в дългосрочен план за тази задача. Следователно тестерът (тестов ръководител / архитект / мениджър) трябва да реши внимателно какво да автоматизира и какво все пак трябва да се направи ръчно.

Изключително важно е да бъдат написани много точни тестове / проверки, така че те да могат да бъдат автоматизирани без никакво отклонение от първоначалните очаквания и да могат да се използват, докато регресират продукта като част от „Непрекъснато тестване“.

Забележка: Думата непрекъснато от термина „Непрекъснато тестване“ е подложена на условни и логически извиквания, подобни на другите термини, които използвахме по-горе със същия префикс. Непрекъснато в този контекст означава все по-често, по-бързо от вчера. Макар и в смисъл, много добре може да означава всяка секунда или наносекунда.

Без да имате перфектно съвпадение на човешките тестери и автоматизираните проверки (тестове с точни стъпки, очакван резултат и критерии за изход от споменатия тест са документирани), постигането на непрекъснато тестване е много трудно и това от своя страна ще направи непрекъсната интеграция, непрекъсната доставка и непрекъснато внедряване по-трудно.

Умишлено използвах термина критерии за излизане от тест по-горе. Нашите автоматични костюми вече не могат да бъдат подобни на традиционните. Трябва да се уверим, че ако се провалят, трябва да се провалят бързо. И за да ги накарат да се провалят бързо, критериите за изход също трябва да бъдат автоматизирани.

Пример:

Да кажем, че има дефект на блокер, при който не мога да вляза във Facebook.

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

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

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

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

Заключение

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

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

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

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

най-добрият Google Chrome хром блокиращ прозорец

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

Препоръчително четене

^