Test Case Management
QACas de test, suites et lots réutilisables — reliés à chaque demande et à chaque pipeline CI, avec une traçabilité complète de l'exigence au défaut.
Plusieurs serveurs: $399
- Redmine
- 5.0 et versions ultérieures, 6.x, 7.x
- Rapports
- 12, avec CSV et Excel
- Permissions
- 18, par rôle de projet
- CI/CD
- API REST, authentification par clé d’API
- Langues
- 50 fichiers de langue
- Trackers de demandes
- Les vôtres, inchangés
Cas de test réutilisables
Suites et lots
Exécutions immuables
Correspondance d'automatisation
API REST pour la CI/CD
Tableaux de bord et rapports
Une seule chaîne, de l’exigence au défaut qu’elle a révélé
Rien dans la chaîne n’est une copie. Une demande pointe vers les cas de test qui la valident, chaque campagne ajoute une exécution, et une exécution en échec pointe vers l’anomalie qu’elle a déclenchée. Suivez les liens dans un sens ou dans l’autre : vous arrivez toujours sur de vrais enregistrements Redmine.
1. Demande
Une fonctionnalité, une story ou une exigence, dans le tracker que vous utilisez déjà. Le plugin n’ajoute aucun tracker.
2. Cas de test
Affecté un par un ou via un lot. Un même cas, TC-41 par exemple, peut servir à autant de demandes que nécessaire.
3. Plan et campagne
Un plan (TP-2) fixe le périmètre d’une version ; une campagne (TR-5) est une session sur un build.
4. Exécution
Réussi, échoué, bloqué ou ignoré, avec build, commit, environnement, résultats par étape et captures d’écran. Jamais modifiée après coup.
5. Défaut
Une demande Redmine ordinaire, liée depuis l’échec, créée à la main ou automatiquement quand un test échoue.
Les règles qui font tenir la chaîne
Des références TC-, TB-, TP-, TR- et DS- avec les préfixes de votre choix, des exécutions figées sur la version du cas réellement exécutée, et une règle facultative qui empêche de fermer une demande tant que ses tests ne sont pas réussis.
Tout le parcours, capturé sur un Redmine 6.1 en fonctionnement
Ce sont de vrais écrans du plugin, avec le thème Redmine par défaut. Le projet, les personnes et les résultats sont des données de démonstration pour une boutique en ligne fictive appelée Harbor Storefront.
Rédiger : une bibliothèque de cas de test réutilisables
Recherchez et filtrez par module, statut, automatisation et étiquettes. Chaque cas a des étapes structurées, un historique de revue et son propre historique de versions.
Planifier : lots, plans de version et données de test
Les lots regroupent des cas pour les réutiliser. Un plan relie lots, demandes, testeurs et une version Redmine. Les jeux de données alimentent un même cas avec plusieurs lignes.
Exécuter : les tests se font sur la demande, et dans la campagne
Développeurs et testeurs travaillent là où ils sont déjà. Chaque résultat est une nouvelle exécution : l’historique fait office de piste d’audit.
Décider : des rapports qui répondent à « peut-on livrer ? »
Douze rapports, chacun avec export CSV, Excel et impression. Deux d’entre eux sont conçus pour la discussion de mise en production.
À votre façon : import, notifications et paramètres
Trente jours de tests, vus dans les rapports
Les chiffres ci-dessous viennent directement du projet de démonstration des captures d’écran, lus dans les rapports du plugin : 70 cas de test et 1 242 exécutions entre le 9 septembre et le 8 octobre 2026. Ils montrent ce que le plugin mesure. Ce ne sont ni des benchmarks ni des résultats clients.
| Mesure | Valeur | Détail |
|---|---|---|
| Cas de test | 70 | 61 approuvés, 5 en revue |
| Exécutions | 1,242 | 856 automatisées, 386 manuelles |
| Taux de réussite | 87.8% | Objectif 90 % |
| Couverture d’automatisation | 60% | 42 cas sur 70 |
| Défauts issus d’échecs | 5 | Liés à l’exécution en échec |
| Environnement | Exécutions | Réussi | Échoué | Bloqué | Ignoré | Taux de réussite |
|---|---|---|---|---|---|---|
| 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% |
| Module | Cas | Exécutions | Réussis | Taux de réussite |
|---|---|---|---|---|
| API | 5 | 129 | 123 | 95.3% |
| Catalogue | 8 | 118 | 112 | 94.9% |
| Notifications | 5 | 99 | 93 | 93.9% |
| Administration | 6 | 62 | 56 | 90.3% |
| Recherche | 6 | 143 | 128 | 89.5% |
| Authentification | 10 | 193 | 172 | 89.1% |
| Passage en caisse | 8 | 131 | 114 | 87.0% |
| Commandes | 6 | 89 | 73 | 82.0% |
| Panier | 8 | 143 | 116 | 81.1% |
| Paiements | 8 | 135 | 103 | 76.3% |
Dans Redmine, les mêmes chiffres apparaissent sur le tableau de bord (anneau de taux de réussite, répartition des résultats, tendance sur 14 jours, couverture par module et par composant) et dans les rapports tabulaires, chacun avec export CSV et Excel.
Conçu autour d’une règle : un cas de test n’est jamais dupliqué
Cas de test réutilisables
Titre, prérequis, étapes structurées avec résultats attendus, module, composant, priorité, sévérité, type et étiquettes. Clonez, modifiez en masse, importez et exportez.
Des versions qui protègent l’historique
Modifier un cas déjà exécuté crée une nouvelle version. Les anciennes exécutions continuent de pointer vers les étapes réellement exécutées.
Revue et approbation
Brouillon, en revue, approuvé, obsolète. Chaque décision est enregistrée avec relecteur, date et commentaire, et l’auteur est notifié.
Lots, plans et campagnes
Les lots regroupent des cas pour les réutiliser. Les plans cadrent une version ou un sprint par rapport à une version Redmine. Les campagnes enregistrent une session sur un build.
Un panneau de tests sur chaque demande
Cas affectés, derniers résultats, taux de réussite, défauts liés et enregistrement en un clic, sur les trackers de votre choix.
Des exécutions auditables
Chaque exécution ajoute un enregistrement avec résultat, mode, environnement, build, commit, durée, résultats par étape, journal et captures d’écran. Rien n’est écrasé.
Tests pilotés par les données
Des jeux de données réutilisables aux colonnes nommées. Rattachez-les à des cas ou à des lots entiers, et enregistrez la ligne utilisée par chaque exécution.
Correspondance d’automatisation et CI/CD
Associez un cas à un framework et à un identifiant que votre runner comprend, puis laissez le pipeline récupérer ce qu’il faut exécuter et publier les résultats.
Tableau de bord et douze rapports
Un tableau de bord que chaque utilisateur compose à partir de huit widgets, plus des rapports de maturité, de couverture, de tendance, d’environnements, de défauts et de suivi.
Quatre petits cycles de vie, tous visibles à l’écran
| Objet | Parcours principal | Autres états |
|---|---|---|
| Cas de test | Brouillon → En revue → Approuvé | Modifications demandées, Obsolète |
| Plan de test | Brouillon → Actif → Terminé | Archivé |
| Campagne de test | Planifiée → En cours → Terminée | Abandonnée |
| Résultat d’exécution | Réussi, Échoué, Bloqué ou Ignoré | Non exécuté. Chaque résultat est enregistré comme manuel ou automatisé. |
Votre pipeline demande quoi exécuter, puis rend compte
L’API REST se trouve sous /testcases/api/v1 et s’authentifie avec une clé d’API Redmine ordinaire. Tout ce qui peut envoyer une requête HTTP peut l’utiliser. Un guide intégré au plugin détaille la configuration, avec vos propres URL déjà renseignées.
| Méthode | Point d’accès | Rôle |
|---|---|---|
| GET | /issues/:id/testing | Quoi exécuter pour une demande |
| POST | /executions/upload | Résultats d’un build pour une demande |
| POST | /executions/bulk_upload | Résultats pour plusieurs demandes ou builds |
| POST | /test_runs | Créer une campagne pour ce build |
| POST | /test_runs/:id/results | Envoyer des résultats dans une campagne |
| GET | /test_cases | Lister, créer et modifier des cas |
| GET | /test_plans | Lister, créer et modifier des plans |
| GET | /issues/:id/coverage | Couverture de test d’une demande |
| GET | /reports/:name | N’importe quel rapport en JSON |
| GET | /dashboard | Indicateurs agrégés |
Publier les résultats d’un build
Envoyez en POST l’identifiant de la demande, le numéro de build, le SHA du commit, l’environnement et une liste de résultats vers /executions/upload. Les résultats sont rapprochés des cas par identifiant d’automatisation, identifiant de cas ou référence, et chacun devient une nouvelle exécution. Les noms de résultats sont normalisés : les passed, failure et ignored de votre runner sont tous correctement interprétés, et un résultat en échec envoyé avec create_defect ouvre une anomalie liée.
Dix-huit permissions sur un seul module de projet
Tests est un module de projet Redmine standard. Activez-le là où vous testez, et donnez à chaque rôle uniquement ce dont il a besoin. Les onglets du menu suivent les permissions.
| Rôle | Permissions types | Ce qu’il fait |
|---|---|---|
| Responsable QA | manage_test_cases, approve_test_cases, manage_test_bundles, manage_test_plans, assign_test_bundles | Gère la bibliothèque, approuve les cas, compose les lots et les plans de version |
| Testeur | view_test_cases, execute_tests, manage_test_runs, manage_test_data | Exécute les tests, enregistre les résultats, tient à jour les données de test |
| Ingénieur en automatisation | manage_test_automation, view_test_executions | Associe les cas aux frameworks et aux identifiants |
| Développeur | view_test_cases, view_test_executions, view_test_runs | Voit ce qui est testé sur une demande et pourquoi le test a échoué |
| Chef de projet | view_test_reports, view_test_plans | Consulte les rapports de maturité, de couverture et de suivi |
| Compte de service CI | upload_test_results | Publie les résultats avec sa clé d’API, rien d’autre |
| Administrateur | admin_testing_settings, manage_test_environments | Préfixes, environnements, objectifs et règle de fermeture |
Fonctionne là où votre Redmine tourne déjà
| Environnement | Statut | Remarques |
|---|---|---|
| Redmine 7.x | Compatible | |
| Redmine 6.1 | Compatible | Cible de développement, sur Rails 7.2 et Ruby 3.4. Les captures d’écran de cette page viennent de la 6.1.2. |
| Redmine 6.0 | Compatible | |
| Redmine 5.x | Compatible | 5.0 est la version minimale déclarée par le plugin |
| MySQL 8 | Compatible | Utilisé pour le développement et pour la démo de cette page |
| Trackers de demandes | Les vôtres | Fonctionne avec n’importe quelle configuration de trackers. Limitez le panneau de tests à certains trackers, ou laissez-le sur tous. |
| Gems supplémentaires | Une, facultative | roo, uniquement pour importer des fichiers .xlsx et .xls |
Installation en trois étapes
Nécessite un accès shell et la possibilité de lancer des tâches rake. Sauvegardez toujours avant d'installer un plugin.
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
Ajoute-t-il ses propres trackers d’exigences, de stories ou d’anomalies ?
Que deviennent les anciens résultats quand quelqu’un modifie un cas de test ?
Un test en échec peut-il empêcher la fermeture d’une demande ?
Avec quels systèmes de CI fonctionne-t-il ?
Les échecs peuvent-ils créer des anomalies automatiquement ?
Peut-on reprendre des cas de test depuis un tableur ?
Les chiffres de cette page sont-ils réels ?
Tarifs
Un serveur
Une instance Redmine · utilisateurs illimités · 12 mois de mises à jour.
Plusieurs serveurs
Serveurs Redmine illimités · utilisateurs illimités · 12 mois de mises à jour.
Besoin d'une solution Redmine sur mesure ?
Vous cherchez une fonctionnalité absente de nos plugins ?
RedmineKit développe des plugins Redmine sur mesure, personnalise des plugins existants, automatise vos workflows, intègre des outils tiers et conçoit des solutions adaptées à votre entreprise.
Dites-nous ce dont vous avez besoin. Nous étudierons vos besoins et vous proposerons une solution adaptée, avec un coût et un délai estimés.