실습 앱 실행과 환경 기록
80분 안팎
학습 목표
제공 앱의 실행 절차와 환경 차이를 확인합니다.
개념
같은 입력보다 먼저 같은 환경을 준비합니다
개발자에게 “제 컴퓨터에서는 실패합니다”라고 전달해도 어떤 버전을 어떤 조건으로 실행했는지 모르면 재현 출발점을 잡기 어렵습니다. QA가 환경을 기록하는 목적은 정보를 많이 모으는 것이 아니라 결과를 바꿀 조건을 찾는 것입니다. 이번에는 앞 모듈의 설계표를 이어받아 HTTP 응답과 메모리 저장 효과를 관찰할 준비를 합니다. 동료가 같은 환경을 만들고 검증 범위를 이해할 수 있는 기록이 목표입니다.
앱 이름이 같아도 결함 버전과 수정 버전에서는 결과가 달라집니다. 이번 실습은 앱 0.3.0, Spring Boot 3.1.5, JDK 17을 사용합니다. buggy와 fixed는 두 동작을 선택하는 교육용 설정이며 Git 브랜치 이름이 아닙니다. 초기화한 메모리에 합성 회원을 만들고 운영 DB와 실제 계정은 사용하지 않습니다. 재시작하면 데이터가 사라진다는 점도 재현 전제로 기록합니다.
다운로드와 실행의 공통 순서
이 모듈의 로컬 실습은 압축을 푼 lab 루트에서 시작합니다. Python 3·Node.js·JDK 17을 사용하며 app 폴더에는 Maven wrapper와 pom.xml이 있습니다. chmod +x app/mvnw로 실행 권한을 줄 수 있습니다. 학습자 명령은 app에서 ./mvnw test입니다. 저장소 자동 검사는 같은 명령에 -o -q를 붙여 캐시로 실행합니다. 오프라인 의존성 오류는 제품 결함으로 등록하지 않고 먼저 일반 test 실행으로 의존성을 준비합니다.
미션 starter는 앞 모듈 solution의 spec·cases·검사기를 그대로 포함합니다. design_check.py와 check.py를 수정하지 않습니다. 설계 원본의 status planned는 실행 결과로 덮어쓰지 않습니다. 이번 실행은 reports/replay.json에 따로 남겨 설계 의도와 관찰 사실을 분리합니다. 해시 검사가 이전 파일 변경을 알려 주면 원래 산출물을 복원하고 추가 문서에서 보완합니다. 운영 config나 전체 저장소 테스트를 실행하는 절차는 없습니다.
각 실습에는 시작본과 완성본이 있습니다. 시작본 실패는 앱을 고치라는 뜻이 아니라 환경 기록과 탐색 노트에 빠진 내용을 채우라는 뜻입니다. 완성본은 형식 검사 통과의 비교 자료입니다. 자신의 OS와 Java 세부 버전은 reports/environment.json에서 읽어 reports/setup.json에 옮깁니다. 다른 작성자의 환경값을 그대로 제출하면 환경 불일치 검사가 실패할 수 있습니다. 완성본도 다른 컴퓨터에서는 해당 환경 기록을 갱신합니다.
네트워크 실행과 서버 내부 검사를 구별합니다
기본 자동 검사는 MockMvc로 Spring MVC의 요청 처리와 응답을 실행합니다. 실제 포트에 접속하는 검사가 아니며 브라우저도 열지 않습니다. HTTP 200, JSON 판정, 처리 전후 회원 수와 닉네임을 비교합니다. 이 방식은 요청 처리 결함을 빠르게 재현하지만 화면 초점, Tab 이동, 실제 네트워크 연결을 증명하지 않습니다. environment의 mode와 browser 필드에 이 차이를 남깁니다.
가입 관련 11개 사례는 실행할 수 있습니다. 프로필·세션 사례 15개는 이번 앱에 기능이 없어 blocked로 남습니다. 가입 테스트가 통과했다고 프로필 권한이나 실제 세션 만료까지 검증했다고 말하지 않습니다. 로그인 화면은 가입 후 이동을 관찰하기 위한 안내 화면이며 인증 기능은 아직 없습니다. 이메일 대소문자 정책과 비ASCII 길이 단위도 이전 보류 범위를 유지합니다.
수동 화면을 보려면 app에서 ./mvnw package를 실행한 뒤 java -jar target/qa-practice-0.3.0.jar로 전면 실행합니다. 브라우저 주소는 http://127.0.0.1:18083/입니다. 이 주소는 자신의 컴퓨터에서만 접근하는 학습용 주소입니다. 별도 실행이므로 본 레슨 출력에는 서버 기동이나 화면 결과를 넣지 않습니다. 실제 실행했다면 브라우저 이름·버전과 포트 변경도 환경 기록에 추가합니다.
환경 문서에는 필요한 사실만 적습니다
OS 이름·버전, Java 버전, 앱 버전, 선택한 동작 버전, 실행 디렉터리와 명령을 기록합니다. 단순히 최신 버전이라고 쓰면 다음 사람이 같은 조건을 만들 수 없습니다. env 전체 출력은 이메일·토큰·경로를 포함할 수 있으므로 첨부하지 않습니다. capture_environment.py는 필요한 항목만 수집하며 비밀 환경변수를 출력하지 않습니다. 쉘 환경 전달의 일반 원리는 더 읽기의 env 장에서 확인합니다.
commands 배열에는 cd app과 ./mvnw test처럼 실제 시작 위치를 알 수 있는 명령을 적습니다. bash check.sh는 lab 루트 기준이고 ./mvnw는 app 기준입니다. 상대 경로는 현재 위치에 따라 의미가 달라집니다. 파일이 없다는 오류가 나오면 먼저 압축을 푼 경로와 app 폴더 존재를 확인합니다. 이름이 같은 다른 저장소의 mvnw를 실행하면 실습과 무관한 프로젝트를 검사할 수 있습니다.
환경 기록은 실패 때만 만드는 문서가 아닙니다. 수정 버전 비교에서도 같은 런타임과 데이터 초기화 조건을 사용해야 수정 효과를 설명할 수 있습니다. 버전과 입력을 동시에 바꾸면 왜 결과가 달라졌는지 분리하기 어렵습니다. 먼저 buggy에서 같은 사례를 재현하고 환경을 고정한 뒤 fixed로만 바꿔 비교합니다. 비교에서 달라진 변수는 문서에 한 줄로 표시합니다.
기동 실패를 읽고 범위를 마무리합니다
Permission denied는 wrapper 실행 권한을 확인할 신호입니다. UnsupportedClassVersionError가 나오면 Java 런타임과 빌드 대상의 불일치를 의심하고 java -version을 읽습니다. 의존성을 오프라인에서 찾지 못했다는 Maven 메시지는 캐시 준비 문제입니다. Tests run의 errors가 0이고 failures만 증가했을 때는 테스트의 기대값 불일치를 읽습니다. 서버가 실행되기도 전에 난 오류와 제품의 가입 응답 결함을 나눕니다.
수동 실행에서 Address already in use가 나오면 다른 프로세스의 상태를 바꾸지 않고 --server.port=18084로 다른 포트를 선택합니다. 주소도 새 포트로 바꾸고 문서에 적습니다. 로그의 마지막 줄만 보지 말고 최초 원인과 어떤 명령에서 났는지 기록합니다. 접속이 안 된 상태에서 가입이 실패했다는 결함을 쓰면 제품이 실제로 입력을 받았는지조차 확인하지 않은 보고가 됩니다.
레슨을 마칠 때 동료가 실행 디렉터리와 명령을 보고 같은 검사를 실행할 수 있는지 확인합니다. setup의 scope에는 HTTP 가입 검사를 실행했고 UI와 로그인 기능은 미확인이라는 범위를 씁니다. 검사 통과는 문서와 실제 환경의 주요 항목이 맞다는 뜻입니다. 저장소 운영 상태나 전체 제품 품질을 뜻하지 않습니다. 이 준비가 끝나면 다음 레슨에서 관찰의 목적과 시간을 정할 수 있습니다.
따라하기
실행 위치와 파일 확인
qa-local-app starter의 압축을 푼 루트에서 실행합니다. app/mvnw가 없으면 현재 폴더와 압축 구조를 확인합니다. 화면 실습 전에는 README의 로컬 주소와 범위를 읽습니다.
pwd
ls app/pom.xml app/mvnw환경 수집
lab 루트에서 환경 수집기를 실행합니다. output은 작성 환경에서 실제 실행한 고정 요약이며 OS 세부 버전은 생성 JSON에 있습니다.
python3 capture_environment.py실행 결과
ENV captured: Java 17 / app 0.3.0 / Spring Boot 3.1.5
가입 결과와 저장 효과 읽기
다음 계산은 합성 비교 자료를 출력하는 읽기 연습입니다. 실제 HTTP 실행 증거는 app에서 ./mvnw test 후 reports/replay.json으로 확인합니다.
const r={caseId:"TC-05",expected:"VALID",actual:"INVALID",beforeCount:0,afterCount:0};
console.log(r.caseId,r.expected===r.actual?"PASS":"FAIL",r.beforeCount+"->"+r.afterCount);실행 결과
TC-05 FAIL 0->0
현재 환경 기록과 검사
reports/setup.json에 생성 환경의 주요 항목을 옮기고 scope를 작성한 뒤 bash check.sh를 실행합니다. PASS 뒤에도 UI는 별도 확인합니다. 원본 설계 status는 바꾸지 않습니다.
bash check.sh확인 문제
실습
압축을 푼 루트에서 bash check.sh를 실행합니다. reports/environment.json의 os·runtime·appVersion·commands를 reports/setup.json에 기록하고 scope에 HTTP와 UI 범위를 구분합니다. 생성기·앱·검사기는 수정하지 않습니다. 시작본은 setup 미작성으로 실패하며 완성본은 현재 환경 기록과 일치하여 통과합니다. 앱 직접 실행과 브라우저 확인 절차는 README를 따릅니다.
실행 명령
bash check.sh
기대 결과
환경 수집·HTTP 회귀는 통과하고 작성한 setup.json의 os·runtime·appVersion·commands가 생성 환경과 일치합니다.
모범 답안
모범 답안 내려받기더 읽기
면접 질문
- 재현하기 좋은 결함 보고서의 구성을 설명해 주시면 됩니다.