DFT : Design for Test

Wprowadzenie

Design For Test (DFT) (pol. Projektowanie pod kątem testowania) to jedna z metod wchodzących w skład większej metodologii określanej mianem DFX - Design For Excellence. DFT skupia się na zagadnieniach związanych z testowaniem produktów na różnych etapach procesu wytwarzania.

Implementacja zaleceń DFT wspomaga proces testów i diagnostyki produktów, co redukuje koszty niezgodności w procesie produkcji i ostatecznie oszczędza czas oraz zasoby.

Niniejszy artykuł zagłębia się w zasady DFT, analizuje typowe przykłady oraz podkreśla znaczenie DFT dla sukcesu projektu.

DFT w projektowaniu urządzeń

W projektowaniu różnych fizycznych urządzeń (hardware), rozwiązania DFT mogą być zastosowane w różny sposób. Poniżej trzy główne aspekty do rozważania:

Połączenie z testerem

Kluczowy aspekt DFT to możliwość poprawnego podłączenia sprzętu kontrolno-pomiarowego do badanego produktu. Preferowany sposób to jakieś łącze, interfejs, punkty testowe itp. Dzięki standaryzacji tego rozwiązania, typowy sprzęt diagnostyczny może być łatwiej zastosowany w czasie procesu produkcji.

Wybrane przykłady w przemyśle elektronicznym:

• Punkty testowe (ang. Test Points). Te punkty powinny być umiejscowione w taki sposób, aby umożliwić poprawny kontakt z igłami testowymi lub sondami pomiarowymi. Punkty testowe są wykorzystywane przez takie systemy jak: ICT (ang. In-Circuit Test), FPT (ang. Flying Probes Test) i FCT (ang. Functional Test).
• Interfejs diagnostyczny. Najczęściej jest to jakaś forma łącza szeregowego (USB, UART, SPI, I2C, JTAG) lub Ethernet. Inne rozwiązania są rzadziej spotykane (np. równoległa szyna danych).

Tryb testowy

Jedną z ciekawych form DFT jest opracowanie rozwiązania, w którym testowany produkt jest wprowadzany w specjalny tryb testowy. Ten tryb pozwala na weryfikację poszczególnych funkcji produktu bez konieczności symulowania całości środowiska oraz nietypowych trudnych do replikacji wymuszeń.

Wybrane przykłady w przemyśle elektronicznym:

• BIST (Built-In Self Test). Wbudowany self-test urządzenia. Ta technika jest stosowana głównie w procesie produkcji półprzewodników, jednakże ten koncept może być także zaimplementowany na poziomie modułów elektronicznych czy wręcz kompletnych dużych systemów.
• JTAG Boundary Scan. Ta metoda testu opiera się o dostęp do wewnętrznych rejestrów układów scalonych za pomocą standardowego portu testowego JTAG. Część cyfrowych układów scalonych posiada możliwość takiego testu (głównie układy FPGA, większe MCU/CPU, niektóre pamięci oraz inne dedykowane układy). Standardy z serii IEEE 1149.x określają szczegółowe wymogi dla tego rodzaju testu[1].
• Tryb testowy aplikacji. Na początku testu modułu elektronicznego wgrywany jest specjalny program testowy do MCU / pamięci / FPGA, który umożliwia łatwy test poszczególnych funkcji produktu. Po zakończeniu testu ten specjalny kod jest zastępowany właściwą aplikacją.

Podział na moduły

Skomplikowane, duże systemy mogą być bardzo trudne do efektywnego przetestowania. Szczególnie wtedy, kiedy błąd w jednym podsystemie powoduje szereg kolejnych błędów w innych podsystemach, a pętla sprzężenia zwrotnego przesyła błędną informację zwrotnie do tego pierwszego podsystemu, gdzie faktycznie wystąpił błąd. Taka sytuacja powoduje „zapętlenie” i nie wiadomo wtedy, w którym podsystemie jest faktyczny błąd. To utrudnia detekcję wady, podnosi koszty testów i analiz. Rozwiązaniem tego problemu może być podział dużego systemu na mniejsze oddzielnie testowane podsystemy. Dopiero po wykonaniu testów poszczególnych podsystemów realizowany jest finalny test całego zintegrowanego systemu.

DFT w rozwoju oprogramowania

W inżynierii oprogramowania możemy spotkać się z pojęciem Test Driven Development (TDD)[2]. TDD to metodyka programowania, w której najpierw pisze się testy dla nowych funkcjonalności, a następnie kod, który te testy przechodzi. Takie podejście promuje tworzenie niezawodnego i łatwiejszego do testowania oprogramowania.

W TDD dzielimy proces tworzenia kodu programu na trzy fazy realizowane cyklicznie:

• Opracowanie i sprawdzenie testu (Faza czerwona):
  • Opracowanie testu. Test jest tworzony z myślą o tym, jakie dane wejściowe zostaną przekazane do testowanego kodu i jaka powinna być jego poprawna odpowiedź. Zalecam opracować wiele wariantów, zmieniając wartości danych wejściowych tj. dane poprawne, dane poprawne w górnej oraz w dolnej granicy zakresu, dane błędne tuż poza zakresem, dane znacząco poza zakresem, brak danych, dane totalnie błędne (np. znaki zamiast liczb) itp.
  • Sprawdzenie testu. Polecam przetestować test :) Uruchamiamy wszystkie testy i upewniamy się, że nowy test ma status "fail" (czerwony status w IDE).
• Opracowanie i testowanie kodu (Faza zielona):
  • Opracowanie kodu. Na tym etapie tworzony jest właściwy kod aplikacji. Np. opracowujemy klasę lub dodajemy kolejną metodę itp. Staramy się napisać minimalną ilość kodu, niezbędną tylko do przejścia nowego testu. Nie dokładamy funkcjonalności, dla których nie mamy jeszcze testu.
  • Testowanie kodu. Uruchamiamy „nowy” test oraz wszystkie uprzednio napisane testy. Następuje weryfikacja opracowanego kodu. Korygujemy kod, aż przejdzie on wszystkie testy na "pass" (status zielony w IDE). Nowy test może wykryć błąd w nowo dodanym kodzie, a "stare testy" powinny wykryć błędy w innej części kodu, która została naruszona przez ten nowy kod.
• Refaktoryzacja kodu:
  • Refaktoryzacja kodu. Poprawa struktury kodu, usunięcie ewentualnych duplikatów, niepotrzebnych zależności i jednocześnie upewnienie się, że wszystkie testy nadal przechodzą pomyślnie.
  • Retest. Po wykonaniu refaktoryzacji gorąco polecam sprawdzić jeszcze raz wszystkie testy.

Trzy fazy Test Driven Development:

Idea testów oprogamowania została świetnie ;) wyjaśniona w tym wideo: Tester oprogramowania w sklepie

TDD zachęca programistów do myślenia o wymaganiach w projekcie przed napisaniem funkcjonalnego kodu, co prowadzi do niezawodnego, czystego i łatwego w utrzymaniu oprogramowania. Wtedy okazuje się, że posiadanie przejrzystych interfejsów oraz stosowanie zasady SOLID jest bardzo, ale to bardzo pomocne.

Istnieje wiele innych zasad, których stosowanie jest pomocne w tworzeniu testowalnego kodu np. zasada SOLID, wzorce projektowe, MVC, stosowanie warstw np. HAL w relacji do sprzętu itd.

Podsumowując, jakość kodu ma być wynikiem wyboru odpowiedniej architektury oprogramowania, przemyślenia struktury kodu, podziału na logiczne warstwy i funkcjonalne bloki. Stosowanie metod takich jak TDD jest bardzo pomocne w tym aspekcie.

Podsumowanie

Projektowanie dla testów (DFT) jest nieodzownym aspektem nowoczesnej inżynierii, zapewniającym, że produkty są projektowane z myślą o testowalności. Stosując zasady DFT, inżynierowie mogą zwiększyć niezawodność, łatwość konserwacji i wydajność swoich produktów. Niezależnie od tego, czy chodzi o oprogramowanie, półprzewodniki, motoryzację, elektronikę użytkową, czy przemysł lotniczy i kosmiczny, metodologie DFT umożliwiają wczesne wykrywanie błędów, usprawniają procesy testowania i poprawiają ogólną jakość produktu. Dla inżynierów projektantów, opanowanie DFT jest niezbędne do dostarczania solidnych i niezawodnych produktów na dzisiejszym konkurencyjnym rynku.