Guide tests fonctionnels

Guide pour la préparation et l’exécution de tests fonctionnels
Page 1 sur 18
GUIDE POUR LA PRÉPARATION ET
L’EXÉCUTION DE TESTS
FONCTIONNELS
PAR CHRISTIAN BERGERON - cvcby@yahoo.com

Page 2 sur 18
TABLE DES MATIÈRES
1. Introduction................................................................................................................................................................ 3
2. Sommaire de la stratégie globale de tests................................................................................................................... 3
3. Environnements pour les tests.................................................................................................................................... 4
4. Les jeux d’essais : Tests reproductibles et régression ................................................................................................ 4
5. Structure des cas de tests - Un processus « top down »............................................................................................. 5
5.1 Règles fonctionnelles, un prérequis essentiel .................................................................................................... 5
5.2 Thèmes et Fonctionnalités ................................................................................................................................ 5
5.3 Domaines de tests .............................................................................................................................................. 6
5.4 Sous-domaines – Croisement des N° de cas tests avec les N° de règles............................................................ 6
5.5 Cas cibles........................................................................................................................................................... 6
5.6 Cas détaillés....................................................................................................................................................... 7
5.6.1 Les prérequis .......................................................................................................................................... 7
5.6.2 Transactions à exécuter .......................................................................................................................... 7
5.6.3 Les données ............................................................................................................................................ 8
5.6.4 Résultats attendus ................................................................................................................................... 8
5.7 Jeux d’essais ...................................................................................................................................................... 8
6. Campagnes de tests .................................................................................................................................................... 9
7. Consignes générales dans la préparation de cas de tests ............................................................................................ 9
8. Conclusion................................................................................................................................................................ 10
ANNEXE – Exemples du processus de préparation de cas de tests ................................................................................. 11
A. Découpage en domaines / sous-domaines........................................................................................................ 12
B. Cas Cibles........................................................................................................................................................ 13
C. Prérequis et Jeux d’essais détaillés .................................................................................................................. 14
D. Cas détaillés et résultats attendus..................................................................................................................... 16

Page 3 sur 18
1. Introduction
Ce document se veut un guide pour aider les gestionnaires ainsi que les équipes de tests dans la préparation et l’exécution
des tests fonctionnels. Outre quelques commentaires sur la stratégie globale de tests, ce document traite exclusivement des
tests fonctionnels.
Vous n’y trouverez pas une méthodologie complète avec des modèles et des plans d’actions. Il s’agit plutôt de principes de
base, très terre à terre, qui peuvent être la fondation d’une méthodologie de tests. Ce qui est dans ce document s’applique à
n’importe quelle plateforme, domaine fonctionnel ou industrie.
Lorsque j’ai utilisé ces principes dans mon travail, en tant que gestionnaire des tests, j’avais des équipes de tests
principalement composées d’experts métiers et non pas d’informaticiens. Donc peu d’expérience en analyse structurée et en
processus de développements et de tests. C’est pour répondre à cet état de fait que j’ai originalement documenté les
principes de bases pour les tests fonctionnels TI, car si on n’a pas assimilé la base, il n’y a aucun gabarits ou modèles qui
fonctionne.
Tout ce que vous verrez ici a été mis en application avec succès dans la vraie vie, où il y a une pression constante au niveau
des délais et des coûts. Les objectifs à respecter dans l’application des ces principes sont donc : facile à assimiler,
organisation simple et mise en œuvre rapide.
En tant que gestionnaire des tests, mon équipe à réussi à diminuer le nombre d’erreurs non détectées de 90% simplement en
appliquant ces quelques principes de base.
2. Sommaire de la stratégie globale de tests
Dans le cycle de vie d’un projet de développement, il y a généralement 4 grandes étapes de tests :
1. Les tests unitaires, ou tests de programmation
Les tests de programmation ont, dans un premier temps, pour but de vérifier la mécanique, l’ergonomie et
la présentation des programmes.
Dans un deuxième temps on s’assure que toutes les règles sont implantées.
Dans un troisième temps, le programmeur s’assure du bon fonctionnement des interfaces, rapports &
traitements.
Le programmeur a la responsabilité d’effectuer les tests unitaires et est responsable de la qualité de ceux-
ci. Il est important de savoir que les étapes suivantes des tests prennent pour acquis qu’aucun programme
ne sera livré sans avoir été adéquatement testé unitairement. Il n’y aura donc pas de post validations des
tests unitaires.
En général le programmeur devra préparer ses propres données de test. Par contre, pour certains cas
exigeant des données plus complexes, les données seront fournies par l’équipe de tests fonctionnels.
2. Les tests fonctionnels
Il s’agit ici de tester les fonctionnalités avec la vision du concepteur. On est préoccupé par l’aspect d’un
thème fonctionnel spécifique plutôt que par l’aspect programmation ou l’aspect global de l’application.
3. Les tests intégrés ou tests de validations ou de conception
Ici on valide l’ensemble du système en fonction des processus opérationnels. L’on s’approche de la vision
de l’utilisateur et il faut donc penser en terme de cycles d’opérations, tenir compte de la séquence
d’exécution et du facteur temps (traitement de jour, de nuit, hebdo, fin de mois, etc.). Un cycle est
composé de données de bases, d’une chaîne d’opérations et d’un résultat.
Le transfert d’information entre les modules fonctionnels doit utiliser les données générées par les
fonctionnalités en amont, et par conséquent, alimenter celles qui sont en aval. Les jeux d’essais seront
donc des données de bases qui devront cheminer dans tout le processus.

Page 4 sur 18
4. Les tests d’acceptation ou recette utilisateurs
Il s’agit ici de la recette utilisateurs, où ils valideront le produit dans son ensemble en fonction de leurs
processus réels.
A noter que le terme « tests intégrés » est utilisé différemment selon les organisations. Pour certains il signifie les tests
fonctionnels (étape 2) et pour d’autres il signifie les tests de validations (étape 3). Dans ce document, les tests intégrés
correspondent à l’étape 3.
3. Environnements pour les tests
Les tests unitaires sont faits sur l’environnement de développement. Les tests fonctionnels sont faits sur un environnement
dédié et indépendant des changements faits dans l’environnement de développement.
Au cours de l’évolution du développement, le paramétrage, les programmes et les données de bases seront appelés à
changer et à évoluer. On doit donc pouvoir les transférer d’un environnement à l’autre.
Les jeux d’essais devront pouvoir être rechargés et ré initialisés afin de permettre de refaire les mêmes tests dans les mêmes
conditions. On peut envisager de créer un environnement de référence qui contiendra tous les objets requis pour les tests
mais sur lequel aucun test ou développement ne sera fait. Ceci requiert un processus permettant de copier des jeux d’essais
entre environnements.
Il est à noter que des tests de régression seront faits suites à des corrections de programmes. Dans certains cas ces tests
devront être effectués dans les plus brefs délais. Ceci exige de pouvoir charger/initialiser un environnement d’essai
rapidement. Il faut pouvoir répondre à cette contrainte.
Il est essentiel de documenter et mettre en place un processus clair et efficace permettant les transferts entre
l’environnement de développement et celui de test.
Ceci doit être fait avant de commencer la mise en place des jeux d’essais.
4. Les jeux d’essais : Tests reproductibles et régression
Chaque fonctionnalité doit être testée dans un contexte isolé et un environnement stable et reproductible à volonté. Il faut
donc des jeux d’essais prédéterminés qui pourront être rechargés à volonté.
La préparation et la mise en place de jeux d’essais représentent un effort important. La tentation est grande de sauter cette
étape et de faire des jeux d’essais à la pièce.
Avoir un jeu d’essais stable et réutilisable permet de refaire les tests suite à des changements, avec exactement le même
environnement et les mêmes données. C’est la seule façon de s’assurer que l’on a réglé un problème sans briser autre chose
(régression suite à des corrections). Quand on utilise des jeux de données qui sont faits au fur et à mesure, il devient très
difficile de détecter les régressions. Il s’ensuit généralement une situation où, suite à plusieurs corrections de code, on
découvre un peu plus tard (des fois beaucoup plus tard) que ce qui marchait avant ne marche plus.
Bien qu’il semble plus rapide de faire des jeux de données au fur et à mesure, ceci implique qu’il faut recommencer à
chaque fois. Quand vous prenez le temps de faire des jeux spécifiques avec un processus de chargement, vous y mettez plus
de temps au début, mais ensuite il est très facile et rapide de mettre en place les jeux d’essais pour refaire une nouvelle série
de tests … et refaire il y aura.

Page 5 sur 18
5. Structure des cas de tests - Un processus « top down »
Thèmes
Fonctionnalités
Domaines de tests (éclatement des fonctionnalités en règles et requirements)
Sous-domaine (regroupement des caractéristiques de domaines)
Cas cibles
--
--
--
5.1 Règles fonctionnelles, un prérequis essentiel
Avant toute chose, il est essentiel d’avoir l’ensemble des règles fonctionnelles. Règles que les programmeurs ont aussi
utilisées pour faire le développement et les tests unitaires.
Les cas de tests exécutés doivent impérativement être liés à une ou plusieurs règles spécifiques. Ainsi si on change une
règle, on sait immédiatement quels sont les cas de tests affectés. A l’inverse, si on trouve une inconsistance fonctionnelle en
exécutant un cas de tests, on sait immédiatement quelles sont les règles en causes.
Il faut toujours numéroter chaque règle fonctionnelle et chaque cas de test. Ensuite, il faut s’assurer que l’on peut facilement
faire le croisement.
5.2 Thèmes et Fonctionnalités
• Thème : Un cycle opérationnel. Un thème est composé d’une ou plusieurs fonctionnalités
• Fonctionnalité : Sous ensemble d’un thème
Exemples :
. Liste des liens entre les thèmes et fonctionnalités
Thèmes Fonctionnalités
Paiements automatiques des relevés Interface relevés/règlements auto
Remise en banque
Effets échus/ suppression du risque
Édition journal des effets
Maj. date d'échéance d'effet
Liste des liens entre les thèmes et les fonctionnalités
Cas détaillés Jeux d’essais
Programmes de chargements
et fichiers de données
Scénarios de tests :
Prérequis
Transactions à exécuter
Données transactionnelles
Résultats attendus

Page 6 sur 18
Règlements manuels Gestion du bordereau de remise en banque
Génération écritures
Saisie rapide règlements (espèces)
Maj. textes postes comptables
Situation de compte Gestion situation de compte
Calcul des intérêts
Génération des éléments de facturation
Liste des situations de compte
En tests fonctionnels on regroupe par thème et on travaille en mode boîte noire. C’est-à-dire que l’on n’utilise pas les
résultats des thèmes amont pour tester un thème aval. Les données et les fichiers d’entrées générés sont spécifiques aux tests
d’un thème en particulier.
Au niveau des fonctionnalités, sous ensemble d’un thème, on travaille en mode boîte blanche. C’est-à-dire, qu’à l’intérieur
du thème, on passe d’une fonctionnalité à l’autre en utilisant les résultats des fonctionnalités précédentes.
5.3 Domaines de tests
Le domaine de tests est un découpage de la fonctionnalité. Il s’agit d’une caractéristique à tester, comme par exemple la
sélection des pièces comptables ou la validation du calcul de taxes. Un domaine de tests peut découler d’une règle
spécifique, de plusieurs règles regroupées, d’une réalité du métier, d’un cycle opérationnel ou tout autre critère de
regroupement pertinent à ce que l’on veut tester.
Un domaine de tests s’éclate en sous domaines.
Par exemple :
Domaine :
Sélection des pièces
Sous domaines :
Sélection selon le type de pièce + DC
Sélection selon le type de client + DC
Sélection selon la date
5.4 Sous-domaines – Croisement des N° de cas tests avec les N° de règles
Les sous-domaines sont l’éclatement des domaines de tests en caractéristiques (règles fonctionnelles spécifiques).
Ici ont doit croiser les numéros de cas de tests (au niveau sous-domaines) avec les numéros de règles fonctionnelles.
Chaque sous-domaine s’éclatera ensuite en cas cibles. La numérotation des sous-domaines peut se faire par incrément de
dix sous la forme 010, 020 … Ceci facilitera l’ajout éventuel de cas.
5.5 Cas cibles
Les cas cibles sont l’éclatement des sous-domaines. C’est le dernier niveau d’éclatement. A partir de ce point, un cas cible
correspondra à un cas de test spécifique à exécuter.
Par exemple si on a comme domaine de test « Validation de pièces comptables » et comme sous-domaines :
- Sous-domaine N° 010 : Valider les sélections selon le type de pièce + DC
- Sous-domaine N° 020 : Validation par type de pièce + client

Page 7 sur 18
Les cas cibles pourraient êtres :
N° TYPE DE PIÈCE DC Résultat
010-1 Valide Valide Sélectionné
010-2 Valide Invalide Non sélectionné
010-3 Invalide Valide Non sélectionné
N° TYPE DE PIÈCE CLIENT Résultat
020-1 Valide Valide Sélectionné
020-2 Valide Invalide Non sélectionné
020-3 Invalide Valide Non sélectionné
Exemple de cas cibles à partir d’une règle de gestion :
Domaine : ASSIGNATION DES PÉRIODES
Règle de gestion : L’assignation de la période est faite selon la date de la pièce.
Analyse du cas :
La date peut :
Correspondre à la période courante
Correspondre à une période précédente
Correspondre à une période postérieure
Une période précédente ou postérieure peut :
Être ouverte
Être fermée
Sous-domaine :
Valider l’assignation des périodes et l’impact de leurs statuts sur le bon fonctionnement de l’interface
Cas cibles :
NOTE : on prend pour acquis que la période courante est toujours ouverte
Statut de la Période
correspondante
Date Résultat
ouverte = période courante période = mois de la date de pièce
< période courante période = mois de la date de pièce
> période courante période = mois de la date de pièce
fermée < période courante Erreur, pièce rejetée
> période courante Erreur, pièce rejetée
5.6 Cas détaillés
Les cas détaillés sont l’exécution des cas cibles. Il s’agit ici de traduire le cas cible en actions précises. Quelqu’un qui ne
connaît pas le sujet doit pouvoir exécuter et valider le test en suivant simplement les instructions du cas détaillé.
5.6.1 Les prérequis
Documenter les prérequis à exécuter avant de pouvoir procéder au test.
5.6.2 Transactions à exécuter
La partie traitement donne les instructions à suivre, pas à pas, pour exécuter le test. (Ex : code transaction, saisie du champ
XXXX, appel de la fonction YYYY via touche ZZZZ,…)

Page 8 sur 18
5.6.3 Les données
Lors de l’exécution des cas de tests détaillés on détermine les données requises selon :
• Les prérequis
• Les transactions à utiliser
• Les champs à saisir
Les principaux types de données sont :
• Les données d’input
Elles sont constituées de l’ensemble des données requises à la bonne exécution du cas détaillé. On
distinguera :
• Les données prérequises pour la bonne exécution du cas détaillé
Exemples : Chargement d’une plage de clients, d’écritures comptables, de factures.
• Les données transactionnelles du jeu d’essai
Exemples : Fichier en entrée dans le cadre d’un traitement d’interface, valeurs de zones à saisir
sur un traitement transactionnel, etc.
• Les données d’output
Les données d’output constituent le résultat attendu du cas détaillé. (Ex : valeurs de zones d’une écriture
comptable générée dans la cadre du cas de test détaillé)
5.6.4 Résultats attendus
Il y a ici deux règles importantes à suivre :
- Résultat clair
- Documenter et valider le résultat global de chaque cas
• Résultat clair
Il est important dans le cas détaillé de donner le résultat attendu sans ambiguïté.
• Documenter et valider le résultat global de chaque cas
Afin de permettre une meilleure détection de la régression lors de tests, la documentation des résultats attendus doit
permettre de valider le résultat total de la transaction et non pas seulement la valeur que l’on teste. Il en découle que l’on
demande aussi au testeur de valider l’ensemble, tel que documenté.
Par exemple :
Si on teste le calcul de taxes sur une facture, dans le résultat final il faut bien indiquer « tout » ce qui sera affiché
ou imprimé sur la facture (noms, items, descriptions, montant de chaque ligne, total, etc.). De cette façon, si
quelque chose d’autre a été affectée suite à une correction de code, on le détectera … même si on ne le cherche pas.
Cette règle exige plus de travail lors de la préparation des cas de tests détaillés et a souvent été remise en question. Mais il a
été démontré, que sur l’ensemble, on sauvait énormément de temps.
Parce que de cette façon nous arrivions à détecter les régressions immédiatement, nous avons diminué considérablement
le nombre de cycles tests/corrections tout en augmentant le niveau de qualité (beaucoup moins de régressions non
détectées).
5.7 Jeux d’essais
Les jeux d’essais découlent des cas de tests détaillés et comprennent l’ensemble des données, prérequises et d’exécution,
nécessaires à la bonne réalisation du test. (cf. cas détaillés).
La plupart du temps, on associera au jeu d’essai un processus de chargement via des programmes ou des outils.

Page 9 sur 18
6. Campagnes de tests
Lors des tests fonctionnels, il faut procéder à un cycle complet de tests avant de faire des corrections. Ceci permet d’obtenir
une vue d’ensemble des corrections à apporter, d’éviter le va-et-vient tests/modifications et de faciliter les tests de
régression. Ce cycle porte le nom de campagne de tests.
Une campagne correspond à :
• Une version de l’application
• Le regroupement d’une série de tests et leurs assignations à des testeurs
• Un environnement dédié pour cette campagne
• Un jeu d’essai spécifique (ou plusieurs) à charger
• Une date système
• Une fiche de résultats par testeur
A la fin de chaque campagne il faudra répertorier et regrouper les anomalies trouvées. Le responsable des tests fera alors le
suivi des corrections (programmes, règles fonctionnelles et cas de tests associés) afin de déterminer quand il sera possible de
faire une nouvelle campagne de tests.
7. Consignes générales dans la préparation de cas de tests
• Utiliser un jeu de données spécifique pour chaque cas de test. Éviter les combinaisons de plusieurs cas de tests avec les
mêmes données. Ainsi la validation s’en trouve plus simple. Si l’on combine plusieurs cas sur un jeu de données, la
validation du résultat et l’analyse d’une erreur s’en trouvent plus complexes. Finalement, et c’est ce qui arrive le plus
souvent, si on doit modifier le jeu de données pour une raison quelconque on sait quoi changer et quels en sont les
impacts sans risque d’interférer avec un autre cas de test qui pourrait utiliser ce même jeu.
• Mettre des références qui permettent d’identifier uniquement chaque enregistrement et de les lier à un cas spécifique.
Comme inclure le N° du cas dans une pièce comptable ou une description de produit. S’il y a plusieurs enregistrements
pour un cas, ajouter aussi un numéro de séquence pour bien les différencier. Ceci permet de faciliter le travail de
validation et est indispensable pour permettre l’automatisation des tests.
• Utiliser une fourchette spécifique et facilement identifiable pour les tests négatifs et les items à exclure du résultat. On
peut les identifier facilement si les références commencent ou se terminent par 99. Par exemple, si pour un test de
sélection toutes les pièces rejetées on une référence qui commence par 99 on pourra rapidement les identifier si elles ont
été incluses par erreur.
• Utiliser des fourchettes de valeurs pour regrouper les données selon les thèmes. Par exemple associer une fourchette de
N° de client spécifique à chaque thème. Le but est d’isoler les tests, afin d’éviter que quelqu’un d’autres modifie vos
données lors de l’exécution des ses tests.
• Commencer par faire des tests positifs (dont le résultat attendus est un succès) simples. Procéder ensuite à des cas
positifs plus complexes. Terminer avec les tests négatifs (cas où le résultat doit générer ou détecter une erreur)
• Voici une liste non exhaustive de divers points à considérer dans l’élaboration des cas de tests :
Validations des combinaisons de règles :
- Est-ce fonctionnellement valide ?
- Même si ça ne plante pas, est-ce que ça fonctionne comme prévu au niveau fonctionnel ?
Validation des différents niveaux de sélections et d’exclusions :
- Lors d’une sélection automatique
- Lors du balayage d’un fichier
Test de sélection nulle :
- Critère de traitement qui retourne une sélection vide (ex : sélection d'un client qui n’a aucune facture)
- Traitement d’un fichier batch vide

Page 10 sur 18
Test des cas extrêmes :
- Fourchette avec minimum plus grande que le maximum
- Valeurs autorisées
- Combinaisons inexistantes
- Valeurs nulles ou vides
- Vérifier si possible d’entrer des nombres dont une opération de totalisation sera plus grande que le
format du champ de total.
Validation des impressions : Il faut au moins imprimer 3 pages (2 pleines + partie de la troisième). Ceci parce que
la première page est souvent différente des autres pages (en-tête, haut de page et bas de page différents). Il s’ensuit
qu’il y a des différences de code entre la page 1 et la page 2. Tant pour la page elle-même que pour la gestion des
sauts de pages. La seule façon de trouver des erreurs ou des régressions, est d’imprimer au moins 3 pages.
Traitement des erreurs. Déterminez quelles sont les erreurs possibles qui pourraient être rencontrées. Ne vous
limitez pas ici, ce genre de situation arrive fréquemment en production et c’est une excellente occasion de
découvrir ce qui arrive à votre système si quelque chose d’imprévu survient :
- Saisie de données erronées
- Repasser deux fois le même fichier batch
- Présence de données erronées dans un fichier input pour batch
- Erreur de données (dates hors phase, déphasage, etc.)
- Absence anormale de données
8. Conclusion
Comme je l’ai mentionné au début de ce document, mon équipe de tests à réussi à diminuer le nombre d’erreurs non
détectées de 90% simplement en appliquant ces quelques principes de base.
Il faut se rappeler que simple n’est pas synonyme de facile. Ce qui, avant tout, a fait la réussite des nos tests c’est la rigueur
dont a fait preuve l’équipe dans la mise en application systématique des ces principes. Même quand on était sous pression,
nous avons respecté les consignes.
Des fois on perd du temps et des fois on gagne du temps. La recette gagnante est celle où on gagne plus souvent que l’on
perd lorsque appliquée systématiquement … Faut juste avoir la discipline de bien tenir la ligne de conduite.

Page 11 sur 18
ANNEXE – Exemples du processus de préparation de cas de tests

Page 12 sur 18
A. Découpage en domaines / sous-domaines
Notez ici le croisement des numéros de cas de tests avec les numéros de règles fonctionnelles
OBJECTIF / Fonctionnalité testée
ID test N° règles BESOIN
RELEVÉS
Date de RLV dans ACTI = Date comptable dans COGEST (= Date de pièce)
010 c-rlv006-trt Relevés ayant des dates différentes
Valider le texte d’en-tête
020 c-rlv009-trt Relevés de différentes périodes de couverture
Valider le type de pièce comptable et le texte du poste client des pièces RLV
030 c-rlv007-trt
c-rlv008-trt
c-rlv014-trt
Différents types de relevés
Valider le choix des clés comptables
040 c-rlv010-trt Inclure différents types de relevés selon les 4 clés comptables possibles
Valider l’enregistrement comptable dans le compte client
050 c-rlv011-trt Inclure plusieurs clients (groupes de compte différents)
Valider l’utilisation des bons comptes généraux
060 c-rlv011-trt Inclure plusieurs comptes généraux de contre partie
Valider la génération d’une contrepartie par nature comptable
070 c-rlv011-trt Inclure des cas où il y a plusieurs comptes généraux de contre partie
Vérifier l’alimentation du Critère de tri et Critères de Tri CGS dans le poste client
080 c-rlv015-trt
c-rlv017-trt
Valider le critère de tri
et le critère de tri CGS
Vérifier l’alimentation de la zone spécifique « mode de versement »
090 c-rlv016-trt Inclure des relevés à modes de versement différents (cf. DAS2)
Valider l’utilisation des bons codes CGS
100 c-rlv019-trt Inclure des cas qui alimentent les codes CGS X,C,U
Valider la procédure de vérification de « non-intégration en double » dans l’interface RLV
110 d-rlv015-prg Inclure des relevés déjà traités (prévoir de découper en 2 fichiers successifs)
Vérifier le message d’anomalie d’absence de référence pour les règlements autos
120 d-rlv018-prg Inclure relevés à mode de règlements 4,5,7 n’ayant pas de références.
Vérifier l’alimentation du mode de paiement
130 c-rlv018-trt Inclure des modes de règlements différents.
Vérifier l’alimentation du mode de versement
140 c-rlv021-prg C’est le mode de versement issue de ACTI
Vérifier l’alimentation de la date différée
150 c-rlv022-prg Le calcul de cette date dépend de la condition de paiement et du mode de règlement
Vérifier la gestion du code blocage d’intérêts
160 c-rlv023-prg La sélection de ce code blocage dépend du compte général
TVA
Vérifier l’alimentation du bon code TVA sur chaque poste de ventes (compte général)
170 c-rlv012-trt Inclure plusieurs taux de TVA sur un même relevé
Vérifier qu’un même code TVA n’apparaît qu’une seule fois sur une pièce comptable (cumul)
180 d-rlv010-prg Mettre le même code TVA sur 2 comptes généraux du même RLV

Page 13 sur 18
B. Cas Cibles
• Interface relevés
OBJECTIF / Fonctionnalité testée (Rappel)
ID test Valeurs cibles / Besoins
En-tête pièce comptable de RLV
Date de RLV dans ACTI = Date comptable dans COGEST (= Date de pièce)
DATE COMPTABLE RESULTAT
010-1 Date RLV = Date 1 DATE DE LA PIECE CREE = DATE 1
010-2 Date RLV = Date 2 DATE DE LA PIECE CREE = DATE 2
Valider le texte d’en-tête
020 La règle de gestion s’applique à ACTI et pas à COGEST
Pour COGEST, il s’agit d’un transfert zone à zone ce qui a du être vérifié en Test Unitaire
Valider le type de pièce comptable et le texte du poste client des pièces RLV
Les types de pièces varient en fonction du type de RLV (info ACTI)
Type de pièce provenant de ACTI Texte du poste client
030-1 T1 Libellé type de pièce T1
030-2 T2 Libellé type de pièce T2
030-3 T3 LIBELLE TYPE DE PIECE T3
Poste client du RLV
Valider le choix des clés comptables
La CC varie en fonction de la présence ou non de CGS et du sens de l’écriture
ENTREE RESULTAT
MODE DE
PAIEMENT
TYPE DE PIECE SENS CODE CGS CC
040-1 Quelconque RB Débit OUI 09
040-2 Quelconque RB Crédit OUI 19
040-3 3 RC Débit OUI 09
040-4 3 RC Crédit OUI 19
040-5 4 RC Débit OUI 09
040-6 4 RC Crédit OUI 19
040-7 Autre que 3 et 4 RC Débit NON 01
040-8 Autre que 3 et 4 RC Crédit NON 11
040-9 4 Autre que RC et
RB
Débit NON 01
040-10 4 Autre que RC et
RB
Crédit NON 11
Valider l’enregistrement comptable dans le compte client
Le numéro de client est une info ACTI
Groupe de comptes : CLGO, PERS, DIVR
Groupe de compte du client N° DE COMPTE CLIENT N° DE COMPTE DU POSTE CLIENT
050-1 CLGO N1 N1
050-2 PERS N2 N2
050-3 DIVR N3 N3

Page 14 sur 18
C. Prérequis et Jeux d’essais détaillés
• Fourchettes de valeurs utilisées
Entités Plage de valeurs Commentaires
Société RGA La société RGA est une copie de la société DPG
Lors de la copie, il faut préciser que le plan
comptable est aussi copié ; ainsi il n’est pas
nécessaire de recréer les plans comptables
Clients 10000 à 10999
Domaine d’activité 672
479
493
ROANNE
ST ETIENNE
VALENCE
• Chargement automatique des données
Séqu
enc.
Entités Fichiers d’input Script autotester Transaction/
programme
Commentaires
1. Clients IFRGA01.XLS ISRGA01 FD01
• Chargement manuel des données
Les données sont saisies dans les tables spécifiques selon la procédure suivante :
1. LANCER LA TRANSACTION SM31
2. SAISIR LE NOM DE LA TABLE A REMPLIR
3. CLIQUER SUR LE BOUTON GERER
4. L’ECRAN DE GESTION DE TABLE APPARAIT, CLIQUER SUR NOUVELLES ENTREES
5. SAISIR LES DONNEES TELLES QUE DANS LES TABLEAUX PAGE SUIVANTE
L’ensemble des tables à remplir est le suivant :
TABLE DES PARAMETRES DE REMISE EN BANQUE
Nom Libellé Type
ZADBQ Délai interne banque
ZADIN Délai interbancaire
ZABQP Priorité banque
ZADOC Délai DPG AVP accéléré
TABLE DES PARAMETRES DES CRITERES DE RECADRAGE
Nom Libellé Type
ZACAF Critère de recadrage chiffre d’affaire
ZAPAR Critères particuliers de recadrage
ZASOC Table paramétrage société arpège

Page 15 sur 18
• Données d’exécution du test
Fichiers d’input Fichiers d’output Script autotester Transaction/
programme
Commentaire
IZRLV01 Sans Objet Sans Objet Ce fichier est copié sous :
GARLVAR1.19981201.74.672.DAT
GARLVAR1.19981202.76.493.DAT
GARLVAR1.19981203.75.479.DAT

Page 16 sur 18
D. Cas détaillés et résultats attendus
• Interface relevés – Règlements auto (création portefeuille)
L’intégration des relevés et la génération des règlements ont été dissociés dans le paragraphe « cas cible » afin de bien isoler les règles de gestion de l’un ou l’autre des
traitements.
Ces deux traitements sont, ici, traités ensembles car dans COGEST c’est un seul programme qui intègre les relevés puis génère les règlements automatique.
PROCÉDURE DE TEST
Intégration du fichier IZRLV01 : 1er fichier de relevés
010-1
010-2
030-1
030-2
030-3
050-1
050-2
050-3
090-1
090-2
090-3
090-4
090-5
100-1
100-2
100-3
100-4
1020-1
1020-2
Lancement de l’exécution du programme
Lancer la transaction « SE38 »
Indiquer le nom du programme ZAJOUHLP
Appuyer sur le bouton EXÉCUTER
Passage à l’écran de saisie des paramètres de sélection
COGEST : Programme d’aide à la mise en place de la journalisation
Saisie des paramètres de sélection :
Nom du programme d’interface : ZARLVB01
Nom de la variante d’interface : V_ZARLVB01_672
DC : 672
Date de traitement : 01.12.1998
Lancer la transaction « SE38 »
Indiquer le nom du programme ZARLVB01
Appuyer sur le bouton EXÉCUTER AVEC VARIANTE
Affichage de la fenêtre de choix de la variante
Sélectionner la variante : V_ZARLVB01_672
Passage à l’écran : COGEST – Interface relevés et règlement
automatique
Modifier la société:
Société : RGA
Dans le menu : ‘Programme / Exéc. Arrière plan’
Passage à l’écran de sélection des paramètres d’impression batch
Décocher les options suivantes :
Impression immédiate
Supprimer après édition
Appuyer sur le bouton ‘SAUVEGARDE’
Suivi de l’exécution du job lancé en arrière-plan
Lancer la transaction « SM37 »
Nom du job : ZARLVB01
Appuyer sur ‘ENTER’
Passage à l’écran de synthèse des jobs
Appuyer sur ‘ACTUALISER’ jusqu’à ce que le statut du job soit ‘Terminé’

Page 17 sur 18
Vérification des données dans les comptes-rendus
Lancer la transaction « SP01 »
Vérifier que la zone « N° d’ordre spool » est vide
Visualisation des ordres spool
Le programme précédent a généré 3 états :
C.R Règlements
C.R
C.R Relevés
Sélectionner le ‘C.R’
Appuyer sur ‘ AFFICHER ‘
Vérifier le total des relevés intégrés pour l’établissement :
Nombre de relevé lus dans le fichier 17
Nombre de relevés générés 17
Nombre de règlements générés 1
Nombre de relevés non traités 0
Sélectionner le ‘C.R RELEVÉS
Appuyer sur ‘ AFFICHER ‘
Vérifier l’ensemble des données en comparaison du tableau des
résultats ci-dessous
Lancement de l’exécution du dossier Batch-Input
Lancer la transaction « SM35 »
Nom de dossier : ARLV01*
Accès à l’écran « Batch input : synthèse des dossiers »
Dans la rubrique ‘Dossier restant à traiter’ :
Nom de dossier : ARLV01JJHHMM
Transaction :
Double cliquer sur le Dossier
Sélectionner le Mode exécution « Arrière-plan »
Appuyer sur ‘EXÉCUTER
Affichage du message ‘1 dossier transféré en arrière plan’
Appuyer sur ‘ENTER’ pour actualiser l’affichage
Lorsque la rubrique ‘Dossier traité’ apparaît
Appuyer sur ‘PROTOCOL’
Reprendre le n° des pièces comptabilisées (créées) dans RGA
Vérifier :
Le nombre de transactions lues : 18
Le nombre de transactions traitées : 18
Le nombre de transaction erronées : 0
Le nombre de transactions supprimées : 0

Page 18 sur 18
• Résultats attendus
Contenu du compte-rendu ‘C.R RELEVÉS’
Etab. Client Type Nbre. Montant Test
672 10993 RD 1 1.302,00
Total Client 1 1.302,00 1020-1
10995 RD 1 1.302,00
Total Client 1 1.302,00 1020-1
10999 RB 1 1.302,00
RC 3 3.906,00
RD 8 21.614,00
RJ 2 617,94
RM 1 12.500,00
Total Client 15 39.939,94 1020-1
Total etab. Par relevé
RD 10 24.218,00 1020-2
RB 1 1.302,00 1020-2
RC 3 3.906,00 1020-2
RJ 2 617,94 1020-2
RM 1 12.500,00 1020-2
Total Établissement 17 42.543,94 1020-2

Guide tests fonctionnels

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Guide tests fonctionnels

Similaire à Guide tests fonctionnels (20)

Guide tests fonctionnels