Optymalizowanie testów regresji w środowisku C++

Question

Aby uniknąć zbyt wielu testów, chciałbym przedstawić zespołowi Quality Assurance (QA) wskazówki, które funkcje muszą być testowane regresyjnie po iteracji programistycznej. Czy znasz narzędzia, które mogą to zrobić w środowisku deweloperów C++ i Subversion (i visual studio)?

Szczegóły o przypadku użycia:

1. Funkcje byłoby zdefiniowane przez zespół rozwoju pod względem wejścia punktów, zazwyczaj klas lub klasy metod. Powiedzmy, funkcja "excel file import" jest zdefiniowana metodą ImportExcelFile (...) klasy FileImporter.
2. Podczas iteracji programowania zespół programistów zatwierdza pewne zmiany w niektórych metodach niektórych klas o klasach . Powiedzmy, jedna z tych klas pośrednio wykorzystywane metodą ImportExcelFile()
3. Pod koniec iteracji, wszystkie commity są analizowane przez narzędzia i raport jest produkowane i dostarczane do zespołu QA. W naszym przykładzie zespół ds. Kontroli jakości jest informowany, że funkcja "import pliku excel" musi być przetestowana pod numerem , a pozostałe funkcje X Y & Z to niezmienione.

Najprawdopodobniej narzędzie to wykorzystywałoby statyczną analizę kodu i korzystało z interfejsów API subwersji. Ale czy istnieje?

Answer 1

G'day,

co opisujesz nie jest to testowanie regresji. Właśnie testujesz nowe funkcje.

Testowanie regresji to miejsce, w którym uruchamia się kompletny zestaw testów, aby sprawdzić, czy kod obsługujący nową funkcję spowodował przerwanie działającego kodu.

Gorąco polecam przeczytanie doskonałego papieru Martina Fowlera "Continuous Integration", który opisuje niektóre aspekty, o których mówisz.

Zapewnia również lepszy sposób pracy, w szczególności aspekty związane z IK, o których Martin mówi w swoim artykule.

Edytuj: Szczególnie dlatego, że CI ma kilka ukrytych małych pułapek, które są oczywiste z perspektywy czasu. Takie rzeczy jak zatrzymywanie testerów próbujących przetestować wersję, która nie zawiera jeszcze wszystkich plików implementujących nową funkcję. (Sprawdzasz, czy w ciągu ostatnich pięciu minut nie było żadnych zatwierdzeń).

Innym ważnym punktem jest utrata czasu, jeśli masz zepsutą kompilację i nie wiesz, że jest ona uszkodzona, dopóki ktoś nie sprawdzi kodu, a następnie spróbuje go zbudować, aby mógł go przetestować.

Jeśli jest uszkodzony, masz teraz:

• testerem siedzieć w stanie wykonać zaplanowane testy,
• deweloper przerywania ich obecnej pracy, aby wrócić do poprzedniej pracy, aby uporządkować to, co jest przyczyną zepsuta budowa.Najprawdopodobniej to deweloperzy, ponieważ problem polega na interakcji między dwiema oddzielnymi częściami, z których każda działa na własną rękę.
• utrata czasu spowodowana tym, że deweloper (y) musiał powrócić do mentalności dla poprzedniej pracy, i
• utratę czasu dla programisty, aby powrócić do mentalności nowego dzieła, którym byli praca przed przerwą w badaniu.

Podstawową ideą CI jest wykonanie kilku kompilacji całego produktu w ciągu dnia, tak aby złapać pułapkę uszkodzonej wersji tak szybko, jak to możliwe. Możesz nawet wybrać kilka testów, aby sprawdzić, czy podstawowe funkcje Twojego produktu nadal działają. Ponownie, aby jak najszybciej powiadomić o problemie z bieżącym stanem twojej kompilacji.

Edytuj: Jeśli chodzi o pytanie, co z oznaczaniem repozytorium po zakończeniu testów, np. TESTS_COMPLETE_2009_12_16. Następnie, kiedy jesteś gotowy, aby przekonać się, jaki jest następny zestaw testów, "svn diff -r" pomiędzy najnowszymi testami zakończył tag i HEAD?

HTH

BTW będę aktualizować tę odpowiedź z niektórych dalszych sugestii, jak o nich myślę.

okrzyki,

Answer 2

podzielić projekt na oddzielne pliki wykonywalne i zbudować je.

Make odbuduje każdy plik wykonywalny, jeśli zmieni się jego zależność.

Dodaj pliki wyjściowe wszystkich powiązanych testów do zależności następnego testu - na przykład wynik testu zapisu pliku jako zależność testu odczytu pliku.

Wszystko, co zostało zbudowane po tym etapie, wymaga testów jednostkowych.

Jeśli dowolne biblioteki używają zwykłych zasobów wyczerpywalnych (pamięć sterty, dysk, globalne muteksy itp.), Dodaj je również jako zależności, ponieważ wyczerpanie z powodu wycieku w jednej bibliotece często jest przyczyną regresji w innej.

Wszystko, co zostało zbudowane po pewnym punkcie, wymaga testów regresyjnych.

Jeśli nie pracujesz w środowisku, w którym brak zasobów wyczerpuje się (np. TinyC), skończy się regresja testująca wszystko. Testowanie regresji nie jest testowaniem jednostkowym.