Cet article est orphelin. Moins de trois articles lui sont liés ().
[[Test de mutation]] dans les articles relatifs au sujet.Les tests de mutation sont des procédures mises au point et utilisées pour concevoir des tests logiciels et évaluer la qualité de ceux qui existent. Ils reposent sur des modifications mineures apportées à un programme afin d'avoir un comportement qui diffère du programme original.[1] Ces versions mutées sont appelée mutant. Le but étant que les tests détectent et "tuent" les mutants. Les suites de tests sont mesurées par le pourcentage de mutants qu'elles tuent. Les mutants sont basés sur des opérateurs de mutation bien définis qui imitent les erreurs de programmation typiques (comme l'utilisation d'un opérateur ou d'un nom de variable incorrect) ou forcent la création de tests précieux (comme la division de chaque expression par zéro). L'objectif est d'aider le testeur à développer des tests efficaces ou à localiser les faiblesses dans les données de test utilisées pour le programme ou dans des sections du code qui sont rarement ou jamais consultées pendant l'exécution. Les tests de mutation sont une forme de test en boîte blanche .[2]
Objectifs
Les objectifs des tests de mutation sont :
- identifier les morceaux de code avec des (ceux pour lesquels les mutants ne sont pas tués)[1]
- calculer le score de mutation,[3] le score de mutation est le nombre de mutants tués / nombre total de mutants.
- en savoir plus sur la propagation des erreurs et l'infection de l'état dans le programme.
Présentation des tests de mutation
Par exemple, considérons cet extrait de code Java:
public boolean exemple(Boolean a, Boolean b){
if (a && b) {
return true;
} else {
return false;
}
}
L'opérateur de mutation va remplacer && par || et produire le mutant suivant :
public boolean exemple(Boolean a, Boolean b){
if (a || b) {
return true;
} else {
return false;
}
}
Pour qu'un test tue un mutant, les trois conditions suivantes doivent être remplies :
- Un test doit atteindre la zone mutée.
- Les données d'entrée de test doivent infecter l'état du programme en provoquant des résultats différents pour le mutant et le programme d'origine. Par exemple, un test avec
a = trueetb = falserespecte cette condition. - L'état incorrect du programme (la valeur retournée) doit se propager à la sortie du programme et être vérifié par le test.
Ces conditions sont collectivement appelées le modèle RIP .[4],[5]
Références
- Moez Krichen, Une enquête sur le test de mutation: principes, avantages, limites et orientations futures, (lire en ligne)
- ↑ S. Misra, CCECE 2003 - Canadian Conference on Electrical and Computer Engineering. Toward a Caring and Humane Technology (Cat. No.03CH37436), vol. 3, Montreal, Que., Canada, IEEE, , 1739–1742 p. (ISBN 978-0-7803-7781-3, DOI 10.1109/CCECE.2003.1226246, S2CID 62549502), « Evaluating four white-box test coverage methodologies »
- ↑ « Le mutation testing, ou comment tester ses tests », sur Blog Ippon - Ippon Technologies, (consulté le )
- ↑ Huan Lin, Yawen Wang, Yunzhan Gong et Dahai Jin, « Domain-RIP Analysis: A Technique for Analyzing Mutation Stubbornness », IEEE Access, vol. 7, , p. 4006–4023 (ISSN 2169-3536, DOI 10.1109/ACCESS.2018.2883776, lire en ligne, consulté le )
- ↑ (en-US) « Briefly about Mutation Testing », sur Sandor Dargo’s Blog, (consulté le )
