ND2140
ND2140
ND2140
METHODOLOG I E
Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000
P. Charpentier, Dpartement Ingnirie des quipements de travail, Centre de l'INRS-Lorraine, Nancy, N. Diette, St Surlog, 1 bis rue du Petit-Clamart, 78140 Vlizy-Villacoublay, et F. Escaffre, St CEP-Systmes/ RIdatas, 150 rue Nicolas-Vauquelin, 31047 Toulouse cedex
ND 2140-181-00
METHODOLOG I E
65 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000
P. Charpentier, Dpartement Ingnirie des quipements de travail, Centre de l'INRS-Lorraine, Nancy, N. Diette, St Surlog, 1 bis rue du Petit-Clamart, 78140 Vlizy-Villacoublay, et F. Escaffre, St CEP-Systmes/ RIdatas, 150 rue Nicolas-Vauquelin, 31047 Toulouse cedex
here is no such thing as a zero fault software.The presence of systematic software faults introduced at the design stage of a programmable device must therefore be given comprehensive and careful consideration, in particular when the consequences of these faults can influence the safety of a complex system. This article proposes a method of carrying out tests, which are the main component of software verification.The requirements to ascertain that this verification has been efficiently carried out are given in annex.To detect the maximum number of faults, testing must be carried out according to an approach that firstly defines the objectives of the tests and the strategy adopted, and secondly that demonstrates that the said objectives have been achieved.
e logiciel zro dfaut n'existe pas. La prsence de fautes logicielles systmatiques, introduites la conception d'un dispositif programm, doit donc tre considre avec beaucoup d'attention, en particulier lorsque les consquences de ces fautes peuvent influer sur la scurit d'un dispositif complexe. Cet article propose une mthode de mise en uvre des tests, qui sont la principale composante de la vrification dun logiciel. En annexe, sont prsentes les exigences qui permettent de s'assurer que cette vrification a effectivement t ralise et qu'elle savre efficace. Pour dtecter un maximum de fautes, ces tests doivent tre conduits en suivant une dmarche qui dfinit, dans un premier temps, les objectifs de tests et la stratgie adopte pour les atteindre, et qui dmontre, dans un deuxime temps, que lesdits objectifs ont t satisfaits.
ans le domaine des machines, les systmes programms peuvent tre utiliss pour traiter des informations relatives la scurit, condition de respecter les exigences de scurit qui leurs sont applicables [1]. Ils doivent, entre autres, satisfaire aux prescriptions contenues dans la norme europenne EN 954-1 [2, 3], un des points les plus dlicats traiter tant de garantir un comportement sr en prsence de fautes. En effet, il est matriellement impossible de caractriser et de prvoir toutes les fautes susceptibles daffecter ces systmes complexes [4]. Seul le recours des moyens prouvs en sret de fonctionnement (SdF), pour dvelopper le matriel et le logiciel de ces systmes, permet dobtenir en final une confiance justifie dans la scurit de ces systmes [5, 6]. Ces moyens peuvent tre rpartis en quatre catgories [7] :
La prvention des fautes. Cest lensemble des dispositions prises par le constructeur pour assurer un dveloppement matris du produit. La prvention des fautes concerne donc le processus gnral de conception du systme. La tolrance aux fautes. C'est l'utilisation de mthodes et techniques constructives destines fournir un service mme de remplir la, ou les fonctions du systme en dpit des fautes pouvant l'affecter. La tolrance aux fautes a donc une influence sur l'architecture du systme. Dans un cadre de scurit, la tolrance aux fautes se limitera lutilisation de techniques de dtection des fautes, la raction tant la mise en position de repli. Llimination des fautes. C'est lapplication, au cours de chaque phase du cycle de vie du systme, de mthodes et techniques destines rduire la prsence des fautes, en nombre et en svrit.
(*) Travaux raliss dans le cadre du Projet europen STSARCES, financ par la DG XII (Commission europenne , Direction gnrale XII - Science, recherche et dveloppement, Bruxelles, Belgique).
Llimination des fautes regroupe lensemble des techniques de vrification du matriel et du logiciel. La prvision des fautes. C'est l'valuation du comportement du systme par rapport l'apparition des fautes. Elle se base sur un ensemble de mthodes et techniques destines estimer la prsence, la cration et les consquences des fautes. La prvision des fautes est destine s'assurer que les techniques de tolrance et d'limination mises en uvre ont l'efficacit souhaite. Dans le cadre du projet europen STSARCES (1) [8], l'INRS a men des travaux, en coopration avec les socits Veridatas (aspect qualit) (2) et Surlog (aspect sret de fonctionnement), pour adapter deux techniques complmentaires de SdF aux systmes programms utiliss en scurit des machines. Ces techniques sont destines traiter les fautes logicielles systmatiques (3) affectant les logiciels systmes (4), en sattachant : prvenir ces fautes, par la dfinition d'exigences en matire de qualit et de sret des logiciels [9, 10]. Des exigences ont t formules pour proposer aux concepteurs une mthode de travail rigoureuse, dans le but de minimiser le nombre des fautes restant dans le logiciel en phase dexploitation. Ces exigences sont adaptes aux logiciels systmes dvelopps pour la scurit des machines et sont cohrentes avec la norme CEI 61508 (partie 3 Prescriptions concernant les logiciels notamment [11] ). Elles concernent : le produit logiciel, le processus de dveloppement du logiciel, la vrification du logiciel. Les moyens de vrifier que ces exigences sont effectivement respectes et efficaces ont t consigns dans le document Guide to assessing software quality and safety requirements [12]. liminer ces fautes, en proposant une dmarche de construction des tests du
(1) STSARCES : STandards for SAfety Related Complex Electronic Systems. Contrat CEE n SMT4-CT97-2191. Financement DG XII. (2) Veridatas est une entit du ple Conseil du bureau Vritas. (3) Faute logicielle systmatique : faute introduite la conception d'un logiciel, qui se rvle lorsque la partie du programme dans laquelle elle est situe est active. (4) Logiciel partie intgrante du systme, fourni par le vendeur et non accessible pour modification lutilisateur final. A distinguer du logiciel applicatif, qui est un logiciel spcifique lapplication utilisateur, dans lequel les fonctions du systme sont programmes.
logiciel. Une dmarche didactique de construction des tests du logiciel a t tudie, pour aider les concepteurs respecter les exigences formules en matire de certification et raliser ainsi des tests efficaces et suffisants. Cette seconde voie a conduit la rdaction du document Guide for the construction of software tests [13]. Cet article est dans la continuit de celui publi en 1997 dans cette revue [9], qui prsentait les exigences en matire de qualit et de sret des logiciels. Il prsente tout dabord la problmatique lie la vrification du logiciel, en focalisant sur son principal composant, c'est--dire le test. Les principales tapes de la dmarche de construction des tests du logiciel sont ensuite prsentes : dfinition pralable des tests raliser, excution des tests, vrification des rsultats de tests. Les objectifs de chaque tape sont indiqus, ainsi que les activits y exercer et les traces fournir pour aider l'analyse. Des exemples d'application illustrant certains points de la dmarche sont donns pour la construction des tests de validation. Une annexe rappelle les exigences du document [10] relatives la vrification du logiciel.
1. La vrification du logiciel
1.1. Gnralits
La vrification du logiciel a pour but de dmontrer que les produits logiciels issus d'une phase du cycle de dveloppement sont conformes aux spcifications (incluant les exigences lgales et rglementaires) tablies lors des phases prcdentes. Elle a galement pour but de dtecter et de rendre compte des fautes qui peuvent avoir t introduites au cours des phases prcdant la vrification. La vrification du logiciel est compose : des tests, partie prdominante pour les logiciels de faible taille, des activits de revues et d'analyse. Ces activits peuvent dans certains cas remplacer certains tests (exemple : un test qui ne pourrait pas tre ralis sans dtrioration d'un composant matriel).
Remarques
L'observation d'un logiciel sous test, l'analyse de l'architecture du logiciel et du codage, l'valuation du processus de dveloppement sont autant d'lments pour rpondre la question : Est-ce que le logiciel est bien fait ? . Mais, pour traiter compltement la sret de fonctionnement au niveau du systme,il faut tre galement en mesure de rpondre la question : Est-ce que le logiciel ralis correspond bien lapplication traiter ? . Seules des analyses au niveau du systme permettent de rpondre cette question, ce qui dpasse l'tude des tests du logiciel. Il faut donc insister sur le fait qu'il est illusoire de qualifier un systme complexe la seule observation de son comportement sur un nombre limit de jeux de tests. Les tests sont essentiels pour dtecter des erreurs et amliorer la confiance dans l'aptitude du systme accomplir sa mission, mais insuffisants pour qualifier le comportement d'un systme.
Il existe un risque pour le concepteur de faire dfinir par une mme entit (individu, quipe), la spcification,la conception,la stratgie de tests et les cas de tests. Deux raisons au moins justifient le recours un tiers pour tester un logiciel : le but des tests est dexcuter un programme avec lintention de trouver ses erreurs [14],ce qui constitue un processus mental non naturel, difficile mener par une mme entit ; le programme peut contenir des erreurs dues la non comprhension de limplmentation ou des spcifications par le dveloppeur [14]. Dans ce cas, il est probable que celui-ci aura ces mmes noncomprhensions quand il testera son propre programme (mode commun de dfaillance). La correction des fautes logicielles peut : injecter de nouvelles fautes et perturber des parties correctes dj testes ; rendre active une partie du logiciel jusqu'alors inaccessible et donc rvler un grand nombre de nouvelles fautes, qui ne pouvaient tre constates avant cette correction.
Spcification
Tests de validation
Conception prliminaire
Tests d'intgration
Conception dtaille
Tests unitaires
Codage
Fig. 1. Phase de dfinition des tests dans le cycle de dveloppement en V Test definition phase in the V-development cycle
Tests de validation, pour sassurer que le logiciel implant dans le matriel rpond aux spcifications fonctionnelles, en vrifiant plus particulirement les fonctions gnrales, les interfaces matriel / logiciel, le fonctionnement temps rel, les performances, l'utilisation et l'allocation des ressources. Cette dcomposition du test, relie au cycle de vie, distingue les tests de validation du logiciel de ceux du systme. Elle montre ainsi clairement quil est ncessaire de vrifier dune part, la conformit du logiciel ses exigences propres et dautre part, la conformit du systme ses exigences (les premires tant dduites des secondes). Cette distinction ne doit cependant pas conduire valider le logiciel indpendamment du matriel sur lequel il est implant.
vrification du logiciel. Il est donc recommand au concepteur du systme de prendre en compte ces exigences ds le dbut du dveloppement du logiciel. Les exigences sont classes en deux niveaux, suivant la criticit du logiciel. Ces niveaux dterminent le degr de rigueur exig pour le dveloppement du logiciel, afin d'viter les fautes dont le logiciel peut tre la cause. Le processus de classification pour fixer le niveau des exigences au logiciel ncessite une valuation spcifique de chaque systme (cf. chap. A.1 de l'annexe I). La dmonstration du respect de toutes les exigences applicables au logiciel valuer doit tre faite par le concepteur du systme. Chacune de ces exigences lmentaires doit faire l'objet d'une rponse approprie, soit par l'intermdiaire des documents produits, soit par l'intermdiaire des activits conduites pour dvelopper le logiciel et dont les traces auront t conserves pour valuation. Il est par exemple important de noter qu'une activit de test qui serait ralise de faon informelle, par exemple l'aide d'un analyseur logique sans aucune trace papier ou informatique, ne constitue pas une preuve de test. Ceci n'empche pas le concepteur de mener cette activit si elle lui est ncessaire dans une phase spcifique de mise au point.
Dfinir ces objectifs permet de raliser les tests avec un maximum d'efficacit en garantissant la couverture des objectifs dfinis, donc de focaliser les efforts sur les aspects essentiels. Les objectifs de tests de chaque phase de tests seront identifis et dfinis en considrant : les exigences fonctionnelles et de performance (en tenant compte aussi des contraintes particulires de lenvironnement final dutilisation du logiciel), exprimes dans les documents de spcification / conception du produit logiciel ; les exigences en matire de qualit et de sret de fonctionnement (rectitude, robustesse, maintenabilit, disponibilit, scurit...) ; toutes les contraintes identifies d'implmentation (utilisation d'une base de donnes, utilisation des nombres rels, langage de programmation, logiciel temps rel) ; les exigences lgales et rglementaires ; les contraintes de cot et de temps de test. Il en rsulte la dfinition des types de tests raliser (chemins structurels, chemins fonctionnels, donnes d'entres sorties aux limites, hors limites, de robustesse, de performance...) et la justification de ces choix.
Attention ! Fixer a priori un objectif en terme de taux de couverture peut conduire le concepteur dgrader son code pour atteindre plus facilement les objectifs. Une valeur de 100 % pour un taux de couverture en branches ou en appels de fonctions peut tre obtenue en diminuant artificiellement le nombre d'appels de procdures par duplication du code ou allongement de la taille moyenne des procdures. Toute dmarche d'objectif de taux de couverture doit donc tre accompagne de rgles de programmation vitant ce type d'effet pervers.
Taux de couverture Pour chaque type de tests dfini, l'exigence sur le taux de couverture des tests atteindre est de 100 %.
Exemple
2.1.1. Objectifs de tests Dfinition des objectifs Dans labsolu, leffort de test (validation, intgration et unitaire) dun logiciel peut tre aussi important que lon veut. La combinatoire des donnes dentre, des modes dutilisation, des modes de fonctionnement, des paramtres dexploitation, la varit des aspects vrifiables (conformits aux spcifications, aux manuels dutilisation et dexploitation, aux exigences de robustesse, de performance, dergonomie, comportement nominal, en cas de dfaillance, etc.) sont telles quune infinit de tests peut tre mene sans quon soit certain de la conformit totale aux exigences.
En pratique, leffort de test doit donc tre adapt aux enjeux. Il ncessite de se fixer des objectifs pralablement toute dfinition dune stratgie, de mthodes et techniques, etc., et finalement des tests eux-mmes.
Si le choix de tester les chemins fonctionnels est retenu, un taux de couverture de 100 % signifie qu'aprs ralisation des tests, chacun des chemins fonctionnels du logiciel doit avoir t parcouru au moins une fois. Il est bien sr ncessaire d'avoir les moyens de mesurer le taux de couverture rel obtenu pour le comparer au taux de couverture souhait (ici, de 100 %). Mais ce taux peut tre rduit par des hypothses justifier : Il se peut par exemple, lors des tests de validation site , que le logiciel soit dans un environnement particulier, empchant le test de certaines fonctionnalits prvues pour un environnement diffrent. Le taux de couverture ne pourra donc pas atteindre 100 % des fonctionnalits dcrites dans les spcifications. La justification de la diminution du taux de couverture devra tre consigne dans le dossier de test. De mme, certains tests portant sur les aspects temps rel ne sont pas toujours ralisables en tests unitaires. Une justification adapte permettra de limiter le taux de couverture des aspects temps rel durant la phase de tests unitaires.
Dfinition des procdures de test Selon lexigence 11 : Les directives pour la rdaction des procdures de test doivent comprendre la description des jeux de donnes d'entre appliquer, la description des sorties attendues et les critres d'acceptation des rsultats des essais , la dfinition des procdures de tests est exige pour le niveau 2 et recommande pour le niveau 1 (cf. chap. A.3 de l'annexe). Un processus de test correctement mis en uvre implique que les procdures de test soient ralises le plus en amont possible dans le cycle de dveloppement. Cette remarque est particulirement importante dans le cadre de lvaluation. En effet, le valideur comme le concepteur auront toujours intrt ce que ces procdures soient values avant leur drou-
lement plutt quaprs, ce qui vite de remettre en cause la phase correspondante de test et permet lvaluateur de ne pas concevoir de tests complmentaires lors de lvaluation finale. Il est ncessaire que ces procdures contiennent toutes les informations ncessaires : leur identification et leur traabilit vis--vis des objectifs et/ou de la stratgie ; lexcution du test pendant la phase (activits de prparation, de droulement des tests, d'enregistrement des anomalies et critre d'arrt des tests).
TABLEAU I
PRODUITS ISSUS DE LA DFINITION DES TESTS PRODUCTS STEMMING FROM THE TEST DEFINITION
Livrable thorique
Planification des tests
Contenu
Objectifs, stratgie, techniques et mthodes, organisation et responsabilits, moyens ncessaires, identification des tests et dmonstration de couverture. Description dtaille de chaque test en termes de mode opratoire, de donnes dentre, de rsultats attendus et de critres darrt.
Procdures de tests
Mthodes et techniques de test : techniques de base Les techniques de base sont rparties en deux catgories suivant qu'elles autorisent ou non l'observation du comportement interne du composant logiciel sous tests [16] : bote noire ou test fonctionnel : pas de visibilit du composant sous test, les entres et les rsultats attendus sont exprims en terme de comportement du composant logiciel dun point de vue externe, sans se soucier de la structure interne du composant ; bote blanche ou test structurel : visibilit du composant sous test, les jeux de test sont produits en analysant le code source. Moyens de test Quel que soit le niveau dexigence, la dfinition de la stratgie et des mthodes de test doit saccompagner de la dfinition des moyens ncessaires pour les mettre en uvre. Labsence de cette information diminue fortement la crdibilit de la stratgie et des mthodes envisages.
A titre dexemple, la liste ci-dessous fournit des moyens auxquels il faut penser au pralable : outils : simulateurs, comparateurs, outils de mesure des signaux, outils de test, etc., environnements de test : configurations diffrentes du systme, en usine, sur site, ventuellement variable en fonction du paramtrage, etc., jeux dessai prenregistrs, tables prdfinies de paramtres, etc. En particulier, pour les tests unitaires, la dfinition dune stratgie au plus tt impose lutilisation doutils adapts la taille du logiciel. Ces outils automatisent lexcution (et la rxcution ventuelle) des tests et la mesure des taux de couverture.
2.1.4. Exemples de tests de validation Objectifs de test A priori, en validation, on doit se fixer comme objectif de couvrir chaque lment de spcification, y compris les mcanismes de scurit. En ce qui concerne ces mcanismes, lvaluateur devra sassurer (EN 954-1 [2]) quau minimum les objectifs couvrent : les fonctions de scurit spcifies ; les comportements attendus pour la catgorie spcifie ; les aspects dimensionnement et paramtrage. De plus, il doit tre possible de vrifier le comportement temps rel du logiciel dans tous les modes oprationnels.
Mthodes et techniques de test Quel que soit le niveau dexigence, des tests fonctionnels (en bote noire ) doivent tre raliss dans la phase de validation. En rgle gnrale, il ne doit pas y avoir de tests en bote blanche pour les raisons suivantes : les tests de validation doivent vrifier la conformit aux spcifications, donc une dfinition du compotrtement du logiciel dun point de vue externe ; la validation doit tre ralise sur le systme intgr, donc en rgle gnrale, avec peu de visibilit sur le comportement interne du logiciel. Lorsque le concepteur prvoit dutiliser des mthodes de type bote blanche , il faut dmontrer quil y a un rel avantage observer le comportement interne du logiciel pendant cette phase et que ces observations ne peuvent pas tre ralises dans les phases prcdentes. Le cas chant, il peut tolrer lutilisation de cette technique si des tests en bote noire existent et couvrent les spcifications fonctionnelles (ces tests peuvent ventuellement comporter aussi des aspects bote blanche ).
Les principales techniques de base utilisables en validation sont [13] : les tests aux limites de valeur (vrification du comportement du logiciel aux limites des domaines de dfinition des donnes dentre) ; les tests de domaine (contrle que les donns de sorties correspondant aux diffrentes classes dquivalence dfinies sont conformes aux spcifications). Ces techniques de base peuvent tre compltes par dautres techniques : moins formelles, comme les tests par intuition (recherche derreurs base sur lexprience) ; plus formelles, pour les hauts niveaux dexigence comme les tests bass sur des graphes de cause effet (identification, partir dun graphe reprsentant les relations logiques, des cas de tests qui ont une grande probabilit de dtecter des fautes) ou les tests bass sur des automates tats finis (gnration des ensembles de tests pour vrifier que le programme est conforme ses spcifications fonctionnelles) ; ncessitant un outillage spcifique pour des objectifs particuliers, par exemple axs sur la mesure de fiabilit, comme les tests alatoires (vrification du logiciel par la gnration de donnes alatoires issues de lensemble des tests possibles).
Cependant, ou bien ces techniques ne sont pas simples mettre en uvre (tests bass sur les graphes de cause effet ou sur les automates tats finis), ou bien la dmonstration de la couverture obtenue reste difficile tablir (tests par intuition, tests alatoires).
Produits Les livrables issus de la dfinition des tests de validation devront contenir les informations dtailles dans lencadr 1.
ENCADRE 1
Contenu des produits issus de la dfinition des tests de validation Content of the products stemming from the definition of the validation tests
Organisation, responsabilits
Personnes impliques dans la validation. Organisation. Responsabilits.
Stratgie de tests
Dmarche retenue, avec ordonnancement en tapes visant des objectifs spcifiques ou sappuyant sur des environnements ou des techniques spcifiques, par exemples : Test de tel groupe de fonctions ; test de tel mode de fonctionnement ; Test denchanement de telles fonctions, tests de bout en bout ; tests de paramtrage ; Tests dendurance ; tests avec simulation dans tel environnement, etc.
TABLEAU II
TABLE DE TRAABILIT : OBJECTIFS - TYPES DE TESTS - NUMROS DE TESTS TRACEABILITY TABLE: OBJECTIVES TYPES OF TESTS TEST NUMBERS
Objectif lmentaire vrifier
Objectif 1 Objectif 2 Objectif 3 Objectif 4 Objectif Objectif n
TN
1, 2 6 7, 8 m
m+1
TN : Test Nominal, THL : Test Hors Limite, TR : Test de Robustesse. 1, 2,..., m, m+1 : numros des tests. TABLEAU III
PRODUITS ISSUS DE LEXCUTION DES TESTS PRODUCTS STEMMING FROM EXECUTION OF THE TESTS
Livrable thorique
Rapport de tests
Contenu
Conditions de ralisation des tests, lments tests, tests excuts, rsultats obtenus, interprtation des rsultats et bilan.
tre considr dans la dfinition de ce critre. Cela peut tre la dcouverte d'un bug ou encore, d'une non-conformit majeure. La dtection d'un vnement constituant le critre d'arrt des tests va entraner l'arrt du groupe de tests en cours avant son terme et le passage au groupe de tests suivant. Le groupe de tests arrt sera raliser nouveau aprs correction.
ENCADRE 2
Contenu des produits issus de lexcution des tests de validation Content of the products stemming from execution of the validation tests
Remarques la dure des tests et les efforts engags ne sont, en aucun cas, des critres d'arrt des tests : aucune garantie sur le logiciel ne peut tre tablie sur ces seules observations. La diminution du nombre d'erreurs constates par unit de temps n'est pas non plus un critre d'arrt. Elle rsulte souvent de la difficult,pour l'quipe de tests, de trouver de nouveaux tests pour mettre en vidence des dfaillances.La modification de l'quipe de tests, ou la mise en place de nouveaux outils, augmente souvent le nombre d'erreurs dtectes. Seule la non-diminution doit tre prise en compte comme un lment bloquant pour l'valuation. Les mesures de taux de couverture pourraient tre un critre d'arrt s'il tait possible d'valuer la probabilit de prsence de fautes non dtectes. Elles seront cependant prises en considration comme un des lments de l'valuation.
Mode opratoire
Suite des actions raliser pour mener le test.
Critres de russite
Implicitement, lobtention des donnes et/ou signaux attendus est un des critres. Ce critre doit tre complt lorsque ncessaire par dautres critres, par exemples : temps de rponse, tolrance sur les valeurs en sortie, absence ou occurrence de tel vnement avant tel laps de temps.
En fait, l'arrt des tests se fait suite l'analyse des vnements redouts au niveau systme et des aspects qui ne sont couverts par aucune des tapes de tests. De cette analyse, on dduit si le risque li cette non-couverture est acceptable et conforme aux exigences applicables.
Essais raliss
Peuvent tre fournis par rfrence aux procdures de tests. A complter par les carts au plan de test, le cas chant (tests non excuts).
Faits marquants
cart lordonnancement prvus, abandons de certains tests, etc.. Peut faire lobjet dun document spar dit journal de test .
Evaluer le taux de couverture atteint par analyse des rsultats de tests. Etablir l'acceptation ou le refus des rsultats de la phase, en prenant en compte les justifications de divergences tablies lors de l'excution des tests.
Relations avec la gestion de configuration et des modifications Lors de la vrification,la gestion de configuration et des modifications doit permettre de sassurer que les tests ncessaires ont effectivement t raliss : conformment ce qui tait prvu (cest--dire par rapport une version rfrence des documents de planification de test et de dfinition des tests) ; sur la version de logiciel sur laquelle porte le processus d'valuation.
La vrification du logiciel est un des moyens qui doit obligatoirement tre mis en uvre pour traiter ce problme et viter l'introduction de fautes. Les exigences prsentes en annexe permettent de s'assurer que cette vrification a effectivement t ralise et qu'elle est efficace. Les tests sont la composante principale de la vrification. Pour dtecter un maximum de fautes, ces tests doivent tre conduits en suivant une dmarche qui dbute par la dfinition pralable des objectifs de tests et de la stratgie adopte pour atteindre ces objectifs, pour finir par la dmonstration que ces objectifs sont satisfaits. La rflexion induite par cette dmarche impose au concepteur d'apprhender le processus test dans sa globalit, sans se focaliser sur la seule phase d'excution. Cette rflexion constitue une condition pralable indispensable pour russir les tests d'un logiciel (en termes d'efficacit de dtection) et minimiser ainsi les risques d'apparition de dfaillances dangereuses en exploitation.
C ONCLUS I ON Le logiciel zro dfaut n'existe pas. La prsence de fautes logicielles systmatiques introduites la conception d'un dispositif programm doit donc tre considre avec beaucoup d'attention, en particulier lorsque les consquences de ces fautes peuvent influer sur la scurit d'un dispositif.
BIBL I OGRAPHI E
1. Directive 98/37/CE du 22 juin 1998 relative au rapprochement des lgislations des tats membres relatives aux machines. Journal Officiel des Communauts Europennes, n L. 207 du 23 juillet 1998, pp. 1-46. 2. EN 954-1 Scurit des machines. Parties des systmes de commande relatives la scurit. Partie 1 : Principes gnraux de conception. Paris - La Dfense, AFNOR, juil. 1996, 46 p. 3. VAUTRIN J.P., CHARPENTIER P., VIGNERON C. La scurit en machinerie. Introduction au concept de catgorie. Cahiers de Notes Documentaires Hygine et scurit du Travail, 1996, 163, Points de repre, pp. 255-262. 4. Mode de dfaillance des circuits intgrs : constats des problmes poss. Nanterre, Institut de Sret de Fonctionnement, , Document interne (groupe de travail MDCI), 1994, 15 p. 5. CICCOTELLI J., BUCHWEILLER J.P. Analyse et certification des composants de scurit machines. In : 10e colloque national de fiabilit et de maintenabilit (actes). Saint-Malo, oct. 1996, pp. 10881102. 6. GEOFFRY J.C., MOTET G. Sret de fonctionnement des systmes informatiques. Paris, Inter Editions, 1998, 349 p. 7. LAPRIE J.C. Guide de la sret de fonctionnement. Toulouse, ditions Cpadus, mai 1995, 324 p. 8. Projet europen STSARCES Mthodes de validation du niveau de scurit des systmes lectroniques. 4e PCRD. Contrat n SMT4-CT97-2191, nov. 1997, 28 p. 9. CHARPENTIER P., MENAGER P. L'vitement des fautes logicielles par la qualit. Cahiers de Notes Documentaires - Hygine et scurit du Travail, 1997, 167, ND 2049, pp. 249-259. 10. STSARCES Project (n SMT4-CT97-2191) Software quality and safety requirements. WP 1.2/1a Final Report. Nancy, INRS, dc. 1999, 35 p. 11. CEI 61508 Scurit fonctionnelle des systmes lectriques, lectroniques, lectroniques programmables relatifs la scurit. Parties 1 7. Genve, CEI, 1998. 12. STSARCES Project (n SMT4-CT97-2191) Guide to evaluating software quality and safety requirements. WP 1.2/1b Final Report. Nancy, INRS, dc. 1999, 80 p. 13. STSARCES Project (n SMT4-CT97-2191) Guide for the construction of software tests. WP 1.2/2 Final Report. Nancy, INRS, dc. 1999, 50 p. 14. MYERS G.J. The art of software testing. New York, John Wiley & Sons, 1979, 177 p. 15. BEIZER B. Software testing techniques, 2e d. Boston, International Thomson Computer press, 1992, 549 p. 16. XANTHAKIS S., MAURICE M., DE AMESCUA A., HOURI O., GRIFFET L. Test et contrle des logiciels. Nanterre, Editions EC2, 1994, 341 p.
ANNEXE I
Cette annexe reprend les exigences contenues dans le projet STSARCES [10].
Classification du logiciel : le produit logiciel destin assurer les (ou certaines) fonctionnalits du systme tant dfini, il s'agit de dterminer le niveau d'exigences fixer en fonction de la classification du systme. De mme que pour les aspects systme, certaines dcisions d'architecture du systme ou de conception des logiciels sont prendre en considration afin de dterminer si elles affectent le niveau d'exigences logiciel retenu. Par exemple, les logiciels versions multiples dissimilaires (ou programmation N-versions ), technique de conception qui consiste raliser deux ou plusieurs composants logiciels assurant la mme fonction d'une manire pouvoir viter certaines sources d'erreurs communes (introduction d'une htrognit par programmation par des personnes diffrentes, utilisation de langages diffrents,...), permettent de limiter l'impact des erreurs ou de dtecter les dfauts.
Facteurs d'ajustement
Classification du systme
Niveau d'intgrit du systme
Classification du logiciel
Fig. A-1. Processus de dtermination du niveau de criticit dun logiciel - Process of determining the software criticality level
TABLEAU A-I
VERIFICATION REQUIREMENTS
Exigences gnrales de vrification
L'valuation de la conformit du logiciel aux prsentes exigences doit pouvoir tre ralise par l'analyste en procdant au cours des phases du dveloppement tous les audits ou expertises jugs utiles. Tous les aspects techniques des processus du cycle de vie logiciel sont sujets valuation par l'analyste. Tous les rapports de vrification (tests, analyses...) ainsi que les documents techniques utiliss durant le dveloppement du logiciel doivent pouvoir tre consults par l'analyste. L'intervention de lanalyste ds la phase de spcification est prfrable une intervention a posteriori pour limiter l'impact des dcisions. Les aspects financiers ou humains du projet ne sont pas sujets valuation. L'intrt du postulant est d'apporter tous les lments de preuves sur les activits qu'il a men pendant le dveloppement du logiciel. Lanalyste doit disposer de tous les lments ncessaires pour formuler un avis.
Niv. 1 E
Niv. 2 E
L'valuation de la conformit du logiciel aux prsentes exigences est faite pour une version spcifique et rfrence du logiciel. Toute modification d'un logiciel prcdemment valu et ayant donn lieu avis final de l'analyste doit tre signale ce dernier en vue d'une concertation sur les activits d'valuation complmentaires ncessaires pour ractualiser l'avis. Toute modification est susceptible de modifier le comportement d'un logiciel, l'avis ne peut donc porter que sur une version prcise du logiciel.
Un rapport de vrification doit tre tabli pour chaque activit de vrification et doit identifier et documenter toutes distorsions (non-conformits) par rapport : - aux spcifications correspondantes, - aux rgles ou normes (conception, codage...), - aux procdures d'assurance qualit, s'il y a lieu. L'objectif de cette exigence est d'enregistrer les non-conformits identifies afin de toutes les corriger (soit immdiatement s'il s'agit de non-conformits inacceptables d'un point de vue fonctionnel ou de la scurit, soit ultrieurement, sur une autre version du logiciel, s'il s'agit d'une non-conformit mineure).
No 4
Niv 1 C
Niv. 2 E
Les revues internes permettent au concepteur de s'assurer, des points cls de l'avancement du dveloppement, que le produit atteindra ses objectifs. Cf. tableau A-I : exigences nos 4 7.
Les activits d'analyse et de vrification de la conception du logiciel doivent vrifier la conformit avec les spcifications du logiciel. L'objectif est d'assurer la cohrence entre la spcification et la conception (prliminaire et dtaille) du logiciel.
Une revue externe (avec lanalyste) de validation doit se tenir en fin de phase de validation du logiciel. Elle permet de savoir si le produit rpond ses spcifications. Si la validation du logiciel est sans rserve, le dveloppement est clos.
Niv. 1 E
Niv. 2 E
No
Niv. 1
Niv. 2
Cette vrification correspond la premire tape de vrification du code aprs son criture. Il s'agit d'une vrification statique , c'est dire base d'inspections, lectures croises, etc. C'est ensuite que seront ralises les tapes de vrification dynamique (tests unitaires, intgration, validation) qui constitueront le principal moyen de vrification. Ces vrifications comprennent des vrifications du code et des donnes. Cf. tableau A-I : exigence n 8.
La vrification du code (analyse statique) doit assurer que le code est conforme aux documents de conception du logiciel ; aux rgles de codage. Cette exigence a pour objectif que la conception est mise jour et cohrente avec le code (source et donnes).
TABLEAU A-II
Il est important, avant d'crire les premires fiches de tests, de dcrire, dans un Plan de tests, une stratgie de tests indiquant la dmarche retenue, les objectifs que l'on se donne en termes de couverture de tests, les environnements et techniques spcifiques qui seront utiliss, les critres de succs de test... Les objectifs de tests doivent tre adapts au niveau d'intgrit de sret du logiciel, au type de logiciel, aux enjeux que le logiciel reprsente... ; en fonction de ces critres, on pourra dduire les types de tests raliser : tests fonctionnels, tests aux limites, tests hors limites, tests de performance, tests en charge, tests de pannes des quipements externes, tests de la configuration..., ainsi que l'ensemble des objets devant tre couverts par les tests : tests des modes de fonctionnement, test des fonctions de sret, test de chaque lment de spcification... Cf. tableau A-II : exigences nos 9 12, page suivante)
Niv. 1 E
Niv. 2 E
11
Les directives pour la rdaction des procdures de test doivent comprendre : - la description des jeux de donnes d'entre appliquer (valeur), - la description des sorties attendues (type, valeur), - les critres d'acceptation des rsultats des essais (tolrance...). Cette exigence implique que les tests raliss seront documents (sous un formalisme dfinir par le concepteur). Cette documentation des tests permet d'optimiser les tests raliss (ne pas rejouer plusieurs fois le mme test) et de pouvoir rejouer ces tests ultrieurement (en tests de non-rgression d'une nouvelle version du logiciel ou pour un autre projet similaire, pour lequel des ensembles logiciels sont rutiliss).
12
Les tests formaliss par un compte rendu doivent pouvoir tre rejous (en prsence de lanalyste). Certains essais, ncessitant certains moyens spcifiques, peuvent cependant n'tre rejouables qu'avec un pravis suffisant. Cette exigence donne la possibilit l'analyste de s'assurer de la ralit de l'exactitude de tous les tests prsents lors de l'valuation.
N 13
Niv. 1 E
Niv. 2 E
Les tests de validation sont la composante principale de la vrification des spcifications du logiciel. Cf. tableau A-II : exigences nos 13 et 14.
14
Les rsultats de la validation doivent tre enregistrs dans un rapport de validation qui doit contenir a minima : - la version du logiciel et du systme objet de la validation, - la description des essais de validation raliss (entres, sorties, procdures d'essai), - les outils et les quipements utiliss pour effectuer la validation ou valuer ses rsultats, - les rsultats permettant d'tablir si chaque essai de validation a abouti ou chou, - le bilan de la validation : non-conformits identifies, impact sur la scurit, dcision d'acceptation ou de refus de validation. Un rapport de validation doit tre disponible pour chaque version de logiciel livre et doit correspondre la version finale de chaque logiciel livr. L'existence de ce rapport permet d'apporter la preuve que les essais ont t jous et donnent des rsultats corrects (ou comportent des carts expliqus). Il permet aussi de rejouer ultrieurement ces tests pour une version ultrieure du logiciel ou pour un autre projet.
Niv. 1
Niv. 2
N 15
Niv. 1 C
Niv. 2 E
L'objectif de cette vrification est centr sur le bon assemblage des modules et sur les relations mutuelles entre les composants logiciels. Elle permet de rvler les erreurs du type : initialisation incorrecte des variables et des constantes, erreurs dans le passage de paramtres, altration de donnes, en particulier de donnes globales, rsolution numrique de bout en bout inadquate, squencement incorrect d'vnements et d'oprations. Les tests d'intgration du logiciel sont la composante principale de cette vrification. Cf. tableau A-II : exigences nos 15 17.
16
Les modifications du logiciel, ralises durant l'intgration du logiciel, doivent tre analyses pour identifier l'impact sur les modules concerns et la ncessit ventuelle de ritrer certaines vrifications. Tous les tests raliss doivent tre reprsentatifs du logiciel final. Une modification du code en cours d'essais peut invalider les rsultats d'essais antrieurs.
17
Les rsultats de l'intgration doivent tre enregistrs dans un rapport de test d'intgration du logiciel, qui doit contenir a minima : - la version du logiciel intgr, - la description des tests raliss (entres, sorties, procdures), - les rsultats des tests d'intgration et leur valuation.
N 18
Niv. 1 /
Niv. 2 C
19
Les rsultats des essais du module doivent tre consigns dans un rapport comprenant a minima : - la version du module en essai, - les entres appliques, - les rsultats attendus et obtenus, - l'valuation des rsultats (essai positif ou non). L'objectif est d'assurer que chaque module est vrifi dans sa dernire version et que l'essai sera reproductible (au titre de la non-rgression par exemple).
L'objectif des tests unitaires est centr sur le module logiciel et sa conformit par rapport la conception dtaille. Cette activit, indispensable pour des logiciels complexes et de taille importante, est seulement conseille pour les logiciels de petite taille auxquels s'adresse le prsent document. Cette conformit peut galement tre dmontre par des techniques statiques (relecture de code par exemple). Cette phase de vrification permet de rvler les erreurs du type : inaptitude d'un algorithme satisfaire une spcification du logiciel, oprations de boucle incorrecte, dcision logique incorrecte, inaptitude traiter correctement des combinaisons valides de donnes d'entres, rponses incorrectes des donnes d'entres manquantes ou altres, violation de limites de tableaux, squence de calcul incorrecte, prcision, justesse ou performances inadquates d'un algorithme. Cf. tableau A-II : exigences nos 18 et 19.
INSTITUT NATIONAL DE RECHERCHE ET DE SCURIT - 30, rue Olivier-Noyer, 75680 Paris cedex 14
Tir part des Cahiers de notes documentaires - Hygine et scurit du travail, 4e trimestre 2000, n 181 - ND 2140 - 1 200 ex. N CPPAP 804 AD/PC/DC du 14-03-85. Directeur de la publication : J.-L. MARI. ISSN 0007-9952 - ISBN 2-7389-0875-6
JOUVE - Paris