Phenquestions
Единично тестване
Unit Testing е тестване, извършено на отделна функция, клас или модул независимо от тестване на напълно работещ софтуер. Използвайки рамка за модулно тестване, програмистът може да създаде тестови случаи с вход и очакван изход. Когато имате стотици, хиляди или десетки хиляди единични тестови случаи за голям софтуерен проект гарантира, че всички отделни устройства работят както се очаква, докато продължавате да променяте кода. При смяна на устройство, което има тестови случаи, тестовите случаи за този модул трябва да бъдат проучени и да се определи дали са необходими нови тестови случаи, изходът се е променил или текущите тестови случаи могат да бъдат премахнати като вече неприложими. Създаването на голям обем единични тестове е най-лесният начин да се постигне голямо покритие на тестови случаи за база от софтуерен код, но няма да гарантира, че крайният продукт работи като система, както се очаква.
Функционално тестване
Функционалното тестване е най-често срещаната форма на тестване. Когато хората се позовават на софтуерно тестване без много подробности, те често имат предвид функционално тестване. Функционалното тестване ще провери основните функции на работата на софтуера, както се очаква. Може да бъде написан план за тестване, който да опише всички функционални тестови случаи, които ще бъдат тествани, което съответства на основните характеристики и възможности на софтуера. Основното тестване на функционалността ще бъде „щастлив път ” тестване, което не се опитва да счупи софтуера или да го използва при предизвикателни сценарии. Това трябва да е абсолютният минимум на тестване за всеки софтуерен проект.
Тестване на интеграцията
След модулно тестване и функционално тестване може да има няколко модула или цялата система, която все още не е тествана като цяло. Или може да има компоненти, които са до голяма степен независими, но понякога се използват заедно. Всеки момент, когато компонентите или модулите се тестват независимо, но не като цялостна система, тогава трябва да се извърши тестване за интегриране, за да се провери функцията на компонентите заедно като работеща система според изискванията и очакванията на потребителя.
Стресиране
Помислете за стрес тестване, сякаш тествате космическа совалка или самолет. Какво означава да поставите вашия софтуер или система под „СТРЕС“? Стресът не е нищо повече от интензивно натоварване от определен тип, което е най-вероятно да повреди вашата система. Това може да е подобно на „Тестване на натоварване“ в смисъл да поставите системата си с висока паралелност с много потребители, които имат достъп до системата. Но подчертаването на системата може да се случи и на други вектори. Например, стартиране на фърмуер на хардуерен компонент, когато хардуерът е имал физическо влошаване и работи в влошен режим. Стресът е уникален за всички видове софтуер, а системите и проектирането на стрес тестове трябва да се вземат предвид кои природни или неестествени причини най-вероятно ще стресират вашия софтуер или система.
Тестване на товара
Тестването на натоварване е специфичен тип стрес тестване, както е обсъдено по-горе, при което голям брой едновременни потребителски връзки и достъпи са автоматизирани, за да генерират симулация на ефекта на голям брой автентични потребители, които имат достъп до вашата софтуерна система едновременно. Целта е да разберете колко потребители могат да имат достъп до вашата система едновременно, без вашата софтуерна система да се счупи. Ако вашата система може лесно да се справи с нормалния трафик от 10 000 потребители, какво ще се случи, ако вашият уебсайт или софтуер стане вирусен и получи 1 милион потребители? Дали това неочаквано „ТОВАР“ разбийте вашия уеб сайт или система? Тестването на натоварване ще симулира това, така че се чувствате комфортно с бъдещото увеличение на потребителите, защото знаете, че вашата система може да се справи с увеличеното натоварване.
Тестване на производителността
Хората могат да бъдат напълно разочаровани и отчаяни, когато софтуерът не отговаря на техните изисквания за производителност. Ефективността като цяло означава колко бързо могат да бъдат изпълнени важни функции. Колкото по-сложни и динамични са функциите в дадена система, толкова по-важни и неочевидни става тестването на нейната производителност, нека вземем един основен пример, операционна система Windows или Linux. Операционната система е изключително сложен софтуерен продукт и извършването на тестване на производителността на нейната система може да включва скоростта и времето на функции като Bootup, инсталиране на приложение, търсене на файл, стартиране на изчисления на графичен процесор и / или друг милионите действия, които могат да бъдат извършени. Трябва да се внимава при избора на случаи за тестване на производителността, за да се гарантира, че са тествани важните и е възможно да повредят функционални характеристики.
Тестване на скалируемост
Тестването на вашия лаптоп е добро, но не е достатъчно добро, когато изграждате социална мрежа, имейл система или суперкомпютърен софтуер. Когато вашият софтуер е предназначен да бъде разположен на 1000 сървъра, всички функциониращи в унисон, тогава тестването, което правите локално на една система, няма да разкрие грешките, които се появяват, когато софтуерът е разположен „в мащаб“ на стотици хиляди случаи. В действителност вашето тестване вероятно никога няма да може да се изпълни в пълен мащаб, преди да бъде пуснато в производство, защото би било твърде скъпо и не е практично да се изгради тестова система с 1000 сървъра, струващи милиони долари. Следователно тестването за мащабируемост се извършва на множество сървъри, но обикновено не пълният брой производствени сървъри, за да се опитат да разкрият някои от дефектите, които могат да бъдат открити, тъй като вашите системи се използват в по-голяма инфраструктура.
Тестване на статичен анализ
Статичният анализ е тестване, което се извършва чрез проверка на софтуерния код, без действително да се изпълнява. За да направите статичен анализ, обикновено бихте използвали инструмент, има много, един известен инструмент е Coverity. Статичният анализ е лесен за стартиране преди пускането на вашия софтуер и може да открие много проблеми с качеството във вашия код, които могат да бъдат отстранени, преди да пуснете. Могат да бъдат намерени грешки в паметта, грешки при обработка на типа данни, пренасочване на нулев указател, неинициализирани променливи и много други дефекти. Езици като C и C ++ имат голяма полза от статичния анализ, тъй като езиците предоставят голяма свобода на програмистите в замяна на голяма мощност, но това също може да създаде големи грешки и грешки, които могат да бъдат открити чрез тестване на статичен анализ.
Изпитване на инжектиране на неизправност
Някои състояния на грешки са много трудни за симулиране или задействане, поради което софтуерът може да бъде проектиран за изкуствено инжектиране на проблем или повреда в системата, без естественият дефект. Целта на тестването на инжектиране на неизправности е да се види как софтуерът се справя с тези неочаквани неизправности. Дали той грациозно реагира на ситуацията, срива ли се или води до неочаквани и непредсказуеми проблемни резултати? Да приемем например, че имаме банкова система и има модул за вътрешно прехвърляне на средства от АКАУНТ А в АКАУНТ Б. Тази операция за прехвърляне обаче се извиква само след като системата вече е проверила, че тези акаунти са съществували, преди да извика операцията за прехвърляне. Въпреки че предполагаме, че и двата акаунта съществуват, операцията за прехвърляне има случай на неуспех, при който една цел или източник не съществува, и че може да изведе грешка. Тъй като при нормални обстоятелства никога не получаваме тази грешка поради предварително тестване на входовете, така че за да проверим поведението на системата, когато прехвърлянето се провали поради несъществуващ акаунт, ние инжектираме фалшива грешка в системата, която връща несъществуващ акаунт за трансфер и тествайте как останалата част от системата реагира в този случай. Много е важно кодът за инжектиране на неизправности да е достъпен само в сценарии за тестване и да не бъде пуснат в производство, където може да създаде хаос.
Тестване за превишаване на паметта
Когато използва езици като C или C ++, програмистът има голяма отговорност да адресира директно паметта и това може да доведе до фатални грешки в софтуера, ако се допуснат грешки. Например, ако даден указател е нулев и дереферентиран, софтуерът ще се срине. Ако паметта е разпределена към обект и след това низ се копира върху паметта на обекта, позоваването на обекта може да доведе до срив или дори неуточнено погрешно поведение. Следователно е от решаващо значение да се използва инструмент, за да се опитате да уловите грешките за достъп до паметта в софтуер, който използва езици като C или C ++, които могат да имат тези потенциални проблеми. Инструментите, които могат да направят този тип тестване, включват Valgrind с отворен код или собствени инструменти като PurifyPlus. Тези инструменти могат да спасят деня, когато не е ясно защо софтуерът се срива или се държи неправилно и директно да сочат към местоположението в кода, който има грешката. Страхотно, нали?
Изпитване на гранични случаи
Лесно е да правите грешки в кодирането, когато сте на това, което се нарича граница. Например банкова автоматична касова машина казва, че можете да изтеглите максимум 300 долара. И така, представете си, че кодерът е написал следния код естествено, когато е изградил това изискване:
Ако (amt < 300)startWithdrawl ()
друго
грешка („Можете да изтеглите% s“, amt);
Можете ли да забележите грешката? Потребителят, който се опита да изтегли $ 300, ще получи грешка, тъй като тя не е по-малка от $ 300. Това е грешка. Следователно граничните тестове се извършват по естествен път. След това границите на изискванията гарантират, че от двете страни на границата и границата, софтуерът функционира правилно.
Fuzz тестване
Високоскоростното генериране на входни данни към софтуера може да доведе до възможно най-много възможни входни комбинации, дори ако тези входни комбинации са пълна глупост и никога няма да бъдат предоставени от реален потребител. Този тип тестване може да открие грешки и уязвимости в сигурността, които не са открити по друг начин поради големия обем на входните данни и сценариите, тествани бързо, без ръчно генериране на тестови случаи.
Изследователско тестване
Затворете очи и визуализирайте какво означава думата „Изследване“. Вие наблюдавате и изследвате система, за да разберете как тя наистина функционира. Представете си, че получавате нов стол за бюро по поръчка и той има 28 части в отделни найлонови торбички без инструкции. Трябва да проучите новото си пристигане, за да разберете как то функционира и как е съставено. С този дух можете да станете изследователски изпитател. Няма да имате добре дефиниран план за тестови казуси. Ще изследвате и изследвате вашия софтуер в търсене на неща, които ви карат да кажете прекрасната дума: „ИНТЕРЕСНО!”. След като научите, проучвате допълнително и намирате начини за разбиване на софтуера, за който дизайнерите никога не са се сещали, и след това представяте доклад, който подробно описва многобройни лоши предположения, грешки и рискове в софтуера. Научете повече за това в книгата, наречена „Разгледайте го“.
Изпитване за проникване
В света на софтуерната сигурност тестването за проникване е едно от основните средства за тестване. Всички системи, независимо дали са биологични, физически или софтуерни, имат граници и граници. Тези граници са предназначени да позволят само на конкретни съобщения, хора или компоненти да влязат в системата. По-конкретно, нека разгледаме система за онлайн банкиране, която използва удостоверяване на потребителя за влизане в сайта. Ако сайтът може да бъде хакнат и влязъл в бекенда без подходящо удостоверяване, това би било проникване, което трябва да бъде защитено срещу. Целта на тестовете за проникване е да се използват известни и експериментални техники за заобикаляне на нормалната граница на сигурност на софтуерна система или уебсайт. Тестването за проникване често включва проверка на всички портове, които слушат и опит за влизане в системата чрез отворен порт. Други често срещани техники включват SQL инжектиране или разбиване на парола.
Тестване на регресия
След като имате работещ софтуер, който е разположен в полето, е от решаващо значение да се предотврати въвеждането на грешки във функционалността, която вече работи. Целта на разработката на софтуер е да увеличи способността на вашия продукт, да въведе грешки или да накара старата функционалност да спре да работи, което се нарича РЕГРЕСИЯ. Регресията е грешка или дефект, който е бил въведен, когато преди това способността е работила според очакванията. Нищо не може да разруши репутацията на вашия софтуер или марка по-бързо от въвеждането на грешки в регресията във вашия софтуер и реалните потребители да ги намерят след издаване.
Случаите за регресионно тестване и плановете за тестване трябва да бъдат изградени около основната функционалност, която трябва да продължи да работи, за да гарантира, че потребителите имат добър опит с вашето приложение. Всички основни функции на вашия софтуер, които потребителите очакват да работят по определен начин, трябва да имат тест за регресия, който може да бъде изпълнен, за да се предотврати прекъсването на функционалността в нова версия. Това може да бъде от 50 до 50 000 тестови случая, които покриват основната функционалност на вашия софтуер или приложение.
Тестване на бисекция на изходния код
В софтуера е въведена грешка, но не е очевидно коя версия на изданието е въвела новата грешка. Представете си, че има 50 ангажирания на софтуера от последното известно време, когато софтуерът е работил без грешката, до сега, когато ..
Тестване на локализация
Представете си приложение за времето, което показва текущото и прогнозираното време във вашето местоположение, както и описание на метеорологичните условия. Първата част от теста за локализация е да се гарантира, че правилният език, азбука и символи се показват правилно, в зависимост от геолокацията на потребителя. Приложението в Обединеното кралство трябва да се показва на английски с латински символи; същото приложение в Китай трябва да се показва с китайски символи на китайски език. По-сложни тестове за локализация, по-широкият кръг от хора от различни геолокации ще взаимодейства с приложението.
Тестване на достъпността
Някои от гражданите в нашата общност имат увреждания и следователно може да имат проблеми с използването на създадения софтуер, така че тестването за достъпност се прави, за да се гарантира, че популациите с увреждания все още имат достъп до функционалността на системата. Например, ако приемем, че 1% от населението е далтонист, а нашият софтуерен интерфейс предполага, че потребителите могат да правят разлика между червено и зелено, но тези далтони лица НЕ МОГАТ да кажат разликата. Следователно, добре софтуерният интерфейс ще има допълнителни сигнали извън цвета, за да посочи значението. Други тестове освен тестването на цветна слепота също ще бъдат включени в теста за достъпност на софтуера, като пълна зрителна слепота, глухота и много други сценарии. Един добър софтуерен продукт трябва да бъде достъпен от максимален процент от потенциалните потребители.
Тестване на надстройка
Простите приложения на телефона, операционните системи като Ubuntu, Windows или Linux Mint и софтуерът, който управлява ядрени подводници, се нуждаят от чести надстройки. Самият процес на надстройка може да въведе грешки и дефекти, които не биха съществували при нова инсталация, тъй като състоянието на околната среда е различно и процесът на въвеждане на новия софтуер върху стария може да е въвел грешки. Нека вземем прост пример, имаме лаптоп с Ubuntu 18.04 и искаме да надстроим до Ubuntu 20.04. Това е различен процес на инсталиране на операционната система, отколкото директно почистване на твърдия диск и инсталиране на Ubuntu 20.04. Следователно, след като софтуерът е инсталиран или някоя от неговите производни функции, той може да не работи на 100% според очакванията или по същия начин, както когато софтуерът е прясно инсталиран. И така, първо трябва да обмислим тестването на самото надстройване при много различни случаи и сценарии, за да гарантираме, че надстройката работи до завършване. И тогава, ние също трябва да обмислим тестването на действителната система след надстройка, за да гарантираме, че софтуерът е бил положен и функционира, както се очаква. Не бихме повторили всички тестови случаи на прясно инсталирана система, което би било загуба на време, но ще обмислим внимателно с нашите познания за това какво МОЖЕ да прекъсне по време на надстройка и стратегически да добавим тестови случаи за тези функции.
Тестване на черна кутия и бяла кутия
Черната кутия и бялата кутия са по-малко специфични методологии за тестване и повече видове тестване на категоризации. По същество тестване на черна кутия, което предполага, че тестерът не знае нищо за вътрешната работа на софтуера и изгражда план за тестване и тестови случаи, които просто гледат системата отвън, за да проверят нейната функция. Тестването на бялата кутия се извършва от софтуерни архитекти, които разбират вътрешната работа на софтуерна система и проектират случаите със знание за това какво би могло, би трябвало, и би могло да се счупи. Тестването както на черно, така и на бяло кутия вероятно ще открие различни видове дефекти.
Блогове и статии за тестване на софтуер
Софтуерното тестване е динамично поле, както и много интересни публикации и статии, които актуализират общността относно най-съвременното мислене за тестване на софтуера. Всички ние можем да се възползваме от това знание. Ето пример от интересни статии от различни източници на блогове, които може да искате да следвате:
- 7 съвета, които трябва да следвате преди тестване без изисквания; http: // www.журнали за тестване.com /
- 60 най-добри инструмента за тестване на автоматизацията: Ръководството за краен списък; https: // testguild.com /
- Инструменти за тестване на база данни с отворен код; https: // www.софтуерно тестванемагазин.com /
- Покритието за тестване на 100 процента не е достатъчно; https: // www.stickyminds.com /
- Тестови тестове в Google и как ги смекчаваме; https: // тестване.googleblog.com /
- Какво е тестване на регресия? ; https: // тест.io / блог /
- 27 най-добри разширения за Chrome за разработчици през 2020 г .; https: // www.ламбдатест.com /
- 5 ключови стъпки за тестване на софтуера, които всеки инженер трябва да извърши; https: // techbeacon.com /
Продукти за тестване на софтуер
По-голямата част от ценните задачи за тестване могат да бъдат автоматизирани, така че не трябва да е изненада, че използването на инструменти и продукти за изпълнение на безбройните задачи за осигуряване на качеството на софтуера е добра идея. По-долу ще изброим някои важни и изключително ценни софтуерни инструменти за тестване на софтуер, които можете да проучите и да видите дали те могат да помогнат.
JUnit
За тестване на Java-базиран софтуер, JUnit предоставя изчерпателен тестов пакет за модулно и функционално тестване на кода, който е приятелски настроен към Java средата.
Селен
За тестване на уеб приложения, Selenium предоставя възможност за автоматизиране на взаимодействията с уеб браузъри, включително тестване на съвместимостта на различни браузъри. Това е водеща инфраструктура за тестване за автоматизация на уеб тестове.
Краставица
Управлявана от поведението рамка за тестване позволява на бизнес потребители, продуктови мениджъри и разработчици да обяснят очакваната функционалност на естествен език и след това да определят това поведение в тестови случаи. Това прави по-четливи тестови случаи и ясно картографиране на очакваната функционалност на потребителя.
Пречистете
Намерете изтичане на памет и повреда на паметта по време на изпълнение, като изпълните софтуера си с вградената апаратура Purify Plus, която проследява използването на паметта и посочва грешки в кода, които не е лесно да се намерят без инструменти.
Валгринд
Инструменти с отворен код, които ще изпълнят вашия софтуер и ще ви позволят да взаимодействате с него, като същевременно посочите доклад за грешка при грешки при кодиране като изтичане на памет и повреда. Няма нужда да прекомпилирате или добавяте инструментариум в процеса на компилация, тъй като Valgrind разполага с интелигентност за динамично разбиране на вашия машинен код и безпроблемно инжектиране на инструментариум, за да открие грешки в кодирането и да ви помогне да подобрите кода си.
Покритие
Инструмент за статичен анализ, който ще открие грешки в кодирането във вашия софтуер, преди дори да компилирате и стартирате кода си. Покритието може да намери уязвимости в сигурността, нарушения на конвенциите за кодиране, както и грешки и дефекти, които вашият компилатор няма да намери. Може да се намери мъртъв код, неинициализирани променливи и хиляди други видове дефекти. Жизненоважно е да почистите кода си със статичен анализ, преди да го пуснете в производство.
JMeter
Рамка с отворен код за тестване на производителността, ориентирана към разработчици, базирани на Java, откъдето идва и името в името. Тестването на уебсайтове е един от основните случаи на използване на JMeter в допълнение към тестването на производителността на бази данни, пощенски системи и много други сървърни приложения.
Метасплойт
За тестване на сигурността и проникването, Metasploit е обща рамка с хиляди функции и възможности. Използвайте конзолата за взаимодействие за достъп до предварително кодирани експлойти и се опитайте да проверите сигурността на вашето приложение.
Академични изследвания за тестване на софтуер
- Изследователска група за тестване на Университета в Шефилд
- Лаборатория за проверка и валидиране на софтуера на Университета в Кентъки
- Изследователска група за тестване на софтуер на държавния университет в Северна Дакота
- Тестване на системата Интелигентна лаборатория; Чешки технически университет в Прага
- НАСА: Тестване и изследване на софтуера на Джон Макбрайд (JSTAR)
- Университет Макмастър; Лаборатория за изследване на качеството на софтуера
- Технически университет Онтарио; Лаборатория за изследване на качеството на софтуера
- Тексаският университет @ Далас; STQA
Заключение
Ролята на софтуера в обществото продължава да расте и в същото време софтуерът в света става по-сложен. За да функционира светът, трябва да имаме методи и стратегии за тестване и валидиране на софтуера, който създаваме, като изпълняваме функциите, които той е предназначен да изпълнява. За всяка сложна софтуерна система трябва да има стратегия за тестване и план за тестване, за да продължат да валидират функционалността на софтуера, тъй като те продължават да се подобряват и да осигуряват неговата функция.
