{"id":408,"date":"2015-05-23T10:10:03","date_gmt":"2015-05-23T08:10:03","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=408"},"modified":"2015-07-04T14:37:16","modified_gmt":"2015-07-04T12:37:16","slug":"testautomatisierung","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/testautomatisierung\/","title":{"rendered":"Testautomatisierung"},"content":{"rendered":"

Hallo Spa\u00df-Coder,<\/p>\n

habt ihr auch schon mal eine \u00c4nderung an eurem Code vorgenommen, alles gepr\u00fcft und hinterher stellte sich doch heraus, dass noch ein Fehler drin war? War dieser Fehler vielleicht in der Vergangenheit bereits einmal aufgetreten und ist nun wieder passiert? Oder seid ihr einmal in der Situation gewesen eine Anwendung zu pr\u00fcfen und habt euch dar\u00fcber ge\u00e4rgert, dass ihr bei jeder \u00c4nderung wieder von Vorne anfangen m\u00fcsst?<\/p>\n

In solchen F\u00e4llen hilft es uns, unsere Tests zu automatisieren.<\/p>\n

 <\/p>\n

Warum Testautomatisierung?<\/h2>\n

Stellt euch vor, wir sollen am unten abgebildeten System eine \u00c4nderung vornehmen. Das Verhalten soll sich also \u00e4ndern, wenn an dem 4. gr\u00fcnen Drehregler der 5. Reihe von rechts gedreht wird. Wo liegt nun das Problem?<\/p>\n

\"MixingDesk\"<\/a><\/p>\n

Nun, wir m\u00fcssen nun im Grunde jede Kombination der Drehregler pr\u00fcfen. Unser ge\u00e4nderter Drehregler ganz links, Mittelstellung und ganz rechts pr\u00fcft zun\u00e4chst, ob unsere gerade implementierte \u00c4nderung das gew\u00fcnschte Verhalten aufweist. Aber wie stellen wir sicher, das unser ge\u00e4nderter Drehregler auch dann noch funktioniert, wenn wir den schwarzen Drehregler hinten rechts nach ganz links drehen? Oder der zweite Schalter in der vorderen ersten Reihe gedr\u00fcckt ist…oder nicht gedr\u00fcckt ist?<\/p>\n

Wer von euch hat Lust, all diese Kombinationen manuell zu \u00fcberpr\u00fcfen? Keiner? Das \u00fcberrascht uns nicht.<\/p>\n

Schaut euch mal das Bild an. Nun denkt an euer aktuelles Software-Projekt. Ist euer Software-Projekt wesentlich weniger Komplex als das abgebildete System? Habt ihr nicht auch ganz verschiedene Kombinationsm\u00f6glichkeiten von Einstellungen, bei denen ihr nicht absch\u00e4tzen k\u00f6nne, welche Auswirkungen sie auf den Rest eures Systems haben?<\/p>\n

Wenn wir also ein solches System haben, bei dem wir bei jeder \u00c4nderung immer wieder unz\u00e4hlige Kombinationen testen und pr\u00fcfen m\u00fcssen, wie w\u00fcrden wir uns w\u00fcnschen, wie das abl\u00e4uft?<\/p>\n

Vielleicht so:<\/p>\n

\"RollerCoaster\"<\/a><\/p>\n

Nach einer \u00c4nderung an unserem System dr\u00fccken wir auf einen Knopf und ab geht die Wilde Fahrt. Das System l\u00e4uft los und testet sich selbst und das immer und immer wieder. Sobald wir auf den Knopf dr\u00fccken, testet sich das System und wir erhalten unmittelbar eine R\u00fcckmeldung dar\u00fcber, ob das System noch funktioniert oder nicht.<\/p>\n

Noch besser w\u00e4re f\u00fcr unsere Software-Systeme, dass sie sich automatisch pr\u00fcfen, wir also nicht einmal mehr auf den Knopf dr\u00fccken m\u00fcssen. Aber das ist f\u00fcr uns Software-Entwickler ja die leichteste \u00dcbung. Bei dem abgebildeten System ist das Vorgehen vielleicht nicht die beste aller Ideen \ud83d\ude09<\/p>\n

 <\/p>\n

Machen wir noch ein anderes Beispiel. Nehmen wir an, wir haben das unten abgebildete System f\u00fcr einen unserer Kunden entwickelt. Es funktioniert seit ein paar Monaten. Durch eine neue Attraktion in der N\u00e4he hat sich aber das Verkehrsaufkommen ge\u00e4ndert und in einer der von unserem System gesteuerten Zufahrtsstra\u00dfen kommt es seit ein paar Tagen immer wieder zu Staus. Unser Kunde m\u00f6chte nun, dass wir die Steuerung so \u00e4ndern, dass die Staus nicht mehr vorkommen.<\/p>\n

\"ComplexTrafficLight\"<\/a><\/p>\n

Was machen wir also? Wir ermitteln die Ursache f\u00fcr die Staus und ver\u00e4ndern das Verhalten unseres Systems so, dass diese in Zukunft nicht mehr vorkommen. Aber was nun? K\u00f6nnen wir mit Gewissheit sagen, dass unsere \u00c4nderung nicht Staus an anderen Stellen des Systems verursacht? K\u00f6nnen wir sicherstellen, dass das System als Ganzes noch funktioniert?<\/p>\n

Der Kunde m\u00f6chte schnell eine L\u00f6sung haben. Aber wenn wir unsere \u00c4nderung durchgef\u00fchrt haben und das neue Verhalten an unsere Kunden ausliefern, darf es auf gar keinen Fall so enden:<\/p>\n

\"Pierre<\/a>

Pierre Vivant’s sculpture, Traffic Light Tree in the Docklands, London<\/p><\/div>\n

Wir m\u00fcssen sicherstellen, dass das System weiterhin genauso funktioniert wie vorher, aber das ge\u00e4nderte Verhalten f\u00fcr die eine Zufahrtsstra\u00dfe aufweist. Wir wollen aber – genauso wie im obigen Beispiel – nicht alle Kombinationen des Systems manuell pr\u00fcfen. Auch w\u00e4re es nicht im Sinne unseres Kunden, wenn wir die \u00c4nderung erst einmal wochenlang einem manuellen Test unterziehen, bevor er die \u00c4nderung bekommt. Bis dahin werden viele Autofahrer ver\u00e4rgert sein, vielleicht wird es sogar Verkehrsunf\u00e4lle geben. Es ist also wichtig, dass unsere \u00c4nderung schnell zum Kunden kommt. So stellen wir den Kunden zufrieden und erh\u00f6hen damit auch die Wirtschaftlichkeit unserer Leistung.<\/p>\n

Mit unseren Software-Systemen ist das genauso. Der Kunde m\u00f6chte ein ge\u00e4ndertes Verhalten. Wir implementieren es und m\u00fcssen sicherstellen, dass<\/p>\n

    \n
  1. unsere \u00c4nderung so funktioniert, wie der Kunde sich das vorstellt<\/li>\n
  2. unsere \u00c4nderung an einem Teil des Systems nicht andere Teile negativ beeinflusst<\/li>\n
  3. wir unsere \u00c4nderung wirtschaftlich profitabel umsetzen und<\/strong> pr\u00fcfen<\/li>\n<\/ol>\n

     <\/p>\n

    Arten der Testautomatisierung<\/h2>\n

    Es gibt verschiedene Arten von Tests, auf die wir in folgenden Artikeln noch weiter eingehen werden hier zun\u00e4chst eine kurze \u00dcbersicht, was euch zum Thema noch erwartet:<\/p>\n