Testing hardware Paweł Noga

Transkrypt

1 Testing hardware Paweł Noga

2 Agenda Wstęp co testujemy? Współpraca z klientem zapewnijcie mi jakość Laboratorium testów Case study mierzenie transferów sieciowych Ciekawe błędy i problemy Wnioski

3 Co będziemy testować?

4 Co będziemy testować? System modułowy do zastosowania w dronach, kamerach, systemach bezpieczeństwa Każdy moduł to niezależna jednostka (wzorowana na bannana PI) + OS (linux) + sterowniki Moduły są wyspecjalizowane w nagrywaniu obrazu 4k, encodowaniu, streamowaniu Moduły mogą pracować równolegle współpracować ze sobą i tworzyć systemy typu swarm z modułem zarządzającym królową Komunikacja modułów odbywa się przez sieć (wifi lub kabelek (10Gbit/s))

5 Współpraca z klientem

6 Współpraca z klientem Zapewnijcie mi jakość

7 Współpraca z klientem Rozpoznanie narzędzi do pomiarów Raportowanie wyników, zgłaszanie błędów Budowa laboratorium testów i jego utrzymywanie Zapewnijcie mi jakość Automatyzacja testów Propozycje scenariuszy i konfiguracji Utrzymywanie wiki z instrukcjami i workaroundami

8 Laboratorium testów

9 Laboratorium testów Prototypy Dużo części zapasowych Laboratorium testów Sprzęt w różnych konfiguracjach (Device Under Test) Kontrolery testów i narzędzia do debugowania Narzędzia wsparcia (KVM, WDS, Clonezilla, Powerswitch)

10 Laboratorium testów Powtarzalność / reprodukowalność Odtwarzalność Prototypy Konfigurowalność Skalowalność Dużo części zapasowych Laboratorium testów Sprzęt w różnych konfiguracjach (Device Under Test) Stabilność Łatwość fizycznego dostępu Możliwość pracy zdalnej Bezpieczeństwo Kontrolery testów i narzędzia do debugowania Narzędzia wsparcia (KVM, WDS, Clonezilla, Powerswitch) Opis / Dokumentacja Łatwość w zarządzaniu i przydzielaniu

11 Automatyzacja

12 Automatyzacja Narzędzie (klasa + metody) Core: ssh, cmd, regex, log, xml konfiguracja XML

13 Automatyzacja Zautomatyzowany scenariusz Narzędzie (klasa + metody) Core: ssh, cmd, regex, log, xml konfiguracja XML

14 Automatyzacja Kontroler Zautomatyzowany scenariusz Narzędzie (klasa + metody) Core: ssh, cmd, regex, log, xml konfiguracja XML Testowane urządzenie 1 Testowane urządzenie 2 Testowane urządzenie 3

15 Automatyzacja Kontroler Zautomatyzowany scenariusz Narzędzie (klasa + metody) Core: ssh, cmd, regex, log, xml konfiguracja XML RAPORT Testowane urządzenie 1 Testowane urządzenie 2 Testowane urządzenie 3

16 Automatyzacja pomiarów transferów sieciowych Poszukiwanie narzędzi Wybór narzędzi oraz opracowanie testów i ich parametrów Stworzenie prototypu testu automatycznego Stworzenie konfiguracji do automatów i zautomatyzowanie zestawu testów System raportowania testów

17 Automatyzacja pomiarów transferów sieciowych Oczekiwane szybkości pomiarów drastycznie zmniejszyły listę narzędzi Konieczność mierzenia transferów po TCP i UDP zmniejszyła listę narzędzi jeszcze bardziej co jest ważne zmieniało się wielokrotnie przez co priorytety nie były stabilne Czasem nie ma na czym testować Stabilność testowanego sprzętu Zestawienia, porównywanie buildów, jasne deklarowanie gdzie jesteśmy względem oczekiwań Poszukiwanie narzędzi Wybór narzędzi oraz opracowanie testów i ich parametrów Stworzenie prototypu testu automatycznego Stworzenie konfiguracji do automatów i zautomatyzowanie zestawu testów System raportowania testów Klient narzucił kilka własnych, które nie mierzyły tego co trzeba (np. przesyłały pliki, a nie strumieniowały) Nieznane było finalne użycie biznesowe Kontekst od chcemy znać dla różnych parametrów zachowanie systemu przeszedł do znajdźcie taką konfigurację gdzie wyniki będą najlepsze O czym jeszcze nie pomyśleliśmy? Mnogość konfiguracji: Wersje OS, platform (dronów) sprzętu, etc Praca ma sens jeśli jest odpowiednio wykorzystana

18 Ciekawe błędy

19 Ciekawe błędy Napięcie z kabelka USB służącego do debugowania było konieczne do działania urządzenia Wyjście z jednego portów było zasłonięte przez obudowę Zastosowano delikatne piny do zworek i łatwo było je wyłamać Sterowniki dostarczone przez zewnętrznego dostawcę uniemożliwiały włożenie kości RAM większych niż 4GB Wciśnięcie reset na urządzeniu gdzie podpięty był moduł nie powodowało resetu na module Sterowniki zamiast prawidłowo wyłączać sieć, tylko ukrywały istnienie połączenia efekt nie dało się bez rebootu maszyny na nowo zestawić połączenia W przypadku równoległych transferów moduły nie potrafiły się po równo dzielić dostępnym pasmem. Zworka do debugowania na module nie działała (było fizyczne przerwanie na scieżce) Kontroler do zmiejszania częstotliwości CPU w przypadku przegrzania nie działał Kabelków USB służących do debugowania nie można było podłączyć pod port USB 3.0 gdyż zawieszało to system Moduł królowa potrafił zarządzać tylko modułami podłączonymi w momencie jego startu (dodawanie kolejnych modułów psuło istniejące połączenia sieciowe)

20 Wnioski

21 Wnioski Zawsze stosuj co najmniej dwa narzędzia do pomiarów Znaj ograniczenia narzędzi, sposób ich parametryzacji i możliwości Prototypowanie i skalowalność są warunkiem koniecznym do sukcesu Konfiguracje lubią rosnąć eksponencjalnie prędzej czy później utraci się możliwość uzyskania 100% pokrycia testów i należy stosować analizę ryzyka Powinno się jasno definiować kryteria przejścia milestone ów (oczekiwane wyniki, ilości błędów krytycznych, ilości workaround ów) To ważne aby określać czy przyczyna leży po stronie hardware czy software Kontekst i zrozumienie biznesowego wykorzystania produktu bardzo ułatwia pracę (a jest krytyczne kiedy klient daje wolną rękę) Brak dokumentacji można skutecznie zamienić w TDD Raportuj nie tylko błędy ale i workaroundy i known issues

22 Dziękuję za uwagę