Le schéma d'exécution des procédures de test. Les procédures de tests sont inclues dans le calendrier d'exécution dans leur contexte et dans l'ordre où elles doivent être exécutées.

Une structure en cinq niveaux qui décrit les éléments clé d'un processus logiciel efficace. Le CMM couvre les pratiques pour la planification, l'ingénierie et la gestion des développements et de la maintenance des logiciels. [CMM]

Une structure décrivant les éléments clé d'un processus de développement et de maintenance efficace d'un produit. Le Capability Maturity Model Integration couvre les pratiques pour le planning, l'ingénierie et la gestion du développement et de la maintenance du produit. CMMi est le successeur désigné de CMM, [CMMi]

L'attribut d'un composant ou système, spécifié ou suggéré par la documentation d'exigences (p.ex. contraintes de fiabilité, disponibilité ou de conception). [d'après IEEE 1008]

Une représentation résumée de mesures de performance qui représentent le progrès réalisé dans la mise en oeuvre de buts à long terme. Une carte de score fournit les mesures statiques de performance pendant ou à la fin d'un intervalle défini.

Un ensemble de valeurs d'entrée, de pré-conditions d'exécution, de résultats attendus et de post-conditions d'exécution, développées pour un objectif ou une condition de tests particulier, tel qu'exécuter un chemin particulier d'un programme ou vérifier le respect d'une exigence spécifique. [d'après IEEE 610]

Cas de test ne pouvant être exécuté parce que les pré-conditions pour son exécution ne sont pas réalisées.

Un cas de test avec des valeurs concrètes (niveau implémentation) en entrée et en sortie.

Un cas de tests sans valeurs d'entrée concrètes (au niveau implémentation) ni résultats attendus concrets. Des opérateurs logiques sont utilisés, des valeurs réelles ne sont pas encore définies ou disponibles. Voir aussi cas de tests de bas niveau.

Acronyme de Computer Aided Software Engineering (Conception Logicielle Assistée par Ordinateur)

Acronyme de Computer Aided Software Testing (Test Logiciel Assisté par Ordinateur). Voir aussi Automatisation des tests.

Une source de défaut telle que si elle est retirée, l'apparition de ce type de défaut est diminuée ou supprimée.

Le processus de confirmation d'un composant, système ou d'une personne se conforme à des exigences spécifiées, par exemple en réussissant un examen.

Une expression d'objectifs de test et éventuellement d'idées de test au sujet de la façon de tester. Les agréments de test sont utilisés en test exploratoire.

Séquence d'événements, par exemple instructions exécutables, d'un composant ou système d'un point d'entrée jusqu'à un point de sortie

Un chemin pour lequel un ensemble de valeurs d'entrées et de préconditions existent qui en causent l'exécution.

Un chemin qui ne peut être exécuté par un ensemble possible de valeurs d'entrée.

Ensemble de critères de sortie

La description d'un ensemble d'objets ayant des propriétés et des comportements communs, qui correspondent typiquement à des items du monde réel (personnes, places ou choses) dans le domaine métier ou dans le domaine du problème.

Une partie prenante du projet qui exige, paie, spécifie, utilise ou reçoit les sorties générées par un produit.

Durant la phase de clôture des tests d'un processus de test, les données sont collectées des activités terminées pour consolider les expériences, les testwares, les faits et chiffres. La phase de clôture des tests consiste en la finalisation et l'archivage des testwares, l'évaluation des processus de tests, incluant la préparation des rapports d'évaluation des tests.

La capacité d'un produit logiciel à co-exister avec d'autres logiciels indépendants dans un environnement commun partageant des ressources communes [ISO 9126] voir tests de portabilité.

Instructions informatiques et définitions de données exprimées dans un langage de programmation ou dans une forme produite par un assembleur, un compilateur ou autre traducteur. [IEEE 610]

Code qui ne peut être atteint et est de ce fait impossible à exécuter

Le degré d'uniformité, de standardisation, et l'absence de contradictions dans les documents ou parties d'un composant ou système [IEEE 610]

Un groupe de personnes responsables de l'évaluation et de l'approbation (ou non) des modifications proposées aux éléments de configuration, et devant s'assurer de l'implémentation des modifications approuvées [IEEE 610]

Le processus d'identifier les différences entre les résultats actuels produits par le composant ou système en cours de test et les résultats attendus pour un test. La comparaison des tests peut être effectuée pendant l'exécution des tests (comparaison dynamique) ou après l'exécution des tests.

Comparaison des résultats effectifs et attendus, effectuée pendant l'exécution du logiciel, par exemple par un outil de test.

Comparaison des résultats actuels et attendus, effectués après la fin de l'exécution du logiciel

Un outil de tests utilisé pour effectuer des comparaisons de tests automatisées.

Un outil logiciel qui traduit un programme exprimé dans un langage de haut niveau dans son équivalent en langage machine. [IEEE 610]

Le nombre de chemins indépendants au travers d'un programme. La complexité cyclomatique est définie par L ? N + 2P, avec : - L : le nombre d'arcs/liens d'un graphe - N : le nombre de n?uds du graphe - P le nombre de parties déconnectées du graphe (p.ex. un graphe appelé ou un sous-programme) [d'après McCabe]

La réponse d'un composant ou d'un système à un ensemble de valeurs d'entrées et de pré-conditions.

Un élément logiciel minimal qui peut être testé isolément

Le processus consistant à transformer des objectifs de test généraux en conditions de test tangibles et en cas de test.

Expression logique qui peut être évaluée à Vrai ou Faux, par exemple A>B.

Deux ou plus conditions simples jointes par un opérateur logique (AND, OR ou XOR)

Un article ou événement d'un composant ou système qui pourrait être vérifié par un ou plusieurs cas de tests; p.ex. une fonction, une transaction, un attribut qualité ou un élément de structure.

Composition d'un composant ou système défini par le nombre, la nature et les interconnexions de ses parties constituantes.

Capacité d'un produit logiciel à adhérer à des standards, conventions ou consignes dans des lois ou prescriptions similaires. [ISO 9126].

Les conséquences/résultats de l'exécution d'un test. Cela inclut les sorties vers des écrans, les modification de données, rapports et messages d'information envoyés.

Une restriction qui est imposée dans les choix disponibles pour le développeur lors de la conception et la construction d'un produit. Parfois utilisée pour indiquer les limitations physiques comme la taille, la forme, le poids. Les contraintes peuvent être imposées soit par les utilisateurs (dans les exigences utilisateur) soit par les développeurs avec une connaissance de spécialiste, comme par exemple la connaissance des standards de sûreté de fonctionnement (dans les exigences système).

Un élément de la gestion de configuration, consistant en l'évaluation, la coordination, l'approbation ou la désapprobation, et l'implantation de modifications des éléments de configuration après l'établissement de leur identification de configuration [IEEE 610]

Le processus par lequel les décisions sont atteintes et les mesures protectrices sont implémentées pour réduire les risques ou les maintenir dans des niveaux acceptables.

Une activité de gestion des tests qui gère le développement et l'application d'un ensemble d'actions correctives pour avoir un projet de tests sur les rails quand les métriques de suivi indiquent une déviation par rapport aux plans.

Le coût total imputé aux activités et problèmes liés à la qualité, souvent divisé en coûts de prévention, coûts d'estimation, coûts des défaillances internes et coûts des défaillances externes

Le degré, exprimé en pourcentage, selon lequel un élément de couverture spécifié a été exécuté lors d'une suite de test.

Une méthode d'analyse qui détermine quelles parties du logiciel ont été exécutées (couvertes) par une suite de tests et quelles parties ne l'ont pas été, p.ex. couverture des instructions, des décisions ou des conditions.

Le pourcentage des branches qui ont été exécutés dans une suite de tests. 100% de couverture des branches implique 100% de couverture des décisions et 100% de couverture des instructions.

Le pourcentage des chemins qui ont été exercés par une suite de tests. 100% de couverture des chemins implique 100% de couverture PLCS

Le pourcentage des résultats de conditions qui ont été exercés par une suite de tests. 100% de couverture des conditions nécessite que chaque condition simple dans chaque instruction conditionnelle soit testée en Vrai et en Faux

Le pourcentage de tous les résultats de conditions simples qui affectent de façon indépendante les résultats des conditions qui ont été exercés par une suite de cas de tests. 100% de couverture des déterminations des conditions implique 100% de couverture

Le pourcentage de combinaison de tous les résultats de combinaisons simples dans une instruction exercées par une suite de tests. Une couverture des conditions multiples à 100% implique la couverture à 100% des conditions.

Le pourcentage des résultats de décisions qui ont été exécutées par une suite de tests. 100% de couverture des décisions implique 100% de couverture des branches et 100% de couvertures des instructions.

Le pourcentage des résultats de toutes les conditions et résultats des décisions qui ont été exercées par une suite de tests. 100% de couvertures des décisions-conditions implique à la fois 100% de couverture des conditions et 100% de couverture des décisions.

Le pourcentage des instructions exécutables qui ont été exécutées par une suite de tests

Le pourcentage de partitions d'équivalence qui ont été exercées par une suite de tests.

Le pourcentage de valeurs limites qui ont été couvertes par une suite de tests.

Le pourcentage de paires de décision-usage qui ont été empruntés par une suite de cas de tests.

Le pourcentage de PLCS d'un composant qui ont été exécutés par une suite de tests. 100% de couverture PLCS implique 100% de couverture des décisions

Critère d'Acceptation : 1. Condition qu'un produit logiciel doit satisfaire pour être accepté par un utilisateur, un client ou toute autre partie prenante. C'est un élément d'une exigence.

L'ensemble des conditions spécifiques et génériques pour permettre à un processus de continuer à exécuter une tâche définie (par exemple une phase de tests). Le but d'un critère d'entrée est d'empêcher le début d'une tâche qui générerait une charge de travail plus importante (inutile et gaspillée) que celle nécessaire pour supprimer le critère d'entrée défaillant. [Gilb et Graham]

Les activités de test qui doivent être répétées quand le test est repris après une suspension. [d'après IEEE 829]

L'ensemble des conditions génériques et spécifiques, convenues avec les responsables, pour permettre de terminer officiellement un processus. L'objectif d'un critère de sortie est d'éviter qu'une tâche ne soit considérée comme achevée alors qu'il y a encore des parties de cette tâche qui n'ont pas été terminées. Les critères de sortie sont utilisés dans le test pour faire des comptes rendus et pour planifier l'arrêt du test. [D'après Gilb et Graham]

Le critère utilisé pour arrêter (temporairement) tout ou partie des activités de tests sur les items de tests. [d'après IEEE 829]

Règles de décisions utilisées pour déterminer si un élément de test (fonction) ou caractéristique a réussi ou échoué un test. [IEEE 829]

Exécution des processus de test sur une version unique et identifiable d'un objet de test.

Une période temporelle qui commence lorsque un produit logiciel est conçu et se termine lorsque le logiciel n'est plus disponible à l'usage. Le cycle de vie logiciel inclut typiquement une phase de mûrissement, une phase d'exigences, un phase de conception, une phase d'implémentation, une phase de test, une phase d'installation et livraison, une phase d'opération et de maintenance, et parfois une phase de retrait. Note : ces phases peuvent se recouper ou être exécutées de façon itérative.