Verteilte Softwaresysteme bringen ein sehr komplexes Verhalten unter echten Einsatzbedingungen mit sich, meist resultiert dies auch in sehr komplexen Fehlerzuständen, die durch den Betrieb unter widrigen Netzwerkbedingungen wie beispielsweise hohen Latenzen und zunehmenden Paketverlusten entstehen. Diese Fehlerzustände können mit herkömmlichen Softwaretestverfahren wie Unit- und Integrationstests nicht mehr hinreichend provoziert, getestet und verifiziert werden. Mit der Methode des Chaos-Engineerings werden komplexe Chaos-Szenarien entworfen, die es ermöglichen dieses unbekannte Verhalten der Software in Grenzfällen strukturiert zu entdecken. Am Beispiel einer verteilten Software, die bereits seit über 10 Jahren am Deutschen Zentrum für Luft- und Raumfahrt (DLR) entwickelt wird, werden Chaos-Engineering-Methoden angewandt und sowohl konzeptuell in existierende Softwaretestverfahren eingeordnet als auch praktisch in einer Experimental-Cloud-Umgebung erprobt. Innerhalb eines Experteninterviews mit den RCE-Entwicklern wird ein Chaos-Szenario entworfen, in der die Robustheit der Software mit Chaos-Experimenten auf die Probe gestellt wird. Aufbauend auf einem Softwareprojekt zur automatischen Erstellung von RCE-Testnetzwerken, wird eine Softwarelösung entwickelt, die eine automatische Ausführung von Chaos-Szenarien innerhalb der Experimental-Cloud-Umgebung ermöglicht. Anschließend wird das aus den Experteninterviews resultierende Chaos-Szenario in der Praxis durchgeführt. Abschließend werden die Erkenntnisse aus der Ausführung des Chaos- Szenarios vorgestellt und weiterführende Fragestellungen und Arbeiten aufgezeigt:1 Einleitung 2 Grundlagen 2.1 Softwareentwicklung und Testverfahren 2.2 Verteilte Software 2.3 Containerorchestrierung 2.4 Chaos Engineering 3 Betrachtetes System 3.1 Remote Component Environment 3.2 Testing von RCE Releases 3.3 Methode Experteninterview 3.4 Fragestellungen entwerfen 3.5 Resultate aus Interview 3.6 Integration von Chaos-Engineering 4 Konzepte des Chaos-Engineering am Beispiel 4.1 Ausgangssituation 4.1.1 Systemumgebung 4.1.2 Automatisierte Erstellung von Testnetzwerken 4.1.3 Microservices 4.1.4 Systemarchitektur 4.1.5 Netzwerkbeschreibung 4.2 Anforderungen an die zu entwickelnde Software 4.3 Erweiterung des vorhandenen Gesamtsystems 4.3.1 Chaos Mesh 4.4 Chaos-Operator Microservice 4.4.1 Erweiterung der Systemarchitektur 4.4.2 Erweiterung der Schnittstellen 4.4.3 Beschreibung eines Chaos-Experiments 4.4.4 Probes 4.4.5 Ablaufsteuerung 5 Evaluierung und Diskussion 5.1 Geplantes Chaos-Szenario 5.1.1 JSON Beschreibung eines Chaos-Szenarios 5.2 Durchführung des entworfenen Chaos-Szenarios 5.2.1 Ausführung mit Chaos-Sequencer 5.2.2 Validierung 5.3 Resultate 6 Fazit Literaturverzeichnis Abbildungsverzeichnis Listings

Thesis (MPhil)--University of Stellenbosch, 2004. / ENGLISH ABSTRACT: The effort to achieve quality is the largest component of software cost. Software testing is costly - ranging from 50% to 80% of the cost of producing a first working version. It is resource intensive and an intensely time consuming activity in the overall Systems Development Life Cycle (SDLC) and hence could arguably be the most important phase of the process. Software testing is pervasive. It starts at the initiation of a product with nonexecution type testing and continues to the retirement of the product life cycle beyond the post-implementation phase. Software testing is the currency of quality delivery. To understand testing and to improve testing practice, it is essential to see the software testing process in its broadest terms – as the means by which people, methodology, tools, measurement and leadership are integrated to test a software product. A knowledge approach recognises knowledge management (KM) enablers such as leadership, culture, technology and measurements that act in a dynamic relationship with KM processes, namely, creating, identifying, collecting, adapting, organizing, applying, and sharing. Enabling a knowledge approach is a worthy goal to encourage sharing, blending of experiences, discipline and expertise to achieve improvements in quality and adding value to the software testing process. This research was developed to establish whether specific knowledge such as domain subject matter or business expertise, application or technical skills, software testing competency, and whether the interaction of the testing team influences the degree of quality in the delivery of the application under test, or if one is the dominant critical knowledge area within software testing. This research also set out to establish whether there are personal or situational factors that will predispose the test engineer to knowledge sharing, again, with the view of using these factors to increase the quality and success of the ‘testing phase’ of the SDLC. KM, although relatively youthful, is entering its fourth generation with evidence of two paradigms emerging - that of mainstream thinking and that of the complex adaptive system theory. This research uses pertinent and relevant extracts from both paradigms appropriate to gain quality/success in software testing. / AFRIKAANSE OPSOMMING: By verre die grootste komponent van sagte ware koste is dié verwant aan kwaliteitsversekering. Toetsing van sagte ware is koste intensief en verteenwoordig tussen 50% en 80% van die kostes om ‘n beta weergawe vry te stel. Die toetsing van sagte ware is nie alleenlik duursaam nie, maar ook arbeidintensief en ‘n tydrowende aktiwteit in die sagte ware ontwikkelings lewensiklus en kan derhalwe gereken word as die mees belangrike fase. Toetsing is deurdringend – dit begin by die inisiëring van ‘n produk deur middel van nie-uitvoerende tipe toetsing en eindig by die voleinding van die produklewensiklus na die implementeringsfase. Sagte ware toetsing word beskou as die geldwaarde van kwalitatiewe aflewering. Om toetsing ten volle te begryp en die toepassing daarvan te verbeter, is dit noodsaaklik om die toetsproses holisties te beskou – as die medium en mate waartoe mense, metodologie, tegnieke, meting en leierskap integreer om ‘n sagte ware produk te toets. ‘n Benadering gekenmerk deur kennis erken die dinamiese verhouding waarbinne bestuurselemente van kundigheid, soos leierskap, kultuur, tegnologie en maatstawwe reageer en korrespondeer met prosesse van kundigheid, naamlik skep, identifiseer, versamel, aanpas, organiseer, toepas en meedeel. Die fasilitering van ‘n benadering gekenmerk deur kennis is ‘n waardige doelwit om meedeling, vermenging van ervaringe, dissipline en kundigheid aan te moedig ten einde kwaliteit te verbeter en waarde toe te voeg tot die proses van safte ware toetsing. Die doel van hierdie navorsing is om te bepaal of die kennis van ‘n spesifieke onderwerp, besigheidskundigheid, tegniese vaardighede of die toepassing daarvan, kundigheid van sagte ware toetsing, en/of die interaksie van die toetsspan die mate van kwaliteit beïnvloed, of een van voorgenoemde die dominante kritieke area van kennis is binne die konteks van sagte ware toetsing. Die navorsing beoog ook om te bepaal of daar persoonlike of situasiegebonde fakfore bestaan wat die toetstegnikus vooropstel om kennis te deel, weer eens, met die oog om deur middel van hierdie faktore kwaliteit te verbeter en die toetsfase binne die sagte ware ontwikkelingsiklus suksesvol af te lewer. Ten spyte van die relatiewe jeudgigheid van die bestuur van kennis, betree dit die vierde generasie waaruit twee denkwyses na vore kom – dié van hoofstroom denke en dié van ingewikkelde aangepaste stelselsdenke. Hierdie navorsing illustreer belangrike en toepaslike insette van beide denkwyses wat geskik is vir meedeling van kennis en vir die bereiking van verbeterde kwaliteit / sukses in sagte ware toetsing.