Test Case Management
QAReużywalne przypadki testowe, zestawy i pakiety — powiązane z każdym zgłoszeniem i potokiem CI, z pełną identyfikowalnością od wymagania do defektu.
Wiele serwerów: $399
- Redmine
- 5.0 i nowsze, 6.x, 7.x
- Raporty
- 12, z CSV i Excelem
- Uprawnienia
- 18, według roli w projekcie
- CI/CD
- REST API, uwierzytelnianie kluczem API
- Języki
- 50 plików lokalizacji
- Typy zgłoszeń
- Państwa własne, bez zmian
Reużywalne przypadki testowe
Kroki, warunki wstępne i oczekiwane wyniki opisuje się raz, z procesem Szkic → Przegląd → Zatwierdzony → Wycofany. Bez duplikowania.
Zestawy i pakiety
Przypadki grupuje się w zestawy i reużywalne pakiety, które można dołączyć do dowolnej liczby zgłoszeń — każde generuje własne wykonania.
Niezmienne wykonania
Każde uruchomienie to osobny rekord, do którego można tylko dopisywać — zaliczony, niezaliczony, zablokowany lub pominięty — z buildem, commitem, środowiskiem i zrzutami ekranu.
Mapowanie automatyzacji
Każdy przypadek mapuje się na framework, klasę, metodę i identyfikator automatyzacji, dzięki czemu runner CI uruchamia go bezpośrednio.
REST API dla CI/CD
Potoki pobierają testy dla zgłoszenia i przesyłają wyniki — Jenkins, GitHub Actions, GitLab CI, Azure DevOps lub Bitbucket.
Dashboardy i raporty
Wskaźnik zaliczeń, pokrycie automatyzacją i wymaganiami oraz raporty gotowości do wydania — z eksportem do CSV.
Jeden łańcuch od wymagania do defektu, który z niego wyniknął
Nic w tym łańcuchu nie jest kopią. Zgłoszenie wskazuje przypadki testowe, które je potwierdzają, każde uruchomienie dodaje wykonanie, a nieudane wykonanie wskazuje błąd, który zgłosiło. Idąc za linkami w dowolną stronę, zawsze trafia się na prawdziwe rekordy Redmine.
1. Zgłoszenie
Funkcja, historyjka lub wymaganie w dowolnym typie zgłoszenia, którego już Państwo używają. Wtyczka nie dodaje własnego typu zgłoszenia.
2. Przypadek testowy
Przypisywany pojedynczo lub w pakiecie. Ten sam przypadek, np. TC-41, może obsługiwać dowolną liczbę zgłoszeń.
3. Plan i przebieg
Plan (TP-2) wyznacza zakres wydania; przebieg (TR-5) to jedna sesja na jednym buildzie.
4. Wykonanie
Zaliczony, niezaliczony, zablokowany lub pominięty, z buildem, commitem, środowiskiem, wynikami kroków i zrzutami ekranu. Nigdy później nieedytowane.
5. Defekt
Zwykłe zgłoszenie Redmine powiązane z niepowodzeniem, tworzone ręcznie lub automatycznie, gdy test nie przejdzie.
Reguły, które spinają łańcuch
Odwołania TC-, TB-, TP-, TR- i DS- z wybranymi przez Państwa prefiksami, wykonania przypięte do wersji przypadku, która została uruchomiona, oraz opcjonalna reguła, że zgłoszenia nie można zamknąć, dopóki jego testy nie przejdą.
Cały proces, uchwycony w działającym Redmine 6.1
To prawdziwe ekrany wtyczki w domyślnym motywie Redmine. Projekt, osoby i wyniki to dane demonstracyjne fikcyjnego sklepu internetowego Harbor Storefront.
Tworzenie: biblioteka reużywalnych przypadków testowych
Wyszukiwanie i filtrowanie według modułu, statusu, automatyzacji i tagów. Każdy przypadek ma ustrukturyzowane kroki, historię przeglądów i własną historię wersji.
Planowanie: pakiety, plany wydań i dane testowe
Pakiety zbierają przypadki do ponownego użycia. Plan łączy pakiety, zgłoszenia, testerów i wersję Redmine. Zestawy danych dostarczają jednemu przypadkowi wiele wierszy.
Wykonanie: testy odbywają się w zgłoszeniu i w przebiegu
Programiści i testerzy pracują tam, gdzie już są. Każdy wynik to nowe wykonanie, więc historia jest dziennikiem audytu.
Decyzja: raporty, które odpowiadają na pytanie „czy możemy wydać?”
Dwanaście raportów, każdy z CSV, Excelem i wydrukiem. Dwa z nich są stworzone do rozmowy o wydaniu.
Po Państwa myśli: import, powiadomienia i ustawienia
Jak trzydzieści dni testów wygląda w raportach
Poniższe liczby pochodzą wprost z projektu demonstracyjnego ze zrzutów ekranu i zostały odczytane z raportów samej wtyczki: 70 przypadków testowych i 1242 wykonania między 9 września a 8 października 2026 r. Pokazują, co wtyczka mierzy. Nie są to benchmarki ani wyniki klientów.
| Miara | Wartość | Szczegóły |
|---|---|---|
| Przypadki testowe | 70 | 61 zatwierdzonych, 5 w przeglądzie |
| Wykonania | 1242 | 856 zautomatyzowanych, 386 ręcznych |
| Wskaźnik zaliczeń | 87,8% | Cel 90% |
| Pokrycie automatyzacją | 60% | 42 z 70 przypadków |
| Defekty z niepowodzeń | 5 | Powiązane z niezaliczonym wykonaniem |
| Środowisko | Wykonania | Zaliczone | Niezaliczone | Zablokowane | Pominięte | Wskaźnik zaliczeń |
|---|---|---|---|---|---|---|
| QA | 700 | 610 | 47 | 29 | 14 | 87,1% |
| Staging | 344 | 307 | 20 | 10 | 7 | 89,2% |
| DEV | 162 | 142 | 12 | 5 | 3 | 87,7% |
| UAT | 36 | 31 | 3 | 1 | 1 | 86,1% |
| Moduł | Przypadki | Wykonania | Zaliczone | Wskaźnik zaliczeń |
|---|---|---|---|---|
| API | 5 | 129 | 123 | 95,3% |
| Katalog | 8 | 118 | 112 | 94,9% |
| Powiadomienia | 5 | 99 | 93 | 93,9% |
| Admin | 6 | 62 | 56 | 90,3% |
| Wyszukiwanie | 6 | 143 | 128 | 89,5% |
| Uwierzytelnianie | 10 | 193 | 172 | 89,1% |
| Finalizacja zamówienia | 8 | 131 | 114 | 87,0% |
| Zamówienia | 6 | 89 | 73 | 82,0% |
| Koszyk | 8 | 143 | 116 | 81,1% |
| Płatności | 8 | 135 | 103 | 76,3% |
W Redmine te same liczby pojawiają się na dashboardzie (pierścień wskaźnika zaliczeń, rozkład wyników, trend z 14 dni, pokrycie modułów i komponentów) oraz w raportach tabelarycznych, każdy z eksportem do CSV i Excela.
Zbudowane wokół jednej zasady: przypadek testowy nigdy nie jest duplikowany
Reużywalne przypadki testowe
Tytuł, warunki wstępne, ustrukturyzowane kroki z oczekiwanymi wynikami, moduł, komponent, priorytet, ważność, typ i tagi. Klonowanie, edycja zbiorcza, import i eksport.
Wersje, które chronią historię
Edycja przypadku, który już był wykonywany, tworzy nową wersję. Stare wykonania nadal wskazują kroki, które faktycznie zostały wykonane.
Przegląd i zatwierdzanie
Szkic, w przeglądzie, zatwierdzony, wycofany. Każda decyzja jest zapisywana z recenzentem, datą i komentarzem, a autor otrzymuje powiadomienie.
Pakiety, plany i przebiegi
Pakiety grupują przypadki do ponownego użycia. Plany wyznaczają zakres wydania lub sprintu względem wersji Redmine. Przebiegi zapisują jedną sesję na jednym buildzie.
Panel testów w każdym zgłoszeniu
Przypisane przypadki, najnowsze wyniki, wskaźnik zaliczeń, powiązane defekty i zapis jednym kliknięciem, w wybranych typach zgłoszeń.
Wykonania, które można audytować
Każde uruchomienie dodaje rekord z wynikiem, trybem, środowiskiem, buildem, commitem, czasem trwania, wynikami kroków, logiem i zrzutami ekranu. Nic nie jest nadpisywane.
Testy sterowane danymi
Reużywalne zestawy danych z nazwanymi kolumnami. Dołącza się je do przypadków lub całych pakietów i zapisuje, którego wiersza użyło każde wykonanie.
Mapowanie automatyzacji i CI/CD
Przypadek mapuje się na framework i identyfikator zrozumiały dla runnera, a potok sam pobiera, co ma uruchomić, i przesyła wyniki.
Dashboard i dwanaście raportów
Dashboard, który każdy użytkownik układa z ośmiu widżetów, oraz raporty gotowości, pokrycia, trendu, środowisk, defektów i monitorowania.
Cztery małe cykle życia, wszystkie widoczne na stronie
| Rekord | Ścieżka główna | Inne stany |
|---|---|---|
| Przypadek testowy | Szkic → W przeglądzie → Zatwierdzony | Wymagane zmiany, Wycofany |
| Plan testów | Szkic → Aktywny → Zakończony | Zarchiwizowany |
| Przebieg testów | Zaplanowany → W toku → Zakończony | Przerwany |
| Wynik wykonania | Zaliczony, Niezaliczony, Zablokowany lub Pominięty | Niewykonany. Każdy wynik jest zapisywany jako ręczny lub zautomatyzowany. |
Potok pyta, co uruchomić, a potem raportuje wyniki
REST API znajduje się pod /testcases/api/v1 i uwierzytelnia się zwykłym kluczem API Redmine. Może z niego korzystać wszystko, co potrafi wysłać żądanie HTTP. Przewodnik wbudowany we wtyczkę prowadzi przez konfigurację z już uzupełnionymi Państwa adresami URL.
| Metoda | Endpoint | Przeznaczenie |
|---|---|---|
| GET | /issues/:id/testing | Co uruchomić dla zgłoszenia |
| POST | /executions/upload | Wyniki jednego buildu dla jednego zgłoszenia |
| POST | /executions/bulk_upload | Wyniki dla wielu zgłoszeń lub buildów |
| POST | /test_runs | Utworzenie przebiegu dla tego buildu |
| POST | /test_runs/:id/results | Przesłanie wyników do przebiegu |
| GET | /test_cases | Lista, tworzenie i aktualizacja przypadków |
| GET | /test_plans | Lista, tworzenie i aktualizacja planów |
| GET | /issues/:id/coverage | Pokrycie testami zgłoszenia |
| GET | /reports/:name | Dowolny raport jako JSON |
| GET | /dashboard | Zagregowane metryki |
Przesyłanie wyników buildu
Wystarczy wysłać metodą POST ID zgłoszenia, numer buildu, SHA commita, środowisko i listę wyników do /executions/upload. Wyniki są dopasowywane do przypadków po identyfikatorze automatyzacji, ID przypadku lub odwołaniu, a każdy z nich staje się nowym wykonaniem. Nazwy wyników są normalizowane, więc passed, failure i ignored z Państwa runnera trafiają we właściwe miejsce, a niezaliczony wynik wysłany z create_defect tworzy powiązany błąd.
Osiemnaście uprawnień w jednym module projektu
Testy to standardowy moduł projektu Redmine. Włącza się go tam, gdzie się testuje, i daje każdej roli tylko to, czego potrzebuje. Karty menu podążają za uprawnieniami.
| Rola | Typowe uprawnienia | Co robi |
|---|---|---|
| Lider QA | manage_test_cases, approve_test_cases, manage_test_bundles, manage_test_plans, assign_test_bundles | Odpowiada za bibliotekę, zatwierdza przypadki, buduje pakiety i plany wydań |
| Tester | view_test_cases, execute_tests, manage_test_runs, manage_test_data | Wykonuje testy, zapisuje wyniki, utrzymuje dane testowe |
| Inżynier automatyzacji | manage_test_automation, view_test_executions | Mapuje przypadki na frameworki i identyfikatory |
| Programista | view_test_cases, view_test_executions, view_test_runs | Widzi, co jest testowane w zgłoszeniu i dlaczego nie przeszło |
| Kierownik projektu | view_test_reports, view_test_plans | Czyta raporty gotowości, pokrycia i monitorowania |
| Konto serwisowe CI | upload_test_results | Przesyła wyniki swoim kluczem API, nic więcej |
| Administrator | admin_testing_settings, manage_test_environments | Prefiksy, środowiska, cele i reguła zamykania |
Działa tam, gdzie już działa Państwa Redmine
| Środowisko | Status | Uwagi |
|---|---|---|
| Redmine 7.x | Obsługiwane | |
| Redmine 6.1 | Obsługiwane | Wersja docelowa rozwoju, na Rails 7.2 i Ruby 3.4. Zrzuty ekranu na tej stronie pochodzą z wersji 6.1.2. |
| Redmine 6.0 | Obsługiwane | |
| Redmine 5.x | Obsługiwane | 5.0 to minimalna wersja deklarowana przez wtyczkę |
| MySQL 8 | Obsługiwane | Używany przy rozwoju i w demo na tej stronie |
| Typy zgłoszeń | Państwa własne | Działa z każdą konfiguracją typów zgłoszeń. Panel testów można ograniczyć do wybranych typów lub zostawić we wszystkich. |
| Dodatkowe gemy | Jeden, opcjonalny | roo, wyłącznie do importu plików .xlsx i .xls |
Instalacja w trzech krokach
Wymaga dostępu do powłoki i możliwości uruchamiania zadań rake. Przed instalacją wtyczki zawsze należy wykonać kopię zapasową.
cd /opt/redmine # unpack so the folder is plugins/redmine_testcases bundle install
RAILS_ENV=production bin/rails redmine:plugins:migrate NAME=redmine_testcases
# Project → Settings → Modules → Test Case Management # Administration → Roles and permissions → grant the testing permissions # Testing → Settings → environments, pass-rate target, trackers
RAILS_ENV=production bin/rails redmine:plugins:migrate NAME=redmine_testcases VERSION=0
Czy wtyczka dodaje własne typy zgłoszeń dla wymagań, historyjek lub błędów?
Co dzieje się ze starymi wynikami, gdy ktoś edytuje przypadek testowy?
Czy niezaliczony test może zablokować zamknięcie zgłoszenia?
Z jakimi systemami CI współpracuje?
Czy niepowodzenia mogą automatycznie tworzyć błędy?
Czy możemy przenieść przypadki testowe z arkusza kalkulacyjnego?
Czy liczby na tej stronie są prawdziwe?
Cennik
Jeden serwer
Jedna instancja Redmine · nielimitowana liczba użytkowników · 12 miesięcy aktualizacji.
Wiele serwerów
Nielimitowana liczba serwerów Redmine · nielimitowana liczba użytkowników · 12 miesięcy aktualizacji.
Potrzebują Państwo rozwiązania Redmine na zamówienie?
Szukają Państwo funkcji, której nie ma w naszych istniejących wtyczkach?
RedmineKit oferuje tworzenie wtyczek Redmine na zamówienie, dostosowywanie wtyczek, automatyzację procesów, integracje z systemami zewnętrznymi i rozwiązania dopasowane do Państwa firmy.
Prosimy opisać swoje potrzeby. Przeanalizujemy wymagania i zaproponujemy odpowiednie rozwiązanie wraz z szacunkowym kosztem i harmonogramem.