Testowanie oprogramowania wbudowanego [zamknięte]

Testowanie jednostkowe w środowisku PC może wiele zyskać (kompilowanie kodu za pomocą kompilatora PC C i uruchamianie kodu w ramach testowania jednostkowego PC), z kilkoma zastrzeżeniami:

1. Nie dotyczy to testowania kodu niskiego poziomu, w tym kodu startowego, testów pamięci RAM, sterowników sprzętu. Będziesz musiał użyć bardziej bezpośrednich testów jednostkowych.
2. twój wbudowany kompilator systemu musi być godny zaufania, więc nie polujesz na błędy stworzone przez kompilator.
3. Twój kod musi być warstwową architekturą, z abstrakcją sprzętową. Może być konieczne napisanie symulatorów sterowników sprzętowych dla platformy testowania jednostkowego komputera.
4. należy zawsze używać typów stdint.h takich jak uint16_t zamiast zwykłych unsigned int itp.

Przestrzegaliśmy tych zasad i stwierdziliśmy, że po jednostkowym przetestowaniu kodu warstwy aplikacji w ramach testów jednostkowych na PC możemy mieć pewność, że działa on dobrze.

Zalety testów jednostkowych na platformie PC:

1. nie napotykasz problemu braku miejsca na pamięci ROM na wbudowanej platformie z powodu dodania frameworka do testów jednostkowych.
2. cykl compile-link-run jest zazwyczaj szybszy i prostszy na platformie PC (i pozwala uniknąć kroku "zapisu/pobierania", który może potrwać kilka minut).
3. masz więcej opcji wizualizacji postępu (niektóre aplikacje wbudowane mają ograniczone urządzenia peryferyjne We/Wy), przechowywania danych wejściowych/wyjściowych do analizy, uruchamiania więcej czasochłonne testy.
4. Możesz używać łatwo dostępnych frameworków testów jednostkowych opartych na PC, które nie są dostępne/odpowiednie dla wbudowanej platformy.

Systemy wbudowane to szeroki temat, ale ogólnie rzecz biorąc, pomyślmy o nim jako o produkcie o konkretnym przeznaczeniu, który łączy zarówno sprzęt, jak i oprogramowanie. Moje osadzone Tło pochodzi z telefonów komórkowych, które jest tylko małym podzbiorem wszystkich systemów wbudowanych. Postaram się zachować następujące punkty nieco na abstrakcyjnej stronie:

• Streszczenie zależności sprzętowych w miarę możliwości. W ten sposób można uruchomić testy jednostkowe na "sprzęcie", a także przetestować różne rzadkie / wyjątkowe przypadki, które trudniej byłoby przetestować cel. Aby zapobiec kosztom abstrakcji, można użyć np. kompilacji warunkowej.

• Mieć jak najmniej zależy od sprzętu.

• Testy jednostkowe uruchomione na emulatorze lub środowisku cross-compiler nadal nie gwarantują działania kodu na docelowym sprzęcie. Musisz przetestować na celu, jak również. Przetestuj cel tak wcześnie, jak to możliwe.

You might want to check out Test Driven Development for Embedded C autor: James W. Grenning Książka ma się ukazać w sierpniu 2010 roku, ale książka beta jest już dostępna na The Pragmatic Bookshelf .

Głos braku doświadczenia tutaj, ale to jest coś, o czym myślałem również ostatnio. Wydaje mi się, że najlepszym podejściem byłoby albo

A) napisz jak najwięcej kodu aplikacji niezależnej od sprzętu w środowisku PC, zanim napiszesz go na komputerze docelowym i napiszesz testy jednostkowe w tym samym czasie (zrobienie tego na komputerze powinno zmusić cię do oddzielenia rzeczy niezależnych od sprzętu). W ten sposób możesz użyć wybranych testerów jednostkowych, a następnie przetestować sprzętowe rzeczy w staromodny sposób - z RS - 232 i / lub oscyloskopów i pinów wejścia/Wyjścia sygnalizujących dane zależne od czasu, w zależności od tego, jak szybko musi działać.

B) zapisz to wszystko na docelowym sprzęcie, ale użyj make target, aby warunkowo skompilować kompilację testów jednostkowych, która uruchomi testy jednostkowe i wyświetli wyniki (lub dane, które mogą być analizowane dla wyników) przez RS-232 lub w inny sposób. Jeśli nie masz dużo pamięci, to może być trudne.

Edit 7/3/2009 Ja tylko miałem kolejną myśl o tym, jak testować sprzęt zależny od sprzętu. Jeśli zdarzenia sprzętowe dzieją się zbyt szybko, aby nagrywać za pomocą RS-232, ale nie chcesz ręcznie przesiać ton sprawdzania danych oscyloskopu, aby sprawdzić, czy flagi I / O Pin rosną i opadają zgodnie z oczekiwaniami, możesz użyć karty PC ze zintegrowanym DIO (takim jak linia kart Akwizycji Danych National Instruments), aby automatycznie ocenić czas tych sygnałów. Wtedy wystarczy napisać oprogramowanie na komputerze, aby kontroluj kartę akwizycji danych, aby zsynchronizować się z aktualnie uruchomionym testem jednostkowym.

Udaje nam się przetestować sporo kodu zależnego od sprzętu za pomocą symulatora, używamy symulatora Keila i IDE(nie powiązanego tylko używać ich narzędzi). Piszemy Skrypty symulatora, aby napędzać "sprzęt" w sposób, w jaki oczekujemy, że zareaguje i jesteśmy w stanie dość niezawodnie przetestować nasz działający kod. Wprawdzie modelowanie sprzętu do niektórych testów może wymagać trochę wysiłku, ale dla większości rzeczy działa to bardzo dobrze i pozwala nam wiele zrobić bez żadnego dostępnego sprzętu. Byliśmy w stanie uzyskać prawie kompletny system działający w symulatorze przed dostępem do sprzętu i miał bardzo niewiele problemów, z którymi trzeba sobie poradzić po umieszczeniu kodu na prawdziwej rzeczy. Może to również znacznie przyspieszyć produkcję kodu, ponieważ wszystko można zrobić na komputerze z bardziej dogłębnym debuggerem dostępnym podczas symulacji układu i próby zrobienia wszystkiego na sprzęcie.

Udało się to osiągnąć niezawodnie dla złożonych systemów sterowania, interfejsów pamięci, niestandardowych układów scalonych opartych na SPI a nawet monofoniczny wyświetlacz.

Jest tu wiele dobrych odpowiedzi, Niektóre rzeczy, które nie zostały wymienione, to mieć uruchomiony kod diagnostyczny w celu:

Loguj zdarzenia HAL (przerwania, komunikaty magistrali itp.)

Mieć kod do śledzenia swoich zasobów, (wszystkie aktywne semafory, aktywność wątku)

Mają mechanizm przechwytywania pamięci RAM do kopiowania sterty i zawartości pamięci do trwałego magazynu (dysku twardego lub równoważnego) w celu wykrywania i debugowania blokad, livelocks, wycieków pamięci, przepełnienia bufora itp.

Kiedy miałem do czynienia z tym w zeszłym roku naprawdę chciałem przetestować na platformie wbudowanej. Rozwijałem bibliotekę i korzystałem z wywołań RTOS i innych funkcji wbudowanej platformy. Nie było nic konkretnego, więc dostosowałem Kod UnitTest++ do moich celów. Programuję na rodzinie NetBurner i ponieważ ma wbudowany serwer WWW, dość prosto było napisać web based GUI test runner, który daje klasyczne czerwone / zielone sprzężenie zwrotne. Informatyka okazało się całkiem nieźle, a teraz testowanie jednostkowe jest o wiele łatwiejsze i czuję się o wiele pewniej wiedząc, że kod działa na rzeczywistym sprzęcie. Używam nawet frameworka unit testing do testów integracyjnych. Na początku wyśmiewam / stubuję sprzęt i wstrzykuję ten interfejs do testu. Ale w końcu piszę kilka testów man-in-the-loop, które ćwiczą rzeczywisty sprzęt. Okazuje się, że jest to znacznie prostszy sposób, aby dowiedzieć się o sprzęcie i mieć łatwy sposób na odzyskanie z wbudowanych pułapek. Ponieważ testy wszystkie uruchamiane od wywołań zwrotnych AJAX do serwera www pułapka dzieje się tylko w wyniku ręcznego wywołania testu i system zawsze uruchamia się czysto kilka sekund po pułapce.

NetBurner jest na tyle szybki, że cykl testowy zapisu / kompilacji / pobierania / uruchamiania trwa około 30 sekund.

Wiele wbudowanych procesorów jest dostępnych na płytach eval, więc chociaż możesz nie mieć swoich prawdziwych urządzeń we/wy, często możesz wykonać wiele swoich algorytmów i logiki na jednym z tego rodzaju rzeczy, często z debugowaniem sprzętowym dostępnym przez jtag. A testy "jednostkowe" zazwyczaj dotyczą bardziej Twojej logiki niż i/O. Problemem jest zazwyczaj odzyskanie testowych artefaktów z jednego z tych środowisk.

Podziel kod pomiędzy zależne od urządzenia i niezależne od urządzenia. Niezależny kod może być testowany jednostkowo bez większego bólu. Kod zależny będzie po prostu musiał być testowany ręcznie, dopóki nie będziesz miał płynnego interfejsu komunikacyjnego.

Jeśli piszesz interfejs komunikacyjny, to przepraszam.