Manualne testowanie dekoderów

8814
wyświetleń
Manualne testowanie dekoderów
Zapraszamy do lektury artykułu autorstwa Sylwii Bartman o testowaniu dekoderów.
 
Abstrakt: Artykuł przedstawia zagadnienie dotyczące manualnego testowania dekoderów powszechnej obecnie telewizji cyfrowej. Skupia się na rodzajach testów jakim poddawany jest dekoder zanim trafi do sprzedaży. Omówione zostały również narzędzia wykorzystywane w testowaniu.
 
 
1. Wprowadzenie – dekoder – definicja i zasada działania
 
W jednym z portali poświęconych zagadnieniom informatyki [1] przeczytać można następującą definicję dekodera: „Dekoderem nazywamy układ cyfrowy majacy n wejść oraz k  wyjść, przy czym k = 2n. Na wejściu podajemy zakodowany numer wyjścia, na którym ma się pojawić wyróżniony sygnał (0 lub 1). Na pozostałych wyjściach powinna się pokazać wartość przeciwna. Dekoder działa odwrotnie niż koder, tzn. zamienia kod binarny na jego reprezentację w postaci tylko jednego wybranego wyjścia. Jako przykladowy układ dekodera można wymienić bramkę AND ponieważ aby uzyskać na wyjściu „1” to na wejście muszą być podane tylko wartości „1”.” W kontekście telewizji cyfrowej dekoder definiuje się inaczej. W książce Gerald’a O’Driscolla pt. „The essential guide to Digital Set-top Boxes and Interactive TV” [2], czytamy, że dekoder zwany jako STB (Set-Top Box), jest konsumenckim urządzeniem elektronicznym, używanym do dekodowania i strojenia sygnałów cyfrowych oraz ich konwersji do formatu, który jest zrozumiały przez Twój telewizor. Pierwotne cechy STB O’Driscoll klasyfikuje następująco: (1) dekodowanie sygnału przychodzącego; (2) weryfikacja praw dostępu i bezpieczeństwa; (3) wyświetlenie kinowej jakości obrazów w odbiorniku telewizyjnym; (4) posiadanie na wyjściu cyfrowego sygnału przestrzennego; (5) przetwarzanie i renderowanie interaktywnych usług internetowych i telewizyjnych. W satelitarnym STB, tuner otrzymuje satelitarną transmisję i dokonuje ekstrakcji poszczególnych kanałów. Następnie demodulator otrzymuje sygnał i konwertuje go do binarnej postaci. Może także dokonać sprawdzenia błędów. Oczyszczony sygnał jest wysyłany do demultipleksera gdzie, audio, video i dane są izolowane z sygnału i sekwencyjnie wysyłane do odpowiedniego dekodera. Demultiplekser może określać również prawa dostępu do określonych usług. Funkcją dekoderów jest transformacja odpowiednich przychodzących strumieni binarnych do odpowiednich widocznych formatów telewizyjnych.
 
 
2. Testy manualne – rodzaje testów jakim poddawany jest dekoder
 
Podobnie jak inne urządzenia, dekoder STB musi przejść szereg różnych testów zanim trafi do sprzedaży. I w tym miejscu należy odpowiedzieć sobie na pytanie czym właściwie testowanie jest. Cytując wg standard [3], testowanie jest procesem składającym się z wszystkich czynności cyklu życia, zarówno statycznych jak i dynamicznych; skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów w celu określenia czy spełniają one wyspecyfikowane wymagania oraz wykazania, że są one dopasowane do swoich celów oraz do wykrywania usterek. Testowaniem nazywamy proces walidacji i weryfikacji oprogramowania, z którego ma wynikać, że spełnione zostały biznesowe i techniczne wymagania.
 

Czym zatem jest walidacja? Walidacja to testowanie zgodności systemu z rzeczywistymi potrzebami użytkownika – walidacja ma odpowiedzieć na pytanie czy zrobiliśmy dobry produkt. Weryfikacją natomiast jest testowanie zgodności systemu z wymaganiami określonymi w specyfikacji  - weryfikacja ma odpowiedzieć na pytanie czy produkt wykonaliśmy dobrze.

Testowanie manualne to przede wszystkim testowanie wykonywane w oparciu o model czarnej skrzynki i, polega ono głównie na testowaniu funkcjonalnym oraz niefunkcjonalnym bez odniesienia do wewnętrznej struktury modułu lub systemu. Rola testera testów manualnych polega na tym, że otrzymuje on dekoder STB, pendrive ze zbudowaną wersją oprogramowania, które ma przetestować. Ma przygotować sobie środowisko testowe tzn. połączyć dekoder z odtwarzaczem strumienia audio-video, zainstalować oprogramowanie, które ma testować – w żargonie testersko-developerskim mówi się, że ma „sflaszować” STB. Następnie korzystając z pilota zdalnego sterowania oraz przycisków - już w samym STB - ma wykonać uprzednio przygotowane scenariusze testowe. Tester nie wnika w to co dzieje się z kodem programu. Jeżeli, któryś ze scenariuszy kończy się porażką czyli oczekiwane wyniki różnią się od rzeczywistych, zgłasza to w specjalnie dedykowanym programie śledzenia błędów (np. Bugzilla, Jira) jako błąd podając dokładny scenariusz zreprodukowania błędu.

Jak już wcześniej wspomniano, dekoder musi przejść szereg różnych testów zanim uzna się, że jest on zdatny do sprzedaży. Najważniejsze z nich zostały opisane poniżej. Definicje zostały zaczerpnięte ze słownika testerskiego [4]. I tak, testy wymagań nazywane również testowaniem opartym na wymaganiach, jest to podejście do testów, w którym przypadki testowe są projektowane w oparciu o cele testów i warunki testowe zawarte w wymaganiach np. testy sprawdzające konkretne funkcje lub badające niefunkcjonalne wymagania systemu takie jak niezawodność lub użyteczność. Wśród przykładów wymienić można:

  • użytkownik powinien mieć możliwość włączenia i wyłączenia wyświetlenia napisów;
  • użytkownik powinien mieć możliwość wyboru języka wyświetlanych napisów: hiszpański, portugalski, niemiecki, angielski;
  • użytkownik powinien mieć możliwość usunięcia ręcznego swoich lub automatycznie ustawionych nagrań.
 

Kolejne testy to testy regresyjne, nazywane również testowaniem regresywnym. Polega ono na ponownym przetestowaniu uprzednio testowanego programu po dokonaniu w nim modyfikacji, w celu upewnienia się, że w wyniku zmian nie powstały nowe defekty lub nie ujawniły się defekty w niezmienionej części oprogramowania. Zazwyczaj tego typu testy przeprowadzane są po zmianach oprogramowania lub jego środowiska pracy. Przykłady takich testów:

  • zmiana w funkcji dotyczącej kontroli rodzicielskiej spowodowała/ujawniła defekty w funkcji dotyczącej nagrywania;
  • zmiana w funkcji dotyczącej napisów (ang. subtitles) spowodowała/ujawniła defekty w funkcji dotyczącej wyboru języka audio (lektor);
  • zmiana w funkcji ustawiania obrazu w formacie 16:9 (ang. aspect ratio) spowodowała/ujawniła defekty dotyczące ustawienia obrazu w formacie 4:3.
 

Następny typ testów to retesty, czyli testowanie polegające na uruchomieniu przypadków testowych, które podczas ostatniego uruchomienia wykryły błędy w celu sprawdzenia poprawności naprawy. Równie ważne jak wymienione powyżej są testy instalowalności, nie jest to nic innego jak proces testowania instalowalności oprogramowania. Następnie będą to testy integracji modułów, tzn. testy wykonywane w celu wykrycia usterek w interfejsach oraz interakcjach pomiędzy integrowanymi modułami. I ostatnie, testy kompatybilności, polegające na testowaniu współdziałania, w celu określenia współdziałania oprogramowania. Jako przykład może tu posłużyć testowanie dekodera STB z różnymi modelami telewizorów.

Zanim jednak tester wykona wyżej wymienione testy, wcześniej przygotować musi odpowiednie przypadki testowe, o czym jest mowa w następnej części niniejszej pracy.

Projektowanie przypadków testowych. Tester posiadając znane wymagania funkcjonalne, niefunkcjonalne oraz specyfikację EPG (ang. Electronic Programming Guide), przystępuje do projektowania przypadków testowych. Jako przykład niech posłuży nam przypadek testowy, którego celem jest sprawdzenie czy dekoder pozwala użytkownikowi obejrzeć listę nagrań. Poniżej zaprezentowane są dwie tabelki,pierwsza z nich zawiera wymaganie funkcjonalne dotyczące nagrywania, natomiast druga tabelka zawiera szczegółowy opis przypadku testowego:
 
 
 
 
 
Poniżej znajduje się podsumowanie wyników -, procentowe oraz szczegółowe określające konkretną liczbę przeprowadzonych testów: ile przeszło pomyślnie, ile nie, ile jest w trakcie, ile testów nie wykonano (podane wartości stanowią jedynie przykład i dlatego nie podana została ich interpretacja).
 
Tabela 3. Przykładowa reprezentacja graficzna podsumowania wyników testów – opracowanie własne
 
 
Testowanie nie mogłoby się odbyć bez wykorzystania do tego celu dedykowanych narzędzi, których spis przedstawiono w następnej części pracy, opisując konkretne zastosowanie każdego z narzędzi.
 
 
3. Narzędzia wykorzystywane w testowaniu
 
Podczas projektowania przypadków testowych, a następnie już podczas samych testów, tester korzysta z różnych narzędzi. W opisanym przypadku są to: 
  • arkusz kalkulacyjny MS Excel- wykorzystywany przy pisaniu scenariuszy, prowadzenia metryk;
  • Bugzilla – wykorzystywana to raportowania i śledzenia zgłaszanych błędów;
  • DekTec StreamXpress – do odtwarzania strumieni audio-video;
  • TeraTerm – narzędzie do monitorowania przebiegu testów – zbierania logów z testów, wykorzystywanych przez developerów w procesie naprawy błędów;
  • RedRat – narzędzie do testów automatycznych – pilot zdalnego sterowania z pakietem sygnłów sterujących, np. podgłaszanie i ściszanie dźwięku, przłączanie programów.
 
 
4. Podsumowanie
 
Testowanie dekoderów jest wbrew pozorom procesem złożonym. Przedstawiony artykuł nie wyczerpuje w całości wszystkich zagadnień dotyczących testowania tych urządzeń. Jednakże opisane rodzaje testów, narzędzia oraz przykładowe scenariusze obrazują w jakim obszarze pracuje tester biorący udział w wytwarzaniu produktu jakim jest dekoder STB. 
 
 
5. Spis cytowanej literatury
 
[2] Gerald O’Driscoll, The essential guide to Digital Set-top Boxes and interactive TV
[3] IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology
[4] Słownik wyrażeń związanych z testowaniem, wersja 2.02 (2011), ISTQB, SJSI
 
 

O Autorze:

Sylwia Bartman z wykształcenia informatyk i chemik. Obecnie zatrudniona w firmie Mobica (http://www.mobica.com/index.php) jako Młodszy Tester. Na co dzień zajmuje się wykonywaniem testów aplikacji na urządzenia mobilne oraz testami oprogramowania na urządzenia wbudowane. Do głównych obowiązków należy: projektowanie przypadków testowych i raportowanie wyników testów. Interesuje się zarządzaniem testami, modelami i metrykami w jakości oprogramowania oraz automatyzacją testów.

Była uczestniczką konferencji: Forum Jakości Systemów Informatycznych – Maj 2013; PMD Project Management Days – Kwiecień 2012; Socjalno-ekonomiczne problemy społeczeństwa informacyjnego – Maj 2011. 

Jest autorką publikacji poświęconej miejscu testowania w modelach cyklu tworzenia oprogramowania – debiut.

 
Kontakt: sylwia.bartman@mobica.com
 
 
 
 
 
 
8814
wyświetleń

To powinno Cię zainteresować