Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Tests non fonctionnels

Introduction

Dans le métier du test, la référence en matière d’Exigence Non Fonctionnelle (ENF ou NFR en anglais - Non Functional Requirements) liée au développement logiciel est l’ISO 25010 [ISTQB 2023]. Cette norme propose huit caractéristiques de la qualité logicielle :

  • Le fonctionnel ;

  • Les performances ;

  • La compatibilité ;

  • L’utilisabilité ;

  • La fiabilité ;

  • La sécurité ;

  • La maintenabilité ;

  • La portabilité.

À part les « tests fonctionnels » relatifs à la première caractéristique que tous les testeurs connaissent, les autres sont évidemment appelés caractéristiques « non fonctionnelles ».

Sur une grosse majorité des projets rencontrés, il s’avère que les tests non fonctionnels sont éludés. À l’évocation de cette catégorie de test, un soupir sonore « Aaaaah » un peu gêné, est en général l’unique ENF connue de tous. Dans certains cas, vous pourrez avoir des tentatives telles qu’un essai de l’application sur X navigateurs différents, ou une équipe spécialisée qui fait des tests de charge ou de sécurité.

Les anomalies ne proviennent des fonctionnalités...

Tests de sécurité

Voyons déjà pourquoi vous devriez être concernés par ce genre d’ENF, même si vous ne travaillez pas dans une banque.

Depuis le 26 mai 2018, l’Europe a promulgué la loi « RGPD » (voir section Les moyens d’une session de TE au chapitre Versant industriel), pour lutter contre le faible niveau de sécurité lié au traitement et à la protection des données personnelles. Au vu des sanctions annoncées (http://tinyurl.com/rgpd-wiki), la grande majorité des entreprises se sont mobilisées pour savoir faire face à ce risque.

Ces sanctions financières sont en fait une raison de plus pour mettre au centre des préoccupations les tests de sécurité. En effet, ils étaient déjà abordés par :

  • l’industrie des cartes bancaires [PCI-DSS] ;

  • l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) qui a produit le « Référentiel général de sécurité » [RGS] et des standards internationaux de sécurité tels que l’ISO27002 ;

  • ou encore ceux liés aux sociétés cotées en bourse [SAS70].

De façon plus large, les tests de sécurité sont cruciaux pour protéger les systèmes, les données et assurer la conformité réglementaire, tout en préservant la confiance des utilisateurs et en minimisant les coûts liés aux failles de sécurité.

Nous allons donc commencer ce voyage dans les ENF par celle qui est la plus mystérieuse et la plus redoutée : les tests de sécurité.

1. Généralités sur les tests de sécurité

La sécurité est un domaine des plus vastes, car il touche toutes les parties du produit, et les personnes qui interagissent avec. Cette configuration fait du test de sécurité :

  • une activité pluridisciplinaire, avec des Experts qui comprennent les règles, les lois, l’organisation sous-jacente, les opérations, les processus et les technologies utilisées ;

  • une exploration des dangers dans l’obscurité, avec pour seul éclairage l’expertise afin...

Tests d’utilisabilité

À force de voir la même application, l’équipe de réalisation a pris des habitudes pour effectuer ses tests, ce qui la rend relativement aveugle à la convivialité de l’application. Les tests d’utilisabilité permettent de prendre du recul sur l‘impression que laisse le produit mis à disposition.

L’utilisabilité repose sur [ISO 25010] :

  • l’intelligibilité ;

  • la facilité d’apprentissage ;

  • l’opérabilité ;

  • la protection contre les erreurs ;

  • l’ergonomie ;

  • l’accessibilité.

Dans certains contextes, l’utilisabilité peut revêtir un aspect critique. Par exemple, dans une salle d’opération ou dans un avion, si l’utilisation s’avère être trop complexe, cela peut mettre en danger des vies humaines [Mentler 2013]. De façon plus générale, ce genre de test permet [D’Agostino 2016] :

  • lorsque le produit est à usage professionnel, de faciliter l’adoption, la formation, l’efficacité opérationnelle et de prendre soin des conditions de travail des utilisateurs ;

  • lorsque le produit est destiné à des clients, de faciliter le taux de conversion (voir la Qualité de Service - section Qualité de service au chapitre Versant technique du test).

Au vu de ces caractéristiques, certains termes peuvent paraître déconcertants, car relativement proches. En fait, l’utilisabilité concerne l’adaptation d’un système au travail tandis que l’autre s’intéresse au bien-être de l’utilisateur [D’Agostino 2016].

Lorsque nous lisons quelques normes et leurs évolutions sur le sujet de l’utilisabilité (ISO 25010, ISO 9126, ISO 9241, IEC 62366, ISO 20000, ISO 13407, ISO/TR 16982, ISO 92441-10, ISO 14915), nous sommes vite confrontés à des termes très voisins, avec des définitions qui tentent de clarifier les nuances, comme l’exemple de l’ISO 25010 ci-dessus. Ces nuances débouchent sur les idées suivantes [D’Agostino 2016] :

  • l’utilisabilité se vérifie à l’usage du produit, elle dépend...

Tests de charges

Lorsqu’un produit est mis à disposition de plusieurs utilisateurs ou que celui-ci doit traiter une grande quantité de données, il est nécessaire de s’assurer qu’il restera opérationnel et utilisable une fois déployé. Pour ce faire, nous procéderons à des tests de charges.

La catégorie des tests de charges exploite une technique relativement simple : effectuer une même action lancée en parallèle (comme par autant d’utilisateurs) avec plus ou moins de force (la charge). Il sera ainsi constitué des « tirs » :

  • pour mesurer la réaction du système en fonction du nombre d’utilisateurs et trouver ainsi la charge limite qui répond aux exigences de temps de réponse - ce sont des « tests de stress » ;

  • pour éprouver la robustesse du système en trouvant son point de rupture - la charge maximale ;

  • pour identifier l’endurance du système en le soumettant à une charge constante sur une longue durée - en anglais vous trouverez parfois le terme de « soak testing ».

images/I-icone.png

Tests de robustesse et piratage

Lorsque le système n’est plus en mesure de réagir à une demande supplémentaire d’un utilisateur, nous nous retrouvons dans une situation qui s’appelle un « Denial of Service » (DoS).

Il s’avère que certaines personnes mal intentionnées comme un concurrent ou un hacktiviste, veulent provoquer un DoS afin de rendre inopérant un produit pour les autres utilisateurs.

Dans certains cas, le service s’arrête et revient à l’OS en y donnant alors un accès direct. Dans d’autres cas, les données sont alors poussées sur la pile d’exécution et sont considérées comme des instructions (voir TOCTOU/Spoofing - section Analyse de failles de sécurité sur le design et le code). C’est pourquoi cette technique est utilisée pour pirater un système et récupérer des informations, faire planter le système ou en prendre complètement le contrôle.

Par conséquent, ces situations doivent être testées par des tests de robustesse afin d’observer le comportement...

Tests de migration ou reprise de données

L’évolution et la durée de vie des moyens sont inévitables sur les systèmes dont la durée de vie dépasse celle d’un prototype. En fait, le besoin de tests de migration d’un ancien composant vers un autre, avec la reprise des données existantes, est une chose pratiquement inévitable.

Voyons ensemble les tenants et aboutissants liés à ce sujet afin de vous permettre d’être prêts pour faire face à ce genre de situations.

1. Généralités sur les migrations

Le besoin de migration peut avoir lieu à tous les niveaux :

  • l’emplacement géographique de l’infrastructure ;

  • le changement des serveurs ;

  • le changement d’OS ;

  • le changement de base de données ;

  • le changement de technologie ;

  • le changement de framework de développement ;

  • le changement fonctionnel.

Chaque situation méritera de définir un plan d’attaque de la migration avec notamment :

  • son périmètre ;

  • une analyse des risques ;

  • un calendrier ;

  • le mode de bascule - par ex. en mode « big bang », par secteurs ou en ZDD (voir chapitre Versant technique du test) ;

  • un plan de secours ;

  • un moyen de test qui vérifie que la migration n’a pas affecté négativement le service.

Il est aisé de constater que plus une migration attend d’être réalisée, plus elle aura tendance à embarquer dans son sillage d’autres parties, ce qui vient complexifier le projet de migration.

En conséquence, si un produit est conçu en intégrant la désuétude prochaine de ses parties dès son démarrage, il est nécessaire de prévoir :

  • une infrastructure qui devrait pouvoir être déménagée rapidement, par exemple avec l’usage de l’IaC (voir chapitre Versant technique du test) ;

  • des applications qui ne devraient pas dépendre d’un OS, par exemple au travers des dépendances isolées dans quelques composants spécifiques, de VM ou de conteneurs (voir chapitre Versant technique du test) ;

  • des technologies en évolution constante, mais interopérables pour ne pas induire de dépendances...

Tests de tolérance aux pannes

La tolérance aux pannes est un comportement du système qui a intégré dès sa conception un comportement qui reste acceptable, même en cas de problème. Cet attribut est indispensable sur les systèmes critiques tels que :

  • les systèmes qui nécessitent qu’une information soit transmise comme les calculateurs embarqués dans les avions, ou les télécommunications à usage militaire, qui doivent obtenir la bonne information même en cas de défaillance ou d’erreur de transmission ;

  • les systèmes où la disponibilité est critique, comme les systèmes de secours (ex. la mise en route automatique d’un groupe électrogène dans un hôpital) ;

  • les systèmes qui subissent une dégradation progressive du matériel que le logiciel vient compenser jusqu’à ce qu’il renseigne à l’avance sur le remplacement nécessaire des pièces ;

  • les systèmes qui subissent des perturbations éventuellement brutales de l’environnement, avec une stabilisation automatique pour que les conditions internes du système soient viables.

Ces systèmes ont en commun :

  • une identification au plus tôt de la criticité et du facteur de défaillance ;

  • le mécanisme de déclenchement du système de secours : une conception résiliente qui répond à cette situation jugée inacceptable et les moyens (souvent élevés) pour faire face à la défaillance à venir ;

  • une instrumentation et une mise en condition pour tester le bon fonctionnement du système de secours.

Pour tester les tolérances aux pannes, vous pouvez procéder à des simulations à l’aide de modèles ; ou plus simplement, introduire délibérément des défauts dans le système pour observer son comportement.

Chaos engineering

Reportez-vous à la section Chaos Engineering du chapitre Environnement technique du test pour aller plus loin dans cette approche.

En termes de prévention, tout comme lorsque nous ne pouvons pas ajouter des pannes, il est nécessaire de mettre en place des journaux détaillés associés à...

Tests d’exploitabilité

Suivant les contextes, ce type de tests est aussi appelé VABE (Vérification d’Aptitude à la Bonne Exploitabilité), ou VAE (Vérification d’Aptitude à l’Exploitabilité) ; et si le test est réalisé après déploiement en production, nous parlons alors de VSR (Vérification du Service Régulier).

L’objectif des tests d’exploitabilité est de vérifier que le niveau de qualité de service pour une mise en production est suffisant. Il couvre généralement :

  • la documentation nécessaire (ex. : codes d’erreurs, analyse des journaux, moyens d’accès, etc.) pour que l’équipe de support utilisateur puisse avoir les informations suffisantes pour jouer son rôle ; si nécessaire, une présentation, voire une formation, sera dispensée à cette équipe pour que sa connaissance et son savoir-faire soient assurés.

  • les tests de déploiement et de retour arrière (rollback) ont été réalisés sur des environnements les plus proches possibles de la production.

  • la vérification que les tests de charges ont des résultats compatibles avec les niveaux attendus en production.

  • la vérification que le niveau de sécurité est en conformité...

Tests de traçabilité

1. Périmètre

La traçabilité est un élément indispensable à un suivi rigoureux des tests.

Lorsqu’il s’agit de connaître la couverture des exigences par les tests, c’est grâce aux liens que vous faites entre les exigences et les tests ; c’est ce qui s’appelle la traçabilité.

Lorsque votre rapport de test établit un statut sur la qualité du produit, la traçabilité de vos tests quant aux versions testées, et la possibilité de retrouver le statut de ces tests dans votre outil de gestion des tests n’est rendue possible qu’avec un effort de traçabilité. 

Lorsque les coûts liés à une mauvaise gestion des impacts d’une anomalie planent au-dessus du projet, c’est encore la traçabilité qui peut vous venir en aide. La traçabilité reflète ainsi une partie de votre capacité à industrialiser votre travail de testeur.

Par ailleurs, dans certains contextes où des vies humaines sont en jeu, comme dans le domaine médical ou l’aéronautique, la traçabilité est une exigence non fonctionnelle réglementaire.

images/X-icone.png

Traçabilité des lots

Dans le cas des produits électroniques manufacturés, la traçabilité est introduite afin de limiter les frais engendrés en cas de problème matériel. La traçabilité peut se faire à un niveau plus ou moins grossier comme :

  • l’identifiant de chaque batch de production de X produits ;

  • le numéro de série de chaque produit ;

  • les numéros de lots de chaque carte mère ;

  • les numéros de lots de chaque composant ;

  • la version du firmware (logiciel flashé à l’usine) ;

  • la version des plans électroniques et les références fournisseur de chaque pièce mécanique (la BOM - Bill of Materials - la nomenclature du produit - https://fr.wikipedia.org/wiki/Nomenclature_(logistique).

La traçabilité mise en place devait permettre d’identifier les numéros de série des produits impactés à partir des lots de parties défectueuses, et vice-versa.

L’idée est d’être...

Tests de sûreté de fonctionnement

La sûreté de fonctionnement est la combinaison de différents facteurs [Laprie 1996] :

  • la fiabilité : ce point peut être couvert notamment par :

  • l’exactitude fonctionnelle et attestée par les tests fonctionnels ;

  • la tolérance aux pannes ;

  • l’utilisabilité ;

  • la durabilité ;

  • la maintenabilité ;

  • la disponibilité et les temps de réponse ;

  • la confidentialité ;

  • l’intégrité : impossibilité d’altération des informations ;

  • la sécurité et l’innocuité : absence de conséquences catastrophiques - la prévention des incidents graves issue d’une analyse de risques.

Dans un premier temps, nous pouvons percevoir la sûreté de fonctionnement comme l’empilement des tranches d’emmental ; chaque tranche est un type de test de sûreté dont le niveau peut alors être calculé comme :

  • le rapport entre les tranches à appliquer et le niveau de risque acceptable sur une version donnée ;

  • le résultat des tests de ces différents contrôles identifiés le plus en amont possible comme une valeur qui sera pondérée par le poids du type de test, par exemple :

Type de test

Poids

Score du test (sur 10)

Résultat (Poids x Score)

Tests fonctionnels

10

8

80

Tests de sécurité

7

4,5

31,5

Tests d’utilisabilité

5

3

15

Tests de charges

2

9

18

Tests de migration

0

(dans notre exemple, il n’y a pas de migration de version prévue)

-

-

Tests de tolérance aux pannes

8

6

48

Tests d’exploitabilité

4

7

28

Tests de traçabilité

2

1

2

RGPD

3

5

15

SÛRETÉ

 

SCORE GLOBAL

images/05DP45.png

5,79

Cet exemple de modélisation peut aussi inclure une pondération, ou une évolution des poids suivant le contexte de la version, ou toute autre valeur qui serait perçue comme pertinente dans l’évaluation de la sûreté de fonctionnement.

La difficulté avec la plupart de ces tests est qu’ils dépendent du bon fonctionnement applicatif. Dans un contexte agile, nous commencerons par réaliser...

Ecoconception

L’écoconception est la volonté de concevoir des produits respectant les principes du développement durable et de l’environnement.

1. Pourquoi devrions-nous tester l’écoconception ?

Voyons ensemble pourquoi vous devriez tester cette exigence non fonctionnelle qui est, à ce jour, en dehors de l’ISO 25010.

Depuis les premiers rapports du Groupe d’Experts Intergouvernemental sur l’Evolution du Climat (GIEC) en 1990 (http://tinyurl.com/rapport-giec-1990), tout le monde a entendu parler de l’impact du CO2 sur notre planète.

Au-delà des débats, voici quelques éléments de réflexion pour vous faire votre propre idée sur ce sujet complexe.

Dans un premier temps, prenez conscience que le CO2 n’est qu’une partie de la problématique. Cela s’appelle effet « Carbon Tunnel Vision » [Konietzko 2021], et correspond à notre aveuglement sur d’autres enjeux que le sempiternel réchauffement climatique dû aux émissions de gaz carboniques.

Ainsi, le rapport de l’ADEME (l’Agence de l’environnement et de la maîtrise de l’énergie) publié en 2022 partage quelques chiffres qui illustrent cela [ADEME 2022] :

  • en France, 10 % de la consommation électrique est liée aux services numériques, et au niveau mondial, 4 % des émissions de Gaz à Effet de Serre (GES) comme le CO2 ;

  • dans le monde, 55 % de la consommation d’énergie correspond est due au trafic des données ;

À titre de comparaison, le trafic aérien contribue à environ 2,5 % des rejets de GES et les véhicules légers à 8 % [Ferreboeuf 2021]. Ici, l’idée n’est pas de pointer du doigt le secteur à abattre, et quel que soit l’avis que nous pouvons avoir sur un quelconque bouleversement climatique, ces mesures montrent que l’informatique a un poids non négligeable dans cette balance.

Par ailleurs, si nous faisons l’analyse du cycle de vie (voir ISO 14040 et 14044) propre au secteur informatique, les GES sont produits à hauteur de [ADEME 2022] :

  • 37 % dans la fabrication des appareils numériques ;

  • 25 % dans les infrastructures réseau et datacenters ;...

Proposition d’organisation pour le test des ENF

Les ENF peuvent prendre beaucoup de temps sur leur ingénierie, comme sur les tests. Par ailleurs, vous remarquerez que la majeure partie des ENF correspond à des contraintes qui émanent de l’exploitation de la solution. La position de Google sur ces contraintes de production est assez radicale [Beyer 2016] :

  • commencer par traiter les contraintes de production ;

  • plafonner le temps de développement des exigences fonctionnelles à 50 %.

De cette façon, les ENF ne sont jamais négligées.

Malheureusement, les ENF sont des exigences que nous découvrons avec l’expérience, tant sur le savoir-faire de test, que sur les attentes des exploitants. Il n’est donc pas rare de livrer des US dont les ENF sont partiellement atteints, ce qui a pour conséquence la reprise du code, ce qui contribue à la dette technique de la solution.

Plutôt que de fermer les yeux sur cette dette, [Larman 2010] fait des propositions telles que :

  • la montée en compétence sur les nouveaux ENF ;

  • la reprise d’ENF partiellement traitées ;

  • l’attribution de thèmes/étiquettes dans vos tickets et composants pour retrouver les endroits où les ENF sont à introduire, corriger, ou améliorer.

En tant que testeur, vous devrez profiter d’opportunités pour saisir la balle au vol, afin d’inciter votre équipe ou le management, et développer des activités de test autour de certaines ENF. En termes d’effectuation, cela s’appelle « la limonade ».

images/I-icone.png

L’effectuation au service des ENF

L’effectuation trouve ses origines à la fin des années 1990 par Saras Sarasvathy, alors jeune doctorante d’origine indienne et ancienne entrepreneure. Elle a abouti à ce concept lors de ses recherches à l’université Carnegie Mellon sous la direction d’Herbert Simon, lauréat du prix Nobel d’économie. Sarasvathy a cherché à identifier les fondements microéconomiques du raisonnement entrepreneurial. Ses résultats ont révolutionné notre façon de penser la manière dont les entrepreneurs raisonnent et agissent dans leur processus...