1) Les contrôles, les tests des ensembles matériels et logiciels visent à déterminer s’ils sont conformes aux spécifications convenues, s’ils sont utilisables dans les conditions attendues. Ils portent sur les ensembles matériels et logiciels eux-mêmes, leurs éléments constitutifs, ou sur les éléments associés (documentation, gestion de configuration…).
Ils sont réalisés par les donneurs d'ordres, les utilisateurs, les responsables techniques.
Ils sont planifiés dans le cycle de réalisation de l’activité (par exemple l’ingénierie, le déploiement), ou effectués en cours d’utilisation, ou à une date définie par un responsable autorisé.
2) Des processus sont à définir pour réaliser ces contrôles et tests.
On distingue les contrôles statiques, qui consistent à examiner, analyser les matériels, le code source, des documents, le contenu de fichiers, et les contrôles et tests dynamiques, qui sont fondés sur une mise en fonctionnement dans un environnement de test ou de production, à partir de données de test ou réelles.
Les principaux contrôles et tests sont fonctionnels, de capacité, de performances, de sécurité, d’adaptabilité, d’exploitabilité, de maintenabilité, d’évolutivité.
En cas de modification, les tests de non-régression visent à vérifier que les fonctions non modifiées continuent à être exécutées de façon correcte. Des choix sont à faire sur leur taux de couverture. Théoriquement, tous les tests mettant en œuvre les éléments constitutifs modifiés sont à refaire complètement. Dans la pratique, compte tenu de la charge que cela représente, sauf si les tests sont complètement automatisés, le périmètre testé est plus restreint, défini de façon empirique, ce qui présente des risques sur la fiabilité.
La charge de contrôle et de test est parfois considérable, étant donné le très grand nombre des possibilités, des contextes d'utilisation. Les systèmes auto-apprenants, qui ont des propriétés très intéressantes, sont très difficiles, voire impossibles à tester complètement.
3) Une stratégie de contrôle et de test est à établir s’il y a lieu par le donneur d'ordres et par les responsables techniques. Elle contribue à garantir la qualité des ensembles matériels et logiciels livrés, mis à disposition. Elle est intégrée à la démarche globale de réalisation des activités.
Elle définit les éléments à contrôler, à tester, la nature des contrôles et tests prévus, leur étendue, leur volume, leur planification, leur périodicité, leur taux de couverture, leur niveau de profondeur, leur responsabilité, les démarches, méthodes, outils...
Entre le donneur d’ordres et les responsables techniques, un équilibre est à trouver en termes d’efficacité, de charge, coûts et délais de réalisation, de respect des responsabilités et de collaboration nécessaire entre les acteurs.
Le mouvement DevOps préconise la réalisation des tests de logiciels au plus tôt, dans un environnement aussi proche que possible de la production.
Des bêta-tests sont réalisables par des utilisateurs extérieurs à l'entreprise, avant le lancement commercial d'un produit, d'un logiciel, d'un service numérique. Des déploiements sur sites pilotes sont parfois à effectuer avant le déploiement général.
4) Des choix sont à faire sur les outils de réalisation des tests.
Des environnements techniques dédiés sont utilisables : développement, intégration, pré-production, recette... Les environnements d'intégration permettent de tester l'interopérabilité d'équipements provenant de constructeurs différents.
Il existe des outils d'automatisation de l'exécution des tests fonctionnels, de comparaison automatique des résultats obtenus aux résultats attendus.
Fonctionnalités
1) Les activités d’ingénierie, de maintenance, de déploiement, de fabrication, comportent des tests fonctionnels. Des anomalies des systèmes en fonctionnement sont également identifiées par les utilisateurs.
Il est en général impossible de tester l’ensemble des cas possibles d’utilisation des ensembles matériels et logiciels. Il est envisageable de définir un ensemble de cas de test permettant une vérification suffisante, pour des coûts et des délais acceptables. En ce qui concerne le nombre de cas de test à retenir, une démarche possible de choix est fondée sur la conservation d’un historique des tests effectués dans des contextes comparables, sur les résultats obtenus, sur l’expérience des intervenants.
Beaucoup d’entreprises considèrent que les modifications fonctionnelles des SI ne sont pas suffisamment testées.
2) La préparation des tests fonctionnels est réalisable au départ à partir des spécifications fonctionnelles détaillées. Leur taux de couverture est améliorable en demandant au donneur d’ordres de fournir des cas de test « métier ».
Dans les méthodes de développement "test driven", les tests fonctionnels des logiciels sont préparés avant le début de la programmation.
Des IA génératives sont utilisables pour préparer des scénarios de test.
Des contrôles des performances sont parfois réalisés sur les environnements de production.
Des tests de charge, de performances, sont parfois à réaliser pour les ensembles matériels et logiciels.
Pour les SI, les logiciels d'utilisation collective, des choix sont à faire sur les environnements techniques à mettre en place, les outils à utiliser. Les environnements techniques sont normalement identiques ou comparables aux environnements de production. Des robots de tests, des outils d'analyse des performances sont parfois utilisés.
La préparation des tests de charge, de performances des SI, est souvent effectuée à partir de données réelles, ou d’extractions de données réelles. Il est en effet difficile, coûteux de créer ex nihilo des bases de données, des fichiers de test volumineux et représentatifs de l’utilisation future des SI.
Les constructeurs d’ordinateurs réalisent parfois des tests de charge à partir d’applications qu’ils considèrent comme représentatives.
Des tests spécifiques de résistance des SI aux intrusions, aux attaques, sont réalisables, à base de tentatives de « casser » les protections mises en place.
Plusieurs environnements cibles sont parfois définis pour les ensembles matériels et logiciels. Des tests de configuration sont à faire dans tous les environnements prévus.
L’adaptabilité, l’exploitabilité, la maintenabilité, l’évolutivité des ensembles matériels et logiciels sont susceptibles d’être contrôlées a priori à partir de :
– des tests des fonctions de paramétrage, d’exploitation… ;
– l’examen de la documentation de paramétrage, d’exploitation, de maintenance/évolution ;
– un audit de configuration ;
– des analyses du code source (structuration, respect des normes de programmation…) ;
– un contrôle des fichiers de test…
Ces contrôles sont à effectuer sur la base des exigences définies dans ces domaines.
Aucun commentaire:
Enregistrer un commentaire