Test et assurance qualité : Focus Projet Outiz

Présentation au sujet: "Test et assurance qualité : Focus Projet Outiz"— Transcription de la présentation:

1 Test et assurance qualité : Focus Projet Outiz
Mohamed Amine belghit V1.0 – 18/04/2015

2 Historique des révisions
Historique des révisions du document Version Date Modifications Auteur 1.0 18/04/2015 Initialisation MABELGHIT 1.1 07/05/2015 Révision + Ajout des modifications © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

3 Sommaire Contexte Utilisation Granularité Plan de test Outils JUnit
JMeter Code coverage Techniques Boite noire Boite blanche Tests d’interface Mock Object Outiz Etat des lieux Limites et possibilités © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

4 Contexte La pratique du test, qu’il soit automatisé ou non, est une aide au développement et à la conception. Les méthodes agiles ont contribué à l’essor du test unitaire, de même que les Framework de test automatisé, JUnit en-tête. Tester veut dire évaluer les effets d’un changement. La conclusion est binaire : accepter ou rejeter. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

5 Contexte Agilité Utilisation
TDD est la discipline phare de l’extreme programming (XP). Le processus est simple : avant de coder une classe, on commence par coder les tests. L’un des intérêts majeurs du TDD est que le développeur doit comprendre, donc analyser la fonctionnalité en se concentrant sur les exigences qu’il doit implémenter pour écrire un test pertinent. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

6 Contexte Refactorisation Utilisation
Les méthodes agiles font grand usage de la refactorisation. Pratiquer la refactorisation peut introduire des régressions, en ce sens les batteries de tests automatisés, ou plan manuels, sont des outils de premier choix pour se prémunir des effets de bord imprévisibles. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

7 Contexte Intégration continue Utilisation L’intérêt de l’IC:
Les développeurs travaillent sur une base de code stable Les managers et les clients peuvent mesurer l’avancement concret du projet . Les architectes peuvent mesurer la qualité du code produit. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

8 Contexte GRANULARITE Tests d’acceptance
Les tests d’acceptance valident que le système fait bien ce qu’on exige de lui. Tests unitaires Les tests unitaires valident que les composants sont correctement codés, ces derniers se préoccupent que d’une seule classe et veillent au maximum à conserver leur isolement. Tests d’intégration Les tests d’intégration sont les tests au niveau composant, qui valident les interactions entre les objets et leur intégration. Tests d’acceptance : Couverture d’exigences par les tests © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

9 Contexte Smoke Testing Positive/Negative Testing Stress Testing
Plan de test Smoke Testing Positive/Negative Testing Stress Testing Plan de test est un document qui recense l’ensemble des tests d’acceptance et de scénarios pour une version donné du produit. Smoke Testing : On extrait entre 20 et 30 cas de tests basiques qui viennent de couvrir les fct principales sans entrer dans le détail. Positive/Negative testing : pour concevoir un plan de test, on calque les tests au exigences et on considère que tout se passe bien, Pour l’approche négativiste : on considere qu’on ne peut faire confiance à l’utilisateur et qu’il se debrouillera tjs pour entrer des données dans un format erroné, ou effectuer des enchainements d’écrans non autorisés, on s’assure que le sys réagit bien  Stress Testing : Dans les applications web ou distribuées, on exige qu’elle supporte une montée en charge conséquente, dc ce type de test éprouve la stabilité du système au delà de ses conditions normales d’utilisation. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

10 Outils JUNIT JMETER CODE COVERAGE
© SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

11 Techniques Boite noire
Tester en boite noire signifie n’utiliser que les fonctions de la classe pour tester celle-ci, et donc ne pas avoir connaissance a priori de son implémentation ni de ses membres privés. Exemple : Test en boite noire de la fonction delete : On s’assure que l’objet n’est pas présent dans le sys (à l’aide de la fct find) On utilise la fct create pour le sérialiser On s’assure qu’il existe bien On appelle la fct delete pour supprimer l’objet du système . On appelle une troisième fois find pour vérifier que la suppression est effective. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

12 TECHNIQUES Boite blanche
Le test en boite blanche signifie tester une classe en sachant son implémentation sous- jacente . Exemple : Vérifier qu’un DAO MY-SQL a bien sérialisé un objet en base de données en interrogeant directement celle-ci via une requête SQL et sans vous contenter des méthodes proposées par le DAO. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

13 Techniques Tests d’interfaces
Le mode boite noire permet de factoriser les tests. Exemple : Les tests définis dans CustomerDaoTest s’appliquent à l’interface CustomerDao et non à une implémentation concrète. Ces tests sont réutilisables tel quel pour une nouvelle implémentation de l’interface. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

14 TECHNIQUES MOCK OBJECT
L’un des principes fondateurs du test unitaire est l’isolation. La raison d’être d’un mock objet est de simuler le comportement des objets tiers. Les avantages : isolement + économie des traitements couteux + programmation par contrat. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

15 OutiZ Etat des Lieux TDD, TU et Tests d’intégrations : Absents Plan de test : OK Intégration Continue : 50% © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 24/04/2015

16 OutiZ Limites et possibilités
Limites : Les tests sur le projet OutiZ ne sont pas écrit au moment opportun, (Charge non vendue au client). TU jetables vs TU automatisés (TDD) Aucun TU est préférable à des TU jetables(même s’il y a la couverture du code , est ce que ces derniers évoluent avec le code de production ? Cas de Split Commande). Possibilités : Introduire TDD sur les nouvelles exigences : Junit avec Ant, Eclipse et Web sont OK. Montée en compétence + engagement de la part de l’équipe de DEV pour adoption d’une telle pratique. © SQLI GROUP 2015 – Workshop Test et Assurance Qualité V1.0 – 03/01/2013

17 © SQLI GROUP 2015 – Workshop Test et Assurance Qualité
V1.0 – 24/04/2015