Les heuristiques de test

Ce qu’est une heuristique de test

Une question courte, posée à un système ou à un document, rend en quelques minutes une liste d’idées de test; la mesure de ce qu’elle a laissé de côté vient d’ailleurs. Le glossaire ISTQB définit l’heuristique comme une règle empirique reconnue qui aide à atteindre un but. Il porte l’entrée distincte test heuristic¹.

Une heuristique sert quand la spécification est muette, quand le temps manque ou quand un système inconnu doit livrer ses premiers renseignements en une heure. Elle complète la conception raisonnée d’un jeu de tests et la couverture mesurée.

Le nom rend l’heuristique transmissible. «Applique CRUD à cette entité» tient en une phrase, là où la description complète en demande cinq, et l’interlocuteur sait quoi faire. Ces noms restent en anglais dans ce chapitre, tels qu’ils sont imprimés sur la feuille. La prose française les glose.

Domaines de test

Une heuristique produit une idée de test à la fois. Un cadre découpe la matière avant qu’il y ait des idées: il dit où regarder, dans quel ordre et contre quoi comparer ce que l’on voit.

Le groupe Web Tests occupe le chapitre suivant, avec le reste de ce que le navigateur et le protocole ajoutent au système.

Les attaques par type de donnée (Data Type Attacks)

Elles s’appliquent à un champ de formulaire, à un paramètre d’URL, à une colonne importée et à un argument d’API².

Nombres

Un nombre du domaine n’a pas de largeur. Dans la machine, il en a une. Les architectures matérielles travaillent par multiples de huit bits, et les types entiers suivent: octet sur 8 bits, word sur 16, long word sur 32, quad word sur 64. Un type signé réserve un bit au signe, ce qui plafonne un entier signé sur 16 bits à 32767 quand le même type non signé atteint 65535. Le développeur choisit cette largeur au moment où il écrit, sur ce qui suffit alors. Le domaine, lui, ne connaît pas cette limite: un compteur de transactions, un montant en centimes ou un identifiant croissant la franchissent des mois plus tard. Au franchissement, le comportement dépend du langage: la valeur repasse au minimum négatif, une exception est levée ou le calcul sature silencieusement.

La virgule flottante apporte un second mécanisme, indépendant du premier. La norme IEEE 754 écrit un nombre comme une somme de puissances de deux³. La fraction décimale 0,1 n’a pas d’écriture finie dans cette base, comme 1/3 n’en a pas en base dix. Elle est donc stockée arrondie. L’écart est invisible sur une valeur et s’accumule sur un lot: additionner dix fois 0,1 ne rend pas 1,0. Sur des montants, la dérive se compte en centimes après quelques milliers de lignes, et le total du grand livre cesse de correspondre à la somme des postes.

On essaie les valeurs qui bordent chaque largeur, dans les deux régimes: 127 et 128, 255 et 256, 32767 et 32768, 65535 et 65536, 2147483647 et 2147483648, plus leurs symétriques négatives. On ajoute zéro, un négatif, une décimale minuscule et la notation scientifique. La série traverse ensuite un calcul, parce qu’un champ accepte une valeur à l’entrée puis la tronque dans une addition. Pour la virgule flottante, l’oracle est une comparaison: on somme dix fois 0,1 et on compare à 1,0, on calcule la TVA ligne par ligne et on compare à la TVA calculée une fois sur le total. L’écran, lui, arrondit à deux décimales et ne montre rien.

Strings / chaînes de caractères

Une chaîne a deux dimensions que le domaine ignore: sa longueur en mémoire et son encodage. La longueur déclarée dans l’interface, celle du schéma de base de données et celle du tampon intermédiaire sont trois valeurs distinctes, et la plus petite tronque. L’encodage pose un second écart: en UTF-8, un caractère accentué occupe deux octets, un émoji trois. Un champ borné à 255 octets ne tient donc pas 255 caractères. La troncature peut couper au milieu d’un caractère, produisant une séquence invalide que la couche suivante rejette ou remplace.

On éprouve les longueurs qui bordent les tailles usuelles: 255, 256, 1024, 2048 et au-delà. On éprouve le jeu de caractères: accents (UTF), idéogrammes, délimiteurs, caractères d’échappement, chaîne d’injection SQL. On y ajoute les valeurs que personne ne saisit volontairement: champ vide, espace seule, espaces en tête, fin de ligne. Chacune traverse ensuite toutes les actions du champ, la saisie, la recherche et la mise à jour. L’oracle de l’encodage est l’aller-retour: on écrit, on relit par un autre chemin, on compare octet à octet.

Heures et dates

Deux horloges cohabitent. Celle de la machine dérive, diffère d’un serveur à l’autre et se déplace deux fois par an au passage à l’heure d’été. Celle du calendrier porte des irrégularités que l’arithmétique naïve ignore: années bissextiles, mois de longueur inégale, jours qui n’existent pas. S’y ajoute l’ambiguïté du format: entre 08/30/2026 et 30/08/2026, rien ne distingue le jour du mois tant que les deux composantes restent inférieures à treize, et la conversion réussit sur une valeur fausse.

Côté machine: expiration, décalage entre deux serveurs, franchissement de fuseau, passage à l’heure d’été, horloge reculée. Côté calendrier: le 29 février, le 29 février d’une année non bissextile, le 31 septembre. L’oracle est le résultat calculé, pas l’affichage: on compte une durée qui enjambe le changement d’heure et on la compare au nombre d’heures réel, qui vaut 23 ou 25 ce jour-là.

P.ex. En Suisse, une date s’écrit 30.08.2026. Un utilisateur qui colle une date recopiée d’une page web américaine apporte 08/30/2026. Le champ le refuse ou l’interprète selon une règle annoncée. En France la situation est encore plus ambigüe: les sépérateurs de date sont identiques.

General

Deux règles se déclarent hors du type. Premièrement: la règle du domaine, qui dit qu’une adresse email porte une arobase et qu’un âge n’est pas négatif. Mais: dans le cas très particuliers d’une assurance d’enfant(s - jumeaux) enfants pas encore nés où on saisit la date du terme de la grossesse. Deuxièment, la contrainte d’unicité, qui dit qu’un identifiant ne se répète pas. Toutes deux se vérifient à un seul endroit dans le code, souvent l’écran. Les autres chemins d’écriture la contournent: import, API, correction manuelle en base.

On soumet une valeur syntaxiquement correcte et sémantiquement fausse: une adresse sans arobase, un âge négatif, une clé de contrôle qui échoue sur un numéro bien formé. Puis on soumet un doublon. L’oracle est le refus, et il se vérifie par chaque canal d’écriture, pas seulement par l’écran.

Chemins d’accès et fichiers

Un nom de fichier voyage plus loin que le fichier: il traverse un système de fichiers, une base, une archive, parfois une URL. Chaque étape a ses caractères interdits et sa longueur maximale, et aucune ne prévient quand elle normalise. Le fichier lui-même ajoute des états que le code de lecture ignore: absent, déjà présent, protégé en écriture, verrouillé par un autre processus, distant, tronqué.

On éprouve le nom au-delà de 255 caractères et avec les caractères spéciaux qu’il transporte, espaces et accents compris. On éprouve ensuite le chemin qui n’existe pas et celui qui existe déjà, puis le fichier protégé, verrouillé, distant, corrompu. L’oracle est l’état du stockage après l’opération, pas le message affiché.

Les tests non procéduraux

Variable Analysis

Un système se comporte selon des valeurs qui changent à l’exécution, et l’inventaire qu’en fait la spécification s’arrête aux champs de l’écran. Les autres restent hors du champ de vision: fuseau horaire, langue de l’interface, délai d’expiration de session, drapeau de fonctionnalité, compteur interne, barème chargé au démarrage. Une variable qui n’a pas été recensée n’a pas de domaine valide écrit, donc pas de comportement défini hors domaine.

On recense tout ce dont la valeur peut changer, en trois passes: les variables évidentes de l’interface, les variables discrètes de l’environnement, les variables cachées du code et de la configuration. Chaque variable recensée devient un axe: on la fait varier seule, les autres tenues fixes. L’oracle est le domaine valide de la variable, qui doit exister avant l’essai.

Points de contact

Un système s’observe par plus d’un chemin. L’écran affiche une valeur mise en forme, la base en stocke une autre, le journal en enregistre une troisième, l’API en publie une quatrième. Une conversion fautive entre deux de ces points reste invisible tant que l’on ne regarde qu’un seul.

On recense les interfaces publiques et privées qui donnent de la visibilité ou du contrôle: écran, API, fichier de configuration, base, journal, file de messages. Chacune sert à provoquer, à observer ou à vérifier. L’oracle est croisé: on provoque par un point et on vérifie par un autre.

P.ex. un logiciel de facturation qui produit des QR-factures offre au moins cinq points de contact: l’écran de saisie, le PDF émis, la ligne enregistrée en base, le journal d’envoi et le fichier camt.054 que la banque renvoie après paiement. Vérifier un montant par le seul écran laisse quatre points sans oracle.

Limmites

Une limite s’écrit dans le code par une comparaison, et la comparaison porte quatre écritures possibles pour la même intention. Le glissement d’une unité entre < et <= échappe à la lecture rapide et ne se manifeste que sur la valeur exacte de la limite ou sa voisine.

On essaie la valeur juste avant la limite, la limite elle-même et la valeur juste après, dans les deux sens du domaine. C’est l’heuristique la plus proche de l’analyse des valeurs limites du vocabulaire ISTQB¹. L’oracle est le comportement annoncé de part et d’autre, qui doit donc être écrit avant l’essai.

Goldilocks

Une quantité que le système accepte ou produit relève souvent de plusieurs régimes, et chaque régime suit son propre chemin de code. Boundaries cherche le bord exact entre deux régimes. Goldilocks vérifie d’abord que les trois régimes existent et se comportent chacun comme annoncé, y compris le régime nominal, que personne n’éprouve parce qu’il paraît acquis. Le nom vient du conte anglais des trois ours.

On essaie une valeur trop grande, une trop petite et une juste, et on lit le résultat des trois. L’oracle du régime nominal se calcule à la main, séparément.

CRUD

Create, Read, Update, Delete. Les quatre opérations d’une entité conservée s’écrivent par des chemins de code distincts, et la spécification n’en décrit qu’un. La création reçoit l’attention parce qu’elle porte l’écran. La suppression reçoit la sienne en production, quand il faut décider du sort de ce qui dépendait de l’entité supprimée.

On exerce les quatre opérations sur l’entité, et on lit dans quel état chacune laisse la donnée. L’oracle est une lecture qui suit l’écriture, par un autre point de contact que celui qui a écrit.

Follow the Data

Une donnée traverse une chaîne d’opérations et change de représentation à chaque frontière: saisie, stockage, transformation, export, import, affichage. Chaque frontière peut tronquer, reformater, convertir en nombre ou perdre un zéro de tête. Le défaut naît à une seule étape et se manifeste à une autre, ce qui explique qu’il résiste aux tests unitaires: chaque étape, prise seule, fait ce qu’elle annonce.

On choisit une donnée et on la suit d’un bout à l’autre d’une chaîne réaliste, en vérifiant l’intégrité à chaque étape. L’oracle est la comparaison à la valeur d’origine, caractère par caractère, à chaque frontière.

Configurations

Le système tourne dans un environnement que le développeur n’a pas: son poste a de la mémoire, un grand écran et un réseau local. L’environnement réel fait varier la résolution, le débit, la latence, la qualité du signal, la mémoire, la place disque et le nombre de périphériques. Un code correct sur un environnement se comporte autrement sur un autre, sans qu’aucune ligne change.

On fait varier une dimension d’environnement à la fois, puis on combine les deux ou trois qui coexistent chez l’utilisateur. La feuille y ajoute Count appliqué aux périphériques: zéro, un, plusieurs écrans ou imprimantes. L’oracle est le comportement annoncé pour la configuration minimale prise en charge, qui doit donc être écrite.

Interruptions

Une opération en plusieurs étapes laisse le système dans un état intermédiaire entre la première étape et la dernière. Si rien ne délimite la transaction, une interruption fige cet état intermédiaire: la moitié des écritures est passée, l’autre non. Les causes d’interruption sont banales: déconnexion, arrêt de la machine, redémarrage, processus tué, réseau coupé, mise en veille, expiration de session, annulation par l’utilisateur.

On arrête l’opération en cours de route, à chaque étape, puis on lit l’état du système et l’état du stockage. On recommence ensuite l’opération pour voir si la reprise duplique son effet. L’oracle est l’idempotence: la même opération reprise après interruption doit produire un seul effet.

Starvation

Un système dimensionné pour des ressources nominales change de comportement quand la mémoire, le processeur, le réseau ou le disque deviennent rares. Le système d’exploitation compense avant d’échouer: il pagine vers le disque (swapping), il met des requêtes en file, il limite le débit. Ces modes de compensation coûtent de la latence, et le code applicatif ne les voit pas. Les délais d’expiration, calibrés sur la latence nominale, se déclenchent alors; les reprises ajoutent de la charge; le système entre dans un régime que personne n’a spécifié.

On contraint délibérément une ressource: plafonner la mémoire, saturer le processeur, remplir le disque, brider la bande passante. On observe ensuite le comportement sous cette contrainte. La mesure porte sur les temps de réponse et sur les modes de compensation déclenchés, pas seulement sur le succès ou l’échec. L’oracle est la dégradation annoncée: refus propre, file d’attente, service réduit.

Position

La même opération rencontre un contexte différent selon son rang: le premier élément trouve un accumulateur vide, le dernier un état accumulé, celui du milieu des voisins des deux côtés. Ces trois situations empruntent des chemins de code séparés: initialisation, corps de boucle, terminaison. Chacun porte ses propres défauts.

On exécute la même action au début, au milieu et à la fin de la séquence, et on lit le résultat des trois. L’oracle est un résultat calculé indépendamment, pas la cohérence apparente de l’écran.

Sélection

Une interface qui propose une sélection multiple porte trois régimes: une partie des éléments, aucun, tous. La spécification décrit le premier, parce qu’il est le cas courant. Les deux autres traversent d’autres chemins: le traitement de l’ensemble vide, qui produit un total nul, un rapport sans ligne ou une action offerte sans objet; et la combinatoire complète, qui fait se rencontrer des options mutuellement exclusives que personne n’a confrontées.

On exécute l’opération sur une partie, puis sur aucun, puis sur tous, et on lit ce que le système fait de chaque cas. L’oracle du cas vide est une règle écrite: refus ou résultat neutre annoncé. L’oracle du cas complet est la liste des incompatibilités déclarées.

Comptes

Une spécification rédigée au singulier («le sinistre», «le contrat») laisse indéterminés le cas zéro et le cas multiple. Le code, lui, doit trancher: il charge une collection, en prend le premier élément ou suppose qu’il en existe au moins un. Sur une collection vide, cette supposition produit une erreur; sur une collection nombreuse, elle produit un écran illisible ou une lecture qui charge tout en mémoire.

On essaie zéro instance, exactement une, puis beaucoup, sur chaque entité et chaque relation. L’oracle du cas zéro est un écran annoncé, pas une page vide par accident. L’oracle du cas multiple porte aussi sur le temps de réponse.

Multi-User

Deux écritures simultanées sur la même donnée entrent en concurrence. Entre la lecture d’une valeur et son écriture, un autre acteur a écrit; la seconde écriture, calculée sur une valeur périmée, écrase la première. Le défaut dépend de l’ordonnancement, donc il ne se reproduit pas à volonté et disparaît des tests séquentiels.

Deux comptes, ou le même compte ouvert deux fois, agissent sur la même donnée au même moment, en création, en modification et en suppression. L’oracle est l’état final de la donnée comparé aux deux intentions et le message rendu à celui dont l’écriture n’a pas abouti.

Innonder

Un système répond correctement à chaque requête et cède sous leur arrivée simultanée. Les ressources partagées se raréfient au même instant: connexions à la base, fils d’exécution, file d’attente.

On envoie beaucoup de transactions ou de requêtes simultanées, de sorte qu’elles arrivent ensemble ou s’empilent dans une file. L’oracle porte sur le taux d’erreur et sur le temps de réponse au percentile, pas sur la moyenne, qui masque les requêtes tombées.

Dépendences

Les entités se tiennent par des relations «a un», et la relation porte ses propres défauts. Le nombre d’éléments au bout de la relation, l’ordre dans lequel on les supprime, ce qui arrive au parent quand l’enfant disparaît: chacun de ces points a un comportement, et la spécification décrit les entités sans décrire la relation.

On recense les relations «a un», puis on applique CRUD, Count, Position et Selection à la relation elle-même. L’oracle est chaque fois l’état de l’entité de l’autre bout après l’opération.

Contraintes

Une contrainte déclarée par le système (champ obligatoire, dépendance entre deux champs, unicité) se vérifie là où elle a été écrite. Les autres canaux d’entrée l’ignorent. Un import de masse insère alors des lignes que l’écran aurait refusées, et la base se retrouve avec des données qu’aucun chemin nominal ne pouvait produire.

On viole la contrainte: on laisse vide un champ obligatoire, on compose une combinaison invalide entre deux champs dépendants, on saisit un identifiant en double. La feuille demande de croiser avec Input Method, donc de violer la contrainte par chaque canal. L’oracle est le refus, et il se vérifie canal par canal.

Input Method

La même donnée entre par plusieurs canaux: frappe, copier-coller, import de fichier, glisser-déposer, appel d’API. Chaque canal valide et normalise à sa façon. Le copier-coller apporte ce que la source contenait: espaces insécables, retours de ligne, mise en forme. L’API n’a pas de couche de présentation pour nettoyer. La même valeur métier finit enregistrée sous plusieurs écritures, et la recherche ne les rapproche pas.

On fait entrer la même donnée par chaque canal offert, puis on relit ce qui est stocké. L’oracle est l’égalité octet à octet des enregistrements produits par les différents canaux.

Sequences

L’ordre des opérations est une variable que la spécification ne traite pas. Elle décrit un enchaînement nominal, et le système en accepte d’autres. Chaque ordre laisse un état différent, et les états atteints par un ordre non prévu ne sont couverts par aucun cas de test.

On fait varier l’ordre: annuler puis refaire, inverser, combiner, exécuter en même temps. L’oracle est l’état final, comparé à celui qu’aurait produit l’ordre nominal quand l’ordre ne devrait rien changer.

Sorting

Un tri dépend d’une collation, c’est-à-dire de la règle qui compare deux chaînes. Elle décide de la place des accents, des majuscules, des espaces et des traits d’union, et elle diffère entre la base de données, le langage applicatif et le navigateur. Un tri appliqué par morceaux, page après page, produit alors un ordre qui n’est global nulle part, et un élément peut apparaître deux fois ou pas du tout.

On trie alphabétiquement, puis numériquement, puis on regarde ce que devient l’ordre au passage à la page suivante. L’oracle est la liste triée attendue, écrite d’avance, avec les cas qui départagent les collations.

State Analysis

Un objet métier passe par des états, et la prose énonce mal les règles qui gouvernent les transitions. La prose décrit le chemin nominal; elle laisse indéterminées les transitions absentes, les retours en arrière et les états atteints par accident, comme celui où laisse une session expirée en cours de saisie.

On recense les états et les événements qui les relient, puis on les pose en diagramme ou en table. La table rend visibles les cases vides, qui sont les transitions non spécifiées. La feuille signale que cette heuristique travaille avec Sequences et Interruptions. La modélisation des états en donne la notation.

Map Making

Un système inconnu se découvre par ses écrans, et l’exploration libre repasse par les mêmes chemins en laissant des zones entières sans visite.

On choisit un état de départ, on fait un pas dans une direction, on revient au départ, on recommence dans une autre. Le procédé parcourt une arborescence de menus, un assistant en plusieurs écrans ou un flux de validation sans s’y perdre. L’oracle est la carte elle-même: les écrans d’où le retour au départ échoue sont le premier résultat.

Users & Scenarios

Un système est spécifié pour un utilisateur moyen que personne n’a rencontré. Les utilisateurs réels ont des situations que le cas nominal n’admet pas: deux pays, une langue minoritaire, une technologie d’assistance, une intention hostile. Ces situations sont les cas courants d’une population que la spécification n’a pas décrite.

On conçoit les tests autour de qui se sert du système et pourquoi: cas d’utilisation, personas, personnalités extrêmes comme l’impatient, le malveillant ou le désorienté. La feuille y ajoute des soap operas, enchaînements dramatiques mais possibles. L’oracle est la tâche achevée par cet utilisateur, pas la fonction disponible.

Les approches

Jugement

Un défaut se constate contre une référence, et la référence manque le plus souvent. Un jugement en donne trois et cherche contre chacune les incohérences, les absences et les ajouts.

On prend une référence à la fois et on parcourt le système avec elle. La troisième référence manque dans les revues: personne n’écrit qu’un montant s’affiche avec l’apostrophe des milliers, et tout le monde le remarque quand il s’affiche autrement.

Observations

Ce que l’on regarde tient en trois endroits: ce qui entre, ce qui sort et le lien entre les deux. Le lien est le moins observé, parce qu’il n’a pas d’écran. Il porte pourtant l’appariement, la règle de correspondance et la jointure.

On instrumente les trois endroits pendant une même exécution réelle. L’oracle du lien est un contrôle de correspondance: chaque élément d’entrée retrouvé dans la sortie et réciproquement.

Flux

Un défaut situé dans un traitement se constate en sortie, où plusieurs causes produisent le même symptôme. Tant que l’entrée, le traitement et la sortie ne sont pas éprouvés séparément, le diagnostic reste une hypothèse.

On découpe le système, ou une seule fonction, en entrée, traitement et sortie, et on attaque chaque étape pour elle-même, avec sa propre entrée et son propre verdict. Observations désigne des endroits où regarder pendant une exécution; Flow en fait trois épreuves séparées.

Requirements

Une analyse d’exigences omet des catégories entières. Gause et Weinberg en donnent quatre: les utilisateurs, les fonctions, les attributs, les contraintes⁴. Une catégorie vide passe inaperçue parce que rien ne la réclame. C’est le seul des six cadres qui soit d’abord une technique d’analyse.

On classifie la spécification dans les quatre catégories et on lit les cases vides.

Noms et verbes

Une spécification en prose porte son modèle de données sans le déclarer. Les noms désignent les objets et les données, les verbes les actions, les adjectifs les attributs, les adverbes la manière. Tant que ce contenu reste implicite, personne ne peut constater qu’une entité manque.

On lit la spécification pour ses noms, puis pour ses verbes, puis pour ses qualificatifs, et on range chaque terme en entité, fonction ou attribut candidat. L’oracle est le dictionnaire de données: tout terme sans entrée est un terme non défini.

Deming’s Cycle

Une série de sessions exploratoires répète la même heure de travail quand rien ne relie une session à la suivante.

Plan, Do, Check, Act, appliqué à une session de test: préparer une charte, l’exécuter, examiner ce qu’elle a appris, en tirer la charte suivante. Deming lui-même écrivait Plan, Do, Study, Act. Il attribuait la roue à Walter Shewhart.

La charte de test

Une heuristique nommée reste un angle. La charte en fait une tâche bornée dans le temps. Elle s’écrit sur une formule⁵:

Explorer <la cible> avec <les ressources> pour découvrir <l’information>

La cible est ce que l’on explore: un écran, une fonction, un module, une exigence. Les ressources sont ce que l’on emporte: un jeu de données, un outil, une fonction voisine, une heuristique de cette feuille. L’information est ce que l’on espère apprendre.

La revue de spécification

Ces tests s’adressent à un testeur devant un système qui tourne. Un analyste qui relit un document n’essaie aucune valeur et la plupart de ces entrées se retournent en question posée au texte. Le classement ci-dessous est le nôtren.

Exigences non-fonctionnelles

«Le système ne perd aucune donnée lorsqu’une opération est interrompue» est une exigence légitime, que l’analyste fait écrire et qui relève de l’analyse des exigences non fonctionnelles. Elle ne devient testable qu’une fois chiffrée et rendue observable. Les exigences de diponibilié tu type 99.9999% peuvent être exprimées, mais impossible à tester efficacement.

Une liste de contrôle pour la revue par un agent

Ces heuristiques sont nées dans le développement agile, où des spécialistes du test rendaient au développeur un retour rapide. Un agent de codage pose le même problème: il produit vite, sans que personne ait éprouvé ce qu’il produit. La boucle de retour se reconstruit au même endroit.

Six familles se transposent en contrôles qu’un agent exécute sur un diff ou sur une spécification. Chacune est un fichier à télécharger, à déposer dans le dossier des compétences de l’agent. Les vérifications sont à l’impératif, une par ligne.

Contrôle des variables · variables-test.md

Recense les valeurs qui changent à l’exécution et vérifie que chacune a un domaine valide, une valeur par défaut et un comportement hors domaine.

Contrôle des bornes · bornes-test.md

Éprouve les limites numériques, de date et de longueur, la largeur du type entier choisi et l’usage d’un flottant binaire sur un montant.

Contrôle CRUD · crud-test.md

Vérifie que les quatre opérations sont couvertes sur chaque entité que le diff touche, au-delà de celle qu’il implémente.

Contrôle du cardinal · cardinal-test.md

Éprouve le cas zéro, le cas unique et le cas multiple, aux deux bouts de chaque relation, et signale les lectures sans borne.

Contrôle des interruptions · interruptions-test.md

Dit dans quel état une opération en plusieurs étapes laisse le système quand elle est interrompue, et vérifie que sa reprise ne duplique pas son effet.

Contrôle du parcours de la donnée · parcours-donnee-test.md

Suit une donnée par toutes les étapes qu’elle traverse et nomme celles où sa forme peut changer, encodage compris.

Le chapitre suivant

Les heuristiques web. Les quatre familles de tests web de la Test Heuristics Cheat Sheet: ce que le navigateur et le protocole ajoutent au système, le mécanisme qui produit le défaut et l'oracle de l'observation.

Notes et références