6761 – Validation de la conformité Vérification et cycle de vie du

6761 – Validation de la conformité
11.03.2009
Peter DAEHNE
http://www.hesge.ch/heg
Vérification et cycle de vie du logiciel
•
•
•
•
Norme ISO 12207 – Novembre 1995
6.4 Processus de vérification
6.4.2.5 Vérification du code
6.4.2.6 Vérification de l’intégration
Peter DAEHNE
-2-
http://www.hesge.ch/heg
6.4 Processus de vérification (1)
• 6.4.2.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 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-
http://www.hesge.ch/heg
1
6.4 Processus de vérification (2)
• 6.4.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 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-
http://www.hesge.ch/heg
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-
http://www.hesge.ch/heg
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-
http://www.hesge.ch/heg
2
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-
http://www.hesge.ch/heg
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-
http://www.hesge.ch/heg
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-
http://www.hesge.ch/heg
3
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 -
http://www.hesge.ch/heg
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 2000.
– 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 -
http://www.hesge.ch/heg
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 -
http://www.hesge.ch/heg
4
Qui effectue les tests ?
Type de test
Testeur
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
Développeur
Développeur
Développeur
Tierce personne (Qualité)
Tierce personne (Qualité)
Groupe de test développement
Groupe de test utilisateurs
Groupe de test développement
Peter DAEHNE
- 13 -
http://www.hesge.ch/heg
5