문성준의 단단해지기

테스팅과 디버깅의 차이는 무엇일까?

다른 활동이지만 서로 의존하는 관계라고도 볼 수 있다.

 테스팅 : 결함을 발견하기 위한 활동

-테스트는 공정상의 결함을 발견할 수 있다.

-시스템이 정지되는 결함과 정지가 되지 않는 결함이 모두 포함된다.

 

 디버깅 : 결함의 원인을 찾고, 코드를 수정하는 개발활동

-디버깅 후 테스터에 의해 확인 테스팅을 수행하여 결함이 제대로 고쳐졌는지 확인이 필요하다.

"결국 테스팅과 디버깅을 반복해야 최종적으로 결함을 수정 및 해결 할 수 있다고 생각된다."

테스팅의 필요성과 품질에 관한 이야기를 저번에 했는데

테스트 품질관련 이야기를하면서 소프트웨어의 요구사항 (기능적, 비기능적) 에 대해서 다음에 포스팅 한다고 했다.

개인공부를 하던 중 기능적, 비기능적 뿐만아니라 도메인 요구사항도 있길래 몇글자 적어보려 한다.

기본적으로 소프트웨어 요구사항과 특성에는 뭐가 있을까?

총 5가지 이다. 사용성, 효율성, 신뢰성, 이식성 , 유지보수성 이다.

사용자가 소프트웨어를 얼마나 쉽게 사용할수 있는지 또 소프트웨어의 효율은 어떠한지, 특정 기능에 대해 실패 확률은 얼

마인지, 이 소프트웨어가 다양한 환경에서도 동작하는지, 이 소프트웨어를 얼마나 오래 쓸건지에 대해 특성을 정리해 보았

다.

<<소프트웨어 요구사항과 특성>>

 

1.     사용성(usability)- 사용자가 소프트웨어를 어떻게 쉽게 사용할 수 있을지가 기술되는 요구 사항

 

2.     효율성(efficiency)- 소프트웨어는 빠를수록, 메모리를 적게 사용할수록 좋다. 이에 대한 제약 사항을 정의

 

3.     신뢰성(reliability) –특정한 기능을 실행할 때 실패할 가능성

 

4.     이식성(portability)- 소프트웨어가 다양한 플랫폼에서 작동

 

5.     유지 보수성(maintainability)- 소프트웨어의 수정, 개선을 용이하게 하는 능력

소프트웨어 시스템의 요구사항은 크게 기능적(functional), 비기능적(non-functional) 또는 도메인 (domain) 요구사항으로 분류될 수 있다.

      << 기능적 요구사항(Functional requirements)>>

 

- 시스템이 제공하는 기능 또는 서비스에 대한 기술

 

- 기능적 사용자 요구사항은 시스템 동작사항에 대한 추상적 기술이지만, 기능적 시스템 요구사항은 시스템 서비스에 대한 상세한 

기술이어야한다.

 

- 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술

 

- 특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술 ( 시스템이 하지 말아야할 것 에 대해 기술하는 경우도 있음)

 

- 소프트웨어 종류, 예상되는 사용자, 소프트웨어가 사용되는 시스템의 종류에 좌우

   <<비기능적 요구사항 (Non-functional requirements)>>

 

-       시스템 속성이나 시스템에 의해 제공되는 서비스나 기능에 대한 제약사항에 대해 정의 한다.

 

-       신뢰도, 반응 시간, 저장소 요구사항 등 대부분 개별적 기능이 아닌 전체적 모습에 관한 요구 ( 프로세스 요구사항이 있을 수도 있다.)

   <<도메인 요구사항 ( Domain requirements)>>

 

-       응용 도메인 으로부터 생기는 요구사항으로 특정 도메인의 용어나 개념이 반영되어 시스템의 특성에 영향을 준다.

 

-       새로운 기능적 요구사항 또는 기존의 요구사항에 대한 제약사항이 되거나 특별한 계산식을 정의하는 것 등이 될 수 잇다.

 

-       도메인의 요구사항이 만족되지 않으면 시스템이 쓸모 없게 된다.

 

-       문제점 : 해당 응용 도메인의 언어로 표현되기 때문에 시스템을 개발하는 소프트웨어 공학자가 이해하기 어렵다. 도메인 전문가에게는 분명한 부분이기 때문에 생략해버린 정보를 개발자가 알 수 없다.

도메인 요구사항은 글을 작성하고 있는 나도 학교에서 배운 기억이 없는것 같다.( 내가 수업시간에 졸았나?)

정리하자면, 기능적 요구사항은 단어의 뜻대로 사용자가 원하는 기능을 말한다. 사용자는 그 기능을 시스템을 통해 제공받기를 원하며, 시스

템은 사용자에게 필요한 기능을 제공해줘야 한다.

기능적 요구사항이 소프트웨어가 제공하는 기능이라면, 비기능적 요구 사항은 수행 가능한 환경, 품질 , 제약 사항이다.

*피드백 환영 합니다* 

<<테스팅의 일반적인 원리>>

1.     테스팅은 결함이 존재함을 밝히는 활동이다. 

 – 결함이 없다는 것은 증명할 수 없다.

2.     완벽한 테스팅(Exhaustive) 은 불가능 하다. 

 – 무한 경로, 무한 입력 값, 무한 타이핑, 리스크 분석과 결정된 우선 순위에 대한 테스팅을 집중

3.     테스팅을 개발 초기에 시작한다. 

 – 개발 시작과 동시에 테스트를 계획, 전략적으로 접근, Test case 를 도출하면서 문서상의 결함 발견

4.     결함 집중(Defect Clustering) 

 – 적은 수의 모듈에서 대다수의 결함 발견 ( 결함과 장애가 집중)

5.     살충제 패러독스(Pesticide Paradox) – 동일한 테스트를 반복적으로 수행하면 버그를 찾기 힘듦, 경험 기반 기법을 통해 테스트 방법을 다양화

 – 해당 기법을 다른 모듈 또는 시각에서 재적용시켜 테스트 케이스를 업데이트하는 노력

– 탐색적 테스팅(Exploratory testing), JIT 테스팅(Just-in-time-testing)등의 경험 기반 접근법을 통해 새로운 테스트 케이스를 추가하는 것이 필요

6.     테스팅은 정황(Context)에 의존적이다. (일의 사정과 상황)

 – 효율적, 효과적 테스트 팀 조직, 독립적 테스트 환경

7.     오류 – 부재의 궤변 (Absence – of – errors fallacy)

 – 사용자 요구사항에 맞지 않는다면 결함을 찾고 수정하는 것은 무의미, 결함을 모두 발견했다고 해도 품질이 높다고 할 수 없다.

*피드백 환영입니다*