7.1 KiB
-
- 4.1. Stratégie de test
- 4.2. Plan pour les tests unitaires
- 4.3. Plan d'intégration
- 4.4. Plan de charge
1. Documents de référence
Voir _Doc_references.md.
2. Gestion des erreurs
Les processus doivent continuer malgré des "sous" traitements/threads en échec et les fonctions doivent être catch si il y a une possiblité d'interuption.
Stratégie de gestion des erreurs et de reporting pour faciliter le débogage et améliorer la résilience du système.
Tous les flux sont reçus par autant de relais et de membres de même rôles. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable par chacun de façon autonome en rapport à sa propre expérience.
Les arrêts de la blockchain dans son ensemble n'entraînent pas d'interruption de service, car les horodatages sont non bloquants, l'impact est une diminution de la preuve le temps de "ré-ancrer" ce qui n'aurait pas pu l'être. L'arrêt de nœuds de la blockchain pourrait ralentir la propagation des informations dans les scénarios les plus critiques, sans impact majeur sur le fonctionnement.
Les arrêts des membres dans les ItemProcess dans leur ensemble n'entraînent pas d'interruption de service, les confirmations restent en attente, toujours relayées jusqu'au rétablissement des services. L'arrêt de membres des rôles critiques des ItemProcess pourrait empêcher le démarrage des services et pour les gestionnaires des membres, l'accès au réseau pour les utilisateurs n'ayant qu'un processus connu avec un rôle dedans. Cela n'entraîne pas une perte des données. Cette incapacité pourrait venir corrompre des signatures attendues dans un délai. Dans ce cas, le rôle "resolve" des ItemProcess est en charge de l'arbitrage pour la bonne restitution des actions.
Les parties prenantes ont tous les moyens organisationnels dans les process, pour procéder au bon redémarrage des services en cas de dégradations et de situations inattendues, avec le versionning des relais et des membres des rôles; ainsi que des conditions contractuelles avec leurs implications opérationnelles et possiblement économiques.
3. Journalisation et monitoring
Tous les utilisateurs reçoivent les mêmes flux qu'ils se relaient et se restituent au démarrage, tous les flux ont une empreinte horodatée sur une timechain et peuvent être demandés unitairement entre parties, avec le même niveau de confidentialité par rôles. Les Pcd sont les listes à jour de l'état de validation de tous les éléments échangés, et les Prd sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un ItemProcess (possible de segmenter par zones et services).
Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents sur les relais qui ne sont pas critiques unitairement, tous les flux sont fongibles, chiffrés, anonymes, et peuvent passer par des relais non révélés. Cependant, l'optimisation des listes de pairs et de contrats, pourrait passer par un système de réputation qui nécessitera un historique. À ce stade, la gestion "qualitative" et "quantitative" des relais et des contrats est gérée en mémoire, non persistée et restaurée par chaque connexion à un nouveau pair.
La timechain permet de monitorer l'activité générale sur la side chain avec un nombre de jetons échangés (le même nombre à chaque message) et des ancrages critiques sont monitorables sur le mainnet publiquement par n'importe qui (mais non exploitable fonctionnellement). Ainsi seul le bon fonctionnement est monitorable, par tous, facilement, sans métadonnées exploitables pour ce qui est des usages qui restent donc confidentiels.
4. Tests
4.1. Stratégie de test
À l'issue du développement en ScrumBan, chaque ticket fait l'objet d'une revue de code, et d'un test par un testeur.
4.2. Plan pour les tests unitaires
Les tests unitaires seront ajoutés par un testeur, ainsi toutes les fonctionnalités reçues auront un test unitaire.
4.3. Plan d'intégration
L'intégration se réalise par sprint hebdomadaire.
L'ensemble des fonctionnalités livrées dans le sprint doivent être testées dans un parcours d'intégration écrit et testé par un testeur en fin de sprint.
4.4. Plan de charge
Tous les 2 sprints, des tests aux limites sont définis et mis en œuvre par un testeur depuis la simulation des comportements des utilisateurs.
5. Outils et les librairies à utiliser
Respect des normes de syntaxe Rust.
Utilisation de Visual Studio (pour le partage de configurations).
À l'étude : revues et pilotage par la documentation depuis une IA et partage d'un chat IA pour la base de connaissance.
-
Environnement : navigateur (tous dispositifs), et relais sous Debian.
-
Développement : en Rust pour compilation Wasm.
-
Pas de base de données sauf IndexedDB présent nativement pour les navigateurs et les applications mobiles.
-
Librairies :
rust-bitcoin,rand,hex,bech32,shamir_secret_sharing,uuid,sha2,chrono,aes-gcm,base64,wasm-bindgen,serde,serde_jsondans leurs dernières versions. -
Librairies de tests : Cargo test
6. Critères d'acceptation
Critères de validation pour que le système puisse être considéré comme prêt pour la production :
- Tous les parcours utilisateurs fonctionnels.
- Tous les tests unitaires présents et parcourus.
- Tous les tests d'intégration présents et parcourus.
- Aucun bug bloquant.
- 10 bugs majeurs.
- 20 bugs mineurs.
- Contrôles manquants clairement précisés.
- Documentation manquante clairement précisée.
- Autres tests manquants clairement précisés.
7. CI/CD
GitLab CI : TBD
8. Maintenance
La liste des dépendances doit être maintenue dans le readme des projets, mise à jour à chaque fin de sprint. Les tests de fin de sprint doivent intégrer une revue des dernières versions et alertes sur les librairies en dépendance.