Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et.

Présentation au sujet: "Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et."— Transcription de la présentation:

1 Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique Vincent.roberge@rmc.ca roberge.segfaults.net PPL25-VerificationCycleVie.pdf

2 Aperçu Vérification dans le cycle de vie Besoins design Mise en œuvre Maintenance Stages de tests Tests utilisateurs Tests d'unités Tests d'intégration Tests aux marges Tests de réception Tests de système 2 Automne 2014GEF492

3 Les tests dans le cycle de vie du logiciel 3 Automne 2014GEF492 L’identification des besoins du système L’identification des besoins du logiciel L’analyse Le design Le testage Le codage La maintenance Imaginez que ce processus est placé sur un calendrier et pensez comme un gestionnaire. Quel est le problème?

4 Besoins & vérification Activités concevoir une stratégie de test – un plan déterminer les exigences de tests (ressources, outils, …) préparer les cas de tests fonctionnels Vérifier les besoins en terme de complétude – évident mais difficile à vérifier, les scénarios utilisateurs peuvent aider à identifier les omissions cohérence – on vérifie que les besoins ne se contredisent pas et ne contredisent pas une interface faisabilité – analyse de risques visant à déterminer la rentabilité selon facteurs clés (sécurité, vitesse, fiabilité) testabilité – les besoins doivent être spécifiques, non- ambigües, et quantitatif pour pouvoir être testés 4 Automne 2014GEF492

5 Design & vérification Activités vérification de la cohérence entre les besoins et le design préparation de tests fonctionnels et structurels plus détaillés vérification de l'architecture et du design Vérification de l'architecture selon les changements – la facilité de maintenance et la flexibilité sont mesures du niveau avec lequel la fondation de design peut changer Vérification du design selon complétude, cohérence, faisabilité et testabilité similaire à la vérification des besoins des outils de pointe peuvent supporter la vérification à l'aide de design exécutables 5 Automne 2014GEF492

6 Mise en œuvre & Vérification Activités vérifier la cohérence entre design et implémentation génération de données de tests fonctionnels et structurels vérification de la mise en œuvre; tests exécutables Vérifier la mise en œuvre selon Le design (et ultimement contre les besoins) La vérification peut être: statique – inspections de code et révision structurées dynamique – tests exécutables Les outils de test et l'automation sont critiques générateurs de tests, souche, polices, comparateurs (JUnit) 6 Automne 2014GEF492

7 Maintenance & vérification Activités maintenir les tests et outils de développement tests de régression Vérifier les changements selon nouveaux besoins, ou besoins changés système qui fonctionnait au préalable Des tests de régression bien conçus sont essentiels afin d'éviter une approche "re-test en entier" En réalité, la maintenance du code commence pendant le développement on doit être prêt à supporter la vérification pour maintenance 7 Automne 2014GEF492

8 STADES DE TESTS Au travers des activités du processus, les tests sont fait selon plusieurs stages 8 Automne 2014GEF492

9 Test utilisateurs tests de prototypes conçus afin de valider les interfaces utilisateurs éliciter ou améliorer la compréhension des besoins doit être fait assez tôt dans le processus afin d'incorporer les résultats dans le produits ou assez souvent afin de bien guider les développements itératifs 9 Automne 2014GEF492

10 Tests d'unité tests d'un module, d'une classe ou d'une unité en soi – basé sur la spécification du module normalement effectué par le développeur responsable les tests doivent inclure flux de données aux interfaces structure de données locales et accès aux structures globales couverture sélective de chemins d'exécution tests aux bornes premier et dernier élément, première et dernière itération, etc 10 Automne 2014GEF492 Catalog_Item attribut1 attribut2 methode1 methode2 methode3

11 Tests d'intégration Montant on test les modules du "bas" avec pilotes représentant le haut amasse les modules en grappes Descendant on test les modules du "haut" avec souches représentant le bas on enlève les souches lorsque les modules du bas sont prêts on peut ajouter les modules "bas" en profondeur ou en largeur 11 Automne 2014GEF492 USE X pilotes test USE souches tests 

12 Tests aux marges (Stress tests) Tests sous haute charge 100 demandes seconde 50 accès simulé à la base de de données relâchement de toutes tâches temps réels en même temps pour horaire On doit tester les systèmes avec besoins de charge sous charge Les scénarios de charge doivent être identifiés et supportés Demande souvent beaucoup de code de tests et d'équipement de soutient pour bien supporter. 12 Automne 2014GEF492

13 Stress Testing Tests sous haute charge 100 demandes seconde 50 accès simulé à la base de de données relâchement de toutes tâches temps réels en même temps pour horaire On doit tester les systèmes avec besoins de charge sous charge Les scénarios de charge doivent être identifiés et supportés Demande souvent beaucoup de code de tests et d'équipement de soutient pour bien supporter. 13 Automne 2014GEF492

14 Test Stages - Stress Testing Tests sous haute charge 100 demandes seconde 50 accès simulé à la base de de données relâchement de toutes tâches temps réels en même temps pour horaire On doit tester les systèmes avec besoins de charge sous charge Les scénarios de charge doivent être identifiés et supportés Demande souvent beaucoup de code de tests et d'équipement de soutient pour bien supporter. 14 Automne 2014GEF492

15 Tests de réception effectuer lorsque "le logiciel se comporte comme le client peut raisonnablement croire qu'il devrait se comporter" Qui décide de ce qui est raisonnable? les tests de réception démontrent la conformité avec les besoins les défaillances sont enregistrées comme déficiences et doivent ultimement être adressées si les besoins sont flous ou si la clientèle est difficile à identifier, on se sert de tests béta certains clients sont prêts à utiliser le produit et faire rapport de fautes en échange de l'utilisation précoce 15 Automne 2014GEF492

16 Tests de système le logiciel n'est qu'un élément du système. qui comprend également gens, procédures, données et matériel En fin de compte, c'est le système en entier qui doit fonctionner 16 Automne 2014GEF492

17 17 Références supplémentaires Roger S. Pressman. Software Engineering - A Practitioner’s Approach 5th Edition, Chapter 18. McGraw-Hill, 2001. ISBN 0-07-365578-3 Automne 2014GEF492

18 INSPECTIONS ET RÉVISION STRUCTURÉES Prochaine séance: Automne 2014GEF492 18