Testing hardware

1

Testing hardwarePaweł Noga

Testwarez 2015-10-08

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

Co będziemy testować?

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))

Współpraca z klientem


Zapewnijcie mi jakość


Zapewnijcie mi jakość

Rozpoznanie narzędzi do pomiarów

Budowa laboratorium testów i jego

utrzymywanie

Propozycje scenariuszy i konfiguracji

Utrzymywanie wiki z

instrukcjami i workaroundami

Automatyzacja testów

Raportowanie wyników, zgłaszanie

błędów

Laboratorium testów



Prototypy

Sprzęt w różnych

konfigura-cjach (Device Under Test)

Narzędzia wsparcia

(KVM, WDS, Clonezilla,

Powerswitch)

Kontrolery testów i

narzędzia do debugowania

Dużo części zapasowych



Prototypy

Sprzęt w różnych

konfigura-cjach (Device Under Test)

Narzędzia wsparcia

(KVM, WDS, Clonezilla,

Powerswitch)

Kontrolery testów i

narzędzia do debugowania

Dużo części zapasowych

Powtarzalność / reprodukowalność Odtwarzalność

Konfigurowalność Skalowalność

StabilnośćŁatwość

fizycznego dostępu

Możliwość pracy zdalnej Bezpieczeństwo

Opis / Dokumentacja

Łatwość w zarządzaniu i przydzielaniu

Automatyzacja

Automatyzacja

Narzędzie (klasa + metody)

Core: ssh, cmd, regex, log, xml konfiguracja XML

Automatyzacja

Zautomatyzowany scenariusz



Automatyzacja

Kontroler

Testowane urządzenie 1






Automatyzacja

Kontroler







RAPORT

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 raporto-

wania testów

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 raporto-

wania testów

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

Klient narzucił kilka własnych, które nie mierzyły tego co trzeba

(np. przesyłały pliki, a nie strumieniowały)

„co jest ważne” zmieniało się wielokrotnie – przez

co priorytety nie były stabilne

Kontekst od „chcemy znać dla różnych parametrów

zachowanie systemu” przeszedł do „znajdźcie taką

konfigurację gdzie wyniki będą najlepsze”

Czasem nie ma na czym testować

O czym jeszcze nie pomyśleliśmy?

Stabilność testowanego

sprzętu

Praca ma sens jeśli jest odpowiednio wykorzystana

Zestawienia, porównywanie buildów,

jasne deklarowanie gdzie jesteśmy względem

oczekiwań

Nieznane było finalne użycie biznesowe

Mnogość konfiguracji:Wersje OS, platform (dronów) sprzętu, etc

Ciekawe błędy

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)

Wnioski

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ę

[email protected]

Testing hardware

Devices & Hardware

Transcript of Testing hardware