Posted in: Základy PowerShellu

Funkce v PowerShellu

Dnes po dlouhé době opět píši něco pro ty, kteří chtějí s PowerShellem začínat a již nějak zvládli základní syntaxi. Pro dnešní práci budeme potřebovat nějaký nástroj k psaní skriptů, viz článek.

Jak jsem se již určitě zmínil v některém předešlém článku, skript je posloupnost příkazů, které se vykonají v daném pořadí. Skript může obsahovat, stejně jako program v některém programovacím jazyce, cykly, podmínky a další řídící příkazy, které vedou na opakování nějakého bloku, nebo naopak přeskočení nějakého bloku kódu. Stejně jako v programování, i při psaní skriptů, můžeme potřebovat opakovat nějaký blok, kus kódu, na různých místech skriptu. Prvním nápadem může být, prostě daný blok kódu zkopírovat a vložit jej na požadovaná místa. Toto je nevýhodné, protože se zkopírovaný blok špatně opravuje, rozšiřuje apod. Proto máme lepší řešení, to jsou funkce, které si umíme volat.

Jmenná konvence

Když si vzpomenete na základní syntaxi PowerShellu, příkazy mají základní podobu:
sloveso-PodstatnéJméno
Tento formát pojmenování je potřeba dodržet i u našich funkcí. Mnohé z vás by mohlo napadnou použít vlastní kombinaci jako například:
Vypis-PCinfo
sice syntakticky vyhovíme, ale není to zcela správné. PowerShell definuje rovněž sadu sloves, která máme využívat a uživatelé jazyka je očekávají a očekávají, že budou mít daný význam. Seznam podporovaných sloves vrátí příkaz:

Get-Verb | Sort-Object -Property Verb

Výstup této funkce rovněž uvádím v článku o syntaxi.

Obecná syntaxe

function Sloveso-PodstatneJmeno
{
    #vlastní kód (tělo) funkce
}

Příklad:

function Get-WinInfo
{
    cls
    Write-Host "Základní informace o počítači"
    Write-Host ""
    $info = Get-ComputerInfo | select WindowsProductName, WindowsCurrentVersion, CsModel, CsName
    Write-Host "Název OS      :" $info.WindowsProductName
    Write-Host "Verze jádra OS:" $info.WindowsCurrentVersion
    Write-Host "Model zařízení:" $info.CsModel
    Write-Host "Název zařízení:" $info.CsName
}

Funkci spustíme tak, že napíšeme její jméno, tedy pro náš příklad by volání vypadalo:

Get-WinInfo

Výše uvedená je nejsprostější verze, samozřejmě i základní funkce může mít parametry, případně vracet hodnoty.

Funkce s parametrem

Výše popsaný základ je dobrý, ale pořád se jedná o poměrně hloupé funkce. Výše popsaná syntaxe slouží k deduplikaci kódu a umí modifikovat globální proměnné, vypisovat na obrazovku, komunikovat s uživatelem atd. Bohužel nemůžeme takto definované funkci předat hodnoty ke zpracovaní. Pojďme se podívat na to, jak tento problém řešit.

Obecná syntaxe:

function Sloveso-PodstatneJmeno
{
     param(
       $NázevParametru,
       $NázevDruhéhoVolitelnéhoParametru
       )
     #vlastní kód (tělo) funkce
}

Čárkou se oddělují jednotlivé parametry, tudíž se uvádí pouze tam, kde za parametrem následuje další parametr. Pojďme si uvést příklad funkce s jedním parametrem.

function Get-OSInfo { 
    param (
        $ComputerName
    ) 
    Get-WmiObject -ComputerName $ComputerName -Class Win32_OperatingSystem | select Caption, Version, SystemDrive | Format-Table 
}

Nyní je na čase si ukázat, jak tuto funkci volat. Obecně voláme funkci v podobě:

Sloveso-PodstatneJmeno -NázevParametru hodnota -NázevDruhéhoVolitelnéhoParametru hodnota

Pojďme si to zkonkrétnit na našem příkladu s funkcí Get-OSInfo pro lokální počítač:

Get-OSInfo -ComputerName localhost

Toto vše je krásné, ale občas bychom potřebovali, aby vstup, který nám dává parametr, byl určitého datového typu, například číslo. Pojďme si na příkladu jednoduché kalkulační funkce ukázat, jak určit datový typ, který parametr bude akceptovat.

function Get-Vysledek { 
    param (
        [double]$cislo1,
        [double]$cislo2,
        [switch]$soucet,
        [switch]$soucin,
        [switch]$rozdil,
        [switch]$podil
    ) 
    if($soucet)
    {
        $vysledek = $cislo1 + $cislo2
        Write-Host "Soucet je:" $vysledek
    }
    if($rozdil)
    {
        $vysledek = $cislo1 - $cislo2
        Write-Host "Soucet je:" $vysledek
    }
    if($soucin)
    {
        $vysledek = $cislo1 * $cislo2
        Write-Host "Soucet je:" $vysledek
    }
    if($podil)
    {
        if($cislo2 -gt 0)
        {
            $vysledek = $cislo1 / $cislo2
            Write-Host "Soucet je:" $vysledek
        }
        else
        {
            Write-Host "Nulou nelze dělit"
        }
    }
}

Datový typ, kterého musí daný parametr nabývat, určíme tak, že název datového typu uvedeme do hranatých závorek před požadovaný parametr. Jedinou výjimkou, která funguje pouze u parametrů, nelze ji uplatnit na proměnné v jiných částí kódu je „datový typ“ switch. Pokud je nějaký parametr typu switch, pak daný parametr nabyde hodnoty True (logické jedničky) tím, že dojde k uvedení daného parametru při volání procedury. Úplné informace o datových typech jsou v dokumentaci. Někdy příště, se na vybrané datové typy podíváme. Příklad volání naší ukázkové funkce Get-Vysledek:

Get-Vysledek -cislo1 6.6 -cislo2 3 -podil

Návratová hodnota

Od PowerShell verze 5 nám funkce může vrátit návratovou hodnotu, stejně jako je tomu v běžných programovacích jazycích. Na rozdíl do programovacích jazyků ovšem PowerShell nevrací hodnotu, ale výraz. Na rozdíl od programovacích jazyků u funkce nedefinujeme datový typ návratové hodnoty. Stejně jako v případě běžných programovacích jazyků máme k dispozici příkaz return, jehož syntax je jednoduchá:

return vyraz

Pojďme si to ukázat na příkladu převzatém z dokumentace a lehce upraveném.

function Get-Kalkuace {
    param ($hodnota)

    $hodnota ="Prosím vyčkejte, počítám...`n" #znak `n je zalomení řádku
    $hodnota += 73
    return $hodnota
}

Takovouto funkci lze volat napřímo, nebo její výstup, který vrací příkaz return přiřadit do proměnné. Pojďme si ukázat verzi, kdy hodnotu navrácenou funkcí (v mé modifikaci strinng) přiřadíme do proměnné, kterou rovnou vypíšeme:

Write-Host ($a = Get-Kalkuace 14)

Závěr

Toto je vše z dnešního úvodu do funkcí. Funkce toho umí dalece více, ale o tom až někdy později u tzv. pokročilých funkcí. Funkce jsou klíčovou součástí jazyka PowerShell, protože moduly jazyka PowerShell vždy funkce obsahují a uživatel modulu volá právě funkce v něm obsažené.

Posted in: Vývoj počítačů, Windows 10, Windows 11, Windows 8 a 8.1

Základy zabezpečení domácí sítě

Předvánoční čas bohužel je nejnáročnější na kybernetickou bezpečnost domácností. Shánění dárků, charity, posílání přání a balíků vede k tomu, že jsme méně opatrní vůči emailům vydávajícím se za přepravce, nebo známé eshopy. Pojďme se podívat na to, jak si nastavit domácí síť tak, abychom minimalizovaly dopady.

Nastavení routeru

Router (lidově většinou nějaká Wifina) je základem každé domácí sítě. S tímto zařízením stojí a padá celá domácí síť. Pojďme se podívat na to, co bychom potřebovali na daném zařízení nastavit, nebo zkontrolovat.

  1. Aktualizace – musíme mít vždy nejnovější verze firmware a bezpečnostních aktualizací
  2. Vypnutí vzdálené správy – nepovolit vzdálené nastavení routeru
  3. Bezpečné přihlašování – silné heslo a definovaná 2 konkrétní MAC adresy (2 zařízení), které smí do nastavení přistoupit
  4. Silné zabezpečení Wi-Fi – používat nejnovější standardy zabezpečení Wi-Fi sítě (co jde, aby to všechna naše zařízení uměla)
  5. Silné heslo k Wi-Fi síti
  6. Samostatná síť pro hosty – naše přítele a členy rodiny, kteří v naší domácnosti nežijí, nepouštíme do vlastní sítě
  7. Omezení zařízení, která se mohou připojit k Wi-Fi – ideální je zadat MAC adresy zařízení, která se mohou správnými údaji přihlásit
  8. Blokování portů – doporučuji nechat dostupné jako cílové porty jen: 443, 587, 993, 995, všechny ostatní porty zakázat v celé síti
  9. Směrem do internetu doporučuji nevystavovat nic
  10. Veškeré DNS servery nastavit na hodnotu: 1.1.1.2 (cloudflare secure DNS) a 185.228.169.9 (Clean browsing secure dns)

Nastavení počítače

I když bude domácí Wi-Fi dobře nastavená, cesta nekončí. I počítač se musí dále zkontrolovat a případně nastavit.

  1. DNS v OS musíme nastavit stejně, jako jsme to udělali u routeru, tedy na 1.1.1.2 a 185.228.169.9. Pro IPv6 si najděte odpovídající konfiguraci, nebo IPv6 úplně zakažte.
  2. Mějte kvalitní bezpečnostní SW, Bitdefender (BitDefender pro domácnost (it-market.cz)), Eset (Eset Antivirus | Antivirové programy ESET NOD32 | Alza.cz) nebo jiný kvalitní placený bezpečnostní SW
  3. Nastavit DNS pomocí DOH ve Windows 11: Jak nastavit DNS-over-HTTPS ve Windows 11? (instaluj.cz) adresa DNS serveru: https://security.cloudflare-dns.com/dns-query
  4. Nastavit si DNS pomocí DOH ve webový prohlížeči: DNS přes HTTPS – Spajk.cz na adresu: https://security.cloudflare-dns.com/dns-query
  5. Instalovat každý měsíc všechny aktualizace Windows
  6. Instalovat každý měsíc všechny aktualizace všech programů

Nastavení telefonů

Stejně jako v případě počítače je potřeba nastavit i všechny telefony. Největší problém notebooků a telefonů je to, že danou domácí síť opouští.

  1. Instalovat všechny dostupné aktualizace telefonu i veškerých aplikací
  2. Nainstalovat si kvalitní placený bezpečnostním SW
  3. Nastavením bezpečných DNS pro Wi-Fi i mobilní data

Práce s emailem a sociálními sítěmi

Další část bezpečnosti jsou naše uživatelské návyky. Pojďme se podívat na to, co a jak bychom měli dělat k tomu, abychom minimalizovali riziko problému.

  1. E-shop ani dopravce nás nebude kontaktovat prostřednictvím sociální sítě
  2. U všech emailů validujeme skutečného odesílatele – v Outlooku stačí najet myší na odesílatele a neklikat, po chvíli se otevře skutečná adresa odesílatele
  3. Doporučuji instalovat analyzátor hlaviček: Find the right app | Microsoft AppSource
  4. Veškeré odkazy NEOTEVÍRAT a nejdříve analyzovat – stačí zkopírovat do VirusTotal – Home, nechat analyzovat a v záložce Detail ověřit, že adresa vede do firmy, kam opravdu chceme
  5. Neznámé emaily neotevírat!

Mobilní zařízení

Mobilní zařízení opouští naší domácí síť, jde o telefony, notebooky apod. Pojďme se podívat na to, co dělat, abychom minimalizovali riziko.

  1. NEPŘIPOJOVAT SE k veřejným sítím – Když už musíme, zajistit, že po síti budeme otevírat jen jízdní řády, mapy nebo jiný zdroj obecných informací a vše ostatní nebude provádět datové přenosy ani na pozadí
  2. I mobilní data využívat obezřetně – jde o bezpečnější variantu, nežli využívání veřejné Wi-Fi, ale i tak je vhodné minimalizovat potenciálně citlivý provoz
  3. Otevírat jen důvěryhodné weby, které dobře známe
  4. Minimalizovat datový provoz
  5. NEOTEVÍRAT odkazy ze SMS, chat a dalších informačních kanálů
  6. Zásilky sledovat výhradně pomocí čísla zásilky a oficiálního webu nebo oficiální aplikace
  7. NEOTEVÍRAT přílohy a odkazy v emailech
  8. Využívat pro přístup k internetu VPN od poskytovatele našeho bezpečnostního SW

E-shopy

Před objednáním, nebo zadáním přihlašovacích údajů, je potřeba si ověřit:

  1. Že jsme skutečně na eshopu, kde chceme být (kontrola URL adresy pomocí Whois nebo virustotal a https certifikátu).
  2. Že se eshop se nenachází na seznamu rizikových od ČOI: Rizikové e-shopy – COI
  3. Ověřit si obchodníka v rejstříku dle IČO: ARES – Ekonomické subjekty (mfcr.cz)
  4. Platit zásilky na dobírku, máte jistotu, že nepřijdete o peníze, když by se jednalo o podvod
  5. Neuvádět informace o platební kartě ani číslo účtu
Posted in: Vývoj počítačů

SW nástroje pro podporu testování

Fáze testování

  • Správa požadavků
  • Správa testovacích případů
  • Exekuce funkčních testů
  • Exekuce zátěžových testů
  • Bugtracking
  • Reporting

HP Quality Center

  • Pokrývá celý proces testování
  • Je řešen jako web aplikace včetně administračního modulu
  • Při prvním spuštění na klientském PC jsou nutná práva admina, z důvodu instalace ovládacích komponent
  • Má otevřené API rozhraní
  • Model požadavků je řešen adresářovou strukturou se stromovým zobrazením
  • Možnost výběru ze tří pohledů
  • Analytický pohled: přehled o stavu pokrytí požadavků testy a o stavu testování vzhledem k požadavkům
  • Stromový pohled
  • Tabulkový pohled
  • Test resources je modul globální repozitory pro testovací případy; ukládá parametry testů formou tabulek i jednotlivých parametrů
  • Modul test plan: slouží k uložení a správě entit spojených s testováním možnost získání statistik o průběhu příprav testů i testování
  • Test lab: sestavuje z testů sady, umožňuje kombinovat manuální a automatizované testy; nastavuje návaznosti a podmínky zpuštění testů; obsahuje hp sprintner který automatizuje manuální testy;
  • Defect: slouží pro evidenci a zprávu identifikovaných neshod; obsahuje vyhledávač a filtr atributů dle parametrů evidovaných u neshod; případě změny dává e-mailem notifikaci a uchovává historii všech změn

HP Quicktest Professional

  • Je nástrojem pro automatizované testy
  • Aktivity se zařazují pomocí kontextových menu
  • Běh skriptu je řízen MS Excel tabulkou
  • Pomocí basic je možné doprogramovat problémová místa skriptu

HP Byznys Availability Center

  • Slouží pro monitoring IT provozů
  • Disponuje pasivním a aktivním monitoringem
  • Pasivní monitoring sleduje chování prostřednictvím atributů získaných od OS
  • Aktivní monitoring sleduje systém z ohledu koncového uživatele; provádí se buď skriptem, nebo sledováním komunikace na daném prvku sítě

Pasivní monitoring

  • Obstarává aplikace SiteScope
  • Agentový přístup: instalace fyzické sondy na aplikační server a jeho konfigurace pro monitoring
  • Bezagentový přístup: připojí se k serveru pomocí jména a hesla a využívá standartní nástroje OS

Aktivní monitoring

  • Spouštění připraveného testovacího skriptu v daném časovém intervalu, kdy skript ověřuje průchodnost dotazu či odpovědi
  • Instalace agenta na PC koncového uživatele a sledování konkrétních činností
  • Odposlech síťové komunikace před aplikačním nebo web serverem

Hp loadrunner

  • Slouží pro zátěžové testování

Test management a další podpůrné nástroje

  • Ke všem nástrojům existují i free varianty
  • Free nástroje se užívají hlavně na malých projektech
  • Správu požadavků na testování mají: Quality Center, SilkCentral, Rational, JIRA, Vienna, TFS
  • TFS je nadstavbou visual studia pro správu testů

Bugtracking

  • Je nejrozšířenějším podprocesem testování
  • Možnost užití free nástroje mantis, který umožňuje práci s přílohami, má rychlou a jednoduchou instalaci

SilkCentral Test Manager

  • Je řešen formou klient server a ovládáním přes webové rozhraní
  • Vyniká ofline nástroji pro manuální tetování
  • Umožňuje dynamickou alokaci HW
  • Má flexibilní licenční model

Rational Quality manager

  • Je druhý nejrozšířenější nástroj v ČR
  • Vestavěné nástroje metrik na návratnost investic známé jako ROI
  • Implementováno RBT
  • Funkce vyhledávající duplicity v seznamu defektů

JIRA

  • Je snadno rozšiřitelný pomocí plugin modelů
  • Má otevřený zdrojový kód
  • Vzdálené rozhraní SOAP usnadňující integraci

Mantis

  • Pokrývá pouze bugtracking
  • Je free
  • Umožňuje práci s více projekty v rámci jedné instalace
  • Integrace do prostředí zákazníka pomocí SOAP
  • Plně podporuje technologie mobilních telefonů

Bugzila

  • Je rozšířena především u vývoje web aplikací
  • Slouží k bugtrackingu
  • Umožňuje provoz na https komunikaci
  • Umožňuje fulltextové vyhledávání
  • Customizace pomocí šablon
  • Umožňuje přidělení práv jednotlivým skupinám uživatelů

Vienna

  • Je jak free tak placená
  • Freeware je pouze v desktop edici
  • Generuje reporty do MS Word
  • Leze exportovat i importovat celé projekty
  • Generuje automatické popisy defektů formou přílohy
  • Export projektu do MS Excel
  • Integrace s MS Sharepoint

Request Tracker

  • Kromě bugtrackingu je užíván pro help desk
  • Rozhraní je uzpůsobeno i pro práci s mobilními telefony
  • Dobře zmáknutý reporting
  • Oboustranná interakce pomocí e-mailu, odpovědí na notifikaci je možné aktualizovat databázi

TFS

  • Pokryje celý životní cyklus testování
  • Dobrá integrace do MS Office
  • Je možné verzovat scénáře
  • Reporting probíhá pomocí SQL
  • Web konzole
  • Podporuje i vývoj
  • Podpora automatizovaného testování
  • Umožňuje virtualizované testování
Posted in: Vývoj počítačů

Test analýza

  • Zajistí efektivní vedení testů včetně určení jejich rozsahu
  • Definuje cíle projektu a požadavky na testování
  • Identifikuje a omezuje rizika plynoucí z neotestování některých fází
  • Napomáhá kontrole nad celým projektem
  • Zkoumá i potřebné zdroje jak technické, tak lidské
  • Posuzuje realizovatelnost akceptačních kritérií

Test analytik

  • Vychází z uživatelských požadavků na základě use cases
  • Use cases jsou namapovány IT analytikem
  • Určuje nejvýhodnější a nejefektivnější způsob testování a typy užitých testů
  • Oblasti, o kterých rozhodne netestovat, ještě vyhodnotí z pohledu projektových rizik
  • Provádí revizi analytické dokumentace proti byznys požadavkům
  • Vytváří dokument plán testů

Test designer

  • Na základě informací z detailního návrhu a vybraných požadavků na testování určí, jak bude testovací případy připravovat, za po jednotlivých funkčnostech nebo po byznys transakcích
  • Spolupracuje na identifikaci rizik pro netestované oblasti
  • Definuje požadavky na testovací prostředí
  • Určuje testovatelnost a náročnost provedení testů

Test implementer

  • Skládá testy do testovacích sad
  • Testovací sady skládá do posloupnosti navazujících funkčností
  • Testovací sady je též možno skládat dle schopností a oblastních znalostí jednotlivých testerů
  • Dále specifikuje HW požadavky a SW požadavky na testovací prostředí a koordinuje jeho přípravu

Procesy test analýzy

Mise

  • Definuje cíl a účel testování
  • Je za ni odpovědný test manažer

Strategie

  • Určuje způsob provedení testování i v závislosti na čase
  • Určuje jednotlivé typy testů pro daná stádia testů
  • Je prací test analytika a test designera
  • Rozhodnutí se zapisují do plánu testů
  • V závislosti na zvoleném typu testu se řeší výběr testovacího nástroje
  • Zabývá se součinností a kompetencí jednotlivých rolí
  • Určuje způsob vyhodnocení testů v závislosti na předmětu a cíli testování

Popis strategie

  • Přístup k testování (úrovně, typy, forma)
  • Role, kompetence, procesy
  • Akceptační kritéria a proces akceptace

Plán testovacích kol (iterací)

  • Zařazení testovacích sad do testovacích kol
  • Odhady na náročnost testů (upřesnění potřeby zdrojů)
  • Rizika neprovedení testů
  • Určení hlavních milníků testování

Vstupy pro test analýzu

  • V praxi často neúplné
  • U starších aplikací musí stačit uživatelská příručka a aplikace samotná
  • Čím více chybí podkladů, tím je nutná složitější spolupráce se zadavateli

Funkční dokumentace

  • Požadavky
  • IT solution
  • Use Case model, funkční specifikace
  • Business zadání

Technická dokumentace

  • Design
  • Architektura systému
  • Detailní návrh, algoritmy
  • Datový model

Změnové řízení a jeho dopady

Akceptační kritéria ze smlouvy

Postup test analýzy

  1. Definice požadavků a jejich navázání na Use Cases
  2. Definice scénářů a jejich přiřazení k požadavkům na testování
  3. Provázáním testovacích požadavků na US nebo BU požadavky a vlastní testovací případy získáme přehled o jejich pokrytí testy a stavu testování v daném čase
  • Červené: artefakty akviziční části projektu
  • Modrá projektové fáze projekce
  • Zeleně projektová fáze konstrukce
  • Žlutě fáze provedení testů
  • Trarovatelnost dokumentace usnadňuje zpracování změn schválených změnovým řízením do navrženého řešení => snížení pracnosti
  • Trasovatelnost umožňuje určit v jednotlivých fázích projektu připravenost testovací dokumentace pomocí pokrytí požadavků na testování již dokončenými testy a míru otestovatelnosti v libovolném čase

Test target

Práce s definicí požadavků na testování

  • Vybere se příslušná funkční oblast
  • Přidají se k vybrané oblasti všechny požadované funkčnosti využívané ze stromové struktury požadavků
  • Navázání na požadavky na SW
  • Pro každý test target se určí úroveň a typ testu

Typy testů

  • Rozdělení testů dle zaměření
  • Rozlišení dle koncepce FURPS
  • Rozhodnutí, které oblasti rizik budou pokryty

Test case

  • Musí obsahovat veškeré náležitosti týkající se provádění a nastavení samotného testu
  • Nutnost provázání s příslušným požadavkem na testování
  • Umožňuje podrobněji určit pracnost testu a rozdíly proti předpokladu řešit s vedoucím projektu
  • Pokud dojde k navýšení potřeby času, tak se řeší priorizací testů, nebo oddálením termínu dodání systému
  • Musí být srozumitelný

Popis případu

  • Popis testu
  • Podmínky před a po spuštění
  • Testovací data
  • Požadavky na prostředí
  • Očekávané výsledky
  • Kontrolní body, metriky
  • Odkaz na test target

Řízení testů

  • Používá priorit, rizika neprovedení/selhání testu
  • Odhad náročnosti testu

Tvorba testovacích kroků

  • Patří do fáze přípravy testů
  • Každý krok testu obsahuje vstupní data a očekávaný výstup
  • Definovány z USE Case a podrobnosti z funkčního protokolu
  • Podrobnost zpracování musí odpovídat znalostem testerů
  • Důležité je psát jednotlivé kroky, vstupy a výstupy, vazbu na test case
  • Automatizované testy se připravují tam, kde je často opakován test bez změny jeho GUI rozhraní
  • Konkrétní kroky, které mají být testerem vykonány

Častý obsah testovacích kroků

  • Popis kroku a očekávaný výsledek
  • Slovní popis pro manuální testy
  • Spustitelný skript pro automatizované testy
  • Skript ve formě SQL dotazu
  • Kombinace předchozích
  • Vazbu na test case

Test data

  • Při definici dat se zohledňuje i možnost jejich opakovaného užití
  • Dělíme na destruktivní a nedestruktivní
  • Problémem je příprava dat ve sdíleném testovacím prostředí pro více projektů
  • Sumární specifikace – data, která budou užita pro test
  • Připravují se správné i chybové hodnoty na mezních stavech
  • Data je třeba zajistit před zahájením testování
  • Často data dodává zákazník, využívá produkční data
  • Před testováním je nutné ověřit použitelnost dat
  • Pokud se data nepřipraví s dostatečným předstihem, hrozí zpoždění nebo zmaření testu

Konfigurace testovacího prostředí

  • Jsou architektem specifikovány již v akviziční části a je postupně upřesněno
  • Akviziční testy probíhají u zákazníka
  • Specifikaci upřesňuje test implementor
  • Prostředí musí být připraveno s předstihem, aby bylo možné připravit test data
  • Za přípravu prostředí odpovídá správce test prostředí, na straně zákazníka jde o pracovníky IT provozu
  • Na sdíleném test prostředí se objevuj stejné problémy jako na sdílených test datech
  • Popis HW a SW konfigurace a nastavení aplikace
  • Je klíčové pro integrační testy mezi více systémy
  • Důležité pro instalační testy
  • Klíčové pro performance a load testy

Příklad parametrů test prostředí

  • Výkon PC
  • Internet a prohlížeč
  • Verze Java
  • Verze .Net Framework
  • Orace klient

Upozornění

  • Pozor na verze, vždy je nutné si ověřit jaký je cílový stav konfigurace na testovacích stanicích
  • Koncové stavy na testovacích stanicích by měly odpovídat stanicím uživatelů

Realizace

  • Je-li vše připraveno, je test spuštěn
  • Tester zaznamenává vše do testovacího protokolu test log
  • V případě zjištění neshody se provede záznam o neshodě a do protokolu je zapsáno ID neshody
  • Vhodně nastavené parametry záznamu o neshodě a test logu umožní efektivní vyhodnocení testu

Vyhodnocení a zpracování změn

  • Test manažer a test analytik sledují průběžný stav testů, počty úspěšných proti neúspěšným testům, počty a závažnosti nalezených chyb, typ identifikovaných chyb aby mohli rozhodnout o případném zastavení testů při přílišném výskytu chyb závažnosti kritická
  • Každá iterace se musí vyhodnotit, aby byla jasná otestovanost zkoumaného řešení
  • Průběžné hodnocení slouží k povolení přechodu do vyššího stádia testů
  • Na konci se provádí sumární vyhodnocení testů, aby se při řešení obdobného problému předešlo chybám již identifikovaným

Cíle vyhodnocení

  • Zajistit kvalitu produktu
  • Zlepšit proces testování – probíhá v každé iteraci

Na základě vyhodnocení se provádí

  • Úprava a doplnění test cases, skriptů a dat
  • Doplnění o další potřebné testy (doplnění performance testů o tress testy, výkonnostní testy)
  • Automatizace testů

Test result a test log

  • Vznikají ve fázi testování ve všech stádiích testů
  • Test log – záznam testu
  • Test result – výsledek analýzy test logu

Nástroje podpory testů

  • MS Office (Word a Excel)
  • HP Quality Center – komerční test manažer tool
  • Vlastní vyvíjené utility
  • JIRA – komerční bug tracking nástroj
  • Bugzila – oupensurse bug tracking nástroj

Nejčastější dotazy

Výběr testovacího nástroje

  • Zvažovat potřeby a možnosti projektu i zákazníka
  • Soustředit se na výši nákladů (zaškolení) X využití nástroje

Jaká je třeba dokumentace pro analýzu

  • Plán projektu, smlouva – především rozsah projektu a akceptační kritéria
  • IT Solutin – IT analýza – požadavky, Use Case model, funkční specifikace, detailní design
  • Architektura systému, popis prostředí

Použití aparátu

  • Viz kapitola postup analýzy

Existují další šablony

  • Metodika RUP
  • Metodika zákazníka (existuje-li)
  • Dokumenty, které užíváme na projektech

Nedostatek dokumentace

  • Je třeba dokumentaci získat od analytiků, nebo vývojářů
  • Sejít se s uživateli, zadavateli, administrátory systému a získat potřebné informace

Nadbytek dokumentace

  • Soustředit se na cíle testování a na jejich základě na příslušné kapitoly podkladů

Určení formy testů

  • Vždy závisí na typu, době trvání a ceně projektu, zvyklostech a potřebách zákazníka
  • Uplatňujeme přístup Good Enough Qvality
Posted in: Studijní materiály, Vývoj počítačů

Základy testování

  • Často dochází k neúplné specifikaci požadavků ze strany klienta
  • Je nutné v průběhu vývoje průběžně ověřovat, zda je navrhované řešení to, které je zákazníkem požadováno

Quality Asurance (QA)

  • Je řízený proces ověřování kvality jednotlivých procesů a výstupu realizovaných produktů
  • Hlavním principem je metoda DMAIC vycházející z cyklu PDCA a je užívána strategií metodiky SIX SIGMA
  • Znamená zajištění kvality, nikoliv její zjištění
  • Proces testování funguje v QA jako měřidlo s jehož pomocí se koriguje výstupní produkt

Metoda DMAIC

Fáze definice

  • specifikuje cíle a získává informace
  • popisuje stav, kterého má být dosaženo
  • popisuje způsob užitého měření
  • určuje tým řešitelů
  • popisuje se proces, který má být zlepšen
  • definuje se plán, který má obsahovat jednotlivé činnosti, jež jsou třeba k odstranění problému
  • nazýváno define

Fáze měření

  • probíhají předem definovaná měření
  • odlišují se domněnky od skutečnosti
  • provádí se:
    • revize kódu
    • dokumentů
    • vlastní testování funkční aplikace
    • revize užitého procesu
  • nazýváno measure

Fáze analýzy výsledků

  • analyzuje měření
  • zjišťuje skutečný potenciál pro zlepšení
  • základem je analýza příčin problémů, nedostatků, nespokojenosti
  • zjišťuje se, zda je opravdu řešen původní problém
  • nazýváno Analyse

Fáze návrhu zlepšení

  • základem zlepšení je odstranění skutečné příčiny
  • nastavují se nové parametry procesu a jeho optimalizace
  • vše se dělá pro zvýšení spokojenosti zákazníka
  • součástí je i zlepšení nákladů, přínosů pro zákazníka
  • nazýváno desing improvements

Fáze řízení zlepšeného

  • je-li problém úspěšně odstraněn, nebo je dosaženo zlepšení tak se děje následující
  • všechny změny se zavádí, standardizují do procesu nebo systému
  • přesvědčí se, zda jsou změny řádně uplatněny a zda jsou užity každodenní činností
  • stanovuje se období, ve kterém se sleduje dosažení stanovených výsledků
  • nazýváno Control

Řízení projektu

Fáze akviziční

  • vymezen skoup projektu
  • jsou definovány oblasti řešení
  • určuje strategie testování
  • provádí se odhady pracnosti všech aktivit
  • definují se hlavní milníky projektu

Fáze návrh

  • probíhá IT analýza
  • vzniká dokument IT solution, který schvaluje zadavatel jako potvrzení pochopení požadavků na řešitelské straně
  • po schválení IT solution jsou zahájeny práce na detailním návrhu, který slouží jako zadání pro vývojáře
  • pro oblast testování vzniká dokument plán testů, kde jsou definovány oblasti, které budou testovány (požadavky na testování)
  • je upřesněn odhad pracnosti
  • jsou definovány milníky testování

Fáze provedení

  • probíhá vlastní vývoj SW řešení
  • probíhá příprava testů a testovacího prostředí
  • příprava testovacích dat
  • realizace jednotlivých stádií testů
  • vývojové, SIT, UAT a TAT testy

Fáze ukončení projektu

  • řešení je nasazeno, předáváno do rutinního provozu
  • je komplementována dokumentace
  • akceptační protokoly
  • je vypracováno závěrečné hodnocení projektu

Diagram životního cyklu tvorby SW

  • Je nazýván V-Diagram
  • Znázorňuje, co se ve které fázi projektu testuje a proti jaké dokumentaci
  • Vývojové testy probíhají proti detailnímu návrhu
  • Testy komponent probíhají proti IT solution
  • Testování systému probíhá formou integračních testů proti systémovým požadavkům
  • Akceptační testování probíhá proti uživatelským požadavkům, kde jsou formulovány produkty a jejich vlastnosti
  • Pokud dojde k vynechání jednoho ze vstupů, nemůže být testování úspěšné
  • Chybějící podklady je nutné sehnat jinak, třeba konzultací se zadavatelem, což není vždy možné

Diagram nákladů na opravu chyb

Ukazuje náklady na opravu chyby v jednotlivých částech vývoje

Testování

Validace

  • Probíhá v různých fázích projektu
  • Účastní se jí různé role pracující na projektu
  • Ověření, že uživatelské požadavky odpovídají potřebám uživatele je prováděno IT analytikem ve spolupráci s View analytikem
  • Vyjasňují se jednotlivé pojmy a způsob práce uživatele a možnosti užité technologie
  • Technologie je omezujícím faktem některých změnových řízení
  • Provádí-li se ověřování je možné práce ukončit dříve, nežli se projekt naplno rozběhne a případné technologické limity budou zjištěny později
  • Je nutno ověřit, že kvalitativní požadavky odpovídají způsobu práce koncového uživatele a současně umožňují splnit uživatelské požadavky v plném rozsahu jak z hlediska funkčnosti, tak z hlediska výkonosti systému
  • Ve fázi vniku návrhu řešení je nutné se soustředit i na to, zda je návrh schopen kvalitativní požadavky naplnit, nebo je nutné je zrevidovat, či pozměnit navrhované řešení
  • Posledním krokem je otestování, zda jsou splněny uživatelské požadavky tak, jak byly schváleny (provádí tester ve stádiu SIT testů)

Verifikace

  • Je finální přejímka zboží zákazníkem
  • Ověřuje, že je možné produkty pomocí SW řešení realizovat
  • Provádí UAT tester (zadavatel) v rámci stádia UAT testů
  • V případě pilotního provozu přímo koncový uživatel

Důležité!

  • Testování znamená měřit
  • Je nutné znát jednotlivé měřitelné požadavky a jednoznačná kritéria jejich naplnění
  • Je nutné ověření již ve fázi definice uživatelských požadavků
  • Netestovatelné požadavky jsou ignorovány, řešení nemusí splňovat představy uživatele
  • Je nutná revize neúplných požadavků => zpoždění projektu
  • Kritéria pro schválení řešení se nazývají akceptační
  • Akceptační kritéria by měla být nadefinována zároveň se zadáním požadavků
  • Typická akceptační kritéria jsou: 0 chyb závažnosti kritická nebo velká, maximálně 5 chyb závažnosti střední s definovaným workraundem a určeným termínem jejich odstranění, maximálně 15 chyb závažnosti malá s určeným termínem odstranění, odezvy kritických operací budou do 3s, nekritické operace s odezvou maximálně 15s.
  • Musí být jednoznačně definovány typy závažnosti s uvedením příkladů
  • Musí být definováno, co je kritická a co je nekritická operace
  • Je nutné si uvědomit, že testováním je možné chyby odhalovat, ale ne garantovat bezchybnost aplikace
  • Akceptační kritéria připouštějí nasazení řešení s identifikovanými chybami
  • Akceptační kritéria:
    • Ukazatel, který měříme
    • Metriku, která bude užita
    • Hodnotu, která je akceptační hladinou
  • Častý je požadavek: systém poskytne uživateli přiměřenou odezvu na běžném internetovém připojení a to i v situaci, kdy pracuje v systému většina uživatelů

Typy testů a základní pojmy

  • Prvním krokem ke sjednocení bylo definování metody FURPS (dělí typy testů dle jasně daných hledisek)

Dělení typů

  • Dle stádia (SIT, AUT, TAT)
  • Dle znalosti kódu (white-box, black-box)
  • Dle způsobu provedení (manuální, automatizované)
  • Dle potřeby běžící aplikace (statické, dynamické)
  • Dle účelu (funkční, zátěžové, instalační, smoke…)
  • Dle podmnožin (funkční – UNIT, assembly, integrační, smoke)

Hlediska FURPS

  • Funkcionality (funkčnost)
  • Usability (užitečnost)
  • Reliability (spolehlivost)
  • Performance (výkonnost)
  • Supportability (rozšiřitelnost)

Metoda FURPS

  • Určuje způsob testování
  • Lez užít jen některé ze skupin testů, ale je nutné vyhodnotit rizika s tím spojená

Typy testů v časové ose projektu

  • Zátěžový a penetrační test má smysl realizovat až v době končících UAT testů, protože mají ověřovat až finální stav řešení před předáním do funkčního prostředí a jejich výsledky bývají součástí akceptačního protokolu

Stádium testů

  • Rozdělení testů dle realizace v časové ose v rámci životního cyklu vývoje SW řešení a v rámci procesu testování

White-box testy

  • Jsou vývojové testy ověřující správnost funkčnosti jednotlivých algoritmů a metod, pomocí automatizovaných testů
  • Je k dispozici příslušná dokumentace, binární a zdrojový kód testované aplikace
  • Provádí je mimo jiné UNIT testy

Black-box testy

  • Je základním testem zdrojového kódu
  • Účelem je ověřit správnost datových typů a logiky kódu
  • Testování probíhá bez znalosti vnitřní datové a programové struktury
  • Známé jsou vstupy a očekávané výstupy

UNIT testy

  • Testování malých nezávislých částí kódu, funkčností jednotlivých dílčích algoritmů, v rámci některého z vývojových nástrojů
  • Typickým znakem je, že nedochází k zápisu do DB

Assembly testy

  • Navazují na UNIT testy
  • Jsou prováděny vývojáři
  • Ověřují spolupráci dílů otestovaných UNIT testy
  • Jsou kombinací UNIT a black-box testů
  • Tester zná částečně strukturu kódu

Funkční testy

  • Ověřují správnost dílčích výstupů na základě připravených vstupů do jednotlivých modulů
  • Patří sem i UNIT testy
  • Užívá se především v SIT testech

Integrační testy

  • Jde o manuální funkční testy
  • Ověřuje schopnost komunikace metod a modulů
  • Užívá se především v SIT testech
  • U rozsáhlých systémů jsou nutnou součástí akceptačního testování

End to end testy

  • Jsou manuální integrační testy ověřující celý byznys proces vybraného produktu
  • Neověřuje dílčí funkčnost, ale klade důraz na realizovatelnost produktu v celém životním cyklu
  • Užívá se především v UAT testech

Výkonnostní testy

  • Měří výkonnost systému z pohledu koncového uživatele
  • Slouží k ladění systému, nebo ke zjištění výkonnostních limitů
  • Dělí se dle cíle testu
  • Back mark, zátěžový, akceptační, low test, test výkonnostního profilu, ladění výkonu…

Bezpečnostní testy

  • Může mít zastoupení již při revizi návrhu řešení
  • Ověřuje architekturu
  • Pomocí rewyou kódu hledá napadnutelná místa kódu
  • Ověřuje loginy
  • Významnou formou jsou penetrační testy, kde se tester pokouší prolomit ochranné mechanismy
  • Jsou jak manuální, tak automatizované

Regresní testy

  • Zjišťují, zda nová verze aplikace nemá vliv na její původní funkcionalitu
  • Užívají se při ověřování opravy chyb, kde je ověřeno okolí chyby, kam oprava neměla zasáhnout

Instalační testy

  • Ověřují správnost dokumentace v návaznosti na instalační postup
  • Ověřují správnou funkčnosti instalačních postupů

Technologické testy

  • Slouží k ověření použitelnosti testovacího nástroje na danou aplikaci
  • Ověřují kompatibilitu použité technologie ve stávající SW a HW konfiguraci
  • Ověřují také možnost užití podprůměrného testovacího nástroje (WinRunner)

Smoke testy

  • Je modifikací funkčního testu, kdy je v krátké době přezkoušena základní funkčnost
  • Užívá se k ověření správnosti instalace SW

Funkční specifikace

  • Je komplexní analytické zadání požadavků, nebo skupiny požadavků
  • Jde o množinu analytických dokumentů, algoritmů a diagramů, které slouží jako zadání pro programátory
  • Pro podporu analytické práce existují nástroje využívající UML nástroje

Testovací skript

  • Obsahuje sekvenci činností testera při testování aplikace zkonvertovanou do formy programového kódu
  • Používá se pro automatizované funkční testy
  • Pro automatizované testy existují nástroje, které usnadňují konverzi do programového kódu, umožňují nahrání testovacího skriptu a jeho další úpravy
  • Často je pojem využíván i pro manuální testy

Zátěžový skript

  • Je obdobou testovacího skriptu v úpravě pro paralelní spouštění více uživatelů na jednom stroji
  • Existují podpůrné nástroje tvorby

RUP

  • Je obecná komplexní metodika vývoje SW
  • Slouží jako podklad pro nadefinování postupu testů s ohledem na stávající firemní zvyklosti

Role v testování

  • RUP přiděluje odpovídajícím společným aktivitám určitou roli
  • Test manažer je kompletně odpovědný za proces testování
  • Test analyst provádí test analýzu a určuje oblasti testování, monitoruje naplnění strategie testování a podílí se na vyhodnocení jednotlivých iterací
  • Test designer je odpovědný za určení všech detailů jednotlivých testů, které se váží k jednotlivým test cases, určuje strategii tesů, zajišťuje všechny podklady pro úspěšnou implementaci všech částí testování
  • Test deployment exekutiv je odpovědný za implementaci, nasazení, vykonání a vyhodnocení veškerých částí testů dle vytvořených návrhů a specifikacích testů, koordinuje přípravu test prostředí; nemá rozhodovací pravomoc jen pravomoc pro koordinaci podřízených rolí
  • Test implementer je odpovědný za implementaci svěřených částí testů; připravuje testovací sady
  • Test executor je odpovědný za vykonávání přidělené sady testů a protokolování výsledků z přidělené sady
  • Test auditor kontroluje správnost testovacích postupů, dodržování metodik, zásad a standardů
  • V praxi dochází ke kumulaci rolí
Back to Top