Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Programmering i Java versjon januar 2005 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else.

Liknende presentasjoner


Presentasjon om: "Programmering i Java versjon januar 2005 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else."— Utskrift av presentasjonen:

1 Programmering i Java http://www.tisip.no/boker/java/ versjon januar 2005 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22 Å teste programmer Refleksjonside 2-3 Enhetstesting med JUnitside 4-7 Funksjonsbrudd og testfeilside 8 Systemtestingside 9-10 Det reserverte ordet assertside 11 Regresjonstestingside 12 Akseptansetestingside 13 Svartboks- og hvitbokstestingside 14

2 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 2 Refleksjon •Refleksjon er at et Java-program “ser seg i speilet” og gjør operasjoner hvor programmets egne metoder, variabler, konstruktører, tabeller og klasser inngår som eksplisitte data. •Et objekt av klassen Class beskriver en klasse. –Kan få laget et Class-objekt ut fra et bestemt objekt Class minKlasse = mittObjekt.getClass(); –eller fra en klasse eller et interface try { Class minKlasse = Class.forName(“MittInterface“); Class annenKlasse = Class.forName(“MinKlasse“); Class stringKlasse = Class.forName(“java.lang.String“); } catch (ClassNotFoundException e) { System.out.println(“Klassenavn ikke funnet: “ +e); } –eller fra en primitiv datatype Class doubleKlasse = Double.TYPE ;

3 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 3 Eksempel på refleksjon import java.lang.reflect.*; class MetodeLister { public void listMetoder() { String klasseNavn = "java.lang.String"; try { Class stringKlasse = Class.forName(klasseNavn); Method[] metoder = stringKlasse.getMethods(); System.out.println("Metoder i klassen " + klasseNavn + ":"); for (int i = 0 ; i < metoder.length ; i++) { System.out.println(metoder[i]); } catch (ClassNotFoundException e) { System.out.println("Klassenavn ikke funnet: " + e); } class RefleksjonsTest { public static void main(String[] args) { MetodeLister lister = new MetodeLister(); lister.listMetoder(); } Utskrift: Metoder i klassen String: public int java.lang.String.hashCode() public int java.lang.String.compareTo(java.lang.Object) public int java.lang.String.compareTo(java.lang.String) public boolean java.lang.String.equals(java.lang.Object) public java.lang.String java.lang.String.toString() public int java.lang.String.length() public char java.lang.String.charAt(int) public void java.lang.String.getChars(int,int,char[],int)... med mere, samtlige offentlige metoder i String, inklusive de arvet fra Object, listes ut.

4 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 4 Enhetstesting med JUnit •”Testing shows the presence of bugs, not their absence.” (Dijkstra) •Rammeverk for testing, kalt JUnit. Lastes ned fra www.junit.org •Enhetstest: Test som skal verifisere at en liten del (f.eks. en klasse) av et program virker som det skal. •JUnit hjelper oss å organisere testingen. •Lager subklasse til TestCase, bruker en del metoder som arves derfra. •Testing er metodekall. Grupperer disse metodekallene logisk. Legger hver gruppe i en metode med navn som begynner på ”test”. •Lager setUp() slik at den ”nullstiller” testobjektet før en gruppe med tester er kjørt. Definerer dermed pre-betingelsene for testing. ”JUnit fixture” •Lager tearDown() slik at den rydder opp (lukker filer, kopler ned nettverksforbindelser, etc.) etter at en gruppe med tester er kjørt. Definerer dermed post-betingelsene for testing. Vis programliste 22.2 side 809-811.

5 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 5 TestSuiter •Metoden suite() skal definere en testsuite, det vil si en mengde testmetoder. Her består testsuiten av alle testmetodene. public static Test suite() { return new TestSuite(JUnitNavneListeTest.class); } public static void main(String[] args) { junit.textui.TestRunner.run(suite()); // tekstlig brukergrensesnitt } klasselitteral lader testsuiten med alle offentlige metoder i klassen JUnitNavneListeTest som har navn som begynner på ”test”

6 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 6 Eksempel på testkjøring som går i feil •Testsuiten vår er avhengig av at toString()-netoden i klassen Navneliste ikke forandres. •Forandrer vi toString()-metoden må vi endre kallene på assertTrue() og assertFalse(). •Bør ha så få slike avhengigheter mellom testobjekt og testsuite som mulig. •Dersom vi endrer toString() uten å endre testsuiten, får vi feilutskrift:.F..F Time: 0,111 There were 2 failures: 1) testInnsetting(JUnitNavneListeTest)junit.framework. AsertionFailedError at JUnitNavneListeTest.testInnsetting(JUnitNavneListeTest.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at JUnitNavneListeTest.main(JUnitNavneListeTest.java:100) 2) testSletting(JUnitNavneListeTest)junit.framework.AssertionFailedError at JUnitNavneListeTest.testSletting(JUnitNavneListeTest. java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at.... FAILURES!!! Tests run: 3, Failures: 2, Errors: 0

7 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 7 JUnit har også et grafisk brukergrensesnitt

8 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 8 Funksjonsbrudd og testfeil •Funksjonsbrudd (engelsk: failure) –forventet feil som vi har tatt høyde for –prøves med assertTrue() •Testfeil (engelsk: error) –ikke planlagt feil og helt uventet •uhåndterte unntak •en sjelden gang en feil i JVM Dette fører også til at testen ikke får OK –testen er inkonklusiv: Kan ikke si noe om det man skulle teste, for en feil med ukjent årsak har forpurret testkjøringen. Gjør oppgavene side 814.

9 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 9 Systemtesting Eksempel, skal teste et databasesystem mange grensesnitt mot databasesystemet, systemtesting må dekke alle grensesnittene

10 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 10 Systemtesting, forts •Hva kreves av et solid rammeverk for systemtesting? –Praktisk dersom alle grensesnittene kan nås via det samme programmeringsspråket –Loggfil på standardisert format –Tidsangivelser for f.eks. oppstart bør være ikke-eksplisitte –Bør tilby parallelle operasjoner •Å teste et stort system er en formidabel oppgave •Fremdeles langt fra å bevise at programmet er riktig, det man gjør er å avdekke feil •Ofte leveres liste over ”kjente feil” sammen med systemet –ikke-kritiske feil –alvorlige feil –kritiske feil Gjør oppgaven side 818.

11 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 11 Det reserverte ordet assert •assert = bekrefte, nytt reservert ord i versjon 1.4 av J2SE •Eksempel: String[] langTabell = new String[20000]; assert langTabell != null : “Alvorlig feil: kunne ikke deklarere tabell.“; •Alvorlig feil dersom assert-uttrykket er false, AssertionError-objekt kastes •Kompilering fra kommandolinjen –>javac MinKlasse.java •Kjøring –>java -ea MinKlasse

12 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 12 Regresjonstesting •Testing i vedlikeholdsfasen av et programsystem •Regresjonstesting (regresjon = vende tilbake til det kjente) •Eksempel –programsystemet Gamma testes med 10 systemtester –mange utviklere arbeider fortløpende med Gamma –de 10 systemtestene kjøres hver gang en endring er gjort –ingen sovepute, en må alltid vurdere om det er tilstrekkelig å kjøre de 10 systemtestene, eller om andre tester må kjøres i tillegg •Målet med regresjonstestingen er å finne ut om endringen har introdusert nye feil •Kan med fordel automatiseres –kjøres om natta når det ellers er liten belastning

13 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 13 Akseptansetesting •Testing utført av mottakerne av et programsystem •Mål: Å verifisere at produktet oppfyller de funksjonelle krav som er spesifisert. •Består gjerne av brukeroperasjoner man har forventet seg å kunne gjøre •Bærer i liten grad preg av kjennskap til selve implementasjonen av produktet. •I en kommersiell situasjon vil det være rimelig med skriftlige godkjenninger av produktet på bakgrunn av akseptansetestingen.

14 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else Lervik og Vegard B. Havdal, 3.utgave, Stiftelsen TISIP og Gyldendal Akademisk 2004. Kapittel 22, side 14 Svartboks- og hvitbokstesting •Strategier for testing •Betrakter testobjektet som en boks •Svart boks –vet ingenting om hvordan boksen ser ut inni og kan kun støtte oss på testobjektets grensesnitt i testutføringen. Dytter data inn og får data ut. –systemtesting (?) –akseptansetesting •Hvit boks –vet hvordan boksen ser ut inni og legger opp testene spesifikt ut fra dette –pass på at brukerens krav ikke kommer ut av syne –enhetstesting •Testingeniørens rolle –systemtesting, svart boks –nært samarbeid med utviklere –  ”grå boks”


Laste ned ppt "Programmering i Java versjon januar 2005 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else."

Liknende presentasjoner


Annonser fra Google