ND2140

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 16

ND 2140-181-00

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

Comment construire les tests d'un logiciel

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

Comment construire les tests d'un logiciel (*)

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.

logiciel faute test mthodologie informatique

software fault test methodology

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).

66 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

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.2. Le test du logiciel


Le test du logiciel [14 16] est une approche dynamique de la vrification, destine s'assurer que ce logiciel possde effectivement les caractristiques requises pour son contexte d'utilisation. La premire action entreprendre est donc de dcrire avec prcision ce contexte, en particulier les fonctionnalits attendues, les contraintes d'environnement, ou encore les situations dangereuses considrer. Le test a pour objectifs : 1. De dtecter d'ventuels carts entre le comportement attendu et le comportement observ au cours des tests, ce qui limine un grand nombre de fautes prsentes dans le logiciel. 2. D'obtenir la confiance ncessaire avant l'utilisation oprationnelle. Il faut cependant noter que le nombre de fautes dtectes ne peut pas tre considr comme un critre de russite des tests. Le retour d'exprience montre en effet qu' complexit technique et industrielle constante, un grand nombre d'erreurs dtectes par rapport dautres projets de rfrence peut seulement tre interprt comme l'indicateur d'un logiciel contenant un trs grand nombre de fautes et non comme l'atteinte d'un bon taux de dtection des fautes prsentes. Il est donc trs difficile d'avoir confiance en un logiciel ayant un grand nombre de fautes dtectes par le test.

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.

67 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

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.

Plan de Test de Validation du logiciel et procdures associes

Spcification

Tests de validation

Conception prliminaire

Plan de Test d'Intgration du logiciel et procdures associes

Tests d'intgration

Conception dtaille

Plan de Test Unitaires et procdures associes

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

1.3. Les diffrents tests du logiciel


Les tests doivent tre mens diffrents niveaux du dveloppement dun logiciel. En suivant le cycle en V de dveloppement du logiciel (fig. 1), ils se dcomposent en : Tests unitaires, pour dmontrer que chaque module effectue toute la fonction prvue et seulement cette fonction. On peut distinguer dans ces tests unitaires : les tests de logique (recherche d'erreur, vrification de l'enchanement correct des branches parcourues) ; les tests de calcul (vrification des rsultats des calculs, des performances, de l'exactitude des algorithmes). Typiquement, les tests de calcul comprennent les tests de donnes dans les limites des spcifications (tat normal), aux limites spcifies et en dehors de ces limites (tat anormal). Les tests de comportements anormaux (hors limites, erreurs) sont gnralement appels tests de robustesse. Tests dintgration du logiciel, pour dmontrer le bon fonctionnement d'units fonctionnelles constitues d'un assemblage de modules. Ils portent principalement sur la vrification des enchanements entre modules, la circulation des donnes, les aspects dynamiques, les squences d'vnements prvus et les reprises en cas d'interruption.

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.

1.4. Exigences pour la vrification du logiciel


Les exigences satisfaire pour la vrification du logiciel, qui portent sur les activits de revues et d'analyse ainsi que sur le test, sont prsentes en annexe I. Leur respect limite le nombre des fautes introduites dans un logiciel. Elles servent dfinir, vis--vis d'un concepteur, des rsultats obtenir pour toutes les activits techniques lies la

68 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

2. La dmarche de construction des tests du logiciel


Ce chapitre propose une dmarche pour tester efficacement un logiciel. Son suivi facilitera le respect des exigences formules en annexe I et permettra dviter au maximum lintroduction de fautes au sein dun logiciel. Les activits lies aux trois phases de tests dcrites au 1.3 sont identiques. Le processus de test, pour qu'il soit de qualit, doit suivre les mmes principes que tous les autres processus de ralisation ou de cration, cest--dire : dfinition au pralable des tests raliser, excution selon des procdures prvues, vrification selon des modalits fixes.

2.1. Dfinition pralable des tests raliser


Les tests se prparent ds la phase de spcification - conception correspondante. Leur dfinition fait l'objet des plans de tests (de validation, d'intgration, unitaires). Elle ncessite la rdaction de procdures associes. La figure 1 prsente, pour un cycle de vie en V , les phases de dfinition des tests.

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.

2.1.2. Stratgie de test


Quel que soit le niveau dexigence, les tests doivent tre conus et raliss sur la base dune stratgie. Elle constitue un pralable ncessaire llaboration des tests et la conception des jeux dessai. La stratgie de test tmoigne d'une rflexion sur les tests. Son absence indique un risque dimprovisation dans llaboration des tests. La stratgie doit dfinir comment, globalement, les tests vont tre mens pour satisfaire aux objectifs pralablement dfinis, en relation avec les environnements que le concepteur compte mettre en uvre. Elle doit organiser les tests en une structure lisible dtapes, ayant des objectifs clairs ou rpondant des contraintes denvironnement prcises (par exemple, relatives la disponibilit dun outil). On dfinit donc les mthodes et les moyens de tests pour y parvenir, puis l'enchanement - ou planification - des tches de ralisation des tests. L'ensemble des moyens de tests et de la planification constitue la stratgie de test mise en uvre. La dfinition des tests aboutit la ralisation des fiches de tests.

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-

69 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

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.3. Produits issus de la dfinition des tests


Les produits d'une phase de test (ou livrables) sont des documents ou des rsultats sous forme informatique (fichier texte, objets d'un atelier de gnie logiciel) observables comme preuve d'une activit du processus de test. Outre les variations de cycle de vie entre les diffrents projets, il peut y avoir des diffrences plus ou moins importantes sur le nom et la rpartition des informations entre ces livrables. Les livrables pourraient mme ne pas exister. Les noms des livrables sont donc donns titre indicatif, avec une courte description de leur contenu : ils doivent tre considrs comme des livrables thoriques , qui sont disponibles ds que le concepteur peut fournir les informations qui les dfinissent. On vrifiera donc la prsence des informations utiles et leur pertinence, plutt que leur rpartition dans une arborescence documentaire thorique . Le tableau I donne le contenu souhait pour les produits issus de la dfinition des tests.

Dfinition de la procdure des tests de validation


Pour montrer ce que peut tre une stratgie de test de validation (une stratgie spcifique est laborer pour chaque contexte spcifique, et pour un contexte donn, il existe n stratgies possibles), la liste ci-dessous fournit des exemples dtapes typiques. Ces tapes sont lies aux types de tests ainsi qu'aux contraintes de mise en uvre des tests (banc de test, environnement) : une tape de test dtaill pour chaque fonction en nominal ; une tape de test dtaill pour chaque fonction aux limites ; une tape de test dtaill pour chaque fonction hors limites ; une tape de test de performance ; une tape vrifiant le comportement en cas de dfaillance ; une tape consacre au paramtrage ; des tapes avec des entres simules et des tapes avec des entres relles du milieu oprationnel ; des tapes usine et des tapes sur un site oprationnel. La stratgie doit sintgrer dans la stratgie densemble de vrification du logiciel. En pratique, il arrive que les essais ne couvrent pas totalement les objectifs fixs, par exemples : - parce que certains dfauts ou certains modes de dfaillance ne peuvent pas tre simuls, ou - parce que certains tats ne sont jamais atteints dans lenvironnement du systme. La stratgie doit alors montrer quelles sont les vrifications complmentaires qui seront menes pour que le risque de nonconformit soit amen un niveau raisonnable, par exemple : renforcement de certains tests en phase de tests unitaires ou dintgration, contrles thoriques, analyse de comportement sur la base de schmas ou de modles.

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.

70 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

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).

2.2. Excution des tests


L'excution des tests doit se conformer aux procdures et aux conditions dfinies pralablement dans les plans de test et les fiches de test (activits de prparation, de droulement des tests, d'enregistrement des anomalies). Tout non-respect de celles-ci doit tre argument, ce qui permettra, lors de la vrification des tests, de justifier ces divergences.

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.

Objectifs gnriques des tests


Par exemple : Couverture de toutes les fonctions ; de tous les modes de fonctionnement ; des exigences de sret en cas de dfaut ; des exigences de performances ; Conformit la documentation dutilisation, dexploitation ; Vrification dendurance, etc.

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.

Mthodes et techniques de tests


Mthodes et techniques utilises, par exemple : techniques manuelles ou automatiques, analytiques ou statistiques, tests de domaines, tests aux limites, etc.

Environnements et outils de tests


Identification des outils de tests utiliss (simulateurs, outils de mesures, comparateurs, etc.). Si lenvironnement du logiciel nest pas le mme dans les diffrentes tapes, description de chacun de ces environnements.

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

Types de tests THL TR


4, 5 3 9

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.

71 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

2.2.1. Table de traabilit


Il est souhaitable d'tablir une table de traabilit lors de lexcution des tests, pour dmontrer : que les tests rfrencs par la table sont bien documents par une procdure ; quil nexiste pas de tests qui ne soient pas rfrencs par la table. Les tables de traabilit fournissent une correspondance entre les tests raliss et les objectifs dfinis pour ces tests. Le

tableau II prsente un format possible de table de traabilit.

2.2.2. Critre darrt des tests


Le critre d'arrt des tests traduit la politique retenue concernant la poursuite des tests sur dtection d'anomalie. Il doit tre dfini au pralable pour viter de raliser des tests inutiles, qui seront de toute faon rejouer. Tout vnement bloquant pour la suite correcte du processus de test, doit

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

Objectifs des tests


Doivent tre dfinis en tenant compte de la rfrence (identification des exigences, paragraphe dun document, etc.)et forment une partie des objectifs gnraux de la planification des tests.

Environnements et outils de tests utiliss


Peut tre fourni par rfrence la documentation de dfinition des tests. A complter par les informations concernant ltalonnage des appareils de mesure (donnes de calibration), le cas chant, et par les carts au plan de test.

Donnes et / ou signaux en entre


A fournir avec leur squencement et leur valeur. Si les tests sont automatiss, ces informations peuvent prendre la forme denregistrements numriques condition de disposer des rgles et moyens pour les interprter.

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.

Donnes et/ou signaux attendus en sortie


Idem ci-dessus.

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).

2.2.3. Produits issus de l'excution des tests


Les remarques du 2.1.3 restent applicables aux livrables issus de l'excution des tests. Le tableau III donne le contenu souhait pour les rapports de tests.

Chronologie des essais


Dates effectives des diffrents essais, ordonnancement des essais.

Faits marquants
cart lordonnancement prvus, abandons de certains tests, etc.. Peut faire lobjet dun document spar dit journal de test .

Dtail des rsultats obtenus


Pour chaque test, signaux et/ou donnes en sortie constats (valeurs et squencement) . Ces rsultats peuvent prendre la forme denregistrements numriques, condition que les rgles et moyens de les interprter soient disponibles.

2.2.4. Exemple des tests de validation


Lencadr 2 dtaille le contenu des livrables (rapports de tests) issus de la phase d'excution des tests de validation. Les informations sur les objectifs de tests, les environnements et outils de tests utiliss, etc., sont requis pour une bonne comprhension des rapports de validation. On notera qu'il doit y avoir autant de rapports que de versions fournies.

Liens avec la gestion de modification


Pour chaque test en chec, lien vers la demande de modification correspondante.

Bilan des non-conformits


Liste synthtique des non-conformits dtectes, avec leur impact sur la scurit .

Preuve de couverture des tests


Par exemple, une liste des tests lmentaires et une rfrence croise entre les exigences tester et les tests identifis.

72 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

2.3. Vrification des tests


La vrification des tests doit dmontrer que les objectifs de test sont atteints. Elle consiste analyser les produits de la phase vrifier (voir exemple des tests de validation) pour : Etablir la traabilit des tests raliss pour chacun des types de tests dfinis, compte tenu des objectifs. Il est ncessaire d'tablir la traabilit au fur et mesure de la ralisation des tests afin d'optimiser la phase de vrification des tests pour laquelle cette traabilit est ncessaire. Si la matrice de traabilit n'existe pas, le contenu de chaque procdure de tests doit tre analys pour tablir la matrice. Cette valuation doit tre affine en examinant sur le fond les procdures pour sassurer que : les tests sont valides, pertinents et reproductibles ; les tests couvrant un objectif donn sont rellement probants pour lobjectif ; les mthodes de test spcifies lors de la planification des tests sont bien utilises.

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.

73 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

ANNEXE I

EXIGENCES DE VERIFICATION DU LOGICIEL SOFTWARE VERIFICATION REQUIREMENTS

Cette annexe reprend les exigences contenues dans le projet STSARCES [10].

A1. DTERMINATION DU NIVEAU DE CRITICIT D'UN LOGICIEL


Les exigences du document Software quality and safety requirements sont modules en deux niveaux (1, 2) selon le niveau de criticit des fonctions assignes au logiciel. Le niveau 2 correspond aux exigences les plus fortes pour les logiciels concerns par ce document. La dtermination du niveau de criticit du logiciel dcoule d'analyses de sret de fonctionnement de l'ensemble du systme. Elle suit des principes largement fonction du domaine d'application, du type de systme, des dommages qu'il peut causer son environnement (humain en particulier), des personnes auxquelles il est destin ou de la constitution mme du systme (architecture par exemple). L'tat de l'art actuel en matire de logiciel ne fournit pas de rgles prcises. Quelques ides directrices, schmatises par la figure A-1, peuvent nanmoins tre fournies, afin de guider la dtermination du niveau d'exigences retenir. Classification du systme : la structure du systme tant dfinie ainsi que les conditions oprationnelles et environnementales, il s'agit d'identifier les types de dangers de ce systme (dans tous ses modes de fonctionnement) ainsi que les cas de pannes ou d'utilisations errones du systme et leurs consquences. Cette classification doit prendre en compte des facteurs d'ajustement tels que l'architecture du systme, les redondances matrielles ou des restrictions d'utilisation ventuelles.

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.

A2. EXIGENCES DE VERIFICATION


Le niveau ainsi dtermin permet d'tablir la liste des exigences lmentaires applicables au logiciel considr. Trois degrs d'exigences sont fixs pour retenir ou non une exigence en fonction du niveau : E (Exige) : son application est systmatique pour le logiciel concern, C (Conseille) : son application est recommande sans tre impose, / (pas d'exigence) : son application est laisse l'apprciation du concepteur. Les textes en italique associs aux exigences sont des commentaires informatifs servant prciser l'objectif de ces exigences, la manire de les apprhender et les limitations ventuelles d'application.

Facteurs d'ajustement Risques Environnement Consquences des pannes du systme

Facteurs d'ajustement

Classification du systme
Niveau d'intgrit du systme

Classification du logiciel

Niveau d'exigence fix au logiciel

Fig. A-1. Processus de dtermination du niveau de criticit dun logiciel - Process of determining the software criticality level

74 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

A2.1. Exigences gnrales

TABLEAU A-I

EXIGENCES DE VRIFICATION Cf. tableau A-I : exigences nos 1 3.


No 1

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).

A2.2. Exigences sur les revues internes

No 4

Exigences sur les revues internes


Une revue (avec lanalyste) de spcification doit se tenir en fin de phase de spcification du logiciel. Les activits d'analyse et de vrification des spcifications du logiciel doivent : - vrifier l'exhaustivit et l'adquation des spcifications du logiciel par rapport aux spcifications du systme. - vrifier la traabilit par rapport aux spcifications systme. La revue de spcification du logiciel doit permettre : de s'assurer que les besoins rels ont t pris en compte dans les spcifications, que les risques techniques ont t identifis, rsolus et rduits par de bons choix ; de vrifier que les spcifications du logiciel satisfont les spcifications du systme. Ces activits permettent d'assurer que les spcifications du logiciel sont en cohrence avec les spcifications du systme, qu'elles sont compltes et que l'on sait faire la correspondance entre les deux.

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.

75 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

TABLEAU A-I (SUITE)

EXIGENCES DE VRIFICATION VERIFICATION REQUIREMENTS


No 7 Exigences sur les revues internes (suite)
Le rsultat de chaque revue doit tre document et archiv. Il doit comprendre la liste des actions dcides en revue et la conclusion de la revue (dcision ou non de passer l'activit suivante). Les activits dcides en revue doivent tre suivies et traites.

A2.3. Exigences sur la vrification du code

Niv. 1 E

Niv. 2 E

No

Exigences sur la vrification du code (source et donnes)

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

EXIGENCES SUR LE TEST DU LOGICIEL SOFTWARETEST REQUIREMENTS


No 9 Exigences gnrales sur le test du logiciel
La stratgie de vrification du logiciel aux diffrentes tapes de dveloppement, ainsi que les techniques et outils utiliser pour cette vrification doivent tre dcrits dans un plan de test avant de les mettre en uvre. Cette description doit concerner a minima : - l'identification du logiciel ou des constituants logiciels relatifs la scurit soumis validation avant mise en service, - l'organisation des activits de vrification (intgration, validation...) et les interfaces avec les autres activits de dveloppement du logiciel, - l'indpendance de la vrification s'il y a lieu : la stratgie de vrification doit tre labore, mise en uvre et les rsultats des essais doivent tre valus de manire indpendante (personne, service ou organisme) dans la mesure o la taille de l'quipe de dveloppement le permet, - les mthodes et outils de vrification (revue, analyse avec liste de contrle, types d'essais...) - l'environnement de vrification (quipements de test, mulateur...) - la manire de contrler les rsultats des essais. - matrice de traabilit, fournissant une correspondance entre les tests raliser et les objectifs de tests dfinis. Un seul document (plan de test par exemple) peut rpondre aux exigences de planification de plusieurs activits de vrification (tests unitaires, intgration, validation). Ces documents peuvent, s'il y a lieu, faire rfrence des procdures ou instructions gnrales applicables tous les projets logiciels, en complment des dispositions spcifiques au projet. La formalisation de la stratgie a en outre l'avantage d'assurer la reproductibilit de l'activit (exemple : identifier l'ordre d'intgration en fonction de l'architecture systme). L'intrt de cette indpendance est d'introduire, dans l'activit de vrification, des personnes non impliques dans les phases de dveloppement amont et n'ayant donc pas la vision de la manire dont est ralis le logiciel. Ceci assure en gnral une plus grande efficacit des tests.

A3. EXIGENCES SUR LE TEST DU LOGICIEL


A3.1. Exigences gnrales
Niv. 1 C Niv. 2 E

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)

76 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

TABLEAU A-II (SUITE)

EXIGENCES SUR LE TEST DU LOGICIEL SOFTWARETEST REQUIREMENTS


N 10 Exigences gnrales sur le test du logiciel (suite)
La vrification d'une nouvelle version doit comporter des tests de non-rgression. Les tests de non-rgression permettent d'assurer que les modifications effectues n'ont pas modifi de manire inattendue le comportement du logiciel par des effets de bord.

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.

A3.2. Exigences relatives aux tests de validation

N 13

Vrification des spcifications du logiciel


La couverture des tests doit tre explicite dans une matrice de traabilit et respecter les exigences suivantes : - chaque lment de spcification doit tre couvert par un test de validation, y compris les mcanismes de scurit, - il doit tre possible de vrifier le comportement temps rel du logiciel dans tous les modes oprationnels. De plus, la validation doit tre effectue dans des conditions reprsentatives de l'utilisation. Cette exigence permet notamment d'assurer que le logiciel ragit tel que fonctionnellement prvu. Elle ne s'applique pas aux cas o les conditions de test sont destructives pour le matriel (dfaut physique non simulable d'un composant par exemple). Pour tre significative, la validation doit se faire dans les conditions de fonctionnement oprationnel du systme (c'est--dire avec le logiciel et le matriel dans leurs versions finales, le logiciel tant charg dans le systme cible). Toute autre combinaison peut diminuer l'efficacit des essais raliss et ncessite une analyse de sa reprsentativit.

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.

77 Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

TABLEAU A-II (FIN)

EXIGENCES SUR LE TEST DU LOGICIEL SOFTWARETEST REQUIREMENTS


N 14 Vrification des spcifications du logiciel
La seconde exigence a pour objectif de garantir que chaque version livre a t valide, dans sa version ultime. Par contre, l'exigence n'impose pas une validation complte pour chaque modification incorpore dans une version : une analyse d'impact peut, dans certains cas, justifier une validation partielle.

A3.3. Exigences relatives aux tests dintgration

Niv. 1

Niv. 2

N 15

Vrification de la conception du logiciel


Les tests d'intgration du logiciel doivent permettre de vrifier : - le squencement correct de l'excution du logiciel, - les changes de donnes entre modules, - le respect des performances, - la non altration des variables globales. La couverture des tests doit tre explicite dans une matrice de traabilit fournissant une correspondance entre les tests raliser et les objectifs de tests dfinis.

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.

A3.4. Exigences relatives aux tests unitaires

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

Vrification de la conception dtaille


Chaque module logiciel doit tre soumis des essais vrifiant au moyen de donnes fournies en entre, que le module remplit les fonctions demandes dans la conception dtaille. La couverture des tests doit tre explicite dans une matrice de traabilit fournissant une correspondance entre les tests raliser et les objectifs de tests dfinis.

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

Vous aimerez peut-être aussi