Phenquestions
Testovanie jednotiek
Testovanie jednotiek je testovanie vykonané na samostatnej funkcii, triede alebo module nezávisle od testovania plne funkčného softvéru. Pomocou rámca pre testovanie jednotiek môže programátor vytvárať testovacie prípady so vstupom a očakávaným výstupom. Ak máte k dispozícii stovky, tisíce alebo desaťtisíce testovacích prípadov jednotiek pre veľký softvérový projekt, zabezpečíte, že všetky jednotlivé jednotky budú pracovať podľa očakávania, pretože budete pokračovať v zmene kódu. Pri výmene jednotky, ktorá má testovacie prípady, by sa mali preštudovať testovacie prípady pre daný modul a určiť, či sú potrebné nové testovacie prípady, či sa zmenil výstup alebo či už nie sú aktuálne testovacie prípady odstránené. Vytvorenie veľkého množstva jednotkových testov je najjednoduchší spôsob, ako dosiahnuť vysoké pokrytie testovacích prípadov pre základňu softvérových kódov, ale nezabezpečí, aby konečný produkt fungoval podľa očakávaní ako systém.
Funkčné testovanie
Funkčné testovanie je najbežnejšou formou testovania. Ak ľudia odkazujú na testovanie softvéru bez väčších podrobností, často to znamená funkčné testovanie. Funkčné testovanie skontroluje primárne funkcie softvéru podľa očakávania. Môže byť napísaný plán testov, ktorý by popisoval všetky funkčné testovacie prípady, ktoré budú testované, čo zodpovedá hlavným vlastnostiam a možnostiam softvéru. Testovanie primárnej funkčnosti bude „šťastná cesta “ testovanie, ktoré sa nesnaží softvér rozbiť alebo ho použiť v náročných scenároch. To by malo byť absolútne minimum testovania každého softvérového projektu.
Testovanie integrácie
Po testovaní jednotiek a funkčných testov môže existovať niekoľko modulov alebo celý systém, ktorý ešte nebol testovaný ako celok. Alebo môžu existovať komponenty, ktoré sú do veľkej miery nezávislé, ale občas sa používajú spoločne. Akékoľvek časové komponenty alebo moduly sa testujú nezávisle, ale nie ako celý systém, potom by sa malo vykonať integračné testovanie, aby sa overilo, či komponenty fungujú spoločne ako funkčný systém podľa požiadaviek a očakávaní používateľa.
Stresové testovanie
Myslite na záťažové testovanie, akoby ste testovali raketoplán alebo lietadlo. Čo to znamená dať váš softvér alebo systém do stavu „STRES“? Stres nie je nič iné ako intenzívna záťaž konkrétneho typu, ktorá s najväčšou pravdepodobnosťou pokazí váš systém. Môže to byť podobné ako „Testovanie zaťaženia“ v zmysle zvýšenia súbežnosti vášho systému s prístupom mnohých používateľov do systému. Zdôraznenie systému by sa však mohlo stať aj na iných vektoroch. Napríklad spustenie firmvéru na hardvérovom komponente, keď sa hardvér fyzicky poškodil a pracuje v zhoršenom režime. Stres je jedinečný pre všetky typy softvéru a pri navrhovaní záťažových testov a systémov by sa malo brať do úvahy to, aké prírodné alebo neprirodzené príčiny s najväčšou pravdepodobnosťou váš softvér alebo systém stresujú.
Testovanie záťaže
Zaťažovacie testovanie je špecifický typ záťažového testovania, ako je uvedené vyššie, pri ktorom sa automatizuje veľký počet súbežných pripojení a prístupov používateľov, aby sa generovala simulácia účinku veľkého počtu autentických používateľov, ktorí súčasne pristupujú k vášmu softwarovému systému. Cieľom je zistiť, koľko používateľov môže súčasne pristupovať k vášmu systému bez porušenia softvérového systému. Ak váš systém ľahko zvládne bežnú premávku 10 000 používateľov, čo sa stane, ak sa váš web alebo softvér stane virálnym a získa 1 milión používateľov? Bude toto neočakávané "NALOŽIŤ" rozbite svoj web alebo systém? Testovanie záťaže to bude simulovať, takže vám bude vyhovovať budúce zvýšenie počtu používateľov, pretože viete, že váš systém zvládne zvýšené zaťaženie.
Testovanie výkonu
Ľudia môžu byť úplne frustrovaní a zúfalí, keď softvér nespĺňa ich výkonnostné požiadavky. Výkon vo všeobecnosti znamená, ako rýchlo je možné dokončiť dôležité funkcie. Čím zložitejšie a dynamickejšie sú funkcie v systéme k dispozícii, tým dôležitejšie a zjavnejšie je testovať jeho výkon, vezmime si základný príklad, operačný systém Windows alebo Linux. Operačný systém je veľmi zložitý softvérový produkt a vykonávanie testov výkonu na jeho systéme môže vyžadovať rýchlosť a načasovanie funkcií, ako je napríklad bootovanie, inštalácia aplikácie, hľadanie súboru, spustenie výpočtov na GPU alebo iné milióny akcií, ktoré je možné vykonať. Pri výbere prípadov testovania výkonu je potrebné postupovať opatrne, aby sa zaistilo testovanie dôležitých a pravdepodobných funkčných funkcií testu.
Testovanie škálovateľnosti
Testovanie na vašom notebooku je dobré, ale nie dosť dobré, keď budujete sociálnu sieť, e-mailový systém alebo softvér superpočítača. Ak je váš softvér určený na nasadenie na 1 000 serveroch, všetko funguje naraz, potom miestne testovanie v jednom systéme neodhalí chyby, ktoré sa vyskytnú, keď je softvér nasadený „v mierke“ na státisícoch inštancií. V skutočnosti vaše testovanie pravdepodobne nikdy nebude možné spustiť v plnom rozsahu pred uvedením do výroby, pretože by bolo príliš drahé a nepraktické stavať testovací systém s 1 000 servermi, ktoré stoja milióny dolárov. Testovanie škálovateľnosti sa preto vykonáva na viacerých serveroch, zvyčajne však nie na plnom počte produkčných serverov, aby sa pokúsili odhaliť niektoré chyby, ktoré by sa mohli zistiť, keď sa vaše systémy používajú na väčšej infraštruktúre.
Testovanie statickej analýzy
Statická analýza je testovanie, ktoré sa vykonáva kontrolou softvérového kódu bez jeho skutočného spustenia. Ak chcete urobiť statickú analýzu, všeobecne by ste použili nástroj, existuje veľa, jedným slávnym nástrojom je Coverity. Statická analýza sa dá ľahko spustiť pred vydaním softvéru a vo vašom kóde nájdete veľa problémov s kvalitou, ktoré je možné vyriešiť ešte pred vydaním. Nájdete chyby pamäte, chyby pri manipulácii s dátovými typmi, dereferencie nulového ukazovateľa, neinicializované premenné a mnoho ďalších chýb. Jazyky ako C a C ++ výrazne profitujú zo statickej analýzy, pretože tieto jazyky poskytujú programátorom veľkú slobodu výmenou za veľkú silu. To však môže tiež spôsobiť veľké chyby a chyby, ktoré je možné nájsť pri testovaní statickej analýzy.
Testovanie vstrekovania poruchy
Niektoré chybové stavy je veľmi ťažké simulovať alebo spustiť, preto je možné softvér navrhnúť tak, aby umelo vniesol problém alebo chybu do systému bez toho, aby sa chyba vyskytla prirodzene. Účelom testovania vstrekovania chýb je zistiť, ako softvér zvláda tieto neočakávané chyby. Reaguje ladne na situáciu, havaruje alebo prináša neočakávané a nepredvídateľné problematické výsledky? Povedzme napríklad, že máme bankový systém a existuje modul na interný prevod finančných prostriedkov z ÚČTU A na ÚČET B. Táto operácia prenosu sa však volá až potom, keď systém už pred zavolaním operácie prenosu overil, že tieto účty existujú. Aj keď predpokladáme, že obidva účty skutočne existujú, operácia prenosu má prípad zlyhania, keď jeden cieľový alebo zdrojový účet neexistuje, a že môže spôsobiť chybu. Pretože za normálnych okolností nikdy nedostaneme túto chybu z dôvodu predbežného testovania vstupov, aby sme overili správanie systému pri zlyhaní prenosu z dôvodu neexistujúceho účtu, vložíme do systému falošnú chybu, ktorá vráti neexistujúci účet na prenos a vyskúšajte, ako v takom prípade reaguje zvyšok systému. Je veľmi dôležité, aby bol kód na vloženie chyby k dispozícii iba v testovacích scenároch a nebol uvoľnený do výroby, kde by mohol spôsobiť zmätok.
Testovanie preplnenia pamäte
Pri používaní jazykov ako C alebo C ++ má programátor veľkú zodpovednosť priamo adresovať pamäť. To môže spôsobiť chyby v softvéri, ak dôjde k chybe. Ak je napríklad ukazovateľ nulový a dereferencovaný, softvér zlyhá. Ak je objektu pridelená pamäť a potom sa do pamäťového priestoru objektu skopíruje reťazec, odkaz na objekt môže spôsobiť zlyhanie alebo dokonca nešpecifikované nesprávne správanie. Preto je nevyhnutné použiť nástroj na vyskúšanie chýb prístupu do pamäte v softvéri, ktorý používa jazyky ako C alebo C ++, ktoré by mohli mať tieto potenciálne problémy. Medzi nástroje, ktoré umožňujú tento typ testovania, patrí Open Source Valgrind alebo proprietárne nástroje ako PurifyPlus. Tieto nástroje môžu ušetriť deň, keď nie je jasné, prečo softvér zlyháva alebo sa správajú nesprávne, a priamo ukážu na miesto v kóde, v ktorom je chyba. Úžasné, správne?
Testovanie hraničných prípadov
Je ľahké urobiť chyby v kódovaní, keď sa nachádzate na hranici, ktorej sa hovorí. Napríklad bankomat hovorí, že si môžete vybrať maximálne 300 dolárov. Predstavte si teda, že kódovač pri vytváraní tejto požiadavky napísal tento kód prirodzene:
Ak (pozm < 300)startWithdrawl ()
else
chyba („Môžete vybrať% s“, čiastka);
Vidíte chybu?? Používateľ, ktorý sa pokúsi vybrať 300 dolárov, dostane chybu, pretože nie je menší ako 300 dolárov. Toto je chyba. Preto sa hraničné testovanie vykonáva prirodzene. Hranice požiadaviek potom zaisťujú, aby softvér na oboch stranách hranice aj hranice fungoval správne.
Fuzz testovanie
Vysokorýchlostné generovanie vstupu do softvéru môže vyprodukovať toľko možných kombinácií vstupu, aj keď sú tieto kombinácie vstupu úplný nezmysel a skutočný používateľ by ich nikdy nedodal. Tento typ testovania fuzz dokáže nájsť chyby a chyby zabezpečenia, ktoré sa nenašli inými prostriedkami, kvôli veľkému množstvu vstupov a rýchlo testovaných scenárov bez generovania manuálneho testovacieho prípadu.
Prieskumné testovanie
Zatvorte oči a predstavte si, čo znamená slovo „Preskúmať“. Pozorujete a sondujete systém, aby ste zistili, ako skutočne funguje. Predstavte si, že dostanete novú stolnú stoličku v zásielkovom obchode a ktorá má 28 častí, všetko v samostatných plastových vreciach bez pokynov. Musíte preskúmať svoj nový príchod, aby ste zistili, ako funguje a ako je zostavený. V tomto duchu sa môžete stať prieskumným testerom. Nebudete mať presne stanovený plán testovania testovacích prípadov. Preskúmate a preskúmate svoj softvér a budete hľadať veci, vďaka ktorým budete môcť povedať úžasné slovo: „ZAUJÍMAVÉ!“. Po učení sa budete ďalej skúmať a nájdete spôsoby, ako rozbiť softvér, na ktorý dizajnéri nikdy nepomysleli, a potom vydať správu s podrobnými informáciami o mnohých zlých predpokladoch, chybách a rizikách v softvéri. Viac sa o tom dozviete v knihe s názvom Explore It.
Testovanie prieniku
Vo svete zabezpečenia softvéru je penetračné testovanie jedným z primárnych prostriedkov testovania. Všetky systémy, či už biologické, fyzické alebo softvérové, majú hranice a hranice. Tieto hranice majú umožniť prístup do systému iba konkrétnym správam, osobám alebo komponentom. Presnejšie, zvážme online bankový systém, ktorý na vstup na stránku používa autentifikáciu používateľa. Ak je možné web hacknúť a vstúpiť do backendu bez náležitého overenia, išlo by o penetráciu, ktorú je potrebné chrániť pred. Cieľom penetračného testovania je použiť známe a experimentálne techniky na obídenie normálnej bezpečnostnej hranice softvérového systému alebo webovej stránky. Penetračné testovanie často zahŕňa kontrolu všetkých portov, ktoré počúvajú a pokúšajú sa vstúpiť do systému cez otvorený port. Medzi ďalšie bežné techniky patrí vstrekovanie SQL alebo prelomenie hesla.
Regresné testovanie
Keď máte funkčný softvér, ktorý je nasadený v teréne, je nevyhnutné zabrániť zavádzaniu chýb do funkčnosti, ktorá už fungovala. Účelom vývoja softvéru je zvýšiť kapacitu vášho produktu, zaviesť chyby alebo spôsobiť, že stará funkčnosť prestane fungovať, čo sa nazýva REGRESIA. Regresia je chyba alebo chyba, ktorá bola zavedená, keď predtým funkcia fungovala podľa očakávania. Nič nemôže pokaziť reputáciu vášho softvéru alebo značky rýchlejšie ako zavedenie regresných chýb do vášho softvéru a získanie skutočných používateľov po ich vydaní.
Prípady regresného testovania a plány testov by mali byť postavené na základných funkciách, ktoré musia pokračovať v práci, aby sa zabezpečilo, že používatelia budú mať s vašou aplikáciou dobré skúsenosti. Všetky základné funkcie vášho softvéru, od ktorých používatelia očakávajú, že budú pracovať určitým spôsobom, by mali mať regresný testovací prípad, ktorý je možné vykonať a zabrániť tak narušeniu funkčnosti nového vydania. Môže to byť kdekoľvek od 50 do 50 000 testovacích prípadov, ktoré pokrývajú základné funkcie vášho softvéru alebo aplikácie.
Testovanie rozdelenia zdrojového kódu
V softvéri bola zavedená chyba, ale nie je zrejmé, ktorá verzia vydania priniesla novú chybu. Predstavte si, že od posledného známeho času, kedy softvér pracoval bez chyby, existovalo 50 softvérových záväzkov, až doteraz, keď ..
Testovanie lokalizácie
Predstavte si aplikáciu počasia, ktorá zobrazuje aktuálne a predpokladané počasie vo vašej oblasti a popis poveternostných podmienok. Prvá časť testovania lokalizácie spočíva v zabezpečení správneho zobrazenia správneho jazyka, abecedy a znakov v závislosti od geolokácie používateľa. Aplikácia vo Veľkej Británii by mala byť zobrazená v angličtine so znakmi latinky; rovnaká aplikácia v Číne by sa mala zobrazovať čínskymi znakmi v čínskom jazyku. Keď bude zložitejšie testovanie lokalizácie hotové, bude s aplikáciou komunikovať širšie spektrum ľudí z rôznych geolokácií.
Testovanie prístupnosti
Niektorí občania v našej komunite majú zdravotné postihnutie, a preto môžu mať problém s používaním vytváraného softvéru, preto sa testuje dostupnosť, aby sa zabezpečilo, že populácie so zdravotným postihnutím budú mať naďalej prístup k funkčnosti systému. Napríklad, ak predpokladáme, že 1% populácie je farboslepých a naše softvérové rozhranie predpokladá, že používatelia môžu rozlišovať medzi červenou a zelenou farbou, ale títo farboslepí jedinci NEDÁ rozlíšiť rozdiel. Preto bude mať softvérové rozhranie ďalšie indikátory presahujúce farbu, ktoré naznačujú význam. Do testovania prístupnosti softvéru by mali byť okrem testovania farebnej slepoty zahrnuté aj ďalšie scenáre, napríklad úplná vizuálna slepota, hluchota a mnoho ďalších scenárov. Kvalitný softvérový produkt by mal byť prístupný pre maximálne percento potenciálnych používateľov.
Testovanie inovácie
Jednoduché aplikácie v telefóne, operačné systémy ako Ubuntu, Windows alebo Linux Mint a softvér, ktorý prevádzkuje jadrové ponorky, vyžadujú časté upgrady. Samotný proces inovácie mohol spôsobiť chyby a chyby, ktoré by pri novej inštalácii neexistovali, pretože stav prostredia bol odlišný a proces zavádzania nového softvéru nad pôvodný mohol obsahovať chyby. Zoberme si jednoduchý príklad, máme notebook so systémom Ubuntu 18.04, a chceme inovovať na Ubuntu 20.04. Toto je iný proces inštalácie operačného systému ako priame čistenie pevného disku a inštalácia Ubuntu 20.04. Preto po nainštalovaní softvéru alebo niektorej z jeho odvodených funkcií nemusí pracovať 100% očakávane alebo rovnako, ako keď bol softvér nainštalovaný čerstvo. Najprv by sme teda mali zvážiť testovanie samotnej inovácie v mnohých rôznych prípadoch a scenároch, aby sme zabezpečili dokončenie aktualizácie. Potom musíme tiež zvážiť testovanie skutočného systému po inovácii, aby sme sa uistili, že softvér bol položený a fungoval podľa očakávaní. Neopakovali by sme všetky testovacie prípady čerstvo nainštalovaného systému, čo by bola strata času, ale s našimi znalosťami systému dobre premyslíme, čo by sa mohlo počas aktualizácie rozbiť, a strategicky pridáme testovacie prípady pre tieto funkcie.
Testovanie čiernej a bielej skrinky
Čierna skrinka a biela skrinka sú menej špecifické metodiky testovania a viac typov kategorizácie testovania. V podstate testovanie čiernej skrinky, ktoré predpokladá, že tester nevie nič o vnútornom fungovaní softvéru, a zostaví plán testov a testovacie prípady, ktoré sa iba pozerajú na systém zvonka a overujú jeho funkciu. Testovanie bielej skrinky vykonávajú softvéroví architekti, ktorí rozumejú vnútornej činnosti softvérového systému a navrhujú prípady so znalosťami toho, čo by sa mohlo, malo, malo a pravdepodobne pokazí. Pri testovaní čiernej aj bielej skrinky sa pravdepodobne zistia rôzne typy chýb.
Blogy a články o testovaní softvéru
Testovanie softvéru je dynamické pole a mnoho zaujímavých publikácií a článkov, ktoré aktualizujú komunitu o najmodernejších úvahách o testovaní softvéru. Všetci môžeme ťažiť z týchto poznatkov. Tu je ukážka zaujímavých článkov z rôznych zdrojov blogov, ktoré by ste možno chceli sledovať:
- 7 tipov, ktoré treba dodržať pred testovaním bez požiadaviek; http: // www.testovacie denníky.com /
- 60 najlepších nástrojov na testovanie automatizácie: Sprievodca zoznamom najlepších aplikácií; https: // testguild.com /
- Nástroje na testovanie databázy s otvoreným zdrojom; https: // www.softvérový testovací časopis.com /
- 100-percentné pokrytie testom jednotky nestačí; https: // www.lepkavé mysle.com /
- Šupinaté testy na Googli a ako ich zmierňujeme; https: // testovanie.googleblog.com /
- Čo je regresné testovanie? ; https: // test.io / blog /
- 27 najlepších rozšírení pre Chrome pre vývojárov v roku 2020; https: // www.lambdatest.com /
- 5 kľúčových krokov na testovanie softvéru, ktoré by mal vykonať každý technik; https: // techbeacon.com /
Produkty na testovanie softvéru
Väčšinu hodnotných testovacích úloh je možné automatizovať, takže by nás nemalo prekvapovať, že používanie nástrojov a produktov na vykonávanie nespočetných úloh zabezpečenia kvality softvéru je dobrý nápad. Ďalej uvádzame zoznam dôležitých a veľmi cenných softvérových nástrojov na testovanie softvéru, ktoré môžete preskúmať a zistiť, či vám môžu pomôcť.
JUnit
Na testovanie softvéru založeného na prostredí Java poskytuje JUnit komplexnú sadu testov na jednotkové a funkčné testovanie kódu, ktorý je priateľský k prostrediu Java.
Selén
Na testovanie webových aplikácií poskytuje Selenium schopnosť automatizovať interakcie s webovými prehliadačmi vrátane testovania kompatibility medzi rôznymi prehliadačmi. Toto je popredná testovacia infraštruktúra pre automatizáciu webového testovania.
Uhorka
Rámec testovania založený na správaní umožňuje podnikovým používateľom, produktovým manažérom a vývojárom vysvetliť očakávanú funkčnosť v prirodzenom jazyku a potom toto správanie definovať v testovacích prípadoch. Vďaka tomu sú čitateľnejšie testovacie prípady a jasné priradenie k očakávanej funkcii používateľa.
Očistiť
Vyhľadajte úniky pamäte a poškodenia pamäte za behu spustením softvéru pomocou zabudovaného prístrojového vybavenia Purify Plus, ktoré sleduje využitie pamäte a upozorňuje na chyby v kóde, ktoré bez prístrojového vybavenia nenájdete ľahko.
Valgrind
Open-source nástroje, ktoré vykonajú váš softvér a umožnia vám s ním pracovať a zároveň poukazovať na chybovú správu o chybách kódovania, ako sú úniky pamäte a poškodenia. Nie je potrebné znova kompilovať alebo pridávať prístrojové vybavenie do procesu kompilácie, pretože Valgrind má inteligenciu na dynamické pochopenie vášho strojového kódu a bezproblémové vstrekovanie prístrojového vybavenia, aby našiel chyby v kódovaní a pomohol vám vylepšiť váš kód.
Krytie
Nástroj statickej analýzy, ktorý nájde chyby v kódovaní vášho softvéru ešte predtým, ako svoj kód skompilujete a spustíte. Coverity môže nájsť chyby zabezpečenia, porušenia konvencií kódovania, ako aj chyby a chyby, ktoré váš kompilátor nenájde. Nájdete mŕtvy kód, neinicializované premenné a tisíce ďalších typov chýb. Pred vydaním do výroby je nevyhnutné vyčistiť kód pomocou statickej analýzy.
JMeter
Open-source framework pre testovanie výkonu zameraný na vývojárov založených na prostredí Java, odtiaľ názov J. Testovanie webových stránok je jedným z hlavných prípadov použitia JMeteru okrem testovania výkonu databáz, poštových systémov a mnohých ďalších serverových aplikácií.
Metasploit
Pre zabezpečenie a penetračné testovanie je Metasploit všeobecný rámec s tisíckami funkcií a schopností. Pomocou interakčnej konzoly získate prístup k predkódovaným exploitom a pokúsite sa overiť bezpečnosť svojej aplikácie.
Akademický výskum v oblasti testovania softvéru
- Výskumná skupina pre testovanie na University of Sheffield
- Laboratórium overovania a overovania softvéru University of Kentucky
- Výskumná skupina pre testovanie softvéru na štátnej univerzite v Severnej Dakote
- Inteligentné laboratórium na testovanie systému; České vysoké učení technické v Prahe
- NASA: Testovanie a výskum softvéru Jon McBride (JSTAR)
- McMaster University; Laboratórium pre výskum kvality softvéru
- Ontario Tech University; Laboratórium pre výskum kvality softvéru
- University of Texas @ Dallas; STQA
Záver
Úloha softvéru v spoločnosti neustále rastie a svetový softvér sa zároveň stáva zložitejším. Aby svet fungoval, musíme mať k dispozícii metódy a stratégie na testovanie a validáciu softvéru, ktorý vytvárame vykonávaním funkcií, ktoré má vykonávať. Pre každý komplexný softvérový systém by mala byť zavedená stratégia testovania a plán testovania, aby bolo možné naďalej overovať funkčnosť softvéru, pretože sa neustále zlepšuje a poskytuje svoju funkciu.
