Test System for SimCorp IMS Controlling and Tools. Automatisk kontrol af data - IMM-B.Eng november Christoffer W.

Transkript

1 28. november 2010 Christoffer W. Krogslund

2 Indholdsfortegnelse Side 1. Indledning Opgaven Problemet Proces Analyse Indledning / Scope Hvad er en test Hvordan testes Forvalte (manege) test Eksekvering af tests Rapportering af test resultater Teknologi System overblik Funktioner Konsol applikationen VSTO applikation VSTO Ribbon Kontrol Kortsigtet Udvidelses muligheder Design VSTO Ribbon Kontrol Nat job Run Frequency notifikation Database server vedligeholdelse Test Manager Kode design Visuelt Design Implementering Database Forklaring af tabeller Test Side 1 af 60

3 TestRecord TestToolRelation Query QueryType OutputType Opbygning af forespørgsler Test Runner Opstart Kør test(s) Debug Test Manager Run test Edit Query Edit Tool Add Tools to Test Listener VSTO Ribbon Kontrol Test Black-box vs. White-box Konklusion Bilag Tools Database Design Billede af Tools Overview Side 2 af 60

4 1. Indledning Opgaven er udarbejdet i samarbejde med IMS Controlling and Tools afdelingen hos SimCorp A/S. SimCorp er en verdensomspændende virksomhed med omkring 1100 ansatte. Virksomheden har et produkt, SimCorp Dimension som er et investerings management system. Dette system bliver opdateret 2 gange om året. For mere information se I løbet af min tid i praktik har jeg arbejdet for SimCorp A/S 1 i IMS Controlling and Tools afdeling. I denne afdeling bliver der udviklet værktøjer til internt brug, som bruges til at gøre visse informationer og opgaver lettere for firmaets andre ansatte. Til dette bliver der primært udviklet i C# med VSTO framework. VSTO indeholder funktioner til at kunne programmere løsninger til Office pakken, både i plug-in form men også på dokument niveau. Netop disse forskellige VSTO værktøjer er det centrale element i opgaven. Som integrationen med Office pakken bliver bedre kan man lave flere hjælpe værktøjer som kan lette arbejdsdagen for mange ansatte. Disse automatiserede Office dokumenter (primært Excel) bliver brugt både som planlægningsværktøjer og som strategi værktøjer, har et behov for at data der bruges er kontrolleret. Denne kontrol er hovedmålet med opgaven. Denne opgave er skrevet på dansk, men da programmet er udviklet til et internationalt firma vil nogle illustrationer samt funktionsnavne optræde på engelsk. 1 Side 3 af 60

5 2. Opgaven 2.1. Problemet Follow up on Budgets and Estimate Version 1.1 Kort beskrivelse I kort omtales det som Follow up Tool, det bruges primært, som navnet antyder, til at se hvordan budgetter og estimater stemmer overens med aktuelle værdier efter og under en given periode. Denne information kan man så benytte til at justere budgeter og estimater til næste periode, samt til status møder, månedsrapporter. Et hvert sted hvor det kan være nyttigt at se enten hvordan et hold ligger i forhold til arbejde udført og budget. Datakilder I dette værktøj benyttes data fra tre kilder, Absence and Duties, ARE og Siebel. Absence and Duties og ARE er VSTO værktøjer, Siebel er SimCorps CRM (Customer Relation Management). Hvad skal testes Hver nat kører der en del database scripts som lægger informationer der ellers ikke ville være tilgængelige ned i data view således at de kan præsenteres for brugere. De kan dog ikke ændres, det vil sige al manipulation med disse data skal ske ved at hive dem ud fra et af disse view. Det er opdateringen af disse views vi ønsker testet således at der ikke arbejdes med gammel data. Eksempel på test Side 4 af 60

6 For at teste at data er blevet opdateret som det skal en gang i døgnet, skal der sættes en test op der kører hver dag der kontrollere at den sidst indsatte række i et view er indsat på dags-dato. Hvis dette ikke er tilfældet skal der gives en fejl. Dette gøre ved at lave et database query der henter den sidste række ud, og herefter tester det tidspunkt den blev tilføjet med dags dato, dette query returnere så 0 eller 1 alt afhængig om datoerne er ens eller ej. Dette eksempel på en test giver en god idé om grundformen som tests i systemet har. Ved denne test som skal kører hver nat vil Follow up toolet straks efter test kørsel vise om datakilden er opdateret. Før skulle fejlen først opdages, herefter skulle den rapporteres til den ansvarlige for Follow up værktøjet. Herefter ville der så blive lavet en udbedring af fejlen. Netop denne fejl, der omhandler natlige opdateringer, er der en anden afdeling der står for, så fejlen skulle videre formidles, og der skulle laves en annoucement der beskrev fejlen således at folk ikke brugte værktøjet til fejlen var udbedret. Efter alt var i orden igen skulle der så endnu en annoucement ud der fortalte at problemet var løst. Målet med test systemet har været at gøre hele denne proces automatisk, for på den måde at undgå at spilde resourcer. Efter den natlige testkørsel stemmer den sidste dato ikke overens med dags dato og derfor meldes der fejl. Herefter bliver den sendt en mail med fejlbeskrivelsen ud til dem på testens mail liste (både den tool ansvarlige og en kontakt fra database gruppen vil være fornuftigt at knytte til denne). Herefter kan fejlen rettes, og i mens dette sker, bliver en hver bruger der åbner Follow up gjort opmærksom på at den sidste test fejlede. Når fejlen er rettet kører man testen igen og hvis alt er vel bliver værktøjets status opdateret. På denne måde bliver meddelelser på intranettet overflødige og man bliver mere sikker på at folk er klar over der er et problem, samt hvornår det ikke er der mere. Side 5 af 60

7 Der arbejdes med data fra mange forskellige kilder, i mange forskellige værktøjer. Indtil dette projekt har der ikke været nogen form for indikation om de data man arbejdede med var valide eller opdateret. Hvis en bruger ikke bliver fortalt andet, regnes et program for at fungere og data der bliver præsenteret går man ud fra er til at arbejde med. Der er imidlertid mistet arbejdstimer på folk der har arbejdet med eksempelvis forældet data. Det er situationer som denne som dette nye test system skal forhindre. For selvom det ikke selv kan rette fejl skal det kunne rapportere til brugere og folk ansvarlige for værktøjet. Herefter kan der så tages handling for at udbedre fejlen, mens brugeren kan lave andet arbejde og vende tilbage senere for at se om fejlen er rettet. Herved får man fordelen af at fejlrapportering bliver automatisk, og ikke som det foregår i dag hvor en fejl først skal findes af en bruger og derefter kommunikeres videre til alle potentielle brugere af et værktøj. Udover dette fjernes behovet for at en ansat selv skal finde den ansvarlige for værktøjet og give besked omkring en fejl, systemet vil selv sørge for at sende en mail til den tilknyttede ansvarlige og kan således udbedre fejlen. Typisk vil arbejdsgangen foregå ved at et værktøj er udviklet og der ønskes nu at sætte en test op til at teste data. Det vil som regel være udvikleren af værktøjet der vil stå for at oprette denne test, da denne af åbenlyse årsager vil have mest forstand på hvordan en sigende test vil være. Testsystemet skal holde brugerne af diverse værktøjer orienteret omkring status på data der bruges i et givent værktøj. Dette er udgangspunktet for opgaven, at lave et system der kan vise om det er tilrådeligt at benytte et værktøj. Formuleret på en anden måde skal det fremgå tydeligt i det et værktøj åbnes om informationerne der vises og kan benyttes er korrekte og opdateret. Opgaven er formuleret således at informationen omkring status på data skal vises i en VSTO Ribbon gruppe. Side 6 af 60

8 Da der bliver lavet nye værktøjer regelmæssigt, skal systemet kunne håndtere at der bliver lavet nye tests som kan knyttes til et eller flere værktøjer. Der skal altså være en mulighed for at kunne tilføje nye tests til systemet, denne funktion vil udelukkende blive benyttet af ansatte i IMS Controlling and Tools, disse er alle IT kyndige mennesker hvor af flere har programmeringserfaring. Fokus i denne del af opgaven ligger derfor på funktionalitet og mindre på brugervenlighed. Udover dette er det et krav at denne del af system kan tilgås fra SimCorps intra-net, som er opbygget i Windows Sharepoint. Dette er en begrænsende faktor da Sharepoint ikke tillader programmer (som eks..exe filer) at eksekvere. Der skal derfor findes et alternativ til en Windows applikation. Microsoft Sharepoint 2 er en metode til at dele og arbejde sammen på dokumenter på tværs af en virksomhed. Derfor kræver det et dokument før at man kan lægge det på serveren. Dette gør at Test Manger vil blive lavet i VSTO som et Excel dokument. På denne måde kan man også drage nytte af standart biblioteker lavet internt til VSTO løsninger, samt at få fordelen af nemt at kunne dele programmet. Der skal laves en applikation til at kører tests samt opdaterer databasen med de nyeste test resultater. Denne applikation skal sættes til at køre dagligt således at hvis det ønskes kan en test kontrollerer data hvert døgn. Denne applikation skal lave et udtræk af test i databasen og herefter eksekvere hver enkelt, for herefter at evaluere resultatet. Grafisk overblik over løsningen der ønskes. 2 Side 7 af 60

9 2.2. Proces Bag et hvert succesfuldt programmerings projekt ligger en god plan for hvordan selve processen skal styres. Der er her flere forskellige metoder hvorpå man kan styre et projekt fra idé til produkt. I dette afsnit vil nogle af disse metoder blive beskrevet kort, samt komme en vurdering om hvor vidt de passer til netop dette projekt. Som med det meste er der ikke en løsning hvor man kan sige at denne er den rigtige måde at styre en udvikling på. Forskellige løsningsmodeller vil passe forskellige projekter/virksomheder. For at begrænse mulighederne e kan man starte med at fastslå at dette projekt er forholdsvis lille set med proces øjne. Det vil blive designet, implementeret samt testet af en mand. Vandfalds metoden (Linær) Side 8 af 60

10 Denne metode fungerer ligesom en tidslinje. Man starter ved krav og ender med et produkt, uden på noget tidspunkt at stoppe op. På denne måde skaber man et projekt der kræver meget lidt vedligeholdelse imens det står på til gengæld vil der være en nødvendighed for mere tid til krav specifikation og design da disse bliver låst fast tidligt i forløbet. Denne model er meget fastlåst og hvis der opstår problemer med designet på et senere tidspunkt er der ikke afsat tid til at rette. Spiral (fortløbende) Her brydes et projektforløb op i mange små dele. Herefter startes der med at analysere, designe og udvikle kernen af problemet. Herefter bygges således på softwaren ved hver gennemløb. Det er de samme typer af milepæle som ved vandfald, her er det således mindre milepæle flere gange. Ved dette opnår man et mere fleksibelt design. Dette kræver regelmæssige møder inden for projektgruppen. Rapid application development (iterativ og fortløbende) Her minimeres behovet for analyse og design til fordel for prototyper. Her designes sideløbende med der udvikles, prototype bliver ofte diskuteret og rettet til så de passer kundens behov. På denne måde kan designet hele tiden ændre sig i takt med at kunden bestemmer sig for funktioner. Af disse tre er Rapid application development valgt som den foretrukne metode til at styre denne proces. Dette er blevet valget i det det er et forholdsvis lille projekt hvor projekt ejerne er meget tilstede. Derfor kan man drage fordel af at lave en lille del af systemet for herefter at vise det frem og diskuterer det der er lavet samt næste skridt. På denne måde bliver produktet hele tiden udviklet efter kundens ønsker. Side 9 af 60

11 3. Analyse 3.1. Indledning / Scope Det centrale i implementeringen af dette system vil være de tests der skal kunne oprettes, redigeres, køres, status rapporteres på. Da netop dette påvirker alle dele af system er en afklaring af præcis hvad der skal kunne testes samt hvor detaljeret rapporteringen skal være, en af de vigtigste brikker at forstå Hvad er en test I dette system dækker udtrykket en test over en samling af informationer der er nok til at gennemføre en kontrol af data. Systemet fokusere på at lave denne kontrol af datakilder (databaser) derfor vil det centrale element i en test være en database forespørgsel. Udover dette skal der være et resultat til at sammenligne resultatet fra forespørgslen. Dette resultat kan enten være en fast værdi, eller endnu en forespørgsel. En test består af følgende elementer. Navn Beskrivelse Fejl tekst Query1 Query2 Fast resultat Side 10 af 60

12 Tolerance I en hver test vil der null felter for at give plads til både et fast resultat og et query2. Disse felter kan ikke blive brugt på samme tid. Tolerance er en fast numerisk værdi giver en såkaldt buffer således at man kan lave en test således resultatet skal passe ± tolerance i det et query altid skal returnere en tal værdi. Fremgangsmåden hvorpå et query vil blive lavet er at brugeren laver sin database forespørgsel i et eksternt IDE, som eksempelvis Microsoft SQL Server Management. Efter man har fået det ønskede resultat ud gemmer man en tekst fil (eller en.sql fil) på trusted location. Det er så denne fil man forbinder med en test. Her vil programmet så gå ind og parse tekst filen får at kunne køre forespørgslen. Fast resultat er en integer der ligger i databasen. Det er ikke altid at der skal testes op i mod et andet query og derfor skal der være mulighed for at give et fast tal som resultatet af query1 skal evalueres op i mod Hvordan testes Generel set er det datakilder til VSTO værktøjer der skal testes. Da dette er et meget bred betegnelse og hvilke data der bruges i hvilket værktøj spænder vidt er det ikke hensigtsmæssigt at opstille grænser hvor hvad der kan testes, i stedet opstilles der regler for hvordan resultatet af dataudtrækket ser ud. Tag eksempel 1, der er to måder hvorpå vi kan strukturere denne. Enten kan der laves et udtræk der returnere datoen for den sidste indsatte række, og herefter give testen et forventet resultat der hedder dags dato, eller man kan vælge at lave denne sammenligning inde i forespørgslen og returnere en boolean værdi alt efter om datoen stemmer eller ej. Således sammenligner den natlige test ikke datoer, men blot en boolean altså om database kaldet returnerer 0 eller 1. Side 11 af 60

13 Det samme gælder for andre typer af test, et eksempel mere kan være antallet af ansatte. Dette kald skal returnere en række med et tal, i stedet for et dataset med alle ansatte. Man vil altså stå tilbage med 2 resultater, enten fra 2 forespørgsler eller fra 1 forespørgsel samt en fast værdi. Udover dette skal der være en mulighed for at have en tolerance værdi, det vil sige en fast værdi som difference mellem de to resultater skal overgå før en fejl bliver meldt. Til at udregne om en status på en fest er sand (test lykkedes) eller falsk (test fejlede) skal der bruges en algoritme der kan tage to resultater, finde forskellen og sammenligne det med en fast værdi. 1 2 Altså hvis den absolutte difference mellem resultat1 og resultat2 er mindre end eller lig med tolerance er en status på test sand (eller test lykkedes). Det næste eksempel er en testcase der er blevet brugt som case under udviklingen af systemet. Denne test skal kontrollere at antallet af medarbejdere, i udviklingsafdelingen, er det samme i to forskellige tabeller. Sql1, kaldet EmployeeCountOLTP. SELECT COUNT([EMPLOYEE_ID]) FROM SC_EMPLOYMENT_DEPARTMENT WHERE GETDATE() BETWEEN START_DATE and ISNULL(END_DATE, GETDATE()) AND UNIT = 'IMS Development Department' Sql2, kaldet EmployeeCountOLAP SELECT COUNT([EMPLOYEE_ID]) Side 12 af 60

14 FROM [WC_EMPLOYMENT_DEPARTMENT_D] WHERE GETDATE() BETWEEN START_DATE and ISNULL(END_DATE, GETDATE()) AND UNIT = 'IMS Development Department' Disse to database queries returnere således en værdi hver, disse to værdier bliver evalueret via den enkle formel vist tidligere i dette afsnit. Herefter skrives resultatet af denne evaluerings ned i TestRecord tabellen Forvalte (manege) test Da både database tabeller samt værktøjerne ændrer sig med tiden (der kommer nye værktøjer og derfor også nye tabeller) skal måden hvorpå en test tilføjes til systemet kunne styres et centralt sted. Efter en test er tilføjet med de nødvendige informationer skal der ikke oprettes noget andre steder(med undtagelse af hvis det er et helt nyt værktøj mere om dette i afsnit 0). Stedet hvor test vil blive forvaltet vil samtidig blive stedet hvor det vil være muligt at finde let statistik over testkørsler. Det er også her det vil muligt at danne sig et overblik over alle test samt deres nuværende status. Hvis en test fejler ved den natlige kørsel, vil det i den perfekte verden blive rettet lige så snart folk møder på arbejde. Hvis dette sker skal værktøjer der bruger denne test naturligvis ikke vise en fejl hele dagen indtil næste gang den natlige kørsel blive eksekveret. Derfor skal der være en funktion til manuelt at køre en eller flere test. I travle tider kan en fejl blive nedprioriteret og derfor ikke rettet inden for et døgn, hertil skal det være muligt at markere en test således at fejlen ikke bliver rapporteret ud hver nat. Dette er mest for at forhindre at sende s ud der Side 13 af 60

15 beretter om en fejl der allerede er kendt. Muligheden for at give dette check en udløbsdato har været diskuteret, således at man ikke glemmer en fejl. Det er et krav fra SimCorp at denne test manager skal kunne tilgås fra SimLink 3 således at den kan findes samme sted som andre værktøjer udviklet af IMS Controlling and Tools Eksekvering af tests Hver nat skal alle test eksekveres og database skal opdates med resultatet af hver test. Til dette formål skal der laves et program der kan analysere på test kriterierne og bestemme om testen er vellykket eller fejlet. Der skal samtidig være en log af hvad dette program foretager således at man kan se hver morgen om alle test er kørt succesfuldt eller ej. Test bliver hentet fra databasen og lagt i en liste, med en status der indikere at den ikke er kørt. Herefter køres denne liste igennem test bliver udført og status bliver opdateret. Herefter kan man så opdatere databasen efter hver test eller vente med at opdatere til hele listen er kørt færdig. For at sikre at oplysninger bliver gemt selvom programmet går ned halvvejs vil det være mest hensigtsmæssigt at opdatere databasen straks efter hver test er udført. Når alle test er kørt skal der udsendes en mail til IMS Controlling & Tools i tilfælde af minimum en ikke succesfuld kørsel. Denne mail skal indeholde en kort 3 SimCorps Intranet Side 14 af 60

16 beskrivelse af hvilke test, samt et dump der viser resultat fra query(ies). Hvis det viser sig at mailen bliver for uoverskuelig med debug informationer i, skal der findes en måde at have en liste med ikke succesfulde test dumps. Dette vil eventuelt kunne ligge som et underpunkt til Forvalte (manege) test (3.1.3). En bruger skal må max modtage 1 mail per eksekvering. Hvis en bruger står til at modtage mails på mere end en test der er fejlet skal denne modtage én mail der beskriver begge fejltilfælde. Eksekveringeren / evalueringen skal kunne tage højde for følgende faktorer: Runfrequency: Ikke alle tests skal eksekveres hver nat, der skal derfor kun køres de test der er sat til at køre dags dato. Compare option: En test skal kunne sammenlignes med enten et andet query, en integer værdi eller en boolean. Tolerance: Hvad enten testen skal sammenlignes med en fast værdi eller resultatet fra en anden forespørgsel skal der være mulighed for at give en tolerance værdi som forskellen på resultaterne skal være større end før der bliver meldt fejl. Dette er ikke muligt på udryk der sammenlignes med en boolean. Side 15 af 60

17 Rapportering af test resultater Som tidligere beskrevet har hver test minimum et værktøj tilknyttet, denne relation vil være beskrevet en database. Alle værktøjer skal således have tilknyttet en Ribbon del der kontrollere status på alle test der er knyttet til det respektive værktøj. Denne del skal både have en grafisk repræsentation af det seneste test resultat, samt en tekst der i tilfælde af fejl beskriver kort hvad der er galt. På et senere tidspunkt skal status på værktøjer kunne ses i VSTO værktøjet tools overview(se bilag 8.2), mere om det under punkt 3.5 Side 16 af 60

18 Her ses et sekvensdiagram der beskriver processen efter en bruger har åbnet et værktøj. En bruger åbner et værktøj, herefter sender værktøjet et forespørgsel til databasen. Retur kommer der et DataSet med alle relevante rækker fra TestRecord tabellen. Herefter bliver det korrekte billede vist til brugeren. Hvis en fejl findes med lav kritisk niveau vises udråbstegnet, hvis en med høj fejl vises stop tegnet. Fejlen en med højt niveau vil altid have præcedens Teknologi Som beskrevet i krav skal Test Manager delen kunne findes på intranettet, derfor skal den laves i VSTO. Det skal ribbon kontrol også, da denne skal integreres i en allerede eksisterende Ribbon i de forskellige værktøjer. Disse to ting er derfor fastlagt til at skulle programmeres i C# eller VBA i det VSTO understøtter disse to sprog. Af disse to sprog vil C# være det foretrukne rukne at udvikle i. Test Runner har ikke det samme fastlagte krav om udviklingssprog denne skal blot kunne køres fra en Windows Server. Da de to andre er fastlagte, er valget om sproget til denne 3. del faldet på C# da det giver det samme sprog over hele systemet. Ud over dette Side 17 af 60

19 får man som medarbejder i SimCorp ikke andet udviklingsmiljø end Microsoft Visual Studio System overblik Dette afsnit vil omhandle systemet som helhed. Ved at kigge på hvordan test er opbygget vil der blive lagt en overordnet plan for hvordan systemet skal opbygges. De ovenstående 3 dele af test, kan siges at være de 3 store emner som projektet indeholder. De overlapper alle hinanden gennem Tools databasen, men udover det vil de ikke dele meget funktionalitet. Derfor kan man opdele projektet i de 3 blokke. Det er relationerne disse blokke i mellem, der vil blive gennemgået nu. Konsol applikationen: henter dens tests i tabellerne i Tools databasen(td), disse vil primært være test i OBI eller den interne produktions database. Herefter lægger den resultatet af hver enkel test ned i en tabel i TD. VSTO applikation: vil have de samme dataforbindelser. Her vil den primære forbindelse være TD, det er her informationerne omkring test og værktøjer vil blive Side 18 af 60

20 hentet frem og præsenteret for brugeren. Da der skal foreligge brugeren muligheden for at afprøve test i denne applikation er det nødvendig at have forbindelse til både OBI og den interne produktions database. VSTO Ribbon Kontrol: Testsystem delen af VSTO værktøjerne har kun behov for at kunne se sidst kørte test. Denne del af system har derfor udelukkende behov for at have forbindelse til TD Funktioner Her vil de vigtigste funktioner i de 3 system dele blive gennemgået kort ved brug af use cases. Hver case vil få en kort beskrivelse, for at give et overblik over hvad systemet har af funktioner. Side 19 af 60

21 Konsol applikationen Det er her test bliver udført og tabellen Test Record bliver vedligeholdt med de nyeste resultater. Run Test: Her bliver tests i systemet eksekveret og resultaterne lagt i Test Record tabellen. Side 20 af 60

22 VSTO applikation Add Test: Tilføj en ny test til systemet. Denne proces deles op i flere funktioner. Ved Add Test bliver brugen bedt om at indtaste navn, beskrivelse og fejl tekst, disse kan alle ændres senere hvis det skulle blive nødvendigt. Herefter bliver den nye test tilføjet til arket og nu kan brugeren tilføje andre dele af testen. Run Test: Eksekverer en test og opdaterer arket med resultatet. Testen der bliver eksekveret afhænger af hvilken en celle brugeren har valgt. Edit Query: Her skal sættes testens forespørgsel(ser) ind, samt informationer der vedrører disse. Add Test to Tool: Her skal værktøjerne kædes sammen med tests. Det skal være muligt at have en forbindelse med enten højt eller lavt kritisk niveau. Dette niveau bestemmer hvilket billede brugeren skal have vist i tilfældet af fejl. Edit Tool: Her kan navn, beskrivelse og fejl meddelelse for en test rettes. Activate/Deactive: Her kan man sætte en test på standby således at den ikke bliver inkluderet i den natlige kørsel før den igen er sat på aktiv. Subscription: Man kan her tilføje medarbejdere til en tests mailing liste. I det en medarbejder er knyttet til en test vil denne modtage en mail hvis denne test fejler VSTO Ribbon Kontrol Display Result: Denne del af systemet ligger ikke som en fast del. Dette er en gruppe, der skal laves til et hvert værktøj. Her bliver de Test Records der vedrører et værktøj hentet fra databasen og resultatet bliver vist med et billede på værktøjets ribbon. Side 21 af 60

23 3.5. Kortsigtet Udvidelses muligheder VSTO Selv test: Alle VSTO værktøjer skal have implementeret en selv test der skal køres fra den natlige test kørsel. Grunden til at dette ikke bliver implementeret fra starten er at der ikke er en sammenhæng mellem disse to typer tests udover at de skal kunne køres automatisk hver nat. Ved VSTO værktøj test skal værktøjet ved eksekvering af en bestemt bruger starte en selvtest, indholdet af denne er ikke bestemt endnu og vil med al sandsynlighed variere i hvert værktøj. Disse test vil omhandle specifikke funktioner i selve værktøjet og vil ikke håndtere datakilder. Statistik: Correction Time: Et tidsinterval i dage der udregnes ved at tage datoen for den første succesfulde test efter den er markeret som ikke succesfuld. Efter som der i kravene er lagt op til forskellige niveauer hvor kritiske fejl er, kan der på et senere tidspunkt også laves et udtræk der fortæller hvor hurtigt fejl bliver rettet i de forskellige niveauer. Test Success Rate: For en hver test kan der udregnes en procent sats for hvor ofte en given test kører succesfuldt. En månedsrapport / årsrapport kan blive afsendt til IMS Controlling and Tools gruppen der indeholde en oversigt over disse værdier, evt. ved brug af grafer. Test eksekvering Vedligeholdelses dage: Der er dage hvor databaserne ikke er tilgængelige, her vil det ikke være hensigtsmæssigt at køre natkørslen da alle test vil blive Side 22 af 60

24 markeret som om der var fejl. Disse datoer kan af indlysende årsager ikke lægges i en tabel i databasen, en mulighed vil være at lægge dem i en tekst fil / XML fil på trust location. Test Manager Passiv test udløbsdato: Muligheden for at sætte en test til passiv skal være til stedet fra første udgivelse. En naturlig udvidelse på dette er at man skal kunne give denne deaktivering en udløbsdato hvorefter testen igen vil indgå i eksekveringen. Side 23 af 60

25 4. Design Nedenstående billeder og beskrivelser er lavet i forbindelse med møder hvor på værktøjet er blevet diskuteret. Design af systemet er opdelt i de 3 hovedgrupper omtalt i analysen, VSTO ribbon kontrol, Natlig test og test forvalter (manager) VSTO Ribbon Kontrol Hver gang et værktøj starter op skal der laves et tjek i Tools databasen for at se den sidst kørte test status. Dette gøres ved at lave en tilføjelse alle værktøjer, her er der to ting der skal tilføjes. Først skal der indsættes en billede kontrol i Ribbon, herefter skal der indsættes koden der opdatere denne kontrol med det rigtige billede samt kommentar tekst. Herefter skal Ribbon kontrollen afspejle denne, til dette formål er der lavet 4 billeder. Nedenfor ses de 4 billeder samt en kort forklaring af hvad de betyder i forhold til test status. Working Hvis alle test der er knyttet til værktøjet har succesfulde kørsler. Warning Side 24 af 60

26 Hvis ingen af de tests der ikke er succesfuldt kørt har et niveau der er kritisk. Her skal brugeren præsenteres overfor hvilke test der er fejlet og kan således selv træffe en beslutning om værktøjet kan benyttes til det formål brugeren har. Do Not Use Kritiske fejl i test. Her vil brugeren igen blive præsenteret for hvilke test der er fejlet. Der har været tale om at man skal kunne låse værktøjet, dette ligger dog ikke i krav specifikationen for denne version af test systemet. Unknown Dette er hvis VSTO ribbon kontrollen ikke kan finde relevante test data. Igen vil brugeren blive præsenteret med en kort beskrivelse af hvorfor denne besked vises, eks. Test data er forældet. Udover det grafiske, skal brugeren også kunne se hvilke dele af værktøjet som ikke er testet succesfuldt. Dette gøres ved at brugeren ved at holde musen over billedet bliver præsenteret for en eller flere linjer kort tekst der fortæller hvilke test der har fundet fejl. Herefter kan brugeren således selv tage en beslutning om denne fortsat ønsker at bruge værktøjet Nat job Denne del af systemet skal udelukke stå for, hver nat, at hente alle test fra databasen og eksekvere dem og opdatere databasen med de nye værdier. Der vil ikke være nogen interaktion med brugeren, alt dette vil forgå i manageren. Derfor vil dette blive lavet i en konsol applikation med Outlook integration. Side 25 af 60

27 Alle tests ligger i en liste, denne liste køres igennem og efter hver test opdateres databasen med de nye informationer dato, status og fejlbesked. Dette gøres ved at indsætte en ny række i databasen for at holde historik overskrives den gamle ikke. Herudover vil der hver nat blive skrevet til en log fil. Dette er for at lette debug arbejdet hvis natkørslen en dag ikke bliver kørt til ende. Her er muligheden for at gemme log filer eller hver nat overskrive den samme. Log filen vil blive lavet i en tekst fil hvor hver linje vil være tidsstemplet samt indeholde information om præcis hvad programmet foretager sig med hvilken test Run Frequency En hver test skal gives et tidsinterval hvor denne skal køres. Til at starte med vil der være muligheden for enten at vælge daglig, ugentlig eller månedlig eksekvering. For at forenkle denne operation vil ugentlige test blive afviklet mandag, og månedlige vil blive afviklet den første i måneden notifikation Applikationen skal kunne udsende s i tilfælde af at en test returnere en fejl. I Visual Studio C# kan man opnå Outlook integration på flere måder. Brug vært computerens Outlook Ved at importere en del af VSTO kan man åbne en instans af Outlook automatisk og herefter benytte denne instans funktioner. Man kan derfor sende mails ud, bruge denne konto s kontakt bog sætte aftaler op osv. Der er visse ulemper ved denne tilgang, alle mails bliver udsendt fra den bruger der er logget på (i dette tilfælde vil det være en server bruger). I det applikationen skal flyttes skal der Side 26 af 60

28 tages hensyn til at der skal være Outlook og der kan udsendes mail med fra adressen. Send direkte fra koden Hvis man har adgang til en SMTP server kan man få applikationen selv til at udsende s. Her skal der opsættes hvilken server man ønsker at benytte. Fordelen her vil være at uanset om man flytter programmet eller ej vil mailen blive sendt så længe applikationen kan tilgå SMTP serveren. Ulempen her er at hvis man ikke har adgang til en sådan server (hvilket er tilfældet her) kan det ikke lade sig gøre. Exchange Web Services(EWS) 4 EWS er udviklet af Microsoft for at lette programmering til Exchange Server. Det er muligt ved brug af dette bibliotek at logge på en hvilken som helst Exchange konto så længe man har adgang til Exchange serveren. Her skal bruges et brugernavn, en adgangs kode, et domæne samt en adresse til serveren. Ud af disse muligheder vil vi benytte os af den sidste, EWS API giver os mulighed for at kunne flytte vores program som det er nødvendigt og samtidig udsende e- mails fra en konto med et sigende navn. Der vil til opgave blive oprettet en ny Exchange konto kaldet autotest, således vil alle mails blive udsendt fra Autotest@Simcorp.com. Udover dette giver denne løsning også muligheden for at styre Server Maintenance dage på en ny måde, se nedenfor Database server vedligeholdelse 4 Side 27 af 60

29 Der vil være dage hvor database serverne er nede og det derfor er uhensigtsmæssigt at køre tests, da alle test vil returnere en fejl og derved lægge fejl data ned i test record tabellen. Derfor skal der udvikles en måde hvorpå der kan sættes datoer hvor applikationen ikke skal køre om natten. Windows Schedular For at få programmet til at køre hver nat benyttes Windows indbygget planlægnings funktion Schedular. Denne funktion kan også bruges til at lave undtagelses dage, hvor programmet ikke skal køres. Dette vil kræve at der er en bruger der aktivt logger på serveren opsætter en undtagelse per dag applikationen ikke skal eksekveres. Lokal database Der kan oprettes en lokal database på serveren hvor test programmet køres fra. Dette vil kræve at denne database kan tilgås fra enhver der har rettigheder til at lægge undtagelses dage ind i systemet. Enten skal administrationen af disse dage forgå i Manager delen ellers skal brugere blot lægge datoer direkte i databasen. Det sidste er udelukkende en mulighed da det vides på forhånd at brugere af dette system er folk med erfaring i både programmering og SQL. Tekst fil Hvis man indtaster datoer i en tekst fil der er placeret på Trust Location vil programmet kunne parse denne tekst fil og derved bestemme om dagsdato er en vedligeholdelses dag. Selvom dette system skal anvendes af programmeringskyndige personer er denne måde lettere end at skulle opdatere en database direkte. En standart for dato input skal opretholdes i dette dokument da det ellers kan føre til at applikation vil blive kørt på dage hvor det ikke er meningen. Side 28 af 60

30 EWS kalender I notifikation (4.2.2) blev der omtalt muligheden for at benytte sig af EWS API. Dette vil give os muligheden for at benytte os af mail kontoens kalender, samt Exchange mødeindkaldelse. På denne måde kan man styre hvilke dage applikationen ikke skal køres ved at oprette en mødeindkaldelse med Autotest@Simcorp.com kontoen med en specifik tekst. Så kan man gøre det via Outlook, men kan også laves en funktion i Manager applikationen som kan lægge en aftale ind på en specifik dato. Løsningen der vil blive brugt i systemet er tekst fil løsningen. Denne har fordelen af at være enormt enkel at vedligeholde Test Manager Dette bliver systemets grafiske interface, det er her brugeren kan ordne alt hvad der er brug for med hensyn til at vedligeholde test databasen. I denne del af systemet skal der være mulighed for at oprette en ny, redigere samt fjerne eksisterende tests. Et af de centrale krav til denne del er at det skal kunne findes på SimCorps intranettet, SimLink. SimLink tillader ikke.exe filer at eksekvere derfor kan denne del ikke laves som en Windows Forms applikation som ellers ville have være det åbenlyse valg. Som alternativ kan der bruges VSTO, hvis man laver en Excel applikation i VSTO vil den have endelsen.xlsx og det vil derfor være muligt at eksekvere den fra SimLink. I dette dokument skal der peges på en trusted location hvor installationsfilerne vil være. Herefter skal opdateringer kun skubbes ud på den ene placering, da dokumentet kontrollere om der er opdateringer hver gang det startes. Dette er en enkelt måde at holde programmet opdateret over hele virksomheden. Side 29 af 60

31 Her vil hver række repræsenterer en test, kolonerne vil repræsenterer hver information der er forbundet med hver test. Informationerne der vil blive vist vil, for overblikkets skyld, være skåret ned til de vigtigste oplysninger. Hvis man så ønsker mere information om en given test vil der være en funktion / flere funktioner til at vise detaljerne på en valg test. På samme måde vil der også være flere skridt i at tilføje en test Kode design Selve koden til Test Manger er opbygget efter 3-lags modellen. Brugerflade delen vil udelukke stå for at præsentere brugeren med data, logik delen vil lave alle udregninger der skal til at præsentere data ordentligt og database laget håndtere lagring af data. Som det kan ses på nedenstående illustration af 3 lags modellen ligger Lists klassen i mellem logik og data laget. Det er for at illustrere at denne klasse er bindeled i mellem de to lag. Metoder i denne klasse tager DataSet fra databasen og lægger informationerne ned i lister som logik laget så håndterer yderligere. Side 30 af 60

32 Udover disse indeholder løsningen også vinduer samt objekter. Hvordan vinduerne ser ud kan du se under Visuelt Design (pkt ). Side 31 af 60

33 Visuelt Design I det New knappen trykkes vil brugeren blive bedt om at indtaste et navn til den nye test. Herefter udfyldes der en række i arket (nederst), udover det netop indtastede navn vil rækken bestå af nul værdier (null, N/A, 0 etc.). Under afsnittet Hvad er en test kan det ses hvad der skal bruges til at køre en test. Det er disse informationer som brugeren nu skal udfylde. Når den nye test er oprettet i på arket vil cellen med testens navn komme i fokus. Dette betyder at redigerings funktionerne bliver aktiveret. Dette er ikke særligt for en ny test, dette vil ske når cellen i fokus er på en række der indeholder en test. Nu kan brugeren vælge at fortsætte med at indsætte flere nye eller specificere den netop oprettede test. Det sidstnævnte gøres gennem de indlagte knapper der ligger i Ribbon. Side 32 af 60

34 Dette program skal bruges internt i en gruppe af IT kyndige mennesker, så selvom der skal være vægt på bruger venlighed ligger funktionalitet højere prioriteret. Hvis ikke det var sådan ville en trin for trin guide nok passe sig bedre til at oprette en ny test. Nedenfor er der skitseret hvordan de 3 vinduer kunne se ud. Run Test(s) Brugeren skal på et hver tidspunkt have muligheden for at starte en hver test. Målet med dette er at man kan kontrollere sin nyoprettede test, så vel som at kunne teste om en udbedring af en fejl virker uden at skulle vente et døgn. Dette gøres ved at vælge en celle der tilhører testens række, herefter trykkes Run Test og denne test vil blive kørt og arket opdateret. Subscriptions Subscription, eller hvad vi på dansk kan kalde for mail grupper er lavet for at personer kan skrive sig op og få en mail i tilfældet at en test fejler. Her vil vi benytte os af en funktion i det allerede eksisterende Forms bibliotek 5, her ligger der en form der giver brugeren mulighed for at vælge ansatte ud fra forskellige kriterier. Herefter returneres en liste med de valgte medarbejder, det er denne liste der ligges i List of selected employees. Dette er ikke færdig udviklet. 5 Forms er det VSTO bibliotek der bruges internt i Controlling and Tools afdelingen. Side 33 af 60

35 Edit Query Dette system bruger SQL queries til at teste data. Arbejdsgangen ved at lave nye test er designet til at man laver og tester selve forespørgslen i SQL Server Management Studio, herefter gemmer man forespørgslen i en.sql fil på trust location. På denne måde bliver alle vil forespørgsler været testet i et IDE 6 og man er sikker på at det korrekte bliver returneret. I dette system skal der derfor bruges stien til den forespørgsel. Dette kan gøres på to måder enten ved at skrive stien ind manuelt, eller bruge Windows indbyggede fil manager, så kan brugeren pege på filen og stien kan hentes ud. Der vil i databasen være et felt der indeholder en sti til en parent folder denne vil holde stien til en mappe på den interne trust location hvor SQL forespørgslerne skal lægges. Der bruges internt i SimCorp tre forskellige database systemer, da der skal være mulighed for at teste på alle disse, og de har forskellige log in samt adresser er brugeren nød til at specificere hvilket system testen skal køres på. 6 Eksempelvis Microsoft SQL Server Management Studio ( Side 34 af 60

36 Den nederste del af denne form skifter alt efter hvad der vælges af Query eller Value. Add tool to test Her laves relationen værktøj og test i mellem. I systemet er der to niveauer af fejl critical level dette kan være højt eller lavt. Det skal være muligt at give forskellige niveauer til hvert værktøj der er knyttet til testen. Derfor vil bindingen blive skabt i det forbindelsen mellem test og værktøj bliver lavet. Som det kan ses på illustrationen vil der være mulighed for at lægge værktøjer ind med niveau 1 (lav) eller 2 (høj). Side 35 af 60