Camera Image Test Suite (ITS) to platforma do przeprowadzania testów obrazów generowanych przez aparat Androida. Ogólnym celem każdego testu w ITS jest skonfigurowanie aparatu w określony sposób, zrobienie jednego lub kilku zdjęć i sprawdzenie, czy zawierają one oczekiwane dane obrazu. Wiele testów wymaga, aby aparat był skierowany na konkretny wykres testowy lub oświetlony z określoną intensywnością.
ITS znajduje się w narzędziu CTS Verifier w
cts/apps/CameraITS.
Urządzenia muszą przejść testy ITS odpowiadające obsługiwanym funkcjom, które są reklamowane przez platformę aparatu dla aplikacji innych firm jako podzbiór CTS.
Konfiguracja
Aby uruchomić testy ITS, musisz skonfigurować te elementy:
- testowane urządzenie (DUT),
- komputer hosta (np. komputer stacjonarny lub laptop z systemem Linux),
- scena, którą fotografuje aparat.
Konfiguracja testowanego urządzenia (DUT)
Aby skonfigurować DUT:
- Podłącz DUT do komputera hosta przez USB.
- Skonfiguruj opcje programisty na DUT:
- Włącz Nie usypiaj i Debugowanie USB.
- Wyłącz Automatyczne aktualizacje systemu i Weryfikuj aplikacje przez 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 DUT 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 komputer hosta był połączony z DUT przez USB, mógł używać ADB do sterowania urządzeniem i komunikacji z nim oraz miał zainstalowane wymagane oprogramowanie.
Aby skonfigurować komputer hosta, zainstaluj te programy:
Narzędzia platformy Android SDK
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. Publiczną wersję narzędzi platformy Android SDK, znajdziesz w informacjach o wersji narzędzi platformy SDK.
Python
Python musi być zainstalowany na komputerze hosta. Zalecamy używanie pakietu Python, aby zapewnić obsługę zgodnych wersji. 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 lub nowszego zainstaluj platformę testową Mobly. Mobly umożliwia skonfigurowanie DUT i tabletu z wykresem w klasie its_base_test. Aby zainstalować platformę testową Mobly, uruchom:
pip install moblyKonfiguracja środowiska
Aby skonfigurować środowisko testowe, uruchom:
cd CameraITSsource build/envsetup.sh
To polecenie sprawdza instalację Pythona, konfiguruje zmienną środowiskową PYTHONPATH i uruchamia testy jednostkowe w modułach utils/*.py. Jeśli w terminalu nie pojawią się żadne błędy, środowisko jest gotowe do uruchomienia testów ITS.
Konfiguracja sceny
Aby skonfigurować sceny, zalecamy użycie konfiguracji Camera ITS-in-a-box, która ułatwia automatyzację, niezawodność i wydajność testowania. Platformy testowe ITS-in-a-box obsługują wszystkie wymagania ITS dotyczące oświetlenia, centrowania i zmiany wykresu. ITS-in-a-box jest też wymagany do testowania rozszerzeń aparatu.
W przypadku testowania ręcznego upewnij się, że:
- DUT jest umieszczony na statywie.
- DUT jest skierowany na odpowiednią scenę dla każdego testu. (Scenariusz testowania ITS wyświetla prośby o zmianę konfiguracji sceny przed rozpoczęciem testów w nowej scenie).
- DUT jest połączony z komputerem hosta przez USB.
- DUT nie porusza się podczas testu.
- Scena jest oświetlona stałym, nie migającym źródłem światła. (Nie używaj światła fluorescencyjnego, ponieważ powoduje ono migotanie).
Scenariusz testowania 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 to sprawdzić za pomocą scen z twarzami w scene2. Większość telefonów ma orientację poziomą, a tylny aparat jest obrócony w lewo, a przedni w prawo.
Aby sprawdzić wyrównanie DUT i wykresu, uruchom tools/check_alignment.py, aby wyświetlić współrzędne x, y środka wykresu względem środka obrazu, i oznacz przechwycony obraz dwoma środkami w celu optymalnego wyrównania.
Pliki konfiguracji
Korzystając z platformy Mobly, musisz utworzyć plik konfiguracji config.yml, aby zdefiniować platformę testową Mobly. Oto przykłady różnych przypadków użycia.
Plik config.yml scen opartych na tablecie
Oto przykład pliku config.yml dla scen opartych na tablecie. W przypadku testowania na tablecie w nazwie platformy testowej musi znajdować się 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 w wierszu poleceń określających aparaty lub sceny, test jest uruchamiany z wartościami z pliku config.yml. Jeśli w wierszu poleceń znajdują się wartości dotyczące aparatów 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
W Androidzie 17 lub nowszym parametr chart_scaling jest uwzględniony w config.yml dla TEST_BED_TABLET_SCENES. Ten parametr rozwiązuje problemy ze skalowaniem wykresu w przypadku urządzeń z teleobiektywem o szerszym polu widzenia, zapobiegając przycinaniu sceny i zapewniając prawidłowe ustawienie ostrości urządzenia podczas testowania.
Obsługiwane wartości chart_scaling to 1, 0.33, 0.5 lub 0.67, a domyślna to 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 chart_scaling jest ustawiony na None, testy automatycznie określają
współczynnik skalowania za pomocą chart_scaling_logic. W przeciwnym razie używana jest wartość określona w config.yml lub zgłaszany jest błąd, jeśli skalowanie jest niedostępne.
Oto przykładowy plik 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 wykresu Camera ITS, musisz wprowadzić zmiany po stronie testu. Jeśli używany test nie obsługuje tej funkcji, zgłoś błąd.
Oto przykładowa zmiana po stronie testu 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 config.yml sceny sensor_fusion
Oto przykład pliku config_yml dla testów sensor_fusion.
W przypadku testowania sensor_fusion w nazwie platformy testowej musi znajdować się słowo kluczowe SENSOR_FUSION. Android 13 lub nowszy obsługuje tylko kontroler Arduino do łączenia czujników ze względu na testowanie stabilizacji podglądu i 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ą
pola łączenia czujników, uruchom:
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 wielu platform testowych
Oto przykład pliku config.yml z kilkoma platformami testowymi: platformą testową tabletu i platformą testową sensor_fusion. Prawidłowa platforma testowa jest określana 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 testowania ręcznego
Oto przykład pliku config.yml do testowania ręcznego. Android 14
lub nowszy obsługuje testowanie ręczne wszystkich testów z wyjątkiem
scene_extensions
testów. W przypadku testowania ręcznego w nazwie platformy testowej musi znajdować się słowo kluczowe MANUAL.
Ponadto sekcja AndroidDevice nie może zawierać sekcji serial lub label dla tabletu.
TestBeds:
- Name: TEST_BED_MANUAL
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
debug_mode: "False"
camera: 0
scene: 1
Plik config.yml testowania platformy Gen2
Oto przykład pliku config.yml platformy testowej TEST_BED_GEN2.
Ta platforma testowa jest używana do testów scene_ip, które korzystają z platformy Gen2.
Poniższy przykład pokazuje parametry platformy testowej, gdy platforma Gen2 jest
dostępna, a
scene_ip
testy 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
Poniższy 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
Uruchamianie testów ITS
W tej sekcji opisujemy, jak uruchamiać testy ITS.
Wywoływanie testów
Po skonfigurowaniu urządzenia, komputera hosta (w tym środowiska) i sceny fizycznej uruchom testy ITS, wykonując te czynności.
Otwórz aplikację CTS Verifier. W menu testów wybierz Test ITS aparatu. W Androidzie 17 lub nowszym testy
sensor_fusionifeature_combinationznajdują się w dodatkowej aktywności o nazwie Test platformy łączenia 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 po aparatach i scenach testowych na podstawie pliku
config.yml. W przypadku konfiguracji debugowania zalecamy uruchomienie jednej ze scenscene2z jednym testem, aby uzyskać najszybsze wyniki.W przypadku testowania ręcznego przed rozpoczęciem uruchamiania zestawu testów ITS w każdej scenie skrypt robi zdjęcie bieżącej sceny, zapisuje je jako JPEG, wyświetla ścieżkę do pliku JPEG w konsoli i prosi użytkownika o potwierdzenie, czy obraz jest prawidłowy. Ten proces przechwytywania i potwierdzania powtarza się, dopóki użytkownik nie potwierdzi, że obraz jest prawidłowy. Oto komunikaty 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 wyświetla log, w którym dla każdego testu ITS widoczny jest wynik
PASS,FAIL,FAIL*lubSKIP.FAIL*oznacza, że test nie powiódł się, ale ponieważ nie jest jeszcze wymagany, w CTS Verifier zostanie zgłoszony jakoPASS.SKIPoznacza, ż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 przechwytywaniem plików DNG są pomijane i liczone jakoPASS.Aby potwierdzić, że testy spełniły wymagania testowe, kliknij zielony przycisk potwierdzenia. W menu testów CTS Verifier pozycja Test ITS aparatu zmieni kolor na zielony, co oznacza, że telefon przeszedł test ITS aparatu.
Równoległe testowanie DUT
Urządzenia z Androidem 14 lub nowszym obsługują równoległe testowanie DUT. Dzięki temu możesz testować DUT równolegle na kilku platformach, co przyspiesza ogólne testowanie. Na przykład testowanie równoległe umożliwia jednoczesne testowanie aparatu 0 na jednej platformie i aparatu 1 na innej. W Androidzie 17 lub nowszym testy ITS aparatu są podzielone na 2 aktywności, więc możesz uruchamiać testy sensor_fusion i feature_combination na jednym DUT, a inne testy na innym DUT równolegle. Wszystkie testy w sesjach testowania równoległego są agregowane w sesji CTS Verifier na referencyjnym DUT.
Testowanie równoległe musisz przeprowadzać za pomocą sterowania oświetleniem Arduino, ponieważ ręczne sterowanie oświetleniem nie jest obsługiwane w przypadku testowania równoległego. Upewnij się, że oświetlenie każdej platformy jest sterowane przez inny kanał na tym samym kontrolerze Arduino.
Oto przykładowy plik config.yml, który definiuje 3 platformy testowe do uruchamiania 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 Androidzie 17 lub nowszym możesz przesyłać zbiorcze wyniki testów ITS aparatu w celu zatwierdzenia kompilacji. CTS Verifier umożliwia jednoczesne testowanie wielu scen na kilku urządzeniach oraz agregowanie wyników testów z wielu raportów CTS Verifier (z różnych testów lub urządzeń) w jednym, ujednoliconym zgłoszeniu.
Proces przesyłania
Aby przesłać zbiorcze wyniki ITS aparatu w celu zatwierdzenia kompilacji:
- Przygotuj urządzenia: zbierz 2–3 testowane urządzenia (DUT), które mają dokładnie ten sam odcisk cyfrowy kompilacji.
- Zainstaluj CTS Verifier: zainstaluj najnowszą wersję APK CTS Verifier, którą możesz pobrać z udostępnionego eksploratora kompilacji.
Równoległe wykonywanie testów:
- Zamontuj DUT na osobnych platformach.
- Uruchom jednocześnie różne sceny ITS aparatu na każdym urządzeniu.
- Kolekcja raportów: po każdym uruchomieniu pobierz raport CTS Verifier. Dotyczy to też raportów, w których sceny nie powiodły się. W kolejnych uruchomieniach powtórz tylko sceny, które nie powiodły się.
Prześlij raporty: prześlij kilka raportów CTS Verifier zebranych ze wszystkich urządzeń.
Sprawdź wyniki: po przesłaniu raportów sprawdź zbiorcze wyniki:
- W sekcji Analiza testów znajdziesz pełną listę wszystkich wykonanych scen.
Sceny, które nie zostały wykonane lub nie powiodły się, są wymienione w sekcji Nieudane.
Rysunek 1. Dokumentacja scen, które nie zostały wykonane lub nie powiodły się.
Sceny, które powiodły się, są wymienione w sekcji Zbiorcze zaliczenie.
Rysunek 2. Sceny sklasyfikowane jako zbiorcze zaliczenie
Stan zatwierdzenia kompilacji
Zatwierdzenie kompilacji jest przyznawane, gdy wszystkie wymagane sceny zostaną pomyślnie ukończone w zbiorczych raportach.
Model szumów DNG
Urządzenia, które reklamują możliwość przechwytywania obrazów RAW lub DNG, muszą udostępniać model szumów w metadanych wyników przechwytywania każdego zdjęcia RAW. Ten model szumów musi być wbudowany w HAL aparatu dla każdego aparatu (np. przedniego i tylnego) na urządzeniu, które deklaruje obsługę.
Implementacja modelu szumów
Aby zaimplementować model szumów, wykonaj te czynności, aby wygenerować model szumów i osadzić go w HAL aparatu.
Aby wygenerować model szumów dla każdego aparatu, uruchom skrypt
dng_noise_model.pyw katalogutools. Wygeneruje on fragment kodu C. Więcej informacji o tym, jak skonfigurować aparat i środowisko przechwytywania, znajdziesz w dokumencieDngNoiseModel.pdfw katalogutools.Aby zaimplementować model szumów na urządzeniu, wytnij i wklej fragment kodu C do HAL aparatu.
Weryfikacja modelu szumów
Automatyczny test ITS tests/scene1_1/test_dng_noise_model.py
weryfikuje model szumów, sprawdzając, czy wartości szumów
dla ekspozycji i wzmocnienia zdjęcia podane w danych aparatu są prawidłowe.
Testy zaliczone z trudem (stan testu PASS*)
W Androidzie 17 lub nowszym zaliczenie z trudem (PASS*) oznacza, że test został zaliczony, ale jego dane skuteczności są bardzo bliskie wstępnie zdefiniowanego progu zaliczenia. Chociaż test technicznie spełnia kryteria zaliczenia, bliskość granicy niepowodzenia sugeruje potrzebę dokładniejszego zbadania.
Korzyści z zaliczenia z trudem
Stan PASS* ma kilka zalet:
System wczesnego ostrzegania: identyfikuje testy, które są na granicy niepowodzenia, co pozwala zespołom rozwiązywać problemy, zanim doprowadzą one do całkowitego niepowodzenia.
Proaktywna optymalizacja: zachęca zespoły do optymalizowania testów i kodu, które działają na dolnej granicy dopuszczalnego zakresu, co zwiększa ogólną stabilność.
Lepsza jakość: 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 testów
PASS*można znacznie skrócić czas i wysiłek potrzebny do debugowania pełnych niepowodzeń w przyszłości.
Szczegóły PASS*
Stan PASS* obejmuje te elementy:
Definiowanie progów: dla każdego odpowiedniego testu w Camera ITS są zdefiniowane konkretne progi zaliczenia z trudem.
Automatyczne wykrywanie: system automatyzacji testów wykrywa i kategoryzuje testy jako
PASS*na podstawie zdefiniowanych progów.Mechanizm ostrzegania: zespoły otrzymują automatyczne alerty o wszystkich testach oznaczonych jako
PASS*, co kieruje je do zbadania konkretnego testu i jego danych.Raportowanie: stany zaliczenia z trudem są wyraźnie wskazywane w raportach z testów i panelach, aby zapewnić lepszą widoczność jako
PASS*w raporcieItsTestSummary, podobnie jakFail*w przypadku testównot_yet_mandated. Aby uniknąć dalszych nieporozumień, test zachowuje stan zielony, ponieważ nadal mieści się w ustalonych progach. StanPASS*dotyczy tylko klasy testu, a nie całej sceny. Na przykład Scene_0 może być uznana zaPASS, nawet jeśli test_jitter i test_metadata sąPASS*.Monitorowanie: dane o skuteczności są zbierane w przypadku testów, które na urządzeniu zostały zaliczone z trudem. Umożliwia to monitorowanie przyszłych ulepszeń aparatu wprowadzonych przez producentów OEM, jeśli te testy przejdą do stanu
PASS.
Oto przykład wyników testu ze stanem 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:
- monitorowania alertów
PASS*, - badania głównej przyczyny testów
PASS*, - proaktywnego optymalizowania testów i kodu oznaczonych jako
PASS*.
Stan PASS* ma na celu zwiększenie niezawodności i stabilności testów ITS aparatu, co przekłada się na stabilny i wysokiej jakości produkt.