czwartek, 17 lipca 2014

Opowiem na Testwarez o testach systemów krytycznych



Testowanie systemów krytycznych dla bezpieczeństwa, wbudowanych i czasu rzeczywistego: uzasadnienie wyboru tematu


Systemy wbudowane (albo: systemy kontrolne) = embedded systems (control systems), systemy krytyczne dla bezpieczeństwa = safety-critical systems, systemy czasu rzeczywistego (albo: systemy nadążne) = real-time systems. Systemy krytyczne dla bezpieczeństwa są z reguły systemami wbudowanymi, wiele z nich jest także systemami czasu rzeczywistego.

Nie rzucają się w oczy tak, jak obecne wszędzie laptopy, tablety i smartfony, ale naprawdę jest ich znacznie od nich więcej: systemów wbudowanych, sterujących dziesiątkami miliardów urządzeń: pralek automatycznych, pomp paliwowych, samochodów, wind, instrumentów medycznych, robotów przemysłowych, statków i samolotów.

Nie pisze się o nich tak wielu socjologicznych dysertacji jak o Facebook ’u, Twitterze i Google, ale zmieniają one świat, w którym żyjemy, o wiele bardziej: systemy krytyczne dla bezpieczeństwa, którym codziennie – nie myśląc o tym – powierzamy i zawdzięczamy nasze życie i zdrowie.

Nie generują takiej masy tajemniczo brzmiącej terminologii jak wielkie zbiory danych (big data), ale to one właśnie tworzą większość tej oszałamiającej masy danych: systemy czasu rzeczywistego, pozwalające elektronice i oprogramowaniu reagować na zmiany środowiska niemal tak zwinnie i szybko, jak organizmy żywe, dzięki czemu świat zaludniają już dziś miliardy robotów, wykonujących zamiast ludzi prace szczególnie uciążliwe, trudne i niebezpieczne.

Firmom, tworzące produkty zawierające takie właśnie systemy - choć nie jest o nich tak głośno jak o informatycznych molochach, tworzących nieporadne systemy IT, które nam wszystkim utrudniają życie – tym firmom właśnie zawdzięczamy w ogromnym stopniu sukcesy polskiej gospodarki, eksportującej coraz skuteczniej wysoką technologię światowej klasy.

Awarie systemów krytycznych dla bezpieczeństwa są szczególnie tragiczne i bolesne, takie jak na przykład katastrofa w Smoleńsku. Przyczyną tej i wielu podobnych awarii nie była jednak zawodność technologiczna, lecz nieumiejętność uwzględnienia w ich projektowaniu czynników psychologicznych, przez co wzrasta ryzyko niepoprawnych działań ich operatorów, zwłaszcza w stresie.  


Opis
Testowanie systemów krytycznych da bezpieczeństwa spełnia dwa podstawowe zadania: jest dowodem na to, że gotowy system rzeczywiście ma określoną wymaganiami funkcjonalność, niezawodność oraz inne, znaczące dla bezpieczeństwa atrybuty jakości, oraz służy wykrywaniu defektów systemu, dzięki czemu możliwe jest ich usunięcie i osiągnięcia wymaganego poziomu jakości.
Nie wszystkie decyzje dotyczące wymaganej staranności testowania oraz jego metod pozostawione są producentom – wiele z nich określają standardy dla produkcji danego rodzaju systemów.

Korzyści
Słuchacze poznają sposoby organizacji procesu testowego, w tym techniki projektowania przypadków testowych, możliwości oraz ograniczenia automatyzacji oraz budowę środowisk testowych dla wbudowanych systemów krytycznych dla bezpieczeństwa.

Grupa docelowa
Osoby, wykonujące lub mające wykonywać testy systemów krytycznych dla bezpieczeństwa, a także osoby odpowiedzialne za ich organizację i nadzorowanie.

Tematyka
·         Definicja, zakres, specyfika dla testowania: systemy krytyczne dla bezpieczeństwa
·         Definicja, zakres, specyfika dla testowania: systemy wbudowane / kontrolne
·         Definicja, zakres, specyfika dla testowania: systemy czasu rzeczywistego
·         Przegląd norm branżowych dotyczących systemów krytycznych dla bezpieczeństwa
·         Co mówią normy na temat zalecanych metod testowania?
·         Środowiska testowe (środowisko wytwarzania, środowisko docelowe, karta testowa, karta docelowa w środowisku testowym, wirtualizacja testów)
·         Narzędzia stosowane w testowaniu: symulatory, emulator architektury, symulator mikroprocesora (instruction set simulator), karta testowa, debugery, debuger sprzętowy, ICE, inne instrumenty pomiarowe i generatory sygnałów
·         Protokół GPIB (IEEE-488) w testowaniu
·         Narzędzia wspomagające testowanie na przykładzie LabView
·         Dostęp do systemu docelowego, śledzenie przebiegu wykonywania programu, pomiary pokrycia, monitorowanie (analiza dynamiczna), testy po uruchomieniu, testy produkcyjne
·         Inwazyjność narzędzi testowych – miarodajność wyników testów dla bezpieczeństwa
·         Przeglądy kodu źródłowego: cele, zakres, metody
·         Analiza statyczna kodu źródłowego: zakres, korzyści, metody, narzędzia
·         Pomiary pokrycia kodu źródłowego w testach jednostkowych – cele i korzyści, wymagania standardów
·         Pomiary pokrycia kodu źródłowego w testach jednostkowych – techniki i narzędzia
·         Automatyczne generowanie testów jednostkowych – cele, metody, narzędzia
·         Automatyczne generowanie testów funkcjonalnych z modeli wymagań
·         Konieczność automatycznego wykonywania testów – ograniczenia wymagane przez standardy
·         Testowanie atrybutów niefunkcjonalnych – niezawodności i odporności na błędy
·         Testowanie aspektów czasu rzeczywistego oraz osiągów i wydajności
·         Testy eksploracyjne systemów krytycznych dla bezpieczeństwa – korzyści, możliwy zakres

Brak komentarzy:

Prześlij komentarz