[IT] 직무분석-지식 제로부터 배우는 소프트웨어 테스트

2021-01-05

SW QA 직무분석

지식 제로부터 배우는 소프트웨어 테스트 - 타카하시 쥬이치

 

• 소프트웨어 테스트에서 중요한 것은 어느 부분에서 버그가 많은지, 그 곳에 어떤 테스트 방법을 적용하면 충분한 품질을 얻을 수 있는지를 아는 것이다. 

테스트 종류

• 화이트 박스 테스트: 프로그램의 논리 구조가 올바른지를 분석하는 테스트, 논리 구조의 올바름을 테스트하므로 소프트웨어의 사양이 틀려 발생하는 버그는 발견할 수 없음. 
• 제어 흐름 테스트: 프로그램이 어떻게 움직이며 어떻게 제어되어 실행되는 가를 테스트 
  제어 흐름 테스트에 따른 코드 커버리지 테스트의 본질은 흐름도를 제대로 지키는 것 
  * 코드 커버리지(Code Coverage)는 소프트웨어의 테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표
• 테스트 담당자가 코드를 보고 분석하는 것이 어려울 때에는 개발자에게 커버리지 결과를 보여주고 의견을 구할
• 테스트는 정해진 시간에 수행해야 하는 최대공약수, 테스트는 시간이 부족하다는 이유로 일부 기능을 테스트하지 않을 수 없음
• TDD - 테스트 주도 개발 
  TDD의 기본은 적색, 녹색, 리팩터 
• 개발자들이 단위 테스트를 하지 않으려고 할 때 
  -> Kent Beck이 추천하는 TDD를 해보도록 하죠 라고 말할 것 
  
  
• 애자일 - 짧은 사이클로 코딩 테스트를 수행하므로 변경이 생겨도 문제가 없다 
  
  
• 블랙박스 테스트 - 프로그램을 일종의 블랙박스로 보고 다양한 입력을 실행함으로써 소스 코드를 이용하지 않고(보지 않고) 테스트를 수행하는 방법 
  
  1) 등가 분할법: 등가 클래스라는 부분 집합으로 분할하고 그 부분 집합에서 선택한 입력값을 모두 같은 값으로 보는 작업 
  2) 경계값 분석: 경계의 어느 값을 테스트할 것인가를 생각할 때는 ON-OFF 포인트법 사용 
  
  
• 상태전이테스트 - 테스트 아이템의 상태 모델 사용, 상태 간의 전이, 이벤트 등을 테스트, 유효(Valid) 테스트 케이스, 비 유효(Invalid)테스트 케이스 
  
  -> 일일이 테스트 케이스를 작성하기보다는 제품을 학습한 다음 테스트를 설계하고 실행하면서 버그 보고를 병행하는 것이 손쉬울 것
  
  -> 테스트 케이스를 일일이 사전에 작성하는 것보다 소프트웨어를 테스트하면서 생각하여 시행하는 것이 더 나음 
  
  
• 탐색적 테스트의 테스크 실행 
  1. 대상 소프트웨어를 정함 
  2. 기능을 목록화함 - 모든 온라인 도움말 확인, 모든 메뉴 확인, 예제 데이터의 사용성 확인 등 
  3. 약한 부분을 발견 - 위험해 보이는 기능이나 조작을 목록화 
  4. 각 기능을 테스트하고 버그 기록 - 테스트를 시행하면서 테스트 케이스를 작성하는 데는 시간이 걸리게 되므로 상대적으로 테스트 자체에 드는 시간은 줄어들기 떄문
  5. 계속적인 테스트 실행 

테스트 기간이 계획 떄보다 짧아졌을 때 테스트 관리자가 취할 수 있는 선택지

• 소프트웨어 품질을 낮춘다
• 출하를 늦춘다
• 기능을 줄인다 

테스트 종료 기준

• 중요도가 높음의 버그가 남아 있지 않을 것
• 모든 테스트 케이스의 98%를 통과했을 것 
• 48시간 이내에 중요도 높음의 버그가 발견되지 않을 것 

테스트 케이스 작성 예 

테스트 케이스 ID: 제품이슈 #00000

제목: 반디집에서 서버 DD의 파일을 압축할 때, 더블 클릭 시 파일 조회 설정에 따라 파업창이 뜨는 이슈

오류상황: 웹에서 서버 DD 파일 다운로드 시 해당 문서가 서버에서 삭제되었습니다 라고 뜨는 이슈

 

오류내용

1. 웹에서 서버 DD로 파일 다운로드 했으나 해당 문서가 서버에서 삭제되었습니다 라는 팝업창이 뜸 

2. 미저장 문서 목록 확인 

3. 등록 선택 시 삭제 메세지 알림창 팝업

4. 열기 선택 시 파일 정상 오픈되어 서버 DD/보안 DD에 저장 시도 

5. 정상 저장되나 삭제 메세지 알림창 팝업

 

테스트 케이스는 언제, 누가 해도 똑같은 결과를 얻을 수 있도록 작성 

 

테스트 담당자가 프로젝트 초기 단계에 참가하는 것이 좋음 

-> 어떤 언어로 개발되었는가에 따라 다른 테스트 방법 사용 가능 

 

출하 전날 버그를 발견했을 때의 대처 

- 출하 기준을 만들 것 

• 남은 버그 수가 총 건수의 0.5% 이내 
• 테스트 케이스 성공률 99%
• 장기간 사용 테스트에서 시스템 멈춤이 한번도 없음 -> 수정은 단념하는 것이 좋음 

사이클로매틱 수: 프로그램의 제어 흐름을 유형 그래프로 표현하여 그 그래프가 가진 성질을 기초로 프로그램의 복잡성을 나타내는 방법 

 

테스트 자동화가 성공하려면 자동화 코드의 유지보수 비용을 낮게 유지

 

테스트만 하는 사람은 도태 -> 상위 공정에서 테스트 코드를 작성하면서 테스트를 해야 함 

 

테스트 케이스를 일일이 사전에 작성하는 것보다 소프트웨어를 테스트하면서 생각하여 시행하는 것이 더 낫다