SW 테스트(Test)
- 정보처리기술사/소프트웨어공학
- 2019. 12. 26.
개발을 한참 하던 시기, 국내에 ISTQB(International Software Testing Qualification Board)라는 자격증이 들어오면서 한 때 테스터에 대해서 진심으로 고민을 했던적이 있었다. 국내에 관련 자격을 취득한 사람이 매우 전무하던 시기이다 보니 왠지 모르게 선구자가 될 수 있다는 생각과 꽤 성장을 할 수 있는 분야로 느꼈으며, 내가 테스트를 꽤 잘하기도 했었기 때문이다.
개발을 1990년부터(Basic) 시작하다보니 남들보다 당연히 개발을 잘하기도 했었고, 추리 소설을 즐겨 읽는 성격이 가미되어 어느 부분에 문제가 발생할 지 등을 남들보다 잘 예측하기도 했다. 그리고, 반년 정도 테스팅 업무를 지원하기도 했는데(스크립트 만드는 것과 테스트 도구를 개발하는 것) 이때 테스트 자동화 툴에 대한 관심이 생겨서 공부를 할까도 이쪽으로 전향을 할까 고민 했었다(당시에는 교재가 없었고, 영어로 된 원서로 공부한 기억이 난다)
약 15년이 지난 지금은 인공지능 개발자, 데이터 사이언티스트 업무를 하고 있지만, 그때는 테스트라는 학문을 제대로 파서 이쪽 관련 교수가 되는 것이 꿈인 시절도 있었다. 우리나라는 테스트에 상당히 취약하다. 만드는 것은 그 어느나라 보다 빠르지만 품질(Quality)에 대해서 신경을 쓰지 않으며, 문서화 하는 능력도 상당히 떨어진다. 옆나라 일본같은 경우 개발 관련해서는 한국보다 한 수 뒤쳐지지만 문서화는 덕후 수준으로 산출물을 체계적으로 쓰고 있으며 그러다보니 표준을 만드는 능력이나 테스트 관련된 능력은 일본이 더 뛰어나다.
아무튼 테스트의 중요성을 모르는 Git 소스 시대의 요즘 개발자들은(라떼 시전...) 테스트를 제대로 배우며 일한 개발자와 품질의 차이가 날 수 밖에 없다. 테스트의 원리를 알면 코드의 품질을 확 끌어올릴 수 있고, 하나를 만들어도 제대로 만들 수 있으니 혹시나 테스트에 관심이 없는 개발자라면 1주일정도라도 짬을 내어 테스트 원리를 한번 공부를 하면 코드도 완성도 있고, 코딩을 하는 방식도 180도 바뀔(긍정적으로) 것이다.
소프트웨어 무결성을 위한, SW 테스트의 개요
소프트웨어 테스트의 개념
- 개발된 소프트웨어의 숨겨진 결함을 발견할 목적으로 제품 관련 소프트웨어 작업 산출물의 품질을 평가하는 일련의 행위나 절차
소프트웨어 테스트의 원칙
마이어의 원칙
- 개발자가 자신의 프로그램을 테스트하지 않는 원칙
테스트 Case
- 기대되는 표준 결과 포함(테스트 오라클), 예측오류, 기대되지 않은 결함이 있다는 가정아래 Test Plan 수립
결과 Review
- 테스트 내용을 점검하여 누락된 사례도출
소프트웨어 테스트의 경제성 원리
- 추가 결함이 발견될 확률은 기 발견된 결함 수에 정비례 개발 시 노력 분포도 40:20:40 (설계 : 프로그래밍 : SW의 내재된 결함을 찾아 내는 시기가 중요)
소프트웨어 테스트의 원리
원 리 |
내 용 |
원 인 |
결함 발견
|
- 결함 제거가 아닌 결함의 발견을 목적 |
Test 본연의 역할 |
불완전성
|
- 완벽한 Test 불가능 함 - 무한 경로, 무한 입력 값, 무한 타이밍 불가능 |
자원의 한계 |
초기 집중
|
- 개발 설계 시부터 테스트 고려 - 결함의 조기 발견 및 재유입 방지 |
품질 비용 감소 |
결함 집중
|
- 결함의 80%는 20%의 특정 모듈에 집중됨 |
파레토 법칙 |
살충제 패러독스
|
- 동일한 테스트 전략, 기법을 적용 할 시 내성 |
테스트에 특화된 코딩 |
정황 의존적
|
- 테스트는 주변 환경에 영향을 받음 |
외부 요소, 심리 요소 |
오류-부재의 궤변
|
- 요구 사항을 충족시키지 못한다면, 결함을 발견하고 모두 제거하여도 좋은 테스트라 볼 수 없음 | 테스터의 수동적 자세 |
테스트 구성도 및 구성요소
테스트 구성도
- 테스트 케이스 등으로 이루어진 테스트 시나리오를 기반으로 테스트 베드에 테스트를 수행 후, 로그, 리포트 등을 결과로 얻는 구조
테스트 구성요소
과정 |
구성 요소 |
특징 및 설명 |
테스트 준비 |
Test Basis |
- 시스템 요구사항이 기록된 모든 문서 - Test Case 생성 시 사용되는 기초 자료 - 기능, 요구 사항, 제약 사항 명시를 기록 |
Test Suite |
- Test Case의 집합 , Test Case간 사전/사후 조건 연관 관계 |
|
Test Case |
- 테스트를 수행하기 위한 입력 값, 사전 조건 등을 입력하고, 예상 결과까지 기록하여 결과가 올바른지 확인 |
|
Test Script |
- 테스트에 대한 절차 명세 |
|
테스트 수행 |
Test Bed |
- 테스트를 수행하기 위해 필요한 모든 지원 요소를 포함하는 환경 - HW, 계층기, DB, 시뮬레이터 등 |
Test Target |
- 테스트 수행의 대상이 되는 컴포넌트, 시스템 |
|
Test Harness |
- 테스트 수행을 위해 필요한 Stub과 Driver로 구성된 테스트환경 - 시험을 지원하는 목적 하에 생성된 코드와 데이터 |
|
Test Driver |
- 컴포넌트나 시스템을 제어하거나 호출하는 테스트 도구 - 상향식(Bottom-Up) 테스트에서 아직 통합되지 않은 상위 컴포넌트 동작을 시뮬레이션 하는 모의 모듈 |
|
Test Stub |
- 하항식(Top-Down) 테스트에서 사용하는 모듈 - 테스트 대상과 협력 구동하는 컴포넌트가 개발되지 않은 시점에 필요한 테스트 진행을 위해 생성하는 더미(Dummy) 컴포넌트 |
|
테스트 결과 |
Test log |
- 테스트 실행에 대한 관련 세부 항목의 시간 순서에 따른 기록 |
Test Report |
- 테스트 활동과 결과를 다루는 문서 - 완료 조건에 대비하여 상응하는 테스트 항목을 평가 |
|
Incident Report |
- 테스트 중에 일어난, 조사를 요구하는 모든 이벤트 보고서 - 테스트 활동 수행 중 발생한 문제점 |
참고자료
연관자료
'정보처리기술사 > 소프트웨어공학' 카테고리의 다른 글
통합테스트(Integration Test) (0) | 2019.12.30 |
---|---|
단위 테스트(Unit Test, Component Test) (0) | 2019.12.30 |
OOP를 더욱 빛나게 해주는, AOP (0) | 2019.01.10 |
낭비요소를 제거하는 개발방법론, 린(Lean) (0) | 2019.01.05 |
비즈니스 요구에 빠른 대응의 가능한, XP(eXtreme Programming) (0) | 2019.01.02 |