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,
Comment construire
Centre de l'INRS-Lorraine, Nancy,
N. Diette, St Surlog,
1 bis rue du Petit-Clamart,
les tests d'un logiciel
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,
Comment construire
Centre de l'INRS-Lorraine, Nancy,
N. Diette, St Surlog,
1 bis rue du Petit-Clamart,
les tests d'un logiciel (*)
78140 Vlizy-Villacoublay,
et F. Escaffre, St CEP-Systmes/
RIdatas, 150 rue Nicolas-Vauquelin,
31047 Toulouse cedex

e logiciel zro dfaut n'existe pas. La prsence de fautes logicielles systmatiques,

T here is no such thing as a zero


fault software.The presence of
L 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
systematic software faults introduced at sur la scurit d'un dispositif complexe.
the design stage of a programmable Cet article propose une mthode de mise en uvre des tests, qui sont la principale compo-
device must therefore be given compre- sante de la vrification dun logiciel. En annexe, sont prsentes les exigences qui permet-
tent de s'assurer que cette vrification a effectivement t ralise et qu'elle savre effi-
hensive and careful consideration, in cace. Pour dtecter un maximum de fautes, ces tests doivent tre conduits en suivant une
particular when the consequences of dmarche qui dfinit, dans un premier temps, les objectifs de tests et la stratgie adopte
these faults can influence the safety of pour les atteindre, et qui dmontre, dans un deuxime temps, que lesdits objectifs ont t
a complex system. satisfaits.
This article proposes a method of car-
rying out tests, which are the main com- logiciel  faute  test  mthodologie  informatique
ponent of software verification.The
requirements to ascertain that this veri-
fication has been efficiently carried out
are given in annex.To detect the maxi-
mum number of faults, testing must be
carried out according to an approach

D
ans le domaine des machines,  La prvention des fautes. Cest len-
that firstly defines the objectives of the
les systmes programms peu- semble des dispositions prises par le
tests and the strategy adopted, and
secondly that demonstrates that the vent tre utiliss pour traiter constructeur pour assurer un dveloppe-
said objectives have been achieved. des informations relatives la ment matris du produit. La prvention
scurit, condition de respecter les exi- des fautes concerne donc le processus
 software  fault  test gences de scurit qui leurs sont appli- gnral de conception du systme.
 methodology cables [1]. Ils doivent, entre autres, satisfai-
re aux prescriptions contenues dans la  La tolrance aux fautes. C'est l'utilisa-
norme europenne EN 954-1 [2, 3], un des tion de mthodes et techniques construc-
points les plus dlicats traiter tant de tives destines fournir un service
garantir un comportement sr en prsen- mme de remplir la, ou les fonctions du
ce de fautes. systme en dpit des fautes pouvant l'af-
fecter. La tolrance aux fautes a donc une
En effet, il est matriellement impossible influence sur l'architecture du systme.
de caractriser et de prvoir toutes les Dans un cadre de scurit, la tolrance
fautes susceptibles daffecter ces systmes aux fautes se limitera lutilisation de
complexes [4]. Seul le recours des techniques de dtection des fautes, la
moyens prouvs en sret de fonction- raction tant la mise en position de repli.
nement (SdF), pour dvelopper le matriel
et le logiciel de ces systmes, permet dob-  Llimination des fautes. C'est lappli-
tenir en final une confiance justifie dans cation, au cours de chaque phase du cycle
la scurit de ces systmes [5, 6]. Ces de vie du systme, de mthodes et tech-
moyens peuvent tre rpartis en quatre niques destines rduire la prsence des
catgories [7] : 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 len- logiciel. Une dmarche didactique de 1.2. Le test du logiciel
semble des techniques de vrification du construction des tests du logiciel a t tu-
matriel et du logiciel. die, pour aider les concepteurs respec- Le test du logiciel [14 16] est une
ter les exigences formules en matire de approche dynamique de la vrification,
 La prvision des fautes. C'est l'valua- certification et raliser ainsi des tests effi- destine s'assurer que ce logiciel poss-
tion du comportement du systme par caces et suffisants. Cette seconde voie a de effectivement les caractristiques
rapport l'apparition des fautes. Elle se conduit la rdaction du document requises pour son contexte d'utilisation. La
base sur un ensemble de mthodes et Guide for the construction of software premire action entreprendre est donc
techniques destines estimer la prsen- tests [13]. de dcrire avec prcision ce contexte, en
ce, la cration et les consquences des particulier les fonctionnalits attendues,
fautes. La prvision des fautes est destine Cet article est dans la continuit de celui les contraintes d'environnement, ou enco-
s'assurer que les techniques de tolran- publi en 1997 dans cette revue [9], qui re les situations dangereuses considrer.
ce et d'limination mises en uvre ont prsentait les exigences en matire de
l'efficacit souhaite. qualit et de sret des logiciels. Il pr- Le test a pour objectifs :
sente tout dabord la problmatique lie
Dans le cadre du projet europen la vrification du logiciel, en focalisant sur 1. De dtecter d'ventuels carts entre le
STSARCES (1) [8], l'INRS a men des tra- son principal composant, c'est--dire le comportement attendu et le comporte-
vaux, en coopration avec les socits test. Les principales tapes de la dmarche ment observ au cours des tests, ce qui
Veridatas (aspect qualit) (2) et Surlog de construction des tests du logiciel sont limine un grand nombre de fautes pr-
(aspect sret de fonctionnement), pour ensuite prsentes : sentes dans le logiciel.
adapter deux techniques complmentaires  dfinition pralable des tests raliser,
de SdF aux systmes programms utiliss  excution des tests, 2. D'obtenir la confiance ncessaire avant
en scurit des machines. Ces techniques  vrification des rsultats de tests. l'utilisation oprationnelle. Il faut cepen-
sont destines traiter les fautes logicielles Les objectifs de chaque tape sont indi- dant noter que le nombre de fautes dtec-
systmatiques (3) affectant les logiciels qus, ainsi que les activits y exercer et tes ne peut pas tre considr comme un
systmes (4), en sattachant : les traces fournir pour aider l'analyse. critre de russite des tests. Le retour d'ex-
Des exemples d'application illustrant cer- prience montre en effet qu' complexit
 prvenir ces fautes, par la dfinition tains points de la dmarche sont donns technique et industrielle constante, un
d'exigences en matire de qualit et de pour la construction des tests de valida- grand nombre d'erreurs dtectes par rap-
sret des logiciels [9, 10]. Des exigences tion. Une annexe rappelle les exigences port dautres projets de rfrence peut
ont t formules pour proposer aux du document [10] relatives la vrification seulement tre interprt comme l'indica-
concepteurs une mthode de travail rigou- du logiciel. teur d'un logiciel contenant un trs grand
reuse, dans le but de minimiser le nombre nombre de fautes et non comme l'atteinte
des fautes restant dans le logiciel en phase d'un bon taux de dtection des fautes pr-
dexploitation. Ces exigences sont adap- sentes. Il est donc trs difficile d'avoir
tes aux logiciels systmes dvelopps
pour la scurit des machines et sont
1. La vrification confiance en un logiciel ayant un grand
nombre de fautes dtectes par le test.
cohrentes avec la norme CEI 61508 (par- du logiciel
tie 3 Prescriptions concernant les logi-
ciels notamment [11] ). Elles concernent : Remarques
 le produit logiciel, 1.1. Gnralits
 le processus de dveloppement du  L'observation d'un logiciel sous test, l'analyse de
logiciel, La vrification du logiciel a pour but de l'architecture du logiciel et du codage, l'valuation
 la vrification du logiciel. dmontrer que les produits logiciels issus du processus de dveloppement sont autant d'l-
Les moyens de vrifier que ces exi- d'une phase du cycle de dveloppement ments pour rpondre la question : Est-ce que le
gences sont effectivement respectes et sont conformes aux spcifications logiciel est bien fait ? .
efficaces ont t consigns dans le docu- (incluant les exigences lgales et rgle-
ment Guide to assessing software quali- mentaires) tablies lors des phases prc- Mais, pour traiter compltement la sret de fonc-
ty and safety requirements [12]. dentes. tionnement au niveau du systme,il faut tre gale-
Elle a galement pour but de dtecter et ment en mesure de rpondre la question : Est-ce
 liminer ces fautes, en proposant de rendre compte des fautes qui peuvent que le logiciel ralis correspond bien lapplica-
une dmarche de construction des tests du avoir t introduites au cours des phases tion traiter ? . Seules des analyses au niveau du
(1) STSARCES : STandards for SAfety Related Complex
prcdant la vrification. systme permettent de rpondre cette question,
Electronic Systems. Contrat CEE n SMT4-CT97-2191. ce qui dpasse l'tude des tests du logiciel.
Financement DG XII. La vrification du logiciel est compose :
(2) Veridatas est une entit du ple Conseil du bureau  des tests, partie prdominante pour Il faut donc insister sur le fait qu'il est illusoire de
Vritas. les logiciels de faible taille, qualifier un systme complexe la seule obser-
(3) Faute logicielle systmatique : faute introduite la  des activits de revues et d'analyse. vation de son comportement sur un nombre limit de
conception d'un logiciel, qui se rvle lorsque la partie Ces activits peuvent dans certains cas jeux de tests. Les tests sont essentiels pour dtec-
du programme dans laquelle elle est situe est active.
remplacer certains tests (exemple : un test ter des erreurs et amliorer la confiance dans l'ap-
(4) Logiciel partie intgrante du systme, fourni par le qui ne pourrait pas tre ralis sans dt- titude du systme accomplir sa mission, mais
vendeur et non accessible pour modification lutilisa-
teur final. A distinguer du logiciel applicatif, qui est un rioration d'un composant matriel). insuffisants pour qualifier le comportement d'un
logiciel spcifique lapplication utilisateur, dans systme.
lequel les fonctions du systme sont programmes.
67
Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

 Il existe un risque pour le concepteur de faire Plan de Test de Validation du logiciel


dfinir par une mme entit (individu, quipe), la et procdures associes
Tests de
Spcification
spcification,la conception,la stratgie de tests et validation
les cas de tests. Deux raisons au moins justifient le
recours un tiers pour tester un logiciel :
Plan de Test d'Intgration
le but des tests est dexcuter un programme avec
du logiciel et procdures associes
lintention de trouver ses erreurs [14],ce qui consti- Conception Tests
tue un processus mental non naturel, difficile prliminaire d'intgration
mener par une mme entit ;
le programme peut contenir des erreurs dues la Plan de Test Unitaires
non comprhension de limplmentation ou des sp- et procdures associes
Conception Tests
cifications par le dveloppeur [14]. Dans ce cas, il
dtaille unitaires
est probable que celui-ci aura ces mmes non-
comprhensions quand il testera son propre pro-
gramme (mode commun de dfaillance).

 La correction des fautes logicielles peut : Codage


injecter de nouvelles fautes et perturber des par-
ties correctes dj testes ;
rendre active une partie du logiciel jusqu'alors Fig. 1. Phase de dfinition des tests dans le cycle de dveloppement en V -
inaccessible et donc rvler un grand nombre de Test definition phase in the V-development cycle
nouvelles fautes, qui ne pouvaient tre constates
avant cette correction.

1.3. Les diffrents tests


du logiciel  Tests de validation, pour sassurer vrification du logiciel. Il est donc recom-
que le logiciel implant dans le matriel mand au concepteur du systme de
Les tests doivent tre mens diffrents rpond aux spcifications fonctionnelles, prendre en compte ces exigences ds le
niveaux du dveloppement dun logiciel. en vrifiant plus particulirement les fonc- dbut du dveloppement du logiciel.
En suivant le cycle en V de dvelop- tions gnrales, les interfaces matriel / Les exigences sont classes en deux
pement du logiciel (fig. 1), ils se dcom- logiciel, le fonctionnement temps rel, les niveaux, suivant la criticit du logiciel. Ces
posent en : performances, l'utilisation et l'allocation niveaux dterminent le degr de rigueur
des ressources. exig pour le dveloppement du logiciel,
 Tests unitaires, pour dmontrer que afin d'viter les fautes dont le logiciel peut
chaque module effectue toute la fonction Cette dcomposition du test, relie au tre la cause. Le processus de classifica-
prvue et seulement cette fonction. On cycle de vie, distingue les tests de valida- tion pour fixer le niveau des exigences au
peut distinguer dans ces tests unitaires : tion du logiciel de ceux du systme. Elle logiciel ncessite une valuation spci-
 les tests de logique (recherche d'er- montre ainsi clairement quil est ncessai- fique de chaque systme (cf. chap. A.1 de
reur, vrification de l'enchanement cor- re de vrifier dune part, la conformit du l'annexe I).
rect des branches parcourues) ; logiciel ses exigences propres et dautre
 les tests de calcul (vrification des part, la conformit du systme ses exi- La dmonstration du respect de toutes
rsultats des calculs, des performances, de gences (les premires tant dduites des les exigences applicables au logiciel va-
l'exactitude des algorithmes). secondes). Cette distinction ne doit cepen- luer doit tre faite par le concepteur du sys-
Typiquement, les tests de calcul com- dant pas conduire valider le logiciel tme. Chacune de ces exigences lmen-
prennent les tests de donnes dans les indpendamment du matriel sur lequel il taires doit faire l'objet d'une rponse appro-
limites des spcifications (tat normal), est implant. prie, soit par l'intermdiaire des docu-
aux limites spcifies et en dehors de ces ments produits, soit par l'intermdiaire des
limites (tat anormal). Les tests de com- activits conduites pour dvelopper le logi-
portements anormaux (hors limites, 1.4. Exigences pour ciel et dont les traces auront t conserves
erreurs) sont gnralement appels tests la vrification du logiciel pour valuation. Il est par exemple impor-
de robustesse. tant de noter qu'une activit de test qui
Les exigences satisfaire pour la vrifi- serait ralise de faon informelle, par
 Tests dintgration du logiciel, pour cation du logiciel, qui portent sur les acti- exemple l'aide d'un analyseur logique
dmontrer le bon fonctionnement d'uni- vits de revues et d'analyse ainsi que sur sans aucune trace papier ou informatique,
ts fonctionnelles constitues d'un assem- le test, sont prsentes en annexe I. Leur ne constitue pas une preuve de test. Ceci
blage de modules. Ils portent principale- respect limite le nombre des fautes intro- n'empche pas le concepteur de mener
ment sur la vrification des enchane- duites dans un logiciel. cette activit si elle lui est ncessaire dans
ments entre modules, la circulation des une phase spcifique de mise au point.
donnes, les aspects dynamiques, les Elles servent dfinir, vis--vis d'un
squences d'vnements prvus et les concepteur, des rsultats obtenir pour
reprises en cas d'interruption. toutes les activits techniques lies la
68
Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

Dfinir ces objectifs permet de raliser Attention ! Fixer a priori un objectif en terme de
2. La dmarche les tests avec un maximum d'efficacit en taux de couverture peut conduire le concepteur

de construction garantissant la couverture des objectifs


dfinis, donc de focaliser les efforts sur les
dgrader son code pour atteindre plus facilement
les objectifs. Une valeur de 100 % pour un taux de
des tests du logiciel aspects essentiels. couverture en branches ou en appels de fonctions
Les objectifs de tests de chaque phase de peut tre obtenue en diminuant artificiellement
tests seront identifis et dfinis en consi- le nombre d'appels de procdures par duplication du
Ce chapitre propose une dmarche drant : code ou allongement de la taille moyenne des pro-
pour tester efficacement un logiciel. Son  les exigences fonctionnelles et de per- cdures.
suivi facilitera le respect des exigences for- formance (en tenant compte aussi des Toute dmarche d'objectif de taux de couverture
mules en annexe I et permettra dviter contraintes particulires de lenvironne- doit donc tre accompagne de rgles de program-
au maximum lintroduction de fautes au ment final dutilisation du logiciel), expri- mation vitant ce type d'effet pervers.
sein dun logiciel. Les activits lies aux mes dans les documents de spcifica-
trois phases de tests dcrites au 1.3 sont tion / conception du produit logiciel ; 2.1.2. Stratgie de test
identiques.  les exigences en matire de qualit et
Le processus de test, pour qu'il soit de de sret de fonctionnement (rectitude, Quel que soit le niveau dexigence, les
qualit, doit suivre les mmes principes robustesse, maintenabilit, disponibilit, tests doivent tre conus et raliss sur la
que tous les autres processus de ralisa- scurit...) ; base dune stratgie. Elle constitue un
tion ou de cration, cest--dire :  toutes les contraintes identifies d'im- pralable ncessaire llaboration des
 dfinition au pralable des tests plmentation (utilisation d'une base de tests et la conception des jeux dessai. La
raliser, donnes, utilisation des nombres rels, stratgie de test tmoigne d'une rflexion
 excution selon des procdures langage de programmation, logiciel temps sur les tests. Son absence indique un
prvues, rel) ; risque dimprovisation dans llaboration
 vrification selon des modalits fixes.  les exigences lgales et rglementaires ; des tests.
 les contraintes de cot et de temps de La stratgie doit dfinir comment, glo-
test. balement, les tests vont tre mens pour
2.1. Dfinition pralable Il en rsulte la dfinition des types de satisfaire aux objectifs pralablement dfi-
des tests raliser tests raliser (chemins structurels, che- nis, en relation avec les environnements
mins fonctionnels, donnes d'entres - que le concepteur compte mettre en
Les tests se prparent ds la phase de sorties aux limites, hors limites, de robus- uvre. Elle doit organiser les tests en une
spcification - conception correspondante. tesse, de performance...) et la justification structure lisible dtapes, ayant des objec-
Leur dfinition fait l'objet des plans de de ces choix. tifs clairs ou rpondant des contraintes
tests (de validation, d'intgration, uni- denvironnement prcises (par exemple,
taires). Elle ncessite la rdaction de pro- Taux de couverture relatives la disponibilit dun outil).
cdures associes. Pour chaque type de tests dfini, l'exi- On dfinit donc les mthodes et les
La figure 1 prsente, pour un cycle de gence sur le taux de couverture des tests moyens de tests pour y parvenir, puis l'en-
vie en V , les phases de dfinition des atteindre est de 100 %. chanement - ou planification - des tches
tests. de ralisation des tests. L'ensemble des
Exemple moyens de tests et de la planification
2.1.1. Objectifs de tests constitue la stratgie de test mise en
Si le choix de tester les chemins fonctionnels est uvre.
Dfinition des objectifs retenu, un taux de couverture de 100 % signifie La dfinition des tests aboutit la rali-
Dans labsolu, leffort de test (validation, qu'aprs ralisation des tests, chacun des chemins sation des fiches de tests.
intgration et unitaire) dun logiciel peut fonctionnels du logiciel doit avoir t parcouru au
tre aussi important que lon veut. La com- moins une fois. Il est bien sr ncessaire d'avoir les Dfinition des procdures de test
binatoire des donnes dentre, des moyens de mesurer le taux de couverture rel obte- Selon lexigence 11 : Les directives
modes dutilisation, des modes de fonc- nu pour le comparer au taux de couverture souhait pour la rdaction des procdures de test
tionnement, des paramtres dexploita- (ici, de 100 %). doivent comprendre la description des
tion, la varit des aspects vrifiables Mais ce taux peut tre rduit par des hypothses jeux de donnes d'entre appliquer, la
(conformits aux spcifications, aux justifier : description des sorties attendues et les cri-
manuels dutilisation et dexploitation, aux  Il se peut par exemple, lors des tests de valida- tres d'acceptation des rsultats des
exigences de robustesse, de performance, tion site , que le logiciel soit dans un environne- essais , la dfinition des procdures de
dergonomie, comportement nominal, en ment particulier, empchant le test de certaines tests est exige pour le niveau 2 et recom-
cas de dfaillance, etc.) sont telles quune fonctionnalits prvues pour un environnement dif- mande pour le niveau 1 (cf. chap. A.3 de
infinit de tests peut tre mene sans frent. Le taux de couverture ne pourra donc pas l'annexe).
quon soit certain de la conformit totale atteindre 100 % des fonctionnalits dcrites dans Un processus de test correctement mis
aux exigences. les spcifications. La justification de la diminution en uvre implique que les procdures de
du taux de couverture devra tre consigne dans le test soient ralises le plus en amont pos-
En pratique, leffort de test doit donc dossier de test. sible dans le cycle de dveloppement.
tre adapt aux enjeux. Il ncessite de se  De mme, certains tests portant sur les aspects Cette remarque est particulirement
fixer des objectifs pralablement toute temps rel ne sont pas toujours ralisables en importante dans le cadre de lvaluation.
dfinition dune stratgie, de mthodes et tests unitaires. Une justification adapte permettra En effet, le valideur comme le concepteur
techniques, etc., et finalement des tests de limiter le taux de couverture des aspects temps auront toujours intrt ce que ces pro-
eux-mmes. rel durant la phase de tests unitaires. cdures 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 TABLEAU I

remettre en cause la phase correspondan- PRODUITS ISSUS DE LA DFINITION DES TESTS -


te de test et permet lvaluateur de ne PRODUCTS STEMMING FROM THE TEST DEFINITION
pas concevoir de tests complmentaires
Livrable thorique Contenu
lors de lvaluation finale.
Il est ncessaire que ces procdures Planification des tests Objectifs, stratgie, techniques et mthodes,
contiennent toutes les informations nces- organisation et responsabilits, moyens ncessaires,
saires : identification des tests et dmonstration de couverture.
 leur identification et leur traabilit
Procdures de tests Description dtaille de chaque test en termes de mode opratoire,
vis--vis des objectifs et/ou de la stratgie ; de donnes dentre, de rsultats attendus et de critres darrt.
 lexcution du test pendant la phase
(activits de prparation, de droulement
des tests, d'enregistrement des anomalies
et critre d'arrt des tests).

Mthodes et techniques de test : 2.1.3. Produits issus Dfinition de la procdure des tests
techniques de base de la dfinition des tests de validation
Les techniques de base sont rparties
en deux catgories suivant qu'elles autori- Pour montrer ce que peut tre une stra-
sent ou non l'observation du comporte- Les produits d'une phase de test (ou tgie de test de validation (une stratgie
ment interne du composant logiciel sous livrables) sont des documents ou des spcifique est laborer pour chaque
tests [16] : rsultats sous forme informatique (fichier contexte spcifique, et pour un contexte
 bote noire ou test fonctionnel : pas texte, objets d'un atelier de gnie logiciel) donn, il existe n stratgies possibles), la
de visibilit du composant sous test, les observables comme preuve d'une activit liste ci-dessous fournit des exemples
entres et les rsultats attendus sont expri- du processus de test. dtapes typiques. Ces tapes sont lies
ms en terme de comportement du com- Outre les variations de cycle de vie aux types de tests ainsi qu'aux contraintes
posant logiciel dun point de vue externe, entre les diffrents projets, il peut y avoir de mise en uvre des tests (banc de test,
sans se soucier de la structure interne du des diffrences plus ou moins importantes environnement) :
composant ; sur le nom et la rpartition des informa-  une tape de test dtaill pour chaque
 bote blanche ou test structurel : tions entre ces livrables. Les livrables fonction en nominal ;
visibilit du composant sous test, les jeux pourraient mme ne pas exister. Les noms  une tape de test dtaill pour chaque
de test sont produits en analysant le code des livrables sont donc donns titre indi- fonction aux limites ;
source. catif, avec une courte description de leur  une tape de test dtaill pour chaque
contenu : ils doivent tre considrs fonction hors limites ;
Moyens de test comme des livrables thoriques , qui  une tape de test de performance ;
Quel que soit le niveau dexigence, la sont disponibles ds que le concepteur  une tape vrifiant le comportement
dfinition de la stratgie et des mthodes peut fournir les informations qui les dfi- en cas de dfaillance ;
de test doit saccompagner de la dfinition nissent. On vrifiera donc la prsence des  une tape consacre au paramtrage ;
des moyens ncessaires pour les mettre informations utiles et leur pertinence, plu-  des tapes avec des entres simules
en uvre. Labsence de cette information tt que leur rpartition dans une arbores- et des tapes avec des entres relles du
diminue fortement la crdibilit de la stra- cence documentaire thorique . milieu oprationnel ;
tgie et des mthodes envisages. Le tableau I donne le contenu souhait  des tapes usine et des tapes sur
pour les produits issus de la dfinition des un site oprationnel.
A titre dexemple, la liste ci-dessous tests.
fournit des moyens auxquels il faut pen- La stratgie doit sintgrer dans la strat-
ser au pralable : 2.1.4. Exemples de tests gie densemble de vrification du logiciel.
 outils : simulateurs, comparateurs, de validation En pratique, il arrive que les essais ne cou-
outils de mesure des signaux, outils de vrent pas totalement les objectifs fixs, par
test, etc., Objectifs de test exemples :
 environnements de test : configura- A priori, en validation, on doit se fixer - parce que certains dfauts ou certains
tions diffrentes du systme, en usine, sur comme objectif de couvrir chaque l- modes de dfaillance ne peuvent pas tre
site, ventuellement variable en fonction ment de spcification, y compris les mca- simuls, ou
du paramtrage, etc., nismes de scurit. En ce qui concerne - parce que certains tats ne sont jamais
 jeux dessai prenregistrs, tables pr- ces mcanismes, lvaluateur devra sassu- atteints dans lenvironnement du systme.
dfinies de paramtres, etc. rer (EN 954-1 [2]) quau minimum les
objectifs couvrent : La stratgie doit alors montrer quelles
En particulier, pour les tests unitaires, la  les fonctions de scurit spcifies ; sont les vrifications complmentaires qui
dfinition dune stratgie au plus tt impo-  les comportements attendus pour la seront menes pour que le risque de non-
se lutilisation doutils adapts la taille du catgorie spcifie ; conformit soit amen un niveau rai-
logiciel. Ces outils automatisent lexcu-  les aspects dimensionnement et para- sonnable, par exemple : renforcement de
tion (et la rxcution ventuelle) des tests mtrage. certains tests en phase de tests unitaires
et la mesure des taux de couverture. De plus, il doit tre possible de vrifier ou dintgration, contrles thoriques,
le comportement temps rel du logiciel analyse de comportement sur la base de
dans tous les modes oprationnels. schmas ou de modles.
70
Cahiers de notes documentaires - Hygine et scurit du travail - N 181, 4e trimestre 2000

Mthodes et techniques de test Cependant, ou bien ces techniques ne 2.2. Excution des tests
Quel que soit le niveau dexigence, des sont pas simples mettre en uvre (tests
tests fonctionnels (en bote noire ) doi- bass sur les graphes de cause effet ou L'excution des tests doit se conformer
vent tre raliss dans la phase de valida- sur les automates tats finis), ou bien la aux procdures et aux conditions dfinies
tion. En rgle gnrale, il ne doit pas y dmonstration de la couverture obtenue pralablement dans les plans de test et les
avoir de tests en bote blanche pour les reste difficile tablir (tests par intuition, fiches de test (activits de prparation, de
raisons suivantes : tests alatoires). droulement des tests, d'enregistrement
 les tests de validation doivent vrifier des anomalies).
la conformit aux spcifications, donc Produits Tout non-respect de celles-ci doit tre
une dfinition du compotrtement du logi- Les livrables issus de la dfinition des argument, ce qui permettra, lors de la
ciel dun point de vue externe ; tests de validation devront contenir les vrification des tests, de justifier ces diver-
 la validation doit tre ralise sur le informations dtailles dans lencadr 1. gences.
systme intgr, donc en rgle gnrale,
avec peu de visibilit sur le comporte-
ment interne du logiciel. ENCADRE 1
Lorsque le concepteur prvoit dutiliser
des mthodes de type bote blanche , il Contenu des produits issus de la dfinition des tests de validation -
faut dmontrer quil y a un rel avantage Content of the products stemming from the definition of the validation tests
observer le comportement interne du
logiciel pendant cette phase et que ces Organisation, responsabilits
observations ne peuvent pas tre ralises Personnes impliques dans la validation. Organisation. Responsabilits.
dans les phases prcdentes. Le cas
chant, il peut tolrer lutilisation de cette Objectifs gnriques des tests
Par exemple :
technique si des tests en bote noire exis- Couverture de toutes les fonctions ; de tous les modes de fonctionnement ;
tent et couvrent les spcifications fonc- des exigences de sret en cas de dfaut ; des exigences de performances ;
tionnelles (ces tests peuvent ventuelle- Conformit la documentation dutilisation, dexploitation ;
Vrification dendurance, etc.
ment comporter aussi des aspects bote
blanche ). Stratgie de tests
Dmarche retenue, avec ordonnancement en tapes visant des objectifs spcifiques
Les principales techniques de base utili- ou sappuyant sur des environnements ou des techniques spcifiques, par exemples :
Test de tel groupe de fonctions ; test de tel mode de fonctionnement ;
sables en validation sont [13] : Test denchanement de telles fonctions, tests de bout en bout ; tests de paramtrage ;
 les tests aux limites de valeur (vri- Tests dendurance ; tests avec simulation dans tel environnement, etc.
fication du comportement du logiciel aux
limites des domaines de dfinition des Mthodes et techniques de tests
donnes dentre) ; Mthodes et techniques utilises, par exemple : techniques manuelles ou automatiques,
analytiques ou statistiques, tests de domaines, tests aux limites, etc.
 les tests de domaine (contrle que
les donns de sorties correspondant aux Environnements et outils de tests
diffrentes classes dquivalence dfinies Identification des outils de tests utiliss (simulateurs, outils de mesures,
sont conformes aux spcifications). comparateurs, etc.).
Si lenvironnement du logiciel nest pas le mme dans les diffrentes tapes,
description de chacun de ces environnements.
Ces techniques de base peuvent tre
compltes par dautres techniques :
 moins formelles, comme les tests par
TABLEAU II
intuition (recherche derreurs base sur
lexprience) ; TABLE DE TRAABILIT : OBJECTIFS - TYPES DE TESTS - NUMROS DE TESTS -
TRACEABILITY TABLE: OBJECTIVES TYPES OF TESTS TEST NUMBERS
 plus formelles, pour les hauts niveaux
dexigence comme les tests bass sur des Objectif lmentaire Types de tests
vrifier TN THL TR
graphes de cause effet (identification,
partir dun graphe reprsentant les rela- Objectif 1 1, 2 4, 5
tions logiques, des cas de tests qui ont Objectif 2 6 3
une grande probabilit de dtecter des Objectif 3 7, 8 9
fautes) ou les tests bass sur des auto- Objectif 4
Objectif
mates tats finis (gnration des Objectif n m m+1
ensembles de tests pour vrifier que le
programme est conforme ses spcifica- TN : Test Nominal, THL : Test Hors Limite, TR : Test de Robustesse. 1, 2,..., m, m+1 : numros des tests.
tions fonctionnelles) ;
 ncessitant un outillage spcifique TABLEAU III
pour des objectifs particuliers, par PRODUITS ISSUS DE LEXCUTION DES TESTS -
exemple axs sur la mesure de fiabilit, PRODUCTS STEMMING FROM EXECUTION OF THE TESTS
comme les tests alatoires (vrification Livrable thorique Contenu
du logiciel par la gnration de donnes
alatoires issues de lensemble des tests Rapport de tests Conditions de ralisation des tests, lments tests,
possibles). 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 tableau II prsente un format possible de tre considr dans la dfinition de ce cri-
table de traabilit. tre. Cela peut tre la dcouverte d'un
Il est souhaitable d'tablir une table de bug ou encore, d'une non-conformit
traabilit lors de lexcution des tests, 2.2.2. Critre darrt des tests majeure. La dtection d'un vnement
pour dmontrer : constituant le critre d'arrt des tests va
 que les tests rfrencs par la table Le critre d'arrt des tests traduit la poli- entraner l'arrt du groupe de tests en
sont bien documents par une procdure ; tique retenue concernant la poursuite des cours avant son terme et le passage au
 quil nexiste pas de tests qui ne soient tests sur dtection d'anomalie. Il doit tre groupe de tests suivant. Le groupe de
pas rfrencs par la table. dfini au pralable pour viter de raliser tests arrt sera raliser nouveau aprs
Les tables de traabilit fournissent une des tests inutiles, qui seront de toute faon correction.
correspondance entre les tests raliss et rejouer. Tout vnement bloquant pour
les objectifs dfinis pour ces tests. Le la suite correcte du processus de test, doit
Remarques
 la dure des tests et les efforts engags ne sont,
ENCADRE 2 en aucun cas, des critres d'arrt des tests : aucu-
ne garantie sur le logiciel ne peut tre tablie sur
Contenu des produits issus de lexcution des tests de validation - ces seules observations.
Content of the products stemming from execution of the validation tests  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
Objectifs des tests
Doivent tre dfinis en tenant compte de la rfrence vidence des dfaillances.La modification de l'qui-
(identification des exigences, paragraphe dun document, etc.)et forment une partie des objectifs pe de tests, ou la mise en place de nouveaux outils,
gnraux de la planification des tests. augmente souvent le nombre d'erreurs dtectes.
Seule la non-diminution doit tre prise en compte
Environnements et outils de tests utiliss comme un lment bloquant pour l'valuation.
Peut tre fourni par rfrence la documentation de dfinition des tests.
A complter par les informations concernant ltalonnage des appareils de mesure  Les mesures de taux de couverture pourraient
(donnes de calibration), le cas chant, et par les carts au plan de test. tre un critre d'arrt s'il tait possible d'valuer la
probabilit de prsence de fautes non dtectes.
Donnes et / ou signaux en entre Elles seront cependant prises en considration
A fournir avec leur squencement et leur valeur.
Si les tests sont automatiss, ces informations peuvent prendre la forme denregistrements numriques comme un des lments de l'valuation.
condition de disposer des rgles et moyens pour les interprter.
En fait, l'arrt des tests se fait suite
Donnes et/ou signaux attendus en sortie l'analyse des vnements redouts au
Idem ci-dessus.
niveau systme et des aspects qui ne sont
Mode opratoire couverts par aucune des tapes de tests.
Suite des actions raliser pour mener le test. De cette analyse, on dduit si le risque li
Critres de russite cette non-couverture est acceptable et
Implicitement, lobtention des donnes et/ou signaux attendus est un des critres. conforme aux exigences applicables.
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.
2.2.3. Produits issus
Essais raliss de l'excution des tests
Peuvent tre fournis par rfrence aux procdures de tests.
A complter par les carts au plan de test, le cas chant (tests non excuts).
Les remarques du 2.1.3 restent appli-
Chronologie des essais cables aux livrables issus de l'excution
Dates effectives des diffrents essais, ordonnancement des essais. des tests. Le tableau III donne le contenu
Faits marquants souhait pour les rapports de tests.
cart lordonnancement prvus, abandons de certains tests, etc..
Peut faire lobjet dun document spar dit journal de test . 2.2.4. Exemple des tests
Dtail des rsultats obtenus
de validation
Pour chaque test, signaux et/ou donnes en sortie constats (valeurs et squencement) .
Ces rsultats peuvent prendre la forme denregistrements numriques, Lencadr 2 dtaille le contenu des
condition que les rgles et moyens de les interprter soient disponibles. livrables (rapports de tests) issus de la
Liens avec la gestion de modification phase d'excution des tests de validation.
Pour chaque test en chec, lien vers la demande de modification correspondante. Les informations sur les objectifs de tests,
les environnements et outils de tests utili-
Bilan des non-conformits ss, etc., sont requis pour une bonne
Liste synthtique des non-conformits dtectes, avec leur impact sur la scurit .
comprhension des rapports de valida-
Preuve de couverture des tests tion. On notera qu'il doit y avoir autant de
Par exemple, une liste des tests lmentaires et une rfrence croise rapports que de versions fournies.
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  Evaluer le taux de couverture atteint La vrification du logiciel est un des
par analyse des rsultats de tests. moyens qui doit obligatoirement tre mis
La vrification des tests doit dmontrer en uvre pour traiter ce problme et vi-
que les objectifs de test sont atteints. Elle  Etablir l'acceptation ou le refus des ter l'introduction de fautes. Les exigences
consiste analyser les produits de la rsultats de la phase, en prenant en comp- prsentes en annexe permettent de s'as-
phase vrifier (voir exemple des tests de te les justifications de divergences tablies surer que cette vrification a effectivement
validation) pour : lors de l'excution des tests. t ralise et qu'elle est efficace.

 Etablir la traabilit des tests raliss Relations avec la gestion de configuration Les tests sont la composante principale
pour chacun des types de tests dfinis, et des modifications de la vrification. Pour dtecter un maxi-
compte tenu des objectifs. Lors de la vrification,la gestion de configuration et mum de fautes, ces tests doivent tre
des modifications doit permettre de sassurer que conduits en suivant une dmarche qui
Il est ncessaire d'tablir la traabilit au les tests ncessaires ont effectivement t rali- dbute par la dfinition pralable des
fur et mesure de la ralisation des tests ss : objectifs de tests et de la stratgie adopte
afin d'optimiser la phase de vrification conformment ce qui tait prvu (cest--dire pour atteindre ces objectifs, pour finir par
des tests pour laquelle cette traabilit est par rapport une version rfrence des documents la dmonstration que ces objectifs sont
ncessaire. de planification de test et de dfinition des tests) ; satisfaits.
Si la matrice de traabilit n'existe pas, sur la version de logiciel sur laquelle porte le pro-
le contenu de chaque procdure de tests cessus d'valuation. La rflexion induite par cette dmarche
doit tre analys pour tablir la matrice. impose au concepteur d'apprhender le
Cette valuation doit tre affine en exa- processus test dans sa globalit, sans se
minant sur le fond les procdures pour C ONCLUS I ON focaliser sur la seule phase d'excution.
sassurer que : Le logiciel zro dfaut n'existe pas. La Cette rflexion constitue une condition
 les tests sont valides, pertinents et prsence de fautes logicielles systmatiques pralable indispensable pour russir les
reproductibles ; introduites la conception d'un dispositif tests d'un logiciel (en termes d'efficacit
 les tests couvrant un objectif donn programm doit donc tre considre avec de dtection) et minimiser ainsi les risques
sont rellement probants pour lobjectif ; beaucoup d'attention, en particulier lorsque d'apparition de dfaillances dangereuses
 les mthodes de test spcifies lors de les consquences de ces fautes peuvent en exploitation.
la planification des tests sont bien utilises. influer sur la scurit d'un dispositif.

BIBL I OGRAPHI E

1. Directive 98/37/CE du 22 juin 1998 relative au In : 10e colloque national de fiabilit et de mainte- 11. CEI 61508 Scurit fonctionnelle des systmes
rapprochement des lgislations des tats membres nabilit (actes). Saint-Malo, oct. 1996, pp. 1088- lectriques, lectroniques, lectroniques program-
relatives aux machines. Journal Officiel des 1102. mables relatifs la scurit. Parties 1 7. Genve,
Communauts Europennes, n L. 207 du 23 juillet CEI, 1998.
1998, pp. 1-46. 6. GEOFFRY J.C., MOTET G. Sret de fonction-
nement des systmes informatiques. Paris, Inter 12. STSARCES Project (n SMT4-CT97-2191)
2. EN 954-1 Scurit des machines. Parties des Guide to evaluating software quality and safety require-
Editions, 1998, 349 p.
systmes de commande relatives la scurit. Partie 1 : ments. WP 1.2/1b Final Report. Nancy, INRS, dc.
Principes gnraux de conception. Paris - La Dfense, 7. LAPRIE J.C. Guide de la sret de fonctionne- 1999, 80 p.
AFNOR, juil. 1996, 46 p. ment. Toulouse, ditions Cpadus, mai 1995, 324 p.
13. STSARCES Project (n SMT4-CT97-2191)
3. VAUTRIN J.P., CHARPENTIER P., VIGNERON 8. Projet europen STSARCES Mthodes de valida- Guide for the construction of software tests. WP 1.2/2
C. La scurit en machinerie. Introduction au concept tion du niveau de scurit des systmes lectroniques. 4e Final Report. Nancy, INRS, dc. 1999, 50 p.
de catgorie. Cahiers de Notes Documentaires - PCRD. Contrat n SMT4-CT97-2191, nov. 1997, 28 p.
Hygine et scurit du Travail, 1996, 163, Points de 14. MYERS G.J. The art of software testing. New
repre, pp. 255-262. 9. CHARPENTIER P., MENAGER P. L'vitement York, John Wiley & Sons, 1979, 177 p.
des fautes logicielles par la qualit. Cahiers de Notes
4. Mode de dfaillance des circuits intgrs : constats Documentaires - Hygine et scurit du Travail, 15. BEIZER B. Software testing techniques, 2e d.
des problmes poss. Nanterre, Institut de Sret de 1997, 167, ND 2049, pp. 249-259. Boston, International Thomson Computer press,
Fonctionnement, , Document interne (groupe de 1992, 549 p.
travail MDCI), 1994, 15 p. 10. STSARCES Project (n SMT4-CT97-2191)
Software quality and safety requirements. WP 1.2/1a 16. XANTHAKIS S., MAURICE M., DE AMESCUA
5. CICCOTELLI J., BUCHWEILLER J.P. Analyse Final Report. Nancy, INRS, dc. 1999, 35 p. A., HOURI O., GRIFFET L. Test et contrle des logi-
et certification des composants de scurit machines. ciels. 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 Classification du logiciel : le produit logiciel destin assurer les
STSARCES [10]. (ou certaines) fonctionnalits du systme tant dfini, il s'agit de dter-
miner le niveau d'exigences fixer en fonction de la classification du
systme.
De mme que pour les aspects systme, certaines dcisions d'ar-
A1. DTERMINATION DU NIVEAU DE CRITICIT chitecture du systme ou de conception des logiciels sont prendre en
D'UN LOGICIEL considration afin de dterminer si elles affectent le niveau d'exi-
gences logiciel retenu.
Les exigences du document Software quality and safety require- Par exemple, les logiciels versions multiples dissimilaires (ou pro-
ments sont modules en deux niveaux (1, 2) selon le niveau de critici- grammation N-versions ), technique de conception qui consiste ra-
t des fonctions assignes au logiciel. Le niveau 2 correspond aux exi- liser deux ou plusieurs composants logiciels assurant la mme fonction
gences les plus fortes pour les logiciels concerns par ce document. d'une manire pouvoir viter certaines sources d'erreurs communes
La dtermination du niveau de criticit du logiciel dcoule d'ana- (introduction d'une htrognit par programmation par des per-
lyses de sret de fonctionnement de l'ensemble du systme. Elle suit sonnes diffrentes, utilisation de langages diffrents,...), permettent de
des principes largement fonction du domaine d'application, du type de limiter l'impact des erreurs ou de dtecter les dfauts.
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). A2. EXIGENCES DE VERIFICATION
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, Le niveau ainsi dtermin permet d'tablir la liste des exigences l-
peuvent nanmoins tre fournies, afin de guider la dtermination du mentaires applicables au logiciel considr. Trois degrs d'exigences
niveau d'exigences retenir. sont fixs pour retenir ou non une exigence en fonction du niveau :
E (Exige) : son application est systmatique pour le logiciel
Classification du systme : la structure du systme tant dfinie concern,
ainsi que les conditions oprationnelles et environnementales, il s'agit C (Conseille) : son application est recommande sans tre
d'identifier les types de dangers de ce systme (dans tous ses modes de impose,
fonctionnement) ainsi que les cas de pannes ou d'utilisations errones / (pas d'exigence) : son application est laisse l'apprciation du
du systme et leurs consquences. concepteur.
Cette classification doit prendre en compte des facteurs d'ajuste- Les textes en italique associs aux exigences sont des commentaires
ment tels que l'architecture du systme, les redondances matrielles ou informatifs servant prciser l'objectif de ces exigences, la manire de
des restrictions d'utilisation ventuelles. les apprhender et les limitations ventuelles d'application.

Facteurs Facteurs
d'ajustement d'ajustement
Niveau
Risques Classification Classification
d'exigence
Environnement du systme du logiciel fix au
Niveau logiciel
Consquences des d'intgrit
pannes du systme du systme

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. VERIFICATION REQUIREMENTS

No Exigences gnrales de vrification Niv. 1 Niv. 2


1 L'valuation de la conformit du logiciel aux prsentes exigences doit E E
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.

2 L'valuation de la conformit du logiciel aux prsentes exigences E E


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.

3 Un rapport de vrification doit tre tabli pour chaque activit de C E


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
No Exigences sur les revues internes Niv 1 Niv. 2
sur les revues internes
4 Une revue (avec lanalyste) de spcification doit se tenir en fin de C E
Les revues internes permettent au concep- phase de spcification du logiciel.
teur de s'assurer, des points cls de l'avan- Les activits d'analyse et de vrification des spcifications du logiciel
cement du dveloppement, que le produit doivent :
atteindra ses objectifs. - vrifier l'exhaustivit et l'adquation des spcifications du logiciel
par rapport aux spcifications du systme.
Cf. tableau A-I : exigences nos 4 7. - 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.

5 Les activits d'analyse et de vrification de la conception du logiciel E E


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.

6 Une revue externe (avec lanalyste) de validation doit se tenir en fin E E


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) A2.3. Exigences sur la vrification


EXIGENCES DE VRIFICATION - du code
VERIFICATION REQUIREMENTS
Cette vrification correspond la premire
tape de vrification du code aprs son cri-
No Exigences sur les revues internes (suite) Niv. 1 Niv. 2 ture. Il s'agit d'une vrification statique ,
7 Le rsultat de chaque revue doit tre document et archiv. Il doit E E c'est dire base d'inspections, lectures croi-
comprendre la liste des actions dcides en revue et la conclusion ses, etc. C'est ensuite que seront ralises
de la revue (dcision ou non de passer l'activit suivante).
les tapes de vrification dynamique (tests
Les activits dcides en revue doivent tre suivies et traites.
unitaires, intgration, validation) qui consti-
tueront le principal moyen de vrification.
No Exigences sur la vrification du code (source et donnes) Niv. 1 Niv. 2 Ces vrifications comprennent des vrifi-
cations du code et des donnes.

8 La vrification du code (analyse statique) doit assurer que le code est C E Cf. tableau A-I : exigence n 8.
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
A3. EXIGENCES SUR LE TEST DU
LOGICIEL
EXIGENCES SUR LE TEST DU LOGICIEL -
SOFTWARETEST REQUIREMENTS
A3.1. Exigences gnrales
No Exigences gnrales sur le test du logiciel Niv. 1 Niv. 2
Il est important, avant d'crire les pre-
9 La stratgie de vrification du logiciel aux diffrentes tapes de dve- C E
mires fiches de tests, de dcrire, dans un
loppement, ainsi que les techniques et outils utiliser pour cette
vrification doivent tre dcrits dans un plan de test avant de les Plan de tests, une stratgie de tests indiquant
mettre en uvre. Cette description doit concerner a minima : la dmarche retenue, les objectifs que l'on se
- l'identification du logiciel ou des constituants logiciels relatifs la donne en termes de couverture de tests, les
scurit soumis validation avant mise en service, environnements et techniques spcifiques qui
- l'organisation des activits de vrification (intgration, validation...) seront utiliss, les critres de succs de test...
et les interfaces avec les autres activits de dveloppement du logiciel, Les objectifs de tests doivent tre adapts
- l'indpendance de la vrification s'il y a lieu : la stratgie de vrifica- au niveau d'intgrit de sret du logiciel, au
tion doit tre labore, mise en uvre et les rsultats des essais type de logiciel, aux enjeux que le logiciel
doivent tre valus de manire indpendante (personne, service ou
organisme) dans la mesure o la taille de l'quipe de dveloppement
reprsente... ; en fonction de ces critres, on
le permet, pourra dduire les types de tests raliser :
- les mthodes et outils de vrification (revue, analyse avec liste de tests fonctionnels, tests aux limites, tests
contrle, types d'essais...) hors limites, tests de performance, tests en
- l'environnement de vrification (quipements de test, mulateur...) charge, tests de pannes des quipements
- la manire de contrler les rsultats des essais. externes, tests de la configuration..., ainsi que
- matrice de traabilit, fournissant une correspondance entre les tests l'ensemble des objets devant tre couverts
raliser et les objectifs de tests dfinis. par les tests : tests des modes de fonctionne-
ment, test des fonctions de sret, test de
Un seul document (plan de test par exemple) peut rpondre aux exigences
de planification de plusieurs activits de vrification (tests unitaires, chaque lment de spcification...
intgration, validation). Ces documents peuvent, s'il y a lieu, faire rfrence
des procdures ou instructions gnrales applicables tous les projets Cf. tableau A-II : exigences nos 9 12, page
logiciels, en complment des dispositions spcifiques au projet. suivante)
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.
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 Exigences gnrales sur le test du logiciel (suite) Niv. 1 Niv. 2

10 La vrification d'une nouvelle version doit comporter des tests E E


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.

11 Les directives pour la rdaction des procdures de test doivent C E


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 C E
(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 N Vrification des spcifications du logiciel Niv. 1 Niv. 2


aux tests de validation
13 La couverture des tests doit tre explicite dans une matrice E E
de traabilit et respecter les exigences suivantes :
Les tests de validation sont la composante
- chaque lment de spcification doit tre couvert par un test
principale de la vrification des spcifications de validation, y compris les mcanismes de scurit,
du logiciel. - il doit tre possible de vrifier le comportement temps rel
du logiciel dans tous les modes oprationnels.
Cf. tableau A-II : exigences nos 13 et 14. De plus, la validation doit tre effectue dans des conditions reprsen-
tatives 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.

14 Les rsultats de la validation doivent tre enregistrs dans un rapport E E


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) A3.3. Exigences relatives aux


tests dintgration
EXIGENCES SUR LE TEST DU LOGICIEL -
SOFTWARETEST REQUIREMENTS L'objectif de cette vrification est centr
sur le bon assemblage des modules et sur les
N Vrification des spcifications du logiciel Niv. 1 Niv. 2 relations mutuelles entre les composants logi-
ciels. Elle permet de rvler les erreurs du
14 La seconde exigence a pour objectif de garantir que chaque version livre
type :
a t valide, dans sa version ultime. Par contre, l'exigence n'impose pas une
validation complte pour chaque modification incorpore dans une version : initialisation incorrecte des variables et
une analyse d'impact peut, dans certains cas, justifier une validation partielle. des constantes,
erreurs dans le passage de paramtres,
N Vrification de la conception du logiciel Niv. 1 Niv. 2 altration de donnes, en particulier de
15 Les tests d'intgration du logiciel doivent permettre de vrifier : C E donnes globales,
- le squencement correct de l'excution du logiciel, rsolution numrique de bout en bout
- les changes de donnes entre modules,
inadquate,
squencement incorrect d'vnements
- le respect des performances,
et d'oprations.
- la non altration des variables globales.
Les tests d'intgration du logiciel sont la
La couverture des tests doit tre explicite dans une matrice de traa-
composante principale de cette vrification.
bilit fournissant une correspondance entre les tests raliser et les
objectifs de tests dfinis.
Cf. tableau A-II : exigences nos 15 17.
16 Les modifications du logiciel, ralises durant l'intgration du logiciel, C E
doivent tre analyses pour identifier l'impact sur les modules concer-
ns et la ncessit ventuelle de ritrer certaines vrifications.
A3.4. Exigences relatives aux
Tous les tests raliss doivent tre reprsentatifs du logiciel final. tests unitaires
Une modification du code en cours d'essais peut invalider les rsultats
L'objectif des tests unitaires est centr sur
d'essais antrieurs.
le module logiciel et sa conformit par rapport
17 Les rsultats de l'intgration doivent tre enregistrs dans un rapport C E la conception dtaille. Cette activit, indis-
de test d'intgration du logiciel, qui doit contenir a minima : pensable pour des logiciels complexes et de
- la version du logiciel intgr, taille importante, est seulement conseille
- la description des tests raliss (entres, sorties, procdures), pour les logiciels de petite taille auxquels
- les rsultats des tests d'intgration et leur valuation. s'adresse le prsent document. Cette confor-
mit peut galement tre dmontre par des
techniques statiques (relecture de code par
exemple).
Cette phase de vrification permet de
rvler les erreurs du type :
N Vrification de la conception dtaille Niv. 1 Niv. 2
inaptitude d'un algorithme satisfaire
18 Chaque module logiciel doit tre soumis des essais vrifiant au / C une spcification du logiciel,
moyen de donnes fournies en entre, que le module remplit les
oprations de boucle incorrecte,
fonctions demandes dans la conception dtaille.
dcision logique incorrecte,
La couverture des tests doit tre explicite dans une matrice de
traabilit fournissant une correspondance entre les tests raliser
inaptitude traiter correctement des
et les objectifs de tests dfinis. combinaisons valides de donnes d'entres,
rponses incorrectes des donnes
19 Les rsultats des essais du module doivent tre consigns dans un / C d'entres manquantes ou altres,
rapport comprenant a minima :
violation de limites de tableaux,
- la version du module en essai, squence de calcul incorrecte,
- les entres appliques, prcision, justesse ou performances
- les rsultats attendus et obtenus, inadquates d'un algorithme.
- l'valuation des rsultats (essai positif ou non).
L'objectif est d'assurer que chaque module est vrifi dans sa dernire version Cf. tableau A-II : exigences nos 18 et 19.
et que l'essai sera reproductible (au titre de la non-rgression par exemple).


JOUVE - Paris

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