software testing terms complete glossary
Afin d'éviter les ambiguïtés dans les différents termes de test logiciel, je joins un glossaire des tests logiciels ici.
Tous les termes de test de logiciels sont inclus dans ce glossaire. Si vous pensez que vous connaissez la définition d'un terme mieux que ce qui est mentionné ici, vous pouvez utiliser ceci Formulaire de contact pour m'envoyer les définitions. Après examen, je les inclurai dans cette liste de glossaires.
Pour savoir avec les définitions de base des tests logiciels et de l'assurance qualité, c'est le meilleur glossaire compilé par Erik van Veenendaal . Pour chaque définition, il existe également une référence IEEE ou ISO mentionnée entre parenthèses.
À
critères d'acceptation: Les critères de sortie qu'un composant ou un système doit satisfaire pour êtreaccepté par un utilisateur, un client ou une autre entité autorisée. (IEEE 610)
test d'acceptation: Des tests formels concernant les besoins des utilisateurs, les exigences et les processus commerciaux sont effectués pour déterminer si un système satisfait ou non aux critères d'acceptation et pour permettre à l'utilisateur, aux clients ou à toute autre entité autorisée de déterminer s'il accepte ou non le système. (Après IEEE 610)
test d'accessibilité: Test pour déterminer la facilité avec laquelle les utilisateurs handicapés peuvent utiliser un composant ou un système. (Gerrard)
précision: La capacité du logiciel à fournir les résultats ou effets corrects ou convenus avec le degré de précision nécessaire. (ISO 9126) Voir également les tests de fonctionnalité.
résultat actuel: Le comportement produit / observé lorsqu'un composant ou un système est testé.
tests ad hoc: Tests effectués de manière informelle; aucune préparation de test formelle n'a lieu, aucune technique de conception de test reconnue n'est utilisée, il n'y a pas d'attentes pour les résultats et le caractère aléatoire guide l'activité d'exécution des tests.
adaptabilité: La capacité du logiciel à s'adapter à différents environnements spécifiés sans appliquer d'actions ou de moyens autres que ceux prévus à cet effet pour le logiciel considéré. (ISO 9126) Voir également les tests de portabilité.
tests agiles: Pratique de test pour un projet utilisant des méthodologies agiles, telles que la programmation extrême (XP), traitant le développement comme le client des tests et mettant l'accent sur le paradigme de conception du test d'abord.
test alpha: Tests opérationnels simulés ou réels par des utilisateurs / clients potentiels ou une équipe de test indépendante sur le site des développeurs, mais en dehors de l'organisation de développement. Le test alpha est souvent utilisé comme une forme de test d'acceptation interne.
analysabilité: La capacité du produit logiciel à être diagnostiqué pour les déficiences ou les causes de défaillances du logiciel, ou pour les pièces à modifier à identifier. (ISO 9126) Voir également les tests de maintenabilité.
anomalie: Toute condition qui s'écarte des attentes en fonction des spécifications des exigences, des documents de conception, des documents utilisateur, des normes, etc. ou de la perception ou de l'expérience de quelqu'un. Des anomalies peuvent être trouvées pendant, mais sans s'y limiter, l'examen, le test, l'analyse, la compilation ou l'utilisation de produits logiciels ou de la documentation applicable. (IEEE 1044) Voir aussi défaut, écart, erreur, défaut, échec, incident, problème.
attraction: La capacité du produit logiciel à être attrayant pour l'utilisateur. (ISO 9126)
Audit: Une évaluation indépendante des produits logiciels ou des processus pour vérifier la conformité aux normes, directives, spécifications et / ou procédures en fonction de critères objectifs, y compris des documents qui spécifient:
(1) la forme ou le contenu des produits à fabriquer
(2) le processus par lequel les produits doivent être fabriqués
(3) comment la conformité aux normes ou directives doit être mesurée. (IEEE 1028)
piste d'audit: Chemin par lequel l'entrée d'origine d'un processus (par exemple, des données) peut être retracée tout au long du processus, en prenant la sortie du processus comme point de départ. Cela facilite l'analyse des défauts et permet de réaliser un audit de processus. (Après TMap)
testware automatisé: Logiciel de test utilisé dans les tests automatisés, tels que les scripts d'outils.
disponibilité: Le degré auquel un composant ou un système est opérationnel et accessible en cas de besoin. Souvent exprimé en pourcentage. (IEEE 610)
B
tests dos à dos: Test dans lequel deux variantes ou plus d'un composant ou d'un système sont exécutées avec les mêmes entrées, les sorties comparées et analysées en cas de divergence. (IEEE 610)
ligne de base: Une spécification ou un produit logiciel qui a été formellement révisé ou convenu, qui sert ensuite de base à un développement ultérieur et qui ne peut être modifié que par un processus formel de contrôle des modifications. (Après IEEE 610)
bloc de base: Une séquence d'une ou plusieurs instructions exécutables consécutives ne contenant aucune branche.
ensemble de test de base: Un ensemble de cas de test dérivés de la structure interne ou de la spécification pour garantir que 100% d'un critère de couverture spécifié est atteint.
comportement: Réponse d'un composant ou d'un système à un ensemble de valeurs d'entrée et de conditions préalables.
test de référence: (1) Une norme par rapport à laquelle des mesures ou des comparaisons peuvent être effectuées. (2) Un test utilisé pour comparer des composants ou des systèmes entre eux ou avec une norme comme en (1). (Après IEEE 610)
logiciel sur mesure: Logiciel développé spécifiquement pour un ensemble d'utilisateurs ou de clients. Le contraire est un logiciel standard.
meilleur entrainement: Une méthode supérieure ou une pratique innovante qui contribue à l’amélioration des performances d’une organisation dans un contexte donné, généralement reconnue comme «meilleure» par d’autres organisations homologues.
Tests bêta: Test opérationnel par des utilisateurs / clients potentiels et / ou existants sur un site externe non impliqué autrement avec les développeurs, pour déterminer si un composant ou un système satisfait ou non les besoins de l'utilisateur / client et s'intègre dans les processus métier. Les tests bêta sont souvent utilisés comme une forme de test d'acceptation externe afin de recueillir les commentaires du marché.
tests big-bang: Un type de test d'intégration dans lequel des éléments logiciels, des éléments matériels ou les deux sont combinés en même temps dans un composant ou un système global, plutôt que par étapes. (Après IEEE 610) Voir aussi les tests d'intégration.
test de boîte noire: Test, fonctionnel ou non, sans référence à la structure interne du composant ou du système.
techniques de conception de test boîte noire: Procédure documentée pour dériver et sélectionner des cas de test sur la base d'une analyse de la spécification, fonctionnelle ou non, d'un composant ou d'un système sans référence à sa structure interne.
cas de test bloqué: Un cas de test qui ne peut pas être exécuté car les conditions préalables à son exécution ne sont pas remplies.
test ascendant: Une approche incrémentielle des tests d'intégration où les composants de niveau le plus bas sont d'abord testés, puis utilisés pour faciliter le test des composants de niveau supérieur. Ce processus est répété jusqu'à ce que le composant en haut de la hiérarchie soit testé. Voir aussi les tests d'intégration.
valeur limite: Une valeur d'entrée ou une valeur de sortie qui se trouve sur le bord d'une partition d'équivalence ou à la plus petite distance incrémentielle de chaque côté d'un bord, par exemple la valeur minimale ou maximale d'une plage.
analyse de la valeur limite: Une technique de conception de test boîte noire dans laquelle les cas de test sont conçus en fonction de valeurs limites.
couverture de la valeur limite: Le pourcentage de valeurs limites qui ont été exercées par une suite de tests.
branche: Un bloc de base qui peut être sélectionné pour l'exécution sur la base d'une construction de programme dans laquelle un ou plusieurs chemins de programme alternatifs sont disponibles, par ex. cas, sauter, aller à, sinon, sinon.
couverture de la succursale: Le pourcentage de branches qui ont été exercées par une suite de tests. Une couverture de succursale à 100% implique à la fois une couverture de décision à 100% et une couverture de déclaration à 100%.
test de branche: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des branches.
tests basés sur les processus métier: Une approche de test dans laquelle les cas de test sont conçus sur la base de descriptions et / ou de connaissances des processus métier.
C
Modèle de maturité des capacités (CMM): Un cadre par étapes à cinq niveaux qui décrit les éléments clés d'un processus logiciel efficace. Le modèle de maturité des capacités couvre les pratiques de planification, d'ingénierie et de gestion du développement et de la maintenance de logiciels. (CMM)
Intégration du modèle de maturité des capacités (CMMI): Un cadre qui décrit les éléments clés d'un processus de développement et de maintenance de produit efficace. L'intégration du modèle de maturité des capacités couvre les pratiques de planification, d'ingénierie et de gestion du développement et de la maintenance des produits. CMMI est le successeur désigné du CMM. (CMMI)
outil de capture / lecture: Un type d'outil d'exécution de test où les entrées sont enregistrées pendant les tests manuels afin de générer des scripts de test automatisés qui peuvent être exécutés plus tard (c'est-à-dire rejoués). Ces outils sont souvent utilisés pour prendre en charge les tests de régression automatisés.
CAS: Acronyme de génie logiciel assisté par ordinateur.
JETER: Acronyme de Test de logiciel assisté par ordinateur. Voir aussi l'automatisation des tests.
graphe de cause à effet: Une représentation graphique des entrées et / ou des stimuli (causes) avec leurs sorties associées (effets), qui peut être utilisée pour concevoir des cas de test.
graphique de cause à effet: Une technique de conception de test boîte noire dans laquelle les cas de test sont conçus à partir de graphiques de cause à effet. (BS 7925/2)
certification: Le processus de confirmation qu'un composant, un système ou une personne satisfait à ses exigences spécifiées, par ex. en passant un examen.
changeabilité: La capacité du produit logiciel à permettre la mise en œuvre de modifications spécifiées. (ISO 9126) Voir aussi maintenabilité.
méthode d'arbre de classification: Une technique de conception de test boîte noire dans laquelle les cas de test, décrits au moyen d'un arbre de classification, sont conçus pour exécuter des combinaisons de représentants de domaines d'entrée et / ou de sortie. (Grochtmann)
couverture de code: Une méthode d'analyse qui détermine quelles parties du logiciel ont été exécutées (couvertes) par la suite de tests et quelles parties n'ont pas été exécutées, par ex. couverture du relevé, couverture de décision ou couverture de l'état.
coexistence: La capacité du produit logiciel à coexister avec d'autres logiciels indépendants dans un environnement commun partageant des ressources communes. (ISO 9126) Voir les tests de portabilité.
complexité: La mesure dans laquelle un composant ou un système a une conception et / ou une structure interne difficile à comprendre, à maintenir et à vérifier. Voir aussi complexité cyclomatique.
conformité: La capacité du logiciel à adhérer aux normes, conventions ou réglementations des lois et prescriptions similaires. (ISO 9126)
tests de conformité : Processus de test pour déterminer la conformité d'un composant ou d'un système.
composant: Un élément logiciel minimal qui peut être testé isolément.
test d'intégration de composants: Tests effectués pour exposer les défauts des interfaces et l'interaction entre les composants intégrés.
spécification des composants: Une description de la fonction d'un composant en termes de ses valeurs de sortie pour des valeurs d'entrée spécifiées dans des conditions spécifiées et du comportement non fonctionnel requis (par exemple, l'utilisation des ressources).
test des composants: Le test de composants logiciels individuels. (Après IEEE 610)
condition composée: Deux ou plusieurs conditions simples jointes au moyen d'un opérateur logique (AND, OR ou XOR), par ex. «A> B ET C> 1000».
test de concurrence: Test pour déterminer comment l'occurrence de deux ou plusieurs activités dans le même intervalle de temps, obtenue soit par entrelacement des activités, soit par exécution simultanée, est gérée par le composant ou le système. (Après IEEE 610)
état: Une expression logique qui peut être évaluée comme True ou False, par exemple A> B. Voir également la condition de test.
couverture de l'état: Le pourcentage de résultats de condition qui ont été exercés par une suite de tests. Une couverture de condition à 100% nécessite que chaque condition de chaque déclaration de décision soit testée comme Vrai et Faux.
couverture de détermination des conditions: Le pourcentage de tous les résultats d'une condition unique qui affectent indépendamment un résultat de décision qui ont été exercés par une suite de cas de test. Une couverture de détermination de condition à 100% implique une couverture de condition de décision à 100%.
test de détermination des conditions: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des résultats de condition uniques qui affectent indépendamment un résultat de décision.
test de condition: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des résultats de condition.
résultat de la condition: L'évaluation d'une condition sur True ou False.
configuration: La composition d'un composant ou d'un système tel que défini par le nombre, la nature et les interconnexions de ses composants.
audit de configuration: La fonction pour vérifier le contenu des bibliothèques d'éléments de configuration, par ex. pour la conformité aux normes. (IEEE 610)
contrôle de configuration: Un élément de gestion de la configuration, consistant en l'évaluation, la coordination, l'approbation ou la désapprobation, et la mise en œuvre des modifications des éléments de configuration après l'établissement formel de leur identification de configuration. (IEEE
610)
identification de la configuration: Un élément de gestion de la configuration, consistant à sélectionner les éléments de configuration d'un système et à enregistrer leurs caractéristiques fonctionnelles et physiques dans la documentation technique. (IEEE 610)
élément de configuration: Agrégation de matériel, de logiciel ou des deux, qui est désignée pour la gestion de la configuration et traitée comme une seule entité dans le processus de gestion de la configuration. (IEEE 610)
gestion de la configuration: Une discipline appliquant une direction et une surveillance techniques et administratives pour: identifier et documenter les caractéristiques fonctionnelles et physiques d'un élément de configuration, contrôler les modifications de ces caractéristiques, enregistrer et signaler le traitement des modifications et l'état de mise en œuvre, et vérifier la conformité aux exigences spécifiées. (IEEE 610)
cohérence: Le degré d'uniformité, de normalisation et d'absence de contradiction entre les documents ou les parties d'un composant ou d'un système. (IEEE 610)
flux de contrôle: Une représentation abstraite de toutes les séquences d'événements (chemins) possibles dans l'exécution à travers un composant ou un système.
test de conversion: Test des logiciels utilisés pour convertir les données des systèmes existants pour les utiliser dans les systèmes de remplacement.
COTS: Acronyme de logiciel commercial sur étagère.
couverture: Le degré, exprimé en pourcentage, auquel un élément de couverture spécifié a été exercé par une suite de tests.
analyse de la couverture: Mesure de la couverture obtenue pour un élément de couverture spécifié pendant l'exécution du test en se référant à des critères prédéterminés pour déterminer si des tests supplémentaires sont nécessaires et, le cas échéant, quels cas de test sont nécessaires.
élément de couverture: Une entité ou une propriété utilisée comme base pour la couverture de test, par ex. partitions d'équivalence ou instructions de code.
outil de couverture: Un outil qui fournit des mesures objectives de quels éléments structurels, par ex. déclarations, les branches ont été exercées par la suite de tests.
complexité cyclomatique: Le nombre de chemins indépendants à travers un programme. La complexité cyclomatique est définie comme: L - N + 2P, où -L = le nombre d'arêtes / liens dans un graphe -N = le nombre de nœuds dans un graphe - P = le nombre de parties déconnectées du graphe (par exemple un graphe appelant et un sous-programme). (Après McCabe)
ré
définition des données: Une instruction exécutable dans laquelle une variable reçoit une valeur.
tests pilotés par les données: Une technique de script qui stocke l'entrée de test et les résultats attendus dans une table ou une feuille de calcul, de sorte qu'un seul script de contrôle puisse exécuter tous les tests de la table. Les tests pilotés par les données sont souvent utilisés pour prendre en charge l'application d'outils d'exécution de tests tels que les outils de capture / lecture. (Fewster et Graham) Voir aussi les tests basés sur les mots clés.
flux de données: Une représentation abstraite de la séquence et des changements possibles de l'état des objets de données, où l'état d'un objet est l'un des:création, utilisation ou destruction. (Beizer)
analyse des flux de données: Une forme d'analyse statique basée sur la définition et l'utilisation de variables.
couverture du flux de données: Le pourcentage de paires définition-utilisation qui ont été exercées par une suite de cas de test.
test de flux de données: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter la définition et utiliser des paires de variables.
débogage: Processus de recherche, d'analyse et de suppression des causes des pannes logicielles.
outil de débogage: Un outil utilisé par les programmeurs pour reproduire les échecs, enquêter sur l'état des programmes et trouver le défaut correspondant. Les débogueurs permettent aux programmeurs d'exécuter des programmes étape par étape, d'arrêter un programme à n'importe quelle instruction de programme et de définir et d'examiner les variables du programme.
décision: Un point de programme auquel le flux de contrôle a deux ou plusieurs itinéraires alternatifs. Un nœud avec deux liens ou plus vers des branches séparées.
couverture des conditions de décision: Le pourcentage de tous les résultats de condition et de décision qui ont été exercés par une suite de tests. Une couverture de condition de décision à 100% implique à la fois une couverture de condition à 100% et une couverture de décision à 100%.
test de condition de décision: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des résultats de condition et des résultats de décision.
passerelle par défaut non disponible Windows 10 2019
couverture de décision: Le pourcentage des résultats de décision qui ont été exercés par une suite de tests. Une couverture de décision à 100% implique à la fois une couverture de la succursale à 100% et une couverture des relevés à 100%.
table de décision: Un tableau montrant les combinaisons d'entrées et / ou de stimuli (causes) avec leurs sorties et / ou actions (effets) associées, qui peut être utilisé pour concevoir des cas de test.
test de table de décision: L'invention concerne des techniques de conception de test boîte noire dans lesquelles les cas de test sont conçus pour exécuter les combinaisons d'entrées et / ou de stimuli (causes) présentées dans une table de décision. (Veenendaal)
test de décision: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des résultats de décision.
résultat de la décision: Le résultat d'une décision (qui détermine donc les branches à prendre).
défaut: Un défaut dans un composant ou un système qui peut empêcher le composant ou le système de remplir sa fonction requise, par ex. une déclaration ou une définition de données incorrecte. Un défaut, s'il est rencontré pendant l'exécution, peut entraîner une défaillance du composant ou du système.
densité de défaut: Le nombre de défauts identifiés dans un composant ou un système divisé par la taille du composant ou du système (exprimé en termes de mesure standard, par exemple lignes de code, nombre de classes ou de points de fonction).
Pourcentage de détection des défauts (DDP): le nombre de défauts détectés par une phase de test, divisé par le nombre trouvé par cette phase de test et par tout autre moyen par la suite.
rapport de défaut: Un document signalant toute faille dans un composant ou un système qui peut empêcher le composant ou le système d'exécuter sa fonction requise. (Après IEEE 829)
gestion des défauts: Le processus de reconnaissance, d'enquête, de prise de mesures et d'élimination des défauts. Il s'agit d'enregistrer les défauts, de les classer et d'identifier l'impact. (Après IEEE 1044)
masquage des défauts: Une occurrence dans laquelle un défaut empêche la détection d'un autre. (Après IEEE 610)
paire définition-utilisation: L'association de la définition d'une variable avec l'utilisation de cette variable. Les utilisations variables incluent le calcul (par exemple, la multiplication) ou pour diriger l'exécution d'un chemin (utilisation de «prédicat»).
livrable: Tout produit (de travail) qui doit être livré à quelqu'un d'autre que l'auteur du produit (de travail).
tests basés sur la conception: Une approche de test dans laquelle les cas de test sont conçus sur la base de l'architecture et / ou de la conception détaillée d'un composant ou d'un système (par exemple, des tests d'interfaces entre des composants ou des systèmes).
vérification de bureau: Test du logiciel ou spécification par simulation manuelle de son exécution.
tests de développement: Tests formels ou informels menés pendant la mise en œuvre d'un composant ou d'un système, généralement dans l'environnement de développement par les développeurs. (Après IEEE 610)
tests de documentation: Tester la qualité de la documentation, par ex. guide de l'utilisateur ou guide d'installation.
domaine: L'ensemble à partir duquel des valeurs d'entrée et / ou de sortie valides peuvent être sélectionnées.
chauffeur: Un composant logiciel ou un outil de test qui remplace un composant qui prend en charge le contrôle et / ou l'appel d'un composant ou d'un système. (Après TMap)
analyse dynamique: Le processus d'évaluation du comportement, par ex. performances de la mémoire, utilisation du processeur, d'un système ou d'un composant pendant l'exécution. (Après IEEE 610)
comparaison dynamique: Comparaison des résultats réels et attendus, réalisée lors de l'exécution du logiciel, par exemple par un outil d'exécution de test.
test dynamique: Test qui implique l'exécution du logiciel d'un composant ou d'un système.
EST
Efficacité: La capacité du produit logiciel à fournir des performances appropriées, par rapport à la quantité de ressources utilisées dans les conditions indiquées. (ISO 9126)
test d'efficacité: Processus de test pour déterminer l'efficacité d'un produit logiciel.
test de comparaison élémentaire: L'invention concerne des techniques de conception de test boîte noire dans lesquelles les cas de test sont conçus pour exécuter des combinaisons d'entrées en utilisant le concept de couverture de détermination de condition. (TMap)
émulateur: Un appareil, un programme informatique ou un système qui accepte les mêmes entrées et produit les mêmes sorties qu'un système donné. (IEEE 610) Voir aussi simulateur.
critères d'admission: l'ensemble des conditions génériques et spécifiques pour permettre à un processus d'aller de l'avant avec une tâche définie, par ex. phase de test. Le but des critères d'entrée est d'empêcher le démarrage d'une tâche qui impliquerait plus d'efforts (gaspillés) par rapport à l'effort nécessaire pour supprimer les critères d'entrée échoués. (Gilb et Graham)
point d'accès: La première instruction exécutable dans un composant.
partition d'équivalence: Partie d'un domaine d'entrée ou de sortie pour laquelle le comportement d'un composant ou d'un système est supposé être le même, en fonction de la spécification.
couverture de partition d'équivalence: Le pourcentage de partitions d'équivalence qui ont été exercées par une suite de tests.
partitionnement d'équivalence: Une technique de conception de test boîte noire dans laquelle les cas de test sont conçus pour exécuter des représentants à partir de partitions d'équivalence. En principe, les cas de test sont conçus pour couvrir chaque partition au moins une fois.
Erreur: Une action humaine qui produit un résultat incorrect. (Après IEEE 610)
erreur de deviner: Une technique de conception de test dans laquelle l'expérience du testeur est utilisée pour anticiper les défauts qui pourraient être présents dans le composant ou le système testé à la suite d'erreurs commises, et pour concevoir des tests spécifiquement pour les exposer.
erreur d'amorçage: Processus consistant à ajouter intentionnellement des défauts connus à ceux déjà présents dans le composant ou le système dans le but de surveiller le taux de détection et d'élimination, et d'estimer le nombre de défauts restants. (IEEE 610)
tolérance d'erreur: La capacité d'un système ou d'un composant à continuer de fonctionner normalement malgré la présence d'entrées erronées. (Après IEEE 610).
gestion des exceptions: Comportement d'un composant ou d'un système en réponse à une entrée erronée, d'un utilisateur humain ou d'un autre composant ou système, ou à une défaillance interne.
instruction exécutable: Une instruction qui, une fois compilée, est traduite en code objet, et qui sera exécutée de manière procédurale lorsque le programme est en cours d'exécution et peut effectuer une action sur les données.
exercé: On dit qu'un élément de programme est exercé par un cas de test lorsque la valeur d'entrée provoque l'exécution de cet élément, tel qu'une instruction, une décision ou un autre élément structurel.
tests exhaustifs: Une approche de test dans laquelle la suite de tests comprend toutes les combinaisons de valeurs d'entrée et de conditions préalables.
Critère de sortie: L'ensemble des conditions génériques et spécifiques, convenues avec les parties prenantes, pour permettre à un processus d'être officiellement achevé. Le but des critères de sortie est d'empêcher qu'une tâche soit considérée comme terminée alors qu'il reste des parties de la tâche en suspens qui ne sont pas terminées. Les critères de sortie sont utilisés par les tests pour établir un rapport et pour planifier quand arrêter les tests. (Après Gilb et Graham)
point de sortie: La dernière instruction exécutable dans un composant.
résultat attendu: Le comportement prédit par la spécification, ou une autre source, du composant ou du système dans des conditions spécifiées.
tests exploratoires: Test où le testeur contrôle activement la conception des tests au fur et à mesure que ces tests sont effectués et utilise les informations obtenues lors des tests pour concevoir de nouveaux et meilleurs tests. (Bach)
F
échouer: Un test est réputé échouer si son résultat réel ne correspond pas à son résultat attendu.
échec: Écart réel du composant ou du système par rapport à sa livraison, son service ou son résultat attendu. (Après Fenton)
mode de défaillance: La manifestation physique ou fonctionnelle d'un échec. Par exemple, un système en mode panne peut être caractérisé par un fonctionnement lent, des sorties incorrectes ou une fin complète d'exécution.
Analyse des modes de défaillance et des effets (FMEA): Une approche systématique de l'identification et de l'analyse des risques pour identifier les modes de défaillance possibles et tenter de prévenir leur survenue.
taux d'échec: Le rapport du nombre de pannes d'une catégorie donnée à une unité de mesure donnée, par ex. échecs par unité de temps, échecs par nombre de transactions, échecs par nombre d'exécutions d'ordinateurs. (IEEE 610)
tolérance aux pannes: La capacité du produit logiciel à maintenir un niveau de performance spécifié en cas de défauts logiciels (défauts) ou de violation de son interface spécifiée. (ISO 9126) Voir aussi fiabilité.
analyse de l'arbre de défaillances: Une méthode utilisée pour analyser les causes des défauts (défauts).
chemin réalisable: Un chemin pour lequel un ensemble de valeurs d'entrée et de conditions préalables existe, ce qui entraîne son exécution.
fonctionnalité: Un attribut d'un composant ou d'un système spécifié ou implicite dans la documentation des exigences (par exemple, la fiabilité, l'utilisabilité ou les contraintes de conception). (Après IEEE 1008)
machine à états finis: Un modèle de calcul constitué d'un nombre fini d'états et de transitions entre ces états, éventuellement avec des actions d'accompagnement. (IEEE 610)
examen formel: Un examen caractérisé par des procédures et des exigences documentées, par ex. inspection.
base de test gelée: Un document de base de test qui ne peut être modifié que par un processus formel de contrôle des modifications. Voir aussi baseline.
Analyse des points de fonction (FPA): Méthode visant à mesurer la taille de la fonctionnalité d'un système d'information. La mesure est indépendante de la technologie. Cette mesure peut être utilisée comme base pour la mesure de la productivité, l'estimation des ressources nécessaires et le contrôle du projet.
intégration fonctionnelle: Une approche d'intégration qui combine les composants ou les systèmes dans le but de faire fonctionner rapidement une fonctionnalité de base. Voir aussi les tests d'intégration.
exigence fonctionnelle: Une exigence qui spécifie une fonction qu'un composant ou un système doit exécuter. (IEEE 610)
technique de conception des tests fonctionnels: Procédure documentée pour dériver et sélectionner des cas de test basés sur une analyse de la spécification de la fonctionnalité d'un composant ou d'un système sans référence à sa structure interne. Voir aussi technique de conception de test de boîte noire.
test fonctionel: Test basé sur une analyse de la spécification de la fonctionnalité d'un composant ou d'un système. Voir aussi les tests de la boîte noire.
Fonctionnalité: La capacité du produit logiciel à fournir des fonctions qui répondent aux besoins énoncés et implicites lorsque le logiciel est utilisé dans des conditions spécifiées. (ISO 9126)
test de fonctionnalité: Processus de test pour déterminer la fonctionnalité d'un produit logiciel.
g
essai de boîte en verre: Voir les tests en boîte blanche.
H
évaluation heuristique: Une technique de test d'utilisabilité statique pour déterminer la conformité d'une interface utilisateur avec des principes d'utilisabilité reconnus (ce que l'on appelle «l'heuristique»).
cas de test de haut niveau: Un cas de test sans valeurs concrètes (au niveau de l'implémentation) pour les données d'entrée et les résultats attendus.
traçabilité horizontale: Le traçage des exigences pour un niveau de test à travers les couches de la documentation de test (par exemple, plan de test, spécification de conception de test, spécification de cas de test et spécification de procédure de test).
je
analyse d'impact: L'évaluation des changements apportés aux couches de la documentation de développement, de la documentation de test et des composants, afin de mettre en œuvre un changement donné aux exigences spécifiées.
modèle de développement incrémental: Un cycle de vie de développement où un projet est divisé en une série d'incréments, dont chacun fournit une partie des fonctionnalités dans les exigences globales du projet. Les exigences sont hiérarchisées et livrées par ordre de priorité dans l'incrément approprié. Dans certaines versions (mais pas toutes) de ce modèle de cycle de vie, chaque sous-projet suit un «mini modèle en V» avec ses propres phases de conception, de codage et de test.
test incrémental: Test 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.
incident: Tout événement survenant pendant le test qui nécessite une enquête. (Après IEEE 1008)
la gestion des incidents: Le processus de reconnaissance, d'enquête, d'action et d'élimination des incidents. Il s'agit d'enregistrer les incidents, de les classer et d'identifier l'impact. (Après IEEE 1044)
outil de gestion des incidents: Un outil qui facilite l'enregistrement et le suivi de l'état des incidents détectés lors des tests. Ils disposent souvent d'installations orientées flux de travail pour suivre et contrôler l'attribution, la correction et le nouveau test des incidents et fournir des fonctions de reporting.
rapport d'incident: Un document rapportant tout événement qui se produit pendant le test et qui nécessite une enquête. (Après IEEE 829)
indépendance: Séparation des responsabilités, qui encourage la réalisation de tests objectifs. (Après DO-178b)
chemin infaisable: Un chemin qui ne peut être exercé par aucun ensemble de valeurs d'entrée possibles.
examen informel: Un examen non basé sur une procédure formelle (documentée).
saisir: Une variable (qu'elle soit stockée dans un composant ou à l'extérieur) qui est lue par un composant.
domaine d'entrée: L'ensemble à partir duquel des valeurs d'entrée valides peuvent être sélectionnées. Voir aussi domaine.
valeur d'entrée: Une instance d'une entrée. Voir aussi entrée.
inspection: Un type d'examen qui repose sur un examen visuel des documents pour détecter les défauts, par ex. violations des normes de développement et non-conformité à la documentation de niveau supérieur. La technique de revue la plus formelle et donc toujours basée sur une procédure documentée. (Après IEEE 610, IEEE 1028)
installabilité: Capacité du logiciel à être installé dans un environnement spécifié (ISO 9126). Voir aussi la portabilité.
test d’installabilité: Processus de test de l'installabilité d'un produit logiciel. Voir aussi les tests de portabilité.
guide d'installation: Des instructions fournies sur n'importe quel support approprié, qui guident l'installateur tout au long du processus d'installation. Il peut s'agir d'un guide manuel, d'une procédure pas à pas, d'un assistant d'installation ou de toute autre description de processus similaire.
Assistant d'installation: Logiciel fourni sur tout support approprié, qui guide l'installateur tout au long du processus d'installation. Il exécute normalement le processus d'installation, fournit des commentaires sur les résultats de l'installation et demande des options.
instrumentation: L'insertion de code supplémentaire dans le programme afin de collecter des informations sur le comportement du programme pendant l'exécution.
instruments: Un outil logiciel utilisé pour réaliser l'instrumentation.
test d'admission: Une instance spéciale d'un test de fumée pour décider si le composant ou le système est prêt pour des tests détaillés et supplémentaires. Un test d'admission est généralement effectué au début de la phase d'exécution du test.
l'intégration: Processus de combinaison de composants ou de systèmes dans des assemblages plus grands.
test d'intégration: Tests effectués pour exposer les défauts des interfaces et des interactions entre les composants ou systèmes intégrés. Voir également les tests d'intégration de composants, les tests d'intégration système.
test d'interface: Un type de test d'intégration qui consiste à tester les interfaces entre les composants ou les systèmes.
interopérabilité: Capacité du produit logiciel à interagir avec un ou plusieurs composants ou systèmes spécifiés. (Après ISO 9126) Voir aussi fonctionnalité.
tests d'interopérabilité: Processus de test pour déterminer l'interopérabilité d'un produit logiciel. Voir également les tests de fonctionnalité.
test invalide: Test à l'aide de valeurs d'entrée qui doivent être rejetées par le composant ou le système. Voir aussi tolérance d'erreur.
test d'isolement: Test des composants individuels indépendamment des composants environnants, les composants environnants étant simulés par des stubs et des pilotes, si nécessaire.
À
test basé sur les mots clés: Une technique de script qui utilise des fichiers de données pour contenir non seulement des données de test et des résultats attendus, mais également des mots-clés liés à l'application testée. Les mots-clés sont interprétés par des scripts de prise en charge spéciaux qui sont appelés par le script de contrôle pour le test. Voir aussi les tests pilotés par les données.
L
LCSAJ: Une séquence de code linéaire et un saut, composé des trois éléments suivants (conventionnellement identifiés par des numéros de ligne dans une liste de code source): le début de la séquence linéaire d'instructions exécutables, la fin de la séquence linéaire et la ligne cible vers laquelle le contrôle le flux est transféré à la fin de la séquence linéaire.
Couverture LCSAJ: Le pourcentage de LCSAJ d'un composant qui ont été exercés par une suite de tests. Une couverture LCSAJ à 100% implique une couverture décisionnelle à 100%.
Test LCSAJ: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des LCSAJ.
apprentissage: La capacité du produit logiciel à permettre à l'utilisateur d'apprendre son application. (ISO 9126) Voir également utilisabilité.
test de chargement: Un type d'essai concernant la mesure du comportement d'un composant ou d'un système avec une charge croissante, par ex. nombre d'utilisateurs parallèles et / ou nombre de transactions pour déterminer quelle charge peut être gérée par le composant ou le système.
cas de test de bas niveau: Un cas de test avec des valeurs concrètes (au niveau de la mise en œuvre) pour les données d'entrée et les résultats attendus.
M
maintenance: Modification d'un produit logiciel après la livraison pour corriger les défauts, améliorer les performances ou d'autres attributs, ou adapter le produit à un environnement modifié. (IEEE 1219)
test de maintenance: Tester les modifications d'un système opérationnel ou l'impact d'un environnement modifié sur un système opérationnel.
maintenabilité: La facilité avec laquelle un logiciel peut être modifié pour corriger des défauts, modifié pour répondre à de nouvelles exigences, modifié pour faciliter la maintenance future ou adapté à un environnement modifié. (ISO 9126)
test de maintenabilité: Processus de test pour déterminer la maintenabilité d'un produit logiciel.
examen de la gestion: Une évaluation systématique du processus d'acquisition, de fourniture, de développement, d'exploitation ou de maintenance de logiciels, effectuée par ou pour le compte de la direction, qui surveille les progrès, détermine l'état des plans et des calendriers, confirme les exigences et l'attribution du système héritier, ou évalue l'efficacité des approches de gestion pour atteindre l'aptitude à l'emploi. (Après IEEE 610, IEEE 1028)
maturité: (1) La capacité d'une organisation en ce qui concerne l'efficacité et l'efficience de ses processus et pratiques de travail. Voir également Modèle de maturité des capacités, Modèle de maturité des tests. (2) La capacité du logiciel à éviter une défaillance due à des défauts du logiciel. (ISO 9126) Voir aussi fiabilité.
mesure: Numéro ou catégorie attribué à un attribut d'une entité en effectuant une mesure (ISO 14598).
la mesure: Processus d'attribution d'un numéro ou d'une catégorie à une entité pour décrire un attribut de cette entité. (ISO 14598)
échelle de mesure: Une échelle qui limite le type d'analyse de données qui peut y être effectuée. (ISO 14598)
fuite de mémoire: Un défaut dans la logique d'allocation de stockage dynamique d'un programme qui empêche la récupération de la mémoire une fois qu'il a fini de l'utiliser, entraînant finalement l'échec du programme en raison d'un manque de mémoire.
métrique: Une échelle de mesure et la méthode utilisée pour la mesure. (ISO 14598)
Étape importante: Un moment dans le temps d'un projet auquel les livrables définis (intermédiaires) etles résultats doivent être prêts.
modérateur: Le chef et la personne principale responsable d'une inspection ou d'un autre processus d'examen.
surveiller: Un outil logiciel ou un dispositif matériel qui s'exécute en même temps que le composant ou le système testé et supervise, enregistre et / ou analyse le comportement du composant ou du système. (Après IEEE 610)
couverture de conditions multiples: Le pourcentage de combinaisons de toutes les conditions uniquesrésultats dans une instruction qui ont été exercés par une suite de tests. 100% multiplela couverture des conditions implique une couverture de détermination des conditions à 100%.
test de conditions multiples: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des combinaisons de résultats de condition unique (dans une instruction).
analyse de mutation: Une méthode pour déterminer l'exhaustivité de la suite de tests en mesurant la mesure dans laquelle une suite de tests peut distinguer le programme de légères variantes (mutants) du programme.
N
Couverture N-switch: Le pourcentage de séquences de transitions N + 1 qui ont été exercées par une suite de tests. (Bouffe)
Test du commutateur N: Une forme de test de transition d'état dans lequel les cas de test sont conçus pour exécuter toutes les séquences valides de N + 1 transitions. (Chow) Voir aussi les tests de transition d'état.
test négatif: Tests visant à montrer qu'un composant ou un système ne fonctionne pas. Les tests négatifs sont liés à l’attitude des testeurs plutôt qu’à une approche de test spécifique ou à une technique de conception de test. (Après Beizer).
non-conformité: Non-respect d'une exigence spécifiée. (ISO 9000)
exigence non fonctionnelle: Une exigence qui ne concerne pas la fonctionnalité, mais des attributs tels que la fiabilité, l'efficacité, la facilité d'utilisation, la maintenabilité et la portabilité.
tests non fonctionnels: Tester les attributs d'un composant ou d'un système qui ne sont pas liés à la fonctionnalité, par ex. fiabilité, efficacité, convivialité, maintenabilité et portabilité.
techniques de conception de tests non fonctionnels: Méthodes utilisées pour concevoir ou sélectionner des tests pour les tests non fonctionnels.
OU
logiciel standard: Un logiciel développé pour le marché général, c'est-à-dire pour un grand nombre de clients, et qui est livré à de nombreux clients dans un format identique.
opérabilité: La capacité du produit logiciel à permettre à l'utilisateur de le faire fonctionner et de le contrôler. (ISO 9126) Voir également utilisabilité.
environnement opérationnel: Produits matériels et logiciels installés sur les sites des utilisateurs ou des clients où le composant ou le système testé sera utilisé. Le logiciel peut inclure des systèmes d'exploitation, des systèmes de gestion de base de données et d'autres applications.
test du profil opérationnel: Tests statistiques utilisant un modèle de fonctionnement du système (tâches de courte durée) et leur probabilité d'utilisation typique. (Musa)
tests opérationnels: Tests réalisés pour évaluer un composant ou un système dans son environnement opérationnel. (IEEE 610)
production: Une variable (qu'elle soit stockée dans un composant ou à l'extérieur) qui est écrite par un composant.
domaine de sortie: L'ensemble à partir duquel des valeurs de sortie valides peuvent être sélectionnées. Voir aussi domaine.
valeur de sortie: Une instance d'une sortie. Voir aussi sortie.
P
programmation en binôme: Une approche de développement logiciel dans laquelle les lignes de code (production et / ou test) d'un composant sont écrites par deux programmeurs assis sur un seul ordinateur. Cela signifie implicitement que des revues de code en temps réel sont effectuées.
test de paire: Deux testeurs travaillent ensemble pour trouver des défauts. En règle générale, ils partagent un ordinateur et en échangent le contrôle pendant les tests.
Passe: Un test est considéré comme réussi si son résultat réel correspond à son résultat attendu.
critères de réussite / échec: Règles de décision utilisées pour déterminer si un élément de test (fonction) ou une fonctionnalité a réussi ou échoué un test. (IEEE 829)
chemin: Une séquence d'événements, par ex. instructions exécutables, d'un composant ou d'un système d'un point d'entrée à un point de sortie.
couverture de chemin: Le pourcentage de chemins qui ont été exercés par une suite de tests. Une couverture de chemin à 100% implique une couverture LCSAJ à 100%.
sensibilisation de chemin: Choisir un ensemble de valeurs d'entrée pour forcer l'exécution d'un chemin donné.
test de chemin: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des chemins.
performance: Le degré auquel un système ou un composant accomplit ses fonctions désignées dans des contraintes données concernant le temps de traitement et le débit. (Après IEEE 610) Voir efficacité.
indicateur de performance: Une métrique de haut niveau d'efficacité et / ou d'efficience utilisée pour guider et contrôler le développement progressif, par ex. Pourcentage de détection des défauts (DDP) pour les tests. (CMMI)
Test de performance: Processus de test pour déterminer les performances d'un produit logiciel. Voir les tests d'efficacité.
outil de test de performance: Un outil pour prendre en charge les tests de performance et qui a généralement deux fonctionnalités principales: la génération de charge et la mesure des transactions de test. La génération de charge peut simuler soit plusieurs utilisateurs, soit des volumes élevés de données d'entrée. Pendant l'exécution, les mesures du temps de réponse sont prises à partir des transactions sélectionnées et celles-ci sont enregistrées. Les outils de test de performance fournissent normalement des rapports basés sur des journaux de test et des graphiques de charge par rapport aux temps de réponse.
datastage interview questions et réponses pdf
plan de test de phase: Un plan de test qui aborde généralement un niveau de test.
portabilité: La facilité avec laquelle le produit logiciel peut être transféré d'un environnement matériel ou logiciel à un autre. (ISO 9126)
test de portabilité: Processus de test pour déterminer la portabilité d'un produit logiciel.
postcondition: Conditions environnementales et d'état qui doivent être remplies après l'exécution d'un essai ou d'une procédure d'essai.
comparaison post-exécution: Comparaison des résultats réels et attendus, effectuée après la fin de l'exécution du logiciel.
condition préalable: Conditions environnementales et d'état qui doivent être remplies avant que le composant ou le système puisse être exécuté avec un test ou une procédure de test particulier.
Priorité: Le niveau d'importance (commerciale) attribué à un élément, par ex. défaut.
test du cycle de processus: Une technique de conception de test boîte noire dans laquelle les cas de test sont conçus pour exécuter des procédures et des processus métier. (TMap)
traiter: Un ensemble d'activités interdépendantes, qui transforment les intrants en extrants. (ISO 12207)
projet: Un projet est un ensemble unique d'activités coordonnées et contrôlées avec des dates de début et de fin, un objectif conforme à des exigences spécifiques, y compris les contraintes de temps, de coût et de ressources. (ISO 9000)
plan de test du projet: Un plan de test qui aborde généralement plusieurs niveaux de test.
pseudo-aléatoire: Une série qui semble aléatoire mais qui est en fait générée selon une séquence préétablie.
Q
qualité: La mesure dans laquelle un composant, un système ou un processus répond aux exigences spécifiées et / ou aux besoins et attentes des utilisateurs / clients. (Après IEEE 610)
assurance qualité: Une partie de la gestion de la qualité s'est concentrée sur la garantie que les exigences de qualité seront satisfaites. (ISO 9000)
attribut de qualité: Une caractéristique ou une caractéristique qui affecte la qualité d'un élément. (IEEE 610)
gestion de la qualité: Coordination des activités pour diriger et contrôler une organisation en matière de qualité. La direction et le contrôle en matière de qualité comprennent généralement l'établissement de la politique de qualité et des objectifs de qualité, la planification de la qualité, le contrôle de la qualité, l'assurance de la qualité et l'amélioration de la qualité. (ISO 9000)
R
tests aléatoires: Une technique de conception de test boîte noire où les cas de test sont sélectionnés, éventuellement en utilisant un algorithme de génération pseudo-aléatoire, pour correspondre à un profil opérationnel. Cette technique peut être utilisée pour tester des attributs non fonctionnels tels que la fiabilité et les performances.
récupérabilité: La capacité du produit logiciel à rétablir un niveau de performance spécifié et à récupérer les données directement affectées en cas de panne. (ISO 9126) Voir aussi fiabilité.
test de récupérabilité: Processus de test pour déterminer la récupérabilité d'un produit logiciel. Voir aussi les tests de fiabilité.
les tests de régression: Test d'un programme précédemment testé après modification pour s'assurer que des défauts n'ont pas été introduits ou découverts dans des zones inchangées du logiciel, à la suite des modifications apportées. Elle est effectuée lorsque le logiciel ou son environnement est modifié.
note de version: Un document identifiant les éléments de test, leur configuration, leur état actuel et d'autres informations de livraison fournies par le développement aux tests, et éventuellement à d'autres parties prenantes, au début d'une phase d'exécution de test. (Après IEEE 829)
fiabilité: La capacité du logiciel à exécuter ses fonctions requises dans des conditions déterminées pendant une période de temps spécifiée ou pour un nombre spécifié d'opérations. (ISO 9126)
test de fiabilité: Processus de test pour déterminer la fiabilité d'un produit logiciel.
remplaçabilité: La capacité du produit logiciel à être utilisé à la place d'un autre produit logiciel spécifié dans le même but dans le même environnement. (ISO 9126) Voir aussi portabilité.
exigence: Une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif qui doit être atteint ou possédé par un système ou un composant de système pour satisfaire un contrat, une norme, une spécification ou tout autre document formellement imposé. (Après IEEE 610)
tests basés sur les exigences: Une approche de test dans laquelle les cas de test sont conçus en fonction des objectifs de test et des conditions de test dérivées des exigences, par ex. des tests qui exercent des fonctions spécifiques ou sondent des attributs non fonctionnels tels que la fiabilité ou l'utilisabilité.
outil de gestion des exigences: Un outil qui prend en charge l'enregistrement des exigences, des attributs des exigences (par exemple, priorité, responsable des connaissances) et des annotations, et facilite la traçabilité à travers des couches d'exigences et de gestion des changements d'exigences. Certains outils de gestion des exigences fournissent également des fonctionnalités d'analyse statique, telles que la vérification de cohérence et les violations de règles d'exigences prédéfinies.
phase des exigences: Période du cycle de vie du logiciel au cours de laquelle les exigences d'un produit logiciel sont définies et documentées. (IEEE 610)
utilisation des ressources: La capacité du logiciel à utiliser des quantités et des types de ressources appropriés, par exemple les quantités de mémoire principale et secondaire utilisées par le programme et les tailles des fichiers temporaires ou de débordement requis, lorsque le logiciel exécute sa fonction dans des conditions définies. (Après ISO 9126) Voir aussi efficacité.
test d'utilisation des ressources: Processus de test pour déterminer l'utilisation des ressources d'un produit logiciel.
résultat: La conséquence / le résultat de l'exécution d'un test. Il comprend les sorties vers les écrans, les modifications des données, les rapports et les messages de communication envoyés. Voir aussi résultat réel, résultat attendu.
critères de reprise: Les activités de test qui doivent être répétées lorsque le test est redémarré après une suspension. (Après IEEE 829)
nouveau test: Test qui exécute des cas de test qui ont échoué la dernière fois qu'ils ont été exécutés, afin de vérifier le succès des actions correctives.
la revue: Une évaluation de l'état d'un produit ou d'un projet pour déterminer les écarts par rapport aux résultats prévus et recommander des améliorations. Les exemples incluent la revue de direction, la revue informelle, la revue technique, l'inspection et la visite virtuelle. (Après IEEE 1028)
critique: La personne impliquée dans la revue qui doit identifier et décrire les anomalies dans le produit ou projet sous revue. Les réviseurs peuvent être choisis pour représenter différents points de vue et rôles dans le processus de révision.
risque: Un facteur qui pourrait entraîner des conséquences négatives futures; généralement exprimée en impact et en probabilité.
analyse de risque: Le processus d'évaluation des risques identifiés pour estimer leur impact et leur probabilité d'occurrence (probabilité).
tests fondés sur les risques: Tests orientés vers l'exploration et la fourniture d'informations sur les risques produits. (Après Gerrard)
contrôle des risques: Processus par lequel les décisions sont prises et les mesures de protection mises en œuvre pour réduire les risques ou les maintenir à des niveaux spécifiés.
identification des risques: Le processus d'identification des risques à l'aide de techniques telles que le brainstorming, les listes de contrôle et l'historique des échecs.
gestion des risques: Application systématique de procédures et de pratiques aux tâches d'identification, d'analyse, de hiérarchisation et de contrôle des risques.
robustesse: Le degré auquel un composant ou un système peut fonctionner correctement en présence d'entrées invalides ou de conditions environnementales stressantes. (IEEE 610) Voir aussi tolérance d'erreur, tolérance aux pannes.
cause première: Un facteur sous-jacent qui a causé une non-conformité et qui devrait éventuellement être éliminé de façon permanente grâce à l'amélioration des processus
S
sécurité: La capacité du logiciel à atteindre des niveaux acceptables de risque de préjudice aux personnes, aux entreprises, aux logiciels, aux biens ou à l'environnement dans un contexte d'utilisation spécifié. (ISO 9126)
test de sécurité: Processus de test pour déterminer la sécurité d'un produit logiciel.
évolutivité: La capacité du logiciel à être mis à niveau pour s'adapter à des charges accrues. (Après Gerrard)
test d'évolutivité: Test pour déterminer l'évolutivité du produit logiciel.
scribe: La personne qui doit enregistrer chaque défaut mentionné et toute suggestion d'amélioration lors d'une réunion de révision, sur un formulaire d'enregistrement. Le scribe doit s'assurer que le formulaire d'enregistrement est lisible et compréhensible.
langage de script: Un langage de programmation dans lequel sont écrits des scripts de test exécutables, utilisé par un outil d'exécution de test (par exemple un outil de capture / relecture).
Sécurité: Attributs des produits logiciels qui influent sur sa capacité à empêcher l'accès non autorisé, accidentel ou délibéré, aux programmes et aux données. (ISO 9126)
test de sécurité: Test pour déterminer la sécurité du produit logiciel.
gravité: Le degré d'impact d'un défaut sur le développement ou le fonctionnement d'un composant ou d'un système. (Après IEEE 610)
simulation: Représentation de caractéristiques comportementales sélectionnées d'un système physique ou abstrait par un autre système. (ISO 2382/1)
simulateur: Dispositif, programme informatique ou système utilisé pendant les tests, qui se comporte ou fonctionne comme un système donné lorsqu'il est pourvu d'un ensemble d'entrées contrôlées. (Après IEEE 610, DO178b) Voir aussi émulateur.
test de fumée: Un sous-ensemble de tous les cas de test définis / planifiés qui couvrent la fonctionnalité principale d'un composant ou d'un système, pour vérifier que les fonctions les plus cruciales d'un programme fonctionnent, mais sans se soucier des détails plus fins. Un test quotidien de construction et de fumée fait partie des meilleures pratiques de l'industrie. Voir aussi test d'admission.
qualité du logiciel: L'ensemble des fonctionnalités et des caractéristiques d'un produit logiciel qui portent sur sa capacité à satisfaire des besoins déclarés ou implicites. (Après ISO 9126)
spécification: Un document qui spécifie, idéalement de manière complète, précise et vérifiable, les exigences, la conception, le comportement ou d'autres caractéristiques d'un composant ou d'un système et, souvent, les procédures permettant de déterminer si ces dispositions ont été satisfaites. (Après IEEE 610)
technique de conception de test basée sur les spécifications: Voir la technique de conception de test de boîte noire.
entrée spécifiée: Une entrée pour laquelle la spécification prédit un résultat.
stabilité: La capacité du produit logiciel à éviter les effets inattendus des modifications du logiciel. (ISO 9126) Voir aussi maintenabilité.
diagramme d'état: Un diagramme qui décrit les états qu'un composant ou un système peut assumer, et montre les événements ou les circonstances qui provoquent et / ou résultent d'un changement d'un état à un autre. (IEEE 610)
table d'état: Une grille montrant les transitions résultantes pour chaque état combinées à chaque événement possible, montrant les transitions valides et non valides.
transition d'état: Une transition entre deux états d'un composant ou d'un système.
test de transition d'état: Une technique de conception de test boîte noire dans laquelle les cas de test sont conçus pour exécuter des transitions d'état valides et non valides. Voir également les tests N-switch.
déclaration: Une entité dans un langage de programmation, qui est généralement la plus petite unité d'exécution indivisible.
couverture du relevé: Le pourcentage d'instructions exécutables qui ont été exercées par une suite de tests.
test de déclaration: Une technique de conception de test en boîte blanche dans laquelle les cas de test sont conçus pour exécuter des instructions.
analyse statique: Analyse des artefacts logiciels, par ex. exigences ou code, exécutés sans exécution de ces artefacts logiciels.
analyseur statique: Un outil qui effectue une analyse statique.
analyse de code statique: Analyse du code source du programme effectuée sans exécution de ce logiciel.
analyseur de code statique: Un outil qui effectue une analyse de code statique. L'outil vérifie le code source, pour certaines propriétés telles que la conformité aux normes de codage, les mesures de qualité ou les anomalies de flux de données.
cadre de test de bout en bout de rapporteur pour les applications angularjs
test statique: Test d'un composant ou d'un système au niveau des spécifications ou de l'implémentation sans exécution de ce logiciel, par ex. revues ou analyse de code statique.
tests statistiques: Une technique de conception de test dans laquelle un modèle de la distribution statistique de l'entrée est utilisé pour construire des cas de test représentatifs. Voir également les tests de profil opérationnel.
comptabilité d'état: Un élément de gestion de configuration, consistant en l'enregistrement et le rapport des informations nécessaires pour gérer efficacement une configuration. Ces informations comprennent une liste de l'identification de la configuration approuvée, l'état des modifications proposées à la configuration et l'état de mise en œuvre des modifications approuvées. (IEEE 610)
Test de résistance: Tests effectués pour évaluer un système ou un composant à ou au-delà des limites de ses exigences spécifiées. (IEEE 610)
couverture structurelle: Mesures de couverture basées sur la structure interne du composant.
technique de conception de test structurel: Voir la technique de conception de test en boîte blanche.
bout: Implémentation squelettique ou spécifique d'un composant logiciel, utilisée pour développer ou tester un composant qui l'appelle ou en dépend d'une autre manière. Il remplace un composant appelé. (Après IEEE 610)
sous-chemin: Une séquence d'instructions exécutables dans un composant.
critères de suspension: Les critères utilisés pour arrêter (temporairement) tout ou partie des activités de test sur les éléments de test. (Après IEEE 829)
pertinence: La capacité du produit logiciel à fournir un ensemble approprié de fonctions pour des tâches et des objectifs utilisateur spécifiés. (ISO 9126) Voir aussi fonctionnalité.
Inventaire de mesure de l'utilisabilité des logiciels (SUMI): Une technique de test d'utilisabilité basée sur un questionnaire pour évaluer l'utilisabilité, par ex. satisfaction de l'utilisateur, d'un composant ou d'un système. (Veenendaal)
test de syntaxe: Une technique de conception de test boîte noire dans laquelle les cas de test sont conçus en fonction de la définition du domaine d'entrée et / ou du domaine de sortie.
système: Un ensemble de composants organisés pour accomplir une fonction ou un ensemble de fonctions spécifiques. (IEEE 610)
test d'intégration du système: Tester l'intégration des systèmes et des packages; tester les interfaces avec des organisations externes (par exemple, échange de données informatisé, Internet).
test du système: Processus de test d'un système intégré pour vérifier qu'il répond aux exigences spécifiées. (Hetzel)
T
analyse technique: Une activité de discussion de groupe de pairs qui se concentre sur l'obtention d'un consensus sur l'approche technique à adopter. Un examen technique est également appelé examen par les pairs. (Gilb et Graham, IEEE 1028)
approche de test: La mise en œuvre de la stratégie de test pour un projet spécifique. Il comprend généralement les décisions prises qui suivent en fonction de l’objectif du projet (de test) et de l’évaluation des risques effectuée, les points de départ concernant le processus de test, les techniques de conception de test à appliquer, les critères de sortie et les types de test à effectuer.
automatisation des tests: L'utilisation de logiciels pour effectuer ou soutenir des activités de test, par ex. gestion des tests, conception des tests, exécution des tests et vérification des résultats.
base de test: Tous les documents à partir desquels les exigences d'un composant ou d'un système peuvent être déduites. La documentation sur laquelle sont basés les cas de test. Si un document ne peut être modifié que par le biais d'une procédure de modification formelle, alors la base de test est appelée une base de test gelée. (Après TMap)
cas de test: Un ensemble de valeurs d'entrée, de conditions préalables d'exécution, de résultats attendus et de post-conditions d'exécution, développés pour un objectif ou une condition de test particulier, comme pour exercer un chemin de programme particulier ou pour vérifier la conformité à une exigence spécifique. (Après IEEE 610)
spécification de cas de test: Un document spécifiant un ensemble de cas de test (objectif, entrées, actions de test, résultats attendus et conditions préalables d'exécution) pour un élément de test. (Après IEEE 829)
charte de test: Un énoncé des objectifs du test et éventuellement des idées de test. Les chartes de test sont entre autres utilisées dans les tests exploratoires. Voir également les tests exploratoires.
comparateur de test: Un outil de test pour effectuer une comparaison de test automatisée.
comparaison de test: Processus d'identification des différences entre les résultats réels produits par le composant ou le système testé et les résultats attendus pour un test. La comparaison des tests peut être effectuée pendant l'exécution du test (comparaison dynamique) ou après l'exécution du test.
condition de test: Un élément ou un événement d'un composant ou d'un système qui pourrait être vérifié par un ou plusieurs cas de test, par ex. une fonction, une transaction, un attribut de qualité ou un élément structurel.
données de test: Données qui existent (par exemple, dans une base de données) avant l'exécution d'un test, et qui affectent ou sont affectées par le composant ou le système testé.
outil de préparation des données de test: Un type d'outil de test qui permet de sélectionner des données à partir de bases de données existantes ou de créer, générer, manipuler et éditer pour une utilisation dans les tests.
spécification de conception de test: Un document spécifiant les conditions de test (éléments de couverture) pour un élément de test, l'approche de test détaillée et identifiant les cas de test de haut niveau associés. (Après IEEE 829)
outil de conception de test: Un outil qui prend en charge l'activité de conception de test en générant des entrées de test à partir d'une spécification qui peut être conservée dans un référentiel d'outils CASE, par ex. outil de gestion des exigences, ou à partir de conditions de test spécifiées contenues dans l'outil lui-même.
technique de conception de test: Une méthode utilisée pour dériver ou sélectionner des cas de test.
environnement de test: Un environnement contenant du matériel, des instruments, des simulateurs, des outils logiciels et d'autres éléments de support nécessaires pour effectuer un test. (Après IEEE 610)
rapport d'évaluation du test: Un document produit à la fin du processus de test résumant toutes les activités de test et les résultats. Il contient également une évaluation du processus de test et des leçons apprises.
exécution du test: Processus d'exécution d'un test par le composant ou le système testé, produisant des résultats réels.
automatisation de l'exécution des tests: L'utilisation de logiciels, par ex. des outils de capture / lecture, pour contrôler l'exécution des tests, la comparaison des résultats réels avec les résultats attendus, la mise en place des conditions préalables de test, et d'autres fonctions de contrôle de test et de reporting.
phase d'exécution du test: La période de temps dans un cycle de vie de développement logiciel pendant laquelle les composants d'un produit logiciel sont exécutés, et le produit logiciel est évalué pour déterminer si les exigences ont été satisfaites ou non. (IEEE 610)
calendrier d'exécution des tests: Un schéma pour l'exécution de procédures de test. Les procédures de test sont incluses dans le calendrier d'exécution des tests dans leur contexte et dans l'ordre dans lequel elles doivent être exécutées.
technique d'exécution des tests: La méthode utilisée pour effectuer l'exécution réelle du test,soit manuellement, soit automatisé.
outil d'exécution de test: Un type d'outil de test capable d'exécuter d'autres logiciels à l'aide d'un script de test automatisé, par ex. capture / lecture. (Fewster et Graham)
faisceau d'essai: Un environnement de test composé de stubs et de pilotes nécessaires pour effectuer un test.
infrastructure de test: Les artefacts organisationnels nécessaires pour effectuer les tests, comprenant des environnements de test, des outils de test, un environnement de bureau et des procédures.
élément de test: L'élément individuel à tester. Il existe généralement un objet de test et de nombreux éléments de test. Voir aussi objet de test.
niveau de test: Un groupe d'activités de test qui sont organisées et gérées ensemble. Un niveau de test est lié aux responsabilités dans un projet. Des exemples de niveaux de test sont le test des composants, le test d'intégration, le test du système et le test d'acceptation. (Après TMap)
journal de test: Un enregistrement chronologique des détails pertinents sur l'exécution des tests. (IEEE 829)
journalisation des tests: Processus d'enregistrement d'informations sur les tests exécutés dans un journal de test.
gestionnaire de test: La personne responsable du test et de l'évaluation d'un objet de test. L'individu, qui dirige, contrôle, administre les plans et régule l'évaluation d'un objet de test.
gestion des tests: La planification, l'estimation, la surveillance et le contrôle des activités de test, généralement effectuées par un gestionnaire de test.
Modèle de maturité de test (TMM): Un cadre par étapes à cinq niveaux pour l'amélioration des processus de test, lié au modèle de maturité des capacités (CMM) qui décrit les éléments clés d'un processus de test efficace.
Amélioration des processus de test (TPI): Un cadre continu pour l'amélioration du processus de test qui décrit les éléments clés d'un processus de test efficace, particulièrement ciblé sur les tests de système et les tests d'acceptation.
objet de test: Le composant ou le système à tester. Voir également l'élément de test.
objectif du test: Une raison ou un but pour concevoir et exécuter un test.
oracle de test: Une source pour déterminer les résultats attendus à comparer avec le résultat réel du logiciel testé. Un oracle peut être le système existant (pour un benchmark), un manuel d’utilisation ou les connaissances spécialisées d’un individu, mais ne doit pas être le code. (Après Adrion)
indicateur de performance du test: Une métrique, en général de haut niveau, indiquant dans quelle mesure une certaine valeur cible ou un certain critère est atteint. Souvent lié aux objectifs d'amélioration des processus de test, par ex. Pourcentage de détection des défauts (DDP).
phase de test: Un ensemble distinct d'activités de test rassemblées dans une phase gérable d'un projet, par ex. les activités d'exécution d'un niveau de test. (Après Gerrard)
plan de test: Un document décrivant la portée, l'approche, les ressources et le calendrier des activités de test prévues. Il identifie entre autres les éléments de test, les fonctionnalités à tester, les tâches de test, qui effectuera chaque tâche, le degré d'indépendance du testeur, l'environnement de test, les techniques de conception de test et les techniques de mesure de test à utiliser, et la justification de leur choix. et tout risque nécessitant une planification d'urgence. Il s'agit d'un enregistrement du processus de planification des tests (d'après IEEE 829)
planification des tests: L'activité d'établissement ou de mise à jour d'un plan de test.
politique de test: Un document de haut niveau décrivant les principes, l'approche et les principaux objectifs de l'organisation en matière de tests.
Analyse des points de test (TPA): Méthode d'estimation de test basée sur une formule basée sur l'analyse des points de fonction. (TMap)
procédure de test: Voir la spécification de la procédure de test.
spécification de la procédure d'essai: Un document spécifiant une séquence d'actions pour l'exécution d'un test. Également appelé script de test ou script de test manuel. (Après IEEE 829)
processus de test: Le processus de test fondamental comprend la planification, la spécification, l'exécution, l'enregistrement et la vérification de l'achèvement. (BS 7925/2)
répétabilité du test: Un attribut d'un test indiquant si les mêmes résultats sont produits chaque fois que le test est exécuté.
essai: Exécution d'un test sur une version spécifique de l'objet de test.
script de test: Couramment utilisé pour désigner une spécification de procédure de test, en particulier une spécification automatisée.
spécifications du test: Un document qui consiste en une spécification de conception de test, une spécification de cas de test et / ou une spécification de procédure de test.
stratégie de test: Un document de haut niveau définissant les niveaux de test à effectuer et les tests à l'intérieur de ces niveaux pour un programme (un ou plusieurs projets).
suite de tests: Ensemble de plusieurs cas de test pour un composant ou un système en cours de test, où la post-condition d'un test est souvent utilisée comme condition préalable pour le suivant.
rapport de synthèse du test: Un document résumant les activités et les résultats des tests. Il contient également une évaluation des éléments de test correspondants par rapport aux critères de sortie.(Après IEEE 829)
cible de test: Un ensemble de critères de sortie.
outil de test: Un produit logiciel qui prend en charge une ou plusieurs activités de test, telles que la planification et le contrôle, la spécification, la création de fichiers et de données initiaux, l'exécution de tests et l'analyse de tests. (TMap) Voir aussi CAST.
type de test: Groupe d'activités de test visant à tester un composant ou un système concernant un ou plusieurs attributs de qualité interdépendants. Un type de test est axé sur un objectif de test spécifique, c'est-à-dire un test de fiabilité, un test d'utilisabilité, un test de régression, etc., et peut avoir lieu sur un ou plusieurs niveaux de test ou phases de test. (Après TMap)
testabilité: La capacité du produit logiciel à permettre aux logiciels modifiés d'être testés. (ISO 9126) Voir aussi maintenabilité.
examen de testabilité: Une vérification détaillée de la base de test pour déterminer si la base de test est à un niveau de qualité adéquat pour servir de document d'entrée pour le processus de test. (Après TMap)
exigences testables: La mesure dans laquelle une exigence est énoncée en des termes qui permettent l'établissement de plans de test (et par la suite de cas de test) et l'exécution de tests pour déterminer si les exigences ont été satisfaites. (Après IEEE 610)
testeur: Un professionnel techniquement qualifié qui est impliqué dans les tests d'un composant ou d'un système.
essai: Processus comprenant toutes les activités du cycle de vie, à la fois statiques et dynamiques, liées à la planification, à la préparation et à l'évaluation des produits logiciels et des produits de travail associés pour déterminer qu'ils satisfont aux exigences spécifiées, démontrer qu'ils sont adaptés à l'usage prévu et détecter les défauts.
testware: Les artefacts produits pendant le processus de test requis pour planifier, concevoir et exécuter les tests, tels que la documentation, les scripts, les entrées, les résultats attendus, les procédures de configuration et de nettoyage, les fichiers, les bases de données, l'environnement et tout logiciel ou utilitaire supplémentaire utilisé dans essai. (Après Fewster et Graham)
test de filetage: Une version de test d'intégration de composants où l'intégration progressive des composants suit la mise en œuvre de sous-ensembles d'exigences, par opposition à l'intégration de composants par niveaux d'une hiérarchie.
traçabilité: La capacité d'identifier les éléments connexes dans la documentation et les logiciels, tels queexigences avec les tests associés. Voir aussi traçabilité horizontale, traçabilité verticale.
test descendant: Une approche incrémentielle des tests d'intégration où le composant situé en haut de la hiérarchie des composants est testé en premier, les composants de niveau inférieur étant simulés par des stubs. Les composants testés sont ensuite utilisés pour tester les composants de niveau inférieur. Le processus est répété jusqu'à ce que les composants de niveau le plus bas aient été testés.
U
compréhensibilité: La capacité du produit logiciel à permettre à l'utilisateur de comprendre si le logiciel est adapté et comment il peut être utilisé pour des tâches et des conditions d'utilisation particulières. (ISO 9126) Voir également utilisabilité.
code inaccessible: Code impossible à atteindre et donc impossible à exécuter.
utilisabilité: Capacité du logiciel à être compris, appris, utilisé et attrayant pour l'utilisateur lorsqu'il est utilisé dans des conditions spécifiées. (ISO 9126)
tests d'utilisation: Test pour déterminer dans quelle mesure le produit logiciel est compris, facile à apprendre, facile à utiliser et attractif pour les utilisateurs dans des conditions spécifiées. (Après ISO 9126)
test de cas d'utilisation: Une technique de conception de test boîte noire dans laquelle les cas de test sont conçus pour exécuter des scénarios utilisateur.
test utilisateur: Un test dans lequel des utilisateurs réels sont impliqués pour évaluer l'utilisabilité d'un composant ou d'un système.
V
Modèle en V: Un cadre pour décrire les activités du cycle de vie du développement logiciel, de la spécification des exigences à la maintenance. Le modèle en V illustre comment les activités de test peuvent être intégrées à chaque phase du cycle de vie du développement logiciel.
validation: Confirmation par examen et par la fourniture de preuves objectives que les exigences pour une utilisation ou application prévue spécifique ont été remplies. (ISO 9000)
variable: Un élément de stockage dans un ordinateur qui est accessible par un logiciel en y faisant référence par un nom.
vérification: Confirmation par examen et par la fourniture de preuves objectives que les exigences spécifiées ont été remplies. (ISO 9000)
traçabilité verticale: Le traçage des exigences à travers les couches de la documentation de développement jusqu'aux composants.
test de volume: Test où le système est soumis à de grands volumes de données. Voir également les tests d'utilisation des ressources.
DANS
procédure pas à pas: Une présentation étape par étape par l'auteur d'un document afin de recueillir des informations et d'établir une compréhension commune de son contenu. (Freedman et Weinberg, IEEE 1028)
technique de conception de test de boîte blanche: Procédure documentée pour dériver et sélectionner des cas de test basés sur une analyse de la structure interne d'un composant ou d'un système.
test de boîte blanche: Test basé sur une analyse de la structure interne du composant ou du système.
Delphi large bande: Une technique d'estimation de test basée sur des experts qui vise à faire une estimation précise en utilisant la sagesse collective des membres de l'équipe.
Contactez moi si vous souhaitez ajouter plus de définitions dans ce glossaire.
Référence: http://www.istqb.org/downloads/glossary-1.0.pdf
lecture recommandée
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
- Emploi d'assistant QA en test logiciel
- Cours de test logiciel: à quel institut de test logiciel dois-je adhérer?
- Choisir les tests de logiciels comme carrière
- Travail d'indépendant de rédacteur de contenu technique de test de logiciels
- Guide d'externalisation de l'assurance qualité: sociétés d'externalisation de tests de logiciels
- Quelques questions d'entretien intéressantes sur les tests de logiciels
- Commentaires et évaluations du cours de test de logiciels