Chcę zacząć od powiedzenia, że wszystko, co robię, to SQL Server, więc oto przykłady, które podaję. Zasadniczo dotyczy to jednak dowolnej formy kodu, niezależnie od systemu.
Zacznijmy od odrobiny tego.
Ulepszenia
Masz system i masz zamiar zaktualizować część lub całość. Na przykład aktualizacja instancji z SQL Server 2012 do 2014. W tym momencie niezbędne jest testowanie. Niestety testowanie każdej części nawet małej aplikacji prawdopodobnie nie będzie możliwe. W tym momencie zrobiłbym coś, co nazwałbym „działającym” testem. Czy działa podstawowy system. Przeprowadź swoje wspólne zadania od początku do końca. Nie testuj każdej opcji, tylko główna ścieżka.
Podczas aktualizacji SQL Server wymagana jest również pewna lektura . Zasadniczo chcesz przeczytać Backward Compatibilitywpis dotyczący nowej wersji ( tutaj jest wersja 2014 ) i upewnić się, że nie masz nic na żadnej z list (zmiany łamiące, zmiany zachowania itp.).
Kod aplikacji
Patrzymy tutaj na nowy / zmieniający się kod aplikacji (ponieważ oczywiście wszystko, co istnieje, zostało już przetestowane, prawda?). W takim przypadku wszystko powinno zostać przetestowane. Powinieneś mieć skonfigurowane przypadki testowe z wyprzedzeniem i przejrzeć przynajmniej większość swoich funkcji. Najlepiej w tym miejscu powinieneś również poprosić kogoś innego o wykonanie podobnej kontroli. Ten kod będzie obowiązywał, prawdopodobnie przez dość długi czas, i będzie używany przez dużą liczbę osób. Chcesz się upewnić, że działa i działa dobrze.
Jedną z rzeczy, które naprawdę mogą w tym pomóc, jest wygenerowanie zestawu, unit testsktóry jest łatwo powtarzalny. Steve Jones zaleca używanie tSQLt do testowania kodu TSQL (obawiam się, że tylko SQL Server). Ale robiąc to, możesz szybko przejść przez ustalony zestaw testów i to naprawdę pomoże w testowaniu regresyjnym (testowanie wszystkiego, powiedzmy przed wykonaniem aktualizacji).
Funkcje / konfiguracje
Więcej niż zmiany kodu aplikacji chcesz dokładnie przetestować nowe funkcje i zmiany konfiguracji. Jeśli na przykład zdecydujesz się rozpocząć pracę z indeksami magazynu kolumnpo raz pierwszy będziesz musiał przetestować każdy fragment kodu, który dotyka dotkniętych tabel. Użyj wygenerowanych testów jednostkowych, aby przetestować aplikację. Te funkcje są prawdopodobnie nowe dla Ciebie (i prawdopodobnie nowe na platformie) i zapewne będą zawierały pewne niespodzianki. Jeśli chodzi o zmiany konfiguracji, mówisz o czymś, co może wpłynąć na cały system, być może znacznie. Zasadą jest testowanie i testowanie dokładnie. Są pewne zmiany, których tak naprawdę nie zobaczysz, dopóki nie przejdziesz do aktywnego systemu (być może tylko systemu produkcyjnego), ale nie jest to wymówka, aby nie wypróbować ich najpierw w środowisku testowym.
Zapytania ad hoc odnoszące się do danych użytkownika / wpływające na nie
Kiedy masz kod, który wpływa na twoje dane użytkownika, zwykle musisz go przetestować, a nawet, a może szczególnie, ponieważ jest Ad Hoc. Biorąc to pod uwagę, jeśli używasz tego samego kodu w kółko, tylko z różnymi parametrami, prawdopodobnie nie musisz się martwić o testowanie za każdym razem.
Na przykład musisz co najmniej raz na kwartał usuwać jedną lub więcej reklam z tabeli AdList.
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')
W tym momencie już przetestowałeś kod (po prostu zmieniasz ustalone ciągi) i prawdopodobnie jesteś całkiem bezpieczny, uruchamiając kod (zakładając, że masz dobre kopie zapasowe na wszelki wypadek).
Prostym sposobem na sprawdzenie DELETE, UPDATEczy INSERTjest zmiana ich do wybrania i uruchomić je, a następnie potwierdź, że liczba i rodzaj wierszy można oczekiwać są zwracane.
Możesz pomyśleć, że nie musisz testować SELECTs, ponieważ tak naprawdę nie zmieniają żadnych danych. Jednak kod działa z jakiegoś powodu, prawda? Załóżmy, że prowadzisz badania dla swojego menedżera, który z kolei przekaże te dane swojemu menedżerowi i tak dalej. Testujesz, aby upewnić się, że nie otrzymujesz niewłaściwych danych (lub blokujesz innym możliwość gromadzenia ich danych).
Zapytania ad hoc odnoszące się do danych systemowych / wpływające na nie
Jest to prawdopodobnie jedyny wyjątek od reguły „testuj wszystko”. Uruchamiasz zapytania informacyjne dotyczące danych systemowych. Ważne jest, aby odzyskać oczekiwane dane. Jeśli zapytanie jest czymś prostym (zapytanie do widoku systemu), prawdopodobnie wszystko jest w porządku, o ile sprawdziłeś, co naprawdę oznaczają widok / kolumny. Jeśli zapytanie jest złożone (powiedzmy, że trafiłeś 3 lub 4 widoki systemu z obliczeniami zwróconych kolumn), możesz przeprowadzić kilka testów, aby upewnić się, że odzyskasz oczekiwane dane.
Podsumowanie
Podsumowując, tak, chcesz wszystko przetestować. Jeśli napisanie go i uruchomienie jest wystarczająco ważne, wystarczy przetestować. Nie oznacza to jednak, że musisz poświęcić ogromną ilość czasu na testowanie każdej gałęzi każdego wiersza kodu. Ale należy przeprowadzić pewien poziom testów.
Zautomatyzowane testowanie jednostek jest tutaj Twoim przyjacielem. Wraz z pojawieniem się DevOpsi Continuous Integrationzobaczysz coraz więcej aplikacji i metod szybkiego i łatwego testowania swojego kodu. Oczywiście wymaga to posiadania dobrego środowiska testowego i danych, ale jest to zupełnie inna dyskusja.
