Omówienie ITS aparatu

Camera Image Test Suite (ITS) to platforma do przeprowadzania testów na obrazach 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 konkretną planszę testową 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:

1. Podłącz DUT do komputera hosta przez USB.
2. Skonfiguruj opcje programisty na DUT:
   • Włącz Nie usypiaj i Debugowanie USB.
   • Wyłącz Automatyczne aktualizacje systemu i Weryfikuj aplikacje przez USB.
3. Przyznaj hostowi uprawnienia dostępu do DUT przez ADB.

4. 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.zip
   cd android-cts-verifier
   adb install -r -g CtsVerifier.apk

5. Na 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 to oprogramowanie.

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. Publicznie udostępnioną 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 planszą w klasie its_base_test. Aby zainstalować platformę testową Mobly, uruchom:

pip install mobly

Konfiguracja środowiska

Aby skonfigurować środowisko testowe, uruchom:

cd CameraITS
source 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. Stanowiska testowe ITS-in-a-box obsługują wszystkie wymagania ITS dotyczące oświetlenia, centrowania i zmiany planszy. 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. (Skrypt testu 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 świetlówki, ponieważ powoduje ona migotanie).

Skrypt testu 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 planszy, uruchom tools/check_alignment.py,aby wyświetlić współrzędne x i y środka planszy 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ć środowisko testowe 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 środowiska testowego 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ć środowisko testowe, 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.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=0 scenes=scene_tele
python 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 planszy w przypadku urządzeń z teleobiektywem o szerszym polu widzenia, zapobiegając przycinaniu sceny i wymuszają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ć testowanie 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 planszy 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 środowiska testowego 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_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
python tools/run_all_tests.py scenes=scene_flash,feature_combination
python tools/run_all_tests.py scenes=checkerboard camera=1

Plik config.yml wielu środowisk testowych

Oto przykład pliku config.yml z kilkoma środowiskami testowymi: środowiskiem testowym tabletu i środowiskiem testowym sensor_fusion. Prawidłowe ś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 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 środowiska testowego 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 stanowiska Gen2

Oto przykład pliku config.yml środowiska testowego TEST_BED_GEN2. Użyj tego środowiska testowego do testów scene_ip, które korzystają ze stanowiska Gen2. Poniższy przykład pokazuje parametry środowiska testowego, gdy stanowisko Gen2 jest dostępne, 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 środowiska testowego, gdy stanowisko Gen2 jest niedostępne, 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.yml
python 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.

1. Otwórz aplikację CTS Verifier. W menu testów wybierz Camera ITS Test. W Androidzie 17 lub nowszym testy sensor_fusion i feature_combination znajdują się w dodatkowej aktywności o nazwie Camera ITS Sensor Fusion Rig Test.

2. 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.py

   Skrypt iteruje po aparatach i scenach testowych na podstawie pliku config.yml. W przypadku konfiguracji debugowania zalecamy uruchomienie jednej ze scen scene2 z 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* lub SKIP. FAIL* oznacza, że test nie powiódł się, ale ponieważ nie jest jeszcze wymagany, w CTS Verifier zostanie zgłoszony jako PASS. SKIP oznacza, ż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 jako PASS.

3. Aby potwierdzić, że testy spełniają wymagania testowe, kliknij zielony przycisk ze znacznikiem wyboru. W menu testów CTS Verifier pozycja Camera ITS Test zmieni kolor na zielony, co oznacza, że telefon przeszedł test Camera ITS.

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 stanowiskach, co przyspiesza ogólne testowanie. Na przykład testowanie równoległe umożliwia jednoczesne testowanie aparatu 0 na jednym stanowisku i aparatu 1 na innym. W Androidzie 17 lub nowszym testy Camera ITS 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ć z użyciem 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żdego stanowiska jest sterowane przez inny kanał na tym samym kontrolerze Arduino.

Oto przykładowy plik config.yml, który definiuje 3 środowiska 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ć środowiska 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; wait

Przesyłanie zbiorczych wyników testów

W Androidzie 17 lub nowszym możesz przesyłać zbiorcze wyniki testów Camera ITS 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 Camera ITS w celu zatwierdzenia kompilacji:

1. Przygotuj urządzenia: zbierz 2–3 testowane urządzenia (DUT), które mają dokładnie ten sam odcisk palca kompilacji.
2. Zainstaluj CTS Verifier: zainstaluj najnowszą wersję APK CTS Verifier, którą możesz pobrać z udostępnionego eksploratora kompilacji.

3. Równoległe wykonywanie testów:

   1. Zamontuj DUT na osobnych stanowiskach.
   2. Uruchom równolegle różne sceny Camera ITS na każdym urządzeniu.
   3. Zbieranie 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 się nie powiodły.

4. Przesyłanie raportów: prześlij kilka raportów CTS Verifier zebranych ze wszystkich urządzeń.

5. Sprawdzanie wyników: 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 się powiodły, 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 we wszystkich zbiorczych raportach.

Model szumu DNG

Urządzenia, które reklamują możliwość przechwytywania RAW lub DNG, muszą udostępniać model szumu w metadanych wyniku przechwytywania każdego zdjęcia RAW. Ten model szumu musi być osadzony w HAL aparatu dla każdego aparatu (np. przedniego i tylnego) na urządzeniu, które deklaruje obsługę.

Implementacja modelu szumu

Aby zaimplementować model szumu, wykonaj te czynności, aby wygenerować model szumu i osadzić go w HAL aparatu.

1. Aby wygenerować model szumu dla każdego aparatu, uruchom skrypt dng_noise_model.py w katalogu tools. Wygeneruje to fragment kodu C. Więcej informacji o tym, jak skonfigurować aparat i środowisko przechwytywania, znajdziesz w dokumencie DngNoiseModel.pdf w katalogu tools.

2. Aby zaimplementować 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 zdjęcia podane w danych aparatu są prawidłowe.

Testy zaliczone z niewielkim marginesem (stan testu PASS*)

W Androidzie 17 lub nowszym zaliczenie z niewielkim marginesem (PASS*) oznacza, że test został zaliczony, ale jego dane skuteczności są bardzo bliskie predefiniowanego progu zaliczenia. Chociaż test technicznie spełnia kryteria zaliczenia, bliskość granicy niepowodzenia sugeruje potrzebę dokładniejszego zbadania.

Zalety zaliczenia z niewielkim marginesem

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 poprawia ogólną stabilność.

• Wyższa 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 wymagany 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 niewielkim marginesem.

• 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 o wszystkich testach oznaczonych jako PASS*, co pozwala im zbadać konkretny test i jego dane.

• Raportowanie: stany zaliczenia z niewielkim marginesem są wyraźnie wskazywane w raportach testów i panelach, aby zapewnić lepszą widoczność jako PASS* w raporcie ItsTestSummary, podobnie jak Fail* w przypadku testów not_yet_mandated. Aby uniknąć dalszych nieporozumień, test zachowuje stan zielony, ponieważ nadal mieści się w ustalonych progach. Stan PASS* dotyczy tylko klasy testu, a nie całej sceny. Na przykład Scene_0 może być uznana za PASS, 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 niewielkim marginesem. 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 z 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 Camera ITS, co prowadzi do stabilnego i wysokiej jakości produktu.