Universiteit Gent Faculteit Toegepaste Wetenschappen
Vakgroep INTEC Informatietechnologie Voorzitter: Prof. Dr. Ir. Paul LAGASSE
Het gebruik van testscenario’s binnen Fortis Bank: automatisering en optimalisering door Jan TALBOOM
Promotor: Prof. Dr. Ir. Bart DHOEDT
SCRIPTIE voorgelegd tot het behalen van de graad van gediplomeerde in de Aanvullende Studie Informatica
Academiejaar 2000 – 2001
“We oefenden hard… maar het leek alsof we, telkens we een team begonnen te vormen, weer heringedeeld zouden worden… Later in het leven zou ik leren dat we elke nieuwe situatie op een reorganisatie onthalen, en wat een wonderbaarlijke manier kan dit toch zijn om een waan van vooruitgang te creëren, terwijl er enkel verwarring, inefficiëntie, en demoralisatie gesticht wordt.” Petronius Arbiter 1ste E na Chr.
Voorwoord De complexiteit in onze samenleving neemt immer toe. Dit blijkt ondermeer uit allerhande systemen en structuren, die -ondanks de alomtegenwoordige toegang tot de verschillende informatiemedia- enkel nog door ingewijden te doorgronden zijn. De vraag naar meer kwalitatieve en efficiëntere producten en diensten neemt evenwel niet af… Ze confronteert ons met het probleem hoe we deze dubbele uitdaging zullen aangaan. De antwoorden liggen een beetje voor de hand: complexiteit verminder je door vereenvoudiging en kwaliteit waarborg je door dingen vooraf te controleren op onvolkomenheden. De efficiëntie is dan verondersteld toe te nemen… Petronius’ zienswijze komt waarschijnlijk over als die van een reactionair cynicus. Ze is dan ook te nemen voor wat ze waard is. Het is in ieder geval wel zo dat reorganisaties en herstructureringen de jongste jaren erg populair zijn, niet in het minst in de bedrijfswereld. Schaalvergroting of strategische alliantievorming, al dan niet vijandige overname, er zijn redenen genoeg om bestaande entiteiten uit te bouwen tot grotere, maar helaas ook complexere gehelen. De banksector laat zich wat dit betreft niet onbesproken, met een reeks van fusies en overnames op zowel nationaal als internationaal vlak tot gevolg. Zo ook ontstond de Fortis Bank in 1999 uit de overname van de Generale Bank door de Fortis Groep en deze gebeurtenis zou op termijn aanleiding geven tot de eenmaking van de drie Belgische retail-bankpolen van de groep, te weten de Generale Bank/la Générale de Banque (GB), de Algemene Spaar- en Lijfrente Kas/la Caisse Générale d’Épargne et des Retraites (ASLK/CGER) en het Krediet aan de Nijverheid/le Crédit à l’Industrie (KN/CI). Dit eenmakingproces zou vooral op informaticavlak een uitdaging worden vermits de drie banken wegens de omvang van het project slechts stapsgewijs naar elkaar toe kunnen groeien. Bovendien moet de dienst aan de cliënteel zoveel mogelijk verzekerd blijven gedurende dit proces, alsof men in volle zee van drie boten één schip moet proberen maken... De drie kantoorplatformen BankStation (GB), Candle (ASLK/CGER) en MIA (KN/CI) moeten uiteindelijk met dezelfde Pacific-toepassing overweg kunnen. Dit ondanks de verschillende architecturen en de verscheidenheid aan randapparaten (printers, Bank Branch Device, …). Pacific werd reeds door de voorheen ASLK gebruikt in hun kantorennet, maar moet nu dus toegankelijk worden voor de voorheen GB (volledige functionaliteit) en KN (met beperkte functionaliteit en andere bevoegdheden, de zogenaamde BluePacific). Dit is uiteraard geen sinecure: er dient code aangepast te worden, de architectuurverschillen moeten overbrugd worden en al deze aanpassingen dienen uitvoerig gecontroleerd en getest te worden alvorens ze effectief in het kantorennet operationeel mogen worden.
Deze studie zal zich toepspitsen op het testen van de voornoemde wijzigingen en adaptaties aan de Pacific kantoorapplicatie, alvorens ze aan de voorheen GB of KN-kantoren wordt toevertrouwd. Het doel is in de eerste plaats de huidige testprocessen binnen het Departement Integratie van de Fortis Bank te analyseren en vertrekkende hieruit een uniform en algemeen toepasbaar sjabloon te distilleren. Belangrijker nog is dat deze gelegenheid in tweede instantie ook zal aangegrepen worden om na te gaan in welke mate deze processen verder geoptimaliseerd en geautomatiseerd kunnen worden, voor zover ze dit al zijn. Het resultaat zal dan aan de praktijk getoetst worden binnen de ontwikkeling- en testomgeving van de Fortis Bank. Om dit te realiseren worden uiteraard de processen bekeken zoals ze zich momenteel in de realiteit voordoen, maar inleidend zal er ook gekeken worden naar de theorie die omtrent de software testproblematiek reeds verschenen is.
Het gebruik van testscenario’s binnen Fortis Bank: automatisering en optimalisering door Jan TALBOOM
SCRIPTIE voorgelegd tot het behalen van de graad van gediplomeerde in de Aanvullende Studie Informatica
Academiejaar 2000 – 2001
Promotor: Prof. Dr. Ir. Bart DHOEDT Faculteit Toegepaste Wetenschappen Universiteit Gent
Vakgroep INTEC Informatietechnologie Voorzitter: Prof. Dr. Ir. Paul LAGASSE
Samenvatting
Deze scriptie handelt over de ontwikkeling van een software testing tool, die de medewerkers van het departement Integratie van de Fortis Bank kan helpen bij het testen van Pacific, de kantoorapplicatie binnen Fortis Bank. Het werk bestaat uit 5 delen. Het voorwoord schetst de situatie van Fortis Bank in het Belgische banklandschap, na de recente fusies en de gevolgen van deze fusies voor het informaticaplatform. De inleiding concentreert zich op de software testingproblematiek, vertrekkende vanuit een definitie voor de termen “software” en “testen”. Ze buigt zich tevens over enkele theoretische aspecten en modellen, om dan de specifieke testterminologie te belichten. Het corpus behandelt enerzijds de praktijk van het software-testen binnen Fortis Bank vandaag de dag en anderzijds de ontwikkeling van de testing tool zelf. Het betreft hier een programma in Visual Basic dat de TFM-code (programmeertaal waarin waarin Pacific geschreven is) scant op zoek naar de namen van invoervelden en dat deze namen dan importeert in een Excelbestand. Het zo gegenereerde Excelbestand vormt dan de basis voor een testscenario, dat de integrator met testgegevens dient aan te vullen alvorens over te gaan tot acceptatie- of regressietesten. De conclusie herneemt het waarom van softwaretesten, naast de mogelijkheden en beperkingen om deze activiteit te automatiseren. In de annex vindt men tot slot de Visual Basic-code van de testing tool en enkele voorbeelden van de applicatiecode in TFM. Trefwoorden: software testing, text parsing, testscenario’s, TFM, Pacific
Description du contenu Ce mémoire, rédigé dans le cadre d’une formation supplémentaire en informatique vise au développement d’un outil de test. Cet outil assistera les membres du département Intégration de la Fortis Banque dans leurs activités, qui se situent dans le domaine du testing de l’application bancaire Pacific. L’ouvrage consiste de 5 volets : une préface, une introduction, un milieu, une conclusion et une annexe. La première partie esquisse la situation actuelle de la Fortis Banque dans le monde bancaire belge avec un aperçu des fusions récentes et de leurs conséquences sur le plan informatique. L’introduction se concentre sur la problématique de tester des logiciels, avec d’abord une définition des mots "logiciel" et "tester" et puis une approche théorique de cette activité, avec quelques modèles et la terminologie propre à ce domaine. Vient ensuite le milieu, qui porte sur le testing tel qu’il existe aujourd’hui au sein de la Fortis Banque et le développement même de l’outil. Cet outil est un logiciel en Visual Basic qui devrait aider les intégrateurs à tester les nouvelles versions de l’application agence Pacific. À cette fin, il parcourt d’abord le code Pacific pour en extraire les noms des champs à remplir. En second lieu, ces noms seront introduits dans un fichier Excel et formeront ainsi le support pour un scénario de test. Ce scénario sera ensuite complété avec des données de test par les intégrateurs pour qu’ils puissent effectuer leurs tests d’intégration et de régression. La conclusion résume le pourquoi des tests, et tente de délimiter les possibilités et les restrictions au niveau de l’automatisation de tests. Dans l’annexe finalement le lecteur trouvera le code en Visual Basic et quelques exemples du code en TFM, la langue dans laquelle le code Pacific est écrit.
Contents description This dissertation was written within the scope of supplementary studies in informatics and aims the development of a software testing tool. This tool will help the staff of the Integration department at Fortis Bank, whose work is essentially the testing of the Pacific application, used in the branches of Fortis Bank. There are 5 parts to be distinguished: a preface, an introduction, a main part, a conclusion and an annex. The first part situates Fortis Bank in the Belgian banking after the recent fusions and this from an informatics viewpoint. The introduction concentrates on software testing as a theoretical discipline, after defining what “software” and “testing” are. It also gives an overview of some theoretical models and of the specific terminology. The main part is about the actual testing activity at Fortis Bank and the development of the testing tool, both of course in relation to the Pacific branch application. The tool -a Visual Basic program- will first scan the TFM-code (programming language in which Pacific is written) for the names of the data-fields and then import these names into an Excel-file. This file will form the basis for a testing scenario that the integrators can complete with test data and then use to execute their acceptation and regression tests. Why we test is stated in the conclusion. Also some remarks about the possibilities and restrictions of automation in relation to software testing are to be found in this part. As a final part, the annex contains the Visual Basic-code and some samples of the TFM-code.
Graag had ik Prof. Dr. Ir. Bart Dhoedt bedankt voor de vorming, de raad en begeleiding die ik dit academiejaar en meerbepaald tijdens de voorbije “scriptieweken” van hem kreeg. Verder zou dit werk onmogelijk geweest zijn zonder de faciliteiten en bijstand geboden door de collega’s van Fortis IT Branch. Zeker Chris De Laet, Jan Van Hove, Jozef Roothooft en Theo Derycke verdienen mijn erkentelijkheid voor hun opvang en toelichtingen. En tot slot genoot ik (en geniet ik nog steeds) de volle steun van mijn ouders, Hilde, Rik, Rebecca en Henk, waarvoor, aan jullie allen, een welgemeende BEDANKT!
1. Inleiding
1 1.1.
Wat is software testing eigenlijk?
1
1.2.
Het watervalmodel en het V-model
4
1.3.
Testen in de praktijk
6
2. Het gebruik van testscenario’s binnen Fortis Bank
17
2.1.
Het testen binnen het IT-project van Fortis Bank
17
2.2.
Analyse van de gangbare testpraktijken binnen het departement Integratie
20
2.3.
Word of Excel voor het opstellen van een scenario?
21
2.4.
Automatisering binnen testscenario’s
22
2.5.
Het Excel testscenario en toelichting
31
3. Conclusies
32 3.1.
Is testen zinvol?
32
3.2.
Hoe dient dit het beste te gebeuren?
32
3.3.
Wat zijn de mogelijkheden en beperkingen van automatisering hierbij?
33
4. Annexen
4.1. Voorbeeld: code van een (kort) dialoogmodel in TFM 35 4.2. Voorbeeld: code van een datasectie in TFM
39
4.3. Voorbeelden van een deelapplicatiescherm en een volledig applicatiescherm
4.4. VB-code Tacos
40 42
Bibliografie
53
Index
54
1. Inleiding 1.1. Wat is Software Testing eigenlijk? De helft van de tijd in een (software)ontwikkelingsproces wordt gespendeerd aan “kijken of het werkt”. Toch is er weinig over software testen bekend en is literatuur dienaangaande eerder schaars. Studenten leren programmeren maar nauwelijks 1 hoe deze programmatuur (systematisch) kan worden getest. Velen menen bovendien dat iets gemaakt wordt, om het dan te testen en tot slot te produceren of te commercialiseren; de voorlaatste stap komt er nog even bij om aan te tonen dat het weldegelijk werkt. Vaak wordt de stap zelfs oppervlakkig gezet of gewoon overgeslagen door tijdsdruk. Eigenlijk kan software testen gezien worden als een vaardigheid, waar eventueel een aantal CAST (Computer Aided Software Testing) tools hulp kunnen bieden. Net zo min men een schrijnwerker wordt door zich in een doe-het-zelfzaak een hamer, een beitel of een zaag aan te kopen, wordt men een softwaretester door zich een tool aan te schaffen: men moet dit leren gebruiken door kennis van theorie en methodiek, door training en ervaring. Een tool kan de professionele tester uiteraard wel ondersteunen in zijn taken, maar vervangt diens know-how niet.
Wat is software? Volgens het van Dale woordenboek is software het geheel van “programma’s, gegevens e.d. die gebruikt, bewerkt of verwerkt worden in (de elektronische) apparatuur of hardware”. Deze definitie is vandaag misschien al een beetje verouderd en erg algemeen. Een recentere definitie 2 is “[De] opeenvolging van instructies die een computer dient uit te voeren noemt men een (computer)programma, en onder software verstaat men een verzameling van dergelijke programma’s”. Het doel van de scriptie is echter niet een volledige definitie van software te geven, maar eerder te bepalen hoe sofware getest kan worden.
Wat is testen? Testa betekent in het Latijn onder andere aardewerken pot, zoals die gebruikt werd om metalen te smelten en te bepalen of er al dan niet (en zo ja in welke mate) waardevol metaal in een legering aanwezig was. Ondertussen is de betekenis van het woord aanzienlijk verruimd en is test(en) een erg alledaags woord geworden. Wat verstaan we vandaag onder die ruime betekenis van testen? Bewijzen dat iets werkt? Aantonen dat ergens geen fouten inzitten? Of is het beter te vertrekken vanuit het doel: kwaliteit leveren? Gelden bovenstaande omschrijvingen dan ook voor het testen van software? Of moeten we het in dat geval eerder interpreteren als het tegengestelde van wat hierboven gesteld wordt: precies het zoeken naar fouten? Als men alleen zou willen aantonen dat software doet wat ze verondersteld is te doen, dan weet men nog niet of ze niet doet wat ze niet verondersteld is te doen. Testing is the process
1
Tijdens de programmeeropdracht voor het vak algoritmisch denken en programmeren dit jaar werd gelukkig wel expliciet gevraagd de oefening te testen. Hoe dit diende te gebeuren maakte deel uit van de oefening en werd aan de creativiteit van de studenten overgelaten.
2
DHOEDT, Bart, PICKAVET, Mario, syllabus Algoritmisch denken en programmeren, RUG, Vakgroep Informatietechnologie, 2000.
of executing a program with the intent of finding errors 3. Als men zich met deze ingesteldheid aan het testen zet, dat wil zeggen met de bedoeling het systeem te laten falen, zal men ongetwijfeld anders tewerk gaan dan wanneer men gewoon nagaat of wat men net zelf geschreven heeft netjes doet wat het verondersteld is te doen. Zo koopt niemand een auto om hem zo snel mogelijk rond een boom of tegen een muur te parkeren, maar om er zich in de eerste plaats mee van A naar B te begeven. Toch voelen we ons meer gerustgesteld als we weten dat onze wagen niet alleen rijdt, maar ook veilig door een crashtest gekomen is. Testen is dus in wezen een destructieve bezigheid, daar waar het ontwikkelen creatief is. En de ingesteldheid van een tester beïnvloedt zijn manier van testen: test hij om aan te tonen dat er geen fouten in zitten of om te bewijzen dat ze er juist wél zijn? Het gaat echter niet om het vinden van alle fouten, want men weet nooit om hoeveel fouten het gaat. Het enige wat men weet is dat men op een bepaald ogenblik zal moeten stoppen met testen… Een andere benadering kan het vergelijken zijn van de bekomen resultaten met de verwachte resultaten. Hoe dan ook, de vraag blijft: is dit product ons vertrouwen waard? Het testen beantwoordt deze vraag schijnbaar paradoxaal: een test die veel fouten aan het licht brengt ondermijnt het vertrouwen, hoewel we juist door het testen vertrouwen in het product wilden krijgen… The best way to build confidence is to try to destroy it! Tot slot, wat is nu een succesvolle test? Een test die fouten ontdekt is succesvol. En als er geen fouten gevonden worden, kan dit twee redenen hebben: er zijn geen fouten (maar perfectie is niet van deze wereld) of het was een bedenkelijke test (perfectie is inderdaad niet van deze wereld…). Als theorie is dit allemaal erg mooi, in de praktijk kan men hier echter niet altijd mee akkoord gaan: als er geen fouten gevonden worden is het nuttig om de kwaliteit van het testproces nog eens te evalueren, maar als die OK is betekent dat dat het systeem voldoet aan de gestelde kwaliteitseisen. Een test die geen fouten ontdekt kan dus ook zeer succesvol zijn!
Is testen hetzelfde als debuggen? Beide termen worden al eens met mekaar verward, hoewel er weldegelijk een onderscheid bestaat. Boris Beizer stelt het als volgt: The purpose of testing is to find bugs. The purpose of debugging is to find the error or misconception in the program that lead to the failure and to implement the program changes to correct the error 4. Testen is dus niet hetzelfde als debuggen en vergt dan ook een andere aanpak.
De beperkingen van het testen Met testen alleen komt men niet tot kwalitatieve software. Er is ten eerste het feit dat niet alles kan getest worden, dit om technische, financiële of andere redenen. Verder is testen maar één van de (weliswaar belangrijkste) activiteiten binnen een heel proces die ervoor zorgen dat er kwalitatieve software geproduceerd wordt. Daarnaast zijn ook de keuze voor een bepaalde programmeertaal, een grondige analyse, goedgeschreven code en een correct gebruik van standaarden en tools van belang. 3
4
MYERS, Glenford J., The Art of Software Testing, John Wiley, New York, 1979.
BEIZER, Boris, Software Testing Techniques, Van Nostrand Reinhold Co., New York, 1983, Second Edition 1990.
Tot slot zijn er zowel logische als theoretische beperkingen aan het testen: You can never be sure that the specifications are correct. No verification system can verify every correct program. You can never be sure that the verification system is correct 5. Na deze sceptische bemerkingen kan men zich afvragen of testen überhaupt zinvol, laat staan mogelijk is. Het zal altijd op een compromis uitdraaien, maar het moet duidelijk zijn dat testen meer vereist dan enkel een kritische houding.
Inleidende testing terminologie Verder in deze scriptie zal ingegaan worden op een aantal technieken; inleidend worden nu al enkele meer algemene en erg frequente testtermen toegelicht:
5
•
Test case: een testcase specifieert een individuele vereiste die getest moet worden. Hiervoor bepaalt het de nodige input, de condities waaronder de test moet plaatsgrijpen en de verwachte of vooraf bepaalde output voor de test. Een testcase wordt vaak gezien als een “validatiepunt”.
•
Test procedure: een testprocedure omschrijft een specifieke opeenvolging van stappen die nodig zijn om een testcase of een aantal testcases uit te voeren. Testprocedures die gebruik maken van een CAST tool (zoals WinRunner®, cf infra) worden vaak testscenario’s of testscripts genoemd. Deze testscripts worden soms afgeleid van “opnames van gebruikerssessies”. Een goede testprocedure is eerder klein en omvat niet veel testcases (vaak niet meer dan vijf). Een slechte testprocedure is een test waar typisch een volledige functionaliteitstest of erger, een complete applicatiemodule of applicatie wordt getest.
•
Test: test is de moeilijkste van alle termen, daar hij vaak verward wordt met zijn algemene, taalkundige betekenis. Specifiek voor softwaretesting beschrijft een test het complete uitvoeringsproces van één of meer testen (in de technische betekenis) of testprocedures. Als dusdanig is een test een recursief gegeven, daar een test andere testen kan omvatten. Hier betekent test dan welke procedures er uitgevoerd dienen te worden, wie de test moet doen (of aan welk profiel de tester moet voldoen) en wat de omgevingsvereisten moeten zijn (initialisatie van een databank, testplatform).
•
Test session: een testsessie is de activiteit uitgevoerd door een tester die één of meer testen uitvoert. Testsessie heeft meer een tijdsbetekenis daar waar de andere termen een technische betekenis hebben.
•
Tester: is iemand die testen uitvoert. Het kan om een IT’er gaan (ontwikkelaar, analist, formele tester) of een gebruiker. Deze functie bestaat niet altijd als een aparte functie binnen een organisatie en wordt vaak gecombineerd met een hoofdfunctie als ontwikkelaar, gebruiker, enz.
MANNA, Zohar, WALDINGER, Richard, The logic of computer programming, IEEE Transactions on Software Engineering, SE-4, 1978.
Waarom wordt er getest? Omdat we denken dat er fouten zijn; mensen maken fouten en computers voeren ze uit. Een misvatting omtrent testen is dat we kwaliteit zouden moeten inbouwen en verder geen aandacht meer moeten besteden aan het uittesten op fouten. Het is echter onmogelijk om fouten uit te sluiten, we kunnen enkel proberen het gemaakte aantal fouten te beperken, eventueel via kwaliteitsprocedures. Softwaretesten blijft bovendien een bijzonder heikele zaak omdat het bouwen van professionele applicaties nog steeds veel weg heeft van een ambacht. Het gebruik van een aantal tools zoals CASE (Computer Aided Software Engineering), code generatoren, debuggers, CAST (Computer Aided Software Testing), … verandert hier niet veel aan en software engineering blijft een eerder ijdel woord. De analyse van functionaliteit is nog steeds een relatief nieuw gegeven. Een computerprogramma is een abstract iets, het voert enkel functies uit. Net als het programma geeft de functionaliteit waaraan het programma moet voldoen zich enkel via een abstractie te kennen. De moeilijkheid waarmee de functionaliteit van een applicatie zich laat omschrijven kan verder nog gecompliceerd worden door de persoonlijke formuleringen, interpretaties en verzuchtingen van de verschillende gebruikers. En dan moet dit alles nog op een eensluidende manier gecommuniceerd worden van gebruiker naar analist en van analist naar ontwikkelaar… De kans dat de gebruiker uiteindelijk ontvangt wat hij precies nodig heeft (had? 6), is helaas gering. Dit alles heeft uiteraard ook een impact op het testen: het dient snel, vaak herhaaldelijk en waar mogelijk automatisch te gebeuren.
Wat moet er getest worden? Net zo min men alle fouten kan vinden, kan men alles testen. Dit zou immers inhouden dat men elke functionaliteit, op elke mogelijk manier of in elke mogelijke combinatie, onder elke mogelijke omstandigheid met elke mogelijke data-input zou moeten controleren… Er dient dus geselecteerd te worden en dit met in het achterhoofd “Managing and controlling our business risks related to the IT infrastructure” of met andere woorden: “Hoeveel mag een fout ons (niet) kosten?”.
1.2. Het watervalmodel en het V-model Een basismethodologie die ons kan bijstaan bij de keuze van wat er moet getest worden is het V-model. In feite komt het erop neer dat het V-model de erkenning van het testen als een echte software engineering activiteit wil bepleiten. Dit vergt planning, analyse, ontwikkeling, uitvoering en evaluatie. Het V-model wil beter doen dan het klassieke watervalmodel, waar de ontwikkeling in sequentiële fases verloopt: • Bepalen van de bedrijfsobjectieven • Definitie van de gebruikersvereisten • Opstellen van het logische design • Creatie van het fysische design • Opstellen van het programma/unit design • Coderen • Testen Schema van het watervalmodel 6
Er verloopt immers ook nog tijd tussen de vraag naar het product en de oplevering ervan. Het is maar zeer de vraag of de gestelde deadlines gehaald werden, of de vereisten intussen alweer niet veranderd zijn…
Historisch gegroeid kampt dit model toch met enkele flinke nadelen: ook al zijn we nog zo zorgvuldig en aandachtig in het bepalen van de doelstellingen en het analyseren van de vereisten, het testen komt pas op het einde van het proces aan bod. Dit verhindert het uitwerken van goede testen: die worden immers best ontworpen tijdens de betreffende fase van de ontwikkeling. Een ander gevaar is dat er helemaal niet meer getest wordt, wegens tijdsdruk () op het einde van de ontwikkeling. Bij het opstellen van kwaliteitstesten zou dus elk deel van het ontwikkelingsproces zijn testtegenpool moeten hebben. Dit probeert het V-model te verwezenlijken, vermits men volop met dat aspect op dat ogenblik bezig is. Om te beginnen moet nagegaan worden of de juiste strategische keuzes gemaakt werden. Een audittest moet dit in een initiële fase nagaan. De gebruikers worden meer betrokken en aangespoord om direct na het formuleren van hun vereisten ook na te denken over hoe de acceptance testen eruit moeten gaan zien. De omschrijving van hoe de gebruikers het systeem gaan valideren kan bovendien verrijkend zijn voor de functionele analyse. Mutatis mutandis heeft de logische designfase haar tegenpool in de systeemtest, het fysische design in de integratietest, het programma en de unit design in de unit test. Het coderen vindt een partner in het debuggen. Zo komen we tot volgend model: Strategische keuzes
System audit
Gebruikersvereisten
Acceptance test
Logisch design
System test
Fysisch design
Integration test
Programma design
Programma en/of Unit test
Coderen
Schema van het V-model
Bij het watervalmodel beslaat het testen slechts één module, dit kan laten vermoeden dat testen slechts 1/7 van het ontwikkelingsproces is; het V-model eist een even grote rol op voor het testen als voor het ontwikkelen zelf. Het model zorgt niet alleen voor een efficiëntere tijdsverdeling tussen ontwikkeling en testen, maar staat ook borg voor beter doordachte testen. Verder bevordert het de interactie tussen gebruikers en ontwikkelaars. Communicatiefouten worden immers vroeger ontdekt als de testvereisten (opgesteld door de gebruikers) direct vergeleken kunnen worden met de functionele omschrijving (zoals de ontwikkelaars die opstelden). De termen, zoals hierboven vermeld in het rechterbeen van het V-modelschema, verdienen nog een verdere toelichting: •
System audit: dit is de bovenste laag van het model. Het gaat om een periodiek uitgevoerde test die enerzijds nagaat of de applicatie nog steeds deel uitmaakt van
de gekozen strategie en anderzijds of de gevolgde strategie nog wel toepasbaar is. De vragen die hier rijzen zijn: o o o
Is het gekozen hardwareplatform wel geschikt? Veroorzaakt de applicatie grote fouten in de productie? Zijn de vooropgestelde gebruikersprocedures (manier van werken) nog up-todate?
•
Acceptance test: dit soort test geniet allicht de grootste bekendheid, maar niettemin is het één van de meest complexe om uit te voeren. Deze test streeft ernaar de fouten te achterhalen die de gebruikers ervan (zouden kunnen) weerhouden de door hen gevraagde functionaliteit te benutten. Daarom omvat dit type test eigenlijk een waaier meer specifieke testen zoals functionaliteittesten, volumetesten, veiligheidstesten enz. We komen hier later op terug.
•
System test: een systeemtest beoogt het testen van de hele applicatie of het hele systeem om na te gaan of het geheel al dan niet aan de vooropgestelde eisen voldoet. Ook deze test wil verifiëren of er fouten gerezen zijn die de functionaliteit van de applicatie in het gedrang brengen en in deze zin komt de inhoud overeen met die van een acceptance test. Er bestaat evenwel een verschil op het niveau van de personen die de test uitvoeren en de omgeving waarin dit gebeurt: de system test gebeurt door IT-mensen, daar waar de acceptance test gebeurt door de gebruikers.
•
Integration test: een integratietest spitst zich toe op het vinden van fouten in een geïntegreerd deel van de applicatie dat meerdere units omvat (zoals we verder zullen zien de FB-kit vóór een release). Men mag er immers niet van uitgaan dat units die afzonderlijk correct werken dit ook doen als ze samengebracht worden met andere units. Fouten kunnen opduiken in de interfaces tussen de units, of de units kunnen mekaar onderling in hun werking beïnvloeden. Integratietesten zijn haast overal aanwezig, maar bijna nooit formeel gedefinieerd. Ook worden ze vaak beschouwd als een deel van de unit- of moduletest, hoewel ze onmogelijk op unit- of moduleniveau kunnen uitgevoerd worden.
•
Unit test: unit- of moduletesten is het testen van het kleinste betekenisvolle programma, deelprogramma of subroutine. Opzet is het vinden van situaties waarin de unit niet doet wat de vereisten voorschrijven. Dit kleinschalige testen laat toe de combinatorische mogelijkheden te controleren alvorens die in het veel grotere geheel van de applicatie compleet onoverzichtelijk worden.
1.3. Testen in de praktijk Wanneer moet er getest worden? Van zodra we weten dat er getest gaat worden, kunnen we ons 2 vragen stellen: wanneer beginnen we ermee en hoelang zullen we dit doen? Het antwoord op de eerste vraag kan kort, klaar en duidelijk zijn: ASAP Het lijkt misschien weinig genuanceerd, maar er zijn nochtans goede redenen voor. Het is de evidentie zelve dat hoe vroeger een fout ontdekt wordt, hoe lager de kosten zijn voor het corrigeren ervan. Een fout die in het ontwerp ontdekt wordt moet niet eerst geprogrammeerd
worden, laat staan nadien geïmplementeerd om steeds opnieuw te bewijzen wat we al wisten. Nochtans mag men hier niet uit afleiden dat vroeg testen ook per definitie betekent vroeg testen uitvoeren. Een test bestaat immers niet alleen uit zijn uitvoering, maar in de eerste plaats uit de gedachte erachter, uit de definitie van de test. Het V-model verplicht ons om bij elke fase –dus ook de beginfase- over het testen na te denken en dus ook om bij elke fase relevante testen te definiëren. De tweede vraag echter laat zich niet zo eensluidend beantwoorden: één van de grote beperkingen van het testen is dat het nooit beëindigd is. En zeker niet als we testen zien als het verwijderen van alle fouten, omdat we nooit weten hoeveel fouten er in het programma zitten, laat staan waar ze zitten. Leitmotiv bij het beantwoorden is net als bij de eerste vraag: geld of, in bedrijfstermen, budget. Men moet testen zolang dit economisch te rechtvaardigen valt Anders gezegd moet men een evenwicht zoeken tussen de testkosten (tijd, mensen, middelen en tools) en de mogelijke kosten die een niet verbeterde fout in de applicatie met zich zou brengen (onderhoud- en herstellingkost, verlies voor het bedrijf aan geld en aan imago). Dit moet dus geval per geval afgewogen worden, maar er kunnen toch enkele slechte en goede richtlijnen meegegeven worden. Slechte richtlijnen om te stoppen met testen: o o o
Als de geplande tijd verstreken is Als het product moet opgeleverd worden Als er geen fouten gevonden werden met de gedefinieerde testen
Goede richtlijnen om te stoppen met testen: o o o o
Als er aan de vereisten voldaan is Als de vereiste testtechnieken toegepast werden Als er voldoende fouten gevonden werden (maar hier kan men uiteraard geen getal opplakken!) Als de tijd tussen het opduiken van de fouten (MTBE: mean time between errors) onder een bepaalde waarde gezakt is (cfr grafiek p.15)
Het definiëren van de optimale testen en van de optimale testprocedure hangt –zoals reeds gezegd- af van het specifieke “economische evenwicht” dat in elk individueel geval gezocht moet worden. Dit mag er ons evenwel niet van weerhouden om doorheen de tijd verbetering na te streven, telkens wanneer testcases en –procedures herbekeken of aangepast worden.
Hoe moet er getest worden? Als we al het voorgaande in overweging nemen, kunnen we nu al zeggen dat testen efficiënt en productief dient te gebeuren. Maar hoe worden deze twee vereisten nu naar de praktijk vertaald?
Engagement Het bedrijf of de organisatie moet ten eerste overtuigd zijn van het nut van testen en het erkennen als een noodzaak.
Een zekere theoretische kennis omtrent testen is een must en deze kennis moet door alle mensen die bij het testproces betrokken zijn gedeeld worden. Testen verdient ook een aparte plaats in het projectplan, zodat er voor deze aparte activiteit afzonderlijke tijd en middelen kunnen uitgetrokken worden. Tot slot moet testen strategisch en volgens bepaalde technieken gebeuren.
Teststrategieën Willekeurig, volgens intuïtie of ervaring of volgens het V-model… er zijn meerdere benaderingen mogelijk: •
Willekeurig: het hoeft geen betoog dat deze aanpak de meest amateuristische en onproductieve is. De efficiëntie ervan laat zich niet bepalen, maar daarmee is nog niet bewezen of ze daarom per definitie inefficiënt moet zijn. Sterker nog, sommige testen vereisen een willekeurige benadering, omdat we altijd denken iets over het hoofd gezien te hebben. Het willekeurig testen kan bijdragen tot het welslagen van het testen, maar niet -zoals men zou verwachten- door willekeur in te voeren bij de keuze van testdata, maar bij het opstellen van de testprocedure 7. Bij normaal gebruik zijn input- en outputdata gedefinieerd door de gebruikersvereisten. De manier waarop de applicatie gaat gebruikt worden is veel moeilijker te bepalen. Het probleem wint verder aan belang bij het gebruik van GUI’s (graphical user interface), die de gebruikers nog veel vrijer laten in het doorlopen van schermen en vensters, zodat in praktijk de dynamiek enorm toeneemt en het onvoorspelbare moet getest worden. Een (gebreidelde) creativiteit is hier dus nodig om efficiënt te testen.
•
Intuïtie en ervaring: deze benadering creëert bij de doorgewinterde tester de overtuiging dat hij of zij efficiënt aan het testen is, maar is dit wel zo? Deze werkwijze kan best productief zijn, want ervaring is hoe dan ook niet zonder belang. Toch zijn ervaring en intuïtie niets zonder techniek. Opgedane kennis en ervaring kunnen immers als oogkleppen gaan fungeren en de tester beletten open te staan voor interessante alternatieven. Laatste aspect is het menselijke aspect van de factoren intuïtie en ervaring: als dit de drijfveren van het testproces zijn, kan de kwaliteit van het testen bezwaarlijk stabiel genoemd worden. Verder bestaat het risico dat bij een personeelswissel een deel van het testproces mee vertrekt, wat niet bepaald wenselijk is. Slotsom is dat intuïtie en ervaring nooit aangewend mogen worden om techniek te vervangen, maar dat ze er moeten zijn om de techniek te verrijken.
•
V-model: het gebruik van een gestructureerde testmethode zoals het V-model is duidelijk de beste manier om tot productief en efficiënt testen te komen: o o o o o o
7
de keuze van de testen wordt bewust gemaakt (volgens de fase) testen kunnen beter ontwikkeld worden door een beter overzicht het bevordert de communicatie tussen de betrokken entiteiten er wordt een evenwaardige test- en ontwikkelingsinspanning geleverd testen zijn opnieuw bruikbaar testen maken volwaardig deel uit van het project
In de praktijk wordt er bij Fortis Bank bijvoorbeeld gecontroleerd op het overschrijven van gegevensvelden. Dit blijkt niet altijd aanvaard te worden door de applicatie, maar is een zeer reëel gegeven bij de gebruikers in het kantoor. Bvb.: een cliënt vraagt geld op aan het loket, maar bedenkt zich tijdens de transactie en verhoogt of verlaagt het initieel gevraagde bedrag. De rekening moet uiteindelijk met het juiste (laatst ingebrachte) bedrag gedebiteerd worden.
Testtechnieken Er bestaat een heel scala aan testtechnieken en –methodes. Het overzicht hier pretendeert dan ook helemaal niet volledig te zijn. Aangezien elke methode of techniek verwant is met een specifieke context, beperkt het overzicht hier zich tot de meest courante, met als hoofdpijlers black box testing en white box testing. Black Box Testing Hierbij wordt de geteste applicatie door de tester beschouwd als een zwarte doos, een gegeven waar hij geen inzicht in heeft. Wat hij wél weet is de functie van de applicatie; hij weet dat een zekere input of actie een welbepaalde output of reactie moet genereren. Hoe de input in de “zwarte doos” gemanipuleerd wordt om tot de output te komen doet voor de Black Box tester niet ter zake. Zijn taak bestaat erin te bepalen in welke gevallen de applicatie geen correcte output verstrekt of wanneer ze niet reageert als voorgeschreven in de specificaties. De testdata wordt afgeleid uit de specificaties van de te testen applicatie. Het is niet de bedoeling dat het testen alle mogelijke inputwaarden controleert (“exhaustive input testing”). Door het soms oneindige aantal inputwaarden (geldige en ongeldige waarden) zou dit in veel gevallen onbegonnen werk zijn, dus moet er selectief met testdata omgesprongen worden. Hoe hoger het testniveau (hoger in het been van de van de V, of anders gezegd, dichter bij de eindgebruiker), hoe groter de kans dat Black Box Testing de aangewezen strategie is. Zo is een acceptance test door een gebruiker altijd een Black Box Test. Andere benamingen voor Black Box Testing zijn data-driven testing en input/output testing. White Box Testing Bij White Box Testing of Glass Box Testing benadert de tester de applicatie dan weer als en doorzichtig gegeven. Hij gaat na hoe de applicatie de data gaat manipuleren en buigt zich hierbij over de interne werking van het programma of stukken code. Met andere woorden, de interne structuur of logica vormt het vertrekpunt om testen en testdata te definiëren. Het kan hierbij zelfs gebeuren dat de applicatiespecificaties terzijde gelegd worden. Net zo min als een uitvoerige inputdata test mogelijk is, is een uitvoerige logicatest haalbaar. Dit zou veronderstellen dat elk mogelijk pad doorheen de code wordt nagegaan. Zelfs bij beperkte mogelijkheden qua inputdata kunnen enkele lussen en beslissingen (die eventueel afhangen van andere beslissingen) al voor een astronomisch aantal mogelijke paden zorgen. En dan nog, het overlopen van de mogelijke paden bewijst niet dat een applicatie aan de specificaties voldoet… Men kan bijvoorbeeld niet controleren of er geen paden ontbreken, want wat er niet is kan niet falen.
Waar dient men nog rekening mee te houden? Het lijkt de evidentie zelve, maar het wordt blijkbaar vaak uit het oog verloren: men moet vóór het testen al bepaald hebben wat de verwachte resultaten zijn. Als dit niet het geval is dreigt het gevaar dat een plausibel, maar verkeerd resultaat als correct beschouwd wordt. Derhalve is het van belang zowel de inputdata als de outputdata te beschrijven. Dan nog is het mogelijk dat de verwachte outputdata niet correct is (want dit is niet altijd even eenvoudig te bepalen en in het proces om ze te bepalen kunnen ook nog fouten sluipen), maar de tester is desgevallend toch gealarmeerd dat er ergens iets schort, en zal het voorgestelde resultaat niet klakkeloos aanvaarden. Kortom, men kan een resultaat niet op zijn correctheid beoordelen, als men niet weet wat het correcte resultaat is.
Welke technieken bestaan er om de testen uit te voeren? Er bestaan meerdere White Box technieken om fouten op te sporen: code inspections, walkthroughs en desk-checking. Ze hebben allemaal wel iets gemeen, maar hebben toch ook hun eigen werkingsprincipes en voordelen. •
Code inspections: deze White Box Testing techniek wordt tijdens de unit-testing fase gebruikt en steunt enerzijds op het lezen van de code in groep en anderzijds op een aantal procedures die een efficiënt en formeel testproces garanderen. Een testteam bestaat uit gebruikelijk vier personen: de auteur van het programma, een moderator en twee overige teamleden (vaak een programmaontwerper of – ontwikkelaar en een testspecialist). De moderator verdeelt vooraf de te testen code en begeleidt de overige teamleden bij het zoeken naar fouten (het is in eerste instantie niet de bedoeling verbeteringen aan te dragen). Een eerste stap bij dit soort vergaderingen bestaat uit het toelichten, regel per regel, van de code en de onderliggende logica door de programmeur. Er is mogelijkheid tot vragenstellen aan de programmeur, die vaak zelf al een aantal onvolkomenheden ontwaart bij deze toelichting. Dan volgt de tweede stap: vanuit vorige sessies werd een lijst aangelegd met frequente programmeerfouten en die wordt nu overlopen en vergeleken met de geteste code. De moderator houdt bij welke fouten er gevonden werden, geeft de lijst aan de programmeur en deze zal dan trachten oplossingen uit te werken om ze nadien te implementeren. Indien er veel fouten gevonden werden wordt de procedure herhaald, want elke “correctie” kan op haar beurt aanleiding geven tot nieuwe fouten. Ook de lijst met frequente fouten kan eventueel vervolledigd worden.
•
Walkthroughs: deze techniek komt in grote lijnen overeen met de code inspection, maar het team gaat nu “computer spelen” in plaats van zich over elke regel code te buigen. Er wordt als het ware “door de code gewandeld” en hierbij worden enkele vooraf opgestelde testcases manueel uitgewerkt. Opnieuw houdt een moderator de mankementen bij en wordt er feedback gegeven naar volgende walkthrough sessies.
•
Desk Checking: dit is eigenlijk een “eenmanswalkthrough“, uitgevoerd door de programmeur. De methode is de minst efficiënte van de drie, omdat ze vooreerst het objectieve element van de vorige twee moet missen. Bovendien is de kans zeer groot dat de programmeur de lacunes die hij tijdens het programmeren niet zag ook niet tijdens het testen ziet. Niettemin blijft deze techniek verkieslijk boven helemaal niets doen.
•
Dynamic Testing: als het op functionaliteitstesten aankomt is de gebruikerssimulatie allicht de meest gebruikte dynamische testtechniek. De tester tracht zich in te leven in de gebruiker, maar zal ongetwijfeld problemen hebben om de manier van werken van de gebruiker te definiëren. Daarom is het aangewezen dat de gebruiker zijn manier van werken zelf definieert. Dit soort testen moet minimum in samenwerking met een gebruiker opgesteld worden. Eens de manier van werken en de testen gedefinieerd zijn is er wel ruimte om eventueel CAST (Computer Aided Software Testing) tools in te schakelen, altijd op voorwaarde dat de testresultaten nadien geanalyseerd kunnen worden.
•
Testing Aids: er zijn meerdere tools beschikbaar o logic coverage tools o program analysers o debuggers o test case generators
•
Test case selectietechnieken: een test is pas nuttig als hij nagaat wat men wil controleren. Het uitvoeren van de test is een eerder bescheiden werk in vergelijking met het bepalen van een relevante test case. Het belang van de hier gemaakte keuzes kan dan ook niet voldoende beklemtoond worden. De hoofdmetriek voor deze keuze is de “Test Coverage Reference”. Deze metriek stelt het aantal testcases voor die gedaan moeten worden om het “business risk-evenwicht” in relatie tot de geteste applicatie onder controle te krijgen. Hoe selecteert men nu de gepaste testcases? Een veelgemaakte fout is het vertrekken van de door de applicatie geboden functionaliteit en hierbij het uit het oog verliezen van de vereisten die door de gebruiker in het lastenboek geformuleerd werden 8. Als men als applicatie een adresboek heeft met als functionaliteit het creëren, wijzigen, verwijderen en consulteren van adressen, en men test deze functionaliteit louter vanuit het oogpunt van de functionaliteit, dan is het best mogelijk dat de applicatie toch aan haar doel voorbijschiet. Misschien is de toegang tot de applicatie enkel mogelijk via de naam van een persoon, daar waar de gebruiker ook zou moeten kunnen opzoeken via de woonplaats… De testen moeten telkens benaderd worden vanuit de vorige fase van het V-model. Als men voor het ontwerpen en programmeren een analyse maakt van de gebruikersvereisten, zou men simultaan de uit te voeren acceptance testen en testcases moeten ontwerpen. Vanuit deze initieel vooropgestelde testen zou het verdere testen in de ontwikkeling afgeleid moeten worden.
•
Test case designtechnieken: ook hier bestaan veel technieken, maar de goede bieden een antwoord op de vragen: waarom deze test, en waarom met deze testprocedure en deze testdata? Met andere woorden bestaat de kunst erin om met zo weinig mogelijk tijd, geld en middelen een subset testcases te ontwerpen die zoveel mogelijk van de vereiste functionaliteit dekken en de grootste kans bieden op het opsporen van een zo hoog mogelijk aantal fouten.
•
Resultaatvoorspelling: er werd reeds gezegd dat het bepalen van het resultaat alvorens de test te laten plaatsgrijpen een basisregel is in het testcasedesign. Er werd toen ook gezegd dat dit niet altijd evident is. Volgende methoden kunnen overwogen worden. o o
o
o
o 8
Gebruikersspecificaties: de specificaties van de gebruiker vormen de meest voor de hand liggende bron voor resultaatvoorspelling. Symbolische voorspelling: het resultaat kan ook voorspeld worden als we een mathematische formule kunnen bepalen die de relatie tussen input en output weergeeft. Kiddie testing: de amateuristische optie is niet direct een aanrader, maar kan mits de nodige discipline toch nuttig zijn. Als het bekomen resultaat van een test algemeen te rechtvaardigen valt, is de methode nuttig. De willekeur in dit type testen kan soms tot verbluffende resultaten leiden, maar het blijft een onproductieve handelswijze. Regressie testen: vaak is de aanleiding tot testen niet het ontwikkelen van compleet nieuwe software, maar het aanpassen of uitbreiden van reeds bestaande. De (test)resultaten bekomen met de vorige (operationele) versie kunnen dan als maatstaf gelden voor de nieuwe versie. Bestaande applicaties: het porteren van een applicatie van het ene platform (of besturingssysteem) naar een ander vergt ook nieuwe testen. De
Dit is een heikel punt bij de dagdagelijkse samenwerking tussen de verschillende IT-afdelingen binnen de Bank: dikwijls worden fouten gemeld die er geen zijn. Daaronder valt te verstaan: de gebruiker/tester vindt dat iets niet werkt zoals hij denkt dat het zou moeten werken, terwijl het wel degelijk geïmplementeerd is conform het lastenboek (waarin in wezen de verwachte werking beschreven wordt). Soms echter, worden hierdoor ook fouten of gebreken aan de lastenboeken geconstateerd.
vooropgestelde testresultaten kunnen dan, zoals in regressietesten geleverd worden door het reeds operationele platform (of systeem). Of een bepaalde applicatie kan –met kleine onderlinge verschillen- op meerdere platformen draaien. Eén platform kan dan vooropgesteld worden als de referentie voor de andere platformen.
Testdocumentatie Het documenteren van de testactiviteit is ook een belangrijk aspect in het hele testproces. Het V-model toont aan dat het testen eigenlijk opgedeeld kan worden in twee hoofdactiviteiten, namelijk het voorbereiden van testen en het uitvoeren ervan. Deze splitsing laat zich ook vertalen naar de testdocumentatie. Vooreerst vergt de voorbereiding een testfile of testdossier, waarin nauwgezet bijgehouden wordt wat en hoe we gaan testen. Later moeten deze richtlijnen uitgevoerd worden en de bevindingen hieromtrent komen dan in een testrapport. Het testdossier hoort een apart document te zijn, waarin men het testplan, de ontwerpspecificaties, de testprocedure, de testcasespecificatie, de testlogfile, de testgeschiedenis, het incidentenrapport en tot slot een eindsamenvatting terugvindt. Er bestaat een ANSI standaard die de testdocumentatie formeel bepaalt (ANSI/IEEE 829). Documenteren is één zaak, rapporteren is een andere. Het belang van een goed rapport mag dan ook niet onderschat worden. Dit rapport zal immers beslissen of een test geslaagd is of niet. Het rapport moet uiteindelijk ook een zicht geven op de efficiëntie en de productiviteit van het testproces.
Testmetrieken Als het rapport opgesteld is, moet het geanalyseerd kunnen worden. Dit gebeurt aan de hand van een aantal metrieken. Zij moeten toelaten om objectieve en gekwantificeerde bemerkingen te maken betreffende onze software en de kwaliteit ervan. Enkele voorbeelden van zulke metrieken zijn: • • • • • • • • • • • •
De omvang van de applicatie, het aantal lijnen code (LOC) het aantal schermen of formulieren het aantal fouten het aantal fouten per module of unit het percentage (niet) geslaagde testen het aantal fouten per tijdseenheid (MTBE, mean time between errors) dekking (statement, branch, decision, …) aantal testuren aantal uren testontwerp directe kost van een fout kost van de verbetering Test Coverage Reference
Het is voordien reeds gesteld dat er vooraf criteria moeten bepaald worden wanneer het testen gestopt wordt. Nadien moeten de metingen geanalyseerd worden om de mate van efficiëntie en productiviteit van de testen te bepalen. Vaak evolueert een testprocedure als volgt:
Testefficiëntie 50
Aantal fouten
40 Het testen stopt best op het snijpunt van de twee curves
30 20 10 0
Tijd Aantal fouten
Kost per fout
Grafiek die de fouten- en kostenevolutie bij een testprocedure aantoont
Wie gaat testen? Het slagen van een test hangt niet enkel af van een correcte methode of procedure, noch van de juiste keuze qua testdata. Het testen impliceert immers hoe dan ook een menselijke betrokkenheid. En de keuze van de tester is al even cruciaal als de voorgaande keuzes. Elk type test vergt een ander type tester, maar een steeds weerkerende vereiste is een “destructieve” ingesteldheid. Deze instelling wordt bij voorkeur niet botgevierd op een eigen creatie. Een ontwikkelaar (programmeur, analist of andere) kan wel begeleiden bij het testen, maar mag de test nooit zelf leiden. Een uitzondering dient hierbij wel gemaakt voor het debuggen, daar niemand de code beter kent dan de programmeur die ze geschreven heeft. Het werk hoort in teamverband te verlopen, waarbij ieder teamlid een welomlijnde rol en bijhorende verantwoordelijkheden krijgt toebedeeld. Testen vereist een aanzienlijke inspanning en investering: goed testen kost een niet te verwaarlozen aantal manuren. Tot slot moet iedereen die bij het testen betrokken is een zekere theoretische basiskennis hebben van wat testen is, tenminste als men het stadium van het vrijblijvende “uitproberen“ ooit wil overstijgen.
Welke types testen en hulpmiddelen bestaan er? Hoe worden ze in de praktijk gebracht? Tot zover de theorie, het wordt nu tijd de praktijk en haar methodes toe te lichten.
Functionaliteittest Dit type test heeft enerzijds tot doel de mate te bepalen waarin een applicatie voldoet aan de opgegeven vereisten en anderzijds te kijken of men voldoende vertrouwen in de applicatie kan hebben om ze in de “productie” in te schakelen. De functionaliteit wordt beoordeeld op haar correcte werking. De functionaliteittest vormt derhalve een belangrijke laatste stap naar het einde van een ontwikkelingsproject en bekleedt het leeuwenaandeel in de acceptance test.
Facility testing kan de functionaliteittest verder vervolledigen. Dit type test, ook smoke test genoemd verifieert of alle vereiste functionaliteit aanwezig is, zonder evenwel na te gaan of ze ook naar behoren werkt. Vaak echter worden de twee, functionaliteit en facility test als één geheel gezien.
Regressietest Een regressietest is een test die een nieuwe versie van een applicatie valideert en dit vertrekkende vanuit een bestaande versie van die applicatie. Stricto sensu verifieert deze test enkel de bestaande (vorige) functionaliteit, ze keert terug en controleert hierbij of er door de wijziging geen “terugval” is opgetreden in de functionaliteit, of alles nog correct werkt. In de praktijk echter omvat en regressietest zowel de bestaande als de toegevoegde functionaliteit van de nieuwe versie van de applicatie. Het testen van louter de nieuwe functionaliteit zou een functionaliteittest genoemd kunnen worden.
Stresstest Een stresstest stelt zich tot doel een applicatie, module of unit te testen onder zware belasting of onder stress. Dit is niet hetzelfde als een volumetest. Een stress-situatie houdt in dat op een korte tijd een grote hoeveelheid data verwerkt dient te worden. Het kan dus omschreven worden als een poging om het systeem te overbelasten.
Volumetest Deze test beoogt het controleren van de correcte verwerking van een grote hoeveelheid data, ongeacht de tijd die hiervoor nodig is. Dit type testen wordt vooral voor databanken en datawarehouses gebruikt. Ter vergelijking: het nagaan of een typiste 50 aanslagen per seconde kan halen is een stress test, controleren of ze een groot rapport kan tikken is een volumetest.
Bruikbaarheidtest Deze test gaat na of de geboden functionaliteit ook hanteerbaar is voor de gebruiker. Voorbeelden zijn: • is het inputscherm verstaanbaar voor de gebruiker? • is de output begrijpbaar? • bieden foutboodschappen een betekenisvolle info en eens te meer is het verstaanbaar? • zijn gegevens voldoende precies? • is de volgende stap/handeling duidelijk en/of toegankelijk?
Veiligheidstesten Veiligheidstesten vormen een klasse binnen de functionaliteittesten waarin de veiligheidsfuncties gecontroleerd en getest worden. Speciale aandacht gaat hierbij uit naar bepaalde functies die toegang verlenen tot gegevens (controlled, restricted, logged, …). Deze testen gaan ook na hoe een applicatie de gebruiker ervan tracht te weerhouden bepaalde fouten te begaan (in dit opzicht overlapt de veiligheidstest de bruikbaarheidstest). Het aspect toegangscontrole heeft met de internetboom van de voorbije jaren dan ook enorm aan belang gewonnen.
Performantietest Performantietesten situeren zich op zowel gebruikers- als systeemniveau. Bij het systeem worden bijvoorbeeld de toegangssnelheid tot de harde schijf of de throughput van een databus nagegaan. Op gebruikersniveau is dit doorgaans de responstijd van een functie of een applicatie.
Benchmarks Benchmarks zijn testen die trachten verschillende gelijkaardige applicaties of computeromgevingen met elkaar te vergelijken. Bij deze benchmarks wordt vooral beroep gedaan op allerhande performantietesten.
Overige types testen • • • • •
Instabiliteittest Betrouwbaarheidstest Disaster/Recoverytest Maintainability/Serviceabilitytest Documentatietest
Testplanning en management Het is al meerdere malen naar voren gekomen: testen moet aangevat worden bij het begin van een project. Daarom is het ook aangewezen dat de testactiviteiten ingepast worden in het globale projectplan en dat de middelen hiervoor formeel bepaald worden. Het plannen zelf laat een zekere keuzevrijheid tussen verscheidene methodes; de keuze hangt af van hoe het ontwikkelingsproces wordt gepland en geleid. Het spreekt voor zich dat de organisatie van het hele project voorafgaat aan de planning en de uitwerking van de deelprojecten. Een niet onbelangrijk deel van de testplanning is het identificeren van de benodigde testers.
Het uitvoeren van testcases Na het toelichten van een aantal mogelijke technieken voor het uitvoeren van testen volgen nu nog enkele items en opmerkingen die bij het testen best in acht genomen worden. •
Testomgeving: in de allereerste plaats is er de testomgeving. Een formeel gedefinieerde testomgeving is cruciaal voor deugdelijk testen. Elke tester moet kunnen beschikken over een duidelijk gedefinieerde testomgeving die eensluidend omschrijft over welke hard- en software hij kan beschikken en wat de beginsituatie is. De volgende zaken dienen hierbij in acht genomen te worden: o test databank en initialisatie o hard- en software-instellingen o datum en ogenblik van de test (tijdelijke of continue test, relatieve test?) o de gebruikte gebruikersnamen en paswoorden o grootte van de testdata o impact van vreemde middelengebruikers (m.a.w. andere applicaties) o afhankelijkheid (vanuit samenwerkingsoogpunt) van andere testers
o o o •
onafhankelijkheid van andere testers “sereniteit” van de testomgeving standaardisatie (!!!)
Keuze van testdata: ook dit is al eerder ter sprake gekomen. Het is toen duidelijk geworden dat niet alle mogelijke inputdata behandeld kan worden: goed testen vergt ook keuzes op dit vlak. Nochtans is er meer dan louter het zorgvuldige kiezen van testdata. Zo moet testdata, willekeurig gekozen of niet, zinvol zijn. Dit gevaar bestaat bijvoorbeeld bij het synthetisch genereren van testdata: “Aaaaaa Bbbbbb” kan bijvoorbeeld voldoen aan de vereiste “karakterinput”, maar het heeft geen betekenis als “naam”. Het is niet uitgesloten dat dit soort data-input een ander gedrag bij de applicatie veroorzaakt. Willekeurige input is dan ook een onderwerp op zich. Vaak leidt dit tot de paradox dat willekeurige input eigenlijk niet al te willekeurig mag zijn. Verder vergt economisch testen een zo klein mogelijke test databank.
Enkele mogelijke hulpmiddelen bij het testen: drivers en stubs Als men delen van een applicatie wil testen (bij module of unit testen) die samen moeten werken met andere applicaties of modules, kan men geconfronteerd worden met afhankelijkheids- en communicatieproblemen. Toch zijn dit soort testen essentieel als men bij het vaststellen van een fout precies wil achterhalen in welk deel van de code of waar in de applicatie deze fout zich situeert. Stel bijvoorbeeld dat een facturatieprogramma bij haar werking terugvalt op een andere module, een prijslijstmodule. Als het facturatieprogramma getest moet worden zonder de prijslijstmodule te beschouwen, zal er voor gezorgd moeten worden dat het facturatieprogramma toch op één of andere manier aan een lijst met invoerwaarden voor de benodigde prijzendata komt. Hiervoor kan een testscript aangemaakt worden dat de waarden van de prijslijst herneemt en zo in de vereiste inputdata voorziet. Dit soort scripts noemt men “drivers”. De driver moet het mogelijk maken dat het te testen programma loopt. Vaak kan (moet?) echter de vraag gesteld worden of het maken van een driver wel opweegt tegen het aanwenden van de module of applicatie die de driver juist moet vervangen. Het gebruik van een driver maakt het testen wel een stuk flexibeler, vermits er niet moet worden gewacht op de andere module of applicatie. Het laat ook toe de test compleet onafhankelijk van de andere module of applicatie uit te voeren, zodat men de te testen applicatie kan afschermen voor eventuele bijkomende invloeden van de opgeroepen module. Hetzelfde doet zich in complexere mate voor wanneer een geteste applicatie aangewezen is op een (externe) procedure die eerst een bepaald proces uitvoert en dan een resultaat moet teruggeven aan de oproepende applicatie, een resultaat dat essentieel is wil de te testen applicatie verder kunnen werken. Nemen we hier als voorbeeld een simulatieprogramma voor woonkredieten dat moet getest worden. Dit simulatieprogramma is afhankelijk van gangbare (en dus veranderlijke) rentetarieven en variabiliteitsformules, die door de uiteindelijke toepassing geconsulteerd worden in een tarievendatabank. Als men de applicatie wil testen zonder toegang tot deze externe procedure, houdt dit in dat de functionaliteit van deze procedure vervangen moet worden door een ander type testscript dat dan de tarieveninfo verschaft. Dit soort testscripts wordt een “stub” genoemd. Het maken van stubs is doorgaans nog complexer en arbeidsintensiever dan het maken van drivers, aangezien de output die hier gegenereerd wordt volledig afhankelijk is van de input. In de praktijk komt het construeren van stubs en drivers vaak erg dicht bij het maken van de functionaliteit zelf, en dit is zeker geen eenvoudige opgave. Tot slot is de aanmaak van een driver of een stub zelf ook niet meer of minder dan een softwareontwikkeling, die dus ook aan fouten onderhevig is en die dus in principe ook eerst zelf getest moet worden.
2. Het gebruik van testscenario’s binnen Fortis Bank 2.1. Situering van de scriptie binnen het IT-project van de Fortis Bank Het opzet van deze scriptie is een tool uit te werken die door uniformisering en automatisering het testen van de kantoorapplicatie Pacific kan vergemakkelijken. Deze kantoorapplicatie is in permanente evolutie, zeker nu ze aangepast wordt aan de computersystemen van de voorheen-GB 9 en -KN. Het testen betreft hier meerbepaald de integratietesten, die plaatsvinden alvorens de applicatie “in productie” gaat. Tot op heden is dit een weinig geautomatiseerde bezigheid, vaak omdat de baten van het automatiseren niet opwegen tegen de kosten. Derhalve wordt er vooral vertrouwd op het inzicht en de ervaring van de testequipe, die over een eigen testomgeving beschikt om haar activiteiten tot een goed einde te brengen. Aangezien testen systematisch dient te gebeuren, is het aangewezen bij te houden hoe er getest gaat worden en –voor eventueel later hergebruik- wat er getest geweest is (met eventueel aanvullend de bevindingen daaromtrent). Hiervoor gebruikt men scenario’s en de scriptie wil dus bijdragen tot een vereenvoudigd en eengemaakt opstellen van zulke scenario’s. Het is echter pas op het einde van de ontwikkeling dat het testen van de complete applicatie aan bod komt. Misschien is het dan ook beter eerst een meer globaal beeld van deze bancaire toepassing te schetsen en even stil te staan bij wat er aan het testen voorafgaat: Wat is de kantoorapplicatie Pacific eigenlijk en hoe is ze geconcipieerd? Hoe verloopt een transactie eens de applicatie er is? Wat zijn de stappen alvorens de applicatie effectief door het kantorennet gebruikt kan worden? Nadien zullen we dan dieper ingaan op de eigenlijke applicatiecode en hoe deze ons zal helpen bij het bereiken van onze doelstelling.
Pacific De kantoorapplicatie binnen de kantoren van de Fortis Bank luistert naar de naam Pacific (letterwoord voor Philips ASLK CGER Integrated Financial Insurance Computer system). Het gaat hierbij om een complexe applicatie die de gebruikers in de kantoren ondersteunt bij hun praktische en commerciële noden: online bankieren, complexe bancaire producten zoals leningen op afbetaling en verzekeringen, relatiebeheer en commerciële opvolging, enz. Ruggengraat van het systeem is een bibliotheek met programmamodules, geschreven in TFM (Task Flow Management, cf infra) die een continu en foutloos transactiesysteem met een mainframe (IMS) moet waarborgen. Verder voorziet het in features voor lokaal kasbeheer, auditing, elektronische post, foutherstel en beschikt het ook over een lokale databank (LDB, vooral voor het bijhouden van een elektronisch journaal en het opvolgen van cliënten en commerciële acties). Met de overname van de Generale Bank door Fortis Bank moest de Windows NT omgeving die binnen de GB bestond (BankStation, sedert 1998) aangepast worden aan de Candle Windows NT-omgeving, zoals die reeds een jaar eerder voor de ASLK/CGER ontworpen werd. Voordien bleef de GB-toepassing gekoppeld aan de GB-mainframe en de ASLKtoepassing aan de ASLK-mainframe. De bedoeling is bij de concrete eenmaking over te stappen naar één Fortis-kantoorapplicatie gekoppeld aan één Fortis-mainframe. Deze aanpassing verloopt in fases (“releases”)en moet op 17 september 2001, bij de Big Bang voltrokken zijn.
9
en weldra zal er ook een versie aangemaakt (en dus getest) moeten worden voor de Bank van de Post.
Het verloop van een transactie: werken in een drielagige clientserverarchitectuur Binnen het kantorennet wordt er met een drielagige client-serverarchitectuur gewerkt. De kritische financiële en persoonsinformatie wordt centraal en veilig beheerd op de mainframe, en dient dus niet in de minder beveiligde kantoorserver bewaard te worden.
Als drie lagen onderscheidt men dan: • • •
laag 1: een werkpost in het kantoor, die de interface naar de gebruiker toe vormt laag 2: de kantoorserver aan dewelke meerdere werkposten gekoppeld zijn laag 3: de centrale en beveiligde mainframe (eindverwerking en databank)
Werkpost Kantoorserver Netwerk
Mainframe
Afbeelding van de drielagige client-serverarchitectuur
Een bancaire transactie verloopt gebruikelijk volgens onderstaand stramien: • • • •
een gebruiker voert op zijn werkpost gegevens in die lokaal op de kantoorserver gevalideerd worden er wordt door de kantoorserver een boodschap aangemaakt die verstuurd zal worden naar de mainframe; op de mainframe zal de applicatie op deze boodschap inwerken het verzenden van de boodschap en het behandelen van het mainframe-antwoord lokale boekhouding (vb.: aanpassing van de agentschapskas na een geldopvraging) en afdruk van documenten (vb.: kasstukken, duplicata voor cliënten, …) ronden de transactie af
Het kan gebeuren dat bij meer complexe transacties de stappen 1 en 3 meerdere malen hernomen worden, naarmate de transactie vordert. Alle transacties die van het kantorennet naar de mainframe gaan worden door een transactiecode ingeleid. Deze code bestaat aan mainframezijde uit typisch 5 posities, met eerst 2 letters en dan 3 cijfers. Vaak is deze code dezelfde aan kantoorzijde, hoewel dit niet altijd (meer) zichtbaar is voor de gebruiker. Toch zullen ze van belang zijn in deze scriptie, want precies deze (letter)codes gaan ons op weg helpen bij het starten van een nieuw testscenario.
Ontwikkeling en planning De ontwikkeling van de Pacific–applicatie verloopt in stappen, releases genoemd, die op hun beurt uit een aantal fases bestaan. Aanvraag en Oplevering lastenboeken: het bekendmaken van de ontwikkelingsaanvraag, net als de grote lijnen van de ontwikkeling en het bepalen van de kalender voor het verdere verloop van de release. Deze kalender omvat: • • •
•
•
• • •
• •
Ontwikkelingsfase: men begint te ontwikkelen (lokaal en mainframe) en van zodra iets klaar is kan er getest worden op een testplatform Contents fixed: de inhoud van de release definitief vastgelegd; slechts bij uitzondering worden er nog wijzigingen aanvaard Development ended: de ontwikkelingen worden zowel lokaal als op mainframe stopgezet en de software wordt ter beschikking gesteld voor de pre-integratietesten. Bij het constateren van fouten worden enkel vastgestelde afwijkingen bijgestuurd; er vinden geen functionele wijzigingen meer plaats Pre-integration: alle applicatieve nieuwigheden en wijzigingen worden nu buiten de ontwikkelingsomgeving getest; de applicatie is nu beschikbaar op mainframe. Afwijkingen dienen zo vlug mogelijk bijgewerkt, wat goedgekeurd word krijgt een acceptatie van het testteam Freeze date: het einde van de applicatieve testen, de acceptaties dienen verstrekt te zijn. In ieder geval worden er geen wijzigingen meer toegestaan, tenzij er een blokkerende afwijking opduikt. Dit wordt dan in nog in één van de volgende fases opgelost. Delivery: de aanmaak van de kits wordt gestart (pakketten die de aparte, gewijzigde modules samenbrengen). Deze worden gelijk op de integratiemachines opgeladen (een installatie conform aan die die op de machines in productie zal draaien). Integration: controle of de release volledig en correct geïnstalleerd is. Er wordt nagegaan of de opgeleverde componenten technisch en applicatie correct (samen)werken Go Release / Go CD-ROM: start van de operationele fases, eventueel aanmaak van de CD-roms die over de kantoren verdeeld zullen worden (afhankelijk van de omvang van de release; kleinere releases kunnen via het netwerk verdeeld worden). Dit houdt in dat de “release technische” applicatie op punt staat en dat er zeker geen blokkerende afwijkingen meer zijn Black Phase – IMS operational: controle op de technische installatie en een grondige Sanity Check Red Phase – Pilot Branches: een zeer beperkt aantal kantoren (4 voorheen GB- en 20 voorheen ASLK/CGER-kantoren) implementeert als eerste de nieuwe release. De goede werking wordt door testmedewerkers ter plaatse nagegaan, o.a. op basis van een checklist. In extremis kan hier nog een blokkerende afwijking gemeld en opgelost worden
• • •
Orange Phase: een 40-tal voorheen GB-kantoren en alle voorheen ASLK/CGERkantoren gebruiken nu de release Green Phase: operationeel in alle kantoren End distribution: alle kantoren dienen nu te beschikken over de nieuwe en gewijzigde functionaliteiten
Patch: uitzonderlijk kunnen na de groene fase nog kleine bijsturingen verspreid worden over het kantorennet en dit via het netwerk door middel van een patch
Dat is de hele levenscyclus van een release. Laten we nu dieper ingaan op de opdracht zoals ze door de medewerkers van de Fortis Bank werd geformuleerd.
2.2. De gangbare testpraktijk binnen het departement Integratie en het gebruik van testscenario’s Er wordt uiteraard door verschillende mensen en op verschillende momenten en niveau’s getest bij het uitbouwen van de Pacific-applicatie. Het onderdeel van de ontwikkelings- en testprocedures waar deze scriptie verband mee houdt valt te situeren even voor de release, bij het testen van de applicatie op een gesimuleerd kantoorniveau. Het gaat om de zogenaamde integratietesten, waarin de applicatie gebruikt wordt zoals ze door de eindgebruiker zou gebruikt kunnen worden. De testploeg baseert zich op de lastenboeken, analysedocumenten, scenario’s en testdata. In het geval er analysedocumenten gebruikt worden, gaat het om dezelfde documenten die ook de programmeurs in handen krijgen vóór het schrijven van de TFM-code. De gebruikte testscenario’s worden door de integratoren zelf opgesteld (in Word of Excel). Het bepalen van de testdata kan ofwel door ze zelf te genereren of door ze te onttrekken aan de mainframe-databank. Hierbij wordt door het departement integratie niet enkel nagegaan of de applicatie de data juist verwerkt, maar ook gecontroleerd of er geen conflicten rijzen met de randapparaten, of documentafdrukken correct plaatsvinden, etc. Indien een toepassing niet voldoet aan de vooropgestelde eisen of wanneer er (uitzonderlijk) een klacht binnenkomt van een kantoor betreffende een reeds operationele versie van de applicatiesoftware maakt het integratieteam een “incident” aan. Dit is een officieel verslag waarin het euvel beschreven wordt alvorens het terug naar de ontwikkelaars kan. In bepaalde gevallen verloopt het uitvoeren van de testen geautomatiseerd, met behulp van de testingtool WinRunner® (een product van Mercury Interactive), maar dit is sterk afhankelijk van de te testen verrichting en van de haalbaarheid (rendabiliteit!) om hiervoor een apart testscript aan te maken. Vaak wordt WinRunner veeleer gebruikt bij regressietesten dan bij integratietesten. Deze geautomatiseerde testen kunnen net als de andere testen niet los gezien worden van een scenario: men moet bij het testen immers weten wat men gaat testen, hoe men dit gaat doen en wat de te verwachten resultaten zijn. Er bestaan evenwel verschillende types testscenario’s, dus komt het erop aan te weten wanneer welk type wordt gebruikt. In essentie kan men twee types testscenario’s onderscheiden: enerzijds zijn er scenario’s die zich louter toeleggen op het verloop van de verrichting, of anders gezegd op de manier waarop de schermen van een bepaalde verrichting mekaar dienen op te volgen. Hiervoor baseren de integratoren zich op de lastenboeken. Voor het aanmaken van dit type tests is Word veruit het meest aangewezen.
Anderzijds zijn er de scenario’s die veeleer de concrete werking van een verrichting dienen te peilen. In dit geval moet de integrator zich vooral toeleggen op het genereren van plausibele en foutenrevelerende testcases, door een pertinente selectie testdata aan te maken (of in te voeren) en die dan op de te testen verrichting los te laten.
2.3. Scenario in Word, Excel of in een andere tool? Bij het communiceren van de opdracht door het departement Integratie werd er vooropgesteld dat de tool in een reeds bekend bestandsformaat (Word, Excel) kon aangemaakt worden, maar dat dit geen vereiste was. Al vlug is gebleken dat het zoeken naar een mogelijke ander formaat of tool weinig zin had: de complexiteit en de beperkte werkbaarheid van een mogelijk ander pakket (extra investering in een aantal licenties, opleiding, …) hypothekeerden reeds vroeg deze piste. De integratoren zijn daarentegen vertrouwd met Word en Excel, dus diende er veeleer een keuze tussen deze twee gemaakt. Het is vanuit de testoptiek dan ook vooral belangrijk om de voor- en nadelen van beide pakketten tegen elkaar af te wegen. Excel
Pro
Contra
Mogelijkheid tot (test)datavalidatie, als dit Het scherm dreigt erg onoverzichtelijk te nuttig en haalbaar mocht blijken (dit kan worden als er veel mogelijke invoervelden in namelijk erg complex worden…) de verrichting voorkomen De meer overzichtelijke keuze wanneer er Tekstonvriendelijk, maar de gevallen waar bij vooral met invoervelden en cijfers moet een verrichting commentaarvelden gewerkt worden voorkomen zijn erg beperkt en dan nog is de commentaar niet of nauwelijks van belang Te combineren met WinRunner® voor het technisch functioneren van de applicatie Mogelijkheid tot systematische toevoeging van commentaarvak of -kolom om Commentaar is evenwel niet altijd nodig en bemerkingen integrator te rapporteren belemmert samenwerking met WinRunner®
Word
Pro
Contra
Tekstvriendelijk, dus meer aangewezen bij Geen voor de hand liggende mogelijkheid tot beschrijvende testscenario’s, waar tekst en (test)datavalidatie uitleg betreffende de te testen verrichting de essentie uitmaken Niet echt compatibel met WinRunner® Vaak meer overzichtelijk door ontbreken van een opgelegde celstructuur zoals in Excel Problemen te verwachten bij andere Er zou met velden kunnen gewerkt worden automatiseringspogingen
Dit alles in acht genomen viel de keuze al snel op Excel, zeker door de mogelijkheid om de functie op termijn te combineren met WinRunner®. Hiervoor zal men dan wel rekening dienen te houden met bepaalde conventies qua font, kleur in kolomhoofden en volgorde van de verrichtingen (eerst opslaan alvorens de macro aan te roepen, eerst enkele constanten en variabelen aanpassen in de macro…).
2.4. Automatisering binnen testscenario’s Bij het uitvoeren van testen: WinRunner® Momenteel wordt er door het departement Integratie gebruik gemaakt van een automatische testing tool: WinRunner®, en meerbepaald Version 4.0. Deze tool, ontworpen door Mercury Interactive is in staat om automatische testprocedures te laten lopen binnen applicaties die onder MS Windows draaien. In Version 4.0 bestaat de keuze tussen een contextgevoelige en een analoge testmode. De contextgevoelige mode maakt een opname van de tester zijn handelingen in de te testen applicatie en registreert hierbij de door de tester geselecteerde GUI-objecten (zoals vensters, lijsten, knoppen, …), onafhankelijk van de positie van deze GUI-objecten op het scherm. Elke handeling wordt omgezet naar een TSL-expressie (Test Script Langage), die zowel het GUI-object als de uitgevoerde handeling beschrijft. Bij het testen wordt deze opname gewoon opnieuw afgespeeld, eventueel aangevuld met extra of aangepaste testdata (uiteraard kan ook toetsenbordinvoer hierbij opgenomen en weergegeven worden). De analoge mode is de meer eenvoudige evenknie van de contextgevoelige en registreert muisclicks en toetsenbordinvoer, zoals ze zich bij het opnemen op precieze plaatsen voordeden. Op deze manier simuleert WinRunner® -meestal in combinatie met een extern programma of script- een onvermoeibare menselijke gebruiker. Binnen het departement wordt WinRunner® voornamelijk gebruikt in analoge mode, in combinatie met Excel testscenario’s. Hiervoor werd reeds een Excelsjabloon aangemaakt voorzien van twee macro’s: een eerste macro onttrekt de celinhouden per testcase aan het Excel Workbook om ze dan in een sequentieel bestand onder te brengen. De tweede macro zet dit sequentieel bestand dan om in een voor WinRunner® leesbaar script (in TSL, Test Script Langage). Beide macro’s dienen per testscenario op enkele punten 10 aangepast, alvorens ze met succes kunnen opgeroepen worden. Dankzij een aantal conventies qua naamgeving, kleur en font slaagt de eerste macro erin een sequentieel aan te maken, maar het is uiteraard aan de integrator om de kolommen binnen het sjabloon juist aan te maken (kolomhoofden bepalen het type invoer hier, de rijen stellen telkens een testcase voor). Zo moet de integrator vooral aandacht besteden aan de volgorde waarin de invoer hoort te geschieden en de benamingen van de kolomhoofden. Kortom, de opmaak is een flinke manuele opdracht, maar ze kan zeker lonend zijn. Dit is vooral het geval bij regressietesten, waarbij men over de bestaande scenario’s kan beschikken, eventueel mits enkele aanpassingen. Er dient hierbij wel opgemerkt dat WinRunner® zich het handigst met Excel laat gebruiken wanneer men verrichtingen test die een sequentieel verloop kennen. De tool werd dan ook in de tweede helft van de jaren ’90 door de voorheen-GB aangekocht om de AT/TA-applicatie 11 te testen, die enkel sequentieel 10
Zo moet men het aantal testcases en gebruikte kolommen opgeven, net als de naam en codenummer van de geteste verrichting 11
AT/TA: agentschapsterminal/terminal agence
verliep. Toen de AT/TA in 1978 operationeel werd, waren GUI’s, dialogboxes en option buttons nog niet aan de orde… Er schuilt dan ook een grote uitdaging in het verzoenen van de dynamiek van de recent ontwikkelde applicaties en de gangbare testtechnieken en –middelen.
Bij de opmaak van een testscenario in Excel: Tacos (TFM application code object scanner) Toen duidelijk werd dat de essentie van deze scriptie rond automatisering zou draaien stelde zich het probleem wat er buiten het geautomatiseerd uitvoeren van testen nog verder geautomatiseerd kon worden, en wat niet. Want reeds vroeg dienden een aantal praktische bezwaren en beperkingen in overweging genomen te worden: •
•
De enorme dynamiek van Pacific is helemaal iets anders dan het sequentiële karakter van BankStation AT/TA: ze kan ook niet voorzien of beïnvloed worden via de parameters zoals dit voor bepaalde dynamische elementen in BankStation (0punt-databank die herinitialiseerbaar was) wél kon. Veel details (al is het maar een dom saldo) in IMS veranderen direct/te vlug zodat men constant de scripts 12 moet aanpassen in geval van automatisch testen (en dus ook bij regressietesten die zich op reeds eerder gebruikte testdata baseren). Als men dit niet doet werkt het niet of moet men de testgegevens dermate ruw gaan nemen dat het eigenlijk niet meer voor een test kan doorgaan. Een andere optie is constant werken met fictieve data, maar dit impliceert dan weer dat men per definitie nooit realistische situaties test.
Het geautomatiseerd uitvoeren van testen binnen de Pacific-omgeving blijkt dus (voorlopig) minder voor de hand te liggen. Dit in het achterhoofd rees de gedachte dat ook het automatiseren van de data-invoer de processen kan helpen versnellen. Bovendien zou het kunnen bijdragen tot een reductie van het aantal fouten in de testscenario’s, als we er tenminste kunnen van uitgaan dat de programmacode waar we ons op baseren óók foutloos is. Dit is misschien iets te ambitieus, maar feit is wel dat een efficiënte semi-automatische data-invoer tijdsbesparend en uniformiserend is. Helaas is het bijzonder complex en arbeidsintensief om dit deel van het testen geautomatiseerd te krijgen. Het gaat immers niet om het omzetten van de code in een ander formaat, maar om het doorlopen en selecteren van bepaalde delen uit de code, delen die elk dan nog in aparte bestanden vervat zitten.
TFM-structuur en architectuur TFM: dit is de tool waarmee de Pacific-applicatie ontwikkeld werd en wordt. TFM staat voor Task Flow Management (voorheen verdeeld door Philips, nu door Compaq) en werd ontworpen voor taak- en transactiegeoriënteerde programma’s. Deze ietwat exotische taal wordt in België enkel door de Bank Brussel Lambert (ondertussen niet meer) en door Fortis Bank gebruikt. De code wordt opgeslagen als een aantal objecten die at runtime opgeroepen 12
Bovendien moet er momenteel nog voor de drie aparte systemen getest worden. De eengemaakte Fortis is pas voor na the Big Bang (17/09/2001). Dan zou het opstellen van complexere scripts al wat rendabeler kunnen zijn (vb. voorbereiding komst Euro).
en geïnterpreteerd worden. De benaming van deze objecten bestaat doorgaans uit een 5karakter-code (2 letters, 3 cijfers) waarover reeds gesproken werd op p.21. De objecten zijn normaalgezien niet leesbaar, maar kunnen wel in ascii omgezet worden. Het begin van ons werk zal dus bestaan uit het omzetten van de TFM-code naar ASCII-code, om deze dan verder te ontleden. De objectbestanden die overlopen worden situeren zich in principe op 2 niveau’s: op een eerste niveau is er het dialoogmodel en hieraan zijn dan –op een tweede niveau- de datasecties gekoppeld. De dialoogmodellen kunnen gezien worden als het skelet van een applicatie, de datasecties als een middel tot het concrete gebruik ervan. Vanuit de structuur van het dialoogmodel worden immers de datasecties aangeroepen, onder meer bij het vragen naar gebruikersinvoer of bij het aansturen van randapparaten. Zo ontstaat een hele bibliotheek van datasecties 13, waar de verschillende dialoogmodellen dan beroep op kunnen doen. Op die manier wordt redundantie binnen het geheel van de applicatiecode (dialoogmodellen en datasecties) tegengewerkt en het biedt het voordeel dat ook de nationale taalproblematiek (althans op applicatieniveau) kan worden aangepakt. Vermits het eigenlijke contact met de gebruiker beperkt blijft tot de datasecties, dienen enkel deze in twee versies aangemaakt te worden: een Nederlandstalige en een Franstalige, respectievelijk gekenmerkt door een aanvullende N of F op het einde van de datasectiefilenaam (vb.: …_N en …_F). Meer in detail bestaat de ASCII-versie van de applicatiecode uit een aantal tags. Deze tags (met cijfer- en lettercodes; gelijkend op HTML) worden gebruikt om een bepaalde functionaliteit binnen de TFM-code aan te duiden. Een complete toelichting hierover zal de lezer in deze scriptie niet vinden, want die zou niet al te relevant zijn voor het vervolg ervan. De essentie voor de functionaliteit die we willen uitbouwen zit in: 1)
het pad naar het juiste dialoogmodel (bvb.: D:\S71M0101\dvlVSS\wsm\naam_van_het_dialoogmodel.ADM => hierin zijn de ASCII-files van zowel de dialoogmodellen als de van het dialoogmodel afhangende datasecties terug te vinden)
2)
de tags die het begin en einde van de datasecties in de dialoogmodellen aanduiden en het terugvinden van het pad naar de datasectiefiles (d.i. wat een invoerveld wordt, eens op het scherm in de verrichting)
3)
de tags die de voor ons interessante velden (labels) in de datasecties inleiden en afsluiten
De onderstaande figuur toont de grafische variant van een (eenvoudig) dialoogmodel. Tussen de accolades vindt men de elkaar opvolgende datasectie-oproepen (8 in totaal, telkens voorgesteld door een rode D in een vierkantje). Onder Step-ID vindt men de naam van de respectievelijke datasectie-bestanden.
13
Sommige datasecties, zoals bijvoorbeeld de datasecties met betrekking tot het identificeren van een cliënt, duiken in meerdere applicaties op en worden dus door meerdere dialoogmodellen aangesproken.
Afbeelding van een TFM-dialoogmodel
We gaan ons bij het scannen van de TFM-code dus niet baseren op de invoervelden als dusdanig, maar op de “labels” die de invoervelden in de datasecties voorafgaan. Het zijn immers deze “labels” die de gebruiker erop attenderen welke input er verstrekt dient te worden (t.t.z. woordelijke lay-out van het invoerscherm in de verrichting). Een voorbeeld van zo’n invoerscherm kan men terugvinden in de annex. Als deze labels verzameld zijn kunnen we overgaan naar de tweede stap: de omschrijvende labels worden nu overgebracht naar een Excelsheet, alwaar ze in de linkerkolom (vanaf cel A2) zullen aangeven welk type testdata de integrator zal moeten invoeren bij het testen van de verrichting. De daaropvolgende kolommen (B, C, D, …) moeten dan van boven naar onder met de gepaste testdata aangevuld worden en gelden dan telkens als een aparte testcase. De cellen in rij 1 worden gereserveerd voor de testcasenummering. Hoe gaat dit nu in zijn werk voor de VB-code die we gaan schrijven, waar baseren we ons op? Het kan misschien bizar lijken de invoervelden te zoeken als we voor het testsheet eigenlijk de labels nodig hebben. We zullen direct zien dat dit zijn redenen heeft. Inleidende tag voor een invoerveld is \9c, die voor een label is \00 of \80. Er zijn evenwel statische en dynamische velden, met respectievelijk een reeds vooraf ingevuld veld en een in te vullen veld. Het zijn enkel de labels die de dynamische velden voorafgaan die we wensen te extraheren (de statische, vooraf ingevulde velden zijn van geen belang bij het testen dat zich enkel op de dynamische velden zal toespitsen. Ze worden dan ook niet weerhouden voor het scenario). Om de juiste informatie terug te vinden moeten we dus een combinatie in de code zoeken van een inleidende \00 of \80 labeltag en een daaropvolgende \9 dynamisch veldtag. De
stukjes tekst die zich hier tussen bevinden kunnen dan via “tussenbestanden” in Word 14 opgespoord worden, om nadien geïmporteerd te worden in een Excelsheet. Binnen een dialoogmodel staan volgende tags voor:
het openen van een dialoogmodel het openen van een datasectie oproep van een datasectie of van een dialoogmodel op een lager niveau de object directory de filename binnen de object directory het einde van het hoger geopende dialoogmodel () of van de hoger geopende datasectie (), al naargelang
Binnen een datasectie kan men volgende tags aantreffen: \00 en \80 kondigen een label aan \9c leidt een invulveld in, (dus een dynamisch veld) en is als dusdanig ook het einde van het hieraan voorafgaand label
Proof of concept en code in Visual Basic 6.0 Met deze wetenschap was de eerste stap het maken van een proof of concept, een poging om binnen een eenvoudige verrichting de dialoogmodellen en de datasecties te scannen. Toen bleek dat dit mogelijk was, werd de code stelselmatig verder uitgebreid. Eerst met de aanmaak van het Excelsheet. Nadien werd de opmaak van het Excelsheet uitgewerkt (opsplitsing in 2 Worksheets volgens taal, aanpassen kolombreedte, inbouwen testdatavalidatie). In een laatste fase werd de interface naar de gebruiker aangepakt (meer verzorgd beginscherm en aanmaak toolbar) Waarom Visual Basic 6.0? Daar er met twee Microsoft pakketten (Word en Excel) ging samengewerkt worden lag de keuze voor Visual Basic nogal voor de hand. De code van “Tacos” (TFM application code object scanner; de lezer heeft ondertussen al gemerkt dat Fortis IT een zwak heeft voor letterwoorden…) werd dan ook in VB 6.0 aangemaakt, teneinde het risico op conflicten te beperken. Een andere, niet onbelangrijke reden was dat VB 5.0 of 6.0 (in tegenstelling tot bijvoorbeeld Java) op de meeste toestellen van het Fortis IT-departement geïnstalleerd was.
Toelichting bij de code Het hoofdprogramma, Private Sub Open_Click gaat in de eerste plaats op zoek naar het te analyseren dialoogmodel. Dit laat zich herkennen aan de extensie *.adm. Het bestaan van het dialoogmodelbestand is een nogal evidente, gestelde vereiste. Het bestandsformaat wordt meteen opgegeven in de directory waarin een dialoogmodel kan geselecteerd worden. Het verloop van het programma kan onderbroken door op de “cancel”-knop te klikken en terwijl het programma loopt verschijnt een zandlopertje op het scherm. De naam van het dialoogmodel (en dus ook die van de te testen verrichting) wordt bekomen door de bestandsnaam die de gebruiker in het beginscherm aanklikte te ontdoen van de 4 laatste
14
het ASCII-formaat wordt in Word geopend waarbij “gezocht” en “vervangen” wordt tot alle door ons gezochte elementen in een in VB aangemaakte array zitten
karakters (een “.” en de extensie “adm”). Dan wordt het linkerdeel van de bestandsnaam verwijderd tot na de “\”. Op het scherm verschijnt dan welk dialoogmodelbestand er momenteel een analyse ondergaat. Nadien wordt het pad voor de datasecties in het dialoogmodel bepaald, door het pad van het dialoogmodel (ComDial.FileName) positie na positie in te korten tot een “\” tegengekomen wordt. De directory waar de datasectie zich in bevindt is dan dit pad zonder de eind-backslash. Vervolgens worden achtereenvolgens twee subs aangeroepen om eerst de datasecties uit het dialoogmodel te halen (Private Sub GetDataSecties) en die op hun beurt te controleren op de aanwezigheid van invoerveldlabels (Private Sub GetFields). Tot slot worden de Word-hulpbestanden afgesloten, zonder ze te bewaren. Aanmaak Excelsheet en opdeling over het Nederlandstalige en Franstalige Worksheet In het Excel testscenario worden door Tacos twee werkbladen aangemaakt: één voor de Nederlandstalige en één voor de Franstalige invoerveldlabels. Deze bladen krijgen netjes hun naam op de tab door er een deel van de dialoogbestandsnaam (variabele “dm” vanuit het hoofdprogramma) aan toe te voegen, aangevuld met respectievelijk NL en FR. Hiervoor werd een teller (variabele “tel2”) bijgehouden, die in de array met gevonden invoerveldlabels het aantal elementen registreert. Als de applicatiecode met de nodige precisie geschreven is, moet het aantal labels voor beide landstalen gelijk zijn. We kunnen er dan van uitgaan dat bij het sequentieel doorlopen van de datasecties (eerst alle Nederlandstalige, dan alle Frantalige) de tweede helft (hier wordt “tel2” gelijkgesteld aan “Frans”) van de gevonden labels de labels in de Franse taal zullen zijn. Op deze manier wordt de array labels over de A-kolommen van de twee werkbladen verdeeld. Cel A1 wordt in beide bladen vooraf ingevuld met “Test Nr.” voor het Nederlandstalige blad en “Test N°” voor het Franstalige. In deze eerste rij dient de integrator sowieso het nummer van de testcase in te voeren. Laatste extraatje hierbij is dat de kolombreedte van kolom A op minimumbreedte 36 ingesteld wordt. Indien een label nog groter zou zijn, volgt de hele eerste kolom die breedte. Analyse dialoogmodellen Private Sub GetDataSecties gaat op zoek naar datasecties, andere dialoogmodellen en dialogboxes door zich respectievelijk op de tagcodes , en te baseren. Hiervan wordt eerst de tag “ en tags, die respectievelijk de naam van het object (datasectie, …) specificeren en naar de directory verwijzen. De inhoud van zal verder ondergebracht worden in de stringvariabele “dial” (in het geval van een dialogbox komt hier nog de extensie “.adx” bij), vooraan aangevuld met de stringvariabele “dir” en een “\”, om zo tot een padnaam te komen. Deze kan dan opgeslagen worden in de array DataSecties, die bij bepaalt welke datasecties of dialogboxes er in een volgend stadium dienen ontleed te worden; teller tel1 houdt bij op welke positie in de array we zitten. Als de hier bekomen directory evenwel overeenkomt met de initiële directory “startdir”, dan hebben we te maken met een genest dialoogmodel, en moet eerst dit dialoogmodel doorlopen worden, alvorens men verdere datsecties kan opzoeken. Het scherm duidt dan ook aan dat er opnieuw een dialoogmodel bestudeerd wordt. Hierna wordt het ontlede dialoogmodel gesloten. Analyse datasecties Private Sub GetFields gaat met behulp van de padnaam pad op zoek naar het juiste pad om de respectievelijke Nederlandse of Franse datasectie te openen (concatenatie van _N of _F aan de stringvariabele “pad” nadat hij ingekort werd). Via de extensie wordt er een
onderscheid gemaakt tussen de dialogboxes en de “gewone” sequentiële datasecties die hier verder geanalyseerd worden; de dialogboxes worden in Private Sub dialogboxes behandeld. Dan bepaalt men de variabele ds, hetzij door de concatenatie van van de strings “pad” en het rechterdeel van de datasectie vanaf de positie bekomen door het verschil van de lengte van deze datasectie en de variabele “posi”. Hetzij door “path” en de datasectie op de i-de positie te concateneren. “ds” vormt na het toevoegen ven de extensie “.ads” het complete pad naar een datasectiebestand en dat kan nu ontleed worden. In het venster van de applicatie verschijnt alweer welk bestand er geanalyseerd wordt, dit door het uitvoeren van een aantal zoek- en vervangopdrachten. De resultaten hiervan worden beperkt tot de loutere invoerveldlabeltekst en zullen vervolgens toegevoegd worden aan de array Fields, de teller “tel2” houdt bij hoeveel elementen er zich in deze array bevinden. Op het einde sluit men het Word tussenbestand. Analyse van de dialogboxes Private Sub dialogboxes behandelt de dialogboxes. Deze zitten eerst in de array DataSecties, maar worden in Private Sub GetFields doorgegeven aan dit stuk code, met hun plaats in de array en een taalcode. Ook hier wordt via het beginscherm aan de gebruiker gemeld welk deel van de TFM-code nu doorlopen wordt, terwijl de zoek- en vervangopdrachten plaatsvinden. Er wordt een lijst ”lijst” aangemaakt met de verschillende dialogboxcontrols, waarbij de tags door komma’s vervangen worden. Als deze lijst niet leeg is gaat men op zoek naar de aan de dialogbox gelinkte algemene en taalspecifieke elementen (via de padnaam die voortvloeit uit de concatenatie van de stringvariabelen “path”, “startdir”, een “_”, “lang”, een “\”, de twee linkse posities uit “startdir” en de vermelding van de extensie “lab.afd”). Zowel de specifieke als de algemene vertaalbuffer worden doorlopen en aangepast met enkele zoek- en vervangopdrachten. Ons baserend op de komma’s gaan we de string “lijst” van links naar rechts doorlopen, de velden “fld” opzoeken en de lijst telkens inkorten door het geëxtraheerde element te verwijderen. Voor de verschillende mogelijkheden (option button, label, frame of checbox) wordt dan naar de adequate vertaling van de veldnaam gezocht (in geval specifieke buffer), anders (algemene buffer) wordt de veldnaam zo overgenomen. Beide uiteraard weer na het nodige zoek- en vervangwerk. De velden worden dan, net zoals de gewone datasectie-veldnamen weggeschreven in de array Fields; de teller tel2 houdt het aantal posities bij. De hulpbestanden worden gesloten Beginscherm van de applicatie Het beginscherm van de applicatie blijft tijdens het hele programma zichtbaar en meldt wat er op een bepaald ogenblik juist gecontroleerd of aangemaakt wordt (dialoogmodel, datasectie, excelsheet, …). Dit staat onder de Private Sub Form_Load En zo wordt dan vanuit de TFM-directory via Word tussenbestanden een Workbook in Excel gegenereerd, met meteen een Worksheet in het Nederlands en één in het Frans. Het verwijderen van het derde sheet vormde een probleem bij het automatiseren, omdat dit nog eens extra bevestigd diende te worden in een pop-up-venster. De blijvende aanwezigheid van het derde sheet was niet storend genoeg om er extra code voor te schrijven.
Afbeelding van een Excelsheet, resulterend uit een scan door Tacos
Bij het aanmaken van het Excelsheet worden er bovendien twee in het scenario in te voeren types data gevalideerd: rekening- en chequenummers. De validatie hiervan mag echter enkel een controle zijn (dus zeker niet blokkerend!), die nagaat of er door de integrator al dan niet moedwillig een fout begaan wordt. Als de validatie een blokkerend effect zou hebben, kan men de reactie van de geteste verrichting op foutieve invoer niet meer controleren, en dit kan uiteraard de bedoeling niet zijn. Er werd dan ook geopteerd voor een “informatieboodschap” bij het invullen van de cel en het rood kleuren van de font in de actieve kolom bij een foutieve invoer. De integrator wordt dus sowieso eerst geattendeerd op de foutieve invoer en heeft dan de vrijheid om dit te behouden of te verbeteren. Later, bij de test wordt meteen duidelijk welke testcase (die uiteraard melding maakt van een rekening- of chequenummer) dient te falen of niet. Vooreerst werd er in het Excelsheet een controle voorzien op de in te brengen rekeningnummers. Om dit te doen werd er gezocht naar de substring “REK”, na eerst de tekst in de cellen van de eerste kolom omgezet te hebben naar hoofdletters. Het komt immers net zo goed voor dat een label “rekeningnummer” als eerste woord (dus met hoofdletter) vermeld, als op een andere positie, verder in het label (en bijgevolg met kleine letter). De validatie moest dan doorgevoerd worden naar de overige kolommen (van de rij zijn we uiteraard zeker). Tevens werd er een formaat voor de in te voeren rekeningnummers ingesteld, namelijk 3 blokken van respectievelijk 3, 7 en 2 cijfers, telkens gescheiden door een koppelteken (vb.: 000-0000000-00).
De formule om te bepalen of een rekeningnummer 15 een correcte structuur heeft Een Belgisch rekeningnummer bestaat uit 12 cijfers, meestal voorgesteld in een blok van 3 cijfers, gevolgd door een blok van 10 cijfers en afgesloten door een blok van 2 cijfers, de check-digit. hoe berekent men nu deze check-digit? Men neme de eerste 10 cijfers van het rekeningnummer en berekent hiervan de modulo 97. Deze dient overeen te stemmen met de 2 laatste cijfers van het rekeningnummer. voorbeeld: het rekeningnummer 293-0000463-33 stap 1: 2930000463 en 33 (als check-digit) van elkaar afzonderen stap 2: 2930000463 modulo 97 = 33 stap 3: modulo 97 van het rekeningnummer is gelijk aan de check-digit; het rekeningnummer is valabel Verder werd er ook een controle op chequenummers voorzien, die mutatis mutandis behoorlijk gelijklopend is met de rekeningnummervalidatie. Uiteraard wordt er op een andere substring gezocht en hier is er geen formaataanpassing. De formule om te bepalen of een chequenummer 16 een correcte structuur heeft Een gewoon Belgisch chequenummer bestaat uit 6 cijfers. Om te controleren of het een valabel chequenummer is (zelfde chequenummer kan toegewezen worden aan cheques getrokken op verschillende rekeningnummers) scheidt men de laatste 5 cijfers van het eerste af. Men trekt het eerste cijfer af van het getal gevormd door de laatste 5 cijfers en berekent dan de modulo 7. Dit zou in 0 moeten resulteren. voorbeeld: het chequenummer 310034 stap 1: afzonderen 3 van 10034 stap 2: 10034 – 3 = 10031 stap 3: 10031 modulo 7 = 0 stap 4: de modulo 7 van het verschil van de laatste 5 cijfers en het eerste cijfer is 0; het chequenummer is valabel
15
Eerlijkheidshalve dient er wel melding gemaakt te worden van de beperkingen van de validatie: deze getalstructuur wordt immers erg frequent gebruikt voor de meest uiteenlopende doeleinden. Alleen al binnen de Bank wordt deze structuur gebruikt voor het toekennen van nummers aan bepaalde contracten (kredietopeningen, allerhande polisnummers, … met een conventie voor het eerste blok van 3 cijfers). Vergeten we niet dat de structuur uiteraard ook door de andere Belgische banken gebruikt wordt. En verder hebben ook gestructureerde mededelingen (bij overschrijvingen), ID-kaarten, enz…deze vorm. Kortom, de bewuste validatie kan ongetwijfeld nog verder verfijnd worden (maar de formule ook gerecycleerd…). 16
Ook hier enige restricties: er bestaan verschillende types cheques, en de nummering is zeker niet eengemaakt! Bankcheques (van sommige banken), circulaire cheques, buitenlandse cheques, reischeques,…houden er elk hun eigen systeem op na. Het gaat hier dus enkel om de Belgische EC, gewone en zakencheque, die in de kantoren ook de meest courante is.
2.5. Het Excel testscenario en toelichting De oorspronkelijke vraag van het departement Integratie was om een sjabloon op te stellen dat de testers in de mogelijkheid zou stellen om op een geüniformiseerde manier testscenario’s op te stellen en te beheren. Toen de keuze op Excel gevallen was, is bij het coderen duidelijk geworden dat het gegeven “sjabloon in Excel (*.xlt)” misschien beter niet als een losstaand element van de automatiseringstool Tacos moest gezien worden. Excel wordt immers door de automatiseringsfunctie als applicatie aangeroepen, en het aanroepen van een sjabloon binnen dezelfde applicatie kan net zo goed vervangen worden door de sjablooneigenschappen voor de applicatie direct in de VB-code op te nemen. (draagbaarheid van de tool; men hoeft geen pad meer op te zoeken naar het sjabloon…). Qua opvatting spreekt zo’n Excelsheet nogal voor zich: in de gangbare testscenario’s werd de rij 1 voorzien om kolomtitels in onder te brengen. Deze kolomtitels waren dan ofwel de “namen“ van de invoervelden ofwel de aan te slagen toetsen in de te testen verrichting (alfanumerieke invoer, softkey, enter of skiptoets). In de huidige versie is er echter geopteerd voor een andere aanpak en zijn de kolomtitels onder mekaar geplaatst in kolom A, en dit vanaf cel A2 17. Dit was nodig omdat de parse-code de TFM-code sequentieel overloopt en alle mogelijke invoervelden in een verrichting weerhoudt. In extreem complexe verrichtingen zou dit kunnen leiden tot een te beperkt aantal kolommen. Bovendien is het aangewezen om kwaliteit van de testcases te laten primeren op de kwantiteit en zal het aantal cases dus kleiner zijn dan het mogelijke aantal invoervelden. Het werk van de integratoren bestaat nu verder uit het aanvullen van de cellen (1 kolom per testcase) in de gegenereerde scenario’s met relevante testdata. Als de tool later gecombineerd wordt is het zeker van belang dat de recurrente velden (datasecties die meerdere malen doorlopen worden in het dialoogmodel) op de juiste plaatsen van testdata te voorzien: maar het testscenario zal nooit los gezien kunnen worden van de te testen verrichting, zonder de verrichting heeft het scenario immers geen reden van bestaan…
17
De cellen in rij 1 werden gereserveerd voor het testcasenummer, wat van belang is bij eventueel later gebruik van het scenario in combinatie met WinRunner®.
3. Conclusies 3.1. Is testen zinvol? Uiteraard is testen zinvol, want alle inspanningen ten spijt kan men kwaliteit niet in die mate in een productieproces inbouwen dat testen overbodig wordt. In veel gevallen, meerbepaald in productieketens wordt automatisering aangegrepen om de kwaliteit te verhogen, maar in dit geval gaat het om het al bij al abstracte gegeven “software”, dat zelf bovenaan de automatiseringsketen staat. In die hoedanigheid is software misschien het beste voorbeeld van hoe kwaliteit zich niet laat inbouwen: de complexiteit en specificiteit van de meeste software maken dat het automatiseren zelf zich moeizaam of niet laat automatiseren. Op die manier zal men de noodzaak van het testen dus al niet kunnen omzeilen … Als men bovendien de budgetten bekijkt die de meeste bedrijven voor deze activiteit uittrekken, dan kan men dit moeilijk loochenen. Maar…, deze budgetten zijn vaak ook de grootste belemmering bij het testen. Men weet immers dat men een product nu eenmaal niet eeuwig zal kunnen testen en dat men ooit zal moeten ophouden met testen. En het einde van de testactiviteit wordt in de praktijk enkel gedicteerd door geld: hetzij onder de vorm van een beschikbaar testbudget, hetzij onder de vorm van een bedrag dat een bedrijf niet bereid is te bepalen indien een bepaalde fout zich voor zou doen. Dit is een realiteit die misschien een beetje aan de essentie van enerzijds een product en anderzijds het testen voorbijgaat, namelijk dat een product gemaakt wordt om een bepaalde functionaliteit uit te oefenen en dat het testen zich in wezen zou moeten toeleggen op het controleren of deze functionaliteit wel door het product wordt gerealiseerd. Het is (gelukkig?) wel zo dat “functionaliteit” doorgaans niet “perfectie” betekent, en dan kunnen testen en budget samen de limiet zoeken tussen het aanvaardbare en het onaanvaardbare “falen”. Kortom, testen is niet alleen zinvol, het is een noodzaak.
3.2. Hoe dient dit het beste te gebeuren? Er wordt bij het testen bij voorkeur enige efficiëntie en productiviteit nagestreefd. Zoals eerder vermeld moet het bedrijf in de eerste plaats overtuigd zijn van de noodzaak van het testen (vertaald naar geld en tijd). Echter ook de mensen die de testtaak op zich nemen dienen er zich bij betrokken te voelen en ze moeten er bovendien vanuit technisch oogpunt iets van af weten. Ze dienen er zich immers van bewust te zijn dat ze een deel in een geheel vormen. Dan pas kan er een strategie uitgewerkt worden, die met de juiste middelen en technieken kan aangevuld worden. Vermits testen kan betekenen “iets controleren met de bedoeling fouten te vinden” kunnen we er vanuit gaan dat de ingesteldheid bij het testen van groot belang is en mee gaat bepalen hoe er getest gaat worden. Elke fout is echter niet dezelfde, en er moet eerst en vooral gezocht worden naar de belangrijke fouten. Bovendien weet men niet hoeveel dat er wel zouden kunnen zijn. Daarom stelt men een aantal metrieken voorop die de efficiëntie en productiviteit van de inspanning moeten helpen beoordelen. Het testen gebeurt ook best systematisch. Systematisch wil zeggen met een onderliggend systeem, een manier van werken waarbij elke schakel in het proces zijn of haar functie kent (is in de praktijk blijkbaar niet altijd zo evident: sommigen wanen zich analist, terwijl de
analist zijn methodes opdringt aan programmeur, een tester laat eigen inzichten primeren op lastenboeken en technische vereisten…). Hoe groter het bedrijf, hoe belangrijker het is om extra aandacht te besteden aan de communicatie tussen de entiteiten (analisten – programmeurs - testers). Pas als iedereen zich mee verzoend heeft, kan men met succes een aantal technieken gaan implementeren. Het V-model heeft hieromtrent een aantal intrinsieke kwaliteiten: het betrekt “testen” bij alle fases en streeft ook communicatiefunctie tussen de betrokken entiteiten na. Het zet aan tot interactie tussen de aangrenzende niveau’s, maar ook iedereen die vereisten formuleert wordt verzocht om na te denken over hoe het al dan niet bereiken van die vereisten kan gepeild worden. Dit houdt dan ook in dat het testen eigenlijk al van bij het begin van de ontwikkeling dient aan te vangen. Dit impliceert niet altijd het concrete uitvoeren van testen, maar ook het in vraag stellen van de gebruikte aanpak, methodes, procedures, … Als dit dan in laatste instantie nog in zekere mate geautomatiseerd kan worden, worden al een flink deel van die al te menselijke nukken weggewerkt.
3.3. Mogelijkheden en beperkingen bij het automatiseren Het is algemeen geweten dat automatisering en standaardisering van processen kunnen bijdragen tot sneller en efficiënter werken. Vaak laten ze een betere planning toe, die ook bijdraagt tot een geoptimaliseerde benutting van de capaciteiten van het personeel. Als beide goed doorgevoerd worden kunnen ze bovendien (menselijke) vergissingen helpen vermijden. Voor grote bedrijven is standaardisering zelfs een must, wil het kunnen functioneren... Daarom heeft dit werk getracht zich op beide te concentreren: de automatisering bij de aanmaak van testscenario’s werkt tijdsbesparend en als iedereen met dezelfde tool (en bijgevolg dezelfde gegenereerde resultaten) werkt, is dit tevens een standaardisering. Eerste vraag was dan ook wat er al geautomatiseerd en gestandaardiseerd was en wat niet. En als het nog niet geautomatiseerd of gestandaardiseerd was, waarom dit nog niet het geval was. Er was tot nu toe niet echt een gestandaardiseerde testtool; elke integrator bepaalde zelf hoe hij zijn scenario’s aanmaakte. Indien een scenario evenwel in combinatie met de bestaande automatische testingtool WinRunner® gebruikt ging worden, werd de aanmaak van het scenario in Excel een noodzaak. Waarom was er dan geen gestandaardiseerde testtool? Vooreerst is er een probleem wat betreft de technische haalbaarheid: textparsing is niet eenvoudig, maar het systeem dient idealiter toepasbaar te zijn op de immense bibliotheek van TFM-objecten (zou zo’n 700MB aan bestanden zijn), en deze bibliotheek herbergt dan ook een enorme diversiteit aan verrichtingen... (dagdagelijkse bank, beleggingen, kredieten, verzekeringen, …). Het realiseren van een allesomvattend systeem (genereren scenario en autonoom runnen van testcases) is weinig waarschijnlijk. Verder is er een probleem met de rendabiliteit van zo’n project: als het gerealiseerd is, kan je het dan ook gebruiken? In dit geval situeert het probleem zich vooral bij het automatisch laten lopen van testen met WinRunner®, omdat de voorheen-ASLK-databank anders geconcipieerd is dan die van de voorheen-Generale Bank. Maar het werk toont aan dat er zeker ook mogelijkheden bestonden en nog bestaan, om via textparsing en eventueel daarop aansluitend een automatic testing tool de testactiviteiten verder te standaardiseren en te automatiseren.
Hoewel er zeker ook vragen blijven, en er bepaalde keuzes dienen gemaakt… Men kan zich bijvoorbeeld methodologische vragen stellen: er kan op deze manier enkel een sequentieel verloop 18 van de verrichting getest worden, daar waar –zeker bij het gebruik van grafische interfaces- absoluut niet kan gegarandeerd worden of de gebruiker de invulvelden, dialogboxes, etc in de praktijk óók sequentieel gaat doorlopen. De gebruiker mag verder in zijn navigatie doorheen de velden nooit geblokkeerd worden. Het testen laat zich evenwel moeilijk, zoniet onmogelijk verzoenen met zulk een verregaand dynamisme zonder op weer andere beperkingen te botsen. Hiertegen kan mogelijk ingebracht worden dat de keuzes en ingevulde tekst in een scherm pas gevalideerd worden op het ogenblik dat de gebruiker op de OK-knop drukt (en dat de wijze waarop de data hieraan voorafgaand verzameld werd van ondergeschikt belang is). Dit soort bedenkingen kan doen vermoeden dat een automatisch gegenereerde test dan ook een flink deel aan realiteitswaarde inboet. Zelfs als men er via een soort randomfunctie in zou slagen om de paden doorheen de verrichting te laten variëren, kan men nog alle mogelijkheden niet testen en zou men, in het geval van de kantoorapplicatie Pacific met een serieus probleem zitten om nog langer WinRunner® te gebruiken voor het automatisch uitvoeren van de tests. Een keuze dient gemaakt: het dynamisme en gebruiksvriendelijkheid (van GUI’s) of een strak verloop en (gedwongen?) efficiëntie…
18
Er kan uiteraard wel in het scenario weergegeven worden welke opties een bepaalde dialogbox aanbiedt, maar dan zijn het gelijk alle mogelijkheden waar er uiteindelijk maar eentje van dient geselecteerd te worden.
4. Annexen 4.1. Voorbeeld: code van een (kort) dialoogmodel in TFM Het dialoogmodel ACN.adm <94 A> <255>
@(#)pACN.DM
5 0 1 [ 530.8 98/07/14 11:14:06] 980714
1 tr te <ex>fi,pr vs no 2 <s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save) buf_op update,buf_ref(sect),buf_ref(code) buf_op update,buf_ref(sect),buf_ref(loket) sect.timacn=loket.end_time sect.adr=INcte.ADRES sect.nod=loket.node sect.tty=loket.tty_nr sect.ltt=loket.ltt_nr technische gegevens S nf pACN %SI_lib in 4 afdruk pet <1024 A> <4> <0 +> <100 b> if code.code="455" then !guard=+1 if code.code="250" then !guard=+1 if code.code="550" then !guard=+1
<s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save) S nf %SI_lib in pACNpe 3 afdruk bedrag <s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save) rem *** makes layout *** #amt=save.amt #amtcur=save.amtcur rem *** geen tegenwaarde drukken op rug overschrijving *** #amt_cvcur=!emp gosub EUR.pAMT.uall_inlab sect.amt=#labout1 S nf %SI_lib in pACNam 1 afdruk aantal verrichtingen SIXXX <s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save) <1024 A> <4> <0 +>
<100 b> if code.code="455" then !guard=+1 if code.code="250" then !guard=+1 if code.code="550" then !guard=+1 S nf %SI_lib in pACNnb 1 afdruk tnum <s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save) <1024 A> <4> <0 +> <100 b> if save.tnum=!emp then !guard=+1 S nf %SI_lib in pACNtn 1 nr. transfert financier <1024 A> <4> <0 +> <100 b> if save.ntf=!emp then !guard=+1 <s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save)
S nf %SI_lib pACNnt in 1 afdruk chequenummer circ. SI250 <1024 A> <4> <0 +> <100 b> if code.code<>"250" and code.code<>"550" then !guard=+1 if save.chqnum=!emp then !guard=+1 <s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save) sect.chqnum=ustr(save.chqnum) S nf %SI_lib in pACNch 2 afdruk referentie <s g> <1024 A> <4> <0 +> <100 b> buf_op update,buf_ref(sect),buf_ref(save) <1024 A> <4> <0 +> <100 b> if code.code<>"455" and code.code<>"250" and code.code<>"550" then !guard=+1
S nf %SI_lib in pACNre <- 1> 3
4.2. Voorbeeld: code van een datasectie in TFM De datasectie ACN.ads, waarnaar in het bovenstaand dialoogmodel verwezen wordt tussen de regels 40 en 47 (blauw aangeduid) <100> pACN 980526 24 1 <ea>0 <er>0 0 0 17 <sv>16 20 78 <sa>0x00000000 <sf o>[ \00 TECHNISCHE GEGEVENS \00 \00 Uur : \9ctimacn;\00 \00 Adres : \9cadr;\00 Node : \9cnod;\00\80 TTY : \9ctty;\00\ \80 LTT : \9cltt;\00\9f] 0x00000520 99:99:99 7 <el>8 0 <sd>0x0000 <pr>2 24
0x00000421 1 <el>1 0 <sd>0x0000 <pr>3 24
<nod> 0x00000421
3 <el>3 0 <sd>0x0000 <pr>3 36 0x00000421 2 <el>2 0 <sd>0x0000 <pr>3 48
0x00000421 2 <el>2 0 <sd>0x0000 <pr>3 59
4.3. Voorbeelden van een deelapplicatiescherm en een volledig applicatiescherm De bovenstaande datasectie resulteert dan in een deeltje van een verrichtingsscherm…
Afbeelding van de gegevens uit de ACN-datasectie
… en meerdere datasecties kunnen dan resulteren in een compleet verrichtingsscherm, zoals de gebruiker ze voor zich krijgt (het voorbeeld op volgende bladzijde is wel afkomstig uit een andere 19 –meer herkenbare- verrichting, namelijk een storting).
Afbeelding van een verrichtingsscherm (storting) uit de Pacificapplicatie
19
Er werd hier duidelijkheidshalve geopteerd voor een “duidelijke” afbeelding, die helaas wel losstaat van het eerder vermelde dialoogmodel en datasectie (die uit een meer simpele, maar weinigzeggende verrichting komen).
4.4. VB-code Tacos ‘Project.components: hier werd MS Common Dialog Control 6.0 aangekruist ‘bij References werd MS Word/Excel geselecteerd opdat men vanuit VB Word en Excel zou ‘kunnen openen Option Explicit 'declaratie en ruimte reserveren voor globale variabelen Dim obj As Word.Application Dim doc As Word.Document Dim xl As Excel.Application Dim DataSecties() As String 'array waar de datasecties in opgeslagen zullen worden Dim Fields() As String 'array waarin de velden zullen opgenomen worden Dim tel1 As Integer 'teller voor de datasecties in het dialoogmodel Dim tel2 As Integer 'teller voor de velden in de datasecties Dim Frans As Integer 'identificator voor de Franstalige velden Dim i As Integer Dim Info As String Dim Veldje As String 'tekststring die bewerkt zal worden tot de eigenlijke veldtekst afgezonderd is Dim path As String 'padnaam van het doorzochte bestand Dim startdir As String 'string om bij te houden in welke directory het geselecteerde dialoogmodel zich ‘bevindt
Private Sub GetFields(path As String) Dim posi As Integer Dim taal As String Dim pad As String Dim ds As String Dim swfout As Boolean On Error GoTo errHandlgf If tel2 > -1 Then taal = "F" Else taal = "N" pad = ComDial.FileName Do pad = Left(pad, Len(pad) - 1) Loop While Right(pad, 1) <> "\" pad = Left(pad, Len(pad) - 1) & "_" & taal 'scan de datasecties For i = 0 To tel1 'open datasectie If Right(DataSecties(i), "4") = ".adx" Then dialogboxes DataSecties(i), taal Else posi = InStr(1, DataSecties(i), "%") If posi Then ds = pad & Right(DataSecties(i), Len(DataSecties(i)) - posi) Else ds = path & DataSecties(i) End If swfout = False Set doc = obj.Documents.Open(ds & ".ads") LblInfo.Caption = Info & vbCrLf & vbCrLf & "Analyzing ... " & obj.ActiveDocument.Name If swfout = False Then With doc.Application.Selection 'vervang "\enter" door "enter" en "\80" door een spatie With .Find
.Text = "\" & vbCrLf .Replacement.Text = vbCrLf .Forward = True .Wrap = wdFindContinue .Execute Replace:=wdReplaceAll .Text = "\80" .Replacement.Text = " " .Execute Replace:=wdReplaceAll End With Do 'zoek identificatie van invoerveld en vervang (om niet in een oneindige lus te verzeilen) With .Find .Text = "\9" .Replacement.Text = "@" .Forward = True .Wrap = wdFindContinue End With If .Find.Execute(Replace:=wdReplaceOne) Then 'zoek voorafgaande identificatie van veld With .Find .Text = "\" .Replacement.Text = "" .Forward = False .Wrap = wdFindContinue End With .Find.Execute 'positioneer in het begin van het veld .MoveRight wdCharacter, 3 'selecteer de veldtekst Do .MoveRight wdWord, 1, wdExtend Loop While Right(Trim(.Text), 1) <> "@" Veldje = Trim(.Text) Veldje = Left(Veldje, Len(Veldje) - 1) If Veldje <> "" Then 'verwijder CrLf uit de veldtekst Do posi = InStr(1, Veldje, vbCrLf) If posi Then Veldje = Left(Veldje, posi - 1) & Right(Veldje, Len(Veldje) - posi - 1) Else Exit Do End If Loop Veldje = Trim(Veldje) 'opvullen en herdefiniëring van fields array If Veldje <> "" Then tel2 = tel2 + 1 ReDim Preserve Fields(tel2) As String Fields(tel2) = Veldje End If Else 'herpositioneer voor verdere opzoeking .MoveLeft wdCharacter, 2 End If Else Exit Do End If Loop End With
'sluit datasectie doc.Close wdDoNotSaveChanges End If End If Next i Exit Sub errHandlgf: swfout = True MsgBox "unable to find " & ds, vbOKOnly, "Message" Resume Next End Sub
Private Sub GetDataSecties(pad As String) Dim dial As String Dim dir As String Dim ds As Boolean Dim dx As Boolean Dim fn As Boolean If processing.Checked Then obj.Visible = True 'het overlopen van de Word-files om de inhoud van de ‘datasecties en datavelden te achterhalen zichtbaar maken With obj.ActiveDocument.Application.Selection 'zoek datasecties (tagcode "7"), dm (tagcode "6") en dx (tagcode "24") LblInfo.Caption = Info & vbCrLf & vbCrLf & "Analyzing ... " & obj.ActiveDocument.Name Do With .Find .Text = "" op te zoeken Do .MoveRight wdCharacter .MoveRight wdCharacter, 1, wdExtend Loop While .Text <> ">" .MoveRight wdCharacter 'selecteer naam Do .MoveRight wdWord, 1, wdExtend
Loop While InStr(1, .Text, vbCrLf) = 0 .MoveLeft wdCharacter, 1, wdExtend If InStr(1, .Text, ".") Then .Text = Left(.Text, InStr(1, .Text, ".") - 1) If Left(.Text, 1) = "%" Then .Text = "%" If fn Then dir = .Text Else dial = .Text End If Loop While dir = "" Or dial = "" If ds Or dx Then If dx Then dial = dial & ".adx" tel1 = tel1 + 1 'herdefinieer de datasecties array ReDim Preserve DataSecties(tel1) As String DataSecties(tel1) = dir & "\" & dial Else If dir = startdir Then dial = dir & "\" & dial If InStr(1, dial, "%") = 0 Then Set doc = obj.Documents.Open(pad & dial & ".adm") GetDataSecties (pad) LblInfo.Caption = Info & vbCrLf & vbCrLf & "Analyzing ... " & obj.ActiveDocument.Name End If End If End If End If Else Exit Do End If Loop End With 'sluit het ontlede dialoogmodel obj.ActiveDocument.Close wdDoNotSaveChanges End Sub
Private Sub Validate() Dim rowke As Long Dim colleke As Long Dim str As String Dim tel As Integer Dim tel1 As Integer Dim formul As String Dim formatformul As String Dim msgtitle As String Dim msg As String Dim i As Integer For rowke = 2 To 65536 'beëindig indien het laatste gegevensveld is bereikt If xl.Cells(rowke, 1) = "" Then Exit For 'controleer of het om een rekening- of chequenummer gaat If InStr(UCase(xl.Cells(rowke, 1)), "REK") Or InStr(UCase(xl.Cells(rowke, 1)), "CHEQ") Then For colleke = 2 To 256 If colleke > 26 Then If colleke Mod 26 Then tel = 64 tel1 = 64 Else tel = 63
tel1 = 90 '"Z" waarde End If str = Chr(Int(colleke / 26) + tel) & Chr(Int(colleke Mod 26) + tel1) Else str = Chr(colleke + 64) End If If InStr(UCase(xl.Cells(rowke, 1)), "REK") Then 'zet rekeningformaat If colleke = 2 Then xl.Range("B" & rowke, "IV" & rowke).NumberFormat = "0000000000-00" 'validatieformule rekeningnummer formul = "=NOT(mod(int(" & str & rowke & "/100);97)-(" & str & rowke & "-int(" & str & rowke & "/100)*100))" 'formule special format rekeningnummer formatformul = "=mod(int(" & str & rowke & "/100);97)-(" & str & rowke & "-int(" & str & rowke & "/100)*100)" msgtitle = "Accountnumber" msg = "You entered an invalid accountnumber" Else 'validatieformule chequenummer formul = "=NOT(mod(" & str & rowke & "-(int(" & str & rowke & "/100000)*100000);7)int(" & str & rowke & "/100000))" 'formule special format chequenummer formatformul = "=mod(" & str & rowke & "-(int(" & str & rowke & "/100000)*100000);7)int(" & str & rowke & "/100000)" msgtitle = "Chequenumber" msg = "You entered an invalid chequenumber" End If 'zet validatieregel For i = 1 To 2 xl.Worksheets(i).Activate With xl.Cells(rowke, colleke).Validation .Add xlValidateCustom, xlValidAlertInformation, xlBetween, formul .ErrorTitle = msgtitle .ErrorMessage = msg .ShowInput = False .ShowError = True End With Next i xl.Worksheets(1).Activate 'zet formaatcondities in eerste cel en kopieer naar volgende If colleke = 2 Then xl.Cells(rowke, colleke).Select xl.Selection.FormatConditions.Add Type:=xlExpression, Formula1:=formatformul xl.Selection.FormatConditions(1).Font.ColorIndex = 3 xl.Selection.Copy xl.Range("C" & rowke, "IV" & rowke).Select xl.Selection.PasteSpecial xlFormats End If Next colleke End If Next rowke 'kopieer formaatcondities naar Franse worksheet xl.Range("A2", "IV" & rowke).Select xl.Selection.Copy xl.Worksheets(2).Activate xl.Range("a2").Select xl.Selection.PasteSpecial xlFormats xl.Range("a1").Select xl.Worksheets(1).Activate
xl.Range("a1").Select xl.Application.CutCopyMode = False End Sub
Private Sub Exit_Click() 'einde End End Sub
Private Sub Form_Load() 'vul Informatie label in Info = "This tool analyses a chosen dialogmodel." & vbCrLf Info = Info & "It extracts all the labels which were found" & vbCrLf Info = Info & "in the datasection components of the model," & vbCrLf Info = Info & "and puts them in an excel sheet." & vbCrLf LblInfo.Caption = Info End Sub
Private Sub Open_Click() 'declaratie locale variabelen Dim dm As String 'variabele voor de dialoogmodel-bestandsnaam Dim test As String Dim swWord As Boolean On Error GoTo errHandler tel1 = -1 tel2 = -1 'open dialoog keuze dialoogmodel ComDial.Filter = "Dialog models (*.adm)|*.adm" ComDial.Flags = cdlOFNFileMustExist 'geef een fout als "cancel" wordt aangeklikt ComDial.CancelError = True ComDial.InitDir = "\\s71m0101\dvlvss\wsm" ComDial.ShowOpen 'bepalen naam van het gekozen dm dm = Left(ComDial.FileName, Len(ComDial.FileName) - 4) Do dm = Right(dm, Len(dm) - InStr(1, dm, "\")) Loop While InStr(1, dm, "\") 'zet scherm in "busy mode" Screen.MousePointer = vbHourglass 'creëer wordobject en open het dialoogmodel Set obj = CreateObject("Word.Application") swWord = True Set doc = obj.Documents.Open(ComDial.FileName) LblInfo.Caption = Info & vbCrLf & vbCrLf & "Analyzing ... " & ComDial.FileName 'zoek de datasecties in het opgegeven dialoogmodel
path = ComDial.FileName For i = 1 To 2 Do path = Left(path, Len(path) - 1) Loop While Right(path, 1) <> "\" If i = 1 Then startdir = Left(path, Len(path) - 1) Else startdir = Right(startdir, Len(startdir) - Len(path)) End If Next i GetDataSecties (path) 'zoek de velden GetFields (path) 'zet path voor Franstalige datasecties Frans = tel2 'zoek de velden GetFields (path) 'sluit Word obj.Quit wdDoNotSaveChanges swWord = False 'open Excel Set xl = CreateObject("Excel.Application") If processing.Checked Then xl.Visible = True LblInfo.Caption = Info & vbCrLf & vbCrLf & "Creating excel workbook" 'maak workbook en vul velden in xl.Workbooks.Add xl.Worksheets(1).Name = dm & " NL" xl.Worksheets(2).Name = dm & " FR" For i = 0 To tel2 If i > Frans Then xl.Worksheets(2).Cells((i + 1 - Frans - 1) + 1, 1) = Fields(i) Else xl.Cells(i + 2, 1) = Fields(i) End If Next i 'het derde, lege blad kan niet automatisch verwijderd worden via VB wegens een opduikend dialoogvenster in Excel 'dat om een extra bevestiging vraagt. Dit heeft een blokkerend effect op de uitvoering van het programma... 'aanpassen columnsize For i = 2 To 1 Step -1 xl.Worksheets(i).Activate xl.Cells.Select xl.Cells.EntireColumn.AutoFit If xl.ActiveSheet.Columns("A:A").ColumnWidth < 36 Then xl.ActiveSheet.Columns("A:A").ColumnWidth = 36 xl.ActiveWindow.SplitColumn = 1 xl.Range("A1").Select If i = 1 Then xl.Cells(1, 1) = "Test Nr." Else xl.Cells(1, 1) = "Test N°" Next i
'zet controles in excel-sheet Validate 'zichtbaar maken van excel xl.Visible = True 'Afsluiten End errHandler: 'tonen van een foutboodschap indien deze niet afkomstig is van cancel op "opendialoog" test = 0 If Err.Number <> 32755 Then test = MsgBox(Err.Description, vbOK, "Error") Screen.MousePointer = vbDefault LblInfo.Caption = Info If swWord Then obj.Quit wdDoNotSaveChanges End Sub
Private Sub processing_Click() processing.Checked = Not (processing.Checked) End Sub
Private Sub dialogboxes(ByVal box As String, lang As String) 'box wordt geïmporteerd by value, omdat in de datasectierange, de naam 'niet gewijzigd mag worden voor later gebruik Dim lijst As String Dim fld As String Dim obj2 As Word.Application Dim doc2 As Word.Document box = Left(box, Len(box) - 4) box = Right(box, Len(box) - InStr(1, box, "\")) 'open de lijst met dboxctrls Set doc = obj.Documents.Open(path & startdir & "\" & Left(startdir, 2) & "dbxlst.afd") LblInfo.Caption = Info & vbCrLf & vbCrLf & "Analyzing ... " & box With doc.Application.Selection 'vervang "\enter" door "enter" ,"[","]" door "" en door "," With .Find .Text = "\" & vbCrLf .Replacement.Text = vbCrLf .Forward = True .Wrap = wdFindContinue .Execute Replace:=wdReplaceAll .Text = "[" .Replacement.Text = "" .Execute Replace:=wdReplaceAll .Text = "]" .Replacement.Text = "" .Execute Replace:=wdReplaceAll .Text = "" .Replacement.Text = "," .Execute Replace:=wdReplaceAll .Text = "<" & box & ">" End With
'zoek de dboxctrls If .Find.Execute Then .MoveRight wdCharacter, 1 .HomeKey wdStory, wdExtend .Delete With .Find .Text = "<" .Execute End With .MoveLeft wdCharacter, 1 .HomeKey wdStory, wdExtend With .Find .Text = vbCrLf .Replacement.Text = "" .Execute Replace:=wdReplaceAll .Text = vbTab .Execute Replace:=wdReplaceAll End With lijst = .Text End If End With If lijst <> "" Then obj.ActiveDocument.Close wdDoNotSaveChanges 'open specifieke vertaalbuffer Set doc = obj.Documents.Open(path & startdir & "_" & lang & "\" & Left(startdir, 2) & "lab.afd") With doc.Application.Selection 'verwijder "\ <enter>", "[" en "]" With .Find .Text = "\" & vbCrLf .Replacement.Text = vbCrLf .Forward = True .Wrap = wdFindContinue .Execute Replace:=wdReplaceAll .Text = "[" .Replacement.Text = "" .Execute Replace:=wdReplaceAll .Text = "]" .Replacement.Text = "" .Execute Replace:=wdReplaceAll End With 'open de algemene vertaalbuffer Set obj2 = CreateObject("Word.Application") Set doc2 = obj2.Documents.Open(path & "INSY" & "_" & lang & "\INlab.afd") With doc2.Application.Selection With .Find 'verwijder "\ <enter>", "[" en "]" .Text = "\" & vbCrLf .Replacement.Text = vbCrLf .Forward = True .Wrap = wdFindContinue .Execute Replace:=wdReplaceAll .Text = "[" .Replacement.Text = "" .Execute Replace:=wdReplaceAll .Text = "]" .Replacement.Text = "" .Execute Replace:=wdReplaceAll End With End With If Left(lijst, 1) = "," Then lijst = Right(lijst, Len(lijst) - 1)
Do 'selecteer de veldnaam If InStr(1, lijst, ",") Then fld = Left(lijst, InStr(1, lijst, ",") - 1) lijst = Right(lijst, Len(lijst) - Len(fld) - 1) Else fld = lijst lijst = "" End If 'zoek de vertaling indien het een optionbutton, label, frame of checkbox betreft If Left(fld, 3) = "OPT" Or Left(fld, 3) = "LAB" Or Left(fld, 3) = "FRA" Or Left(fld, 3) = "CHK" Then .Find.Text = "<" & fld & ">" 'in specifieke buffer If .Find.Execute Then .MoveRight wdCharacter, 1 Do .MoveRight wdCharacter, 1, wdExtend Loop While Right(.Text, 1) <> "<" .MoveLeft wdCharacter, 1, wdExtend With .Find .Text = vbCrLf .Replacement.Text = "" .Execute Replace:=wdReplaceAll .Text = vbTab .Execute Replace:=wdReplaceAll End With fld = .Text .HomeKey wdStory Else 'in algemene buffer With doc2.Application.Selection .Find.Text = "<" & fld & ">" If .Find.Execute Then .MoveRight wdCharacter, 1 Do .MoveRight wdCharacter, 1, wdExtend Loop While Right(.Text, 1) <> "<" .MoveLeft wdCharacter, 1, wdExtend With .Find .Text = vbCrLf .Replacement.Text = "" .Execute Replace:=wdReplaceAll .Text = vbTab .Execute Replace:=wdReplaceAll End With fld = .Text .HomeKey wdStory End If End With End If fld = Trim(fld) If fld <> "" Then 'schrijf veld in field array tel2 = tel2 + 1 ReDim Preserve Fields(tel2) As String Fields(tel2) = fld End If End If Loop While lijst <> ""
End With 'sluit algemene buffer obj2.Quit wdDoNotSaveChanges End If 'sluit specifieke buffer obj.ActiveDocument.Close wdDoNotSaveChanges End Sub
Referenties Bibliografie The Complete Guide to Software Testing, door William HETZEL, QED Information Sciences, Inc., Wellesley, Massachusetts 02181, 1984, Second Edition 1988. Software Testing Techniques, door Boris BEIZER, Van Nostrand Reinhold Co., New York, 1983, Second Edition 1990. Effective Methods for Software Testing, door William PERRY The logic of computer programming, door Zohar MANNA en Richard WALDINGER, IEEE Transactions on Software Engineering, SE-4, 1978. Software Testing, door Marc ROPER The Art of Software Testing, door Glenford MYERS, John Wiley, New York, 1979. Algoritmisch denken en programmeren, door Bart DHOEDT en Mario PICKAVET, syllabus, RUG, Vakgroep Informatietechnologie, 2000.
Nuttige link http://www.aptest.com/ op deze site kan men meer informatie vinden betreffende automatic
testingtools, onder andere WinRunner® van Mercury Interactive
Index acceptance test, 6; 10 AT/TA-applicatie, 24 automatisering, 33; 34 bedrijfsobjectieven, 4 Benchmarks, 16 beperkingen van het testen, 2 bestaande applicaties, 13 Black Box Testing, 10 Bruikbaarheidtest, 15 budget, 7; 33 CASE, 4 CAST, 1; 4; 11 chequenummer, 31 code generatoren, 4 code inspections. Zie White Box testing coderen, 4 data-driven testing. Zie Black Box testing datasectie, 25; 26; 28; 29; 40 debuggen, 2 debuggers, 11. Zie debuggen Desk Checking. Zie White Box testing dialogboxes, 29 dialoogmodel, 25; 26; 28; 36 drielagige client-serverarchitectuur, 19 drivers, 17 Dynamic Testing. Zie White Box testing Engagement, 8 functionaliteit, 4 Functionaliteittest, 14 fysische design, 4 gebruikersspecificaties, 12 gebruikersvereisten, 4 Glass Box Testing, 10 GUI-objecten, 23 Het uitvoeren van testcases, 16 Hoeveel mag een fout ons (niet) kosten?, 4 ingesteldheid, 2 input/output testing. Zie Black Box testing integratietesten, 21 integration test, 6 intuïtie en ervaring, 8 IT-project van de Fortis Bank, 18 kantoorserver, 19 Keuze van testdata, 17 kiddie testing, 12 logische design, 4 methodologische vragen, 35 metrieken, 33 ontwikkeling van de Pacific–applicatie, 20 Pacific, 18; 25 patch, 21 Performantietest, 16 porteren, 13 praktijk, 6 programma/unit design, 4
Proof of concept en code in Visual Basic 6.0, 27 regressie testen, 12 Regressietest, 15 regressietesten, 13; 21 rekeningnummer, 31 release, 21 resultaatvoorspelling, 12 richtlijnen om te stoppen met testen, 7 scenario. Zie scenario's software, 1 software engineering, 4 Software Testing, 1 specificaties, 10 standaardisering, 34 statische en dynamische velden, 26 stubs, 17 succesvolle tes, 2 symbolische voorspelling, 12 system audit, 6 system test, 6 Tacos (TFM application code object scanner), 24 terminologie, 3 Test, 3 test case designtechnieken, 12 test case generators, 12 test case selectietechnieken, 12 test procedure, 3 test session, 3 Testdocumentatie, 13 testen, 1; 5 testen van software. zie software testing tester, 3 Testing Aids, 11 Testmetrieken, 13 Testomgeving, 16 Testplanning en management, 16 testscenario’s, 18; 21; 32 Teststrategieën, 8 Testtechnieken, 10 testtechnieken en –methodes, 10 TFM-code, 21; 25; 26; 32 TFM-structuur en architectuur, 25 Toelichting bij de code, 27 TSL-expressie, 23 unit test, 6 validatiepunt, 3 Veiligheidstesten, 15 verwachte resultaten, 10 Visual Basic, 27; 43 V-model, 4; 5; 7; 8; 13; 34 Volumetest, 15 Waarom testen?, 4 walkthroughs. Zie White Box testing Wanneer moet er getest worden?, 6
watervalmodel, 4; 5 Welke types testen en hulpmiddelen bestaan er? Hoe worden ze in de praktijk gebracht?, 14 werkpost, 19 White Box Testing, 10 Wie gaat testen?, 14 willekeurig, 8 Windows NT-omgeving, 19 WinRunner®, 21; 23; 24; 34; 35
