Brain443. 테스트 절차 (Test Procedure) / 테스트 스크립트 (Test Script)
핵심 인사이트 (3줄 요약)
- 본질: 테스트 절차(Test Procedure)는 테스트 케이스의 구체적인 실행 방법을 순차적으로 기술한 문서이며, 테스트 스크립트(Test Script)는 이를自動化 가능한 형태로 기술한 스크립트이다. 둘 다 "어떻게 테스트를 실행할 것인가"에 대한 상세 지침을 제공하며, 테스트의 재현성과 일관성을 보장하는 데 필수적인 요소이다.
- 가치: 표준화된 테스트 절차는 테스트 실행자 간의 결과 차이를 최소화하고,新人 onboarding 시간을 단축시키며, 감사 및 컴플라이언스 요구사항 충족에 기여한다. 자동화된 테스트 스크립트는 반복적 테스트의 효율성을 극대화하여 CI/CD 파이프라인의 핵심 구성 요소로 활용된다.
- 융합: 테스트 절차는 수동 테스트와 자동화 테스트 모두에 적용되며, 최근에는 테스트 자동화 프레임워크(Selenium, Appium, JUnit, pytest 등)와의 결합을 통해 "스크립트화된 테스트 절차"로 진화하고 있다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 테스트 절차(Test Procedure)는 특정 테스트 케이스를 실행하기 위해 필요한 단계별 지침을 상세히 기술한 문서이다. 각 단계는 명확한 작업(입력, 클릭, 확인 등)과 예상되는 중간 결과를 포함한다. 테스트 스크립트(Test Script)는 이러한 절차를 프로그래밍 가능한 형태로 작성한 것으로, 도구를利用하여 자동으로 실행될 수 있다.
-
필요성:测试用例が抽象적 실행 지침만 제공하는 경우, 실제 실행할 때 실행자마다 접근 방식이 다를 수 있다. 테스트 절차는 이러한 variability를 방지하여 동일한 결과를 재현할 수 있게 한다. 특히 규제的行业(항공, 의료, 금융)에서는 감사 가능한 테스트 절차 문서가 필수적이다.
-
💡 비유: 테스트 절차는 **'医療机械设备 操作手册'**과 같다. MRI 操作手册에는 "1. 환자를 스캔台에 눕힌다", "2. 스캔部位를 레이저로 맞춤다", "3. 스캔 시작 버튼을 누른다" 등詳細な 순차적 지침이 포함된다. 소프트웨어 테스트 절차도 마찬가지로, 각 단계가 순서대로 명확히 기록되어 있어,操作자 누구든 동일한 결과를 얻을 수 있다.
-
등장 배경 및 발전 과정:
- 1980년대: 공식 테스트 문서화 표준( military, aerospace)에서 테스트 절차 개념 정립
- 1990년대: WinRunner, QuickTest Professional 등의 상용 테스트 자동화 도구 등장
- 2000년대: 오픈소스 자동화 프레임워크(Selenium, JUnit) 대중화
- 현재: CI/CD, DevOps 환경에서 테스트 자동화가 표준으로 정착
-
📢 섹션 요약 비유: 테스트 절차는 **'평행우는길 찾기 내비게이션'**과 같다. 내비게이션은 "500m 직진 → 신호가 있는 교차로에서 우회전 → 1km 후 좌회전"처럼 단계별로 정확한 길을 안내한다. 소프트웨어 테스트 절차도 마찬가지로 "①로그인 페이지 접속 → ②사용자명 입력 → ③비밀번호 입력 → ④로그인 버튼 클릭"과 같이 정확한 단계별 지침을 제공하여, 사용자(테스터)들이 동일한 목적지(테스트 결과)에 도달할 수 있게 한다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
테스트 절차의 구성 요소
[테스트 절차 기본 구성 요소]
┌─────────────────────────────────────────────────────────────────┐
│ 테스트 절차 (Test Procedure) 구조 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [Header / 머리말] │
│ - 절차 ID, 버전, 작성일, 작성자 │
│ - 관련 테스트 케이스 ID 목록 │
│ - 전제조건 (Precondition) 요약 │
│ │
│ [단계별 실행 지침] │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 단계 | 작업 내용 | 기대 결과 | 확인 방법 │ │
│ ├─────────────────────────────────────────────────────────┤ │
│ │ 1 | 시스템에 접속 | 로그인 화면 표시 | 화면 확인 │ │
│ │ 2 | 사용자명 입력 | 입력필드에 텍스트 표시 | 시각적 확인 │ │
│ │ 3 | 비밀번호 입력 | 비밀번호가 ***로 표시 | 시각적 확인 │ │
│ │ 4 | 로그인 버튼 클릭 | 처리 중 표시 | 로딩 아이콘 표시 │ │
│ │ 5 | 결과 확인 | 메인 화면 또는 오류 메시지 | 시각적 확인 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ [Clean-up / 사후 처리] │
│ - 테스트 데이터 삭제 │
│ - 세션 종료 │
│ - 환경 복원 │
│ │
│ [예외 처리] │
│ - 예상치 못한 결과가 나왔을 때의 조치 │
│ - 결함 리포팅 절차 │
│ │
└─────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 테스트 절차는 머리말, 단계별 실행 지침, 사후 처리, 예외 처리 등의 구성 요소로 이루어진다. 핵심인 단계별 실행 지침은 각 단계를 순차적으로 기술하며, 작업 내용, 기대 결과, 확인 방법을 명시하여 누구든 동일한 테스트를 재현할 수 있게 한다.
테스트 스크립트의 유형
[테스트 스크립트 유형]
┌─────────────────────────────────────────────────────────────────┐
│ 테스트 스크립트 유형 분류 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [1. 선형 스크립트 (Linear Script)] │
│ -最简单的 형태:录制된 操作을 그대로 실행 │
│ -优点: 작성 용이 │
│ -缺点: 데이터 변경에 취약, 재사용 어려움 │
│ 예: Selenium IDE에서录制한 단순 스크립트 │
│ │
│ [2. 구조화된 스크립트 (Structured Script)] │
│ - 제어 구조(if, loop)를 추가하여灵活性 향상 │
│ -的优点: 조건에 따른分支処理 가능 │
│ -缺点: 프로그래밍 지식 필요 │
│ 예: if (isElementPresent("error")) { handleError(); } │
│ │
│ [3. 데이터 기반 스크립트 (Data-Driven Script)] │
│ - 테스트 데이터를 별도 파일(CSV, Excel)에 분리 │
│ -的优点: 동일 스크립트로 다양한 데이터 테스트 가능 │
│ -缺点: 데이터 파일 관리 필요 │
│ 예: @DataProvider를利用한 TestNG 데이터_driven 테스트 │
│ │
│ [4. 키워드 기반 스크립트 (Keyword-Driven Script)] │
│ - 키워드(Login, Click, Verify)를 추상화하여非기술자도 이해 가능 │
│ -的优点: 행위 주도 테스트(BDD)와 유사 │
│ -缺点: 키워드 사전 정의 및 관리 필요 │
│ 예: Robot Framework │
│ │
│ [5. 하이브리드 스크립트 (Hybrid Script)] │
│ - 데이터 기반 + 키워드 기반 조합 │
│ - 현재 가장 널리 사용되는 접근법 │
│ -优点: 유연성 + 재사용성 균형 │
│ │
└─────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 테스트 스크립트는 선형에서 하이브리드까지 다양한 성숙도 수준이 있다. 선형 스크립트는 simplest하지만 유연성이 낮고, 하이브리드 스크립트는 데이터와 키워드를 결합하여 실용性与 재사용성 사이의 균형을 맞춘다.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
테스트 절차 작성 예시: 웹 로그인 기능
[웹 애플리케이션 로그인 테스트 절차]
┌─────────────────────────────────────────────────────────────────┐
│ TC-001: 유효한 자격 증명으로 로그인 테스트 절차 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [전제조건] │
│ - 테스트 환경: https://test.example.com │
│ - 테스트 계정: user_id="testuser", password="Test123!" │
│ - 브라우저: Chrome 최신 버전 │
│ │
│ [단계별 실행 지침] │
│ 1. Chrome 브라우저를 실행한다. │
│ 기대 결과: 빈 Chrome 창이 표시된다. │
│ 확인 방법: 시각적 확인 │
│ │
│ 2. 주소 표시줄에 "https://test.example.com/login"를 입력한다. │
│ 기대 결과: 로그인 페이지가 로드된다. │
│ 확인 방법: URL 확인 + 페이지 타이틀 "로그인" 표시 │
│ │
│ 3. "사용자명" 입력필드를 찾고 "testuser"를 입력한다. │
│ 기대 결과: 입력필드에 "testuser"가 표시된다. │
│ 확인 방법: 입력필드 텍스트 읽기 검증 │
│ │
│ 4. "비밀번호" 입력필드를 찾고 "Test123!"를 입력한다. │
│ 기대 결과: 입력필드에 "****"로 표시된다. (비밀번호 숨김) │
│ 확인 방법: 입력필드 type="password" 확인 │
│ │
│ 5. "로그인" 버튼을 찾고 클릭한다. │
│ 기대 결과: 버튼이 클릭되고 페이지가 로딩된다. │
│ 확인 방법: 버튼 클릭 이벤트 발생 + 로딩 표시 │
│ │
│ 6. 페이지 로드가 완료될 때까지 최대 10초간 기다린다. │
│ 기대 결과: 페이지 로드가 완료된다. │
│ 확인 방법: 페이지 로딩 스피너(loading spinner) 사라짐 │
│ │
│ 7. 현재 페이지 URL이 "/dashboard"로 변경되었는지 확인한다. │
│ 기대 결과: URL이 "https://test.example.com/dashboard" │
│ 확인 방법: URL 읽기 검증 │
│ │
│ 8. 화면 상단에 "환영합니다, testuser님" 메시지가 표시되는지 확인한다.│
│ 기대 결과: 메시지가 표시된다. │
│ 확인 방법: 텍스트 포함 검증 │
│ │
│ [사후 처리] │
│ - 브라우저를 종료한다. │
│ - 테스트 데이터 정리 (세션 쿠키 등) │
│ │
│ [예외 처리] │
│ - 6단계에서 10초 이내에 페이지가 로드되지 않으면: │
│ → 5초 더 대기 후 재확인 │
│ → 그래도 안 되면 "TC-001: 로그인 시간 초과"로 결함 등록 │
│ - 8단계에서 메시지가 표시되지 않으면: │
│ → 현재 페이지 전체 스크린샷 캡처 │
│ → "TC-001: 로그인 성공 후 메시지 미표시"로 결함 등록 │
│ │
└─────────────────────────────────────────────────────────────────┘
###自动化测试脚本 예시 (Python + Selenium)
[自动化登录测试脚本 예시]
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
def test_login_valid_credentials():
"""TC-001: 유효한 자격 증명으로 로그인"""
# 1. 브라우저 실행
driver = webdriver.Chrome()
driver.get("https://test.example.com/login")
try:
# 2. 사용자명 입력
username_input = WebDriverWait(driver, 10).until(
EC.presence_of_element_located((By.ID, "username"))
)
username_input.send_keys("testuser")
# 3. 비밀번호 입력
password_input = driver.find_element(By.ID, "password")
password_input.send_keys("Test123!")
# 4. 로그인 버튼 클릭
login_button = driver.find_element(By.ID, "login-btn")
login_button.click()
# 5. 대시보드 페이지 이동 확인
WebDriverWait(driver, 10).until(
EC.url_contains("/dashboard")
)
# 6. 환영 메시지 확인
welcome_msg = driver.find_element(By.CLASS_NAME, "welcome-message")
assert "testuser" in welcome_msg.text, f"Expected testuser in message, got: {welcome_msg.text}"
print("TC-001 PASSED: 로그인 성공")
except Exception as e:
print(f"TC-001 FAILED: {str(e)}")
driver.save_screenshot("tc001_failure.png")
raise
finally:
driver.quit()
Ⅳ. 품질 관리 및 테스트 (Quality & Testing)
테스트 절차 품질 기준
[좋은 테스트 절차/스크립트의 조건]
1. 명확성 (Clarity)
- 각 단계가 모호하지 않고 정확하게 기술되어야 함
- "클릭한다"보다 "로그인 버튼을 클릭한다"가 더 명확
2. 완전성 (Completeness)
- 모든 필요한 단계가 누락 없이 포함되어야 함
- 전제조건, 실행단계, 사후처리, 예외처리 모두 포함
3. 재현 가능성 (Reproducibility)
- 동일한 절차로 항상 동일한 결과를 얻을 수 있어야 함
- 시간 의존적 요소(날짜, 시간 등)나 랜덤 값이 없어야 함
4. 독립성 (Independence)
- 다른 테스트 절차와의 순서 의존성이 없어야 함
- 각 테스트는 고유한 전제조건을 가져야 함
5. 유지보수 용이성 (Maintainability)
- 변경이 용이해야 함
- 데이터와 로직이 분리되어 있어야 함
6. 실행 가능성 (Executability)
- 실제 환경에서 실행 가능한 절차여야 함
- 참조하는 요소( locator 등)가 유효해야 함
- 📢 섹션 요약 비유: 테스트 절차는 **'IKEA 가구 조립 설명서'**와 같다. 조립 설명서에는 "1. 패널 A와 나사 B를，拿起하여 연결한다", "2. 육각 렌치로 나사를時計 방향으로 돌린다" 등 단계별로 명확한 지침이 있다. IKEA 설명서가 명확하고 순서대로 되어 있어 누구든 IKEA Furniture를 조립할 수 있듯이, 테스트 절차도 명확하고 순서대로 되어 있어 누구든 동일한 테스트를 실행할 수 있다.
Ⅴ. 최신 트렌드 및 결론 (Trends & Conclusion)
최신 동향
- Codeless Test Automation: Leapwork, Tosca, Mabl 등의 codeless 테스트 자동화 도구가 확산되고 있어, 프로그래밍 지식 없이도 테스트 스크립트를 생성하고 실행할 수 있게 되었다. 이는 테스트 자동화의 진입 장벽을 크게 낮추고 있다.
- AI 기반 스크립트 생성: 머신러닝이 UI의 구조를 분석하여 자동으로 테스트 스크립트를 생성하거나, 기존 스크립트의 불완전한 部分을 보완하는研究方向가 활발히 진행되고 있다.
- 셀프 힐링(Self-Healing) 스크립트: UI가 변경되어도 자동으로_locator를 조정하여 스크립트의 지속적 실행을 가능하게 하는 기술이 도입되고 있다. 이는テスト自動化のメンテナンス负荷을 줄이는 데 기여한다.
한계점 및 보완
- 문서 vs 실제 불일치: 테스트 절차 문서가 실제 UI와 달라지면 실행 불가능해진다. 이를 해결하기 위해 문서의 정기적更新과 프로그래밍 기반 테스트 스크립트의活用が推奨される.
- 自動화 과잉: 모든 테스트를 자동화하는 것이 항상 바람직한 것은 아니다.探索적 테스트나 일회성 테스트에는手動测试 절차가 더 적절할 수 있다.
- 跨平台 지원: 다양한 브라우저, 기기, OS에서 테스트해야 하는 경우, 각 환경에 맞는 스크립트 유지보수가 부담이 된다.크로스 브라우저 테스트 도구( BrowserStack, Sauce Labs) 활용이 권장된다.
테스트 절차와 테스트 스크립트는测试执行의 표준화와自动化의核心要素로서, 소프트웨어 품질 보증에 필수적이다. 적절한粒度로 설계된 테스트 절차는テストの再現性と効率性を 높이고, 자동화된 테스트 스크립트는 CI/CD 환경에서의 지속적 품질 검증을 가능하게 한다. 앞으로 AI/ML 기반의 自己修復型 스크립트, Codeless 도구 등의 발전과 함께 테스트 절차/스크립트의 작성과 관리 방식도 더욱 지능화되고高效화될 것으로 전망된다.
- 📢 섹션 요약 비유: 테스트 절차와 스크립트는 **'오케스트라의 지휘자 악보'**와 같다. 지휘자 악보에는 각 악기의 진입 시기, 강도, 역이가詳細히 표시되어 있다. 음악가들은 이 악보를 따라 연주하여 통일된 음악을 만들어낸다. 테스트 절차/스크립트도 마찬가지로, 각 단계의 지침을 따라 테스트를実行하면统一된 결과를 얻을 수 있다. 또한 MIDI 파일(스크립트)이 악보보다 더自動化하기 쉬운 것처럼, 자동화된 테스트 스크립트는手動テスト 절차보다 효율적으로 반복 실행할 수 있다.
참고
- 모든 약어는 반드시 전체 명칭과 함께 표기:
API (Application Programming Interface) - 일어/중국어 절대 사용 금지 (한국어만 사용)
- 각 섹션 끝에 📢 요약 비유 반드시 추가
- ASCII 다이어그램의 세로선 │와 가로선 ─ 정렬 완벽하게
- 한 파일당 최소 800자 이상의 실질 내용