Plan de Validation du Logiciel Version 3.0

Transcription

Date : 24/01/2004
Groupe : Is3be2
Isi Engineering Process Publisher
Plan de Validation du Logiciel
Version 3.0
Superviseurs de projet :
Responsable :
Claude Aubry
Bernard Cherbonneau
Nicolas PUJOS
Nombre de pages : 19
Projet IEPP
Plan de Validation du Logiciel v3.0
Groupe :Is3be2
Historique des révisions
VERSION
DATE
DESCRIPTION DES EVOLUTIONS
AUTEURS
1.0
24/01/2004
Création
Nicolas PUJOS
2.0
28/02/2004
Ajout de cas de tests
Nicolas PUJOS
3.0
08/03/2004
Ajout de cas de tests
Nicolas PUJOS
2
Projet IEPP
Groupe :Is3be2
Sommaire
Chapitre 1 : Introduction .......................................................................................... 5
1.1
Avant propos.......................................................................................................... 5
1.2
Objet ...................................................................................................................... 5
1.3
Responsabilités...................................................................................................... 5
Chapitre 2 : Documents applicables et de référence............................................. 6
2.1
Documents applicables .......................................................................................... 6
2.2
Documents de référence........................................................................................ 6
Chapitre 3 : Terminologie ........................................................................................ 7
3.1
Glossaire................................................................................................................ 7
3.2
Acronymes et abréviations ..................................................................................... 7
Chapitre 4 : Exigences de test................................................................................. 8
4.1
Exigences communes ............................................................................................ 8
4.2
Exigences spécifiques............................................................................................ 8
Chapitre 5 : Description du logiciel........................................................................10
5.1
Domaine d’application et objectifs .........................................................................10
5.2
Information............................................................................................................10
5.2.1 Programmes.........................................................................................................................................10
5.2.2 Données...............................................................................................................................................10
5.2.3 Documentation Utilisateur ....................................................................................................................10
5.2.4 Documentation technique ....................................................................................................................10
5.2.6 Code Source ........................................................................................................................................11
Chapitre 6 : Stratégie générale de test ..................................................................12
6.1
Information à tester ...............................................................................................12
6.2
Techniques de test................................................................................................12
6.3
Risques et contingences .......................................................................................12
Chapitre 7 : Spécification de test ...........................................................................13
Chapitre 8 : Organisation de test ...........................................................................16
8.1
Fonctions ..............................................................................................................16
8.2
Tâches identifiées .................................................................................................16
8.3
Formation requises ...............................................................................................16
8.4
Fournitures............................................................................................................17
8.5
Critères généraux de succès / échec ....................................................................17
Chapitre 9 : Environnement de test .......................................................................18
9.1
Configuration matérielle ........................................................................................18
9.2
Configuration logicielle ..........................................................................................18
9.3
Outils de développement ......................................................................................18
3
Projet IEPP
Groupe :Is3be2
Chapitre 10 : Planification.......................................................................................19
10.1
Critères généraux de suspension et conditions générales de reprise....................19
10.1.1
10.1.2
Critères de suspension ..............................................................................................................19
Conditions de reprise .................................................................................................................19
4
Projet IEPP
Groupe :Is3be2
Chapitre 1 : Introduction
1.1
Avant propos
Ce document a été développé par les étudiants de Master M1 de l’Institut Universitaire
Professionnalisé (IUP) « Ingénierie des Systèmes Informatiques » (ISI) de l’Université Paul
Sabatier dans le cadre du bureau d’études.
1.2
Objet
Ce document présente la stratégie, l’organisation, l’environnement et la planification des
activités de test de validation du logiciel IEPP.
Il identifie notamment les éléments à tester, les taches correspondantes, les ressources
requises pour ces tâches et les risques associés au présent plan.
Les cas et procédures de test sont fournis dans le cahier de validation du logiciel [CVL].
1.3
Responsabilités
Les responsables de ce document sont les membres de l’équipe de test.
5
Projet IEPP
Groupe :Is3be2
Chapitre 2 : Documents applicables et de référence
2.1
Documents applicables
[12207]
NF ISO/CEI 12207 : 1995 (F)
Traitement de l’information – Ingénierie du logiciel – Processus du cycle de
vie du logiciel
AFNOR, 1995
[9126]
NF ISO/CEI 9126 : 1992
Évaluation des logiciels - Caractéristiques de qualité et lignes directrices pour
leur utilisation.
AFNOR, 1992
[NF LOG]
NF LOGICIEL
Règlement de la marque NF Logiciel - Exigences pour le dossier de test du
logiciel – Annexe 1.2
AFNOR, 1996
[14598-5]
ISO/IEC 14598-5:1998(E)
Information technology - Software Product Evaluation - Part 5: Process for
Evaluators.
ISO/IEC, 1998
[14598-6]
ISO/IEC FDIS 14598-6:1999
Information technology - Software Product Evaluation - Part 6:
Documentation of evaluation modules.
ISO/IEC, 1999
2.2
Documents de référence
[DCU]
Document des cas d’utilisation du logiciel IEPP V4.0
[SS]
Spécifications supplémentaires du logiciel IEPP. V2.0
[CVL]
Cahier de validation du logiciel IEPP. V3.0
[CC]
Guide de codage IEPP V2.2
6
Projet IEPP
Groupe :Is3be2
Chapitre 3 : Terminologie
3.1
Glossaire
La terminologie se conforme aux documents applicables mentionnés au chapitre 2.
Pour rappel [NF LOG]:
Stratégie de validation : description des objectifs de test, description et justification des
objectifs en termes de couverture d'essai, ainsi que des méthodes qui vont permettre
d’atteindre ces objectifs
Cas de test : instructions écrites à l’usage du responsable d’essai qui spécifient la manière
dont une fonction ou une combinaison de fonctions doit être testée ou dont il convient qu’elle
le soit. Un cas de test contient des informations détaillées sur les points suivants :
• l’objectif du test ;
• les fonctions à tester ;
• l’environnement d’essai et autres conditions (configuration détaillée et travaux
préparatoires) ;
• les données de test ;
• le mode opératoire ;
Le comportement attendu du programme.
Scénario de test : ensemble autonome et cohérent d’interactions avec le logiciel regroupant
un ou plusieurs tests élémentaires, et les éventuelles phases préparatoire et finale de ces tests
élémentaires.
Test élémentaire : test spécifiant les interactions avec le logiciel contribuant à vérifier un
objectif de test particulier et une fonction particulière.
Procédure de test : expression d’un test élémentaire en une succession de commandes ou
d’instructions directement applicables par les personnes chargées d’exécuter les tests.
3.2
AQ
BE
IUP
IHM
ISI
IT
RUP
CU
PVL
Acronymes et abréviations
Assurance Qualité
Bureau d’études
Institut Universitaire Professionnalisé
Interface Homme/Machine
Ingénierie des Systèmes d’Information
Itération
Rational Unifed Process
Cas d’utilisation
Plan de Validation Logiciel
7
Projet IEPP
Groupe :Is3be2
Chapitre 4 : Exigences de test
4.1
Exigences communes
Ce paragraphe rappelle les exigences communes à l’ensemble des outils développés dans le
cadre du BE ISI M1.
[EX-U-01]
Les outils doivent posséder une interface (menus, messages d'
erreur,...) en français.
[EX-P-01]
L'
internationalisation doit pouvoir se faire sans re-compilation, uniquement en
modifiant un fichier de ressources. Il est recommandé d'
en proposer une version en
anglais.
[EX-U-02]
Les outils doivent posséder un menu Préférences
[EX-U-03]
Les outils doivent posséder un menu Aide avec une rubrique à propos dans laquelle
apparaît le nom de l'
outil, le numéro de version et la date de fabrication.
[EX-M-01]
Les composants utilisés doivent être cités dans la rubrique A propos, ainsi que les
informations de licence.
[EX-M-02]
Tout au long du développement, les règles de codage définies devront être respectées.
[EX-P-02]
Les outils doivent pouvoir être utilisés sous Windows sans installation ni écriture dans
le registre.
[EX-P-03]
Les outils doivent être fournis sous forme de fichier jar qu'
on peut lancer directement.
[EX-R-01]
Les outils doivent se lancer en moins de 3 secondes.
[EX-P-04]
Les outils doivent fonctionner au moins avec Java 1.4.2
Seule l’exigence [EX-P-02] n’est pas retenue
4.2
Exigences spécifiques
[DCU] spécifie la combinaison de recommandations, contraintes et exigences spécifiques à
satisfaire par le logiciel.
Dans le cadre du présent plan de test, sont retenues comme exigences de test :
8
Projet IEPP
[EX-F-01]
[EX-F-25]
[EX-F-02]
[EX-F-33]
[EX-F-03]
[EX-F-04]
[EX-F-05]
[EX-F-06]
[EX-F-08]
[EX-F-09]
[EX-F-10]
[EX-F-15]
[EX-F-16]
[EX-F-17]
[EX-F-18]
[EX-F-19]
[EX-F-20]
[EX-F-21]
Créer une nouvelle définition de processus
Ajouter un composant à la definition de processus
Ajouter un composant de processus au diagramme
Ajouter un commentaire sur le diagramme
Créer un composant vide
Editer l’interface d’un composant vide
Sauvegarder un composant vide avec ses interfaces
Supprimer un composant de la definition de processus
Lier deux produits
Supprimer le lien entre deux produits
Renommer un produit lien
Ouvrir une définition de processus existante
Editer les propriétés d’une définition de processus
Sauvegarder une définition de processus
Fermer une definition de processus
Lancer la verification de la définition de processus
Lancer la génération du site
Modifier l’ordre des composants dans l’arbre de
navigation
Exporter une definition de processus
Ajouter un composant au référentiel
Supprimer un composant du réferentiel
Supprimer une definition de processus du referentiel
Créer un nouveau référentiel
Charger un referentiel
Ajouter un paquetage de présentation au référentiel
Ajouter un paquetage de présentation à la définition
de processus
Si un champ est manquant, incohérent ou incorrecte,
un message d'
erreur est affiché à l'
écran
En cas d'
absence d'
un fichier de configuration un
fichier par défaut est généré.
[EX-F-22]
[EX-F-23]
[EX-F-24]
[EX-F-26]
[EX-F-27]
[EX-F-29]
[EX-F-31]
[EX-F-32]
[EX-T-01]
[EX-T-02]
Groupe :Is3be2
9
Projet IEPP
Groupe :Is3be2
Chapitre 5 : Description du logiciel
5.1
Domaine d’application et objectifs
Le projet IEPP (Isi Engineering Process Publisher) est un projet libre de droits qui a
pour but de publier un processus d'
ingénierie en associant entre eux les divers composants de
processus et en générant un site web.
Ce projet s'
inscrit dans le cadre d'
une suite allant de l'
édition de composants de
processus à l'
exécution et au suivi d'
un processus complet.
5.2
Information
5.2.1 Programmes
Le logiciel est composée des programmes/exécutables suivants:
[EXE1]
iepp.jar
Dans le cadre du présent plan, iepp.jar est retenu.
5.2.2 Données
Les données du logiciel sont :
[L-FR]
Fichier contenant les messages en français
[L-AN]
Fichier contenant les messages en anglais
[L-PROP]
Fichier contenant les préférences du logiciel
[L-STYLE]
Feuilles de style utilisées lors de la génération
5.2.3 Documentation Utilisateur
Les éléments suivants constituent la documentation Utilisateur du logiciel.
[MI]
[MU]
Procédure d’installation
Manuel Utilisateur
5.2.4 Documentation technique
Les éléments suivants constituent la documentation technique du logiciel.
[DCU]
[DV]
[LR]
[PCV]
[PD]
[SS]
Document des cas d’utilisation
Document Vision
Liste des risques
Plan de cycle de vie
Plan de développement
Spécifications supplémentaires
10
Projet IEPP
[DAL]
[PI]
[EI]
[EXC]
[PVL]
[CVL]
Groupe :Is3be2
Document d’architecture logiciel
Plan des itérations
Evaluation des itérations
Exigences complémentaires
Plan de validation logiciel
Cahier de validation logiciel
Seuls les items suivants sont retenus :
Document des cas d’utilisation
Document Vision
Spécifications supplémentaires
Document d’architecture logiciel
5.2.6 Code Source
Code spécifique
Le code source du logiciel se compose des paquetages suivants:
[INTERFACE1]
Iepp.ui
[TEST1]
tests
[APPLICATION1] Iepp.application.aedition
[APPLICATION2] Iepp.application.ageneration
[APPLICATION3] Iepp.application.averification
[APPLICATION4] Iepp.infrastructure.JSX
[DOMAINE1]
Iepp.domaine
Dans le cadre du présent plan, tous les items sont retenus.
Code réutilisé
[LIB1]
[LIB2]
JSX
Apes2.jar
S’agissant de code réutilisé, aucun test ne sera appliqué
11
Projet IEPP
Groupe :Is3be2
Chapitre 6 : Stratégie générale de test
Ce chapitre résume la stratégie de test mise en place pour la validation du logiciel. Il précise
notamment, pour chaque caractéristique logicielle [9126], les informations logicielles
concernées ainsi que les techniques de test retenues.
6.1
Information à tester
Pour chaque caractéristique logicielle, le tableau ci-dessous précise l’information logicielle à
tester (X) ou non testée (NT) :
Information à tester par caractéristique:
Information
Programmes et données
Capacité
fonctionnelle
Fiabilité
Facilité
d’utilisation
Rendement
X
X
X
X
Maintenabilité
Portabilité
X
Documentation Utilisateur
Documentation technique
X
Code source
6.2
X
X
Techniques de test
Le tableau ci-dessous résume les techniques de test sélectionnées en fonction des exigences de
test et des informations à tester.
Techniques de test
Capacité
fonctionnelle
Fiabilité
Facilité
d’utilisation
Rendement
Maintenabilité
Portabilité
X
Test fonctionnel
X
Inspection de l’IHM
X
X
Test de performance
X
Inspection de code
X
X
Test de stress
Chaque technique de test retenue fait l’objet d’une spécification détaillée présenté au chapitre
suivant.
6.3
Risques et contingences
Sans objet
12
Projet IEPP
Groupe :Is3be2
Chapitre 7 : Spécification de test
Ce chapitre raffine la stratégie de test pour chaque technique de test sélectionnée.
Les tests fonctionnels ont pour but de vérifier une utilisation normale des exigences.
Les tests de stress servent à mettre en évidence la fiabilité du produit.
Identificateur :
Technique de test :
Exigences testées :
[EX-F-01]
[EX-F-25]
[EX-F-02]
[EX-F-03]
[EX-F-04]
[EX-F-33]
[EX-F-05]
[EX-F-06]
[EX-F-08]
[EX-F-09]
[EX-F-10]
[EX-F-15]
[EX-F-16]
[EX-F-17]
[EX-F-18]
[EX-F-19]
[EX-F-20]
[EX-F-21]
[EX-F-22]
[EX-F-23]
[EX-F-24]
[EX-F-26]
[EX-F-27]
[EX-F-29]
[EX-F-31]
[EX-F-32]
FUNC
Test fonctionnel
Cas de test
CT-FUNC-01
CT-FUNC-02
CT-FUNC-03
CT-FUNC-02
CT-FUNC-02
CT-FUNC-02
CT-FUNC-02
CT-FUNC-04
CT-FUNC-03
CT-FUNC-04
CT-FUNC-03
CT-FUNC-04 CT-FUNC-05 CT-FUNC-07
CT-FUNC-03
CT-FUNC-03
CT-FUNC-03
CT-FUNC-05
CT-FUNC-06
CT-FUNC-06
CT-FUNC-06
CT-FUNC-02
CT-FUNC-07
CT-FUNC-07
CT-FUNC-01
CT-FUNC-07
CT-FUNC-02
CT-FUNC-02
Information sous test
Exécutable
Iepp.jar
Démarche :
Niveau de complétude : 100% des cas des exigences de test
Critères de succès / échec : voir §8.5
13
Projet IEPP
Groupe :Is3be2
INSP
Identificateur :
Technique de test : Inspection de l’IHM
[EX-U-01]
Les outils doivent posséder une interface (menus, messages d'
erreur) en français
[EX-P-01]
[EX-U-02]
.
L'
internationalisation doit pouvoir se faire sans re-compilation,
uniquement en modifiant un fichier de ressources. Il est recommandé d'
en
proposer une version en anglais
Les outils doivent posséder un menu Préférences
[EX-U-03]
Les outils doivent posséder un menu Aide avec une rubrique à propos
dans laquelle apparaît le nom de l'
outil, le numéro de version et la date de
fabrication.
[EX-M-01]
Les composants utilisés doivent être cités dans la rubrique A propos,
ainsi que les informations de licence
Executable
Iepp.jar
Démarche :
Cas de test :
[CT-INSPIHM-01] Cas de test inspection de l’IHM
Niveau de complétude :
PERF
Identificateur :
Technique de test : Test de performance
[EX-U-01]
L’outil doit se lancer en moins de 3 secondes
Executable
Iepp.jar
Démarche :
Cas de test :
[CT-PERF-01]
Vérifier que l’outil se lance en moins de 3 secondes
Critères de succès / échec :
Excellent : lancement en moins de 3 secondes quelques soit le volume des donnée à charger
Bon: Lancement parfois supérieur à 3 secondes.
Moyen : Lancement souvent supérieur à 3 secondes.
Mauvais Lancement systématiquement supérieur à 3 secondes.
Identificateur :
Technique de test :
INSTALL
Test d’installation
14
Projet IEPP
Groupe :Is3be2
[EX-P-03]
Les outils doivent être fournis sous forme de fichier jar qu'
on peut lancer
directement
[EX-P-04]
Les outils doivent fonctionner au moins avec Java 1.4.2
Executable
Iepp.jar
Démarche :
Cas de test :
[CT-INSTAL-01] Vérifié que le produit est portable sur les machines voulues
STRESS
Identificateur :
Technique de test : Test de stress
Exigences testées : Cas de test :
[EX-T-01]
[CT-STRESS-01] Stress des champs de texte
[EX-T-02]
[CT-STRESS-02] Stress de la configuration
Executable
Iepp.jar
Démarche :
Niveau de complétude : 1 cas de test doit être effectué pour chaque EX-T
INSPEC_CODE
Identificateur :
Technique de test : Inspection de code
Exigences testées : Cas de test :
[EX-M-02]
[CT-INSPCOD-1] Vérification des règles de codage
Code source , [CC]
Démarche :
Niveau de complétude : 100% des paquetages spécifiques (cf §5.2.6)
15
Projet IEPP
Groupe :Is3be2
Chapitre 8 : Organisation de test
Ce chapitre présente l’organisation mise en place pour réaliser le présent plan de test.
8.1
Fonctions
Le tableau ci-dessous indique les différentes fonctions requises pour exécuter le présent plan
de test ainsi que les ressources initialement allouées pour chacune de ces fonctions.
Fonctions et ressources allouées:
Fonctions
RC - Représentant Client
RU - Représentant Utilisateurs
CP - Chef de Projet
RV- Responsable Validation
EX - Exécutant
8.2
Ressources allouées
M. Claude AUBRY
M. Claude AUBRY
Sandra POULAIN
Nicolas PUJOS
Equipe de 2A
Organisation
IUP ISI
IUP ISI
IUP ISI
IUP ISI
IUP ISI
Tâches identifiées
Le tableau ci-dessous identifie les différentes tâches requises pour réaliser le présent plan de
test. Les colonnes "Fonctions" et "Resp." indiquent respectivement les fonctions impliquées
dans la tâche et le niveau de responsabilité correspondant :
- R (Responsable): la réalisation de la tâche est placée sous la responsabilité de la
fonction mentionnée, notamment concernant les fournitures relatives à cette tâche;
- E (Exécutant): la tâche est exécutée par la ou les fonctions mentionnées;
- C (Consultant): La fonction mentionnée peut requérir l’avis pour consultation de la
ou les fonctions mentionnées. Ces fonctions ne sont pas directement impliquées
dans la réalisation
Tâches et responsabilités associées :
Tâches
Spécification des tests
Conception des cas de tests
Réalisation des cas de tests
8.3
Fonction
Responsable / Exécutant
Responsable / Exécutant
Responsable
Exécutant
Resp.
RV
RV
RV
EX, RV
Formation requises
Sans objet
16
Projet IEPP
8.4
Groupe :Is3be2
Fournitures
Les éléments suivants doivent être fournit :
- un jeu de données :
- les fichiers créés par l’outil 2 à charger (.pre)
- un fichier .iepp pour l’ouverture d’une définition de processus existante
- un cahier de test remplit
- un cahier de test vierge
8.5
Critères généraux de succès / échec
Un test fonctionnel est :
- excellent si aucune erreur n’a été constatée
- bon/moyen si la fonctionnalité ne s’exécute que partiellement
- faible si une erreur est apparue durant le test
Un test pour l’inspection de l’IHM :
- excellent si les principes ergonomiques d’IHM sont respectés
- faible si l’IHM est inexploitable ou illisible
17
Projet IEPP
Groupe :Is3be2
Chapitre 9 : Environnement de test
Ce chapitre décrit l’environnement requis pour exécuter le présent plan de test.
Certains tests peuvent nécessiter des besoins complémentaires. Le cas échéant, se référer à la
rubrique correspondante dans les spécifications des cas de tests fournis dans [CVL].
9.1
Configuration matérielle
La configuration matérielle suivante est requise pour exécuter le présent plan de test :
- Un PC
9.2
Configuration logicielle
La configuration logicielle suivante est requise pour exécuter le présent plan de test :
- Java 2 Runtime Environement SE v1.4.2
- Windows XP
- WinRar (pour pouvoir éditer des fichiers du .jar)
9.3
Outils de développement
Les outils de développement suivants sont requis pour exécuter le présent plan de test :
-
Environnement de développement JDK 1.4 (pour l’inspection de code)
18
Projet IEPP
Groupe :Is3be2
Chapitre 10 : Planification
Le scénario 11 (CT-INSTAL-01) doit être réalisé à l’installation
L’utilisation nominale du logicielle peut être testée en effectuant les scénarios 1 à 7.
Les cas de stress et d’inspection d’IHM peuvent être exécutés séparément.
Lors de la recette, les scénarios 1 à 7 seront déroulés
10.1 Critères généraux de suspension et conditions générales
de reprise
10.1.1
Critères de suspension
Les critères généraux de suspension du présent plan de test sont les suivants :
-
Lorsqu'
une erreur empêchant le fonctionnement du logiciel survient, il est
impératif de suspendre les tests et de corriger cette erreur avant de poursuivre les
tests
10.1.2
Conditions de reprise
Les conditions générales de reprise du présent plan de test sont les suivantes :
- Les tests fonctionnels et de stress concernés par les corrections apportées devront être
repassés.
19

Plan de Validation du Logiciel Version 3.0

Transcription

Documents pareils

RédIGER uNE NOtE dE SyNthESE MéthOdOLOGIE

FR-Documentation JO

Plan de développement logiciel Version 4.0

Formation de Élus - Voyage BILBAO Économie sociale et les

Droit et gestion des collectivités territoriales - DESU

Première en France : une agence de voyage politique pour

agrement jar 145

Comment faire votre .jar sous Eclipse

ewoks wicket chewbacca jango fett jabba le hutt dark vador c3po

ISI Web of Knowledge

2. l`analyse des performances