[소프트웨어공학] 12장. 테스팅

12장. 테스팅

SW testing : 테스트는 최종 사용자에게 전달하기 전에 오류를 발견할 목적으로 프로그램을 연습하는 과정이다.

테스트를 통해 얻을 수 있는 것

• Errors (논리적 오류)
• Requirements conformance (요구사항 일치 여부)
• Performance (성능)
• Indication of quality (품질 수준)

누가 테스트해야 할까?

1. Developer
   1. 시스템을 이해하고 있음
   2. 조심스럽게 테스트하고
   3. 전달을 이끌어냄
   4. “구성 작업”
2. Independent Tester
   1. 시스템에 대해 배워야 함
   2. 고장내려고 시도함
   3. 품질을 이끌어냄
   4. “파괴적인 일”

전략적 접근

• 테스트는 사전에 계획하고 체계적으로 수행할 수 있는 일련의 활동입니다.
• 특성
  • 효과적인 기술 검토 수행
  • 구성 요소 수준에서 시작하여 "외부"로 작동합니다.
  • 다양한 시점에서의 다양한 테스트 기법
  • 개발자 및 독립 테스트 그룹에 의해 수행
  • 디버깅을 수용해야 합니다.

V&V: Verification & Validation (검증 및 유효성 검사)

• Verification - 확인: 소프트웨어가 특정 기능을 올바르게 구현하도록 보장하는 일련의 태스크를 말합니다.
• Validation - 검증: 구축된 소프트웨어가 고객의 요구사항을 추적할 수 있도록 보장하는 다양한 작업 세트를 말합니다.
• V&V는 아래 SQA를 포함한다.
  • Verification : “우리가 제품을 알맞은 방법으로 짓고 있나?” - 논리적 검증
  • Validation : “우리가 알맞은 제품을 짓고 있나?” - 유효성 검증

 💡 테스팅 전략

1. 단위시험(Unit test) : code : 각 단위에 집중
2. 통합시험(Integration test) : design : 설계와 SW아키텍처에 집중
3. 검증시험(Validation test) : requirements : 요구사항 확인
4. 시스템시험(System test) : system engineering : SW와 기타 시스템 요소를 전체적으로 시험

우리는 '작은 것에서 시험'으로 시작하여 '큰 것에서 시험'으로 나아간다.

• 기존 소프트웨어의 경우
• 모듈(구성 요소)이 초기 초점입니다.
• 모듈 통합은 다음과 같습니다.
• 객체지향 SW의 경우
  • 개별 모듈(일반적인 관점)에서 특성과 운영을 포괄하고 커뮤니케이션과 협업을 암시하는 OOO 클래스로 "소규모 테스트"가 변경될 때 초점을 맞춥니다.

 

테스팅 전략 요령

• 테스트가 시작되기 훨씬 전에 정량화 가능한 방식으로 제품 요구사항을 지정하십시오.
• 테스트 목표를 명시적으로 설명합니다.
• 소프트웨어 사용자를 이해하고 각 사용자 범주에 대한 프로파일을 개발합니다.
• "신속한 주기 테스트"를 강조하는 테스트 계획을 수립합니다.
• 자체 테스트를 위해 설계된 "강력한" 소프트웨어 구축
• 테스트 전에 효과적인 공식 기술 검토를 필터로 사용
• 공식적인 기술 검토를 수행하여 테스트 전략과 테스트 사례를 평가합니다.
• 테스트 프로세스에 대한 지속적인 개선 접근 방식 개발

Unit Testing → SW 최소 단위의 초점 검증 (using test cases - 인터페이스, 로컬데이터 구조, 경계 조건, 독립 path, 예외처리)

 

 💡 Driver vs Stub

• 드라이버 : 테스트 케이스 데이터를 받아 테스트할 구성 요소에 전달하고 관련 결과를 출력하는 상위 메인모듈의 역할.
• 스텁 : 테스트할 구성 요소에서 호출한 하위 모듈을 대체하는 임시 모듈
  • 최소한의 데이터 조작과 입출력 검증, 테스트 중인 모듈에 대한 제어 권한 반환 등을 수행한다.

 

통합 테스트 전략

• 옵션:
  • "빅뱅" 전략
  • 점진적 건설 전략

알파 테스트 : 특정 사용자들에 의해 개발자의 입장에서 테스트

베타 테스트 : 여러 사용자들이 자신의 사용환경에서 테스트

 

 

Top-down vs Bottom-up

 

• 탑 다운 : 테스트가 쉽지 않지만 스텁을 사용하여 주 제어 기능을 조기에 테스트할 수 있다. vs
• 바텀 업 : 엔티티로서의 프로그램은 마지막 모듈이 추가될 때까지 존재하지 않지만 테스트 케이스 설계가 더 쉽고 스텁이 없습니다.
• 샌드위치 테스팅 : middle-out 테스팅으로 탑다운과 바텀업을 합친 것

OOT 전략

• 클래스 시험은 단위 시험과 동등하다.
  • 클래스 내 작업이 테스트됩니다.
  • 클래스의 상태 행동이 조사된다.
• 통합은 세 가지 다른 전략을 적용했다.
  • 스레드 기반 테스트—하나의 입력 또는 이벤트에 응답하는 데 필요한 클래스 집합을 통합
  • 사용 기반 테스트—하나의 사용 사례에 대응하는 데 필요한 일련의 클래스 통합
  • 클러스터 테스트—하나의 협업을 시연하는 데 필요한 일련의 클래스를 통합

 

High Order Testing (고차 테스트)

• 유효성 검사
  • 소프트웨어 요구사항에 초점을 맞춘다.
• 시스템 테스트
  • 시스템 통합에 초점을 맞춥니다.
• 알파/베타 테스트
  • 고객 사용에 초점을 맞춥니다.
• 복구 테스트
  • 소프트웨어가 다양한 방식으로 장애를 일으키도록 강제하고 복구가 적절하게 수행되는지 확인합니다.
• 보안 테스트
  • 시스템에 내장된 보호 메커니즘이 실제로 부적절한 침투로부터 시스템을 보호할 것임을 확인한다.
• 스트레스 테스트
  • 비정상적인 양, 빈도 또는 부피의 자원을 요구하는 방식으로 시스템을 실행한다.
• 성능 테스트
  • 통합 시스템의 맥락에서 소프트웨어의 런타임 성능을 테스트합니다.

디버깅 : A Diagnostic process(진단 프로세스)

• 성공적인 테스트의 결과로 발생.
• 증상(symptom)과 원인(cause)을 연결하는 정신적 과정이 제대로 이해되지 않음

 

Debugging Techniques

• brute force testing : 무력 시험
• back-tracking : 역추적
• cause elimination : 원인 제거

💡 무차별 대입 디버깅

이것은 개념적으로 가장 단순한 방법이며 종종 가장 덜 성공적 이다. 여기에는 개발자가 오류의 흔적을 찾기 위해 스택 추적, 메모리 덤프, 로그 파일 등을 수동으로 검색하는 작업이 포함됩니다. 소프트웨어가 모든 단계에서 무엇을 하는지 검사하기 위해 중단점 외에 추가 출력 문이 코드에 추가되는 경우가 많다.

 

💡 역추적

이 방법은 개발자가 즉시 관찰 가능한 오류를 생성하는 코드로 시작하도록 한다. 개발자가 실행 경로를 역추적하여 원인을 찾습니다. 불행하게도, 소프트웨어에서 주어진 지점으로 이어지는 실행 경로의 수는 버그의 원인이 오류가 발생하는 곳에서 멀어질수록 상당히 커질 수 있으며, 따라서 이 방법은 비실용적이 될 수 있다.

 

💡 원인제거

이 방법에서 개발자는 버그가 발생한 이유에 대한 가설을 개발합니다. 코드는 버그를 직접 검사하거나 가설을 테스트하기 위한 데이터를 구성할 수 있다. 이 방법은 소프트웨어를 잘 이해하는 개발자에게 의존하지만 종종 가장 짧은 디버그 시간을 초래할 수 있다.

 

 

Correcting the errors

1. 다른 부분에서 재현된 건지?
2. 다음 버그?
3. 발생 장소에서 예방 가능한지?

Testability : 테스트 가능성

• 운영성(Operability) — "잘 작동할수록 더 효율적으로 테스트할 수 있습니다."
• 관찰 가능성(Observability) — "본 것이 테스트하는 것입니다."
• 제어성(Controllability) — "소프트웨어를 더 잘 제어할수록 테스트를 더 많이 자동화하고 최적화할 수 있습니다."
• 분해성(Decomposability) — "테스트 범위를 제어함으로써 문제를 보다 신속하게 격리하고 보다 스마트한 재테스트를 수행할 수 있습니다."
• 단순성(Simplicity) — "테스트 대상이 적을수록 더 빠르게 테스트할 수 있습니다."
• 안정성(Stability) — "변경 사항이 적을수록 테스트 중단이 줄어듭니다."
• 이해 가능성(Understandability) — "더 많은 정보를 확보할수록 더 현명하게 테스트할 수 있습니다."

💡 훌륭한 테스트란?

• 좋은 테스트는 오류를 발견할 확률이 높습니다.
• 좋은 테스트는 중복되지 않습니다.
• 좋은 테스트는 "최고의 품종"이어야 한다.
• 좋은 시험은 너무 간단하지도 너무 복잡하지도 않아야 한다

 

Test Case Design (시험 사례 설계)

• 목표: 오류 파악
• 기준: 완전한 방식으로
• 제약 조건: 최소한의 노력과 시간으로

Exhaustive Testing vs Selective Testing

White-Box Testing : sw 구조 테스트, 내부 설계 및 코드의 구조 및 영향

• Glass-box testing
  1. independent path
  2. logical decision
  3. all loop
  4. data structure

→ 화이트박스 테스트를 통해 test case 설계자는 절차 설계의 논리적 복잡성 측정을 도출하고, 이 측정을 실행 경로의 기본 세트를 설계하기 위한 지침으로 사용할 수 있다.

Basis Path Testing

Black-Box Testing : sw 기능 테스트, 외부 설계 및 동작 테스트

내부를 볼 수 없는 박스 (블랙박스)

• Behavioral testing
  1. incorrect/missing function
  2. interface errors
  3. data structure errors
  4. behavioral errors
  5. initiation/termination errors

• 기능 유효성은 어떻게 테스트됩니까?
• 시스템 동작 및 성능은 어떻게 테스트됩니까?
• 어떤 종류의 입력이 좋은 테스트 사례가 될 것인가?
• 시스템이 특정 입력 값에 특히 민감합니까?
• 데이터 클래스의 경계는 어떻게 분리됩니까?
• 시스템에서 허용할 수 있는 데이터 속도 및 데이터 볼륨은 얼마입니까?
• 특정 데이터 조합이 시스템 작동에 어떤 영향을 미칩니까?

< 동등성 분할 : Equivalence Partitioning >

→ 입력 도메인을 데이터 클래스로 나누는 블랙박스 테스트 방법.

• 유효한 값 하나, 범위 내의 유효하지 않은 값 두 개
• 유효한 멤버 하나, 유효하지 않은 멤버 하나
• 하나는 유효하고 하나는 잘못된 부울

< 경계값 분석 : Boundary Value Analysis >

→ 더 많은 오류가 "중앙"이 아닌 입력 도메인의 경계에서 발생합니다.

1. a와 b의 바로 위와 아래의 a와 b의 값
2. 최소 및 최대 수, 최소 및 최대 바로 위 및 아래
3. 출력에 1, 2 적용
4. 데이터 구조 경계