Tableau montrant les transitions résultantes pour chaque état combiné à chaque événement possible, montrant les transitions valides et invalides.

Table montrant la combinaison des entrées et/ou stimuli (causes) et de leurs sorties et/ou actions (effets) associées, qui peut être utilisée pour concevoir des cas de tests.

Une représentation de mesures dynamiques des performances opérationnelles d'une organisation ou d'une activité. On utilise des métriques représentées par des métaphores telles que des alarmes visuelles, des compteurs et d'autres dispositifs ressemblant à ceux du tableau de bord d'une voiture. Le but étant que les effets des évènements ou activités puissent être facilement compris et reliés à des objectifs opérationnels.

Une représentation - de type tableau de bord - du statut des données relatives à l'efficacité de l'entreprise.

Un outil stratégique de gestion des performances permettant de mesurer si les activités opérationnelles d'une entreprise sont conformes à ses objectifs en termes de vision commerciale et de stratégie.

Un tableau à deux dimensions construit à partir de propriétés mathématiques particulières, tel que le choix de deux colonnes du tableau fournit toutes les paires de combinaisons de chaque nombre du tableau.

Le rapport du nombre de défaillances d'une catégorie à une unité de mesure donnée, p.ex. défaillances par unité de temps, par nombre de transactions, par nombre d'exécutions [IEEE 610]

Un système de catégories (hiérarchiques) destiné à aider à la reproduction de défauts classifiés.

La méthode utilisée pour effectuer l'exécution des tests, soit manuellement, soit de façon automatisée.

Une procédure de dérivation et/ou sélection des cas de tests appliquée à une ou plusieurs catégories de défauts, avec un développement des tests à partir de ce qui est connu de catégorie de défaut spécifique.

Procédure documentée pour dériver et sélectionner des cas de tests élaborés à partir d'une analyse des spécifications des fonctionnalités d'un composant ou système sans référence à sa structure interne.

La moyenne arithmétique de temps pour qu'un système se rétablisse d'une défaillance quelconque. Cela comprend généralement les tests pour s'assurer que le défaut a été résolu.

La moyenne arithmétique du temps entre les défaillances d'un système. Le MTBF fait généralement partie d'un modèle de croissance de fiabilité qui suppose que le système défaillant est réparé immédiatement, dans le cadre d'un processus de réparation des défauts.

Processus consistant en toutes les activités du cycle de vie, statiques et dynamiques, concernant la planification et l'évaluation de produits logiciels et produits liés pour déterminer s'ils satisfont aux exigences, pour démontrer qu'ils sont aptes aux objectifs et détecter des anomalies.

Une approche du test dans laquelle des activités de test sont planifiées comme les sessions ininterrompues de conception de tests et d'exécution. Elle est souvent utilisée en conjonction avec le test exploratoire.

Test effectué de manière informelle ; sans préparation formelle des tests, pas d'utilisation de technique de conception de tests reconnue, il n'y a pas d'attente spécifique de résultats et le hasard guide les activités de test.

Technique de conception de tests boîte noire où les cas de tests sont sélectionnés, par exemple avec un algorithme de génération pseudo-aléatoire, pour correspondre à un profil opérationnel. Cette technique peut être utilisée pour tester les attributs non-fonctionnels tels la fiabilité et les performances.

Une approche du test selon laquelle les cas de tests sont conçus sur la base de l'architecture et/ou des conceptions détaillées d'un composant ou système (par exemple tests des interfaces entre composants ou systèmes)

Une approche des tests où les cas de tests sont conçus sur base des objectifs de tests et conditions de tests déduites des exigences, par exemple des tests qui exercent des fonctions spécifiques ou examinent des attributs non-fonctionnels tels la fiabilité ou l'utilisabilité.

Une approche de test visant à réduire le niveau des risques du produit et informer les parties prenantes de leurs statuts, et commençant dans les stades initiaux d'un projet. Elle comprend l'identification des risques du produit et l'utilisation de niveaux de risque pour guider le processus de test.

Une technique de test basée sur l'expérience de conception selon laquelle le testeur expérimenté utilise une liste de haut niveau d'éléments à noter, à vérifier, ou à se rappeler, ou un ensemble de règles ou de critères en fonction desquels un produit doit être vérifié.

(1) un standard à partir duquel des mesures ou des comparaisons peuvent être effectuées. (2) un test qui peut être utilisé pour comparer des composants ou systèmes entre eux ou à un standard comme en (1) ci-dessus [d'après IEEE 610]

Un type de tests d'intégration dans lequel les éléments logiciels, matériel ou les deux sont combinés en une fois en un composant ou un système complet, plutôt qu'effectué par étape. [selon IEEE 610]

Tests basés sur une analyse de la structure interne du composant ou système.

Tests, fonctionnels ou non-fonctionnels, sans référence aux structures internes du composant ou du système.

Test formel en rapport avec les besoins, exigences et processus métier, conduit pour déterminer si un système satisfait ou non aux critères d'acceptation et permettre aux utilisateurs, clients ou autres entités autorisées de déterminer l'acceptation ou non du système [d'après IEEE 610]

Test opérationnel en phase de test d'acceptation, généralement effectué dans un environnement opérationnel (simulé) par l' exploitation et/ou le personnel de l'administration des systèmes en se concentrant sur les aspects opérationnels, par exemple la reprise (après incident), le comportement des ressources et la conformité technique.

Tests d'acceptation effectués par des utilisateurs/clients sur leur site, pour déterminer si le composant ou système répond à leurs besoins et s'insère dans leur processus de gestion, incluant généralement des aspects matériels autant que logiciels.

Test qui détermine la facilité avec lesquels les utilisateurs avec handicaps peuvent utiliser un composant ou un système [Gerrard]

Une instance spéciale des tests fumigatoires (ou smoke tests) pour décider si le composant ou système est prêt pour des tests détaillés et plus complets. Un test d'admission est typiquement effectué au début d'une phase d'exécution de tests.

Processus de test visant à déterminer la pertinence d'un produit logiciel.

Test pour déterminer l'évolutivité du produit logiciel. Evolutivité : La capacité d'un produit logiciel à être étendu pour répondre à une charge accrue [d'après Gerrard]

Processus de test visant à déterminer l'exactitude d'un produit logiciel. Exactitude : capacité d'un produit logiciel à fournir le résultat ou les effets correct ou convenu avec le degré de précision nécessaire. [ISO 9126]

Le processus consistant à tester l'installabilité d'un produit logiciel.

Test des méthodes et processus utilisés pour accéder et gérer les (bases de) données, pour s'assurer que les méthodes d'accès, processus et règles de données fonctionnent comme attendu et que lors des accès à la base de données, les données ne sont pas corrompues ou inopinément effacées, mises à jour ou créées.

Un type de test d'intégration qui porte sur le test des interfaces entre les composants ou systèmes.

Le processus de tester pour déterminer l'interopérabilité d'un produit logiciel. Interopérabilité : capacité d'un produit logiciel à interagir avec un ou plusieurs composants ou systèmes spécifiés [d'après ISO 9126]

Tests pour déterminer le niveau par lequel le produit logiciel est compris, facile à apprendre ou à utiliser, et attrayant pour l'utilisateur quand il est utilisé dans des conditions spécifiées [d'après ISO 9126]

Le processus de test utilisé pour déterminer l'utilisation des ressources pour un produit logiciel.

Une approche incrémentale des tests d'intégration ou le niveau le plus bas des composants sont testés d'abord, et ensuite utilisés pour faciliter les tests des composants de plus haut niveau. Ce processus est répété jusqu'au test du composant le plus haut de la hiérarchie.

Un type de test concerné par la mesure du comportement d'un composant ou système avec une charge croissante, p.ex. nombre d'utilisateurs et/ou nombre de transactions en parallèle pour déterminer quelle charge peut être gérée par le composant ou système.

Une technique de conception de tests boîte noire selon laquelle les cas de tests sont conçus pour exécuter les combinaisons d'entrées en utilisant le concept de couverture des conditions et décisions.

Le processus de test pour déterminer la conformité d'un composant ou système (à ses exigences).

Test du logiciel utilisé pour convertir des données depuis des systèmes existants pour une utilisation dans les systèmes de remplacement.

Une technique de conception des tests boîte blanche où les cas de tests sont désignés pour exécuter les résultats et conditions et les résultats des décisions.

Une technique de conception de tests boîte blanche selon laquelle les cas de tests sont conçus pour exécuter des résultats de conditions simples qui affectent indépendamment les résultats d'une décision.

Tester la qualité de la documentation, p.ex. guide utilisateur ou guide d'installation.

Le processus de tests pour déterminer la fiabilité d'un produit logiciel. Fiabilité : la capacité d'un produit logiciel à effectuer les fonctions requises dans les conditions spécifiées pour des périodes de temps spécifiées, ou pour un nombre spécifique d'opérations. [ISO 9126]

Processus de test utilisé pour déterminer la maintenabilité d'un produit logiciel.

Test des modifications d'un système opérationnel ou de l'impact d'une modification d'environnement sur un système opérationnel.

Le processus de test pour déterminer les performances d'un produit logiciel. Voir test de rendement.

Le processus de tests pour déterminer la portabilité d'un produit logiciel. Portabilité : facilité avec laquelle un produit logiciel peut être transféré d'un environnement matériel ou logiciel vers un autre. [ISO 9126]

Test ayant pour but d'assurer que le composant ou le système peut opérer en conjonction avec des procédures nouvelles ou existantes pouvant être des procédures métiers ou opérationnelles.

Une technique de conception de tests boîte noire selon laquelle les cas de tests sont conçus pour exécuter les processus et procédures d'entreprise. [Tmap]

Le processus de tests pour déterminer la récupérabilité d'un produit logiciel.

Tests d'un programme préalablement testé, après une modification, pour s'assurer que des défauts n'ont pas été introduits ou découverts dans des parties non modifiées du logiciel, comme suites des modifications effectuées. Ces tests sont effectués quand le logiciel ou son environnement est modifié.

Test pour déterminer la robustesse d'un produit logiciel. Robustesse : le degré pour lequel un composant ou système peut fonctionner correctement en présence de données d'entrée invalides ou de conditions environnementales stressantes [IEEE 610]

Tests effectués pour déterminer la sécurité d'un produit logiciel. Sécurité : attributs d'un produit logiciel qui ont trait à sa capacité à empêcher un accès non autorisé, qu'il soit accidentel ou délibéré, aux programmes et aux données [ISO 9126]

Tests pour déterminer comment l'occurrence de deux activités ou plus sur un même intervalle de temps, obtenue en intercalant les activités ou en les exécutant simultanément, est gérée par le composant ou système [d'après IEEE 610]

Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l'accès mémoire ou serveurs [d'après IEEE 610].

Tests effectués pour déterminer la sûreté d'un produit logiciel. Sûreté : capacité d'un produit logiciel à atteindre des niveaux de risques acceptables concernant les dommages aux personnes, entreprises, logiciels, biens ou à l'environnement dans un contexte d'utilisation spécifié [ISO 9126]

Une technique de conception de tests boîte noire dans laquelle les cas de tests sont conçus sur base de la définition des domaines d'entrée et/ou de sortie.

Une version des tests d'intégration de composants où l'intégration progressive de composants suit l'implémentation de sous-ensembles d'exigences, par opposition à l'intégration des composants par niveau hiérarchique.

Une technique de conception de tests boîte noire dans laquelle les cas de tests sont conçus pour exécuter les transitions d'états valides et invalides.

Tests quand le système est soumis à de larges volumes de données.

Une technique de conception de tests boîte noire dans laquelle les cas de tests sont conçus pour exécuter des scénarios de cas d'utilisation. Cas d'utilisation : Une séquence de transactions dans un dialogue entre un acteur et un composant ou un système avec un résultat tangible. L'acteur peut être un utilisateur ou tout ce qui peut échanger des informations avec le système.

Une technique de conception des tests boîte blanche dans laquelle les cas de tests sont conçus pour exécuter des chemins.

Une technique de conception de test boîte blanche selon laquelle les cas de tests sont conçus pour exécuter les résultats de conditions.

Une technique de conception de tests boîte blanche selon laquelle les cas de tests sont conçus pour exécuter les résultats de décisions.

Test où deux ou plus variantes d'un composant ou d'un système sont exécutés avec les mêmes entrées, les sorties étant comparées, et analysées en cas de divergences. [IEEE 610]

Tests formels ou informels exécutés pendant la réalisation d'un composant ou système, généralement dans l'environnement de développement et par les développeurs. [d'après IEEE 610]

Une technique de conception de tests boîte blanche dans laquelle les cas de tests sont conçus pour exécuter les paires de définition et d'usage de variables.

Test statistique utilisant un modèle du système d'opération (tests de courte durée) et leur probabilité d'utilisation typique [Musa]

Test qui nécessite l'exécution du logiciel d'un composant ou système. (Note Hightest : s'oppose au test statique)

Deux testeurs travaillant ensemble pour trouver des défauts. Typiquement ils partagent un poste de travail et s'en échangent les contrôles pendant les tests.

Test des composants individuels indépendamment des autres composants, ces derniers étant simulés par des bouchons ou pilotes si besoin.

Tests utilisant des valeurs d'entrée qui devraient être rejetées par le composant ou système.

Un cadre en cinq niveaux pour l'amélioration des processus de tests, lié au Capability Maturity Model (CMM) qui décrit les éléments clés d'un processus de tests efficace.

Une structure étagée à cinq niveaux pour l'amélioration des processus de test, liée au Capability Maturity Model Integration (CMMI), qui décrit les éléments clés d'un processus de test effectif.

Tests effectués pour évaluer un composant ou système dans son environnement opérationnel [IEEE 610]

Une technique de conception de test boîte noire, par laquelle les cas de tests sont conçus pour exécuter toutes les combinaisons de paires possibles des paramètres d'entrée.

Une approche de test systématique pour tester toutes les combinaisons de paires de variables en utilisant des tableaux orthogonaux. Tester toutes les combinaisons de paires réduit sensiblement le nombre de toutes les combinaisons.

Une technique de conception des tests boîte noire dans laquelle les cas de tests sont conçus pour exécuter les combinaisons d'entrées et/ou de stimuli (causes) présentes dans une table de décision [Veenendaal]

Un cadre continu pour l'amélioration des processus de test qui décrit des éléments clé d'un processus de tests efficace, spécifiquement ciblé vers les tests système et les tests d'acceptation.

Test au moyen d'une sélection aléatoire d'une large gamme d'entrées ou en poussant au hasard des boutons, en ignorant comment un produit est utilisé.

Test d'un composant ou système au niveau spécification ou implémentation sans exécution de ce logiciel (par exemple : revues ou analyse statique du code).

Une technique de conception des tests selon laquelle un modèle de distribution statistique des entrées est utilisé pour construire des cas de tests représentatifs.

Une approche incrémentale des tests d'intégration où les composants en haut de la hiérarchie sont testés d'abord, avec les composants de niveau inférieur simulés par des bouchons. Les composants testés sont ensuite utilisés pour tester des composants de niveaux inférieurs. Le processus est répété jusqu'à ce que les composants de plus bas niveau ont été testés.

Un test où des utilisateurs réels sont impliqués pour évaluer l'utilisabilité d'un composant ou système.

Capacité d'un produit logiciel à permettre le test du logiciel modifié. [ISO 9126]

Un professionnel technique qui est impliqué dans les tests d'un composant ou système

Pratique de test pour un projet utilisant les méthodes agiles, telles la programmation extrême (XP), traitant le développement comme un client des tests et mettant l'accent sur le paradigme "Test first".

Une approche du test où les cas de tests sont conçus sur base des descriptions et/ou connaissances des processus métier.

Tests effectués pour montrer des défauts dans les interfaces et interactions de composants ou systèmes intégrés.

Tests de l'intégration des systèmes et progiciels ; tests des interfaces vers des organisations externes.

Le processus de test pour déterminer le rendement d'un produit logiciel.

Une technique de conception des tests boîte blanche dans laquelle les cas de tests sont conçus pour exécuter les branches.

Une technique de conception de tests boîte blanche selon laquelle les cas de tests sont conçus pour exécuter des combinaisons de conditions simples (au sein d'une seule instruction).

Le processus de test pour déterminer la fonctionnalité d'un produit logiciel.

Une technique de conception de tests boîte blanche dans laquelle les cas de tests sont conçus pour exécuter des instructions.

Une technique de script utilisant des fichiers de données qui contiennent outre les données de test et les résultats attendus, des mots clé liés à l'application à tester. Ces mots clé sont interprétés par des scripts de support spécifiques, appelés par le script de contrôle du test.

Une approche des tests selon laquelle la suite de tests comprend toutes les combinaisons de valeurs d'entrée et de pré-conditions. (Note Hightest : à part dans le cas d'un applicatif trivial, les tests exhaustifs sont réputés impossibles.)

Tests où le testeur contrôle activement la conception des tests en même temps que ces tests sont exécutés, et utilise l'information obtenue pendant les tests pour concevoir de nouveaux et meilleurs tests [d'après Bach]

Un sous-ensemble de tous les cas de tests conçus/prévus qui couvrent les fonctionnalités principales d'un composant ou système, pour s'assurer que les fonctions les plus cruciales d'un programme fonctionnent, sans se préoccuper des détails fins. Un build journalier et des tests fumigatoires font partie des meilleures pratique de l'industrie.

Tests où les composants ou systèmes sont intégrés et testés un ou plusieurs à la fois, jusqu'à ce que tous les composants ou systèmes soient intégrés et testés.

Tests dont l'objectif est de montrer qu'un composant ou système ne fonctionne pas. Les tests négatifs sont liés à l'attitude des testeurs plutôt qu'à une approche spécifique des tests ou une technique de conception des tests spécifique [d'après Beizer]

Test des attributs d'un composant ou système qui ne sont pas liés aux fonctionnalités (p.ex. fiabilité, rendement, utilisabilité, maintenabilité et portabilité).

Une technique de script qui sauvegarde les entrées et résultats attendus dans une table ou un tableur, de façon à ce qu'un seul script de contrôle puisse exécuter tous les tests de la table. Les tests déterminés par les données sont souvent utilisés pour assister l'utilisation de tests automatisés tels ceux de capture/rejeu. [Fewster et Graham]

Une technique de conception de tests boîte blanche dans laquelle les cas de test sont conçus pour exécuter des PLCS.

Le processus de test d'un système intégré pour vérifier qu'il réponde à des exigences spécifiques [Hetzel]

Artefact produit pendant le processus de test afin de planifier, concevoir et exécuter les tests, tel que la documentation, les scripts, les entrées, les résultats attendus, les procédures de mise en place et de nettoyage, les fichiers, bases de données, environnements et tout logiciel ou utilitaires supplémentaire utilisé dans les tests. [d'après Fewster & Graham]

La capacité du produit logiciel à maintenir le niveau spécifié de performances en cas de défaut (anomalie) ou de violation de ses interfaces spécifiées. [ISO 9126]

La capacité d'un système ou composant à continuer une opération normale malgré la présence de données d'entrée erronées [d'après IEEE 610]

Capacité à identifier les éléments liés d'une documentation et d'un logiciel, tel que les exigences et les tests y associés.

Le suivi des exigences pour un niveau de test au travers des couches de la documentation de tests (p.ex. plan de tests, spécifications de conception de test, spécification de cas de test et spécification de procédure de test).

Traçabilité des exigences au travers des couches de documentation de développement vers les composants.

Le chemin par lequel l'entrée originelle d'un processus (les données) peut être retracé dans le process, en prenant les sorties du process comme point de départ. Ceci facilite l'analyse des défauts et permet l'exécution d'un audit du processus [d'après TMap]

1) Un ensemble de risques regroupés par un ou plusieurs facteurs communs tels qu'un attribut de qualité, la cause, l'emplacement, ou l'effet potentiel du risque. 2) Un ensemble spécifique de types de risque du produit est liée au type des tests qui peuvent atténuer (contrôler) ce type de risque. Par exemple, le risque que les interactions avec l'utilisateur soient mal comprises peut être mitigé par des tests utilisabilité.

Un groupe d'activités de test dont l'objectif est de tester un composant ou système sur un ou plusieurs attributs liés entre eux. Un type de tests est focalisé sur un objectif de test spécifique p.ex. test de fiabilité, d'utilisabilité, de régression et peut couvrir un ou plusieurs niveaux de tests et une ou plusieurs phases de tests. [d'après TMap]