Projekt

Obecné

Profil

Akce
Historie

Wiki »

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)

Popis: Ověření chování aplikace při stahování projektu do prázdné databáze bez inicializovaných dat.

Kroky:
  1. Vytvoří se prázdná databáze bez spuštění data.sql
  2. Spustí se proces stahování projektu
Očekávaný výsledek:
  • Aplikace buď úspěšně inicializuje potřebné struktury, nebo vrátí srozumitelnou chybovou zprávu

Výsledek testu: netestováno

2. Opakované stažení projektu

Popis: Ověření schopnosti aplikace znovu vytvořit data po smazání projektu.

Kroky:
  1. Stáhne se projekt do DB
  2. Smaže se projekt z DB přes API
  3. Stáhne se stejný projekt znovu
Očekávaný výsledek:
  • Data by se měla znovu vytvořit bez duplicit nebo chyb

Výsledek testu: netestováno

3. Stažení více projektů pro 1 ToolInstance

Popis: Ověření správy více projektů pro jednu instanci nástroje.

Kroky:
  1. Vyberou se 2+ různých projektů ze stejného ALM nástroje
  2. Spustí se proces stahování pro každý projekt
Očekávaný výsledek:
  • Data všech projektů jsou uložena a přiřazena ke stejné ToolInstance

Výsledek testu: netestováno

4. Přiřazení autorů k WorkItemům

Popis: Ověření kompletního přiřazení autorů ke všem položkám.

Kroky:
  1. Stáhnou se projekty z různých ALM nástrojů
  2. Ověří se, že každý WorkItem má vyplněné author_id
Očekávaný výsledek:
  • Žádný WorkItem nesmí mít prázdného autora

Výsledek testu: netestováno

5. Nevalidní vstupy v GUI

Popis: Ověření ošetření nevalidních uživatelských vstupů do formuláře v GUI.

Kroky:
  1. Zadají se postupně:
    1. Neexistující URL repozitáře
    2. Neplatný API klíč
    3. SQL injection (' OR 1=1 --)
    4. Speciální znaky (@#$%^&*)
    5. Překročení max. délky vstupních polí
Očekávaný výsledek:
  • Aplikace by měla odmítnout nevalidní vstup a zobrazit uživatelsky přívětivou chybu

Výsledek testu: netestováno

6. Prázdný projekt

Popis: Ověření stažení prázdného projektu (nový repozitář bez souborů).

Kroky:
  1. Vytvoří se nový prázdný repozitář na GitHubu
  2. Pokusí se jej stáhnout přes ALM pumpu
Očekávaný výsledek:
  • Aplikace by měla zpracovat prázdný stav (tj. neměla by spadnout)

Výsledek testu: netestováno

7. Integrita vztahů WorkItems

Popis: Ověření správného uložení vztahů mezi položkami.

Kroky:
  1. 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)
  2. Zkontroluje se tabulka v databázi work_item_relation
Očekávaný výsledek:
  • 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

8. Typy WorkItem

Popis: Ověření správného mapování různých typů WorkItem.

Kroky:
  1. Stáhne se projekt obsahující různé typy entit (Issues, Commits, Artifacts)
  2. Zkontrolují se záznamy v tabulce work_item
Očekávaný výsledek:
  • 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

9. Historie změn

Popis: Ověření zachování historie změn WorkItems.

Kroky:
  1. Stáhne se projekt s issue, které prošlo několika změnami stavu
  2. Zkontroluje se struktura tabulek field_change a work_item_change
Očekávaný výsledek:
  • 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

10. Kategorie a Labels

Popis: Ověření mapování kategorii a labelů.

Kroky:
  1. Stáhne se GitHub projekt s dobře označkovanými issues
  2. Zkontrolují se záznamy v tabulce work_unit a vazební tabulce mezi work_unit a category
Očekávaný výsledek:
  • 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

11. Konfigurace commitů

Popis: Ověření správy Configuration a CommittedConfiguration.

Kroky:
  1. Stáhne se Git projekt s několika commity
  2. Zkontroluj záznamy a vazby v tabulkách committed_configuration, configuration a commit
Očekávaný výsledek:
  • 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

12. Větve a commity

Popis: Test na propojení mezi commit a branches.

Kroky:
  1. Stáhne se Git repozitář s více větvemi obsahujícími stejné commity
  2. Zkontrolují se tabulky a vazební tabulka mezi branch a commit
Očekávaný výsledek:
  • 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

13. Vazby instancí

Popis: Test na vazby ToolInstance a ProjectInstance

Kroky:
  1. Nakonfiguruje se více projektů na stejné instanci nástroje (např. více repozitářů na jednom GitHub účtu)
  2. Zkontrolují se záznamy v tabulkách tool_instance a project_instance
Očekávaný výsledek:
  • 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

14. Klasifikační tabulky

Popis: Ověření mapování priorit, statusů a další klasifikačních tabulek.

Kroky:
  1. Stáhnou se projekty z různých ALM nástrojů s různými prioritami a statusy
  2. Zkontrolují se záznamy v tabulkách wu_type, priority, status, severity a resolution
Očekávaný výsledek:
  • 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

15. Správa osob a rolí

Popis: Test na persistenci Person a jejich vazeb

Kroky:
  1. Stáhne se projekt, kde stejná osoba vystupuje v různých rolích (autor, assignee, committer)
  2. Zkontrolují se tabulky person a person_role
Očekávaný výsledek:
  • 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 Štěpán Faragula před 1 den · 38 revizí