실기 - 요구사항 테스트 [문제 풀어보기]
- 테스트 : 검증과 획인을 하는 단계
- 소프트웨어 테스트의 기본 원칙
- 결합 집중 : 소수의 특정한 모듈에 집중되는 경향
- 파레토 법칙 : 80%중 20%에 결함에 집중
- 살충제 패러독스 : 반복적인 테스트만으로는 새로운 결함을 찾기 어려움
- 오류-부재의 궤변 : 오류가 없더라도 사용자의 요구사항 충족하지 안흥면, 좋다고 볼 수 없다.
- 결합 집중 : 소수의 특정한 모듈에 집중되는 경향
- 테스트 케이스
- 테스트 시나리오
- 테스트 오라클 : 참인지? 거짓인지? 판단하기 위해서 사전에 정의된 참값(True)을 비교하여 검증
- 오라클의 유형 :
- 참 오라클 : 모든 입력값에 대한 정확한 결과 / 전부
- 샘플링 오라클 : 제한된 입력값 / 몇개
- 휴리스틱 오라클 : 근사값으로 테스트(추정) / 몇개하고 추정
- 일관성 검사 오라클 : 수정시 다시 테스트로 회귀 테스트랑 비슷 / 수
- 오라클의 유형 :
- V모형
- 단위 테스트 : 개발자가 모듈을 테스트
- 소스 코드를 실생시켰는지? 안시켰는지?
- 정적 테스트 : 실행시키지 않고 소스 코드만 보는 것
- 중복 코드를 사용했는지? 변수명은 잘 준수 헀는지?
- 동적 테스트 : 실제 실행시켜서 테스트
- 화이트박스 테스트 : 개발자
- 기초 경로 검사
- V(G) = E - N +2
- 기초 경로 검사
- 블랙박스 테스트 : 사용자
- 동등분할기 : 대표값으로 테스트
- 경계값 분석 : 경계의 값 90 ~ 100 이므로 89,90,91,99,100,101으로 6개
- 원인-효과 그래프 검사 : 입력(원인)과 출력(효과)
- 오류 예측 검사 : 경험이 많은 테스터
- 비교 검사 : 여러 버전 결과가 동일한지 확인
- 상태전이 검사 : 상태 전이시 입력값을 파악
- 화이트박스 테스트 : 개발자
- 정적 테스트 : 실행시키지 않고 소스 코드만 보는 것
- 소스 코드를 실생시켰는지? 안시켰는지?
- 통합 테스트 : 인터페이스 테스트
- 점진적
- 상향식 - 드라이버 임시모듈
- 하향식 - 스텁 임시모듈
- 비점진적
- 빅뱅
- 점진적
- 시스템 테스트
- 비기능 테스트
- 기능 테스트
- 인수 테스트 : 사용자가 테스트함
- 알파 테스트 : 개발자와 사용자 같이 테스트
- 베타 테스트 : 개발자 없이 사용자만 테스트
- 단위 테스트 : 개발자가 모듈을 테스트
- 테스트 목적
- 성능
- 구조
- 회귀 : 변경된 코드가 새로운 결함을 유발하지 않는지? 확인
- 강도 : 부하를 일으키는 테스트
- 회복
- 안전
- 병행
- 스모크 테스트
- 테스트 커버리지
- 테스트를 얼마나 진행했느냐?
- 커버리지 종류
- 라인 : 한줄
- 코드 : 분기
- 구문 커버리지 : 라인이 한번씩 실행
- 조건 커러리지 : (x>3 && x <4) 하나씩 / 개별
- 결정 커버리지 : (x>3 && x <4) 둘다 / 결정
- 기능
- 소프트웨어 테스트의 기본 원칙
애플리케이션 품질 분석
- 동료 검토
- 워크스루
- 익스펙션
- 3가지의 목적 : 리택포링
문제 풀기
[테스트 기본원칙]
1. 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 일컫는 법칙
2. 사용자의 요구사항을 충족시켜주지 못한다면, 오류가 없다고 해도 품질이 높다고 볼 수 없는 소프트웨어 테스트의 원리
3. ‘동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못한다’라는 이론으로 테스트 케이스의 정기적 리뷰와 개선 및 다른 시각에서의 접근을 강조한 원리 (20년 1회 실기 기출)
[오라클]
1. 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법 (20년 4회 필기 기출)
2. 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해주는 오라클 (20년 4·5회 실기 기출)
3. 모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
4.. 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클
5. 애플리케이션 변경이 있을 때, 수행 전과 후의 결과값이 동일한지 확인하는 오라클
[V모형]
1. ( )은 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태 중 하나로 볼 수 있다. 아래 방향으로 선형적으로 내려가면서 진행되는 폭포수 모델과 달리, 이 프로세스는 코딩 단계에서 왼쪽으로 꺾여서 알파벳 V자 모양으로 진행된다.
2. 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자의 입장에서 확인하는 테스트 단계로, 알파 테스트와 베타 테스트가 있음 (20년 3회 기능사 실기 기출)
3. 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 테스트하는 단계
4. 단위테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능을 구현된 것인지를 확인하고, 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
5. 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것으로, 구조 기반 테스트와 명세 기반 테스트로 나뉘지만 주로 구조 기반 테스트를 시행하는 테스트 단계
[테스트 기법]
1. 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식
2. 소프트웨어 검사 방법 중 하나로 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법 (20년 3회 실기 기출)
3. 입력 데이터의 영역을 유사한 도메인별로 유효값/무효값을 그룹핑하여 대표값 테스트 케이스를 도출하여 테스트하는 기법
~60 구간, 60~70 구간, 70~80 구간, 80~90 구간, 90~100 구간 표에서 각 구간마다 하나씩 테이스 데이터가 주어져 테스트하는 기법 (20년 4·5회 실기 기출)
4. 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용해 입력 조건의 경계값을 테스트 케이스로 선정해 검사하는 기법 (20년 1·2회 필기 기출)
5. 블랙 박스 테스트 종류를 쓰시오.
[테스트 목적]
1. 소프트웨어가 다양한 방법으로 실패하도록 유도하고, 정상적 복귀(원복)가 적절하게 수행되는지를 검증하는 테스트
2. 불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스 코드 내의 보안적인 결함을 미리 점검하는 테스트
3. 시스템에 과다 정보량을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트
4. 사용자의 이벤트에 소프트웨어가 응답하는 시간, 특정 시간 내에 처리하는 업무량, 반응하는 속도 등을 측정하는 테스트
5. 소프트웨어의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트
6. 오류를 제거하거나 수정한 소프트웨어에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트
7. 테스트 목적에 따른 분류 중 하나로, 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력 후 결과를 비교하는 테스트
8. 다음은 테스트 커버리지에 대한 문제이다. 아래 내용에 알맞는 답을 보기에서 골라 작성하시오.
1. 테스트를 통해 프로그램의 모든 문장을 최소한 한 번씩 실행했는지를 측정
2. 프로그램 내의 모든 분기(조건문)의 각 분기를 최소한 한 번씩 실행했는지를 측정
3. 복합 조건 내의 각 개별 조건이 참과 거짓으로 평가되는 경우를 모두 테스트했는지를 측정
보기
ㄱ. 조건 ㄴ. 경로 ㄷ. 결정 ㄹ. 분기 ㅁ.함수 ㅂ. 문장 ㅅ. 루프
[통합 테스트]
1. 상위의 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈로 상향식 통합테스트에 사용되는 것
2. 모듈 및 모든 하위 컴포넌트를 대신하는 더미 모듈로 하향식 통합 테스트 수행 시 사용하는 것으로, 기존 코드를 흉내내거나 아직 개발되지 않은 코드를 임시로 대치하는 역할을 수행함
[결함 관리 프로세스]
1. 순서대로 작성하시오
2. 명세 기반 테스트의 설계 산출물로, 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력 값, 실행조건, 기대 결과로 구성된 테스트 항목의 명세서
[애플리케이션 품질 분석]
1. 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻하는 것으로, 주로 가독성을 높이고 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위 (20년 3회 필기, 실기 기출)
2. 2~3명이 진행하는 리뷰의 형태로 요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 설명을 들으면서 코드에 대한 결함을 발견하는 형태로 진행하는 검토 기법 (20년 1·2회, 3회 필기 기출)
3.검토 자료를 회의 전에 배포해서 사전에 검토를 진행한 후 짧은 시간 동안 회의를 통해 코드의 오류를 검출하고 문서화하는 기법 (20년 1·2회, 3회 필기 기출)
4. 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 기법
5. 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램 (20년 1·2회 필기 기출)
[애플리케이션 성능 개선]
1. 잘 작성되어 가독성이 높고, 단순하며, 의존성을 줄이고, 중복을 최소화하여 깔금하게 잘 정리된 코드