Testovací scénáře pro ALM Pumpy¶
Úspěšně otestováno
Popis: Scénář byl kompletně proveden a všechny kroky byly úspěšně dokončeny v souladu s očekávanými výsledky.
Vlastnosti:- Všechny testovací kroky proběhly bez chyb
- Skutečné výsledky plně odpovídají očekávaným výsledkům
- Nevyžaduje se žádná další akce
- Test může být považován za platný a úspěšný
Testováno neúspěšně
Popis: Scénář byl proveden, ale během testování byly zjištěny nesrovnalosti nebo chyby.
Vlastnosti:- Minimálně jeden testovací krok nesplnil očekávání
- Skutečné výsledky se liší od očekávaných
- Je vyžadována oprava a následné přetestování
- Může být přidán komentář s popisem nalezeného problému
Netestováno
Popis: Scénář zatím nebyl podroben testování nebo je testování plánováno na později.
Vlastnosti:- Testovací procedura ještě nebyla zahájena
- Je připraven k provedení, ale čeká na realizaci
- Po provedení bude přehodnocen na úspěšný/neúspěšný
1. Stažení projektu do DB bez inicializovaných dat (data.sql) ¶
Testování požadavku: Samotná funkčnost datových pump 1.1
Popis: Stažení projektu do prázdné databáze ověřuje schopnost systému správně inicializovat datové struktury při prvním nasazení. Důležité je ověření, že aplikace buď automaticky vytvoří potřebné tabulky a vazby, nebo poskytne jasnou chybovou zprávu, pokud chybí základní konfigurace. Tento test zajišťuje, že systém dokáže fungovat i bez předchozího naplnění daty.
Kroky:- Vytvoří se prázdná databáze bez spuštění data.sql
- Spustí se proces stahování projektu
- Aplikace úspěšně inicializuje potřebné struktury a data z projektu budou nahrána do databáze.
Výsledek testu: Otestováno – Úspěšně
Aplikace úspěšně inicializovala potřebné databázové struktury i bez předchozího spuštění data.sql. Data z projektu byla také úspěšně nahrána do databáze SPADE. Žádné chyby nebyly zaznamenány.
Nalezené chyby:
1. U GitHub pumpy byl nalezen problém s mapováním commitů z repozitáře: https://github.com/Luosunce/material-design-data Stav: neopraveno
2. Opakované stažení projektu ¶
Testování požadavku: 1.2.4
Popis: Opakované stažení projektu kontroluje schopnost systému obnovit data po jejich smazání. Klíčové je ověření, že při opětovném stažení nedochází k vytváření duplicitních záznamů a že všechny vazby zůstávají konzistentní. Tento test je důležitý pro zajištění integrity dat.
Kroky:- Stáhne se projekt do DB
- Smaže se projekt z DB přes API
- Stáhne se stejný projekt znovu
- Data by se měla znovu vytvořit bez duplicit nebo chyb.
Výsledek testu: Otestováno – Úspěšně
Projekt byl úspěšně stažen do databáze. Po smazání přes API nedošlo k žádným zbytkům nebo nekonzistentním záznamům. Při opětovném stažení se data obnovila korektně, bez duplicit a se zachováním všech vazeb. Systém nehlásil chyby a fungoval podle očekávání.
3. Nevalidní vstupy v GUI ¶
Testování požadavku: 2.5.1
Popis: Testuje se odolnost systému proti chybným a potenciálně škodlivým uživatelským vstupům. Zásadní je ověření, že aplikace správně detekuje a odmítá neplatné údaje včetně SQL injection a překročení maximálních délek. Tento test chrání systém před bezpečnostními riziky a zajišťuje stabilní chování i při neočekávaných vstupech.
Kroky:- Zadají se postupně:
- Neexistující URL repozitáře
- SQL injection (' OR 1=1 --)
- Překročení max. délky vstupních polí
- Aplikace by měla odmítnout nevalidní vstup a zobrazit uživatelsky přívětivou chybu.
Co funguje:
- Neexistující URL repozitáře → Pokud není zadaná validní URL adresa GUI vypíše chybovou hlášku. Pokud je zadaná validní URL adresa ale není to existující URL repozitář WebSockets Messenger napíše, že repozitář nebyl nalezen. !!!nefunguje u Jiry!!!
- SQL injection (' OR 1=1 --) → Aplikace bezpečně blokuje pokus o injekci na backendu.
- Speciální znaky (@#$%^&*) → Zpracovává je korektně nebo je odmítá, pokud jsou neplatné.
- GUI při překročení max. délky vstupních spadne či zamrzne.
- Pokud je zadaná validní URL adresa ale není to existující URL repozitář WebSockets Messenger nenapíše, že repozitář nebyl nalezen.
Nalezené chyby:
1. Pokud se pokusím napsat něco do vyhledávacího pole projektů GUI spadne a vypíše se zpráva: Application error: a client-side exception has occurred (see the browser console for more information). Stav: neopraveno
2. Pokud překročím max. délku vstupních polí tak GUI spadne či zamrzne. Stav: neopraveno
3. Pokud je zadaná validní URL adresa ale není to existující URL repozitář WebSockets Messenger nenapíše, že repozitář nebyl nalezen. Stav: neopraveno
4. Prázdný projekt ¶
Testování požadavku: Samotná funkčnost datových pump 1.1
Popis: Tento test ověřuje chování systému při práci s projekty bez obsahu. Důležité je testování reakce na nově vytvořené repozitáře bez souborů. Tento test zajišťuje, že systém zvládá i okrajové případy a nedojde k jeho pádu při zpracování prázdných projektů.
Kroky:- Vytvoří se nový prázdný repozitář na GitHubu
- Pokusí se jej stáhnout přes ALM pumpu
- Aplikace by měla zpracovat prázdný stav a neměla by spadnout.
Výsledek testu: Otestováno – Úspěšně
Prázdný repozitář na GitHubu byl úspěšně vytvořen. ALM pumpa jej bez problémů zpracovala a stáhla do systému. Aplikace nezhavarovala. Nebyly zaznamenány žádné chyby ani neočekávané chování.
5. Propojení projektu z různých ALM nástrojů ¶
Testování požadavku: 1.1.4
Popis: Ověření schopnosti systému správně ukládat instance projektů z různých ALM nástrojů do jednoho projektu.
Kroky:- V systému existuje již vydolovaný projekt z ALM nástroje (např. Jira)
- Vybere se stejný projekt z jiného ALM nástroje
- Spustí se proces stahování projektu z druhého nástroje
Očekávaný výsledek: V databázi budou 2 instance projektu napojené na stejný projekt.
Výsledek testu: Otestováno – Úspěšně
Systém úspěšně zpracoval stejný projekt z dvou různých ALM nástrojů (Jira a GitHub). V databázi byly korektně uloženy obě instance projektu, přičemž obě odkazovaly na stejný základní projekt.
6. Paralelní zpracování projektů při těžení ¶
Testování požadavku: 1.3.4
Popis: Test ověřuje, že během probíhajícího těžení dat lze spustit paralelní zpracování dalšího projektu. Systém musí zajistit správné provádění operací, aby nedocházelo ke konfliktům při zápisu do databáze.
Kroky:- V GUI se pustí těžba dat z vybraného projektu
- Během těžby se spustí těžba dalšího projektu
- Oba projekty se správně stáhnou do databáze a nedojde k žádné kolizi či ztrátě dat.
Výsledek testu: Otestováno - neúspěšně
Co nefunguje:- Při paralelním těžení více Jira projektů dochází k zastavení obou procesů a žádný se nedokončí. Pravděpodobná příčina je sdílení stejného API klíče pro oba současné požadavky, což způsobuje konflikt v přístupu k Jira API.
Nalezené chyby:
1. Při paralelním těžení více Jira projektů dochází k zastavení obou procesů a žádný se nedokončí. Stav: ignorováno
2. Při těžení konkrétního Jira projektu: https://issues.apache.org/jira/projects/ABDERA docházelo k této chybě:
2025-05-10 15:09:54 java.lang.NullPointerException: Cannot invoke "com.atlassian.jira.rest.client.api.domain.BasicUser.getDisplayName()" because the return value of "com.atlassian.jira.rest.client.api.domain.Attachment.getAuthor()" is null
Chyba vznikla kvůli nezpracované null hodnotě u autorů některých artefaktů. Systém předpokládal, že pole author je vždy vyplněné, ale u části dat chybělo, což vedlo k pádu těžebního procesu. Stav: Opraveno
----
Testování mapovaní dat¶
Testování požadavku: 1.2
Tyto testy mají za úkol ověřit, zda systém správně zpracovává a mapuje data v nejproblematičtějších scénářích, které jsme identifikovali během analýzy. Zaměřujeme se na situace, které mohou vést ke ztrátě dat, nekonzistenci nebo chybným vazbám.
7. Přiřazení autorů k WorkItemům ¶
Popis: Tento test ověřuje, zda každá položka v systému (issue, commit nebo artifact) má správně přiřazeného autora prostřednictvím pole author_id nebo v případě, že autora přiřazeného nemá mělo by tomu tak být i v daném ALM nástroji. Kontroluje se jak existence této vazby, tak i platnost referencovaného autorova ID.
Kroky:- Stáhnou se projekty z různých ALM nástrojů
- Ověří se, že každý WorkItem má vyplněné author_id
- Každý WorkItem by měl mít vyplněného autora, pokud to tak není mělo by to tak být i v daném ALM nástroji odkuď byl projekt stažen.
Výsledek testu: Otestováno – Úspěšně
Každý WorkItem měl přiřazeného autora až na nějaké artefakty z Jira projektů. Tyto artefakty ale neměli přiřazeného autora ani v nástroji proto se test bere jako úspěšný.
8. Integrita vztahů WorkItem ¶
Popis: Tento test se zaměřuje na správné ukládání a správu vztahů mezi jednotlivými WorkItemy, jako jsou parent-child vztahy nebo různé typy propojení. Ověřuje se, zda jsou všechny vztahy korektně uloženy v příslušné tabulce a zda jsou zachovány obousměrné vazby. Tento test je důležitý pro zachování logických souvislostí mezi WorkItemy.
Kroky:- Stáhne se projekt obsahující vzájemně propojené issues (například parent-child vztahy v Jira nebo propojení přes odkazy v GitHub Issues)
- Zkontroluje se tabulka v databázi work_item_relation
- Vztahy mezi WorkItems jsou korektně uloženy v tabulce work_item_relation
- Pro každý vztah existuje záznam s korektně naplněnými poli leftItemId, rightItemId a relationId
- Bidirektivní vazby jsou zachovány (pokud existuje vztah A->B, pak musí existovat i B->A s příslušnou relací)
Výsledek testu: netestováno
9. Typy WorkItem ¶
Popis: Test kontroluje správné přiřazení typu každé položce podle jejího původu (COMMIT, ISSUE, ARTIFACT). Tento test zajišťuje, že položky lze následně správně filtrovat a zpracovávat podle jejich typu.
Kroky:- Stáhne se projekt obsahující různé typy entit (Issues, Commits, Artifacts)
- Zkontrolují se záznamy v tabulce work_item
- Každý WorkItem má správně nastavený podle svého původu (COMMIT, ISSUE, ARTIFACT atd.) workItemType
- Všechny WorkItems mají správně nastavené pole podle zdrojového systému externalId
- Existuje korektní reference na autora v poli authorId
Výsledek testu: netestováno
10. Historie změn ¶
Popis: Test historie změn ověřuje úplnost a přesnost evidence všech změn provedených na WorkItemech. Test kontroluje, zda jsou všechny změny stavů a atributů řádně zaznamenány v příslušných tabulkách a zda je správně určen typ každé změny. To je klíčové pro možnost auditování a analýzy vývoje položek v čase.
Kroky:- Stáhne se projekt s issue, které prošlo několika změnami stavu
- Zkontroluje se struktura tabulek field_change a work_item_change
- Pro každou změnu existuje záznam v tabulce work_item_change
- Pole v name správně indikuje typ změny (ADD, MODIFY, COMMENT) work_item_change
- V tabulce field_change jsou uloženy konkrétní změny polí s hodnotami před a po změně
Výsledek testu: netestováno
11. Kategorie a Labels ¶
Popis: Tento test se zaměřuje na správné mapování štítků z původních systémů na kategorie v cílové databázi. Důležité je ověření, že všechny štítky jsou převedeny na kategorie a že vazby mezi WorkUnits a kategoriemi jsou zachovány. Tento test zajišťuje, že filtrování a kategorizace položek bude fungovat správně.
Kroky:- Stáhne se GitHub projekt s dobře označkovanými issues
- Zkontrolují se záznamy v tabulce work_unit a vazební tabulce mezi work_unit a category
- Všechny GitHub Labels jsou uloženy jako entity Category
- Vazby mezi WorkUnits a kategoriemi jsou korektně uloženy v propojovací tabulce
- Kategorie mají správný odkaz na projectInstance
Výsledek testu: netestováno
12. Konfigurace commitů ¶
Popis: Test konfigurace commitů ověřuje, zda jsou ke každému commitu správně přiřazeny informace o konfiguraci a zda jsou zachovány vazby na větve. To je důležité pro možnost rekonstrukce stavu systému v libovolném okamžiku. Test kontroluje úplnost a správnost těchto vazeb.
Kroky:- Stáhne se Git projekt s několika commity
- Zkontroluj záznamy a vazby v tabulkách committed_configuration, configuration a commit
- Každý WorkItem typu COMMIT má přiřazenou konfiguraci
- V tabulce committed_configuration existuje záznam pro každý commit
- Tabulka obsahuje správné reference na branch, committed_configuration a commit
Výsledek testu: netestováno
13. Větve a commity ¶
Popis: Test se zaměřuje na správné propojení commitů s větvemi v repozitáři. Ověřuje se, zda jsou všechny vazby mezi commity a větvemi korektně uloženy a zda commity patřící do více větví mají odpovídající záznamy. Tento test je klíčový pro zachování historie vývoje kódu.
Kroky:- Stáhne se Git repozitář s více větvemi obsahujícími stejné commity
- Zkontrolují se tabulky a vazební tabulka mezi branch a commit
- Pro každou branch v repozitáři existuje záznam v tabulce branch
- V propojovací tabulce mezi commit a branch je správně zaznamenáno, které commity patří do jakých větví
- Commit patřící do více větví má správný počet záznamů ve vazební tabulce
Výsledek testu: netestováno
14. Vazby instancí ¶
Popis: Test kontroluje správné propojení mezi nástroji (tool_instance) a projekty (project_instance). Důležité je ověření, že pro jednu instanci nástroje existuje pouze jeden záznam a že všechny instance projektu na ni správně odkazují.
Kroky:- Nakonfiguruje se více projektů na stejné instanci nástroje (např. více repozitářů na jednom GitHub účtu)
- Zkontrolují se záznamy v tabulkách tool_instance a project_instance
- V tabulce tool_instance existuje pouze jeden záznam pro jednu instanci nástroje
- Každý project má vlastní záznam v project_instance
- Všechny ProjectInstance odkazují na správnou ToolInstance
Výsledek testu: netestováno
15. Klasifikační tabulky ¶
Popis: Test ověřuje správné mapování priorit, stavů a dalších klasifikačních údajů z různých ALM nástrojů. Test kontroluje, zda jsou tyto údaje jednotně mapovány napříč systémy a zda jsou správně přiřazeny k příslušným projektům. To je důležité pro cross-platform analýzy.
Kroky:- Stáhnou se projekty z různých ALM nástrojů s různými prioritami a statusy
- Zkontrolují se záznamy v tabulkách wu_type, priority, status, severity a resolution
- Každá entita má správně nastavené pole class podle mapování z ALM nástroje
- Každá entita je správně přiřazena k příslušné project_instance
- Entity se stejným významem z různých nástrojů jsou mapovány na stejnou klasifikaci
Výsledek testu: netestováno
16. Správa osob a rolí ¶
Popis: Test se zaměřuje na správné uchovávání informací o osobách a jejich rolích v systému. Ověřuje se, že pro každou osobu existuje pouze jeden záznam a že všechny její role jsou správně zaznamenány.
Kroky:- Stáhne se projekt, kde stejná osoba vystupuje v různých rolích (autor, assignee, committer)
- Zkontrolují se tabulky person a person_role
- V tabulce existuje pouze jeden záznam pro jednu osobu person
- V tabulce person_role jsou správně zaznamenány různé role osoby
- Osoby se stejným jménem ale různými identifikátory jsou správně rozlišeny
Výsledek testu: netestováno
Autor: Jakub Homolka
Datum: 24.4.2025
Stav: hotový
Aktualizováno uživatelem Jakub Homolka před 3 dny(ů) · 106 revizí