sobota, 17 września 2016

Testowanie systemów krytycznych dla bezpieczeństwa, wbudowanych i czasu rzeczywistego


Spis treści

Uwaga: to jest długi artykuł. Śpieszysz się? 
Najpierw obejrzyj tę animowaną prezentację:
 

  • Testowanie systemów krytycznych dla bezpieczeństwa, wbudowanych i czasu rzeczywistego. 1
  • Wprowadzenie do tematyki 3
  • Testowanie systemów krytycznych da bezpieczeństwa. 4
  • Skąd wybór tematu?. 5
  • Specyfika testowania systemów wbudowanych. 5
  • Na wielu platformach testowych. 6
  • Projektowanie aplikacji pod kątem możliwości testowania, również na środowisku docelowym.. 6
  • Równoległe projektowanie, tworzenie i testowanie sprzętu i aplikacji 7
  • Stosowanie języków niskopoziomowych, które wymagają od programistów dużej staranności i unikania błędów.. 8
  • Ze względu na ograniczoną dostępność testów w środowisku docelowym.. 8
  • Pełny nadzór, co jest testowane, w jakim środowisku. 9
  • Bardzo dokładne planowanie. 9
  • Używanie narzędzi, programistycznych i sprzętowych, umożliwiających bardzo dokładny oraz niskopoziomowy nadzór nad przebiegiem testów oraz ich wynikami 10
  • Bliskie związki testowania z debugowaniem, na dobre (współpraca) i złe (możliwa rywalizacja o dostęp do środowiska) 11
  • Nowość – testowanie zdalne przez łącze internetowe. 11
  • Jakie specjalne testy stosuje się dla systemów czasu rzeczywistego?. 14
  • Testy szybkości oraz czasowej przewidywalności nie tylko aplikacji, lecz również platformy sprzętowej i systemu operacyjnego. 14
  • Długotrwałe testy stabilności 14
  • Testowanie poprawności implementacji wymagań czasowych. 15
  • Testowanie niezawodności (MTBF) 15
  • Testowanie systemów krytycznych dla bezpieczeństwa. 16
  • Normy – warto je poznać. 16
  • Nacisk norm na zapobieganie, nie tylko na testy. 18
  • SIL a testowanie. 18
  • Jeszcze o testach systemów krytycznych dla bezpiueczeństwa. 18
  

Wprowadzenie do tematyki

Systemy wbudowane (albo: systemy kontrolne) = embedded systems (control systems), systemy krytyczne dla bezpieczeństwa = safety-critical systems, systemy czasu rzeczywistego (albo rzadziej: 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. 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. 
 
Ponieważ konsekwencje nieprawidłowego działania (awarii) systemów krytycznych dla bezpieczeństwa są bardzo wysokie, gdyż mogą oznaczać śmierć lub zranienie ludzi, dlatego proces ich tworzenia ma służyć zminimalizowaniu ryzyka (prawdopodobieństwa) awarii.
Mówiąc bardzo ogólnie, oznacza to wymaganie, żeby proces tworzenia takich systemów był staranniejszy niż proces tworzenia mniej krytycznych systemów. Z reguł te wymagania wobec procesu określają specyficzne dla danej branży normy / standardy. Te standardy określają zarówno wymagania bezpieczeństwa wobec produktu, jak i wymagania wobec procesu jego tworzenia, a także określają, w jak sposób producenci muszą udowodnić spełnienie tych wymagań.
 
Zasady inżynierii wymagań dla takich systemów nie różnią się zasadniczo od tych, które obowiązują dla innych systemów, ale muszą być w pełni przestrzegane, oraz wymagana jest możliwość potwierdzenia i udowodnienia, że są rzeczywiście przestrzegane.
 
Wymagania specjalne dla systemów krytycznych dla bezpieczeństwa są dwóch rodzajów: wymagania wobec produktów, oraz wymagania wobec procesu ich wytwarzania. Dla znakomitej większości tego rodzaju produktów istnieją międzynarodowe, obszerne i drobiazgowe normy, określające, jakie wymagania mają być spełnione, jakimi metodami i w jaki sposób musi się być w stanie potwierdzić ich przestrzeganie.
  

Testowanie systemów krytycznych da bezpieczeństwa

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.
Temat tego artykułu można by równie dobrze rozszerzyć na trzy obszary naraz: 1) testowanie systemów wbudowanych, 2) krytycznych jeśli chodzi o bezpieczeństwo oraz 3) czasu rzeczywistego, lub ograniczyć do ich części wspólnej – dość obszernej. Dodatkowo, możliwe byłoby omówienie osobno testowania oprogramowania, a osobno – platformy sprzętowej. Dla wielu systemów wbudowanych, złożoność, krytyczność i czasochłonność testowania zarówno elektroniki, jak i części mechanicznych systemu są znacznie bardziej wymagające, więc i ciekawsze, niż testy oprogramowania.
 
Ze względu na profil konferencji „Testwarez”, dla krórej artykuł został napisany, jak i na dostępny czas, nasz wybór padł na omówienie specyfiki testów wyłącznie oprogramowania, osobno dla aspektu wbudowania, osobno dla aspektu działania w czasie rzeczywistym, a osobno dla aspektu krytyczności dla bezpieczeństwa, choć oczywiście wiele konkretnych systemów jest jednocześnie wbudowanych, i krytycznych, i działająca w czasie rzeczywistym zarazem.
 

Skąd wybór tematu?


Ta tematyka jest ogromnie znacząca. Choć systemy wbudowane + krytyczne, które omawiam, to dziś ponad 60% systemów na świecie, a ich znaczenie dla jakości i bezpieczeństwa życia jest jeszcze większe, to ich specyfika jest osobom mieniącym się „testerami” zwykle nieznana. Z drugiej strony, nasi koledzy stamtąd, choć merytorycznie łączy nas niemal wszystko, naszych fascynacji i konferencji nie podzielają: mają swoje. Tester oprogramowania sterującego, na przykład, mechanizmem ABS hamulców samochodowych, ma za kolegów inżynierów z branży motoryzacyjnej, a nie innych testerów oprogramowania.
 
My, testerzy „niewbudowani” i „niekrytyczni”, możemy się od nich bardzo wiele nauczyć – i na to staramy się położyć nacisk w naszej prezentacji. Oni od nas też, ale to temat na inną konferencję, która dopiero się odbędzie.
   

Specyfika testowania systemów wbudowanych

Znacie model Kano? Nie, skądże, więc go streszczę: to jest taki kluczowy dla osób mieniących się odpowiedzialnymi za jakość model, dzielący wymagania na trzy grupy: na (1) wymagania zwykłe, na (2) „zachwycacze” i na (3) „rozwściekacze”.
 
Zachwycacze to te, których niespełnienie nikomu specjalnie nie doskwiera, ale kiedy choć w części się je zrealizuje, wywołują efekt wielkiego WOW. Te wymagania są ważne dla takich produktów IT, których zawodność i zwykłe bugi są do zaakceptowania, ale atrybut trafnie nazwany przez Jamesa Bacha „charyzmą”, choćby dostępny tylko trochę, zaraz wywołuje lawinę lajków. Do nich zaliczają się gadżety, telefony, gry, wszelkie fejsbuki, twitery oraz instagramy, a nawet zupełnie normalne aplikacje internetowe: sklepy, portale informacyjne i plotkarskie, i te pokazujące pogodę.
 
Natomiast dla systemów wbudowanych / krytycznych dominują rozwściekacze: cechy, których płynnego działania wręcz nie zauważamy, ale najmniejsze potknięcie ciężko przeżywamy, albo i nie przeżywamy, jeśli zawiedzie na przykład ABS w hamulcach, czy system sterowania ruchem kolejowym, czy rozrusznik serca. One są jak powietrze, dlatego ci, którzy je testują, są cisi, solidni, mało mówią i dobrze pracują, i mało mają czasu na uleganie mistycznym modom typu XP, TDD, eksploracja i inne. Kto się nie lansuje, tego nie ma?
  

Na wielu platformach testowych


Autorzy wielu programów już od pierwszej udanej kompilacji mogą je testować w środowisku docelowym. Budujący wielkie systemy administracyjne, czy bankowe, są w nieco gorszej sytuacji, ale i tam dostęp do środowiska ograniczają raczej względy organizacyjno-biznesowe, a nie bezwzględna, fizyczna niemożność.
 
Kiedy tworzy się (nie chce mi przejść przez wargi to komiczne nowe słówko „rozwija się”, oprogramowanie to nie nitka na szpulce) nowe urządzenie, wówczas nie można z pisaniem mającego nim sterować oprogramowania czekać, aż wszystko inne będzie gotowe, bo to by po pierwsze, strasznie przedłużyło cały projekt, a po drugie, częściowo działające oprogramowanie potrzebne jest także, aby pomóc testować sprawność samej platformy (elektronicznej, mechanicznej, hydraulicznej, cokolwiek tam mamy). Testuje się je więc wielokrotnie, zmieniając miejsca po drodze: najpierw na miękkim symulatorze procesora, albo i reszty całego układu, potem na tak zwanej karcie testowej (właściwy mikroprocesor, brak całej reszty), potem na właściwej karcie, ale jeszcze bez systemu, którego będzie częścią, wreszcie w gotowym systemie, ale ostrożnie: tak, by nikogo nie zabił, ani sam nie wyleciał w powietrze.
 
Praca domowa: jaki ma to wpływ na proces testowania, i czego możemy pozazdrościć i naśladować?
 

Projektowanie aplikacji pod kątem możliwości testowania, również na środowisku docelowym


Dla wielu, wielu z nas – testerów – propozycja, by stymulować system inaczej, niż przez klawiaturę, myszkę albo ekran dotykowy, a wyniki testów oglądać inaczej, niż na ekranie czy innym wyświetlaczu, jest niemal obrazoburcza. Jeśli wykonujemy test „INSERT Jan Kowalski”, to jak sprawdzamy jego wynik? Albo system sam uprzejmie wyświetla na ekranie „Jan Kowalski INSERTED”, a my w to wierzymy, albo robimy „FIND Jan Kowalski”, i… również wierzymy. Ale urządzenia wbudowane często nie mają ekranu, myszki, ani klawiatury. Niech nas nie zmyli smartphone: ma om wprawdzie wyświetlacz i ekran dotykowy, ale tylko do niektórych funkcji, cała reszta jest gołym okiem i gołym palcem niedostępna.
 
Co wtedy? Trzeba sięgać po przemyślne, czasem niełatwe w obsłudze narzędzia, twarde lub miękkie, dające nam dostęp do niewidocznych czeluści w głębi gadżetu. Dodatkowo, warto od samego początku ten gadżet i jego oprogramowanie projektować tak, żeby ten dostęp ułatwić, w przeciwnym razie będą kłopoty. Nam zdarzyło się nawiercać nieprzebijalne obudowy, lutować dodatkowe druciki na karcie, a na nich diody, żeby móc mierzyć chytrze schowany sygnał, a nawet mocować przylepcem czujniki urządzeń pomiarowych na dolnej stronie karty o dwustronnym montażu J. Efekt? Następnym razem, będzie się projektować tak, żeby nie utrudniać niepotrzebnie przyszłych testów. Jakie z tego warto wyciągnąć lessons learned?
 

Równoległe projektowanie, tworzenie i testowanie sprzętu i aplikacji


Kiedy w 1998 roku usłyszeliśmy po raz pierwszy o certyfikacji ISEB (tak się nazywał bezpośredni przodek ISTQB), wrażenie na nas zrobiła zarówno marketingowa genialność tego prostego pomysłu, jak i szereg podstawowych błędów w sylabusie. Notabene, nikt ich nie poprawił do dziś. Szczególnie efektowny jest najzupełniej niepoprawny, rażąco niefrasobliwy i głęboko wprowadzający w błąd podział testów na „czarną skrzynkę” i „białą skrzynkę”. Czemu niby biała skrzynka zatrzymuje się na poziomie kodu źródłowego aplikacji, skoro poniżej jest mnóstwo poziomów, będących dla przeciętnego programisty najprawdziwszą czarną skrzynką?
 
Budując urządzenie, nawet tak proste, jakie tkwi w pralce za 699 złotych, nie programuje się, i wobec tego nie testuje, chyba tylko mikroprocesora. Piętro wyżej jest ASIC – układ scalony wykonany specjalnie na potrzeby danego urządzenia. To droga rzecz, więc akurat w pralce raczej go nie zobaczymy. Testy jego projektu (symulowanego prototypu) spadają wprawdzie na inżyniera-elektronika, ale są to identyczne testy, jak nasze, miękkie. No, solidniejsze. Jednak potem taki ASIC jeszcze dodatkowo dotestowuje się na karcie, i tutaj nasz inżynier często prosi testera-programistę o napisanie specjalnie do tego celu dedykowanych kawałków kodu.
 
Kolejny poziom, to układy programowalne (FPGA). To z punktu widzenia testów to samo, co ASIC, tyle że mniej kosztowny i dający się łatwo przeprogramować. Typowe testowanie, takie samo, jak oprogramowania. Bezprzedmiotowość pytania, czy to biała, czy czarna skrzynka, rzuca się w oczy.
Programowaniem PROM zajmuje się już zwykle programista. Wiele systemów wbudowanych ma wyłącznie to oprogramowanie. Można je zmieniać, ale nie po dostarczeniu klientowi.
Testowanie na co najmniej czterech poziomach. Jednoczesne. Wnioski?
 

Stosowanie języków niskopoziomowych, które wymagają od programistów dużej staranności i unikania błędów


Może i Ruby wymyślono po to, by – cytuję – zapewnić szczęście programistom, ale wszystkie języki wysokopoziomowe, obudowane uszczęśliwiającymi środowiskami, powodują, że nie wiadomo, co tak naprawdę dzieje się w systemie. To wyklucza je z zastosowania dla systemów czasu rzeczywistego. Ponadto, są ogromnie zasobo-chłonne i pamięciożerne, co wyklucza je z wielu systemów wbudowanych. Trzeba pamiętać, że pamięć nie tylko kosztuje (dziś już niewiele), ale zajmuje miejsce i, co najgorsze, grzeje. Kto chciałby mieć kilkadziesiąt psujących się wentylatorków w samochodzie?
 
Czyli wracamy na poziom C++, C i asemblera. To, w połączeniu z wymaganiami niezawodności, odświeża, tak niemiłosiernie wydrwione przez Mistrzów Javy i innych miłośników kreatywności, znaczenie analizy statycznej oraz pomiarów pokrycia testowego kodu.
 
I powraca też staranne testowanie, także pod kątem braku bugów, a nie tylko UX (user experience), charyzmy i doświadczeń mistyczno-ludycznych.
 

Ze względu na ograniczoną dostępność testów w środowisku docelowym


Znacie te pięknie brzmiące zasady: nie paraliżować projektu zbyt precyzyjnymi wymaganiami, dostarczać MVP (minimalny możliwy produkt, minimum viable product), wyjść jak najwcześniej z częściowym choćby produktem do ludzi i w bezpośredniej interakcji z nimi sprawdzić, czy produkt im się podoba. Tak, mamy na myśli ten produkt wbudowany, pocisk typu cruise
 
Pośmialiśmy się? To dobrze, bo tak, jak groteskowo śmieszne jest stosowanie zasad budowania rakiet do tworzenia rozrywkowych portali, równie śmieszna – czy może tragiczna? – byłaby sytuacja odwrotna. Każde wbudowane oprogramowanie dla złożonego i potencjalnie niebezpiecznego systemu musi być w jakimś sensie zintegrowane skokowo – w pewnym momencie wszystko nagle musi działać.
 
To wymaga umiejętności testowania po kawałku, w różnych środowiskach symulowanych, oraz takiego projektowania testów integracyjnych, by uniknąć losu tej międzyplanetarnej misji, gdzie wstrząs wywołany rozłożeniem nóg lądownika wyłączył hamownice, lub tej, gdzie jeden system zaprogramowano w metrach, a drugi – w jardach.
 
Umiejętność realizacji stopniowych, wielopoziomowych testów integracyjnych tak, aby na koniec procesu wszystko chodziło jak w zegarku, może się przydać budowniczym nie tylko rakiet, ale też innych produktów.
 
Przy okazji – wbrew obiegowym opiniom, to nie wyklucza realizowania takich projektów częściowo w trybie agile, na poziomie, gdzie pracuje się w środowisku symulowanym.
 

Pełny nadzór, co jest testowane, w jakim środowisku


To jest kwestia organizacyjna, nie techniczna. Skoro testowanie przychodzi wykonywać w kilku różnych środowiskach, to po przemnożeniu liczby kombinacji przez liczbę regresji, otrzymuje się wynik wskazujący, że warto to dobrze zaplanować i podzielić, by uniknąć zarówno niebezpieczeństwa pominięcia tego, co przetestować należało, jak i niepotrzebnego i kosztownego dublowania. Czyli – nie wykluczając pewnego wykorzystania testów eksploracyjnych, jako możliwego uzupełnienia – testy trzeba starannie zaprojektować i opisać zawczasu, i odpowiednio je rozplanować w czasie.
 
W sytuacji, gdy koszty wykonywania każdego z testów są znaczne, bo sumują się koszty tak samych środowisk, jak i czasochłonnego ich wykorzystania, nie mamy ochoty przedłużać tego kosztownego procesu, wykrywając potrzebne wymagania, testując na chybił-trafił, metodą prób i błędów.
Systemy wbudowane likwidują w pewnej mierze charakterystyczną cechę oprogramowania, czyli względną taniość (czasem złudną!) wykonywania zmian, w porównaniu z branżami, działającymi w mniej plastycznej materii. To powoduje, że wyraźniejsza niż na innych obszarach IT staje się przewaga zapobiegania, zamiast naprawiania, jako sposobu osiągnięcia potrzebnej jakości.
 

Bardzo dokładne planowanie


Dla oprogramowania wbudowanego maleje, czasem znika zupełnie zasada, żeby jak najszybciej wejść z pierwszą wersją na rynek i zdobyć klientów, a potem dostarczać kolejne wersje.
Nie tylko koszty awarii bywają kosmiczne, ale możliwości naprawy w tak zwanym środowisku produkcyjnym, może w ogóle nie być.
 
Krzywa Boehma, w czasach sekwencyjnych oficjalnie poważana, ale w praktyce ignorowana, w czasach iteracyjno-zwinnych doczekała się słusznych, także teoretycznych zastrzeżeń, że wypacza obraz biznesowej opłacalności starań o zdobycie precyzyjnych wymagań z góry, mówiąc tylko o kosztach zmiany/naprawy, a pomijając koszty, czy wręcz niemożność, uzyskania dobrych wymagań na samym początku, bez prototypowania. Niemniej, nie oznacza to, że krzywa Boehma przestała obowiązywać, a systemy, które wysyłamy na inne planety, na dno Rowu Mariańskiego, czy nawet tylko 200 metrów pod powierzchnię morza i platformy wiertniczej, mocno nam o tym przypominają.
 

Używanie narzędzi, programistycznych i sprzętowych, umożliwiających bardzo dokładny oraz niskopoziomowy nadzór nad przebiegiem testów oraz ich wynikami


Jak już pisaliśmy, tradycyjny, miękki tester, z trudem uznaje potrzebę stosowania innych narzędzi do wprowadzania i rejestrowania wychodzących z systemu danych, niż myszka, klawiatura, joystick, ekran i głośniki. Niemniej, wykonując testy, dajmy na to, odporności systemu na burze piaskowe, pewnie weźmie do ręki dmuchawę piasku, jednak z poczuciem, że to trochę śmieszne i niepoważne narzędzie… w porównaniu z takim Selenium, JTest, JMeter, Quality Center, albo Cucumber!
Natomiast narzędzia sprzętowe, elektroniczne, budzą zwykle u miękkiego testera podziw, ale i przerażenie, niczym operacja na otartym sercu, zaproponowana wizażyście.
 
Testerzy oprogramowania wbudowanego muszą się jednak nimi posługiwać, żeby w ogóle móc testy uruchomić, ale też żeby wiedzieć, co ono tam w środku porabia. Czym różni się wynik 9 od wyniku 8, ale nie na ekranie, bo go nie ma, tylko na 4-bitowej magistrali? 9, to binarne 1001, zaś 8, to binarne 1000 – różni je wartość bitu po prawej stronie. Można to zmierzyć – nie bójmy się brzydkiego słowa – oscyloskopem!
 
To samo zadanie, tylko w drugą stronę – jak bez klawiatury wepchnąć do środka maszyny wartość 7? No cóż, trzeba nałożyć 3V napięcia na następujące bity: 0111. To umożliwia generator sygnałów.
To samo zadanie, co oscyloskop, ale jednocześnie dla całej magistrali adresowej, danych lub instrukcji, wykonuje analizator logiczny.
 
ICE – debuger sprzętowy – pozwala do celów testowania dokładnie widzieć i manipulować czynnościami mikroprocesora.
 
JTAG (skrót ładnie brzmiącej nazwy Joint Testing Action Group) służy do testów prawidłowości podłączenia układów scalonych, ale przydaje się i testerom.
 

Bliskie związki testowania z debugowaniem, na dobre (współpraca) i złe (możliwa rywalizacja o dostęp do środowiska)


Poprzedni akapit pokazał urządzenia, w pierwszym rzędzie służące do debugowania, jako groźne narzędzia testerskie. To prawda – każde z nich wykorzystuje do badania tego, co dzieje się wewnątrz komputera zarówno inżynier-elektronik, jak i programista, szukający przyczyny awarii.
 
Programista systemów wbudowanych pracuje w środowisku innym, niż docelowe. Bugi, powodujące awarię w środowisku docelowym, też nie zawsze ujawniają się w symulowanym. Wobec tego debugowanie musi się czasem odbywać w środowisku docelowym. O ile symulowane daje się niedrogo powielać, o tyle docelowe bywa kosztowne i odstęp do niego staje się towarem „deficytowym”, jak mawiano w czasach PRL. Wtedy dostęp do niego trzeba racjonować, stosować listy kolejkowe, pilnować porządku. Tej idealnie konfliktogennej sytuacji zapobiegać musi albo przewidujący ją szef, albo narzędzie do rezerwacji i kontroli dostępu do środowiska testowego – warto się o nie postarać.
 
Podobne kłopoty występują także w testach miękkich wszędzie tam, gdzie o dostęp do środowiska docelowego, lub prawie-docelowego (przedprodukcyjnego) rywalizuję różne osoby – na przykład w bankach, w dużych portalach informacyjnych. Organizacji dostępu do nich można się uczyć od naszych wbudowanych kolegów.
 

Nowość – testowanie zdalne przez łącze internetowe


Kiedy w laboratorium testowym stoi takie urządzenie, jak centrala telefoniczna, chłodzenie utrzymuje w pomieszczeniu stałą temperaturę 19o, co jest bardzo miłe latem, ale nieprzyjemne zimą. Ponieważ jednak testy, wykorzystujące centralę telefoniczną, wykonuje często nawet kilkadziesiąt osób, dostęp zdany staje się koniecznością, niezależnie od pory roku.
 
Podłączając urządzenia, wykorzystywane do testowania, do internetowego łącza, oraz oczywiście nadzorując, kto i kiedy z niego ma prawo korzystać, można umożliwić zdalny dostęp i zdalne testowanie nawet dla naprawdę małych urządzeń wbudowanych, nie mających nawet tych interfejsów dostępowych, które oferuje centrala telefoniczna.
 
Nie każdy oscyloskop czy ICE daje się łatwo podłączyć do Internetu wprost. Dobrym rozwiązaniem jest podłączenie tych urządzeń – zwykle przez specjalne łącze zwane GPIB – do komputera, zaopatrzonego w specjalne sterowniki GPIB, i program do zarządzania nimi. Ten komputer powinien być także dostępny jako serwer przez Internet.

    

Jakie specjalne testy stosuje się dla systemów czasu rzeczywistego?

Systemy czasu rzeczywistego nie muszą być specjalnie szybkie. To, co odróżnia je od innych systemów, to wymóg, aby pewne czynności odbyły się w określonym przedziale czasowym, albo trwały nie dłużej i nie krócej, niż pewna liczba nano-, mili-, albo sekund.
 
Dla innych systemów powolne działanie to problem z zakresu osiągów: dotkliwy, nawet dyskwalifikujący pod względem biznesowym, ale nie powodującym awarii funkcjonalności. Zbyt szybkie działanie – takie cuda się czasem zdarzają – to problem z zakresu interakcji / użyteczności / HCI. Dla systemów czasu rzeczywistego, brak zgodności z wymaganiami czasowymi, powoduje niepoprawne funkcjonowanie, albo zupełną awarię systemu.
 

Testy szybkości oraz czasowej przewidywalności nie tylko aplikacji, lecz również platformy sprzętowej i systemu operacyjnego

  
Podobnie jak dla testów osiągów, testów systemu czasu rzeczywistego nie wystarczy przeprowadzić raz, w korzystnych warunkach. Ważne, że wymagania czasowe spełnia w różnych sytuacjach i pod różnym obciążeniem także platforma sprzętowa (nie tylko „komputer” - elektronika, ale także elementy mechaniczne, chemiczne, elektryczne, wszystkie, które mają razem działać w czasie rzeczywistym), oraz system operacyjny.
 
W różnych sytuacjach – także pod obciążeniem, lub przy braku danych. W formie fabularnej, możliwe zagrożenia tych właściwości, biorące się nawet ze specyfiki procesu wytwarzania, znakomicie opisuje „Ananke” Stanisława Lema.
 

Długotrwałe testy stabilności

  
Przetestowanie, dostatecznie staranne, wymagań podanych na poprzedniej ilustracji, wymaga z reguły testów długotrwałych, zwanych czasem testami stabilności.
  
Aby osiągnąć potrzebny rozrzut i zróżnicowanie obciążenia, niekiedy dane testowe do tego celu generuje się automatycznie.
  

Testowanie poprawności implementacji wymagań czasowych

  
W systemach czasu rzeczywistego występują pewne typy awarii, nie mające odpowiednika w systemach, dla których czynnik synchronizacji czasowej nie ma znaczenia. Można im zapobiegać poprzez odpowiednie projektowanie, ale potrzebne są także testy dla dodatkowej kontroli, że takie sytuacje dla danego systemu nie występują. Trzeba je rozumieć, aby móc pod ich kątem zaprojektować testy.
 
„Deadlock” (wzajemne blokowanie): dwa procesy wzajemnie czekają na siebie, a brak time-out powoduje, że zatrzymanie trwa w nieskończoność.
 
„Resource starvation” oznacza, że proces o niskim priorytecie zbyt rzadko i na zbyt krótko uzyskuje dostęp do potrzebnych mu zasobów, w związku z czym zatrzymuje się, lub działa błędnie, lub zbyt wolno.
 
„Priority inversion” to dość zawiła sytuacja, w wyniku której do głosu, zamiast czekającego procesu o najwyższym priorytecie, dochodzi proces o niższym priorytecie; zapobiega się jej poprzez odpowiednie manipulowanie obsługą przerwań.
 
„Race conditions” to sytuacja, kiedy przez to, że jeden proces – wbrew intencjom programisty – zdąży zmienić wartość semafora przez innym procesem, system podejmuje błędne działania.
 

Testowanie niezawodności (MTBF)

 
Zasady testowania niezawodności (inne nazwy: Statistical Usage-Based Testing, Reliabiilty Testing) zakładamy są znane czytelnikom.
 
Wielokrotnie, niepoprawne działanie systemu może się zdarzać od czasu do czasu (nie jest zero-jedynkowe między „zawsze” a „nigdy”), byle niezbyt często. Jak często? – to określa wymaganie sformułowane jako MTBT, albo MTTF. Testowanie niezawodności sprawdza, czy – na pewnym poziomie statystycznej istotności – to wymaganie jest spełnione.
    

Testowanie systemów krytycznych dla bezpieczeństwa

Systemy krytyczne dla bezpieczeństwa (ang. safety-critical) to takie, których niepoprawne działanie, lub awaria, może stanowić bezpośrednie zagrożenie dla zdrowia i życia ludzi.
 

Normy – warto je poznać

 
Ta celowo nieczytelna ilustracja poniżej, wskazuje z jednej strony na wielość obszarów, gdzie mamy do czynienia z systemami krytycznymi dla bezpieczeństwa, a z drugiej strony, na zbędne, uzasadnione historią branżowych odrębności, oddzielne (i redundantne) opisywanie tych samych zasad w wielu różnych miejscach.


 

Nacisk norm na zapobieganie, nie tylko na testy


Testowanie jest swego rodzaju strażą pożarną: odkrywa awarie tam, gdzie nie powinno ich w ogóle być. W społeczności, aby obniżyć ryzyko pożaru, nie mnoży się liczby ani intensywności patroli straży, tylko stosuje szereg kroków zapobiegawczych (które nb. straż pożarna może nadzorować, ale tylko mając szczególne kompetencje i odpowiednie uprawnienia).
Ta sama zasada dotyczy systemów krytycznych szczególnie, że wykrywane bugi dotyczące bezpieczeństwa, często nie dają się łatwo naprawić, lecz wymagają gruntownej rekonstrukcji zasad budowy systemu.
 

SIL a testowanie


SIL (Safety Integrity Level) to miara, określające jak „bezpieczny”, czyli mający niezbędne dla bezpieczeństwa funkcje i właściwości, dostatecznie niezawodne.
 
Miarą SIL są dla danego możliwego zagrażającego zdarzenia: jego konsekwencje x prawdopodobieństwo x dostępne czynności ratunkowe (zmniejszające skutki).
 
SIL dla jednoczesnej awarii wszystkich silników w samolocie jest różny dla samolotu wojskowego i pasażerskiego, mimo że ryzyko może być identyczne, ponieważ ten pierwszy wyposażony jest w katapultę i spadochron, a drugi nie. Dlatego w odniesieniu do samolotów pasażerskich wymagane jest znacznie mniejsze prawdopodobieństwo takiej awarii.
 
Wielkość SIL określają specjaliści branżowi, a jego wielkość wpływa na wymagania bezpieczeństwa i niezawodności komponentów, co określa m.in. niezbędną staranność testowania.
 

Jeszcze o testach systemów krytycznych dla bezpieczeństwa

   
Analiza bezpieczeństwa jest całościowa – nie tylko miary niezawodności komponentów IT. Analiza musi być zawsze wykonywane łącznie, przez specjalistów w różnych dziadzin, nie ma ona sensu osobno w odniesieniu do samego oprogramowania.
   
Normy bezpieczeństwa wymagają wykonywanie testów statycznych, w tym analizy statycznej kodu certyfikowanymi narzędziami.
  
Normy bezpieczeństwa wymagają osiągnięcia określonych poziomów pokrycia kodu testami, różnych dla różnych poziomów SIL. Pomiar pokrycia musi być wykonany przez certyfikowane narzędzia. 
   
Istnieje, wyglądające paradoksalnie, pewne podobieństwo między systemami wymagającymi wysokiej „charyzmy” (jak gry, portale plotkarskie itp.), a systemami krytycznymi dla bezpieczeństwa. Dla obu drobiazgowe testowanie nie wystarcza, aby ocenić to, co najważniejsze. Dla systemów charyzmatycznych, to poziom UX (user experience), a dla bezpiecznych – czynniki organizacyjne i psychologiczne, w tym HCI, mogące sprowadzić niebezpieczeństwo dla użytkownika systemu, przetestowanego jako dostatecznie niezawodny.
   
Automatyzacja testów - tylko wyniki testów wykonanych przez certyfikowane narzędzia, traktowane są jako miarodajne, dostateczne. Certyfikuje się zarówno poziom inwazyjności narzędzia, jego wiarygodność oraz trafność (accuracy) i dokładność (precision) wyników.

Brak komentarzy:

Prześlij komentarz