Camera Image Test Suite (ITS) to platforma do przeprowadzania testów na obrazach wygenerowanych przez aparat Androida. Ogólnym celem każdego testu w ITS jest skonfigurowanie aparatu w określony sposób, zrobienie co najmniej 1 zdjęcia i sprawdzenie, czy zawierają one oczekiwane dane obrazu. Wiele testów wymaga skierowania kamery na konkretną kartę testową lub oświetlenia jej z określoną intensywnością.
ITS znajduje się w platformie testowej CTS Verifier w cts/apps/CameraITS.
Urządzenia muszą przejść testy ITS odpowiadające obsługiwanym funkcjom
reklamowanym przez platformę aparatu dla aplikacji innych firm jako podzbiór CTS.
Konfiguracja
Aby przeprowadzić testy ITS, musisz skonfigurować te elementy:
- Urządzenie testowe
- urządzenie hosta (np. komputer stacjonarny lub laptop z systemem Linux);
- scena, którą fotografuje aparat;
Konfiguracja testowanego urządzenia
Aby skonfigurować urządzenie DUT, wykonaj te czynności:
- Połącz DUT z maszyną hosta za pomocą kabla USB.
- Przyznaj hostowi uprawnienia dostępu do DUT przez ADB.
Zainstaluj na urządzeniu aplikację CTS Verifier (
CtsVerifier.apk). Więcej informacji znajdziesz w artykule Korzystanie z CTS Verifier.extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zipcd android-cts-verifieradb install -r -g CtsVerifier.apkNa testowanym urządzeniu uruchom domyślną aplikację aparatu i zamknij wszystkie okna, które pojawią się po uruchomieniu, aby uniknąć zakłóceń podczas testowania.
Konfiguracja hosta
ITS wymaga, aby maszyna hosta była połączona z DUT przez USB, mogła używać ADB do sterowania urządzeniem i komunikacji z nim oraz miała zainstalowane wymagane oprogramowanie.
Aby skonfigurować komputer hosta, upewnij się, że zainstalowane jest na nim to oprogramowanie.
Android SDK Platform Tools
Narzędzia platformy Android SDK muszą być zainstalowane, a ADB musi znajdować się w ścieżce wykonywalnej powłoki lub terminala działającego na komputerze hosta. Informacje o wersji publicznej narzędzi platformy Android SDK znajdziesz w informacjach o wersji narzędzi platformy SDK.
Python
Na komputerze hosta musi być zainstalowany język Python. Zalecamy używanie pakietu dystrybucyjnego Pythona, aby mieć pewność, że obsługiwane są zgodne wersje. Szczegółowe informacje o tym, które wersje Pythona i pakietów należy zainstalować w przypadku konkretnej wersji, znajdziesz w informacjach o wersji Camera ITS.
Mobly
W przypadku Androida 12 i nowszych wersji zainstaluj platformę testową Mobly. Mobly umożliwia skonfigurowanie DUT i tabletu z wykresem w klasie its_base_test. Aby zainstalować platformę testową Mobly, uruchom to polecenie:
pip install moblyKonfigurowanie środowiska
Aby skonfigurować środowisko testowe, uruchom to polecenie:
cd CameraITSsource build/envsetup.sh
To polecenie sprawdza instalację Pythona, konfiguruje zmienną środowiskową PYTHONPATH i uruchamia testy jednostkowe modułów utils/*.py. Jeśli w terminalu nie pojawią się żadne błędy, środowisko jest gotowe do uruchomienia testów ITS.
Konfiguracja sceny
Do konfigurowania scen zalecamy używanie konfiguracji Camera ITS-in-a-box, która zapewnia łatwość automatyzacji, niezawodność i wydajność testowania. Stanowiska testowe ITS-in-a-box spełniają wszystkie wymagania ITS dotyczące oświetlenia, centrowania i zmiany wykresów. Do testowania rozszerzeń aparatu wymagany jest też zestaw ITS-in-a-box.
W przypadku testowania ręcznego upewnij się, że:
- Urządzenie jest umieszczone na statywie.
- Urządzenie jest skierowane na odpowiednią scenę w przypadku każdego testu. (Scenariusz testowania ITS zawiera prośby o zmianę konfiguracji sceny przed rozpoczęciem testów w nowej scenie).
- Urządzenie jest połączone z komputerem hosta za pomocą kabla USB.
- Urządzenie nie przemieszcza się podczas testu.
- Scena jest oświetlona stałym, nie migającym źródłem światła. (Nie używaj świetlówki, ponieważ powoduje ona migotanie).
Skrypt testowy ITS wyświetla prośbę o zmianę konfiguracji sceny przed rozpoczęciem testów w nowej scenie.
Orientacja telefonu musi być ustawiona tak, aby aparat robił zdjęcia bez obracania. Najłatwiej sprawdzić to na scenach z twarzami w scenie 2. W większości telefonów są one w orientacji poziomej, przy czym w przypadku tylnego aparatu telefon jest obrócony w kierunku przeciwnym do ruchu wskazówek zegara, a w przypadku przedniego aparatu – w kierunku zgodnym z ruchem wskazówek zegara.
Pliki konfiguracji
Za pomocą platformy Mobly musisz utworzyć plik konfiguracji config.yml, aby zdefiniować platformę testową Mobly. Poniżej znajdziesz przykłady różnych przypadków użycia.
Plik Tablet-based scenes config.yml
Poniżej znajdziesz przykład pliku config.yml dla scen na tabletach. W przypadku testów na tabletach w nazwie platformy testowej musi się znajdować słowo kluczowe TABLET. Podczas inicjowania narzędzie do uruchamiania testów Mobly inicjuje parametry w pliku i przekazuje je do poszczególnych testów.
TestBeds:
- Name: TEST_BED_TABLET_SCENES
# Test configuration for scenes[0:4, 6, _change]
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
- serial: 5B16001229
label: tablet
TestParams:
brightness: 192
chart_distance: 22.0
debug_mode: "False" # "True" or "False"; quotes needed
lighting_cntl: <controller-type> # "arduino" or "None"; quotes needed
lighting_ch: <controller-channel>
camera: 0
foldable_device: "False". # set "True" if testing foldable
scene: <scene-name> # if <scene-name> runs all scenes
Aby wywołać platformę testową, uruchom tools/run_all_tests.py. Jeśli nie ma wartości wiersza poleceń określających kamery lub sceny, test jest przeprowadzany z wartościami pliku config.yml. Jeśli w wierszu poleceń znajdują się wartości dotyczące kamer lub scen, zastępują one wartości w sekcji TestParams pliku config.yml.
Przykład:
python tools/run_all_tests.pypython tools/run_all_tests.py camera=1python tools/run_all_tests.py scenes=2,1,0python tools/run_all_tests.py camera=0 scenes=scene_telepython tools/run_all_tests.py camera=0.4 scenes=4,scene6_tele
Parametr chart_scaling
Na Androidzie 17 lub nowszym parametr chart_scaling jest uwzględniany w config.yml w przypadku TEST_BED_TABLET_SCENES. Ten parametr rozwiązuje problemy ze skalowaniem wykresów w przypadku urządzeń z teleobiektywem o szerszym polu widzenia, zapobiegając przycinaniu sceny i zapewniając prawidłowe ustawianie ostrości urządzenia podczas testowania.
Obsługiwane wartości parametru chart_scaling to 1, 0.33, 0.5 i 0.67, przy czym domyślną wartością jest None. Dzięki temu urządzenia mogą używać optymalnego współczynnika skalowania dostosowanego do ich konkretnych wymagań, co pozwala zachować testy funkcjonalne na wszystkich urządzeniach.
Jeśli parametr chart_scaling ma wartość None, testy automatycznie określają współczynnik skalowania za pomocą parametru chart_scaling_logic. W przeciwnym razie używana jest wartość podana w elemencie config.yml lub zgłaszany jest błąd, jeśli skalowanie jest niedostępne.
Oto przykładowy config.yml z parametrem chart_scaling
TestBeds:
- Name: TEST_BED_TABLET_SCENES # Need 'tablet' in name for tablet scenes
# Use TEST_BED_MANUAL for manual testing and remove below lines:
# - serial <tablet_id>
# label: tablet
# Test configuration for scenes[0:4, 6]
Controllers:
AndroidDevice:
- serial: <device-id> # quotes needed if serial id entirely numeric
label: dut
- serial: <tablet-id> # quotes needed if serial id entirely numeric
label: tablet
TestParams:
brightness: 192
chart_distance: 22.0
debug_mode: "False" # quotes needed
lighting_cntl: <controller-type> # can be arduino or "None"
lighting_ch: <controller-channel>
camera: <camera-id>
scene: <scene-name> # if <scene-name> runs all scenes
foldable_device: "False" # "True" if testing foldable device
chart_scaling: "None" # use the values available for scene to be tested
resultstore_upload: "False" # "True" if results should be uploaded to ResultStore
Aby włączyć funkcje skalowania wykresów ITS aparatu, wymagane są korekty po stronie testu. Jeśli używany przez Ciebie test nie obsługuje tej funkcji, zgłoś błąd.
Oto przykładowa zmiana strony testowej z parametrem chart_scaling.
# load chart for scene
its_session_utils.load_scene(
cam, props, self.scene, self.tablet, self.chart_distance,
chart_scaling=self.chart_scaling)
plik sensor_fusion scene config.yml
Poniżej znajdziesz przykładowy plik config_yml do testów sensor_fusion.
W przypadku testów sensor_fusion w nazwie platformy testowej musi znajdować się słowo kluczowe SENSOR_FUSION. Android 13 i nowsze wersje obsługują tylko kontroler Arduino do fuzji czujników ze względu na testowanie podglądu i stabilizacji wideo.
Android 12 obsługuje kontrolery Arduino i Canakit.
Testbeds
- Name: TEST_BED_SENSOR_FUSION
# Test configuration for sensor_fusion/test_sensor_fusion.py
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
fps: 30
img_size: 640,480
test_length: 7
debug_mode: "False"
chart_distance: 25
rotator_cntl: arduino
rotator_ch: 1
camera: 0
Aby uruchomić testy sensor_fusion za pomocą urządzenia do fuzji czujników, wykonaj to polecenie:
python tools/run_all_tests.py scenes=sensor_fusionpython tools/run_all_tests.py scenes=sensor_fusion camera=0python tools/run_all_tests.py scenes=scene_flash,feature_combinationpython tools/run_all_tests.py scenes=checkerboard camera=1
Plik config.yml z wieloma platformami testowymi
Poniżej znajdziesz przykład pliku config.yml z kilkoma platformami testowymi, platformą testową na tablety i platformą testową sensor_fusion. Odpowiednie środowisko testowe jest określane na podstawie testowanych scen.
Testbeds
- Name: TEST_BED_TABLET_SCENES
# Test configuration for scenes[0:4, 6, _change]
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
- serial: 5B16001229
label: tablet
TestParams:
brightness: 192
chart_distance: 22.0
debug_mode: "False"
chart_loc_arg: ""
camera: 0
scene: <scene-name> # if <scene-name> runs all scenes
- Name: TEST_BED_SENSOR_FUSION
# Test configuration for sensor_fusion/test_sensor_fusion.py
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
fps: 30
img_size: 640,480
test_length: 7
debug_mode: "False"
chart_distance: 25
rotator_cntl: arduino # cntl can be arduino or canakit
rotator_ch: 1
camera: 0
Plik config.yml testów ręcznych
Poniżej znajdziesz przykładowy plik config.yml do testowania ręcznego. Android 14 i nowsze wersje obsługują testowanie ręczne wszystkich testów z wyjątkiem testów scene_extensions. W przypadku testów ręcznych w nazwie platformy testowej musi się znajdować słowo kluczowe MANUAL.
Sekcja AndroidDevice nie może też zawierać sekcji z numerem seryjnym ani etykietą w przypadku tabletu.
TestBeds:
- Name: TEST_BED_MANUAL
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
debug_mode: "False"
camera: 0
scene: 1
Plik Gen2 rig testing config.yml
Poniżej znajdziesz przykładowy plik config.yml platformy testowej TEST_BED_GEN2.
To stanowisko testowe jest używane do scene_ip testów, które wykorzystują platformę Gen2](/docs/compatibility/cts/camera-its-box-gen2).
Poniższy przykład pokazuje parametry platformy testowej, gdy dostępna jest platforma Gen2 i testy scene_ip nie są pomijane.
Testbeds
- Name: TEST_BED_GEN2
# Test configuration for scene_ip/test_default_jca_ip.py
Controllers:
AndroidDevice:
- serial: <device-id> # quotes needed if serial id entirely numeric
label: dut
TestParams:
debug_mode: "False" # quotes are needed here
chart_distance: 30
rotator_cntl: gen2_rotator # gen2 rig specific. "None" if gen2 rig not available
rotator_ch: 0
camera: <camera-id>
foldable_device: "False" # "True" if testing foldable device
tablet_device: "False" # "True" if testing tablet device
lighting_cntl: gen2_lights # gen2 rig specific. "None" if gen2 rig not available
lighting_ch: 1
scene: scene_ip
Ten przykład pokazuje parametry platformy testowej, gdy platforma Gen2 jest niedostępna, a testy scene_ip są pomijane.
Testbeds
- Name: TEST_BED_GEN2
# Test configuration for scene_ip/test_default_jca_ip.py
Controllers:
AndroidDevice:
- serial: <device-id> # quotes needed if serial id entirely numeric
label: dut
TestParams:
debug_mode: "False" # quotes are needed here
chart_distance: 30
rotator_cntl: "None" # gen2 rig specific. "None" if gen2 rig not available
rotator_ch: <controller-channel>
camera: <camera-id>
foldable_device: "False" # "True" if testing foldable device
tablet_device: "False" # "True" if testing tablet device
lighting_cntl: "None" # gen2 rig specific. "None" if gen2 rig not available
lighting_ch: <controller-channel>
scene: scene_ip
Aby uruchomić test scene_ip, użyj jednego z tych poleceń:
python tests/scene_ip/test_default_jca_ip.py -c config.ymlpython tools/run_all_tests.py camera=<camera-id> scenes=scene_ip
Przeprowadzanie testów ITS
Z tej sekcji dowiesz się, jak przeprowadzać testy ITS.
Wywoływanie testów
Po skonfigurowaniu urządzenia, hosta (wraz ze środowiskiem) i sceny fizycznej przeprowadź testy ITS, wykonując te czynności.
Otwórz aplikację CTS Verifier. W menu testów wybierz Camera ITS Test (Test ITS aparatu). W przypadku Androida 17 i nowszych testy
sensor_fusionifeature_combinationsą przeprowadzane w ramach dodatkowej aktywności o nazwie Test stanowiska do fuzji czujników ITS aparatu.Na komputerze hosta uruchom testy ITS z katalogu
CameraITS/. Na przykład w przypadku urządzenia z przednim i tylnym aparatem uruchom to polecenie:python tools/run_all_tests.pySkrypt iteruje kamery i sceny testowe na podstawie pliku
config.yml. W przypadku konfiguracji debugowania zalecamy uruchomienie jednej ze scenscene2z pojedynczym testem, aby uzyskać najszybsze wyniki.W przypadku testowania ręcznego przed rozpoczęciem wykonywania zestawu testów ITS w każdej scenie skrypt robi zdjęcie bieżącej sceny, zapisuje je jako plik JPEG, drukuje ścieżkę do pliku JPEG w konsoli i prosi użytkownika o potwierdzenie, czy obraz jest w porządku. Ten proces robienia zdjęć i potwierdzania jest powtarzany, dopóki użytkownik nie potwierdzi, że obraz jest w porządku. Poniżej znajdziesz komunikaty wyświetlane w tym procesie.
Preparing to run ITS on camera 0 Start running ITS on camera: 0 Press Enter after placing camera 0 to frame the test scene: scene1_1 The scene setup should be: A grey card covering at least the middle 30% of the scene Running vendor 3A on device Capture an image to check the test scene Capturing 1 frame with 1 format [yuv] Please check scene setup in /tmp/tmpwBOA7g/0/scene1_1.jpg Is the image okay for ITS scene1_1? (Y/N)Każde uruchomienie skryptu powoduje wydrukowanie logu z informacją
PASS,FAIL,FAIL*lubSKIPdla każdego testu ITS.FAIL*oznacza, że test się nie powiódł, ale ponieważ nie jest on jeszcze wymagany, CtsVerifier zgłosi go jakoPASS. SymbolSKIPoznacza, że test został zaliczony, ponieważ urządzenie nie reklamowało testowanej funkcji. Jeśli na przykład urządzenie nie reklamuje za pomocą interfejsów aparatu, że obsługuje format DNG, testy związane z robieniem zdjęć w tym formacie są pomijane i liczone jakoPASS.Aby potwierdzić, że testy spełniają wymagania, kliknij zielony przycisk ze znacznikiem wyboru. Wpis Test ITS aparatu w menu testów CTS Verifier zmieni kolor na zielony, co oznacza, że telefon przeszedł test ITS aparatu.
Równoległe testowanie urządzeń
Urządzenia z Androidem 14 lub nowszym obsługują równoległe testowanie DUT. Umożliwia to testowanie urządzeń równolegle na wielu stanowiskach, co przyspiesza ogólny proces testowania. Na przykład testowanie równoległe umożliwia jednoczesne testowanie kamery 0 na jednym stanowisku i kamery 1 na innym. W przypadku Androida 17 i nowszych wersji, ponieważ testy Camera ITS są podzielone na 2 aktywności, możesz uruchamiać testy sensor_fusion i feature_combination
na jednym urządzeniu, a inne testy na innym urządzeniu równolegle. Wszystkie testy w sesjach testów równoległych są agregowane w sesji CTS Verifier na referencyjnym urządzeniu DUT.
Musisz przeprowadzić testy równoległe z użyciem sterowania oświetleniem Arduino, ponieważ ręczne sterowanie oświetleniem nie jest obsługiwane w przypadku testów równoległych. Upewnij się, że oświetlenie każdego stanowiska jest sterowane przez inny kanał na tym samym kontrolerze Arduino.
Poniżej znajdziesz przykładowy plik config.yml, który definiuje 3 platformy testowe do uruchomienia równoległego.
TestBeds:
- Name: TEST_BED_TABLET_SCENES_INDEX_0
Controllers:
AndroidDevice:
- serial: <device-id-0>
label: dut
- serial: <tablet-id-0>
label: tablet
TestParams:
brightness: 192
chart_distance: 22.0
debug_mode: "False"
lighting_cntl: "arduino"
lighting_ch: <controller-channel-0>
camera: 0
scene: <scene-name> # if <scene-name> left as-is runs all scenes
foldable_device: "False"
- Name: TEST_BED_TABLET_SCENES_INDEX_1
Controllers:
AndroidDevice:
- serial: <device-id-1>
label: dut
- serial: <tablet-id-1>
label: tablet
TestParams:
brightness: 192
chart_distance: 22.0
debug_mode: "False"
lighting_cntl: "arduino"
lighting_ch: <controller-channel-1>
camera: 1
scene: <scene-name> # if <scene-name> left as-is runs all scenes
foldable_device: "False"
# TEST_BED_SENSOR_FUSION represents testbed index 2
# Parallel sensor_fusion is currently unsupported due to Arduino requirements
- Name: TEST_BED_SENSOR_FUSION
# Test configuration for sensor_fusion
Controllers:
AndroidDevice:
- serial: <device-id>
label: dut
TestParams:
fps: 30
img_size: 640,480
test_length: 7
debug_mode: "False"
chart_distance: 25
rotator_cntl: "arduino"
rotator_ch: <controller-channel-2>
camera: <camera-id>
foldable_device: "False"
tablet_device: "False"
lighting_cntl: "None"
lighting_ch: <controller-channel>
scene: "sensor_fusion"
Aby uruchomić platformy testowe równolegle, użyj tego polecenia:
for i in 0 1 2; do python3 tools/run_all_tests.py testbed_index=$i num_testbeds=3 & done; waitPrzesyłanie zbiorczych wyników testów
W przypadku Androida 17 i nowszych możesz przesyłać zbiorcze wyniki testów Camera ITS w celu zatwierdzenia kompilacji. CTS Verifier umożliwia jednoczesne testowanie wielu scen na różnych urządzeniach i zbieranie wyników testów z wielu raportów CTS Verifier (z różnych przebiegów testów lub urządzeń) w jednym, ujednoliconym zgłoszeniu.
Proces przesyłania
Aby przesłać zbiorcze wyniki testów ITS aparatu w celu zatwierdzenia kompilacji, wykonaj te czynności:
- Przygotuj urządzenia: zgromadź 2–3 urządzenia testowe, które mają dokładnie ten sam odcisk cyfrowy kompilacji.
- Zainstaluj narzędzie CTS Verifier: zainstaluj najnowszą wersję APK narzędzia CTS Verifier, którą możesz pobrać z udostępnionego eksploratora kompilacji.
Równoległe przeprowadzanie testów:
- Zamontuj DUT w oddzielnych statywach.
- Równoczesne uruchamianie różnych scen ITS kamery na każdym urządzeniu.
- Kolekcja raportów: po każdym uruchomieniu pobierz raport CTS Verifier. Dotyczy to raportów, w których sceny nie zostały wyrenderowane. W kolejnych uruchomieniach powtarzaj tylko sceny, które się nie powiodły.
Przesyłanie raportów: przesyłanie wielu raportów CTS Verifier zebranych ze wszystkich urządzeń.
Sprawdź wyniki: po przesłaniu raportów sprawdź zagregowane wyniki:
- W sekcji Analiza testu znajdziesz pełną listę wszystkich wykonanych scen.
Sceny, które nie zostały wykonane lub zakończyły się niepowodzeniem, są wymienione w sekcji Nieudane.
Rysunek 1. Dokumentacja scen, które nie zostały wykonane lub zakończyły się niepowodzeniem.
Przewinięte sceny są wymienione w sekcji Zagregowane przewinięcia.
Rysunek 2. Sceny sklasyfikowane jako Zagregowane Przejście
Stan zatwierdzenia kompilacji
Zatwierdzenie kompilacji jest przyznawane, gdy wszystkie wymagane sceny zostaną pomyślnie ukończone w zagregowanych raportach.
Model szumu DNG
Urządzenia, które reklamują możliwość rejestrowania zdjęć w formacie RAW lub DNG, muszą podawać model szumu w metadanych wyniku rejestrowania każdego zdjęcia w formacie RAW. Ten model szumu musi być wbudowany w HAL aparatu dla każdego aparatu (np. przedniego i tylnego) na urządzeniu, które deklaruje obsługę.
Implementacja modelu szumu
Aby wdrożyć model szumu, wykonaj te czynności, aby wygenerować model szumu i osadzić go w warstwie HAL aparatu.
Aby wygenerować model szumu dla każdego aparatu, uruchom skrypt
dng_noise_model.pyw katalogutools. Wygeneruje to fragment kodu w języku C. Więcej informacji o konfigurowaniu kamery i środowiska przechwytywania znajdziesz w dokumencieDngNoiseModel.pdfw katalogutools.Aby wdrożyć model szumu na urządzeniu, wytnij i wklej fragment kodu C do HAL aparatu.
Weryfikacja modelu szumu
Automatyczny test ITS tests/scene1_1/test_dng_noise_model.py sprawdza model szumu, weryfikując, czy wartości szumu dla ekspozycji i wzmocnienia podane w danych z aparatu są prawidłowe.
Testy zaliczone z niewielkim marginesem (stan testu PASS*)
W Androidzie 17 i nowszych marginal pass (PASS*) oznacza, że test został zaliczony, ale jego dane dotyczące wydajności są bardzo bliskie wstępnie zdefiniowanego progu zaliczenia. Chociaż test technicznie spełnia kryteria zaliczenia, bliskość granicy niepowodzenia sugeruje konieczność dokładniejszego zbadania.
Korzyści z marginalnego zaliczenia
Stan PASS* zapewnia kilka korzyści:
System wczesnego ostrzegania: identyfikuje testy, które są bliskie niepowodzenia, dzięki czemu zespoły mogą rozwiązywać problemy, zanim doprowadzą one do całkowitej porażki.
Proaktywna optymalizacja: zachęca zespoły do optymalizacji testów i kodu, które działają na dolnej granicy dopuszczalnego zakresu, co poprawia ogólną stabilność.
Poprawa jakości: pomaga utrzymać wyższy standard jakości, oznaczając obszary, które mogą być podatne na przyszłe regresje przy niewielkich zmianach w kodzie.
Krótszy czas debugowania: dzięki wczesnemu wykrywaniu
PASS*testów można znacznie skrócić czas i wysiłek potrzebne do debugowania pełnych błędów w przyszłości.
Szczegóły PASS*
Stan PASS* obejmuje te elementy:
Określanie wartości progowych: dla każdego odpowiedniego testu w Camera ITS określono konkretne wartości progowe.
Automatyczne wykrywanie: system automatyzacji testów wykrywa i kategoryzuje testy jako
PASS*na podstawie zdefiniowanych progów.Mechanizm alertów: zespoły otrzymują automatyczne alerty dotyczące wszystkich testów oznaczonych jako
PASS*. Dzięki temu mogą sprawdzić konkretny test i jego dane.Raportowanie: w raportach z testów i na panelach wyraźnie oznaczamy stany „Marginal pass” (Marginalnie zaliczone), aby zapewnić lepszą widoczność. W
ItsTestSummaryraporcie oznaczamy je symbolemPASS*, podobnie jak testynot_yet_mandatedsymbolemFail*. Test zachowuje stan zielony, ponieważ nadal mieści się w ustalonych progach, aby uniknąć dalszych nieporozumień. StanPASS*dotyczy tylko klasy testowej, a nie całej sceny. Na przykład Scene_0 może być uznana zaPASS, nawet jeśli test_jitter i test_metadata mają wartośćPASS*.Monitorowanie: dane o skuteczności są zbierane w przypadku testów, które na urządzeniu uzyskały wynik na granicy zaliczenia. Umożliwia to monitorowanie przyszłych ulepszeń aparatu wprowadzanych przez producentów OEM, jeśli te testy przejdą w stan
PASS.
Oto przykład wyników testu z użyciem PASS*:
INFO:root:Reporting camera 1 ITS results to CtsVerifier
INFO:root:ITS results to CtsVerifier: {'scene0': {'result': 'PASS', 'TEST_STATUS': [{'test': 'test_jitter', 'status': 'PASS*'}, {'test': 'test_metadata', **'status': 'PASS*'**}, {'test': 'test_request_capture_match', 'status': 'PASS'}, {'test': 'test_sensor_events', 'status': 'PASS'}, {'test': 'test_solid_color_test_pattern', 'status': 'PASS'}, {'test': 'test_test_patterns', 'status': 'SKIP'}, {'test': 'test_tonemap_curve', 'status': 'SKIP'}, {'test': 'test_unified_timestamps', 'status': 'PASS'}, {'test': 'test_vibration_restriction', 'status': 'PASS'}], 'mpc_metrics': [], 'performance_metrics': [], 'feature_query_proto': [], 'feature_query_proto_path': [], 'summary': '/tmp/CameraITS_zojk4sdr/cam_id_1/scene0/scene_test_summary.txt', 'start': 1754330630345, 'end': 1754330764534}, 'scene1_1': {'result': 'NOT_EXECUTED'}, 'scene1_2': {'result': 'NOT_EXECUTED'}, 'scene1_3': {'result': 'NOT_EXECUTED'}, 'scene2_a': {'result': 'NOT_EXECUTED'}, 'scene2_b': {'result': 'NOT_EXECUTED'}, 'scene2_c': {'result': 'NOT_EXECUTED'}, 'scene2_d': {'result': 'NOT_EXECUTED'}, 'scene2_e': {'result': 'NOT_EXECUTED'}, 'scene2_f': {'result': 'NOT_EXECUTED'}, 'scene2_g': {'result': 'NOT_EXECUTED'}, 'scene3': {'result': 'NOT_EXECUTED'}, 'scene4': {'result': 'NOT_EXECUTED'}, 'scene6': {'result': 'NOT_EXECUTED'}, 'scene7': {'result': 'NOT_EXECUTED'}, 'scene8': {'result': 'NOT_EXECUTED'}, 'scene9': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_hdr': {'result': 'NOT_EXECUTED'}, 'scene_extensions/scene_low_light': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene6_tele': {'result': 'NOT_EXECUTED'}, 'scene_tele/scene7_tele': {'result': 'NOT_EXECUTED'}, 'scene_video': {'result': 'NOT_EXECUTED'}, 'scene5': {'result': 'NOT_EXECUTED'}, 'sensor_fusion': {'result': 'NOT_EXECUTED'}, 'feature_combination': {'result': 'NOT_EXECUTED'}, 'scene_flash': {'result': 'NOT_EXECUTED'}, 'scene_ip': {'result': 'NOT_EXECUTED'}}
Zachęcamy partnerów do:
- Monitorowanie alertów
PASS* - Zbadaj główną przyczynę
PASS*testów - Proaktywnie optymalizuj testy i kod oznaczone jako
PASS*.
Status PASS* ma na celu zwiększenie niezawodności i stabilności testów Camera ITS, co przekłada się na stabilny produkt wysokiej jakości.