S5-TPRE575

La
méthodologie
autour des
tests
C'est quoi un test ?
 "Tester c'est douter !*"

Pourquoi tester ?

- On fait tous des erreurs

- On peut partir sur une mauvaise hypothèse de départ
- On peut toujours s'améliorer
- Meilleure compréhension de ce que l'on fait
Et en informatique ?

1 Satisfaction client

2 Éviter les erreurs

3 Build&Run* simplifiés

4 Qualité du produit

5 Qualité des livrables

*Build : Phase de développement applicative

*Run : Phase de maintenance applicative
La qualité c'est bien ! Robustesse

Utilité Rentabilité

Durabilité Qualité Stabilité

Maintenabilité
Ergonomie

Design
Je teste quand ?

recette à l'aveugle

recette scriptée

Phase de Phase de recette Automatique

développement

Phase de test
Sachants Ignorants
Je retiens quoi de tout
ça ?

Qualité : Qualité de l'application : satisfaction client

Différentes façons de tester : tests possibles à n'importe quelle phase du projet

Application rencontrant peu d'erreurs

Gestion des erreurs réglée en avance de phase

Simplification de l'application : Construction par les tests (TDD)

Collaboration : travail en équipe (développeur + métier + QA...)

Documentation : fonctionnalités de l'application lisibles à travers les tests

Temps gagné : un problème géré à la source n'entraînera pas une grosse charge de
travail
Types de tests
Partie I
 Unitaires
1.1

Un test unitaire doit permettre de vérifier le fonctionnement d'une brique (fonction,

procédure...) de façon autonome et isolé.

Quand : Phase de développement

 Unitaires
1.1

Code entrée Code sortie

test
 Unitaires
1.1
Exemples

- public function deuxPlusDeux() {

return 4;
}

- public function creationBateau(Bateau $bateau) {

$nouveauBateau = $bateau->save();
return 'OK';
}

- public function enfileVetementSurEnfant(Vetement $vetement, Enfant $enfant) {

$enfantHabille= $enfant->enfile($vetement);
return $enfantHabille;
}
 Intégration
1.2

Un test d'intégration doit permettre de vérifier le bon fonctionnement détaillé d'une brique
de l'application (fonction, procédure..)

Quand : Phase de développement

Intégration
1.2

Code fonction

test
 Intégration
1.2
Exemples

- public function creationBateau() {

$bateau = New Bateau();
$nouveauBateau = $bateau->save();
return $nouveauBateau;
}
- public function peindreBateauEnBleu(Bateau $bateau) {
$bateau->peindre(bleu);
return $bateau;
}
- public function construitBateauBleu() {
$bateauBleu = creationBateau();
return $bateauBleu->peindreBateauEnBleu();
}
 Intégration
1.2

- Top-down
- Bottom-up
- Sandwich
- Big-bang
 Fonctionnel
1.3

Les tests fonctionnels sont destinés à s’assurer que, dans le contexte d’utilisation réelle, le
comportement fonctionnel obtenu est bien conforme avec celui attendu.

Quand : phase de développement

 Fonctionnel
1.3

- Se connecter avec son e-mail

- Ajouter un bénéficiaire
- Faire un virement
- Consulter ses dernières opérations
- Demander l'envoi d'un nouveau chéquier
- ....
 Acceptation
1.4

En informatique, le test d'acceptation (ou recette) est une phase de développement des projets,
visant à assurer formellement que le produit est conforme aux spécifications
(réponse donnée à un instant « t » aux attentes formulées).

Quand : Phase de spécification

 Acceptation
1.4

- Le bateau doit flotter

- Le bateau doit pouvoir se déplacer
- Des gens doivent pouvoir monter sur le bateau
- ....
 Charge
1.5

Un test de charge consiste à effectuer un test permettant de mesurer la performance d'un

système en fonction de la charge d'utilisateurs simultanées. L'objectif est de prévoir la charge
maximale que peut encaisser votre SI.

Quand : Phase de recette

 Charge
1.5

Tests de charge : Nombre d'utilisateurs fixe

Tests de capacité : Nombre d'utilisateurs croissant
Tests de volume : Nombre d'utilisateurs bien supérieur
Tests de stress : Nombre d'utilisateurs maximal
Tests d'endurance : Nombre d'utilisateurs qui varie selon une période
Test Driven Development
(TDD)

Partie 2
 Définition

2.1

Méthode de développement qui consiste à écrire un test unitaire avant d'écrire le code
correspondant.

Quand : phase de développement

CLASSIQUE
TDD
CLASSIQUE VS TDD
 Méthode 3A

2.2

Arrange :
On créé l'objet dans un environnement fixe -> Valeurs en durs, mocks..
Act :
On exécute une fonction sur cet objet
Assert :
On compare le retour de la fonction avec le retour attendu
 Avantages

2.3

- Objectif simple
- Pas de modification en cascade
- Rapidité de développement
- Compréhension du code et du métier accrue
- Stabilité de l'application
- Refactorisation permanente
TDD
 Inconvénients

2.3

- Plus de code à écrire

- Développement avec œillères
- Spécification métier variable
- Maintenabilité
 Couverture de test

2.4

Objectif : Créer une métrique qui permette de quantifié la couverture du code par les tests
 Couverture de test

2.4

Unitaire : Est-ce que toutes les fonctions sont appelés dans le code ?
Fonctionnelle : Est-ce que toutes les fonctionnalités sont testées ?
Intégration : Est ce que tous les changements que provoquent les fonctions sont testés ?
 Couverture de test

2.4

- Couverture de test Manuelle

- Couverture de test Automatique

=> Test duration: 15.63 seconds.

=> Memory usage: 8.25 Mb.
> Total test duration: 15.63 seconds.
> Total test memory usage: 8.25 Mb.
> Code coverage value: 92.52%
=> Class mageekguy\atoum\template: 91.14%
==> mageekguy\atoum\template::setWith(): 80.00%
==> mageekguy\atoum\template::resetChildrenData(): 25.00%
==> mageekguy\atoum\template::addToParent(): 0.00%
==> mageekguy\atoum\template::unsetAttribute(): 0.00%
=> Class mageekguy\atoum\template\data: 96.43%
==> mageekguy\atoum\template\data::__toString(): 0.00%
> Running duration: 2.36 seconds.
Success (1 test, 27 methods, 485 assertions, 0 error, 0 exception) !
 TP

TP

Contexte : L'entreprise Dacotte vend des vêtements de chantiers depuis plusieurs années. Avec la pandémie, ils voudraient développer leur site internet pour passer au b2c (actuellement leur site n'est qu'un
site vitrine).Pour cela, ils font faire passer des tests aux entreprises ayant répondues à leur appel d'offre. Ayant entendu parler de tests pour sécuriser leur application et créer un logiciel de qualité, ils
souhaiteraient voir dans leur entretiens :

- des morceaux de leur logiciel créé de façon traditionnelle (développement puis tests). Cela peut être n'importe quel brique de l'application (passage de commande, mise au panier et validation d'article...)
- un morceau de leur logiciel créé en TDD (pour pouvoir comparer)
- des tests unitaires (entre 15 et 20, pas que sur les setters et getters..)
- des tests d'intégration (une dizaine)
- des tests fonctionnels (une petite dizaine)

- Bonus : tests de charge & couverture de code

La recette fonctionnelle

Partie 3
Je teste quand ?

recette à l'aveugle

recette scriptée

Phase de Phase de recette Automatique

développement

Phase de test
Sachants Ignorants
Un cycle de vie ?
 La recette fonctionnelle

3.1

Décliner les scénarios à exécuter :

- Plan de test
- Cas de test
- Jeux de test
- Scenario de test
 La recette fonctionnelle

3.2

Entrée -> Comportement -> Résultat attendu -> Résultat effectif

Et les anomalies ?
 Une fiche anomalie

4 étapes Clefs :
- Conditions pour arriver à l’anomalie

- Scénario pour reproduire l’erreur

- Décrire l’impact sur les utilisateurs

- Fournir des documents nécessaires à la reproduction

Le plan d'une recette

3.3
 Exercice

Contexte : L'entreprise Dacotte ajoute sur son site e-commerce la possibilité de régler en carte bleue. Vous êtes
responsable de ce projet.
Vous avez avec vous plusieurs développeurs, et êtes en relation avec d'autres services (comptabilité, magasins, référent e-
commerce...).
Suite aux développements effectués selon les spécifications du métier (Annexe 1), on vous annonce la fin de votre
mission car il y a un manque de budget. On vous demande avant de partir de rédiger un court document sur la recette de
votre projet.
Vous devrez définir :
- Acteurs de la recette
- Périmètre testé par acteur
- Flux de remontés d'anomalie/d'information
- Calendrier prévisionnel de la recette
- COPROJ / COPIL ? ..
- ...
Vous disposez dans l'annexe 2 des acteurs identifiés par votre hiérarchie et de certaines informations transmises.