Upgrade to Pro — share decks privately, control downloads, hide ads and more …

블랙박스 테스팅 기법

Buzzvil
September 08, 2021

블랙박스 테스팅 기법

By Erica

Buzzvil

September 08, 2021
Tweet

More Decks by Buzzvil

Other Decks in Programming

Transcript

  1. QA
    블랙박스 테스팅 기법
    Erica
    2021.09.08
    Copyright ⓒ All Right Reserved by Buzzvil

    View Slide

  2. Copyright ⓒ All Right Reserved by Buzzvil
    Table of contents
    1. 블랙박스 테스팅이란?
    2. 테스트 데이터 결정을 위한 테스팅 기법
    3. 테스트 프로시저 도출을 위한 테스팅 기법

    View Slide

  3. Copyright ⓒ All Right Reserved by Buzzvil
    Software Verification Techniques
    ● Inspection: 요구사항, 디자인, 코드 리뷰
    ● Analysis: 정적 분석, 버그 패턴, 데이터 흐름 분석
    ● Testing
    ● Demonstration
    https://www.celerity.com/the-true-cost-of-a-software-bug

    View Slide

  4. Copyright ⓒ All Right Reserved by Buzzvil
    블랙박스 테스팅이란?
    ● 시스템이 테스트 베이시스(요구사항, 사양, 유스케이스, 사용자 스토리)에 맞게 동작하는지 확인
    ● 유저 관점에서 Input과 Output에 집중 (소프트웨어 내부 동작을 모른다고 가정)

    View Slide

  5. Copyright ⓒ All Right Reserved by Buzzvil
    블랙박스 테스팅의 종류
    ● Functional Testing
    ● Non-functional Testing
    ● Regression Testing
    넓은 범위의 테스팅에 앞서 테스트 가능한 수준인가 판단하기 위해 Smoke 혹은 Sanity test 수행

    View Slide

  6. Copyright ⓒ All Right Reserved by Buzzvil
    블랙박스 vs. 추론적 테스팅 (Black Box vs. Explanatory)
    ● 선설계 → 후실행
    ● 명세서 (유저 스토리 등) 기반
    ● 주로 시스템의 동작을 테스트
    ● 최적의 테스트 데이터를 결정하는 기법
    ○ 동등 분할, 경계값 분석, 페어와이즈, 분류 트리
    ● 테스트 프로시저를 도출하는 기법
    ○ 결정 테이블, 상태 전이, 유스케이스
    블랙박스 (명세기반) 테스팅
    ● 선실행 → 문제인지 추론 → 후설계
    ● 테스트 시간과 시스템 문서가 부족, 테스트 전문 지식
    보유, 동적 장애를 분석할 때 활용 가능
    ● 반복성을 확보하기 어려움, 커버리지 평가 능력 제한,
    자동화에 사용할 수 없음
    ● 후속 작업으로 생각의 이유, 판단 근거에 대한 문서화,
    명세화, 자동화할 수 있는 케이스 구분
    추론적 (반응적, 경험기반) 테스팅

    View Slide

  7. Copyright ⓒ All Right Reserved by Buzzvil
    테스트 진행 단계
    분석 설계 구현 실행
    ● 테스트 컨디션 식별 ● 테스트 케이스 설계
    ● 테스트 데이터 식별
    ● 필요한 인프라 식별
    ● 합격/불합격 기준을
    명확하게 식별
    ● 테스트 프로시저 개발
    ● 자동화 테스트
    스크립트 작성
    ● 테스트 데이터 및
    테스트 환경 준비
    ● 수동/자동화 테스트
    ● 실제 결과와 예상 결과 비교
    ● 이상 현상에 대한 원인 분석
    ● 식별한 장애 보고
    ● 결과 기록

    View Slide

  8. 테스트 데이터 결정을 위한 테스팅 기법
    Copyright ⓒ All Right Reserved by Buzzvil

    View Slide

  9. Copyright ⓒ All Right Reserved by Buzzvil
    Case study #1 - 백신접종현황 지도 (UI 변경)
    ● 백신접종현황 지도 색깔을 빨간색에서 파란색
    계열로 변경 후, 백신접종현황률에 따라 지도
    색깔이 잘 바뀌는지 확인해보고 싶다.
    ● UI 변경사항만 있고, 빨간색일 때 잘 동작하는
    기능이므로 가장 간단한 TC로 빠르게 QA를
    통과시킬 순 없을까?
    https://m.news.naver.com/covid19/index.nhn

    View Slide

  10. Copyright ⓒ All Right Reserved by Buzzvil
    Test data 처리: 동등 분할 (Equivalence Partitioning)
    ● 테스트 데이터 셋에서 동등 파티션을
    식별하고 파티션에서 하나의 대푯값
    선택
    ● 테스트 데이터 셋의 모든 값이 서로
    상호 작용하지 않는 경우에 적합
    ● 경계값 분석과 함께 사용시 효과적
    60%
    30%
    테스트
    케이스
    1 2 3
    입력값 25 70 80
    테스트 영역 [0, 30] (30, 60] (60, 100]
    기대 결과

    View Slide

  11. Copyright ⓒ All Right Reserved by Buzzvil
    Case study #2 - 백신접종현황 지도 (로직 변경)
    ● 백신접종현황에 대해 접종률을 %로 표시하는
    로직이 변경되었다.
    ● 로직을 변경한 이후에도 접종률에 따라 색깔이
    제대로 바뀌는지 확인해야한다.
    https://m.news.naver.com/covid19/index.nhn

    View Slide

  12. Copyright ⓒ All Right Reserved by Buzzvil
    Test data 처리: 경계값 분석 (Boundary Analysis)
    ● 동등 분할 경계에 존재하는 값의
    적절한 처리를 테스트하는 기법
    60%
    30%
    테스트
    케이스
    1 2 3 4
    입력값 30 30.01 60 60.01
    기대 결과
    30.01% 60.01%

    View Slide

  13. Copyright ⓒ All Right Reserved by Buzzvil
    Case study #3 - 아이폰 구매
    ● 아이폰을 구매하는 일반적인 케이스 (재입고
    알림신청, 로켓와우 무료체험 신청하기 제외)에
    대해 테스트 해보자
    https://bit.ly/3BCHrbh

    View Slide

  14. Copyright ⓒ All Right Reserved by Buzzvil
    Case study #3 - 아이폰 구매시 가능한 테스트 경로
    ● 저장용량: 64GB or 128GB or 256GB → 3가지
    ● 색상: 레드 or 그린 or 블랙 or 블루 or 퍼플 or 화이트 → 6가지
    ● 애플케어: 가입 or 미가입 → 2가지
    ● 로켓와우: 쿠팡판매가 or 로켓와우회원가 → 2가지
    ● 구매개수: 1대 or 2대 → 2가지
    ● 구매유형: 장바구니 담기 or 바로구매 → 2가지
    ● 총 경우의 수: 3 x 6 x 2 x 2 x 2 x 2 = 288가지

    View Slide

  15. Copyright ⓒ All Right Reserved by Buzzvil
    경우의 수가 많을 때 테스트를 어떻게 진행해야 효과적일까?
    The primary responsibility of the test lead or the test analyst is to come up with ‘Test case design & Planning’ in
    order to attain maximum test coverage. As it is nearly impossible to achieve 100% test coverage (unless and until
    your product has very simple requirements & implementation), the test team should come up with test cases/test
    suites that can help in testing the core functionalities of the product, thereby achieving the best coverage results.
    Along with test coverage, another Key Performance Indicator (KPI) that is critical as far as software testing is
    concerned is ‘Defect Yield Rate’. Higher the test coverage and defect yield rate, better the quality of the product.
    Some things are easier said than done and the same can be said about ‘Website Testing’. Due to factors like
    reduced Time To Market, growing business competition, tight deadlines, and other varying factors; the
    development and test teams are always under intense pressure to maximize their productivity (thereby improving
    the Return on Investment [ROI]). For the development team, the criteria could be LOC (Lines of Code) pushed to
    the project/product repository; for the test team, the criteria could be number of tests executed/bugs
    raised/number of tests developed.
    https://www.lambdatest.com/blog/leveraging-pairwise-test-technique-for-cross-browser-testing/
    테스트케이스 계획과 설계 목표: 최고 수준의 테스트 커버리지 달성
    하지만 간단한 제품이 아니라면 100% 커버리지 달성은 거의 불가능
    (빠른 제품 출시, 시장 경쟁력 강화, 촉박한 마감 일정 등으로 인해
    개발팀과 테스트팀 모두 생산성을 극대화해야한다는 압박을 받기 때문)
    결함 검출률과 테스트 커버리지를 높일수록 제품 품질이 좋아짐 → 테스트팀의 목표

    View Slide

  16. Copyright ⓒ All Right Reserved by Buzzvil
    Pairwise Testing, also called as all-pairs testing is a black-box test design technique that can deliver nearly 100% test
    coverage. As per the ISTQB (International Software Testing Qualifications Board), the official definition of Pairwise
    Testing is as mentioned below
    “Pairwise Testing is a black box test design technique in which test cases are designed to
    execute all possible discrete combinations of each pair of input parameters.”
    In a complex project, the output for majority of the test cases may not depend on one single parameter. There could be
    multiple factors like state transitions/state machines, input parameters, shared parameters, variable factors like
    accessible memory/user preferences, etc. depending on the type & domain of the project.
    Though you may come up with the possible values for these variable factors, come up with test cases/test suites that
    can cover all the combinations can be a herculean task. Hence, it becomes critical to come up with a ‘subset of
    combinations’ which when inputted to the test cases result in achieving the best results i.e. maximum test coverage
    https://www.lambdatest.com/blog/leveraging-pairwise-test-technique-for-cross-browser-testing/
    Test data 처리: 페어와이즈 (Pairwise, all-pairs)
    Pairwise testing의 등장: 100%에 가까운 테스트 커버리지 달성을 위해
    복잡한 프로젝트에서 대부분의 테스트케이스는
    하나의 입력값에 의존하지 않는 사실에 착안 + 모든 조합을 커버하긴 힘듦
    대신 모든 조합의 일부분으로 최선의 결과를 내려고 함

    View Slide

  17. Copyright ⓒ All Right Reserved by Buzzvil
    Test data 처리: 페어와이즈 (Pairwise, all-pairs)
    ● 파라미터-값 모든 쌍의 조합을
    테스트하는 대신 서로 다른 두 개의
    파라미터에 대한 파라미터-값의 모든
    쌍을 테스트
    ● 대부분의 결함은 페어와이즈로 검출이
    가능하고, 전체 조합이 페어와이즈보다
    결함 검출률을 크게 높이지 않는다는
    사실에 기반
    ● 저장용량: 64GB or 128GB or 256GB → 3가지
    ● 애플케어: 가입 or 미가입 → 2가지
    ● 구매유형: 장바구니 담기 or 바로구매 → 2가지
    ● 총 경우의 수: 3 * 2 * 2 = 12가지
    ● 모든 쌍에 대한 경우의 수: 4 * 3 + 2* 2 = 16가지
    64GB,
    가입
    128GB,
    가입
    256GB,
    가입
    가입,
    장바구니
    64GB,
    미가입
    128GB,
    미가입
    256GB,
    미가입
    가입,
    바로구매
    64GB,
    장바구니
    128GB,
    장바구니
    256GB,
    장바구니
    미가입,
    장바구니
    64GB,
    바로구매
    128GB,
    바로구매
    256GB,
    바로구매
    미가입,
    바로구매
    저장용량 애플케어 구매유형
    1 64GB 가입 장바구니
    2 64GB 미가입 바로구매
    3 128GB 가입 바로구매
    4 128GB 미가입 장바구니
    5 256GB 가입 장바구니
    6 256GB 미가입 바로구매

    View Slide

  18. Copyright ⓒ All Right Reserved by Buzzvil
    Test data 처리: 페어와이즈 (Pairwise, all-pairs)
    https://inductive.no/pairwiser-tool/

    View Slide

  19. Copyright ⓒ All Right Reserved by Buzzvil
    Test data 처리: 페어와이즈 (Pairwise, all-pairs)
    ● 전체 조합: 1440가지
    ● 2-wise: 19가지
    ● 3-wise: 56가지

    View Slide

  20. 테스트 프로시저 도출을 위한 테스팅 기법
    Copyright ⓒ All Right Reserved by Buzzvil

    View Slide

  21. Copyright ⓒ All Right Reserved by Buzzvil
    Case study #4 - 쇼핑라이브 메시지 처리
    https://www.figma.com/file/imENsG0DoVi9N5e5em7JAV/Live-Commerce?node-id=309%3A3063
    ● Step 4: 적립 신청하기 버튼을 눌렀을 때
    나오는 메시지를 확인해보자.
    ● Step 1과 Step 3 진행 이후에 Step 4가
    진행되어야 한다.
    ● 메시지 타입에는 적립 신청 완료 메시지,
    참여 확인 실패 메시지, Step 1이나 Step
    3 동작 진행을 요청하는 메시지가 있다.

    View Slide

  22. Copyright ⓒ All Right Reserved by Buzzvil
    Test procedure 결정: 결정 테이블 (Decision Table)
    ● 조건과 조건에 따른 동작을 표현한 표
    ● 비즈니스 규칙을 분석해서 TC 설계
    조건 1 2 3 4 5 6 7 8
    광고주 방송 알림 스크린샷 Y Y Y - N N N Y
    Step 1 진행 Y Y N N Y Y N Y
    Step 3 진행 Y N Y N Y N Y Y
    적립 요청 성공 후 Step 4 진행 - - - - - - - Y
    동작
    적립 확인 성공 메시지 Y - - - N - - Y
    적립 확인 실패 메시지 N - - - Y - - N
    동작 확인 요청 메시지 - Y Y Y - Y Y Y

    View Slide

  23. Copyright ⓒ All Right Reserved by Buzzvil
    Test procedure 결정: 결정 테이블 (Decision Table)
    조건 1 2 3 4 5 6 7 8
    광고주 방송 알림 스크린샷 Y Y Y - N N N Y
    Step 1 진행 Y Y N N Y Y N Y
    Step 3 진행 Y N Y N Y N Y Y
    적립 요청 성공 후 Step 4 진행 - - - - - - - Y
    동작
    적립 확인 성공 메시지 Y - - - N - - Y
    적립 확인 실패 메시지 N - - - Y - - N
    동작 확인 요청 메시지 - Y Y Y - Y Y Y
    조건 1 2 3 4 5 6
    광고주 방송 알림 스크린샷 Y - - - N Y
    Step 1 진행 Y Y N N Y Y
    Step 3 진행 Y N Y N Y Y
    적립 요청 성공 후 Step 4 진행 - - - - - Y
    동작
    적립 확인 성공 메시지 Y - - - N Y
    적립 확인 실패 메시지 N - - - Y N
    동작 확인 요청 메시지 - Y Y Y - Y

    View Slide

  24. Copyright ⓒ All Right Reserved by Buzzvil
    Case study #5 - 쇼핑라이브 메시지 처리
    https://www.figma.com/file/imENsG0DoVi9N5e5em7JAV/Live-Commerce?node-id=309%3A3063
    ● 브릿지 페이지 랜딩 이후 모든 유스케이스
    흐름을 살펴보자
    ● 대체흐름을 작성할 때 Step 4 메시지 결정
    테이블을 참고하자

    View Slide

  25. Copyright ⓒ All Right Reserved by Buzzvil
    Test procedure 결정: 유스케이스 (Usecase)
    ● 액터와 컴포넌트 또는 시스템 간의
    상호작용 정의
    https://www.zyxware.com/articles/3761/basic-structure-of-an-use-case-template-for-software-testing

    View Slide

  26. Copyright ⓒ All Right Reserved by Buzzvil
    Test procedure 결정: 유스케이스 (Usecase)
    기본흐름 단계 기술
    A: Actor
    S: System
    1 A: ‘라이브 알림 받기’ 버튼 누르기
    2 S: 쇼핑 라이브 랜딩 URL로 랜딩
    3 S: 알림 설정 팝업 표시 (네/아니오)
    4 A: ‘네’ 버튼 누르기
    5 S: 알림 설정 완료 팝업 표시
    6 A: 알림 설정 완료 팝업 화면을
    스크린샷으로 저장
    7 A: 브라우저 뒤로가기로 브릿지
    페이지로 이동하기
    8 A: ‘사진 선택’ 버튼 누르기
    9 S: 사진 보관함 띄우기
    10 A: 광고주의 스크린샷 등록
    11 S: 등록된 스크린샷 파일명 표시
    기본흐름 단계 기술
    12 A: ‘적립 신청하기’ 버튼 누르기
    13 S: 참여 확인중 로딩 메시지 표시
    14 S: 참여 확인 완료 메시지 표시
    15 A: ‘네’ 버튼 누르기
    16 S: 알림 설정 완료 팝업 표시
    대체흐름 1 3a 네이버에 로그인 되어 있지 않은 경우
    S: 네이버 로그인 화면 표시
    대체흐름 2 4a - 1 사용자가 아니오를 선택하는 경우
    A: ‘아니오’ 버튼 누르기
    4a - 2 S: 쇼핑 라이브 메인 화면 표시
    대체흐름 3 10a 사용자가 10MB가 넘는 이미지를 등록한
    경우
    S: 10MB 미만 이미지 등록 요청 메시지
    표시
    기본흐름 단계 기술
    대체흐름 4 12a Step 1을 진행하지 않은 경우
    S: Step 1 진행 요청 메시지 표시
    12b Step 3를 진행하지 않은 경우
    S: Step 3 진행 요청 메시지 표시
    대체흐름 5 14a 광고주 캠페인 스크린샷이 아닌 경우
    S: 참여 확인 실패 메시지 표시

    View Slide

  27. Thank you!!
    Copyright ⓒ All Right Reserved by Buzzvil

    View Slide