Test et Validation. Tristan Crolard. Laboratoire CEDRIC Equipe CPR. cedric.cnam.fr/cpr/crolard

Transcription

1 Test et Validation Tristan Crolard Laboratoire CEDRIC Equipe CPR cedric.cnam.fr/cpr/crolard 1

2 Organisation du cours Cours/ED : 5 séances de 3h Langages de programmations : Java et Ada Exemples et démonstrations d'outils TP : 4 séances de 3h Langage de programmation : Java Plateforme de test : junit et autres plugins Eclipse 2

3 Organisation du cours Séances de cours TP 1. Fondamentaux des tests 1 2. Tester pendant le cycle de vie logiciel 3. Techniques de test Techniques statiques et revues de code Techniques boites noires 2 Techniques boites blanches X Critères de couverture 3 X 4. Gestion des tests X 5. Tester à partir de modèles Modéliser les spécications 4 X Génération automatique de tests X 6. Outils de support aux tests X 7. Méthodes formelles (survol) 5 3

4 Bibliographie Pratique des tests logiciels (Dunod, 2009) J. Printz, J.-F. Peyre. Le test des logiciels (Hermès, 2000) S. Xanthakis, P. Régnier, C. Karapoulios. The art of software testing (Wiley, Second edition 2004) G. J. Meyers. Glossaire des termes utilisés en tests de logiciels. (CFTL/ISTQB, 2007) Comité Français des Tests Logiciels/International Software Testing Qualications Board. 4

5 Test, vérication et validation Terminologie Validation. The assurance that a product, service, or system meets the needs of the customer and other identied stakeholders. It often involves acceptance and suitability with external customers. Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specication, or imposed condition. It is often an internal process. The PMBOK guide (norme IEEE) 5

6 Test, vérication et validation Citation Verication is building the product right, and Validation is building the right product. B. W. Boehm Verifying and Validating Software Requirements and Design Specications Software Risk Management, pp , IEEE Computer Society Press,

7 Terminologie Extraite des normes IEEE STD 982 et 1044 : ERROR (Erreur) : Human action that results in software containing a fault. E.g. omission or misinterpretation of user requirements in a software specication, and incorrect translation or omission of a requirement in the design specication. DEFECT (Défaut) : A product anomaly; e.g. (1) omissions and imperfections found during early life cycle phases and (2) faults contained in software suciently mature for test or operation. FAULT (Défaillance) : (1) An accidental condition that causes a functional unit to fail to perform its required function. (2) A manifestation of an error in software. A fault if encountered may cause a failure. FAILURE (Panne) : The termination of the ability of a functional unit to perform its required function. A failure may be produced when a fault is encountered. 7

8 Méthodes de vérication et validation Revue de code et de documentation (relecture) Analyse statique (typage, analyse de ot information/contrôle,...) Test (dynamique) Execution symbolique (génération de tests,...) Vérication formelle (model-checking, preuve de programme,...) 8

9 Analyse statique Principalement réalisée par le compilateur vérication de la syntaxe vérication du typage vérication du ot d'information (variables initialisées) vérication du ot de contrôle (code mort) Certains outils existent souvent pour les langages dynamiques (comme python, javascript, php,...) Certains outils permettent de faire des analyses plus nes que celles des compilateurs (par exemple par interprétation abstraite) 9

10 Analyse statique (exemple) Closure : Compilateur javascript de Google Extraits de la documentation : The Closure Compiler provides warnings for illegal JavaScript and warnings for potentially dangerous operations, helping you to produce JavaScript that is less buggy and easier to maintain. The Closure Compiler can use data type information about JavaScript variables to provide enhanced optimization and warnings. The Closure Compiler's type language derives from the annotations used by the JSDoc document-generation tool. 10

11 Analyse statique de source JavaScript /** {number x {number */ function foo(x) { return x+2; /** {number x some value {number some result */ function bar(x) { return x+"bar"; Line 14: WARNING - inconsistent return type found : string required: number return x+"bar"; ^ 0 error(s), 1 warning(s), 100.0% typed 11

12 Analyse statique (autre exemple) Phantm : PHP ANALYZER FOR TYPE MISMATCH Extraits de la documentation : Phantm analyzes PHP code statically (with optional help from dynamic instrumention). It has found many errors in real PHP applications. Phantm is a tool written in Scala that can be used to detect potential programming errors inside PHP applications. It will both work for small isolated script as well as full-blown applications. Phantm does multiple things: it first parses your php files, then try to resolve both constants and included les, from that point it will do name analysis, ensuring basic language restrictions. From that stage, it will perform data-ow analysis for every scopes in your applications. This data- ow analysis will be focused on checking whether the types of the values are used in a sound way. 12

13 <?php /** int $x int */ function foo($x) { return ($x + 2); /** int $b */ function bar($b) { return $x+"bar"; Analyse statique de source PHP Line 14 Notice: Type mismatch: expected: Numeric, found: Top return $x+"bar"; 1 notice and 0 error occured. 13

14 Autres exemples récents Facebook Hack: Statically Typed PHP Apple Swift Perl 6 Microsoft TypeScript (javascript) Mypy : experimental optional static type checker for Python 14

15 Test : dénition et citations Testing is the process of analyzing a software item to detect the dierences between existing and required conditions, (that is, bugs) and to evaluate the features of the software items IEEE (Standard Glossary of Software Engineering Terminology). Testing is the process of executing a program with the intent of nding errors. Glenford J. Myers. The Art of Software testing. Wiley, Second edition Testing can reveal the presence of errors but never their absence Edsgar W. Dijkstra. Notes on structured programming. Academic Press,

16 Terminologie [CFTL] Processus de test : processus consistant en toutes les activités du cycle de vie, statiques et dynamiques, concernant la planication et l'évaluation de produits logiciels, pour déterminer s'ils satisfont aux exigences, pour démontrer qu'ils sont aptes aux objectifs et pour en détecter des anomalies. Test : un ensemble d'un ou plusieurs cas de tests [IEEE 829]. Cas de test : un ensemble de valeurs d'entrée (données de tests), de pré conditions d'exécution, de résultats attendus et de post conditions d'exécution, développées pour un objectif particulier, tel qu'exécuter un chemin donné d'un programme ou vérifier le respect d'une exigence spécifique [IEEE 610]. Objectif de test : une raison ou un but pour la conception et l'exécution d'un test. Scénario de test : un document spécifiant la séquence d'actions pour l'exécution d'un cas de test. Stratégie de test : un document de haut niveau dénissant, pour un programme, les tests à exécuter (pour un ou plusieurs projets). 16

17 Cycle de vie du logiciel modèle en V Spécifications Tests de conformité Conception générale Tests d intégration Conception détaillée Tests unitaires Implémentation 17

18 Diérents types de tests En fonction de la granularité Tests unitaires Tests d'intégration Tests de conformité En fonction des caractéristiques Tests de non-régression Tests de robustesse Tests de performance Tests de sécurité... En fonction de l'accessibilité Tests fonctionnels boites noires Tests structurels boites blanches 18

19 Test fonctionnel boites noires Dénition [CFTL] Technique de test où les cas de tests sont élaborés à partir d'une analyse des spécifications des fonctionnalités d'un composant ou système sans référence à sa structure interne. Méthodes du test fonctionnel Test aléatoire Analyse partitionnelle des domaines des données d'entrée (et test aux limites) Test combinatoire Algorithmes Pairwise Génération automatique de tests à partir de spécications 19

20 Test structurel boites blanches Dénition [CFTL] Technique de test où les cas de tests sont basés sur une analyse de la structure interne d'un composant ou système (en général, le code source). Méthodes du test structurel Basés sur le graphe de ot de contrôle (toutes les instructions, toutes les branches, tous les chemins,...) Basés sur la couverture du flot de données (toutes les définitions de variable, toutes les utilisations,...) Remarque. Le test structurel complète le test fonctionnel, il ne peut pas le remplacer (il permet de couvrir le code source existant mais il ne dit rien sur le code source qui peut manquer). 20

21 Le test dans le cadre des logiciels critiques Norme DO-178 : Software Considerations in Airborne Systems and Equipment Certication (Règlementation pour le développement de logiciels dans le secteur aéronautique). Norme EN : Railway applications Software for railway control and protection systems Communication, signalling and processing systems (Domaine ferroviaire Logiciels pour les systèmes de contrôle et de protection ferroviaires Systèmes de signalisation électroniques reliés à la sécurité) 21

22 Norme DO-178 (aéronautique) 6.4 Software Testing Process ::: Test Coverage Analysis Test coverage analysis is a two step process, involving requirements-based coverage analysis and structural coverage analysis. The first step analyzes the test cases in relation to the software requirements to conrm that the selected test cases satisfy the specified criteria. The second step confirms that the requirements-based test procedures exercised the code structure. 22

23 Norme DO-178 (aéronautique) Software Failure Denition Associated Structural Criticality Level Coverage Level Level A Catastrophic: prevents continued safe MC/DC & ight or landing, many fatal injuries Statement Coverage Level B Hazardous/Severe: potential fatal injuries Decision Coverage & to a small number of occupants Statement Coverage Level C Major: impairs crew eciency, discomfort Statement Coverage or possible injuries to occupants Level D Minor: reduced aircraft safety margins None required but well within crew capabilities Level E No Eect: does not eect the safety None required of the aircraft at all 23

24 Norme EN (ferroviaire) Test Coverage Criterion SIL 0 SIL 1 SIL 2 SIL 3 SIL 4 Statement R HR HR HR HR Branch - R R HR HR Compound Condition - R R HR HR Data ow - R R HR HR Path - R R HR HR R : Recommended HR : Highly Recommended 24

25 Why is structural testing not a DO-178B/ED- 12B requirement? (RTCA/DO-248A 1,FAQ #44) There is a distinction between structural coverage analysis and structural testing. The purpose of structural coverage analysis is to determine which code structure was not exercised by the requirements-based test procedures (reference DO-178B/ED-12B Section ). Structural testing is the process of exercising software with test scenarios written from the source code, not from the requirements. Structural testing does not meet the DO-178B/ED-12B objective that all code structure is exercised by the requirements-based test procedures. The correct approach when structural coverage analysis identies untested code is to consider the possible causes in accordance with DO-178B/ED-12B Section If any additional testing is required, it should be requirements-based testing, using high-level, low-level, or derived requirements, as appropriate. 25

26 Structured testing cannot find errors such as the non-implementation of some of the requirements. Since the starting point for developing structural test cases is the code itself, there is no way of nding requirements (highlevel, low-level, or derived) not implemented in the code through structural tests. It is a natural tendency to consider outputs of the actual code (which is de facto the reference for structural testing) as the expected results. This bias cannot occur when expected outputs of a tested piece of code are determined by analysis of the requirements. Since the code itself is used as the basis of the test cases, structural testing may fail to nd simple coding errors. 1. RTCA/DO-248A, Second Annual Report for Clarification of DO-178B "Software Considerations in Airborne Systems and Equipment Certification". RTCA, Inc., Washington, D. C., September 13,

27 Exercice 1 On suppose donné en java une fonction de tri dont le prototype est le suivant : public static void sort( int[] num ) L'exigence de test est la suivante : après un appel à sort le tableau num contient toujours les mêmes éléments, mais classés dans l'ordre décroissant. 1. Proposer des cas de tests pour cette fonction de tri. 2. Compléter les tests en supposant que la fonction est écrite comme suit. 27

28 BubbleSort public static void sort( int[] num ) { int j; boolean ag = true; // set ag to true to begin rst pass int temp; // holding variable while ( ag ) { ag = false; // set ag to false awaiting a possible swap for( j =0; j < num.length -1; j ++ ) { if ( num[ j ] < num[j +1] ) // change to > for ascending sort { temp = num[ j ]; // swap elements num[ j ] = num[ j +1 ]; num[ j +1 ] = temp; ag = true; // shows a swap occurred 28

29 Exercice 2 Même question pour l'implantation suivante des piles : class SimpleStack { private Object[] elems; private int top, max; public SimpleStack (int sz ) { max = sz ; elems = new Object[sz ]; public void push(object obj) { elems[top++] = obj; public Object pop() { return elems[- -top]; public boolean isfull() { return top == max; public boolean isempty () { return top == 0; 29

30 Exigences pour les piles Vérier que top est toujours compris entre 0 et max Vérier qu'une pile est correctement créée si sz est supérieur à 0. ::: Vérier que si on empile un objet sur une pile non pleine, la pile contient alors un élément de plus et son sommet est l'objet empilé. Vérier que si on dépile un objet d'une pile non vide, la pile contient alors un élément de moins et on retourne bien l'ancien sommet de la pile. Vérier que isfull détermine bien si la pile est pleine. Vérier que isempty détermine bien si la pile est vide. 30

31 CleanStack Spécication des piles utilisant invariant et pre/post-conditions : (top >= 0 && top <= max) */ class CleanStack { private Object[] elems; private int top, max; 31

32 (sz > (max == sz && elems!= null ) */ public CleanStack (int sz ) { max = sz ; top = 0; elems = new Object[sz ]; (top == $pre (int, top) + 1) && elems[top-1] == obj */ public void push(object obj) { elems[top++] = obj; (top == $pre (int, top) - 1) && $ret == elems[top] */ public Object pop() { return elems[- -top]; 32

33 ($ret == (top == max)) */ public boolean isfull() { return top == max; ($ret == (top == 0)) */ public boolean isempty () { return top == 0; // End MyStack 33