Vue d’ensemble (définitions et normes)
Les tests informatiques sont destinés à évaluer si un système informatique et ses composants satisfont les exigences métier ou pas. Cette activité résulte des différences qu’il pourrait y avoir entre le résultat attendu et le résultat réellement obtenu.
Les tests peuvent couvrir l’analyse et la vérification des exigences métier, la révision de la conception ainsi que la vérification et la validation du code d’un développeur. Les tests peuvent commencer dès la phase de recueil du besoin et dure jusqu’au déploiement de l’application livrée. Si le démarrage des tests peut commencer assez tôt dans le cycle de développement en imaginant les cas de tests, y mettre fin serait un casse-tête face à un testeur perfectionniste. L’arrêt des tests arrive en général quand les dates jalons sont atteintes, quand les cas de tests couvrent un certain périmètre fonctionnel, quand le taux d’anomalies est réduit à un minimum ou tout simplement par une décision de gestion. Il y a beaucoup de termes en relation avec les tests. Passons les en revue.
| Vérification (tests unitaires, tests d’intégration) | Validation (recette) |
| Est-ce construit/codé correctement ? | Est-ce que c’est codé correctement vis-à-vis des exigences ? |
| Assurer que l’application couvre toutes les fonctionnalités demandées | Assurer que le comportement obtenu est bon |
| Effectué par les développeurs | Effectué par des recetteurs, homologateurs ou testeurs indépendants de l’équipe de développement |
| Vision statique et objective car elle est accès sur le code et sa logique | Vision dynamique et subjective car l’application est testée par rapport aux exigences métier et à des décisions de l’utilisateur |
L’assurance qualité est une activité visant l’implémentation de processus, de procédures et de standards dans le contexte du développement d’applications informatiques. Elle a pour but la prévention d’anomalies et fait partie du cycle de vie des tests d’applications informatiques.
Le contrôle qualité est une activité destinée à vérifier que le logiciel développé respecte les exigences métier. Il met en application les processus définit par l’assurance qualité. C’est une activité corrective et se focalise sue un logiciel particulier. Il peut être considéré que le contrôle qualité est un sous-ensemble de l’assurance qualité.
Les tests informatiques sont l’activité d’identification des bugs, anomalies et défauts d’un logiciel. Ils sont un sous-ensemble de l’assurance qualité.
L’audit est un examen des processus de testing exitants. Il est mené par un organisme externe aux développeurs et aux testeurs et délivre un certificat ou un accréditation. C’est une comparaison des processus documentés et des processus vraiment déroulés. L’audit peut se décliner en audit de conformité, audit légal, audit interne, audit du système et autres.
Les inspections sont des examens des exigences métiers, de la conception et du code. Elles sont effectués par une tierce personne et vise au respect des processus documentés. A différence de l’audit, il n’y a pas de certifications.
Le testing est l’identification de bogue, d’anomalies et de défauts. C’est une activité qui vise le repérage mais pas la correction. Cette dernière est réalisée par d’autres équipes
Le débogage est l’identification, la qualification et la correction des anomalies.
La norme ISO/IEC 9126 définit un langage de modélisation de la qualité des logiciels. Le langage de description utilise des termes tels que “facteurs qualité” , “caractéristiques, “sous-caractéristiques ,”métriques” pour classer de façon arborescente et structurée, sur la base de définitions standardisées, un vocable de plusieurs dizaines de propriétés en “ité” (portabilité, maintenabilité, fiabilité, etc.)
- Capacité fonctionnelle : Est-ce que le logiciel répond aux besoins fonctionnels exprimés ?
- Fiabilité : Est-ce que le logiciel maintient son niveau de service dans des conditions précises et pendant une période déterminée ?
- Facilité d’utilisation : Est-ce que le logiciel requiert peu d’effort à l’utilisation ?
- Rendement / Efficacité : Est-ce que le logiciel requiert un dimensionnement rentable et proportionné de la plate-forme d’hébergement en regard des autres exigences ?
- Maintenabilité : Est-ce que le logiciel requiert peu d’effort à son évolution par rapport aux nouveaux besoins ?
- Portabilité : Est-ce que le logiciel peut être transféré d’une plate-forme ou d’un environnement à un autre ?
ISO/IEC 9241-11 aborde l’usage d’un produit par des utilisateurs dans un contexte donnée afin d’atteindre des objectifs de safistaction et d’efficacité.
ISO/IEC 25000 remplace ISO-9126 and ISO-14598 et définit des guides d’utilisation SQUARE (Software product Quality Requirements and Evaluation)
IEEE est l’acronyme de “institute of Electrical and Electronics Engineers”. Il définit aussi des normes spécifiques à des contextes du testing comme les tests unitaires, les plans des tests et de recette, la classification des anomalies etc.
Types de tests
Les tests peuvent être catégorisés suivant la manière comme ils sont réalisés. Ils sont soit manuels soit automatisés
Lors des tests manuels, le testeur adopte le point de vue de l’utilisateur final et procède à la recherche d’un comportement non-conforme. Il y a plusieurs niveaux de profondeur de testing. Ceux-ci seront expliqués par la suite.
Les tests automatisés sont effectués quand le testeur écrit un script d’automatisation et les tests eux-mêmes sont exécutés par un logiciel dédié à l’exécution des tests. L’automatisation permet de dérouler plusieurs fois le même test ce qui est propice aux tests de non régression. Les domaines qui se prêtent à l’automatisation sont des transactions comme le login ou le remplissage de formulaires ou l’accès simultané peut générer des pics d’utilisation. Il est recommandé d’automatiser dans de très grands projets, quand la même fonctionnalité est testée fréquemment, quand les exigences sont stables, dans des situations visant des critères de performance et de robustesse d’accès.
Les étapes de l’automatisation sont les suivantes :
- Identification des domaines d’automatisation
- Sélection de l’outil d’automatisation
- Ecriture des scripts et des enchainements
- Exécution des tests
- Génération des rapports
- Analyse des résultats
Parmi les logiciels d’automatisation on trouve entre autres HP Quick Test Professional, Selenium, IBM Rational Functional Tester, SilkTest, TestComplete, Testing Anywhere, WinRunner, LaodRunner, Visual Studio Test Professional et WATIR.
Méthodes de testing
Dans la méthode de boite noire, le testeur n’a pas de connaissances sur le code et l’architecture. Le testeur utilise l’IHM et examine les résultats obtenues. Les avantages sont l’’adaptation à des périmètres très grands, la bonne séparation de la vision de l’utilisateur final et du développeur et l’absence de connaissances techniques poussées. Le risque de cette méthode est la couverture inappropriée de certaines parties du logiciel.
Dans la méthode de la boite blanche, une investigation détaillée de la structure et de la logique du code est conduite. Une connaissance technique du langage de programmation et des modules des logiciels testés est requise. En boite blanche, le code peut être optimisé et il est plus probable de couvrir la totalité des cas. D’un autre côté, cette métode est plus couteuse dans le sens où il faut maintenir des outils spécialisés comme les analyseurs de code et de débogage. Aussi les ressources sont plus chères car il faut qu’elles aient la connaissance des techniques en lien avec le logiciel testé.
Dans la méthode de boite grise, le testeur a accès aux documents de conception et au modèle de base de données. Ceci lui permet de préparer les données de tests et les scénarios de tests.
Catégories de tests
Il y a deux niveaux de tests, chacun divisé en sous-catégories : Les tests fonctionnels et les tests non fonctionnels
Les tests fonctionnels se basent sur les spécifications fonctionnelles. Le logiciel est testé dans un environnement afin de vérifier sa conformité aux exigences (requirements). Les étapes qui les composent sont les suivantes ;
- Détermination de la fonctionnalité testée
- Ecriture des scénarios de test et des cas de test
- Création des données de tests
- Détermination de la sortie
- Comparaison des résultats obtenus et des résultats attendus.
| Sous catégories des tests fonctionnels | Description |
| Tests unitaires | Ce test est réalisé par le développeur afin de vérifier que le module livré est conforme. Il se focalise sur la fonctionnalité livrée |
| Tests d’intégration | Ces tests succèdent les tests unitaires. Ils vérifient le fonctionnement d’un ensemble de modules et sont exécutés de la forme « bottom-up » et ensuite « top-down ». Dis d’une autre façon, soit les tests sont organisés par empilement de modules testés, soit par un ensemble de modules non-testés et commandés par le module de plus haut niveau qui les testent. Les tests d’intégration sont réalisés par l’équipe de développement |
| Tests système | Après les tests d’intégration, les tests système confrontent l’application à des données réelles dans un environnement proche de celui de production. Ces tests valident les exigences métier et l’architecture applicative. En général, ils sont exécutés par des testeurs de l’éditeur. |
| Tests de non régression | Les tests de non-régression contrôlent que les évolutions d’un système, les nouveaux modules, n’ont pas d’effet de bord sur les fonctionnalités existantes. Ceci minimise les risques de l’ensemble suite au rajout ou la modification d’un fonctionnalité. Il est donc important de conserver l’historique des tests puisque ceux-ci pourront être rejoués à nouveau sur des livraisons futures |
| Recette (User Acceptance Test) | Les UAT comme son nom l’indique sont réalisés par les utilisateurs finaux. Leur finalité est d’avoir l’accord client sur le bon fonctionnement de l’application.Suivant le type d’application il y aura des tests pour des versions alpha et des versions beta. Les tests des versions alpha se réalisent en binôme entre les développeurs et l’assurance qualité. L’intention est de corriger des erreurs de cosmétique, des enchainements illogiques, etc. Les tests beta sont réalisés sur une version diffusée auprès d’un échantillon d’utilisateur représentatif du grand public. |
Les tests non-fonctionnels sont basés sur des critères applicatifs détaillés dans le dossier d’architecture système, les exigences non-fonctionnelles. Ils sont donc menés par des experts techniques
Les tests de performance cherchent à identifier des problèmes de performance et des goulots d’étranglement. Les différentes causes peuvent être la lenteur du réseau, les traitements des bases de données, la répartition de charge (load balancing). Parmi les tests de performance, les tests de charge simulent des connexions et des manipulations de données avec des scripts d’automatisation. Ainsi l’application dévoile son comportement aux heures de pointe de l’utilisation. Les tests de stress poussent le système à ses limites et dans des situations risqué (perte de connexion au réseau ou à une base de données ou surcharge des processus machine)
Les tests de convivialité (usability) permettent d’évaluer la satisfaction de l’utilisateur quand celui-ci se fixe un objectif opérationnel et quand cet objectif est atteint de manière efficace. Ils mesurent les interactions de l’utilisateur dans l’atteinte d’un but précis.
Les tests de sécurité ont pour vocation l’identification de failles et de vulnérabilités en termes de sécurité. Ces tests garantissent la confidentialité, l’intégrité des données, la protection contre des attaques malveillantes, le respect de réglementations spécifiques à la banque etc…
Les tests de portabilité assurent que l’application peut être installée et exécutée dans un autre système.
A part ces catégories de tests, l’IEEE-Std 830 – 1993 liste 13 exigences non-fonctionnelles :
- performance
- interface
- opérationnel
- sur les ressources
- vérification
- validation / recette
- documentation
- sécurité
- portabilité
- qualité
- fiabilité
- maintenabilité
- sauvegarde
Documentation relative aux tests
Le plan de tests résume la stratégie de tests visée pour l’application. Il inclut les sections suivantes :
- hypothèses
- liste des cas de test
- liste des fonctionnalités
- liste de livrables
- liste des ressources humaines et matérielles
- risques
- planning et jalon
Les scénarios de test sont des regroupements de cas de tests. Le cas de test est un ensemble de pas à suivre. Elle est représentative d’un situation opérationnelle. Voici l’exemple du formalisme de représentation.
A l’issue des tests, des anomalies seront relevées dans des fiches descriptives. Il sera important donc de dressée la matrice de traçabilité. Ce document fait le lien entre les exigences, les tests prévus, les tests exécutés et les anomalies déclarées.
L’outil « Quality Center » permet d’informatiser e processus. Le module « requirements » permet de saisir les exigences. Le module « Test Plan » permet de décrire les cas de tests et les organisent sous forme arborescente de sorte à produire des scénarios de tests. Le module « Test Lab » représente une exécution donnée pour un scénario de tests. Un scénario de tests peut être exécuté plusieurs fois . L’exécution peut avoir lieu manuellement ou automatiquement. De ce fait, Quality Center permet de générer des scripts d’automatisation. Après une exécution, les anomalies déclarées peuvent être liés aux cas de tests. Finalement, Quality Center offre la possibilité de générer des rapport sur l’état d’avancement des tests.
Références
| Sujet (Quality Center) | Lien |
| introduction | http://www.youtube.com/watch?v=RoHYqeBxcY&list=PL3751912B18050F7F |
| modules | http://www.youtube.com/watch?v=fBREaBJPYc8&list=PL3751912B18050F7F |
| requirements | http://www.youtube.com/watch?v=fBREaBJPYc8&list=PL3751912B18050F7F |
| Test plan module | http://www.youtube.com/watch?v=Gm6pnKmFjAA&list=PL3751912B18050F7F |
| Automated test case design | http://www.youtube.com/watch?v=6-tcVrnEyAU&list=PL3751912B18050F7F |
| Test linkage | http://www.youtube.com/watch?v=QormvqA0_eQ&list=PL3751912B18050F7F |
| Test lab module | http://www.youtube.com/watch?v=mvoGw8GRbs4&list=PL3751912B18050F7F |
| Run automated test | http://www.youtube.com/watch?v=QSKh-UiVHco&list=PL3751912B18050F7F |
| Defects module | http://www.youtube.com/watch?v=rC9noc_FrpU&list=PL3751912B18050F7F |
| Defects linkage | http://www.youtube.com/watch?v=VVI-p9YI57w&list=PL3751912B18050F7F |
| favorites | http://www.youtube.com/watch?v=-qCMLvxGfvw&list=PL3751912B18050F7F |
| traceability | http://www.youtube.com/watch?v=j87YjWVewXQ&list=PL3751912B18050F7F |
| Graphs and reports | http://www.youtube.com/watch?v=CyDaLj_dhyA&list=PL3751912B18050F7F |
| Analysis graphs | http://www.youtube.com/watch?v=Wdm7RzPbTio&list=PL3751912B18050F7F |
