| Terme | Définition | Référence |
|---|---|---|
| Couverture des conditions et décisions | 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 | Glossaire CFTL/ISTQB |
| Couverture des conditions multiples (ou composées) | 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. | Glossaire CFTL/ISTQB |
| Couverture des décisions | 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. | Glossaire CFTL/ISTQB |
| Couverture des décisions-conditions | 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. | Glossaire CFTL/ISTQB |
| Couverture des instructions | Le pourcentage des instructions exécutables qui ont été exécutées par une suite de tests | Glossaire CFTL/ISTQB |
| Couverture des partitions d'équivalence | Le pourcentage de partitions d'équivalence qui ont été exercées par une suite de tests. | Glossaire CFTL/ISTQB |
| Couverture des valeurs limite | Le pourcentage de valeurs limites qui ont été couvertes par une suite de tests. | Glossaire CFTL/ISTQB |
| Couverture du flot de données (ou data flow) | Le pourcentage de paires de décision-usage qui ont été empruntés par une suite de cas de tests. | Glossaire CFTL/ISTQB |
| Couverture PLCS | 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 | Glossaire CFTL/ISTQB |
| Critère d'entrée | 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] | Glossaire CFTL/ISTQB |
| Critère d'acceptation | 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. 2. Le critère de sortie que doit satisfaire un composant ou un système de façon à être accepté par un utilisateur, client ou une autre entité autorisée [IEEE 610] |
Glossaire CFTL/REQB |
| Critère de continuation | 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] | Glossaire CFTL/ISTQB |
| Critère de sortie | 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] | Glossaire CFTL/ISTQB |
| Critère de suspension | 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] | Glossaire CFTL/ISTQB |
| Critère réussite/échec | 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] | Glossaire CFTL/ISTQB |
| Cycle de test | Exécution des processus de test sur une version unique et identifiable d'un objet de test. | Glossaire CFTL/ISTQB |
| Cycle de vie logiciel | 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. | Glossaire CFTL/ISTQB |
| dd-path (decision-to-decision path) | Un chemin d'exécution (habituellement par le moyen d'un graphe représentant un programme, tel qu'un flot de contrôle) qui n'inclut aucun nud conditionnel tel qu'un chemin d'exécution entre deux décisions. | Glossaire CFTL/ISTQB |
| Déboguer | Le processus de trouver, analyser et éliminer les causes de défaillance dans les logiciels. | Glossaire CFTL/ISTQB |
| Débordement de pile | Une défaillance d'accès mémoire dû à la tentative par un processus de stocker des données aux delà des limites d'une zone de taille fixe, ayant pour conséquences l'écrasement de zones mémoires adjacentes ou la levée d'une exception pour débordement. | Glossaire CFTL/ISTQB |
1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 - 16 - 17 - 18 - 19 - 20 - 21 - 22 - 23 - 24 - 25
