Prowadzący opowie o testowaniu hardware od projektowania układów, przez testy BIOS i sterowników do biznesowego wykorzystania przez zewnętrzne moduły i aplikacje. Główny nacisk prezentacji będzie położony na: – specyfika testów hardware – jak projektować i o czym należy pamiętać podczas tworzenia testów – tworzenie fizycznego środowiska testowego – budowa symulatorów, praca ze wczesnymi wersjami sprzętu i typowe wyzwania jakie stoją przy stworzeniu dobrego laboratorium testów – automatyzacja procesu testowego zarówno od strony kodu jak i sprzętu – mierzenie performance sprzętu (na przykładzie performance transferów sieciowych) – wyzwania i błędy, których nie spotyka się przy innych rodzajów testów Prezentacja będzie casestudy problemów i rozwiązań jakie autor napotykał w swojej pracy zawodowej. Na potrzeby prezentacji stworzony zostanie ‚wirtualny startup’ tworzący nowy sprzęt związany z najnowszymi technologiami nagrywania i encodowania obrazów 4k oraz szybkich transferów sieciowych. Będzie on tworzył autonomiczną jednostkę podobną do popularnych dziś „Rasberry PI” czy innych mini komputerów. Prowadzący wystąpi w roli lidera zespołu, na którego spłynęła odpowiedzialność kompleksowego przetestowania urządzenia począwszy od jego konstrukcji, przez bios i inne oprogramowanie do zmierzenia performance i możliwości technicznych nowego urządzenia. Opowie o specyficznym podejściu jakie należy mieć przy testowaniu nowego sprzętu oraz o nietypowych błędach i wyzwaniach jakie stoją przed zespołem validującym jakość hardware. Główne tezy prezentacji: – hardware jest dodatkową zmienną do uwzględnienia przy projektowaniu testów i wymaga tak samo dokładnych testów jak software – testowanie hardware ma swoją unikalną specyfikę i podobnie jak testowanie aplikacji mobilnych czy webowych wymaga specjalistycznej wiedzy – przy testowaniu należy nie tylko mieć rozbudowaną skrzynkę narzędziową ale również doskonale znać możliwości i ograniczenia każdego narzędzia – zawsze należy znać kontekst i big picture. Testowanie tylko drobnego fragmentu bez zrozumienia jego zależności i zastosowania jest stratą zasobów i nie gwarantuje jakości.

1. 1
Testing hardware
Paweł Noga
Testwarez 2015-10-08

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

8. Laboratorium testów

9. Laboratorium testó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


10. Laboratorium testó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

Powtarzalność /
reprodukowalność
Odtwarzalność
Konfigurowalność Skalowalność
Stabilność
Łatwość
fizycznego
dostępu
Możliwość pracy
zdalnej
Bezpieczeństwo
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
Testowane
urządzenie 1
Testowane
urządzenie 2
Testowane
urządzenie 3
Zautomatyzowany scenariusz
Narzędzie
(klasa + metody)
Core: ssh, cmd,
regex, log, xml
konfiguracja XML

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

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
raporto-
wania
testów

17. 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

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. 22
Dziękuję za uwagę
pawel.noga@solwit.com