6761 Validation de la conformité. Vérification et cycle de vie du logiciel. 6.4 Processus de vérification (1)

Dimension: px

Commencer à balayer dès la page:

Download "6761 Validation de la conformité. Vérification et cycle de vie du logiciel. 6.4 Processus de vérification (1)"

Justin Bastien
il y a 7 ans
Total affichages :

1 6761 Validation de la conformité Peter DAEHNE Vérification et cycle de vie du logiciel Norme ISO Novembre Processus de vérification Vérification du code Vérification de l intégration Peter DAEHNE Processus de vérification (1) Vérification du code La traçabilité du code est assurée par rapport à sa conception et aux exigences, le code est testable, correct et conforme aux exigences, et aux normes de codage; le code est complet et met en œuvre correctement les séquences d événements, les interfaces cohérentes, les données et les flux de contrôle, les budgets alloués en temps et en taille, et la définition, le traitement et la reprise des erreurs; le code peut être déduit de la conception ou des exigences; le code met correctement en œuvre les exigences de sûreté, de sécurité et d autres exigences critiques comme le démontrent des méthodes suffisamment rigoureuses. Peter DAEHNE -3-1

5 Vérification du code La traçabilité du code est assurée par rapport à sa conception et aux exigences, le code est testable, correct et conforme aux exigences, et aux normes de codage; le code est

2 6.4 Processus de vérification (2) Vérification de l intégration Les composants et les éléments de chaque élément de logiciel ont été correctement et complètement intégrés dans l élément logiciel; les éléments de matériel, de logiciel et les opérations manuelles du système ont été correctement et complètement intégrés dans le système; les tâches d intégration ont été mises en œuvre conformément au plan d intégration. Peter DAEHNE -4- Les différents types de tests Tests unitaires Tests des modules fonctionnels Tests d intégration Tests d acceptation Tests de non régression Tests de stress Tests de redémarrage Peter DAEHNE -5- Tests unitaires Les composants de l application sont testés individuellement. Conduits par le développeur lui-même, ils permettent de détecter et de corriger les erreurs de codage. Les tests de chaque unité doivent être documentés: la procédure de test, les données employées, les situations testées ainsi que les résultats attendus doivent faire l objet d une description. Les cas de test doivent être conçus pour détecter les erreurs éventuelles et non pas pour montrer que l unité fonctionne comme décrit. Le test unitaire est la première et la meilleure occasion de mettre en évidence des erreurs de codage. Peter DAEHNE -6-2

6 Vérification de l intégration Les composants et les éléments de chaque élément de logiciel ont été correctement et complètement intégrés dans l élément logiciel; les éléments de matériel, de

3 Tests des modules fonctionnels Lors de cette phase, on teste les entités fonctionnelles de l application: les modules. Ceux-ci sont constitués d un assemblage de composants. On se trouve donc au premier niveau d intégration des unités individuelles. En général, c est également le développeur qui conduit ces tests, car ils nécessitent une bonne visibilité des choix d implantation et un accès au code source des composants du module. Les erreurs détectés sont plus globales, elles affectent en général plusieurs composants. Les erreurs les plus communes concernent l interfaçage des différentes unités et les choix de structures de données. Des défauts de conception et de spécifications peuvent également être détectés à ce stade. Les procédures de test doivent être documentées. Peter DAEHNE -7- Tests d intégration Les tests d intégration commencent lorsque les différents modules fonctionnels de l application commencent à être testés ensemble. Ces tests sont en général conduits par une tierce personne. Ce sont des tests purement fonctionnels qui ne nécessitent aucune connaissance de la structure du code lui-même. Ils sont dirigés par la conception détaillée et l architecture définies lors de l analyse. Les erreurs détectées à ce stade concernent plus particulièrement l interfaçage des différents modules ainsi que des problèmes de base de données. Les conditions et données de test sont semblables à celles employées lors du test des modules fonctionnels. On cherchera plus particulièrement à mettre le système dans des états invalides ainsi qu à en vérifier les performances. Peter DAEHNE -8- Tests d acceptation Le système final est testé complètement de manière à démontrer qu il satisfait bien aux spécifications. Le plan de test est construit sur la base des spécifications qui ont été définies et acceptées par le client. Autant que faire se peu, ce test devrait être effectué par le client. On vérifie également que le système développé s intègre bien à la séquence de tâches prévues pour le poste de travail et que les responsabilités n ont pas changé de personne. C est la dernière étape avant la livraison du système au client. Peter DAEHNE -9-3

En général, c est également le développeur qui conduit ces tests, car ils nécessitent une bonne visibilité des choix d implantation et un accès au code source des composants du module.

4 Tests de non régression Les tests de non régression vérifient qu une modification d une partie du système n invalide pas les autres parties. Il s agit en général d un sous-ensemble des tests d acceptation. On fournit des données valides au système pour vérifier le fonctionnement de l ensemble de ses éléments. Des études montrent que plus de 50% des modifications d un système conduisent à l introduction de nouvelles erreurs. Le processus de gestion du changement doit administrer la trace des modifications et la documentation qui y est associée. Peter DAEHNE -10- Tests de stress Les tests de stress permettent d étudier le comportement du logiciel lorsque celui-ci est mis dans des situations extrêmes, aux limites de ses capacités. Exemples: À la fin de la journée, lorsque l heure passe de 23:59:59 à 00:00:00, le système doit reconnaître que 00:00:00 est plus tard que 23:59:59 ou encore problème de l an Si le système est prévu pour traiter au maximum n transactions simultanées, que se passe-t-il si on lui en soumet n+1 ou n+2? Que se passe-t-il si le système est en fonction pendant une grande période de temps sans redémarrage? Peter DAEHNE -11- Tests de redémarrage Les tests de redémarrage permettent de vérifier le comportement du système après une fin anormale telle que le crash du système après une panne de courant par exemple. Ils comprennent également la vérification du fonctionnement correct de la procédure de backup-restore. On vérifie que le système continue de fonctionner correctement après une procédure de restauration des informations. Ces tests peuvent la plupart du temps être effectués au moyen de la procédure de test de non régression ou encore de celle du test d acceptance. Peter DAEHNE -12-4

Des études montrent que plus de 50% des modifications d un système conduisent à l introduction de nouvelles erreurs.

5 Qui effectue les tests? Type de test Debugging du code Tests unitaires Tests des modules fonctionnels Tests d intégration des modules Tests d intégration des ss-systèmes Tests du système complet Tests d acceptation Autres tests Testeur Tierce personne (Qualité) Tierce personne (Qualité) Groupe de test développement Groupe de test utilisateurs Groupe de test développement Peter DAEHNE -13-5

des modules Tests d intégration des ss-systèmes Tests du système complet Tests d acceptation

Documents pareils

exigences des standards ISO 9001: 2008 OHSAS 18001:2007 et sa mise en place dans une entreprise de la catégorie des petites et moyennes entreprises.

exigences des standards ISO 9001: 2008 OHSAS 18001:2007 et sa mise en place dans une entreprise de la catégorie des petites et moyennes entreprises. R E S U M E de la Thése de doctorat Perfectionnement du systemé de management intégré qualité-responsabilité sociale-santé et sécurité occupationnelle élaborée par Monsieur le thésard Denuntzio C. Romeo,