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 :

À 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 :

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é.

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] :

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] :

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] :

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 » :

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.

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 :

Ces systèmes ont en commun :

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.

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 :

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.

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] :

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 :

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	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.

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] :

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 :

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 ».

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...