267 lines
7.7 KiB
Markdown
267 lines
7.7 KiB
Markdown
|
<style>pre, table { font-size: 0.6em !important; }</style>
|
|||
|
|
|
|||
|
|
# Qualification et intégration continue
|
|||
|
|
|
|||
|
|
William Petit - S.C.O.P. Cadoles
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
<!-- page_number: true -->
|
|||
|
|
|
|||
|
|
## Qu'est ce que la qualification ?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Qu'est ce que l'intégration continue ?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Les tests applicatifs
|
|||
|
|
|
|||
|
|
Les tests applicatifs ont pour objectif de valider le bon fonctionnement de l'application d'un point de vue métier, c'est à dire de vérifier que celle ci répond aux attentes et aux contraintes du client d'un point de vue fonctionnel.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## La pyramide des tests applicatifs
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Tests unitaires
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Objectifs
|
|||
|
|
|
|||
|
|
Tester le bon fonctionnement des plus petites unités logiques/fonctionnelles de l'application: les fonctions/méthodes d'objets.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Cycle de vie
|
|||
|
|
|
|||
|
|
1. Définir le comportement attendu de la classe/fonction à implémenter.
|
|||
|
|
2. Créer le cas de test validant ce comportement.
|
|||
|
|
3. Exécuter le test. Il ne devrait pas être passant, l'implémentation étant incomplète à ce stade.
|
|||
|
|
4. Implémenter la fonction/classe pour que le test soit passant.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Caractéristiques clés
|
|||
|
|
|
|||
|
|
- Ils sont nombreux.
|
|||
|
|
- Ils sont mis en place dès le début de l'implémentation, voir avant.
|
|||
|
|
- Ils sont rapides à exécuter.
|
|||
|
|
- Ils permettent de détecter rapidement les régressions.
|
|||
|
|
- Ils permettent de rassurer le développeur qui doit apporter des évolutions à une base de code existante.
|
|||
|
|
- Ils s'exécutent en continu sur le poste du développeur et à chaque changement sur le serveur de gestion des sources.
|
|||
|
|
- Ils ne devraient pas nécessiter de dépendances externes.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Tests unitaires en Javascript (Mocha)
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Tests unitaires en PHP (Symfony3)
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exercice: Tests unitaires d'une fonction de validation d'un numéro de carte bancaire en Javascript
|
|||
|
|
|
|||
|
|
Soit un numéro de carte bancaire donné, implémenter un test pour la fonction validant le code de celle ci PUIS implémenter la fonction qui permet de valider ce code.
|
|||
|
|
|
|||
|
|
**Ressources**
|
|||
|
|
|
|||
|
|
- [La formule de Luhn](https://fr.wikipedia.org/wiki/Formule_de_Luhn)
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Tests d'intégration
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Objectifs
|
|||
|
|
|
|||
|
|
Tester la bonne communication des différents "modules" composant une application.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Caractéristiques clés
|
|||
|
|
|
|||
|
|
- Ils sont moins nombreux que les tests unitaires.
|
|||
|
|
- Ils peuvent prendre un peu de temps à s'exécuter.
|
|||
|
|
- Ils sont mis en place au cours de l'implémentation initiale et maintenus au fur et à mesure de l'évolution de l'application.
|
|||
|
|
- Ils peuvent nécessiter des dépendances externes, mais généralement pas l'ensemble de l'infrastructure.
|
|||
|
|
- Ils peuvent nécessiter des données d'amorçage.
|
|||
|
|
- Ils impliquent souvent la mise en place de composants "factices" pour simuler une partie de l'application.
|
|||
|
|
- Ils s'exécutent à la demande sur le poste du développeur et sur le serveur d'intégration continue à intervalles réguliers.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Cycle de vie
|
|||
|
|
|
|||
|
|
Les tests d'intégration devraient être abordés (en général) en seconde moitiée d'itération, au moment de la finalisation des modules applicatifs prêts à être livrés.
|
|||
|
|
|
|||
|
|
Ils devraient cibler en premier les modules critiques de l'application, notamment ceux ayant pour rôle de contrôler/valider le cycle de vie des données métiers.
|
|||
|
|
|
|||
|
|
Les tests d'intégration peuvent être un bon témoin/validateur de l'état de réussite d'une itération.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Test de la soumission d'un formulaire (Symfony3)
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Tests fonctionnels
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Objectif
|
|||
|
|
|
|||
|
|
Tester le bon fonctionnement de l'application d'un point de vue utilisateur.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Caractéristiques clés
|
|||
|
|
|
|||
|
|
- Ils devraient être les moins nombreux de l'ensemble des tests applicatifs.
|
|||
|
|
- Ils devraient être représentatifs des cinématiques d'action des utilisateurs.
|
|||
|
|
- Ils devraient s'exécuter sur un environnement identique à la production.
|
|||
|
|
- Ils sont souvent complexes à mettre en place/maintenir.
|
|||
|
|
- Ils ont une couverture fonctionnelle très large mais ne permettent pas d'identifier directement les sources de dysfonctionnement.
|
|||
|
|
- Ils devraient couvrir les procédures faisant intervenir les dépendances externes de l'application (serveur de courriel, API externes, base de données...).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Cycle de vie
|
|||
|
|
|
|||
|
|
Les tests fonctionnels devraient être implémentés une fois que l'itération a été validée par le client.
|
|||
|
|
|
|||
|
|
Ils ne devraient être modifiés que lorsque le client demande une évolution de l'interface utilisateur et/ou des cinématiques d'action.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Tests fonctionnels Web avec NightmareJS
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exercice: Tester une procédure d'authentification d'un utilisateur
|
|||
|
|
|
|||
|
|
TODO
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Les tests "techniques"
|
|||
|
|
|
|||
|
|
Les tests techniques ont pour objectif de valider le bon fonctionnement de l'infrastructure exécutant l'application, c'est à dire que l'application et son infrastructure seront capables de répondre au contexte d'usage en production.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Tests de charge
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Objectif
|
|||
|
|
|
|||
|
|
Les tests de charge doivent permettre de valider le niveau de stabilité de l'infrastructure et de l'application par rapport à la volumétrie d'utilisateurs en production et son contexte technique d'utilisation.
|
|||
|
|
|
|||
|
|
Pour ce faire, la mise en place d'une stratégie concrète de métrologie est **obligatoire**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Caractéristiques clés
|
|||
|
|
|
|||
|
|
- Ils nécessitent la mise en place d'une infrastructure identique (ou au plus proche) à la production.
|
|||
|
|
- Les données produites sont souvent peu fiables car les tests de charge véritablement représentatifs d'un comportement d'un utilisateur sont complexes à mettre en place.
|
|||
|
|
- Ils doivent couvrir toutes les briques techniques de l'infrastructure et de l'application: disques, réseau, mémoire vive, CPU, serveur HTTPS, serveur applicatif, base de données...
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Cycle de vie
|
|||
|
|
|
|||
|
|
Les tests de charge devraient être effectués avant tout primo déploiement d'une application et réactualisés lorsque le contexte d'usage de celle ci change (exemple: bascule d'un usage local à un usage national).
|
|||
|
|
|
|||
|
|
Les tests de charge devraient être exécutés régulièrement afin de vérifier qu'aucun "goulot d'étranglement" n'a été introduit dans l'itération en cours.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Utilisation d'Apache Benchmark pour vérifier le temps de réponse d'une application Web
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Tests de sécurité
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Objectif
|
|||
|
|
|
|||
|
|
Valider la conformité de l'infrastructure et de l'application d'un point de vue sécurité. Découvrir des vulnérabilités dans la conception de l'application.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Caractéristiques clés
|
|||
|
|
|
|||
|
|
- Ils sont complexes à mettre en place
|
|||
|
|
- Ils doivent fonctionner sur un environnement identique à la production.
|
|||
|
|
- Ils ne peuvent remplacer un audit de sécurité "manuel".
|
|||
|
|
- Ils sont souvent peu efficaces pour détecter les failles qui nécessites un premier niveau d'accréditation.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Cycle de vie
|
|||
|
|
|
|||
|
|
Ils doivent être mis en place au plus tôt dans le cycle de développement.
|
|||
|
|
|
|||
|
|
Suivant le type de cible, ils peuvent être exécutés de différentes manières: à chaque fin d'itération, de manière règulière, etc...
|
|||
|
|
|
|||
|
|
Ils doivent être réactualisés lors de tout changement d'infrastructure et de socle technologique de l'application.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Vérification de sécurité pour les dépendances PHP
|
|||
|
|
|
|||
|
|
TODO https://github.com/sensiolabs/security-checker
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Tests d'attaques automatisées sur les applications Web avec w3af
|
|||
|
|
|
|||
|
|
TODO https://tools.kali.org/web-applications/w3af
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Les serveurs d'intégration continue
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Technologies de conteneurisation
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Présentation de Docker
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exemple: Gitlab et Gitlab Runner
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Exercice: Mise en application générale
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Licence
|
|||
|
|
|
|||
|
|
## CC BY-NC-SA 3.0 FR
|
|||
|
|
|
|||
|
|
[Creative Commons - Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 France](https://creativecommons.org/licenses/by-nc-sa/3.0/fr/)
|