Génie Logiciel 3ième Info Test & Vérification logiciel

Mohamed KHADRAOUI SW Consultant IT Spectrum+ Génie Logiciel 3ième Info Test & Vérification logiciel May 2011 - V 1.0 Cours Esprit 2010-2011 1

Objectifs S assurer que le produit répond aux exigences S assurer que le produit est bien construit Améliorer la productivité des équipes 2

L idée du test logiciel est de rechercher la présence d erreurs pour les corriger, et non pas de démontrer qu il en est exempt. Pour cela il faudrait être capable de pouvoir tester tous les comportements ce qui est rarement envisageable et possible. Processus Vérification & Validation (VER & VAL) Des tests rigoureux des systèmes et de la documentation peuvent aider à réduire les risques d'occurrence de problèmes dans l'environnement opérationnel et contribuent à la qualité des systèmes logiciels, si les défauts découverts sont corrigés avant la livraison du système pour un usage opérationnel. Les tests de logiciels peuvent aussi être nécessaires pour respecter des exigences légales ou contractuelles, ou atteindre des normes industrielles spécifiques.. (ISTQB, 1.1.3 3

Planning du cours Problématique Un peu d Historique Description du métier Défauts logiciels Cycle de vie Niveaux de tests & le cycle en V Niveaux de tests & le cycle itératif Méthodes de tests «Tester, c est exécuter le programme dans l intention Différents types des tests d y trouver des anomalies ou des défauts»-g. Myers Principes des tests (The Art of Software testing) Code & ethique Testing can reveal the presence of errors but never Processus de tests their absence EdsgarW. Dijkstra. Notes on structured Fondamentaux programming. AcademicPress, 1972. Exemple de Fiche de Test 4

Test & Vérification logiciel : Problématique Les ordinateurs sont parmi les produits les plus complexes que l'homme a fabriqué, et ils ont par conséquent un très grand nombre d'états. Les logiciels sont plus complexes que les ordinateurs, et, contrairement à une automobile, aucune pièce ne se ressemble. La conformité à de nombreuses normes, caractéristique des domaines proches de la télécommunication, accroit la complexité de ces derniers. Les logiciels sont de plus des produits invisibles, qui ne peuvent pas être représentés dans un espace géométrique, Les tests de logiciels sont la première mesure pour contrer les bugs. Pour des raisons pratiques (coût des travaux et délais) il n'est pas possible de tester un logiciel dans toutes les conditions qu'il pourra rencontrer lors de son utilisation et donc pas possible de contrer la totalité des bugs: un logiciel comme Microsoft Word compte 850 commandes et 1600 fonctions, ce qui fait un total de plus de 500 millions de conditions à tester Les bugs résultent d'erreurs humaines lors des travaux de spécification, de conception, de programmation et de tests de logiciel et de matériel informatique. La complexité grandissante des logiciels, les problèmes de communication, le manque de formation des ingénieurs et la pression des délais et des coûts durant les travaux d'ingénierie sont des facteurs qui tendent à augmenter le nombre de bugs 5

Test & Vérification logiciel : Un peu d histoique L'échec du vol inaugural de la fusée Ariane 5 en 1996 a pour origine un défaut dans les appareils d'avionique de la fusée, appareils utilisés avec succès pendant plusieurs années sur la fusée Ariane 4. Lors du décollage, l'appareil informatique qui calculait la position de la fusée en fonction de son accélération ne supporta pas les accélérations d'ariane 5-5 fois plus fortes que celles d'ariane 4. Un dépassement de capacité provoque le crash informatique de l'appareil. Aveuglé, le pilote automatique perdit le contrôle de la fusée, et un dispositif de sécurité provoqua son auto-destruction quelques secondes après le décollage. C'est le bug informatique le plus coûteux de l'histoire. Le bug de l'an 2000, aussi appelé bug du millénaire : un ou plusieurs bugs dans un logiciel qui manipule des dates provoquent des dysfonctionnements lorsque les dates sont postérieures au 31 décembre 1999. Une des causes est que les calculs sur les dates se font uniquement sur les deux derniers chiffres de l'année. Les problèmes potentiels posés par la date du 31 décembre 1999 ont été anticipés la première fois par Bob Berner en 1971. Ils ont provoqué une importante mobilisation des entreprises de génie logiciel quelques années avant la date butoir et le coût total des travaux de contrôle et de maintenance préventive sont estimés à plus de 600 millions de dollars. Bien que le passage à l'an 2000 se déroula sans problème majeur une certaine psychose ayant atteint le grand public. On attend comme même le Bug 2038 (système à 32 bits) 6

Test & Vérification logiciel : Description du métier Le test des logiciels est un métier à part entière. Dans l industrie, c est la seule activité dans le cycle de développement où l on peut voir toutes les fonctionnalit és d un produit logiciel. Contrairement au développement, où les développeurs sont très compartimentés : Protocole, IHM, BdD, Middleware, Le test est une activité créatrice : imaginer des scénarios plausibles pouvant mettre un logiciel en défaut imaginer et construire des bancs de tests permettant de vérifier les fonctionnalités et les contraintes,... Malheureusement, le test a mauvaise réputation, voici les principaux griefs : les testeurs sont les derniers dans la chaîne de développement du logiciel, il accumule donc tous les retards pris par les phases précédentes! les testeurs découvrent des anomalies et des défauts, par conséquent il se prennent pour des procureurs! le complexe du développeur: je suis le seul qui faut avancer le projet, les autres ne sont pas entrain de m aider! Le test logiciel est le maillon principal dans la chaine d assurance qualité produit Le test logiciel pourra avoir pour but de qualifier un logiciel ou certifier un produit 7

Test & Vérification logiciel : Défauts logiciels 1/2 Bug : Le mot anglais bug (insecte, bogue) vient du jargon des ingénieurs de matériel et représentant les problèmes qui y survenaient. une anecdote raconte qu elle aurait découvert qu un insecte (bug), coincé entre deux contacts d un relais, causait le mauvais fonctionnement du Harvard Mark II, l un des premiers ordinateurs électromécaniques. Crash : Les bugs peuvent amener les logiciels à tenter d'effectuer des opérations impossibles à réaliser (exceptions): division par zéro, recherche d'informations inexistantes. Ces opérations - qui ne sont jamais utilisées lors de fonctionnement correct du logiciel - déclenchent un mécanisme à la fois matériel et logiciel qui met alors hors service le logiciel défaillant, ce qui provoque un Crash applicatif ou un Deny of Service fuite de mémoire : est un dysfonctionnement dû à un bug dans les opérations d'allocation de mémoire. Avec ce dysfonctionnement, la quantité de mémoire utilisée par le logiciel défaillant va en augmentant continuellement. Si le logiciel défaillant arrive à utiliser la quasi-totalité de la mémoire disponible, celui-ci gêne alors le déroulement des autres logiciels et les entraîne à des dysfonctionnements. 8

Test & Vérification logiciel : Défauts logiciels Segmentation Fault : Une erreur de segmentation est un dysfonctionnement dû à un bug dans des opérations de manipulations de pointeurs ou d'adresses mémoire. Le logiciel défaillant va tenter de lire ou d'écrire des informations dans un emplacement de mémoire (segment) qui n'existe pas ou qui ne lui est pas autorisé. Le mécanisme de détection des exceptions provoque alors la mise hors service du logiciel défaillant. Integer Overflow : Un dépassement de capacité est un dysfonctionnement dû à un bug dans des opérations de calcul mathématique. Le logiciel défaillant va tenter d'effectuer un calcul dont le résultat est supérieur à la valeur maximum autorisée. Le mécanisme de détection des exceptions provoque alors la mise hors service du logiciel défaillant. Buffer Overflow : dépassement de tampon ou débordement est un bug par lequel un processus, lors de l'écriture dans un tampon, écrit à l'extérieur de l'espace alloué au tampon, écrasant ainsi des informations nécessaires au processus. Le comportement de l'ordinateur devient imprévisible. Il en résulte souvent un blocage du programme, voire de tout le système. C'est une faille de sécurité courante des serveurs qui est souvent exploitée par les pirates informatiques. 9

Test & Vérification logiciel : Défauts logiciels 3/3 DeadLock : Un inter blocage est un dysfonctionnement durant lequel plusieurs processus s'attendent mutuellement, c'est à dire qu'ils attendent chacun que l'autre libère les ressources qu'il utilise pour poursuivre. Les ressources restent verrouillées durant les attentes, ce qui peut bloquer d'autres processus et par effet domino bloquer l'ensemble du système. Un mécanisme de prévention provoque l'annulation de l'opération lorsque la durée d'attente dépasse le délai admissible (anglais timeout). Race condition : Une situation de compétition est un dysfonctionnement dû à un bug, qui fait que dans un même logiciel deux automatismes qui travaillent simultanément donnent des résultats différents suivant l'automatisme qui termine avant l'autre. Vulnérabilité : est une faiblesse dans un système informatique permettant à un attaquant de porter atteinte à l'intégrité de ce système, c'est-à-dire à son fonctionnement normal, à la confidentialité et l'intégrité des données qu'il contient. On parle aussi de faille de sécurité informatique. Quelques vulnérabilités surviennent lorsque l'entrée d'un utilisateur n'est pas contrôlée, permettant l'exécution de commandes ou de requêtes SQL (connues sous le nom d'injection SQL). D'autres proviennent d'erreurs d'un programmeur lors de la vérification des buffers de données (qui peuvent alors être dépassés), causant ainsi une corruption de la pile mémoire (et ainsi permettre l'exécution de code fourni par l'attaquant). 10

Test & Vérification logiciel : Cycle de vie 1/2 Les bugs résultent d'erreurs humaines lors des travaux de spécification, de conception, de programmation et de tests de logiciel et de matériel informatique. facteurs qui tendent à augmenter le nombre de bugs : Complexité grandissante des logiciels, Problèmes de communication, Manque de formation des ingénieurs : métier et technique Pression des délais et des coûts durant les travaux d'ingénierie sont des. modifications & évolution de technologies multiples interactions entre les systèmes Erreur Spécification, conception, programmation Défaut dans le logiciel Anomalie de fonctionnement 11

Test & Vérification logiciel : Cycle de vie 2/2 Tester au sein d un modèle de cycle de vie : Quel que soit le modèle de cycle de vie, plusieurs bonnes pratiques de tests s'appliquent: A chaque activité de développement, correspond une activité de test. Chaque niveau de test a des objectifs de tests spécifiques pour ce niveau. L'analyse et la conception des tests pour un niveau de test devraient commencer pendant l'activité correspondante de développement. Les testeurs doivent être impliqués dans la revue des documents aussi tôt que des brouillons sont disponibles dans le cycle de développement. Cadre Managériale: Tests d acceptation contractuelle et réglementaire Les tests d'acceptation contractuelle sont exécutés sur base des critères d'acceptation contractuels pour la production de logiciels développés sur mesure. Les critères d'acceptation devraient être définis lors de la rédaction du contrat. Les tests d'acceptation réglementaires sont exécutés par rapport aux règlements et législations qui doivent être respectés, telles que les obligations légales, gouvernementales ou de sécurité. 12

Test & Vérification logiciel : Niveaux de tests & le modèle en V Tests de Validation Spécifications Conception Générale Test de Vérification Conception Détaillée Codage Développement Tests Intégration Tests Unitaires Test& & Contrôle 13

Test & Vérification logiciel : Niveaux de tests & Cycles Itératifs Le mode de développement itératif est une succession d'activités exécutées comme une série de petits développements: exigences, conception, construction et tests d un système. Exemples : prototypage, développement rapide d'applications (RAD), Rational Unified Process (RUP) et les modèles de développement agiles. Le système logiciel résultant (l'incrément) d une itération peut être testé à plusieurs niveaux de tests à chaque itération. Un incrément, ajouté à ceux développés préalablement, forme un système partiel en croissance, qui devrait également être testé. Les tests de régression sont de plus en plus importants sur toutes les itérations après la première. La vérification et la validation peuvent être effectuées sur chaque incrément. 14

Test & Vérification logiciel : Méthodes de Tests Méthode boîte noire : les essais tournent autour du fonctionnement externe du système : les détails d'implémentation des composants ne sont pas connus (ou sciemment ignorés), et seul le comportement extérieur est testé. Méthode boîte blanche : (ou transparente) les détails d'implémentation des composants sont ici tous connus, et le test teste spécifiquement ces implémentations. Méthode boîte Grise: 15

Test & Vérification logiciel : Types de Tests 1/6 Test nominal : ou test de bon fonctionnement : Les cas de test correspondent à des données d entrée valide => Test-to-pass Test De Robustesse : (ou de défense) Les cas de test correspondent à des données d entrée invalide => Test-to-fail Test De Performance : ou Tests d endurance, correspondent aux : Tests de charge : Load Testing, dans le temps ou avec des valeurs aux limites Tests de stress : soumis à des fressources anormales Test unitaire : Dans le premier niveau des tests, les fonctions (ou les modules) de code sont testés, habituellement par les programmeurs, car ces tests supposent une connaissance approfondie du design interne et du code de l application. Ce type de test peut nécessiter le développement des drivers ou des programmes additionnels. 16

Test & Vérification logiciel : Types de Tests 2/6 Test Intégration : Ce type de test se focalise sur une parties de l application ayant pour but de valider le fait que toutes les parties développées indépendamment fonctionnent bien ensemble. Les parties peuvent être modules de code,librairies (statique ou dynamique), applications individuelles, applications du type client ou serveur d un réseau. Test Système: On teste ici par la méthode boîte noire la fiabilité et la performance de l'ensemble du système, tant au niveau fonctionnel que comportement de la totalité du système (plutôt que de ses composants). On teste aussi la sécurité, les sorties, l'utilisation des ressources et les performances. Test de Recette: Ce test doit confirmer que l'application réponde d'une manière attendue aux requêtes qui lui sont envoyées. Ce test permet d'adapter l'application aux attentes des clients et utilisateurs. Test de Compatibilité: Tester la manière dont un logiciel fonctionne dans une configuration spécifique du système, sous un système d exploitation spécifique, dans un environnement de réseau particulier etc. 17

Test & Vérification logiciel : Types de Tests 3/6 Test de bout en bout : (end 2 end) : Similaire au test système qui implique le teste de l entière application dans l environnement qui imite la situation réelle d utilisation de l application. Ce test met en jeu plusieurs composants en interaction : BdD, Réseau, autres système et application, composant hardware Test de non régression: (ou Tests liés au changement ) Choisir un ensemble de cas des test pour les reprendre après avoir fixé les bogues ou les modifications du logiciel ou de l environnement. Déterminer la nécessité de re - tester peut être difficile, notamment si on est proche de la fin du cycle de développement. Les outils de test automatisé peuvent être extrêmement utiles pour ce type de test. Sanity tests : IL s'agit de jeu initial de test pour déterminer si une nouvelle version du logiciel présente des performances suffisamment acceptable pour entamer une campagne de tests majeur. Par exemple, si le nouveau logiciel est un système qui plante toutes les 5 minutes, le logiciel n est pas saint pour pouvoir aller plus loin dans des tests fonctionnels ou non fonctionnels 18

Test & Vérification logiciel : Types de Tests 4/6 Test d utilisabilité : Ce test doit valider si l application est facile à utiliser. Clairement ce test est subjectif et il va dépendre des utilisateurs finals ou clients visés. Les interviews, les enregistrements vidéo des interrogations des clients ou d autres techniques peuvent être utilisées. Les programmeurs et les testeurs ne sont pas indiqués pour ce teste. Test d installation : Tester le processus d installation / désinstallation intégralement, partiellement ou progressivement. Test de charge Tester une application sous de grandes charges, comme par exemple tester un site web sous une série de charges pour déterminer jusqu à quel point la réponse du système n est plus prompte ou craque. Test de sécurité: Tester la manière dont le système protège contre les accès interne ou externes pas autorisés, endommagement par mauvaises intentions Protéger contre les intrusions et les failles de sécurité par le biai d une vérification périodique de vulnérabilité de sécurité Test d administration : focalisation sur les aspects d administration : Tests des backups et restaurations; Reprise après sinistre; Gestion des utilisateurs; Tâches de maintenance; Chargements de données et tâches de migration 19

Test & Vérification logiciel : Types de Tests 5/6 Test contextuel : Ce type de test est peut être exécuté après une bonne connaissance de l environnement, culture et utilisation prévue pour le logiciel développée. Par exemple on va avoir une approche complètement différente pour un équipement médical que pour un simple jeu de PC. Test alpha: Tester une application lorsque le développement est presque fini et des changements mineurs peuvent être faits à la suite de ce type de test. Couramment faits par utilisateurs finals ou par d autres que les testeurs ou développeurs Test Beta : Tester lorsque le développement et les tests sont presque terminés et on doit trouver les bugs et défauts finaux avant de lancer la version finale. Couramment faits par utilisateurs finaux ou par d autres que les testeurs ou développeurs (rejoigne aussi les test terrains). Test d Exploration : Utilisé souvent pour faire de tests créatifs, informels qui ne portent pas sur un plan ou cas de test formels: Des simples testeurs qui apprennent l application tout en la testant ou. Des testeurs d attaque qui se basent sur leur expérience sur des produits ou Technologies similaires tout en utilisant leur intuition pour anticiper la trouvailles des bugs via des cas de tests formels 20

Test & Vérification logiciel : Types de Tests 6/6 Test aux limites : Le principe de ce genre de test est de s intéresser aux bornes des intervalles partitionnant les domaines des variables d entrées. Ce genre de test se rejoigne aussi avec les tests de robustesse prenant le produit dans des conditions aux limites: Temps de réponse suite à la saturation de la BdD, Comportement suite à un faible débit de réseau, Test libre : Ou Aléatoire, déroulé souvent par des utilisateurs connaissant le produit mais sans stratégie particulière ou un suivi de cas de tests. Ce genre de test permet rapidement de chasser le maximum de bug au début d une campagne et de vérifier l acceptabilité du produit à la fin de la campagne. Test automatique: Ou plutôt tests automatisés sont des tests dont l exécution a été rendu automatisée. La création du test est plus ou moins assistée en fonction du type de test et de l outil utilisé. Les tests peuvent être des tests unitaires portant sur des fonctions ou des classes ou des tests fonctionnels via des scripts (batch). L analyse à froid des résultats de tests sera rendu disponible au testeur suite à une batterie en mode nuit, week-end, A noter que le mot Test automatique signifie la génération automatique de jeu de tests utilisant le plus souvent des outils du Framework de développement 21

Test & Vérification logiciel : Principe de Tests 1/3 Principe 1 Les tests montrent la présence de défauts : Les tests peuvent prouver la présence de défauts, mais ne peuvent en prouver l'absence. Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun défaut n'est découvert, ce n'est pas une preuve d'exactitude. Principe 2 Les tests exhaustifs sont impossibles : Tout tester (toutes les combinaisons d'entrées et de pré-conditions) n'est pas faisable sauf pour des cas triviaux. Plutôt que des tests exhaustifs, nous utilisons l'analyse des risques et des priorités pour focaliser les efforts de tests. Principe 3 Tester tôt : Pour trouver des défauts tôt, les activités de tests devraient commencer aussi tôt que possible dans le cycle de développement du logiciel ou du système, et devraient être focalisés vers des objectifs définis. 22

Test & Vérification logiciel : Principe de Tests 2/3 Principe 4 Regroupement des défauts : L'effort de test devrait être fixé proportionnellement à la densité des défauts prévus et constatés dans les différents modules. Un petit nombre de modules contient généralement la majorité des défauts détectés lors des tests pré-livraison, ou affichent le plus de défaillances en opération. Principe 5 Paradoxe du pesticide : Si les mêmes tests sont répétés de nombreuses fois, il arrivera que le même ensemble de cas de tests ne trouvera plus de nouveaux défauts. Pour prévenir ce paradoxe du pesticide, les cas de tests doivent être régulièrement revus et révisés, et de nouveaux tests, différents, doivent être écrits pour couvrir d'autres chemins dans le logiciel ou le système de façon à permettre la découverte de nouveaux défauts. 23

Test & Vérification logiciel : Principe de Tests 3/3 Principe 6 Les tests dépendent du contexte : Les tests sont effectués différemment dans des contextes différents. Par exemple, les logiciels de sécurité critique seront testés différemment d'un site de commerce électronique. Principe 7 L illusion de l absence d erreurs : Trouver et corriger des défauts n'aide pas si le système conçu est inutilisable et ne comble pas les besoins et les attentes des utilisateurs. 24

Test & Vérification logiciel : Code & Ethique L'implication dans le test logiciel permet aux individus d'avoir accès à des informations confidentielles et privilégiées. Un code d'éthique est nécessaire, notamment pour assurer que les informations ne soient pas utilisées dans des cas non appropriés. En référence au code d'éthique d ACM et de l IEEE pour les ingénieurs, ISTQB définit le code d'éthique suivant : PUBLIC les testeurs de logiciels doivent agir en fonction de l'intérêt public CLIENT ET EMPLOYEUR les testeurs de logiciels doivent agir pour l'intérêt de leur client et de leur employeur tout en respectant l'intérêt public PRODUIT les testeurs de logiciels doivent assurer que les fournitures qu'ils produisent (concernant les produits et les systèmes qu'ils testent) répondent le plus possible aux standards professionnels JUGEMENT les testeurs de logiciels doivent conserver leur intégrité et leur indépendance dans leur jugement professionnel 25

Test & Vérification logiciel : Processus de Tests 1/3 1. Organisation des tests : dans le plan de management au lancement du projet et dans le plan d assurance qualité produit 2. Rôles et responsabilités : Les responsabilités et les interfaces des personnes intervenant dans le processus de test : Responsable de tests, Concepteur de Test, Testeur Pas de développeur testant son propre code (ou une équipe Vs son Produit) Des testeurs indépendants voient des défauts différents et sont de nature Impartiaux Les experts métiers sont souvent engagés dans des tests de recette 3. Développement d une stratégie de tests: Définir les moyens à mettre en place pour tester le logiciel Décrire la stratégie de tests `a mettre en place pour tester la première version, tester les versions suivantes, critères d arrêt des tests Rédiger les fiches de tests sur la base de l analyse et conception des cas d utilisation et des cas aux limites et détailler en fonction de la criticité des différentes fonctions Passer en revue la stratégie, le plan et les cas de tests quant à leur testabilité, leur cohérence, leur couverture et les exigences de départ, 26

Test & Vérification logiciel : Processus de Tests 2/3 4. Planification et estimation de passage des tests Chronométrer le passage des fiches, Ecrire un calendrier d exécution des tests pour une série de cas de test donnés en tenant compte des priorités ainsi que des dépendances logiques et techniques Planifier avec des outils appropriés, planifier le passage aux bancs de tests, prévoir parfois des équipes 3x8, 5. Critères de sortie : Critères d acceptance et de qualification pour le passage à la livraison : Vecteur de Bugs (Critique, Majeur, Mineur, Evolution) Activités de clôture des tests et activité relative de la production de rapports et synthèse des tests. 6. Suivi et contrôle de l avancement des tests Le contrôle identifie les déviations par rapport à ce qui a été planifié ou les variations en termes d'atteinte des objectifs prévus, et propose des actions afin d'atteindre ces objectifs Juger la priorité des passages de tests par rapport aux dates jalons de livraisons Adapter le planning continuellement tout en entreprenant les actions nécessaires, 27

Test & Vérification logiciel : Processus de Tests 3/3 7. Gestion de configuration : Gestion des fiches de tests : Administration, Versionning, Traçabilité, partage entre les testeurs (et les développeurs) intégration avec la gestion des exigences 8. Risques et tests Décrire un risque comme un problème probable qui peut compromettre l atteinte des objectifs de projet d un ou de plusieurs acteurs Se rappeler que le niveau de risque est déterminé par sa probabilité d occurrence et son impact (dommages en résultant) 9. Gestion d incidents Rédiger un rapport d incident couvrant l'observation d une défaillance pendant le test Décrire les étapes de reproduction du scénario Etablir le rapport de synthèse de la campagne à partir des informations recueilli pendant le test et donner son avis nquant au critère de libération 28

Test & Vérification logiciel : Les fondamentaux Le test ne commence pas après que le logiciel soit développé. Il commence d`es la phase de spécification d un logiciel et se déroule durant chaque phase du cycle de développement. Le processus de test n'est pas limité à l'exécution du logiciel dans le but d'identifier des défaillances : il englobe aussi la définition de la stratégie, planification, conception des cas de tests, suivi & contrôle un logiciel ne pourra pas être mis en service si la démonstration de son bon fonctionnement n a pas été effectuée Un programmeur ne doit pas tester ses propres programmes (juge et partie) Le test logiciel est un métier à part entière 29

Test & Vérification logiciel : Cas d une fiche de test Test Sheet Description : Importing the external reference data By : mkh Test sheet : Gen_DbInst_001 Tested modules : IRIS Database Context : Database service name initialised Iris user created on the oracle service name Dumped external data file is given Condition of success : All expected results are observed STEP 1 2 3 ACTION Launch Imp command and supply the irisname account login Supply the path/name of the dumped external data And respond to all appearing questions Connect as irisname/irisname EXPECTED RESULT Connection succeeded Import of the external data finished with no error Connection succeeded Following entries are displayed: 4 Select * from tab ALPS_B_NUMBER_GROUP TABLE ALPS_ENGINEERING_ROUTE TABLE ALPS_RD_CARRIER TABLE ALPS_RD_CID_DEFINITIONS_VIEW TABLE Notes : this step is relative to XXX soft platform test For AZURE this step will be replaced by running a script to configure database links to external data in which case when starting: select * from USER_DB_LINKS; all needed data tables are displayed 30