REA 버전 비교: 업데이트로 무엇이 바뀌었을까요?

01. 회귀 문제 구체화하기

‘업데이트 때문에 내보내기가 안 된다’는 추측의 여지가 너무 큽니다. 입력, 동작, 차이를 적으세요. 예를 들어 따옴표가 포함된 제목이 업데이트 전에는 올바르게 내보내졌지만 이제는 잘못된 CSV 행을 만든다고 구체화하세요.

두 앱 버전을 별도 폴더에 두세요. 릴리스 표기와 아티팩트 해시를 기록하세요. 동등한 아티팩트를 비교하세요. 개발 소스 트리와 프로덕션용으로 축소된 번들은 같은 종류의 근거가 아닙니다.

npx -y [email protected] analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y [email protected] analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json

02. 보관한 분석 자료 비교하기

완전한 원본 JSON 출력을 보관하세요. 비교 절차에는 진위가 확인되는 애플리케이션 분석 자료가 필요합니다. 수동으로 편집한 요약이나 파일명 목록으로 대체할 수 없습니다.

연결된 에이전트에 사용 가능한 compare_application_versions 스키마를 확인하고 그에 맞게 두 결과를 전달하도록 요청하세요. 이렇게 하면 릴리스마다 바뀔 수 있는 중첩 입력 필드를 추측하지 않아도 됩니다. CLI에서도 같은 규격을 확인할 수 있습니다.

npx -y [email protected] compare-application-versions --schema

before.json과 after.json의 완전한 애플리케이션 분석 자료로 REA compare_application_versions를 사용하세요. 먼저 설치된 도구 스키마를 확인하세요. CSV 내보내기에 초점을 맞춰 변경된 모듈, 관련 호출 경로, 대응 관계를 확인하지 못한 부분을 보고하세요. 부분 분석에서 노드가 보이지 않는 것을 삭제 증거로 해석하지 마세요.

03. 축소된 이름보다 기능 비교하기

이미 알고 있는 버튼, IPC 채널, 포매터에서 시작하세요. 두 버전에서 같은 기능을 추적하며 바뀐 코드를 확인하세요. 빌드를 다시 하면 동작이 같아도 축소된 변수명이 바뀌는 경우가 많습니다.

모듈 해시는 정확한 동일성을 확인할 수 있습니다. 함수 이름이 바뀌거나 번들 청크 번호가 새로 붙었다는 사실만으로 의미상 변경을 입증할 수는 없습니다. 대응하지 못했거나 일부만 파싱된 영역도 보고서에 드러내세요.

• 두 버전 모두 관련 기능의 진입점이 있나요?
• 실제로 다른 소스 영역은 어디인가요?
• 변경된 분기가 실패 입력에 영향을 주나요?
• 패키징, 설정, 분석 범위 누락으로 차이를 설명할 수 있나요?

04. 두 버전에서 같은 입력 재실행하기

새 버전 앱을 열어도 이전 버전의 테스트 상태가 마이그레이션되지 않도록 별도의 일회용 데이터 폴더를 사용하세요. 같은 테스트 내용으로 정확히 같은 작업을 실행하세요. 각 실행의 출력 파일이나 해당 동작에 집중한 기록을 저장하세요.

CSV 회귀 문제라면 결과 행을 파싱해 필드를 비교하세요. 줄바꿈 같은 바이트 차이도 중요할 수 있지만, 바뀐 타임스탬프 때문에 실제 따옴표 처리 실패가 가려져서는 안 됩니다. 비교에 사용한 모든 정규화를 기록하세요.

관찰한 정확한 입력에 대한 회귀 테스트를 만드세요. 이전 출력과 새 출력을 파싱해 내보낸 필드를 비교하세요. 원시 차이와 정규화한 비교를 모두 보여 주세요. 의심되는 소스 변경과 실제로 재현한 동작을 구분하세요.

05. 유용한 버그 보고서 작성하기

두 버전의 식별 정보, 실패하는 입력 하나, 정확한 재현 절차, 관찰된 이전/새 출력, 관련된 최소 소스 차이를 포함하세요. 동작을 재현했는지 정적 코드로 예측만 했는지 명시하세요.

좋은 비교는 회귀 테스트, 호환성 우회 방법, 범위를 좁힌 대체 구현 같은 다음 행동으로 이어집니다. 이 튜토리얼은 분석 절차를 설명하며 특정 상용 릴리스에 회귀 문제가 있다고 주장하지 않습니다.