Rozdział 7. Testy

Rozdział 6. Protokoły | OpenDiag - STM32 CAN Tool | Rozdział 8. Roadmap

Tak. I tutaj proponuję podejść do tego profesjonalnie. Nie chodzi tylko o "sprawdzić czy działa", ale o to, żeby każdy etap projektu miał jasno określone kryteria zaliczenia. Dzięki temu po każdej zmianie będziemy mogli wrócić i sprawdzić, czy nic nie zepsuliśmy.

Rozdział 7. Testy

7.1 Cel

Celem testów jest potwierdzenie poprawności działania każdego modułu projektu OpenDiag.

Testy wykonywane są stopniowo – od pojedynczych modułów, poprzez integrację, aż do testów z rzeczywistym pojazdem.

Każdy etap implementacji kończy się zestawem testów zakończonych wynikiem PASS lub FAIL.

7.2 Rodzaje testów

Projekt przewiduje następujące poziomy testowania:

Testy modułów

Sprawdzają pojedynczy moduł.

Przykład:

  • USB
  • CAN
  • Logger
  • Parser

Testy integracyjne

Sprawdzają współpracę kilku modułów.

Przykład:

USB
 ↓
Parser
 ↓
ELM327

Testy systemowe

Sprawdzają cały firmware.

Przykład:

FORScan
 ↓
USB
 ↓
STM32
 ↓
CAN
 ↓
Samochód

Testy regresyjne

Po każdej większej zmianie ponownie wykonywane są wcześniej zaliczone testy.

Ich celem jest wykrycie błędów wprowadzonych podczas rozwoju projektu.

7.3 Środowisko testowe

Komputer

  • Linux (platforma główna)
  • Windows (FORScan)

Sprzęt

  • STM32 Nucleo-F767ZI
  • SN65HVD230
  • przewód OBD-II
  • Ford S-Max (główna platforma testowa)

7.4 Testy sprzętu

Pierwszym etapem jest sprawdzenie poprawności działania sprzętu.

Lista kontrolna:

  • STM32 uruchamia się poprawnie
  • ST-Link działa
  • Debug działa
  • Virtual COM działa
  • USB CDC jest wykrywany
  • Transceivery CAN działają

7.5 Testy komunikacji

UART

Sprawdzamy:

  • wysyłanie
  • odbiór
  • poprawność transmisji

USB CDC

Sprawdzamy:

  • enumerację urządzenia
  • wysyłanie danych
  • odbiór danych
  • długie ramki
  • szybkie wysyłanie wielu komend

CAN

Sprawdzamy:

inicjalizację odbiór nadawanie błędy magistrali różne prędkości

7.6 Testy parsera

Dla każdej komendy określamy:

wejście, oczekiwaną odpowiedź, wynik.

Przykład:

Polecenie Oczekiwana odpowiedź
ATI wersja urządzenia
ATZ restart
ATE0 OK

7.7 Testy ELM327

Sprawdzamy zgodność z wymaganiami FORScan.

Między innymi:

  • rozpoznawanie komend AT,
  • odpowiedzi zgodne z ELM327,
  • obsługę błędów,
  • poprawne zakończenie odpowiedzi (>).

7.8 Testy CAN

Każdy port CAN testujemy niezależnie.

Zakres:

  • CAN A
  • CAN B
  • CAN C (po jego dodaniu)

Sprawdzamy:

  • wysyłanie ramek,
  • odbiór ramek,
  • jednoczesną pracę wielu kanałów.

7.9 Testy z pojazdem

Pierwszym pojazdem testowym będzie:

Ford S-Max

Zakres:

  • wykrycie adaptera,
  • identyfikacja modułów,
  • odczyt błędów,
  • kasowanie błędów,
  • odczyt parametrów Live Data.

Później można rozszerzyć testy o inne pojazdy.

7.10 Testy wydajności

Sprawdzamy:

  • maksymalną liczbę ramek CAN/s,
  • opóźnienie odpowiedzi,
  • obciążenie procesora,
  • wykorzystanie pamięci RAM,
  • wykorzystanie pamięci Flash.

7.11 Testy stabilności

Urządzenie powinno pracować przez dłuższy czas bez:

  • zawieszeń,
  • resetów,
  • utraty ramek,
  • błędów USB.

7.12 Dokumentacja testów

Każdy test powinien zawierać:

  • identyfikator (np. USB-001),
  • opis,
  • warunki wstępne,
  • procedurę,
  • oczekiwany wynik,
  • rzeczywisty wynik,
  • status (PASS/FAIL),
  • datę wykonania.

Przykład:

ID Nazwa Wynik
USB-001 Enumeracja USB CDC PASS
CAN-001 Inicjalizacja CAN A PASS
ELM-001 Odpowiedź na ATI PASS

7.13 Narzędzia testowe

Na obecnym etapie planujemy używać:

  • STM32CubeIDE – debugowanie,
  • PuTTY / GtkTerm / Minicom – testy UART i USB CDC,
  • FORScan – testy zgodności z ELM327,
  • Wireshark (USBPcap na Windows) – analiza komunikacji USB (jeśli zajdzie potrzeba),
  • SocketCAN + can-utils (Linux) – w przyszłości do porównywania ruchu CAN z naszym interfejsem.

Moja propozycja do całego projektu

Chciałbym dodać jeszcze jedną zasadę:

Każdy nowy moduł musi mieć własny plan testów, zanim zaczniemy go implementować.

Przykład:

  • zanim napiszemy parser ELM, tworzymy listę 10–20 komend do sprawdzenia;
  • zanim napiszemy obsługę CAN, definiujemy testy nadawania, odbioru i błędów.

To może wydawać się dodatkową pracą, ale bardzo ułatwia rozwój i późniejsze refaktoryzacje. Dzięki temu zawsze wiemy, czy po zmianach projekt nadal zachowuje się zgodnie z założeniami.