V úterý vyšla beta Fedory 23. Její prozatímní vývoj probíhá velice poklidně a dalo by se říct, že se neobjevují příliš závažné chyby, které by způsobily odložení finálního vydání. To ovšem neznamená, že žádné takové chyby neexistují, ale že se mohou schovávat někde, kde je ještě nikdo nehledal. Kompletně otestovat tak velký projekt, jakým je Fedora se třemi svými produkty zabere opravdu spoustu času a hardwaru. A hlavně spousta lidí, kteří Fedoru na tom daném hardwaru spustí, a otestují, jestli všechno funguje.
Testování Fedory má na starost tým FedoraQA. Placených členů je ovšem příliš málo (a hardwaru, který máme k dispozici není moc), a tak velká porce testování leží na bedrech komunity. Tedy lidí, kteří by byli rádi, kdyby Fedora fungovala co nejlépe. Doufám, že mezi takové patříte i vy, čtenáři Fedora.cz. Zapojení se do testování má dozajista i spoustu výhod pro testera samotného. V první řadě se můžete něco naučit a dále zajistit funkčnost systému na svém konkrétním hardwaru (spousta chyb se totiž projevuje pouze na určitém hardwaru). Aktivní testování Fedory si případný žadatel o zaměstnání na pozici testera (v jakékoli softwarové firmě) může zapsat do životopisu, a jeho pracovní výsledky budou dostupné všem. V neposlední řadě přispějete k tomu, že nová Fedora bude ještě lepší než ty předchozí, a že bude lidem přinášet pouze radost. Rozhodl jsem se tedy v tomto článku popsat, jak testování nového vydání probíhá, abyste se mohli zapojit a nemuseli tápat, jak na to.
Co má vlastně Fedora splňovat?
Pokud chceme, aby nová Fedora vyšla v dostatečné kvalitě, musíme nejdříve jasně stanovit co, a jak má fungovat. Toto je definováno tzv. release kritérii. Pro každou fázi – Alfa, Beta a Final – existuje sada požadavků na funkcionalitu, které musí být splněny pro přechod z jedné fáze do druhé – tedy Alfa kritéria jsou de facto vstupní branou do Beta fáze, a tak dále. Zde jsou Beta a Final kritéria.
Průběh vývoje dané fáze je pak následující – nejdříve jsou vydávány TC (test compose), tedy testovací obrazy disků (pro instalování ze sítě, livecd apod.). Při jejich testování se snažíme nalézt chyby (bugy), které porušují některá z kritérií současné či některé z předchozích fází. Tyto nazýváme blocker bugy. TC vychází tak dlouho, dokud nejsou všechny objevené blocker bugy opraveny. Následují RC (release compose), tedy sestavení, která by neměla obsahovat žádné blockery. Pokud je tomu opravdu tak, pak RC prohlášeno za vydání dané fáze. Přesně toto se stalo nyní. Beta RC1 neobsahovala žádné chyby, které by porušovaly Alfa nebo Beta kritéria, a tak byla prohlášena za vydanou beta verzi.
A jak se to tedy testuje?
Co je k testování potřeba?
V první řadě potřebujete nějaký stroj, na kterém budete testovat. Můžete použít buď přímo nějaký počítač (ať už stolní nebo notebook) nebo můžete použít virtualizaci. Pro virtualizaci lze použít například virt-manager, ale můžete použít i jakoukoli jinou technologii. Je potřeba si ovšem dát pozor, jestli daný test není potřeba zkoušet přímo na hardwaru (bývá uvedeno u testu). Pokud si nejste opravdu jisti s tím co děláte, doporučuji nepoužívat stroj, na kterém máte svá data. Uvědomte si, že testujete nehotový software, kde lze očekávat chyby.
Je též vhodné mít účet v bugzille. Fedora ji používá jako primární místo pro hlášení chyb a správu blokujících bugů. Existuje ovšem spousta dalších míst, kam hlásit chyby. Např. bugzilla.gnome.org je místo, kam je dobré hlásit bugy týkající se přímo GNOME.
Účet ve FAS je dobrovolný. Je ovšem dobré, jej při hlášení bugů používat. Nejenže pak můžete lépe vyhledat vaše změny v historii, ale můžete také dostat odznak! Tím se pak můžete chlubit svým kamarádům a kolegům.
V neposlední řadě je potřebná znalost angličtiny. Ať už bugzilla či wiki stránky jsou totiž v anglickém jazyce.
Co mám testovat?
Vždy, když vyjde nové TC nebo RC, je na wiki stránkách Fedory vytvořena sada matic, které obsahují pokyny k testování (tzv. test casy) a prostor pro zapsání výsledků. Matic je tedy několik a jsou rozděleny podle toho, co se snaží otestovat. Máme matici pro instalátor, která obsahuje test casy týkající se instalace na všechny možné způsoby, která je nejrozsáhlejší. Na Anacondu (instalátor Fedory) jsou kladeny vysoké nároky. Případné selhání při instalaci může vést k nefunkčnímu výslednému systému či hůř ke ztrátě uživatelských dat. Také je to první věc, se kterou se nový uživatel setká. Testuje se vše, od toho jestli instalační médium nabootuje do instalátoru, přes všechna možná nastavení disků a zdrojů pro instalaci, až po takové drobnosti jako je vytvoření uživatelského účtu během instalace. V matici pro instalátor též naleznete postup k otestování dual bootu, upgradu z předchozích verzí, nebo hlášení chyb přímo z instalátoru.
Obr. 2: Ukázka vyplněné tabulky
Dále existuje matice základní funkcionality systému. Ta obsahuje základní testy společné pro všechny produkty a platformy. Zde se snažíme zjistit, jestli nainstalovaný systém správně bootuje, ukládá logy, jestli funguje správa služeb a podobná základní funkcionalita.
Maticí, která je velice zajímavá pro koncové uživatele je matice jednotlivých desktopových prostředí. V té jsou uvedeny testy funkcionality GNOME (produkt Workstation), KDE, MATE, Xfce a dalších. Test casy jsou zde často velice obecné (např. testování celého menu) a snaží se obsáhnout vše. Bohužel, i když je desktop velice důležitý pro uživatele, bývá kvůli nedostatku času otestován pouze povrchně a tudíž důkladné otestování závisí na komunitě, tedy na vás, budoucích i nynějších nadšených testerech.
Pro nadšence do cloudu a serverových technologií mám jednu dobrou zprávu. I pro tyto oblasti jsou matice. Fedora se totiž nedávno rozdělila na několik produktů. Workstation, Server a Cloud. Existuje tedy zvlášť matice pro server a matice pro cloud.
Jednotlivé matice též obsahují sloupeček, ve kterém je uvedeno, pro kterou fázi je daný test case důležitý (od které fáze nefunkčnost testované vlastnosti bude blokovat vydání). Před vydáním alfy stačí, aby byly otestované pouze test casy pro fázi alfa. Podobně v betě. V závěrečné fázi (ve které jsme nyní) už musí být otestováno vše. Jedinou vyjímku tvoří test casy, které mají uvedeno, že jsou optional (nepovinné). Ty je sice dobré otestovat také, ale nejsou pro vydání tak zásadní.
Jak tedy testování probíhá?
Když už víte, kde máte hledat jednotlivé test casy, vyberte si takový, který vás zajímá a otevřete si jej. Jednotlivé test casy obsahují následující informace:
- Popis (Description) – Zde naleznete informaci o tom, co tento test case konkrétně testuje. Např. jestli se lze přihlásit a odhlásit z desktopu.
- Příprava (Setup) – Tato sekce se neobjevuje ve všech test casech. Popisuje přípravu systému před testováním – např. pokud chcete otestovat instalaci na více disků, musíte si nachystat stroj (případně virtuální mašinu) s více disky. Mnohdy ovšem je příprava složitější (např. u některých serverových testů), obsahuje několik kroků a mnohdy zabere i více času, než samotné testování.
- Postup (How to test) – V této sekci je uveden návod k testování. V jednotlivých krocích se dozvíte, co přesně máte udělat. Příklad:
- Proveďte čerstvou instalaci.
- Nabootujte.
- Zkuste se přihlásit jako uživatel.
- Očekávané výsledky (Expected Results) – Nakonec je popsáno, co se má dít v průběhu testování. Někdy nemusí být výsledky jednotlivých kroků na první pohled zřejmé, a tato sekce vám pomůže se rozhodnout, jestli jste test case provedli úspěšně. Příklad:
- Systém nabootuje do přihlašovací obrazovky.
- Je možné se přihlásit jako uživatel.
A to je vše. Při samotném testování si tedy vyberete test case, který chcete otestovat (či jen danou vlastnost vyzkoušet), nachystáte si prostředí podle popsané přípravy a pak už jen krok za krokem provádíte jednotlivé body postupu a kontrolujete, jestli se děje to, co je uvedeno v očekávaných výsledcích.
Nakonec je potřeba zapsat výsledek. Matice jsou většinou rozděleny do podsekcí, aby testeři nemuseli upravovat celou wiki stránku, a hledat, kde je tabulka s test casem, který právě otestovali. Stačí pouze upravit konkrétní tabulku v sekci, kde se nalézá test case, kterým jste právě prošli (edit v pravo u názvu sekce). V tabulce poté najdete řádek, na kterém je uvedený váš test case a výsledek zapíšete do správného sloupce. Sloupce většinou značí, jaký boot systém jste použili, jakou máte architekturu, jaký produkt jste použili, a podobně.
Formát, v jakém se výsledky uvádějí včetně popisu, kdy tento výsledek použít, naleznete na obrázku č. 3. Pokud vše fungovalo, jak má (myslí se tím přímo ta testovaná vlastnost), je výsledek pass. Pokud jste narazili na něco, co sice úplně nebrání provedení testu, ale objevili se jiné problémy, použijte warn. A pokud jste narazili na chybu, tak ji ideálně nahlašte a pak použijte výsledek fail a uveďte číslo bugu.
Závěr
To co jsem v tomto článku popsal je z pohledu FedoraQA nejdůležitější a časově nejnáročnější část práce, která musí být provedena, aby jsme mohli systém vydat. Není to ovšem z testování všechno. Je též nutné testovat updaty, protože ne vždy pouze opravují staré chyby, ale často přináší i nové. Je potřeba hlásit chyby, které se dostaly už do systému a nikdo si jich prozatím nevšiml. Je též potřeba řešit již staré chyby, kterým se vývojáři dostatečně nevěnují.
Práce je tedy hodně a lidí (a hardwaru) málo. Pokud se chcte zapojit určitě se stavte na našem irc kanálu (#fedora-qa na freenode), případně se přihlašte do mailing listu zde.
27. 9. 2015 at 17:09
Pekny clanek.
Hlaseni bugu na linuxu mi prijde docela slozite, kdysi jsem chtel neco postnout do Ubuntu a vzdal jsem to. Navic jak v clanku nakonec pisete je treba anglictina, navic bych to upresnil, ze je potreba vyborna anglictina, protoze treba pro me, ktery sice anglicke navody cte, ale obcas si musi pomoct prekladacem, ruzne technicke vyrazy apod. tak je nemozne neco vysvetlit tak, aby to bylo k pochopeni pro nekoho, kdo se s podobnou chybou nesetkal.
Je to problem, protoze testeru bude asi opravdu malo. Usmal jsem se pri vete o vsemoznem testovani disku pri instalaci. No ja mam jeden disk, chtel jsem si ho rozdelit doporucovanym zpusobem: „/“, „/home“, „swap“. Prirozene jsem chtel aby / bylo sda, /home bylo sdb a swap byl sdc. Protoze logicky budete chtit /home pridelit nejvetsi prostor, / mensi a swapu nejmensi, tak toho rozdeleni ve Fedore 22 nedosahnete. Musel jsem to udelat tak, ze jsem / pridelil zamyslenych 20GB, /home dostal 10GB a swap 4GB. Po instalaci jsem si jako prvni nainstaloval GParted a / zustal jak byl, swap jsem odstranil, /home jsem zvetsil na 90GB a potom jsem vytvoril novy swap opet 4GB. Doufam, ze duvod je jasny, chtel jsem zachovat ono sda /, sdb /home a sdc swap.
Naschval si to v F22 zkuste, pokud budete chtit to rozdeleni disku vcetne velikosti, jak jsem popsal, tak to proste v instalatoru nejde a instalartor vem z nejvetsiho logickeho oddilu /home udela vzdy sda, to jest prvni logicky oddil, ikdyz je mnohem prirozenejsi dat jako prvni teda sda / a naopak swap mit az uplne na konci. No a ted si predstavte, ze bych tuhle chybu mel vysvetlovat v anglictine tak, aby nekdo porozumel tomu, kde ta chyba je, jsem bez sance, obavam se, ze tak dobre anglicky nikdy vladnout nebudu.
27. 9. 2015 at 21:37
Osobně si myslím, že není potřeba nějaká pokročilá znalost angličtiny. Když to nasypete po větách do google translatoru, tak by výsledek měl být pochopitelný.
Rozdělení oddílů přes více disků (sda,sdb,…) jsem, abych se přiznal, nezkoušel (ani nemám kde, v PC mám jen jeden fyzický disk). Jestliže máte na mysli více oddílů na jednom disku (sda1,sda2,…), tak to mi ve Fedoře funguje normálně. Je to sice v instalátoru někdy méně přehledné, ale lze to nastavit podle potřeby.
27. 9. 2015 at 23:14
Tak to nechapu, ale me to neslo, jsem si s tim hral pul hodiny a proste nic. Dal jsem vytvorit oddil / 20GB a byl prvni v poradi, pak jsem dal vytvorit oddil /home 90GB a sup ho a po vytvoreni byl zase prvni a ten oddil / se prestehoval na druhe misto, takze jsem to neulozil zacal znova a kdyz jsem vytvarel ten oddil /home tak jsem mu dal 10GB (mene nez oddilu /) a potom ho instalator nechal normalne na druhem miste, tak jak jsem chtel. Jestli to souvisi s tim, ze mam jeste PATA disk a instalator si s nim nevedel rady, nic jineho me nenapada, jestli to jinym lidem funguje.
28. 9. 2015 at 01:14
Tak řekl bych, že na pořadí oddílů nezáleží, jestli jde jen o tohle. Pokud se nepletu, tak na funkčnost by to vliv mít nemělo.
28. 9. 2015 at 11:51
Dobrý den, popsané chování anacondy je jejich záměr. Chtějí uživatele oprostit od uspořádání disku. Navíc vřele doporučuju používat LVM. Je s ním snažší správa oddílů (logical volumes).
Pokud máte reálný důvod pro použití rozdělení, které jste uvedl, tak vám doporučuju nejdříve nabootovat do live systému a pomocí nástroje gnome-disks (či fdisk) si nejdříve disk naformátovat a poté v instalátoru použít vytvořené oddíly. Takhle dosáhnete požadovaného rozdělení.