Studio의 모든 화면과 각 화면의 기능.

파일의 구성

네. Studio가 작성하거나 가져오는 모든 테스트는 팀에 이미 익숙한 프레임워크 코드입니다. 엔진은 기존 코드를 대체하지 않고 그 위에 증거 자료, 원격 측정, 판정 및 자동 복구 기능을 추가합니다.

• Playwright, JavaScript 및 TypeScript: Playwright Test 파일입니다. 상단에서는 Studio의 픽스처를 가져오며, 본문은 page, 로케이터, expect로 구성됩니다.
• Playwright, Python: 기본 pytest-playwright 형식으로, page를 인수로 받는 test_ 함수입니다. pytest만으로 실행됩니다.
• Selenium, Python: driver 픽스처를 사용하는 pytest입니다. 엔진이 아닌 곳에서 실행할 때는 작업 공간의 conftest.py가 기본 WebDriver를 대신 사용합니다.
• Selenium, JavaScript: run({ driver, By, until }) 안에 selenium-webdriver 코드가 들어갑니다. Studio의 실행기가 드라이버를 생성하고 종료합니다.
• Selenium, Java: JUnit 5, @ExtendWith(NexusExtension.class), 확장 기능이 제공하는 WebDriver 매개변수를 사용합니다. Maven으로 빌드합니다.
• Selenium 및 Playwright, C#: NUnit, NexusSeleniumTest 또는 NexusPageTest를 상속하는 클래스를 사용합니다. .NET으로 빌드합니다.
• API 테스트는 Studio 자체 JavaScript 형식을 사용합니다.

다른 환경으로 옮기는 방법

테스트, 증거 자료, 이력은 작업 공간에 파일로 저장됩니다. Nexus 없이 테스트 모음을 실행하려면: Python 테스트는 그대로 실행하고, Playwright JavaScript의 가져오기 경로는 @playwright/test로 되돌립니다(시각적 체크포인트를 추가했다면 교체해야 합니다). Selenium JavaScript의 run() 함수에는 드라이버를 시작하는 코드 몇 줄을 추가합니다. API 테스트는 다른 실행기에 맞게 다시 작성해야 합니다.

Patrol

테스트를 작성하고, 실행하고, 일정을 설정하는 곳입니다. 트리에는 모든 테스트가 브라우저별 로고와 함께 표시되며, 색상으로 상태를 구분합니다. 편집기 위의 실행 표시줄은 각 브라우저가 무엇을 하는지 글로 알려 줍니다.

• 다섯 가지 탭: 테스트 케이스, Patrol 실행, Nexus Recorder, AI 작성 도구, Test Adapter.
• 대상: 데스크톱 조합(Chromium, Firefox 및 WebKit), 모바일 에뮬레이션, 실제 기기(실제 Android 휴대전화), 또는 PC와 Android 휴대전화를 동시에 사용하는 데스크톱 + 실제 기기를 선택할 수 있으며, 증거 자료는 각 식별 정보별로 저장됩니다.
• 기본적으로 브라우저를 하나씩 순서대로 실행합니다. 설정하면 브라우저를 최대 세 개까지 동시에 실행하고 여러 테스트도 동시에 실행할 수 있습니다. Selenium은 Chromium과 Firefox에서 실행됩니다.
• 새 테스트는 실행 결과가 집계되기 전에 이력이 기록되지 않는 샌드박스에서 예행 실행됩니다.
• 기능 플래그: 각 플래그는 켜짐, 꺼짐 또는 두 상태 모두로 실행하며, 쿠키, 헤더, 로컬 저장소 또는 쿼리 문자열로 전달합니다. 카드에는 테스트가 실패한 조합이 표시됩니다.

Nexus Recorder

브라우저에서 수행하는 동작을 테스트 코드로 기록합니다. AI는 개입하지 않습니다: 클릭한 동작이 그대로 코드로 작성됩니다.

• 데스크톱, 모바일 에뮬레이션 또는 실제 기기에서 기록합니다: USB로 연결된 Android 휴대전화에서 기기 자체의 Chrome을 제어합니다. 현재는 JavaScript와 Python만 지원하며; Java와 C#은 데스크톱에서 기록할 수 있습니다.
• JavaScript, TypeScript, Python 또는 C#으로 Playwright 코드를, JavaScript, Python, Java 또는 C#으로 Selenium 코드를 작성합니다.
• 또는 페이지가 호출하는 API를 REST 또는 GraphQL 테스트로 기록합니다. 인증 또는 쿠키 헤더는 제외하고, 비밀 정보로 보이는 필드는 환경 변수로 바꿉니다.
• 선택자 맵은 AI 없이 페이지를 분석하고, 각 선택자를 HIGH, MEDIUM 또는 LOW로 평가하며, 맵을 로컬 디스크에 보관합니다.

Test Adapter

팀에서 이미 사용 중인 테스트를 직접 다시 작성하지 않고 Studio로 가져옵니다.

• 테스트를 붙여넣거나, 파일을 끌어다 놓거나, 폴더를 지정하세요: Playwright Test, mocha, jest, pytest 또는 unittest에서 실행하는 JavaScript, TypeScript 또는 Python 기반의 Playwright나 Selenium 테스트를 지원합니다.
• AI가 아닌 규칙에 따라 다시 작성합니다: 브라우저 실행과 설정은 Studio의 픽스처로 옮기고, 검증문, 조건문, 반복문, 대기는 그대로 유지합니다.
• 변경 전후의 차이를 나란히 표시하고 검증문 수를 비교합니다. 검증문이 누락되면 해당 변경을 줄별로 승인하지 않는 한 가져오기가 차단됩니다.
• 선택적으로 사용하는 AI는 규칙으로 처리할 수 없는 부분만 담당하며, 생성된 코드는 엄격한 Vet 검사를 거칩니다. 유지된 테스트는 오류 없이 세 번 실행될 때까지 샌드박스에서 예행 실행합니다.
• Cypress, WebdriverIO, Robot Framework, Java 및 C#은 지원하지 않습니다.

줄 수정 및 자동 복구

로케이터가 작동하지 않을 때의 처리 방식입니다. 사용자 모르게 수정하는 일은 없습니다.

• 자동 복구의 기본 설정은 제안입니다: 실패하면 백그라운드 브라우저가 실패한 줄까지 테스트를 재실행하고 페이지를 읽어 대체 후보를 준비합니다. AI는 사용하지 않으며, 테스트는 실패 상태로 유지됩니다.
• 줄 수정은 해당 줄의 여백에서 실행합니다: 해당 단계만 다시 기록하거나 선택자를 교체할 수 있으며, 가장 안정적인 후보부터 표시하고 XPath는 마지막에 표시합니다. 변경 사항은 저장되지 않은 상태로 편집기에 반영되며, 저장하면 승인한 것으로 간주합니다.
• 내 AI에게 선택 요청은 후보의 순서만 바꿀 수 있으며, 새 후보를 추가할 수 없습니다. 파일의 이전 버전은 타임라인에 보관됩니다.
• 로케이터 상태는 열려 있는 테스트에서 취약한 로케이터를 나열하고 같은 방식으로 수정합니다.

Devices & Mobile

엔진이 실행되는 컴퓨터에 USB로 연결한 실제 Android 휴대전화를 사용합니다. 기기 팜도, 분 단위 이용권 구매도 필요 없습니다.

• adb와 Chrome DevTools Protocol을 통해 여러 휴대전화를 동시에 연결하며, 첫 기기 연결 안내도 제공합니다.
• 화면 보기는 휴대전화 화면을 PC에 표시합니다: 이 화면에서는 조작할 수 있고, Patrol에서 열면 보기만 가능합니다.
• Playwright의 기기 프로필을 활용한 모바일 에뮬레이션을 제공합니다: Android의 Chrome, Safari 엔진인 WebKit을 사용하는 iPhone 또는 iPad, 저사양 프로필을 지원합니다. 실제 기기는 Android 휴대전화만 지원합니다: iPhone이나 iPad는 항상 에뮬레이션하며 실제 Apple 기기를 사용하지 않으므로, iOS 키보드와 시스템 제스처는 테스트하지 않습니다.
• 휴대전화에서는 테스트를 한 번에 하나씩 실행하며, 휴대전화 테스트는 항상 해당 기기가 연결된 컴퓨터에서 실행됩니다.

Watch

Patrol의 순찰 실행에서 선택한 항목을 정해진 시간 간격으로 자동 재실행합니다.

• 5분에서 24시간 간격으로 반복하거나, 지정한 날짜에 한 번 실행합니다. 직접 중지하거나, 지정한 횟수만큼 실행하거나, 지정한 날짜가 되면 종료됩니다.
• 별도 프로세스로 실행되므로 Studio를 닫아도 중단되지 않습니다. 해당 컴퓨터가 켜져 있어야 합니다: 절전 상태에서는 예약된 실행이 대기하거나 건너뛰어집니다.
• 상태가 바뀔 때만 Telegram 또는 Slack으로 ALERT 또는 RECOVERED 알림을 보냅니다.

Docker 및 SSH

Studio는 사용자 PC 또는 선택적으로 Windows 11 미니 PC에서 사용하는 Windows 11 데스크톱 앱입니다. Studio에서 엔진은 작업 공간의 테스트 모음을 이 기기에서, 이 기기의 Docker에서, 또는 SSH를 통해 다른 기기에서 실행합니다. Studio 자체는 Docker에서나 SSH를 통해 실행되지 않습니다.

• Docker에서는 테스트 모음이 같은 디스크의 실행기 컨테이너에서 실행되므로, 증거 자료는 평소처럼 작업 공간에 저장됩니다.
• SSH를 사용하는 경우, 키 기반으로 접속하는 Ubuntu 24.04 LTS, Docker Engine 및 Compose v2가 설치된 VPS에서 실행됩니다: 엔진은 로컬 Docker와 동일한 컨테이너 이미지로 해당 VPS에서 테스트 모음을 실행하며, 증거 자료는 가져오기 전까지 그곳에 보관됩니다.
• 실제 Android 휴대전화, Selenium 및 Python 테스트 모음, 인프라 카오스 테스트, 결과 가져오기는 항상 Studio가 설치된 컴퓨터에서 실행됩니다.
• 상단 표시줄에는 작업 공간이 실행되는 위치와 해당 환경의 RAM 및 CPU가 표시됩니다. 적응형 실행 조절을 켜면 사용 가능한 RAM에 맞춰 동시에 실행할 브라우저 수를 조정합니다.

API 테스트

일곱 가지 전용 판정을 제공하는 REST 및 GraphQL 테스트입니다. 다른 테스트처럼 Patrol에서 실행되며, 각 엔드포인트의 자료는 Evidence Locker의 API 테스트 섹션에 별도 폴더로 저장됩니다.

• API_SECURE: 모든 검증 조건을 충족했고 응답 구조가 마지막 기록과 일치합니다. API_FLAKY: 재시도에서 통과했습니다. API_DRIFTED: 통과했지만 구조가 바뀌었으며, 차이 내역에 추가, 삭제 또는 유형이 변경된 각 필드가 표시됩니다. 엄격 모드로 설정하기 전까지 구조 변경은 통과로 처리됩니다.
• API_BREACHED: 검증 조건을 충족하지 못했습니다. API_DEGRADED: 지연 시간 허용 한도(기본값 2000 ms)를 초과했으며, 성능에 엄격 모드를 적용할 때만 이 판정이 내려집니다. API_VULNERABLE: 401 또는 403이 예상되는 요청에 인증 정보 없이 응답을 받았습니다; 보안 헤더 누락만으로는 이 판정이 내려지지 않습니다. API_BLOCKED: 429 또는 Cloudflare나 Akamai 식별 정보가 있는 403으로, 요청이 제품에 도달하지 못했습니다.
• 화면 구성: 엔드포인트, 통과, 허용 한도 초과 실행, 구조 변경, 취약점 발견 이력 및 관측된 최장 응답 시간 타일; 전체, 실패, 구조 변경 및 취약 필터; 엔드포인트, 판정, 최솟값, 중앙값, p95, 최댓값, n 및 통과율 표. 관측 횟수가 20회 미만인 엔드포인트에는 백분위수 대신 대시가 표시됩니다.
• 실행을 클릭하면 보고서, 요청, 응답, 성능, 스키마, AI 분석의 여섯 탭이 열리며, 마지막 탭은 AI를 연결하면 내용이 채워집니다. 흐름에서 실패한 단계에는 N단계부터 다시 실행과 실패한 단계 다시 실행이 제공됩니다.
• 실행별로 api-evidence에 저장되는 파일: request.json, response.json, performance.json, schema.json, report.md 및 metadata.json. 헤더와 본문의 비밀 정보는 가려집니다. report.md는 호출을 재현하는 curl 명령으로 끝납니다. 통과한 실행은 테스트별로 최신 20개를 보관하며; 실패한 실행은 항상 보관합니다.
• 만들기: 새 테스트에서 API를 선택하면 유형을 지정해야 합니다: REST, GraphQL 또는 HTTP 기반 SOAP. 각 유형은 작성된 그대로 공개 엔드포인트에 대해 실행할 수 있는 테스트 사례로 시작합니다. 파일의 첫 줄에 유형이 기록되므로 파일 트리에도 표시되며, 파일을 이동해도 유형은 바뀌지 않습니다. SOAP는 XML 파서 없이 XML을 텍스트로 전송하고 텍스트 규칙으로 검사합니다. staging과 prod 같은 이름의 환경은 각각 자체 기본 URL을 유지하며, 토큰은 해당 변수의 이름으로만 보관됩니다. 폴더는 중첩할 수 있습니다.
• API Flow Recorder: Nexus Recorder에서 페이지가 보내는 호출을 기록한 다음 테스트 모음이 작성되기 전에 기록을 검토하세요. 호출에는 각 호출의 메서드, 경로, 상태, 분류 및 그 이유가 나열됩니다. 처음에는 업무, 인증, 조회 및 상태 변경 API 호출만 테스트 모음에 포함됩니다; 원격 측정 비콘, 외부 호스트, 정적 자원 및 사전 요청은 제외되며, 선택하여 다시 포함할 수 있습니다. 흐름은 로그인 토큰처럼 한 응답의 값을 이후 요청으로 연결하며, 정보 가림에는 비밀 정보로 추정되어 저장 금지로 표시된 필드가 나열됩니다.
• 검토 화면에서 테스트 생성은 테스트 모음을 작성하고, OpenAPI 생성은 기록된 값 없이 자료형과 상태 코드를 포함한 3.1 초안을 작성하며, 부하 테스트는 호출을 부하 계획으로 엽니다.

History

매 실행마다 각 식별 환경에서 수행하는 모든 테스트.

• 요약, 안정성, 성능, API, 실패, 테스트 범위, 품질, 단위 및 통합 테스트 결과를 보여 주는 탭.
• 세션별, 일별 또는 주별 추이: 악화됨, 복구됨, 여전히 실패, 느려짐. 식별 환경 매트릭스는 모든 테스트를 모든 브라우저 및 기기와 교차하여 보여 줍니다.
• 단위 및 통합 테스트: Jest, Vitest, pytest, Maven 또는 gotestsum의 JUnit XML을 가져오며, 종단 간 테스트 수치와 별도로 관리합니다.
• 증거 보관함과 순찰의 위험도: 테스트 결과가 뒤바뀌거나, 실패하거나, 시간을 소모하는 빈도에 따른 순위입니다. 5회 미만 실행한 테스트는 불안정하다고 판정하지 않으며, 실행 이력에 대한 로지스틱 회귀로 위험도를 예측하고 데이터가 부족하면 EWMA를 사용합니다.

이력 한 행에 담긴 내용 →

Visual Regression

승인한 이미지와 픽셀 단위로 비교합니다. --visual로 처음 실행하면 기준 이미지가 설정되고 이후 모든 실행은 이 이미지와 비교됩니다. 화면을 열면 판단이 필요한 항목인 픽셀 변경이 표시됩니다.

• 각 회귀는 카드로 표시됩니다: 테스트, 체크포인트, 허용치 대비 변경된 픽셀 비율, "M개 중 N개 픽셀", 크기, 변경된 영역 수, 그리고 캡처가 끝내 안정되지 않았을 때의 안내가 담깁니다. 안티앨리어싱으로 다시 혼합된 가장자리 픽셀은 집계하지 않습니다.
• 나란히 보기, 밀어서 보기, 차이 보기, 번갈아 보기와 동일한 체크포인트의 이전 실행을 확인할 수 있습니다: 회귀가 한 번 발생했다면 하나의 사실이지만, 네 번 연속 조금씩 악화되었다면 UI가 점차 변하고 있다는 뜻이며, 네 번 모두 같다면 불안정한 상태를 기준으로 테스트를 기록했다는 뜻입니다.
• 기준 이미지는 브라우저와 플랫폼별로 보관됩니다. 이 변경 승인은 해당 체크포인트의 이미지만 교체합니다; 모두 승인은 공통 머리글처럼 여러 체크포인트에 영향을 주는 변경에 사용합니다.
• 같은 화면에 있는 설정과 기본값입니다: 실행할 때마다 픽셀 비교 꺼짐, 전체 페이지 허용치 1.0%, 요소 체크포인트 허용치 0.1%, 회귀 발생 시 테스트 실패 처리 꺼짐(회귀는 기록되고 테스트는 SECURE 상태를 유지하며; 켜면 BREACHED로 표시됨), 시계나 광고를 가리는 모든 사진에서 가리기(CSS 선택자).
• 회귀별로 visual-regression에 저장됩니다: baseline.png, current.png, diff.png(빨강은 변경, 주황은 무시된 안티앨리어싱, 회색은 변경 없음), visual-report.md 및 result.json. 테스트와 체크포인트별로 최신 10개를 보관하며 한 묶음은 약 1 MB입니다.

Executive Report

출시 승인자를 위해 PDF 한 장에 담은 출시 품질.

• 기간을 선택하세요: 전체, 최근 7일, 30일, 90일 또는 사용자 지정 범위.
• 신뢰도, 커버리지, 통과율을 바탕으로 출시 진행, 주의 또는 보류를 판단합니다.
• 실패의 근본 원인과 비즈니스 영향, 테스트별 안정성, 보안 발견 사항, API 테스트, 종단 간·통합·단위 테스트 결과로 구성된 품질 피라미드를 제공합니다.
• 권장 사항은 AI가 아닌 규칙을 기반으로 합니다.

Chaos Lab

브라우저부터 컨테이너까지 아우르는 복원력 테스트.

• 브라우저 장애: 네트워크 (≈3G) 지연, 테스트 도중 오프라인 단절, Chromium의 CPU 4배 속도 제한을 개별적으로 또는 한꺼번에 적용하고, 패킷 손실과 메모리 압박까지 추가합니다.
• 인프라: Docker 컨테이너나 테스트 대상 앱을 등록한 다음, 대상에 대한 테스트 실행 여부와 관계없이 일시 중지, 중지, 강제 종료 또는 재시작합니다.
• 500 ms마다 상태를 점검하여 감지 시간, 복구 시간, 가용성으로 복구를 측정합니다. 결과는 RESILIENT, DEGRADED, NOT_RECOVERED 또는 NOT_INJECTED로 표시됩니다.
• 등록된 대상에만 적용되며, Studio 자체 컨테이너에는 절대 적용되지 않습니다. 장애는 발생 전에 기록되며, 장애 적용 후에는 항상 원상 복구됩니다. 장애가 발생하지 않은 통과 결과는 복원력이 있다고 판정하지 않습니다.

Load

동시 실행 수, 백분위수와 판정을 엔진에서 직접 제공합니다.

• 외부 부하 도구 없이 엔진의 작업자 스레드를 사용하며, 레이블별 statistics.json 파일로 보고서를 제공합니다.
• 초당 요청 수, p50, p90, p95, p99, 오류율과 APDEX를 제공합니다. 판정은 PASS, OVER_BUDGET 또는 UNMEASURED입니다.
• 부하 상태에서 Web Vitals 측정: 실제 Chromium 페이지에서 부하 발생 전, 부하 발생 중 15초마다, 부하 종료 후에 LCP, CLS, FCP, TTFB, TBT를 측정합니다.
• AUTHORIZED를 입력해야만 실행 준비 상태가 되며, 대상이 현재 기기가 아니면 다시 확인을 요청합니다.

보안

설정한 보안 검사를 실행하고 발견한 내용을 증거와 함께 기록합니다. DAST 스캐너인 Smart Monkey는 보안 화면의 검사 실행 아래에 있습니다.

• Smart Monkey는 테스트 권한이 있는 대상을 검사합니다: XSS, SQL 삽입, 접근 제어 결함, IDOR, SSRF, 명령어 삽입, 경로 탐색, 템플릿 삽입, XXE, 개방형 리디렉션, CORS, 보안 헤더, 쿠키 플래그 등을 확인합니다.
• 단계를 선택하거나 모두 실행하세요: pre-auth, auth-transit, post-auth, http-probes(쿠키, CORS, 헤더, 리디렉션, 파일), ssrf, cmdi, xss-oob, sqli(블라인드, 불리언 및 시간 기반), idor 또는 agent(조율 및 예산 제한이 적용되는 탐색). 선택한 단계는 쉬운 말로 된 한 줄 설명으로 안내됩니다.
• 대역 외 확인에는 사용자 컴퓨터의 HTTP 수신기를 사용합니다: 각 페이로드에는 무작위 32자 토큰이 담기며, SSRF, 명령어 삽입 및 블라인드 XSS는 대상이 해당 토큰으로 콜백을 보낼 때만 인정됩니다. DNS 콜백이나 Interactsh 또는 Burp Collaborator 같은 공개 서비스를 사용하지 않으므로 대상에 관한 정보는 제3자에게 전달되지 않습니다.
• 테스트 권한: 권한 근거가 기록되지 않은 호스트는 패킷을 보내기 전에 거부되며, 사설 및 로컬 주소는 근거 없이도 허용됩니다. 모든 검사는 권한, 실행자, 대상, 작업 및 60분의 허용 시간을 기록하며, 이 기록은 로컬에서 봉인되고 어디에도 전송되지 않습니다.
• 각 세션은 발견 사항별 폴더에 audit_report.json, screenshot.png, 녹화가 보존된 경우 replay.webm, 그리고 실행 가능한 replay.mjs를 저장합니다. nexus replay는 해당 발견 사항의 폴더를 대상으로 이 스크립트를 실행합니다. 세션 최상위 폴더에는 session_summary.json과 results.sarif가 추가됩니다. 최신 10개 세션이 보관됩니다.
• SARIF 2.1.0 형식이며 발견 사항마다 결과 하나가 생성됩니다: 규칙은 발견 사항의 CWE이고, CRITICAL과 HIGH는 error, MEDIUM은 warning, 나머지는 note로 표시되며, 위치는 검사한 URL입니다. GitHub 코드 검사와 GitLab에서 바로 가져올 수 있으며, nexus monkey는 Studio 없이 CI 실행기에서 이를 기록합니다.

실행 중 품질 점검

순찰 실행 또는 설정에서 실행별로 활성화합니다. 각 점검은 엄격 모드로 전환하기 전까지 권고 사항이며, 전환 후에는 판정에 반영됩니다.

• axe-core로 WCAG 2.1 AA 기준에 따라 접근성을 점검하고, 휴대전화의 터치 대상 크기도 확인합니다.
• Web Vitals를 허용 기준(LCP 2.5 s, CLS 0.1, INP 200 ms, TTFB 800 ms)과 비교하고, 지연 로딩 점검으로 페이지의 이미지 로딩 방식을 A부터 F까지 평가합니다.
• 차단 감지: 403, 429 또는 인증 확인 페이지는 BLOCKED로 표시됩니다. 기본적으로 사이트에서 자동화 신호를 볼 수 없도록 숨기며, 스위치 하나로 이 기능을 끌 수 있습니다.
• 엄격 모드에서는 기준 위반을 A11Y_VIOLATION, PERFORMANCE_DEGRADED 또는 SECURITY_VIOLATION으로 판정합니다.

Timeouts

실행 결과가 TIMEOUT으로 표시되기 전까지 Playwright 단계가 대기할 수 있는 시간입니다. 설정의 실행 & 시간 제한에서 네 가지 값을 조절합니다. 아래 값은 기본값입니다.

AI Providers

실패의 정밀 원인 분석과 Smart Monkey 발견 사항의 분류를 담당하는 AI.

• 기본값은 로컬 전용입니다: Ollama를 통해 현재 기기의 모델을 사용하며, 클라우드로 대체 전환하지 않습니다.
• 원할 때 자동, Anthropic 또는 OpenAI를 선택할 수 있으며, 프롬프트가 네트워크 외부로 전송될 때는 화면에 명확히 표시됩니다. 키는 저장만 가능하며 조회할 수 없습니다.

Settings

다른 화면의 동작을 제어하는 설정을 한곳에 모았습니다.

• 연동: Jira, Xray, Azure DevOps, Slack 및 Telegram은 직접 켜기 전까지 모두 꺼져 있습니다. Jira와 Azure Boards는 실패한 테스트마다 이슈 하나를 유지합니다: 실패(BREACHED, BREACHED_FLAKY 또는 CHAOS_BREACHED)나 TIMEOUT이 발생하면 이슈를 열고, 반복되면 댓글을 추가하며, 정상 통과하면 닫습니다. 차단, 비정상 종료, 사이트 접속 불가 또는 구성 오류로는 이슈를 열지 않습니다. 연동
• 증거 및 보관: 각 테스트가 보관할 버그 보고서, 통과 시 스크린샷, 검사 세션의 수를 설정합니다.
• 선택자와 자동 복구, RAM 압박에 따른 적응형 속도 조절, 브라우저에 노출되는 자동화 신호를 설정합니다.