Marshalling-Funktion<\/a> aufzurufen, h\u00e4tte dieses Problem vor uns verborgen.<\/p>\n\n\n\nEin weiteres unerwartetes Problem betraf eine \u00c4nderung an der Golang-DNS-Bibliothek, die unsere Produktionsumgebung komplett lahmgelegt h\u00e4tte, wenn unsere funktionale Test-Suite nicht gewesen w\u00e4re\u00a0\u2013 und ja, wir f\u00fchren eine DNS-Mock-Implementierung f\u00fcr unsere Tests aus.<\/p>\n\n\n\n
Erstellen von funktionalen Tests zur Suche nach Edge-Cases und zur Fehlerdiagnose<\/h2>\n\n\n\n Okay, sobald wir also unsere Umgebung modelliert haben, sollten Sie als Erstes eine funktionale Test-Suite erstellen. Eine funktionale Test-Suite ist ein Container, der eine Reihe von Tests enth\u00e4lt, die bei der Ausf\u00fchrung und Berichterstattung von Testausf\u00fchrungsstatus helfen sollen.<\/b> Sie k\u00f6nnen Ihren Suites Testf\u00e4lle und Testpl\u00e4ne hinzuf\u00fcgen, um eine Vielzahl von Szenarien und Edge-Cases abzudecken. Je besser Ihre Suite ist, desto einfacher wird es, wenn Sie versuchen, ein Problem zu diagnostizieren.<\/p>\n\n\n\n
Wenn das Problem, das Sie l\u00f6sen m\u00f6chten, als funktionaler Test existiert, k\u00f6nnen Sie die Werte im Test einfach (und schnell) durch die genauen Werte aus der Produktion ersetzen.\u00a0 Allein die lokale Reproduktion des Problems durch die Wiederherstellung der exakten Daten aus der Produktion kann zur L\u00f6sung f\u00fchren. <\/b>Wenn Sie es einfach gemacht haben, Daten aus der Produktion zu importieren oder zu simulieren, kann dies ein unsch\u00e4tzbar wertvolles Werkzeug in Ihrem Arsenal sein.<\/p>\n\n\n\n
Wenn Sie keinen bestehenden funktionalen Test haben, der das Szenario abdeckt (was h\u00e4ufig vorkommt, da Nutzer oft nervige<\/i>, \u00e4hm … einzigartige und unvorhergesehene Wege finden, Ihr System zu nutzen), m\u00fcssen Sie diesen erstellen.<\/p>\n\n\n\nSelbstportr\u00e4t einer frustrierten Fachkraft der Entwicklung, die keine funktionalen Tests erstellt hat.<\/em><\/figcaption><\/figure>\n\n\n\nEin Teil davon, die Weichen auf Erfolg zu stellen, besteht darin, funktionale Tests durchzuf\u00fchren oder die F\u00e4higkeit zu besitzen, schnell einen funktionalen Test zu erstellen. Unit-Tests (das Testen des kleinsten Code-Teils, der in einem System logisch isoliert werden kann) k\u00f6nnen n\u00fctzlich sein, sobald Sie das Problem eingegrenzt haben. Ein funktionaler Test erm\u00f6glicht es Ihnen, ein grobes Bild Ihres Dienstes zu zeichnen und aus der Perspektive des Kunden zu verstehen, wie der Dienst in einem bestimmten Szenario funktioniert. Beim Debugging gilt:<\/b> Tests des Produkts sind immer wichtiger als das Testen des Codes.<\/b><\/p>\n\n\n \r\n\r\n
Erstellen Sie automatisierte funktionale Tests in Ihren Suites, die Testf\u00e4lle automatisch ausf\u00fchren. Nutzen Sie dies als Teil Ihres QA-Programms, um Bugs aufzudecken und zu beheben, bevor Ihre Anwendung in die Produktion geht.<\/div>\r\n <\/div>\r\n\n\n\n
Warum Sie manuelle Tests vermeiden sollten und was stattdessen zu tun ist<\/h2>\n\n\n\n Das Gegenteil von funktionalen Tests sind manuelle Tests. Manuelles Testen ist eine Art von Softwaretest, bei dem Testf\u00e4lle manuell von einer testenden Person ausgef\u00fchrt werden, ohne automatisierte Tools zu verwenden. Sie sollten sich immer auf funktionale Tests statt auf manuelle Tests konzentrieren, da ein manueller Test fehleranf\u00e4llig und nicht reproduzierbar ist.<\/p>\n\n\n\n
Viele in der Programmierung machen den Fehler, einen Dienst lokal auszuf\u00fchren und Endpunkte manuell zu testen, um Probleme zu diagnostizieren. Da wir dies viele Jahre lang getan haben, k\u00f6nnen wir Ihnen aus erster Hand gar nicht sagen, wie oft wir ein Problem reproduziert haben, ohne genau zu wissen, wie wir das gemacht haben. Das hat bei dem Versuch, unsere Schritte zur\u00fcckzuverfolgen, schon oft dazu gef\u00fchrt, dass wir am liebsten den Tisch umgeworfen h\u00e4tten.<\/p>\n\n\n\n
Debugging-Sitzungen dauern oft Stunden bis Tage, und bei manuellen Tests bleiben alle ausprobierten Szenarien undokumentiert und verschwimmen miteinander. Wenn jedoch all diese versuchten Szenarien als funktionale Tests<\/b> geschrieben werden, kann jedes Szenario Teil der Historie der Debugging-Sitzung werden.<\/p>\n\n\n \r\n\r\n
Wenn Sie funktionale Tests f\u00fcr neue Szenarien schreiben, k\u00f6nnen diese Teil der Regressions-Suite von Tests werden, die w\u00e4hrend der CI ausgef\u00fchrt werden.<\/div>\r\n <\/div>\r\n\n\n\n
Es gibt ein Geheimnis bei funktionalen Tests. Das Schreiben funktionaler Tests zur Diagnose von Problemen ist eine Schl\u00fcsselstrategie, um die Zeit bis zur Fehlerbehebung zu minimieren. Diese Diagnosemethode funktioniert jedoch nicht, wenn das Schreiben des funktionalen Tests schwierig ist. Die L\u00f6sung: Vereinfachen Sie die Dinge vom ersten Schritt an.<\/p>\n\n\n\n
Erstellen Sie eine Suite von Hilfsfunktionen und einfachen Assertions.<\/b> Das Ziel ist es, Aktionen wie Retry-Schleifen und das Importieren von Daten-Suites SEHR einfach zu machen. Diese Hilfsfunktionen sollten zu den ersten Tools geh\u00f6ren, die beim initialen Schreiben der Software erstellt werden, um sp\u00e4ter als Support f\u00fcr neue funktionale Tests zu dienen.<\/p>\n\n\n\nEin Beispiel: Wie wir das bei Mailgun gemacht haben<\/h3>\n\n\n\n
Die prim\u00e4re \/messages-API bei Mailgun wird von einem Dienst verarbeitet, den wir Influx nennen. Dieser Dienst verarbeitet sowohl HTTP- als auch SMTP-Nachrichten in unserem System und kommuniziert mit fast jedem anderen Dienst in unserer Suite f\u00fcr den Nachrichtenversand.<\/p>\n\n\n\n
Infolgedessen haben wir stark in unsere funktionale Test-Suite investiert und unsere Produktionsumgebung f\u00fcr diesen sehr \u00f6ffentlichen Teil unseres Dienstkatalogs im Code modelliert. Wir haben \u00fcber 700 Tests erstellt. Die meisten davon sind funktional und auf einem lokalen Rechner in etwa sechs Minuten abgeschlossen.<\/p>\n\n\n\n
Viele dieser Tests kamen w\u00e4hrend Debugging- oder Diagnosesitzungen hinzu und wurden dann in unsere Test-Suite aufgenommen. Wenn ein neues Szenario ben\u00f6tigt wird, wird es der funktionalen Suite hinzugef\u00fcgt und bildet einen Schutz vor zuk\u00fcnftigen Regressionen.<\/p>\n\n\n\n
Abschlie\u00dfende Gedanken<\/h2>\n\n\n\n Die wahren Kosten der Softwareentwicklung liegen in der Wartung und Diagnose von Code. Deshalb ist es die zus\u00e4tzliche Zeit und das Geld wert, die Weichen f\u00fcr den Erfolg zu stellen, indem Sie eine Suite von Tools erstellen, mit denen Sie die L\u00f6sungszeit verk\u00fcrzen k\u00f6nnen.<\/p>\n\n\n\n
Diese fr\u00fche Investition wird sich umso mehr auszahlen, je l\u00e4nger das Projekt andauert.<\/p>\n\n\n\n
Hat Ihnen unser Ansatz zum Finden und Diagnostizieren von Software-Bugs gefallen? Wenn Sie mehr Inhalte wie diesen m\u00f6chten, vergessen Sie nicht, unseren Newsletter zu abonnieren.<\/p>\n\n\n