Wskazówki dotyczące testowania aplikacji intensywnie wykorzystującej dane:

Question

Pracuję nad bardzo obszerną, wymagającą dużych nakładów aplikacją. Baza danych kodu & jest ogromna. Duża część logiki biznesowej jest rozproszona na wszystkich poziomach, w tym w procedurach przechowywanych.

Czy ktoś ma sugestie, w jaki sposób rozpocząć stosowanie testów "jednostkowych" (testy integracji technicznej, ponieważ muszą one przetestować na różnych poziomach dla jednego aspektu prawie dowolnego procesu) w efektywny sposób? Obecna architektura nie ułatwia łatwego wstrzykiwania ani szyderstwa. W celu ułatwienia testowania napisany jest nowy kod, ale co ze starszym kodem? Ze względu na silną zależność od samych danych i logiki biznesowej w bazie danych, obecnie używam wbudowanego sql, aby znaleźć dane do wykorzystania do testowania, ale są one czasochłonne. Tworzenie widoków i/lub procedur przechowywanych nie wystarcza.

Co podejścia brałeś (jeśli dotyczy)? Co zadziałało? Dlaczego nie? Wszelkie sugestie będą mile widziane. Dzięki.

Answer 1

Pobierz kopię Working Effectively with Legacy Code przez Michaela Piór. Jest pełen użytecznych porad dotyczących pracy z dużymi, nietestowanymi bazami kodów.

Kolejna dobra książka jest Object Oriented Reengineering Patterns. Większość książki nie jest specyficzna dla oprogramowania obiektowego. Pełny tekst jest dostępny do bezpłatnego pobrania w formacie PDF.

Z własnego doświadczenia: spróbuj ...

• Automatyzacja procesu budowania oraz wdrażania
• Get schematu bazy danych pod kontrolą wersji, jeśli nie jest jeszcze. Zwykle bazy danych zawierają dane referencyjne, których kod transakcyjny musi istnieć, zanim będzie mógł działać. Pobierz również tę kontrolę wersji. Narzędzia takie jak dbdeploy mogą pomóc w łatwym przebudowaniu schematu i danych referencyjnych z sekwencji delt.
• zainstalować wersję bazy danych (i wszelkich innych usług infrastrukturalnych) na stacji roboczej rozwoju. Umożliwi to pracę z bazą danych bez konieczności ciągłego przechodzenia przez DBA. Jest także szybszy niż używanie schematu na współdzielonym serwerze w odległym centrum danych. Wszystkie główne komercyjne serwery baz danych mają darmowe wersje rozwojowe (jak w piwie), które działają w systemie Windows (jeśli utkniesz w nie do pozazdroszczenia, że ​​rozwijasz się w systemie Windows i wdrażasz na systemie Unix).
• Przed rozpoczęciem prac na obszarze kodu, pisać end-to-end testy, które z grubsza pokrywają zachowanie obszaru, nad którym pracujesz. Kompleksowy test powinien wykonywać system z zewnątrz - kontrolując jego interfejs użytkownika lub wchodząc w interakcje za pośrednictwem usług sieciowych - nie trzeba więc zmieniać kodu, aby go wprowadzić. Będzie działać jako (niedoskonały) test regresji i da ci większą pewność, aby odmienić elementy wewnętrzne systemu w kierunku struktury łatwiejszej do testowania jednostkowego.
• Jeśli istnieją ręczne plany testowe, przeczytaj je i zobacz, co można zautomatyzować. Większość ręcznych plany testowe są niemal całkowicie skryptów i tak są nisko wiszące owoce dla automatyzacji
• Gdy masz zasięg testów end-to-end, byłaby kod do bardziej luźno powiązanych jednostek, jak modyfikować i/lub przedłużyć go. Otocz te jednostki testami jednostkowymi.

warte unikać:

• Kopiowanie danych z bazy danych do środowiska produkcyjnego używanego do automatycznego testowania. To sprawi, że twoje testy będą nieprzewidywalne.Oczywiście, uruchom system na podstawie kopii danych produkcyjnych, ale używaj go do testowania eksploracyjnego, a nie do regresji.
• Wycofywanie transakcji po zakończeniu testów w celu odizolowania testów od siebie. Nie przetestuje to zachowania zachodzącego tylko po zatwierdzeniu transakcji i wyrzuci dane, które są cenne dla diagnozowania niepowodzeń testowych. Zamiast tego, testy powinny zapewnić, że baza danych znajduje się w znanym stanie początkowym po uruchomieniu.
• Tworzenie "małego" zestawu danych do testów, przeciwko którym można wykonać. To sprawia, że ​​testy są trudne do zrozumienia, ponieważ nie można ich odczytać jako pojedynczej jednostki. "Mały" zestaw danych wkrótce staje się bardzo duży, gdy dodajesz testy dla różnych scenariuszy. Zamiast tego, testy mogą wstawiać dane do bazy danych, aby skonfigurować test-urządzenie.

Answer 2

„modernizacja Testowanie Legacy Application”, podkreśla:

przegląd

1. wysoki poziom jak testy są tworzone w AscentialTest

2. sposoby konwertowania spuściznę obiektów do nowych komponentów platformy obiektu definicja

3. Jak zapewnić, że zmodernizowana wersja aplikacji daje takie same wyniki

Więcej informacji na temat używania aplikacji testowania starszych, należy sprawdzić tutaj:

http://application-management.cioreview.com/whitepaper/testing-legacy-application-modernization-wid-529.html