DataMuseum.dk

top - metrics - download

    Length: 13824 (0x3600)
    Types: RcTekst
    Names: »CORN23.WP«

└─⟦b73a66207⟧ Bits:30005844 Dokumenter - Per Cornelius #12 - #134
    └─⟦this⟧ »CORN23.WP« 

RcTekst

╱04002d4e0a000600000000020a5031000000000000000000000000000000000000000000000000000e18222c36404a545e68727c86909aff04╱
↲
↲
CORN          AFD. 12                      84.02.27       EDB.CORN.23↲
↲
↲
↲
↲
↲
↲
┆a1┆PLANLÆGNING AF EN BRUGER TEST.↲
↲
↲
↲
1.  INDLEDNING.↲
↲
↲
2.  FORUDSÆTNING FOR TEST PLAN.↲
↲
↲
3.  HVAD SKAL TESTES ?↲
↲
↲
4.  KAN TESTEN DELES OP ?↲
↲
↲
5.  HVILKEN RÆKKEFØLGE SKAL TESTEN UDFØRES I ?↲
↲
↲
6.  HVORNÅR KAN TESTEN TIDLIGST STARTE ?↲
↲
↲
7.  HVORNÅR SKAL TESTEN VÆRE AFSLUTTET ?↲
↲
↲
8.  HVEM FREMSTILLER TEST DATA ?↲
↲
↲
9.  HVORDAN LAVER MAN TEST DATA ?↲
↲
↲
10. HVORNÅR KAN MAN LAVE TEST DATA ?↲
↲
↲
11. SKAL TEST DATA OPBEVARES TIL GENBRUG ?↲
↲
↲
12. HVEM OG HVOR MANGE SKAL TESTE ?↲
↲
↲
13. HVORDAN KONTROLLERER MAN TESTEN ?↲
↲
↲
14. HVILKEN DOKUMENTATIONS FORM SKAL ANVENDES ?↲
↲
↲
15. HVEM GODKENDER TESTEN ?↲
↲
↲
16. ERFARINGER.↲

════════════════════════════════════════════════════════════════════════
↓
┆a1┆1.   INDLEDNING.↲
↲
Test af et edb-system kan være en uoverskuelig opgave, og anses↲
af nogle for den vanskeligste del af udviklings processen for et↲
edb-system.↲
↲
Årsagen kan være, at man for det meste går lidt let hen over plan-↲
lægningen af test-fasen på grund af mangel på tid, samt manglende↲
vejledning og erfaring.↲
↲
↲
┆b0┆┆a1┆Omfanget af test┆f0┆ i et edb-system kan afhænge af og kan være ↲
┆a1┆en kombination af:↲
↲
- systemets størrelse, antal program-moduler.↲
↲
- systemets art, online eller batch, opdatering eller udskrift.↲
↲
- systemets kompleksitet, hvor "indviklet" er det.↲
↲
- nyt eller gammelt system, er det første eller anden generation.↲
↲
- edb-anlæg og styre-systemer, gammelt og prøvet eller nyt.↲
↲
- test-person eller personer, har de prøvet det før.↲
↲
- systemets sikkerheds-niveau, højt eller lavt.↲
↲
- antal mulige brugere af systemet samtidigt.↲
↲
- file-transport, hvilken måde er valgt.↲
↲
↲
┆a1┆Hvordan udfører vi ┆b0┆┆f0┆en ┆f0┆bruger test, der omfatter følgende:↲
↲
Hvad skal testes ?↲
↲
Kan testen deles op ?↲
↲
Hvilken rækkefølge skal testen udføres i ?↲
↲
Hvornår skal testen tidligst starte ?↲
↲
Hvornår skal testen være afsluttet ?↲
↲
Hvem laver testdata ?↲
↲
Hvordan laver man testdata ?↲
↲
Hvornår kan man lave testdata ?↲
↲
Skal testdata opbevares til genbrug ?↲
↲
Hvem og hvor mange skal teste ?↲
↲
Hvordan kontrollerer man testen ?↲
↲
Hvilken dokumentations form skal anvendes ?↲
↲
Hvem godkender testen ?↲
↲
┆b0┆┆a1┆VI SKAL LAVE EN PLAN !!!┆e1┆┆f0┆  ( Forudsætning for eksempel se punkt 2)↲

════════════════════════════════════════════════════════════════════════
↓
┆a1┆2.  FORUDSÆTNING FOR TEST PLAN.↲
↲
Vi skal lave et system, ud fra en ide hos en bruger, der har deltaget↲
i udarbejdelse af kravspecifikation, og som har godkendt både krav-↲
specifikation og dertil hørende systemløsning.↲
↲
Ved udvikling af et system har vi nedbrudt systemet fra en stor ┆b0┆kasse↲
til et eller andet antal ┆b0┆små kasser.┆f0┆Denne nedbrydning bruger vi som↲
udgangspunkt. Vi kunne for eksempel tænke os følgende oversigt:↲
↲
                    ┆a1┆              ┆e1┆                          (niveau)↲
                    ┆a1┆DEBITOR-SYSTEM┆e1┆                          system↲
↲
--------------------------------------------------------- ↲
    ┆a1┆         ┆e1┆       ┆a1┆             ┆e1┆      ┆a1┆           ┆e1┆↲
    ┆a1┆POSTERING┆e1┆       ┆a1┆STAM-KARTOTEK┆e1┆      ┆a2┆┆e2┆┆a1┆KONTO-UDTOG┆e1┆ ┆a1┆┆e1┆         delsystem↲
↲
        -----------------------------------↲
     ┆a1┆        ┆e1┆  ┆e1┆     ┆a1┆           ┆e1┆        ┆a1┆         ┆e1┆↲
     ┆a1┆UDSKRIFT┆e1┆  ┆e1┆     ┆a1┆VEDLIGEHOLD┆e1┆        ┆a1┆FORESPØRG┆e1┆            segment↲
↲
             -------------------------↲
           ┆a1┆     ┆e1┆       ┆a1┆     ┆e1┆        ┆a1┆    ↲
           ┆a1┆OPRET┆e1┆       ┆a1┆ÆNDRE┆e1┆        ┆a1┆SLET┆e1┆                    modul↲
↲
↲
↲
For nemheds skyld er der kun vist noget af hele DEBITOR-SYSTEMET↲
og i det følgende vælger vi at lave en testplan for delsystemet↲
STAM-KARTOTEK med  tilhørende segmenter UDSKRIFT, VEDLIGEHOLD samt↲
FORESPØRG.↲
↲
Vi har til vores system lavet en ┆a1┆TIDSPLAN┆e1┆, her på et GANT-KORT:↲
Vi vil bruge denne tidsplan som et udgangspunkt til vores BRUGER↲
TEST PLAN.↲
↲
↲
↲
DEBITOR SYSTEM          >  STAM-KARTOTEK <          ↲
┆a1┆                                                                  ↲
┆a1┆AKTIVITET     !uge.nr:  41  42  43  44  45  46  47  48  49  50    ↲
↲
VEDLIGEHOLD:↲
   PROGRAM OPRET        -----↲
   PROGRAM ÆNDRE             -------↲
   PROGRAM SLET                     ------↲
↲
UDSKRIFT:↲
   PROGRAM LIST                          ---------↲
↲
FORESPØRG:↲
   PROGRAM SPØRG                                  --------↲
↲
Det fremgår af ovenstående tidsplan, at vi skal fremstille 5 ↲
programmer i en bestemt rækkefølge, og med anførte start- og ↲
slut-uger.↲
↲
Vi forudsætter, at vi kan teste de enkelte programmer hver for sig.↲
Det vil sige, at vi her kan teste program-moduler, men det er ikke↲
altid givet. Afhængig af systemets art og rækkefølgen af moduler kan↲
vi i nogle tilfælde kun teste hele segmenter eller delsystemer.↲

════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.  HVAD SKAL TESTES ?↲
↲
Vi skal teste VEDLIGEHOLD i stam-kartoteket til debitor-systemet.↲
VEDLIGEHOLD er et segment bestående af tre moduler (programmer).↲
↲
↲
┆a1┆4.  KAN TESTEN DELES OP ?↲
↲
Ja, og vi har faktisk fået forærende, at vi her kan dele VEDLIGEHOLD↲
op i 3 dele, nemlig opret, ændre og slet.↲
↲
↲
┆a1┆5.  HVILKEN RÆKKEFØLGE SKAL TESTEN UDFØRES I ?↲
↲
Vi følger her vores opdeling, som naturligt først tester oprettelser,↲
derefter ændringer, og til slut sletninger.↲
Det vil sige, at vi kan følge tidsplanens inddeling.↲
↲
↲
┆a1┆6.  HVORNÅR KAN TESTEN TIDLIGST STARTE ?↲
↲
Vi ser kun på selve maskin-testen, og forudsætter at test data er klar↲
forlængst.↲
Vi ser på vores tidsplan fra før:↲
↲
┆a1┆                                                                  ↲
┆a1┆AKTIVITET     !uge.nr:  41  42  43  44  45  46  47  48  49  50    ↲
↲
VEDLIGEHOLD:↲
   PROGRAM OPRET        -----↲
   PROGRAM ÆNDRE             -------↲
   PROGRAM SLET                     ------↲
↲
UDSKRIFT:↲
   PROGRAM LIST                          ---------↲
↲
FORESPØRG:↲
   PROGRAM SPØRG                                  --------↲
↲
Det fremgår af ovenstående tidsplan, at PROGRAM OPRET er færdigt i↲
uge 42, og at PROGRAM ÆNDRE er færdigt i uge 44 samt at PROGRAM SLET↲
er færdigt i uge 45.↓
Vi kan føre start tidspunktet ind på tidsplanen således:↲
↲
┆a1┆                                                                  ↲
┆a1┆AKTIVITET     !uge.nr:  41  42  43  44  45  46  47  48  49  50    ↲
↲
VEDLIGEHOLD:↲
   PROGRAM OPRET        -----↲
*  TEST    OPRET             *↲
   PROGRAM ÆNDRE             -------↲
*  TEST    ÆNDRE                    *↲
   PROGRAM SLET                     ------↲
*  TEST    SLET                           *↲
↲
UDSKRIFT:↲
   PROGRAM LIST                          ---------↲
↲
FORESPØRG:↲
   PROGRAM SPØRG                                  --------↲
↲
*'erne under ugenumrene markerer nu vores start tidspunkt for test.↲

════════════════════════════════════════════════════════════════════════
↓
↲
┆a1┆7.  HVORNÅR SKAL TESTEN VÆRE AFSLUTTET ?↲
↲
Hvis vi siger, at OPRET , ÆNDRE og SLET skal være testet færdig ↲
inden testen af PROGRAM LIST, så kan vi indsætte slut markering↲
på tidsplanen således:↲
↲
┆a1┆                                                                  ↲
┆a1┆AKTIVITET     !uge.nr:  41  42  43  44  45  46  47  48  49  50    ↲
↲
VEDLIGEHOLD:↲
   PROGRAM OPRET        -----↲
*  TEST    OPRET             *********************↲
   PROGRAM ÆNDRE             -------↲
*  TEST    ÆNDRE                    **************↲
   PROGRAM SLET                     ------↲
*  TEST    SLET                           ********↲
↲
UDSKRIFT:↲
   PROGRAM LIST                           --------↲
↲
FORESPØRG:↲
   PROGRAM SPØRG                                  --------↲
↲
*'erne under ugenumrene markerer nu vores test periode for VEDLIGEHOLD↲
men *'erne udtrykker ikke noget tidsforbrug.↲
↲
↲
┆a1┆8.  HVEM FREMSTILLER TEST DATA ?↲
↲
Programmøren fremstiller stort set sine egne test data, der skal teste↲
de program tekniske funktioner. Disse test data ser vi bort her.↲
↲
Vi ser på bruger test data. Brugeren har fra ide-fase, igennem krav-↲
specifikation og systemløsning, samt ikke mindst fra sit daglige ar-↲
bejde, det bedst mulige udgangspunkt for at fremstille test data.↲
↲
Der kan godt være flere brugere, der fremstiller test data, men der↲
en ansvarlig bruger, der skal sikre, at alle muligheder og de mest↲
tænkelige kombinationer er med.↲
↲
↲
┆a1┆9.  HVORDAN LAVER MAN TEST DATA ?↲
↲
Man kan lave et registreringsbilag, og skrive test data ned.↲
Afhængig af systemets art kan data måske tastes ind på forhånd.↲
↲
Hvis der er mulighed for det, kan man måske anvende et register↲
eller log fra eksisterende system, direkte eller konverteret.↲
↲
Test data skal omfatte lette og enkle data, men også komplicerede↲
og kombinerede data, der skal gå igennem testen.↲
↲
Fejl behæftede test data, der SKAL AFVISES, skal også fremstilles.↲
Under fejl behæftede data hører data, der ikke opfylder kravene til↲
felt indhold, f.eksempel bogstaver i talfelter, kodemarkeringer der↲
ligger udenfor tilladte værdier, beløb der er for store, eller nega-↲
tive tal i felter, der skal være possitive. Datoer i beløbsfelter og↲
omvendt skal også prøves.↲
↲
I udarbejdelsen af kravspecifikation og systemløsning vil man tit↲
diskutere vanskelighederne, derfor skriv ned og husk at bruge dette↲
til fremstilling af test data.↲

════════════════════════════════════════════════════════════════════════
↓
┆a1┆10. HVORNÅR KAN MAN LAVE TEST DATA ?↲
↲
Allerede fra ide-fasen og i kravspecifikation vil man kunne få ideer↲
om, hvad der skal testes. I systemløsningen vil der også være beskre-↲
vet, hvad og hvilke værdier, hvem må hvad, en række fakta der kan be-↲
nyttes til udarbejdelse af test data.↲
↲
Den eller de brugere der er med i de ovennævnte faser samt de brugere↲
der fra dagligt arbejde kender til "fejl-muligheder","problemerne",↲
"unødvendigt tidsrøveri","kontrol-arbejde" og "træls manuelt arbejde"↲
vil være de rette personer til udarbejde test data. Arbejdet kan rent↲
faktisk begynde, når et projekt er "født", og kan starte med at man↲
simpelhent skriver stikord ned, efterhånden som ideerne til test data↲
opstår.↲
↲
Senere, når man med sikkerhed ved hvilke oplysninger og deres række-↲
følge der skal bruges til testen, kan der fremstilles bilag, eventuelt↲
registreringsbilag til systemet's driftsfase !, og på disse bilag↲
overføres så de ideer, som der er skrevet ned.↲
↲
Undervejs i testen kan det sagtens forekomme, at man konstaterer mang-↲
lende test data, og så må testen gentages med flere data.↲
↲
På registreringsbilaget til test skal man anføre dels om data er ok↲
eller fejl, samt eventuel bemærkning om, hvad hensigten med netop ↲
disse test data er.↲
↲
↲
┆a1┆11. SKAL TEST DATA OPBEVARES TIL GENBRUG ?↲
↲
Hvis det er overhoved er muligt, så skal test data gemmes.↲
↲
Ved gentagne test, på grund af program eller systemændringer både↲
under udviklingen af et nyt system eller senere ved rettelser i↲
et gammelt system, er det en stor fordel at have test materialet↲
liggende. Brugeren bør kende resultatet på forhånd i de fleste↲
tilfælde.↲
↲
Det kan også forekomme at et eller flere programmer bliver ændret↲
bare lidt "hen ad vejen" af programmøren, og i disse tilfælde skal↲
testen gentages for at sikre mod fejl.↲
↲
┆b0┆Og husk at tid, der er anvendt til test under under udvikling af↲
┆b0┆et nyt system, bliver sparet når systemet kører i drifts-fase. !!↲
↲
↲
┆a1┆12. HVEM OG HVOR MANGE SKAL TESTE ? ↲
↲
Det afhænger at systemets art. Hvis det et et enkelt bruger system,↲
så kan der selvfølgelig ikke være flere brugere, der tester samtidigt↲
men kun een bruger af gangen.↲
↲
Et debitor-system er som regel et fler-bruger system, og her skal der↲
om ikke ved første test, så under senere test være flere brugere,↲
der tester samtidigt.↲
↲
Uanset antal af testende bruger, så er der en bruger som er ansvar-↲
lig for ┆b0┆HELE BRUGER TESTEN.↲
↲
Hvis der er flere brugere til at udføre test, så skal arbejdet plan-↲
lægges, så de deltagende brugere ved HVAD , HVORNÅR ,og HVORDAN de↲
skal udføre deres del af testen.↲

════════════════════════════════════════════════════════════════════════
↓
┆a1┆13. HVORDAN KONTROLLERER MAN TESTEN ?↲
↲
Hvis der er fundet fejl under en test, så skal den skrives ned, og↲
efter rettelse af system eller program så skal det ved ny test sikres↲
at fejlen er rettet.↲
↲
Udskrifter fra registre kan bevise at data er kommet er rigtigt ind,↲
og ved ændring kan en ny udskrift bevise at ændringen er registreret↲
ok.↲
↲
Beregning af beløb kan ved små test data mængder beregnes manuelt på↲
forhånd, så ved udskrift (skærm eller liste) kan beløb eller beløbene↲
hurtigt kontrolleres. Differencer mellem manuelt beregnet og program↲
kan i de fleste tilfælde hurtigt spores, så fejlen kan rettes.↲
↲
Ved selekterede udskrifter, hvor der for eksempel kun er bestilt↲
debitorer med saldo forskellig fra 0 (nul) skal med på udskriften,↲
kan bruger ved hjælp af sine nedskrevne test data kontrollere at de↲
rigtige debitorer er med på listen, og at debitorer med saldo ↲
= 0 (nul) IKKE er med på listen.↲
↲
↲
┆a1┆14. HVILKEN DOKUMENTATIONS FORM SKAL ANVENDES ?↲
↲
I det omfang det er muligt bør test resultater være skrevet ud på↲
papir, enten som "hard-copy" (tilkoblet printer til en skærm) eller↲
i liste-form.↲
↲
Disse resultater bør opbevares i en testbog hos den ansvarlige↲
test-bruger. Denne test bog kan "genbruges", også i tilfælde af↲
rettelser i gamle systemer, såfremt de oprindelige test data har været↲
anvendt.↲
↲
↲
┆a1┆15. HVEM GODKENDER TESTEN ?↲
↲
Den bruger, som udfører den enkelte test, skal i første omgang god-↲
kende testen.↲
↲
Dernæst skal den ansvarlige test-bruger også godkende testen, så↲
vedkommende er klar over, hvor langt man er nået i test-planen.↲
↲
↲
┆a1┆16. ERFARINGER.↲
↲
Det vil være nyttigt for test til kommende systemer, at man undervejs↲
i testen nedskriver de erfaringer, man har fået i den aktuelle test.↲
↲
Det kan være test data, som man i starten ikke syntes var nødvendigt↲
at medtage, men som senere viste sig at være af betydning.↲
↲
Eller det kan være at man næste gang vil planlægge testen på en måde,↲
eller at opfølgningen af testen skulle være udført anderledes.↲
↲

════════════════════════════════════════════════════════════════════════
↓
┆1a┆┆1a┆den måde.↲
↲

════════════════════════════════════════════════════════════════════════
↓
↓
┆1a┆┆8a┆┆d8┆↓
↓
┆1a┆┆d8┆↓
↓
┆1a┆↓

════════════════════════════════════════════════════════════════════════
↓
↓
┆1a┆orekomme at