Zunächst möchte ich sagen, dass alles, was ich tue, SQL Server ist. Dies sind also die Beispiele, die ich gebe. Im Allgemeinen gilt dies jedoch für jede Art von Code, unabhängig vom System.
Beginnen wir damit, dies ein wenig aufzuschlüsseln.
Upgrades
Sie haben ein System und sind dabei, einige oder alle davon zu aktualisieren. Aktualisieren Sie beispielsweise eine Instanz von SQL Server 2012 auf 2014. Zu diesem Zeitpunkt ist das Testen von wesentlicher Bedeutung. Leider wird es wahrscheinlich nicht möglich sein, jeden Teil einer kleinen Anwendung zu testen. Zu diesem Zeitpunkt würde ich einen "funktionierenden" Test durchführen. Funktioniert das Basissystem? Führen Sie die allgemeinen Aufgaben durch, bis sie abgeschlossen sind. Testen Sie nicht jede Option, nur den Hauptpfad.
Bei einem SQL Server-Upgrade sind einige Lesevorgänge erforderlich . Grundsätzlich möchten Sie den Backward CompatibilityEintrag für die neue Version lesen ( hier ist der für 2014 ) und sicherstellen, dass Sie nichts in einer der Listen haben (aktuelle Änderungen, Verhaltensänderungen usw.).
Anwendungscode
Hier sehen wir uns neuen / sich ändernden Anwendungscode an (weil natürlich alles, was existiert, bereits getestet wurde, oder?). In diesem Fall sollte alles getestet werden. Sie sollten Testfälle im Voraus einrichten und mindestens die Mehrzahl der betroffenen Funktionen durchlaufen. An dieser Stelle sollte vorzugsweise auch jemand anderes eine ähnliche Prüfung durchführen. Dieser Code wird wahrscheinlich für längere Zeit existieren und von einer großen Anzahl von Leuten verwendet werden. Sie möchten sicherstellen, dass es funktioniert und gut funktioniert.
Eines der Dinge, die dabei wirklich helfen können, ist die Generierung eines Satzes, der unit testsleicht wiederholbar ist. Steve Jones empfiehlt , tSQLt zum Testen Ihres TSQL-Codes zu verwenden ( leider nur für SQL Server). Auf diese Weise können Sie jedoch schnell eine Reihe festgelegter Tests durchführen, was beim Regressionstest (z. B. vor einem Upgrade) sehr hilfreich ist.
Funktionen / Konfigurationen
Noch mehr als Änderungen des Anwendungscodes möchten Sie neue Funktionen und Konfigurationsänderungen gründlich testen. Wenn Sie sich zum Beispiel dafür entscheiden, mit Columnstore-Indizes zu arbeitenZum ersten Mal müssen Sie jeden Code testen, der die betroffenen Tabellen berührt. Verwenden Sie die von Ihnen generierten Komponententests, um Ihre Anwendung zu testen. Diese Funktionen sind wahrscheinlich neu für Sie (und möglicherweise neu in der Plattform) und werden wahrscheinlich einige Fallstricke haben, die Sie nicht erwartet haben. Bei Konfigurationsänderungen sprechen Sie von etwas, das Ihr gesamtes System möglicherweise erheblich beeinträchtigen kann. Die Faustregel lautet, zu testen und sorgfältig zu testen. Es gibt einige Änderungen, die Sie erst dann wirklich sehen, wenn Sie in ein aktives System (möglicherweise nur Ihr Produktionssystem) eintreten. Dies ist jedoch keine Entschuldigung, sie nicht zuerst in einer Testumgebung auszuprobieren.
Ad-hoc-Anfragen, die auf Benutzerdaten verweisen / diese beeinflussen
Wenn Sie Code haben, der sich auf Ihre Benutzerdaten auswirkt, müssen Sie ihn im Allgemeinen testen, auch und vielleicht gerade, weil er ist Ad Hoc. Nun, wenn Sie immer und immer wieder denselben Code mit unterschiedlichen Parametern ausführen, müssen Sie sich wahrscheinlich nicht jedes Mal Gedanken über das Testen machen.
Beispielsweise müssen Sie vierteljährlich eine oder mehrere Anzeigen aus der AdList-Tabelle löschen.
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')
Zu diesem Zeitpunkt haben Sie den Code bereits getestet (Sie ändern nur feste Zeichenfolgen) und sind wahrscheinlich ziemlich sicher, wenn Sie nur den Code ausführen (vorausgesetzt, Sie haben gute Sicherungen für alle Fälle).
Eine einfache Möglichkeit , ein zu testen DELETE, UPDATEoder INSERTist sie zu einem SELECT zu ändern , und führen sie dann bestätigen , dass die Anzahl und die Art der Zeilen , die Sie erwarten , werden zurückgegeben.
Sie könnten denken, dass Sie SELECTs nicht testen müssen, da sie tatsächlich keine Daten ändern. Wie auch immer, Sie führen den Code aus einem bestimmten Grund aus, oder? Angenommen, Sie recherchieren für Ihren Manager, der diese Daten wiederum an seinen Manager weitergibt, und so weiter. Sie testen, um sicherzustellen, dass Sie nicht die falschen Daten erhalten (oder andere daran hindern, ihre Daten zu sammeln).
Ad-hoc-Abfragen, die Systemdaten referenzieren / beeinflussen
Dies ist möglicherweise die einzige Ausnahme von der Regel "Alles testen". Sie führen Informationsabfragen zu Systemdaten aus. Das Wichtigste dabei ist, die erwarteten Daten zurückzugewinnen. Wenn die Abfrage etwas Einfaches ist (Abfragen einer Systemansicht), sind Sie wahrscheinlich in Ordnung, solange Sie überprüft haben, was die Ansicht / Spalten wirklich bedeuten. Wenn die Abfrage komplex ist (z. B. 3 oder 4 Systemansichten mit Berechnungen für die zurückgegebenen Spalten), möchten Sie möglicherweise einige Tests ausführen, um sicherzustellen, dass Sie die erwarteten Daten zurückerhalten.
Zusammenfassung
Zusammenfassend möchte man ja alles testen. Wenn es wichtig genug ist, dass Sie es schreiben und ausführen, ist es wichtig genug, dass Sie es testen. Das bedeutet jedoch nicht, dass Sie enorm viel Zeit damit verbringen müssen, jeden Zweig jeder Codezeile zu testen. Es müssen jedoch noch einige Tests durchgeführt werden.
Automated Unit Testing ist hier Ihr Freund. Mit dem Aufkommen von DevOpsund werden Continuous IntegrationSie immer mehr Anwendungen und Methoden zum schnellen und einfachen Testen Ihres Codes sehen. Das setzt natürlich eine gute Testumgebung und Daten voraus, aber das ist eine ganz andere Diskussion.