Critères d’évaluations des langages de programmation:

1. Domaine d’application
2. Consistance syntaxique
3. Abstraction
4. Coût: de formation, de développement, de compilation,
d’exécution, et de maintenance.

Conventions de programmation: sont introduites pour

augmenter la lisibilité des sources des programmes.
1. Variables vs constantes: les noms utilisés pour designer les
variables ou les constantes doivent être des substantifs.
Le premier caractère d’une constante est une majuscule.
Le premier caractère d’une variable est une minuscule.
2. Identificateurs doivent être:
 le plus significatif possible
 Pas trop long, pas trop court
 Cohérents par rapport au contexte.
Il est possible d’utiliser plusieurs mots pour former un
identificateur significatif.
Chaque début de mot sera indiqué par une lettre majuscule, sauf
pour le premier qui respectera la règle des
variables/constantes.
Chaque élément de l’identificateur sera séparé par un caractère
souligné ou encore par le caractère moins lorsque cela est
syntaxiquement possible.
Il est possible d’utiliser des abréviations en éliminant les voyelles
centrales des identificateurs pour ne conserver que les
consonnes.
Les variables muettes: tels que les indices de boucles, les index
de tableaux, les copies temporaires… dans ce cas on utilisera des
identificateurs mono lettré ou une lettre et un chiffre.
I,j,k,l,m,n pour les variables muettes de type entier.
v,r,x,y,z pour les variables muettes de type réel.
b type booléen.

Les commentaires: doivent être claires et concis et doivent

apparaître dans:
Chaque ligne de déclaration
Chaque début de bloque logique
Chaque entête de procédure.

Les procédures: leurs noms devra être un verbe à l’infinitif.

 Tester un système est une opération coûteuse qui peut
prendre jusqu’à la moitié des coûts de développement.

 Les tests ne permettent pas d’établir qu’un programme

est correct. Il sert à démontrer la présence des erreurs
et non pas leur absence.

I. Types de tests
1. Tests unitaires: permettent la vérification du
fonctionnement correct des procédures constituant un
module et vérifier la bonne coopération des fonctions
d’un même module.
2. Tests d’intégration: après avoir testé unitairement
les modules, il faut tester leur intégration
progressive jusqu’à obtenir le système complet.
test Alpha: l’application est mise dans des
conditions réelles d’utilisation au sein de l’équipe
de développement (simulation de l’utilisation
finale).

 Tests de réception: sont effectués par les clients

dans leurs propres environnement pour vérifier
que les dispositions contractuelles sont bien
respectées.
Tests Bêta: distribution du produit sur un groupe de
clients avant le déploiement de la version définitive.

4. Tests de non régression: à la suite de la modification

d’un logiciel, un test de non régression a pour but de
montrer que les autres parties du logiciel n’ont pas été
affectées par cette modification.

II. Stratégies de test

 Tests descendants
 Tests Ascendants
1. Tests dynamique:
 soit un programme PR qui calcule le résultat r à partir des
données d.
 un test est composé d’un couple(vd,vr) ;
 l’application du test (vd,vr )à un programme PR consiste à
exécuter PR avec Vd comme données en entrée, et vérifier si le
resultat r obtenu par l’exécution est identique à la valeur Vr.
 Si r=Vr alors le test réussi sinon on dira qu’il a échoué et le
programme PR contient une erreur.
 Les jeux de tests doivent aussi faire fonctionner le système sur
des données incorrectes et s’assurer qu’il se comporte de la
façon prévue.

1.1 tests fonctionnels (en boite noire):on considère seulement la

spécification de ce que doit faire le programme sans
considérer sa structure interne.
La technique consiste à analyser les valeurs frontières et le
regroupement en classes d’équivalences.
1. On détermine les classes d’équivalence.
2. On choisit un représentant de chaque classe de façon qu’on
ait une grande probabilité de détecter une erreur (les valeurs
limites sont les plus utiles).

Parfois, il convient de considérer des classes d’équivalence liées

aux sorties et essayer de déterminer les entrées qui
permettront de générer des résultats appartenant à ces classes
de sorties.
1.2 tests structurels (en boite blanche): on tient compte de la
structure interne du module.

Graphe de contrôle: c’est un graphe qui résume les structures de

contrôle d’un programme.

Un graphe de contrôle permet de construire les chemins Il y peut y

avoir beaucoup de chemins possibles et certains chemins
impossibles.
Graphe de contrôle

C If C Then S1 else
Bloc S2;
d’instructions
S1 S2
sequentielles

C
Case C of

L1: S1; C
S1 Sn L2: S2; If C Then S1;
…
Ln: Sn; S1
end;
 C
While C do S; I=1
TF
For loop:
S I <=n
yes no for I = 1 to n do S;
S

S1 Do loop:

do S1 until C;
F
C
T
Différents critères pour préparer les jeux de tests:

1. Critère de couverture des instructions: tester toutes les

instructions (noeuds) au moins une fois.

2. Critère de couverture des conditions: tester toutes les conditions

possibles au moins une fois.

3. Critère de couverture des chemins: tester tous les chemins

possibles en passant de 0fois a i fois dans chaque boucle : (i-
chemins)
Complexité cyclomatique : definie le nombre
de chemins dans le programme. C’est une
metrique qui determine la complexité d’un
logiciel.
V(G) = E - N +2
E: nombre d’arcs du graphe de controle.
N: nombre de noeuds du graphe de controle
2. Tests statiques: la recherche des erreurs consiste à inspecter
le code et en s’aidant d’une liste des défauts les plus
courants:

 L’utilisation de variables non initialisées

 Les sauts dans les boucles

 Les affectations incompatibles

 Les boucles infinies

 Les débordements de tableaux

 Les mauvaises correspondances entre paramètres formels et

effectifs.