[소프트웨어 테스팅] 1. 소프트웨어 테스팅

특수대학원에서 배우는 소프트웨어 테스팅 강의 내용을 정리하려고 한다.

 

프로그램을 개발하면 우리는 반드시 그 프로그램을 테스트 해봐야한다...

이유는 생략한다...(다들 알죠..?)

 

 

---

테스트 종류에 대해서 알아보자.

1. 개발 테스트(development test)

2. 배포 테스트(Release testing)

3. 사용자 테스트(User testing)

4. TDD(Test-driven development)

 

---

 

테스트 방식을 배우기에 앞서 프로그램 테스트(programing test)는 다음과 같은 특징이 있다.

1. 프로그램 사용전 결함을 확인

2. 소프트웨어를 테스트 할때, 인위적인 데이터를 사용하여 실행한다.

3. 에러, 비정상 또는 프로그램의 비기능적인 속성을 확인

4. 에러의 존재를 확인

5. verification(검증) 과 validation(검토) 과정

 verification: 명세에 부합하는 프로그램인지 확인(옳게 만들고 있는가?)                 명세에도 오류가 있을 수 있다.🙄

• inspection(static verification)
• software testing(dynamic verification)

  validation: 프로그램이 사용자가 원하는 요구사항을 충족하는지 확인(옳은 것을 만들고 있는가?)

 

---

 

그러면 program testing 의 목표는 무엇인가?

1. 소프트웨어가 요구사항에 맞게 개발되고있는지 확인하는 것
   1. custom software에서는 요구사항 마다 test를 진행함
   2. generic software에서는 모든 시스템의 특징에 test가 있음을 의미.
2. 소프트웨어의 부정확함과 바람직하지 않거나 명세에 부합하지 않은 행위로 그러한 상황을 발견하는 것

 

---

728x90

 

validation 과 defect testing에 대해서 알아보자.

validation testing의 목적은 테스트로 주어진 요구사항을 실행하는데 문제가 없는지 확인하는 것

defect testing의 목적은 결함을 찾는것이다.(시스템이 일반적으로 사용되는 상황을 반영할 필요가 없다.)

 

즉, 다시 한 번 말하자면 

validation testing은 사용자가 원하는 요구사항을 충족하는지 확인하는 것이다.

성공적인 validation testing은 시스템이 의도된 대로 작동하는지 보여주는 것이다.

defecting testing은 부정확한 행위 또는 명세에 부합하지 않는 것으로 결함을 찾는 것이다.

성공적인 defecting testing은 시스템을 부정확하게 만들어서 시스템내에 결함을 발견하게 하는 것이다.

 

validation testing

input test data -> system -> output test result (요구사항에 맞는 동작 확인)

defecting testing

inputs causing anomalous behaviour -> system -> output which reveal the presence of defects(결함의 존재 확인)

 

---

 

verification & validation의 목적은 system이 목적에 부합하다는 확신을 확립하는 것

다음 3가지에 따라서 v & v의 수준이 달라 질 수 있다.

1. software purpose
   • 해당 소프트웨어가 조직에서 얼마나 중요한지?
2. user expectations
   • 특정 소프트웨어는 사용자가 낮은 기대를 갖고 있을 수 있음.
3. marketing environment
   • 버그 하나를 해결하는 것보다는 빠르게 시장에 해당 소프트웨어를 출시하는 것이 이득 일때.

 

---

반응형

 

inspections(검사)과 testing

software inspections은 정적인 문서들을 이용하여 문제를 발견하는것 이다.(static verification)

software testing은 실행하여 프로그램의 동작을 관찰하는 것이다.(dynamic verification)

 

inspections and testing

software inspections의 특징은 다음과 같다.

1. 변칙, 결함을 발견하기위해 소스를 검사하는 사람을 포함.

2. 시스템의 실행을 요구하지 않는다. 따라서 구현 전에 사용함.

3. 시스템의 representation을 요구한다.(요구사항, 디자인, 설정 데이터, 테스트 데이터)

4. 프로그램의 error를 찾을 때 매우 효과적임.

 

software inspections의 장점

1. error간의 상호작용을 신경쓰지 않아도 된다. (테스트 중에 error는 다른 error로 인해 숨겨질 수 있기 때문, 또한 정적인 과정이기 때문)

2. 불완전한 버전의 시스템은 추가적인 비용없이 검사가 가능하다.(만약 프로그램이 불완전한 경우, 그에맞는 테스트를 개발해야함.)

3. 결함을 찾을 뿐만아니라 프로그램의 품질성을 고려할 수 있다.(표준준수, 가능성, 유지성)

 

inspections 과 testing 관계

1. inspections과 testing은 상호보완적이다.(상충관계 X)

2. V & V 과정에서 둘다 사용되어야한다.

3. inspections은 명세에 부합하는지 확인 가능하지만 고객의 요구와 부합하는지는 알 수 없다.

4. inspections은 비기능적인 특성은 알수 없다.(퍼포먼스, 사용성..)

model of the software testing process

test case = input + expected output 으로 표현 가능

 

---

testing의 단계는 다음과 같이 3단계가 있다.

1. Development testing
   • 개발자들이 개발과정에서 버그나 결함을 찾기 위해 테스트 하는 것
     1. unit testing
        • 프로그램의 유닛 또는 클래스별로 객체나 메서드를 테스트함
     2. componet testing
        • unit을 통합하여 component를 테스트함
     3. system testing
        • 시스템의 총 component를 통합하여 component간 상호작용을 테스트함
2. Release testing
   • testing 전담 팀을 꾸려서 프로그램 배포전에 테스트 하는 것
   • 시스템이 사용하기에 충분하고 확신을 주는 것이 목표
   • 시스템이 지정된 기능, 성능, 신뢰성을 제공하고 정상 사용중에 실패하면 안됨.
   • 일반적으로 블랙박스 테스트 진행
   • system testing 의 형식이다.
   • 시스템이 요구사항과 외부 사용에 충분한지 testing(validation testing)
3. user testing
   • 사용자 환경에서 테스트 하는 것(필수적으로 해야함 -> 사용자 환경과 개발 환경이 다르기 때문)
     1. Alpha testing
        • 개발자 팀과 함께 개발환경에서 사용자가 테스트 하는것
     2. Beta testing
        • 사용자 환경에서 사용자가 테스트 하여 개발자와 함께 프로그램 문제를 찾는것 
     3. Acceptance testing
        • 고객은 시스템을 테스트하여 시스템 개발자로부터 승인을 받고 고객 환경에 배포할 준비가 되었는지 여부를 결정합니다. 주로 맞춤형 시스템용에서 사용함.

 

---

 

 

TDD(Test-Driven-Development)

참고: http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/

• 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스
• 코딩을 하기전에 테스트 코드를 먼저 작성한다. 그리고 테스트 코드를 통과하기 위해 코딩을 한다.(무엇을 코딩해야 할지 명확해짐)
• 테스트 코드를 통과하기 전에는 다음 단계로 진행할 수 없다.
• 애자일 방식의 일부로 도입되었다.(계획 중심 개발 프로세스에도 사용가능) 

1. User Story 파악

2. test 코드 작성

3. test 코드를 통과하기 위한 코드 작성

-> 제일 먼저 작성되는 test가 제일 많이 실행된다.(따라서 프로그램에서 가장 중요한 기능 부터 test를 생성함)

 

TDD

 

TDD 프로세스 과정

• 필요한 기능의 갯수를 파악하는것부터 시작함.(기능은 간단한 몇줄의 코드로 구현 가능해야함)
• 기능에 대한 테스트코드를 작성하여 자동화 테스트로 구현해야함.
• 구현된 다른 모든 테스트와 함께 테스트를 실행함.(처음 테스트 코드는 기능을 구현하지 않았으므로 실패함)
• 기능을 구현하고 테스트를 다시 실행한다.

 

TDD의 장점

• Code coverage(코드 적용범위)
  • 작성된 모든 코드는 최소 1회는 테스트가 된다.
• Regression testing(회귀 테스트)
  • 회귀 테스트는 프로그램이 개발됨에 따라 점진적으로 개발
• Simplified debugging(단순 디버깅)
  • 시험에 실패 했을 때, 문제가 어디 있는지 명백하다. 새로 작성된 코드는 확인 및 수정이 필요함.
• System documentation(시스템 설명서)
  • 테스트 코드 자체는 코드가, 무엇을 해야하는지 설명하는 일종의 문서 역할.

 

Regression testing

• 회귀 테스트는 이전에 작성된 코드가 문제가 없다는 것을 시험하는 것 이다.
• 일반적으로 회귀 테스트는 비용이 많이 들지만, 자동화 테스트를 통하면 간단합니다. 모든 테스트는 변경 될 때마다 재실행 된다.
• 변경사항을 적용하기 전에 테스트를 성공적으로 실행해야 한다. 

 

---

 

내용 정리

Key Point

1. 테스트는 error의 존재를 보여줄 수 있다.(결함이 없다는 것은 증명 할 수 없다.)
2. 개발 테스트(development testing)은 개발 팀의 책임아래 있다.
3. 개발 테스트(development testing)은 개별 개체 및 메서드 구성요소 테스트를 테스트하는 유닛 테스트가 포함된다. 이 테스트는 개체 그룹과 시스템 전체를 테스트 한다.
4. 경험과 지침을 통해 다른 시스템의 결함을 발견하는데 효과적인 테스트 사례 유형을 선택하여 소프트웨어를 파손하도록 노력해야함.
5. acceptance testing은 소프트웨어가 운영환경에 배포되고 사용하기에 충분한지 여부를 결정하는 사용자 테스트 프로세스이다.
6. 가능한 테스트는 자동화되어야 한다.
7. TDD는 테스트 코드가 개발 코드보다 먼저 작성되는 개발접근 방법이다.