IV.2.2. Tests unitaires
Ces tests permettent de vérifier individuellement que
chaque sous-ensemble du
logiciel est implémenté conformément aux
spécifications. En effet, Pour tester notre application nous avons
sélectionné les données que nous jugeons
représentatives des situations cernées dans notre travail. Cette
activité consiste à tester les résultats de
l'implémentation pour s'assurer du bon déroulement des
fonctionnalités du système.
IV.2.2.1 Test du cas d'utilisation «
Authentification »
A. Données types
L'utilisateur fournit au système le login et mot de passe
et valide les données par le
bouton connexion.
Pseudo (code user) : fred
Mot de passe : fred
B. Résultats obtenus
Le système ouvre le menu général de
l'application avec tous les sous menus.
C. Analyse et discussion des résultats
Le login et mot de passe doivent préalablement exister
dans la base de données.
Si l'utilisateur entre un mot de passe qui n'existe pas dans
la base, le système lui demandera le mot de passe jusqu'à ce
qu'il entre le bon. Mais au cas où il entre un login sans respecter la
casse, le système n'activera pas l'application et par conséquent
les me nus ne seront que désactivés.
Figure 21 : Formulaire de
connexion à l'application pour le cas d'utilisation
«
authentification »
64
IV.2.2.3. Test du cas d'utilisation « Ajouter un
utilisateur »
A. Données types
L'administrateur est le seul à ajouter les
utilisateurs, sur ce il fournit au système le code de l'utilisateur, le
nom, le sexe, l'adresse, le droit ou autorisation, le pseudo et mot de
passe.
Numéro
|
Nom
|
Postnom
|
Sexe
|
Adresse
|
Droits
|
Pseudo
|
MotPass
|
GES003
|
Maliro
|
Fabrice
|
Masculin
|
Butembo
|
Lecture
|
Fab
|
Fab1072
|
|
Tableau 2:Données test pour le cas
d'utilisation « ajouter un utilisateur »
B. Résultats obtenus
Figure 22:Capture d'écran du résultat
d'ajout d'un utilisateur
Lorsqu'il clique sur sauver, le système lui affiche dans
un datagrid les données qu'il vient de saisir et s'il désir les
modifier ou supprimer, les recettes y relatives sont déjà
prévues.
C. Analyse et discussion des résultats
Le système sauvegarde dans la base de données les
informations saisies et affiche leur aperçu à chaque fois qu'il
charge ce formulaire. Le numéro du gestionnaire est unique, aucune
duplication n'est permise sinon un message d'erreur.
65
IV.2.2.4 Test du cas d'utilisation « éditer
une facture de vente »
A. Données types
Le système par le truchement du formulaire de ventes
demande à l'utilisateur logué de fournir les
éléments ci après :
|
Numéro vente
|
Date vente
|
Réf.facture client
|
Code produit
|
Code tva
|
CodEx
|
Prix vente
|
Qte vendue
|
|
V001
|
26/07/2011
|
FAC004
|
31110000
|
T70V
|
2011
|
700
|
4
|
|
V001
|
26/07/2011
|
FAC004
|
31130000
|
T70V
|
2011
|
50
|
2
|
|
V002
|
26/07/2011
|
FAC004
|
31120000
|
T70V
|
2011
|
900
|
10
|
Tableau 3 : Données test
pour le cas d'utilisation « éditer une facture de ventes
»
B. Résultats obtenus
L'impression des éléments ci-dessus sera faite sur
du papier en y ajoutant le Total Hors Taxe, Toutes Taxes Comprises, Tva pour
chaque ligne de vente en cumul.
Figure 23 : Capture d'écran du résultat
de l'application de l'impression d'une facture de vente
C. Analyse et discussion des résultats
Pour éditer une facture de vente, le système
doit vérifier d'abord si le client, le produit, l'exercice, le bon de
commande attaché à la facture, le Taux de Tva existent
préalablement, sinon l'édition de la facture ne sera effective.
Et cette recherche se fait par les listes de choix faisant remarquer
l'existence d'un élément. L'on peut saisir dans la liste voulant
éditer la facture de vente avec les données non réelles,
le système par les contraintes d'intégrité et de
référence signalera une erreur.
66
| 
