블랙박스 테스팅 기법

By Erica

Transcript

1. QA 블랙박스 테스팅 기법 Erica 2021.09.08 Copyright ⓒ All Right Reserved by Buzzvil
2. Copyright ⓒ All Right Reserved by Buzzvil Table of contents 1. 블랙박스 테스팅이란? 2. 테스트 데이터 결정을 위한 테스팅 기법 3. 테스트 프로시저 도출을 위한 테스팅 기법
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
4. Copyright ⓒ All Right Reserved by Buzzvil 블랙박스 테스팅이란? • 시스템이 테스트 베이시스(요구사항, 사양, 유스케이스, 사용자 스토리)에 맞게 동작하는지 확인 • 유저 관점에서 Input과 Output에 집중 (소프트웨어 내부 동작을 모른다고 가정)
5. Copyright ⓒ All Right Reserved by Buzzvil 블랙박스 테스팅의 종류 • Functional Testing • Non-functional Testing • Regression Testing 넓은 범위의 테스팅에 앞서 테스트 가능한 수준인가 판단하기 위해 Smoke 혹은 Sanity test 수행
6. Copyright ⓒ All Right Reserved by Buzzvil 블랙박스 vs. 추론적 테스팅 (Black Box vs. Explanatory) • 선설계 → 후실행 • 명세서 (유저 스토리 등) 기반 • 주로 시스템의 동작을 테스트 • 최적의 테스트 데이터를 결정하는 기법 ◦ 동등 분할, 경계값 분석, 페어와이즈, 분류 트리 • 테스트 프로시저를 도출하는 기법 ◦ 결정 테이블, 상태 전이, 유스케이스 블랙박스 (명세기반) 테스팅 • 선실행 → 문제인지 추론 → 후설계 • 테스트 시간과 시스템 문서가 부족, 테스트 전문 지식 보유, 동적 장애를 분석할 때 활용 가능 • 반복성을 확보하기 어려움, 커버리지 평가 능력 제한, 자동화에 사용할 수 없음 • 후속 작업으로 생각의 이유, 판단 근거에 대한 문서화, 명세화, 자동화할 수 있는 케이스 구분 추론적 (반응적, 경험기반) 테스팅
7. Copyright ⓒ All Right Reserved by Buzzvil 테스트 진행 단계 분석 설계 구현 실행 • 테스트 컨디션 식별 • 테스트 케이스 설계 • 테스트 데이터 식별 • 필요한 인프라 식별 • 합격/불합격 기준을 명확하게 식별 • 테스트 프로시저 개발 • 자동화 테스트 스크립트 작성 • 테스트 데이터 및 테스트 환경 준비 • 수동/자동화 테스트 • 실제 결과와 예상 결과 비교 • 이상 현상에 대한 원인 분석 • 식별한 장애 보고 • 결과 기록
8. 테스트 데이터 결정을 위한 테스팅 기법 Copyright ⓒ All Right Reserved by Buzzvil
9. Copyright ⓒ All Right Reserved by Buzzvil Case study #1 - 백신접종현황 지도 (UI 변경) • 백신접종현황 지도 색깔을 빨간색에서 파란색 계열로 변경 후, 백신접종현황률에 따라 지도 색깔이 잘 바뀌는지 확인해보고 싶다. • UI 변경사항만 있고, 빨간색일 때 잘 동작하는 기능이므로 가장 간단한 TC로 빠르게 QA를 통과시킬 순 없을까? https://m.news.naver.com/covid19/index.nhn
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] 기대 결과
11. Copyright ⓒ All Right Reserved by Buzzvil Case study #2 - 백신접종현황 지도 (로직 변경) • 백신접종현황에 대해 접종률을 %로 표시하는 로직이 변경되었다. • 로직을 변경한 이후에도 접종률에 따라 색깔이 제대로 바뀌는지 확인해야한다. https://m.news.naver.com/covid19/index.nhn
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%
13. Copyright ⓒ All Right Reserved by Buzzvil Case study #3 - 아이폰 구매 • 아이폰을 구매하는 일반적인 케이스 (재입고 알림신청, 로켓와우 무료체험 신청하기 제외)에 대해 테스트 해보자 https://bit.ly/3BCHrbh
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가지
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% 커버리지 달성은 거의 불가능 (빠른 제품 출시, 시장 경쟁력 강화, 촉박한 마감 일정 등으로 인해 개발팀과 테스트팀 모두 생산성을 극대화해야한다는 압박을 받기 때문) 결함 검출률과 테스트 커버리지를 높일수록 제품 품질이 좋아짐 → 테스트팀의 목표
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%에 가까운 테스트 커버리지 달성을 위해 복잡한 프로젝트에서 대부분의 테스트케이스는 하나의 입력값에 의존하지 않는 사실에 착안 + 모든 조합을 커버하긴 힘듦 대신 모든 조합의 일부분으로 최선의 결과를 내려고 함
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 미가입 바로구매
18. Copyright ⓒ All Right Reserved by Buzzvil Test data 처리: 페어와이즈 (Pairwise, all-pairs) https://inductive.no/pairwiser-tool/
19. Copyright ⓒ All Right Reserved by Buzzvil Test data 처리: 페어와이즈 (Pairwise, all-pairs) • 전체 조합: 1440가지 • 2-wise: 19가지 • 3-wise: 56가지
20. 테스트 프로시저 도출을 위한 테스팅 기법 Copyright ⓒ All Right Reserved by Buzzvil
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 동작 진행을 요청하는 메시지가 있다.
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
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
24. Copyright ⓒ All Right Reserved by Buzzvil Case study #5 - 쇼핑라이브 메시지 처리 https://www.figma.com/file/imENsG0DoVi9N5e5em7JAV/Live-Commerce?node-id=309%3A3063 • 브릿지 페이지 랜딩 이후 모든 유스케이스 흐름을 살펴보자 • 대체흐름을 작성할 때 Step 4 메시지 결정 테이블을 참고하자
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
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: 참여 확인 실패 메시지 표시
27. Thank you!! Copyright ⓒ All Right Reserved by Buzzvil