Cahier de tests pour les RC

Dans le monde du développement logiciel, une bonne pratique est de disposer d’un cahier de tests lorsque l’on a une nouvelle version d’un logiciel à mettre à disposition des utilisateurs.

Pour quoi faire ?

Ce cahier liste des fonctionnalités à tester qui n’ont pas pu l’être de façon automatisée, ou bien qui l’ont été mais dans un environnement trop éloigné de la production et donc trop éloignée des conditions réelles. Son but est de valider le bon fonctionnement du logiciel, afin d’éviter que les utilisateurs s’y cassent les dents :slight_smile: (car de toute façon, les bugs, ils vont les trouver : mais autant qu’ils trouvent les moins évidents !).

Où ça ?

J’ai commencé à initier un tel cahier il y a 5 mois, disponible ici : cahier de tests Duniter.

Qui peut participer ?

Je ne suis pas du tout spécialiste des tests, alors j’aurai bien besoin que vous m’aidiez dans cette tâche de listage et rédaction. N’importe qui peut participer, même les non spécialistes. Typiquement, si vous êtes utilisateur, vous avez certainement votre mot à dire, ayant une certaine expérience à utiliser des logiciels.

Il ne s’agit pas de dire qu’il manque au logiciel telle ou telle fonctionnalité, mais de dire « le logiciel est censé faire telle ou telle chose » conformément à ce qui a été annoncé par les développeurs.

Or lister tout ce que doit faire le logiciel, ce peut-être long ! Et être exhaustif est toujours délicat. Donc, toute aide est la bienvenue.

Comment ?

Je vous propose de participer en répondant à ce fil. Je mettrais à jour le fichier au fur et à mesures de vos réponses. Je souhaite faire ce cahier en français, et éventuellement nous le traduirons plus tard, car nous faisons tout cela principalement pour le développement de la Ğ1 qui est très largement utilisée par des francophones.

5 « J'aime »

Je vais considérer qu’on repart de zéro. Aussi, je propose que l’on divise ce cahier en plusieurs parties. Je propose déjà les quatre suivantes pour lesquelles je donne des exemples :

Installation

[…]

Commandes (duniter-server)

reset data

Vide le dossier de données de ses fichiers duniter.db, wotb.bin, […].

direct_start

Lance le programme en mode interactif (ne rend pas la main), et démarre le cycle de vie du nœud.

[…]

Interface graphique (duniter-desktop)

Démarrage

Conditions : le dossier $HOME/.config/duniter/duniter_default n’existe pas.

Le programme se lance et ouvre une fenêtre qui affiche éventuellement “The server is starting…”, puis l’écran « Initialisation du nœud » s’affiche.

[…]

Transverse

Mémoire

Le nœud Duniter ne doit pas dépasser :

  • les 200 Mo d’utilisation pour duniter-server
  • les 500 Mo d’utilisation pour duniter-desktop [à vérifier]

Maintenant je vais commencer à exprimer quelques tests importants qui me viennent à l’esprit :

Installation

  • Taille du fichier
    • La taille du fichier duniter-server .deb x64 ne doit pas dépasser 50 Mo
    • La taille du fichier duniter-server .deb ARM ne doit pas dépasser 50 Mo
    • La taille du fichier duniter-desktop .deb x64 ne doit pas dépasser 120 Mo
    • La taille du fichier duniter-desktop .tar.gz x64 ne doit pas dépasser 120 Mo
    • La taille du fichier duniter-desktop .exe x64 ne doit pas dépasser 90 Mo
  • Utilisabilité
    • Le programme duniter-server est utilisable sur Debian avec le paquet .deb x64
    • Le programme duniter-desktop est utilisable sur Debian avec le paquet .deb x64
    • Le programme duniter-server est utilisable sur sur ARM avec le paquet .deb ARM
    • Le programme duniter-desktop est utilisable sur GNU/Linux avec le paquet .tar.gz x64
    • Le programme duniter-server est utilisable sur GNU/Linux par compilation manuelle
  • Dossiers d’installation
    • L’installation de Duniter ne crée pas de dossier $HOME/.config/duniter
    • Le paquet Debian remplace tout le contenu du dossier /opt/duniter

Interface graphique

  • La nouvelle version s’affiche bien dans la barre de titre
  • Lorsque la fenêtre (duniter-desktop exclusivement) est redimensionnée, l’application conserve ces dimensions même après un redémarrage du logiciel.
  • [Home] Changer pour une version plus récente conserve les données (nom de monnaie, current block, …)
  • [Home] La tuile [Connected peers] s’incrémente rapidement à une valeur positive après le démarrage
  • [Home > Network > WS2P Connections] Le nœud se connecte bien au réseau, avec des connexions entrantes (INCOMING) et/ou sortantes (OUTCOMING) selon la configuration réseau demandée.
  • [Home > Network > WS2P Connections] Le nœud liste les nœuds privilégiés sur fond violet
  • [Home > Network > WS2P Connections] Le nœud liste les nœuds préférés sur fond vert
  • [Home > Network > Network view] En version >= 1.6, le nœud est visible dans la liste.
  • [Home > Network > Network view] En version >= 1.6.15, le nœud affiche une valeur pour la colonne [Step]
  • [Home > Network > Network view] En version >= 1.6.15, le nœud affiche une valeur “WS2P[O…][I…]” pour la colonne [API]
  • [Home > Network > Network view] En version >= 1.6.15, le nœud affiche une valeur pour la colonne [Free Rooms]
  • [Home > Network > Network view] En version >= 1.6.16, le nœud modifie la valeur de la colonne [Free Rooms] à mesure que des connexions entrantes (INCOMING) s’ajoutent à la liste [WS2P Connections] et à l’occasion d’un changement de valeur du champ [HEAD] (se produit lorsqu’un nouveau bloc arrive).
  • [Settings > Network]

Transverse

  • Le nœud reste synchronisé avec le réseau, et reçoit en quasi temps-réel les nouveaux blocs.
  • Le nœud reçoit correctement les transactions, et tente de les inclure dans un bloc.
  • Le nœud ne dépasse pas, pendant toute son utilisation, les seuils de mémoire suivants :
    • 250 Mo d’utilisation pour duniter-server
    • 350 Mo d’utilisation pour duniter-desktop

Rien que faire ces tests, ça devrait nous calmer et éviter qu’on sorte des versions à tout bout de champ :grin:

J’ajouterai :

  • le noeud se resynchronise de lui même au réseau, même des dizaines de jours après avoir été déconnecté
  • un noeud fraichement installé peut se resynchroniser au réseau via la commande sync
1 « J'aime »

je confirme j’ai déjà rattraper 7000 blocs de retard une fois juste via ws2p donc sans sync (soit environ 3 semaines de retard)

11 messages ont été déplacés vers un nouveau sujet : Connectivité WS2P

Autre règle :

Le nœud doit effectivement calculer plusieurs blocs.

1 « J'aime »

@cgeek @Inso @jytou @nanocryk @vit @gerard94 et tout les testeurs, je viens de créer une issue qui sert de cahier des tests collaboratif pour la 1.6.17, merci d’y cocher ce que vous avez tester, ou de répondre en commentaire de l’issue si vous n’avez pas les droits pour la modifiée !

Merci pour votre aide :slight_smile:

2 « J'aime »

Bon ça y ai je crois avoir recopier toutes les règles et devinez quoi !? On a pile 42 cases a cocher :rofl:

5 « J'aime »

Tip top ce cahier, en plus avec GitLab on a un suivi très précis de qui a fait quoi ! J’aime !

2 « J'aime »