공부한 것 꼭꼭 씹어먹기

웹앱 프로그램 테스트 : V모델과 정적 테스트 본문

소소한 개발 지식

웹앱 프로그램 테스트 : V모델과 정적 테스트

젤라솜 2022. 11. 3. 22:43
반응형

 

웹앱 프로그램은 개발환경이 준비되고 개발 언어를 알면 개발 할 수 있습니다. 비즈니스 로직을 정확히 이해한 상태라면 기능 자체를 개발하는 것은 전체 소프트웨어 개발 과정 중 가장 쉬운 일이라고 할 수 있습니다.

문제는 개발한 프로그램의 기능이 제대로 작동하는지, 최적화가 잘되어서 만족할 만한 성능을 가지고 있는지, 보안에 취약하지는 않은지, 안정적인 운영이 가능한지, 그리고 추후 확장성이 충분한지 등등 검증해야 할 것들이 매우 많다는 것입니다.

이런 검증을 웹앱 프로그램 테스트를 통해 할 수 있습니다.

예전에는 개발이 완료된 후 출시 전에 테스트를 했지만, 요즘은 개발 단계별로 그에 맞는 테스팅 전략을 이용합니다.

마치 공장에서 공정이 하나하나 흘러갈 때마다 품질 테스트를 거쳐서 다음 단계로 나가는 것처럼 말이죠.

아무래도 프로그램 개발에 있어서 초기 단계에서 문제점을 발견하기도 쉽고, 수정하기도 쉽습니다.

 

 

 

테스트 모델링 V 모델

V 모델은 waterfall model의 확장형으로, waterfall 모델의 개발 각 단계를 대칭되는 4개의 단계로 정의하여 각 절차를 좀 더 강화한 테스팅 모델입니다. V의 왼쪽은 검증의 영역입니다. 검증은 verification인데 맞는 제품을 만들고 있는가에 대한 검증을 의미합니다. 그리고 오른쪽은 검수의 영역인데요. 검수는 validation으로 제품을 맞는 방법으로 만들고 있는가에 대한 검수를 의미합니다. 검증 영역은 기능 구현을 제대로 수행했는지에 대한 테스트가 되고, 검수 영역은 개발이 된 프로그램을 가지고 테스트를 하게 됩니다.

검증을 하기 위해서는 요구 사항이 옳은지, 디자인이 원하는 기능에 맞게 제대로 되었는지 등을 테스트하게 됩니다.  제품이 다 만들어지기 전이기 때문에 주로 문서로 체크리스트를 작성하게 됩니다. 이렇게 제품이 아닌 문서로 테스트하는 것을 static test, 즉 정적 테스트라고 합니다. 모든 개발이 다 끝나면 꼭 제출해야 하는 것들이 있죠.  많은 개발자들이 제일 힘들어하고 하기 싫어하는 것인 요구 사항 정의서, 설계 문서, 혹은 소스 코드와 같은 모든 문서 기반의 산출물들이 이 정적 테스트의 결과물이라고 할 수 있습니다. 개발 시작 전에 이런 설계 문서들이 완벽하게 준비되면 참 좋을텐데요, 많은 경우 우당탕탕 개발 완료 후 산출물을 끼워맞추는 식으로 진행이 되기도 합니다.

대표적인 정적 테스트 중 작성하기 가장 까다로운 것은 아무래도 보안검증 관련 문서인 것 같습니다. 보안검증은 개발의 전 단계에 걸쳐 작성해야 할 항목들이 있지만 많은 부분이 개발 마무리 단계에서 체크하게 되는데요. 보안 표준을 잘 준수했는지 여부를 체크함으로써 프로그램의 전체적인 안정성을 확보했는지 검증할 수 있게 됩니다.

오른쪽 검수 영역은 왼쪽 검증 영역, 즉 정적 테스트와 반대되는 동적 테스트의 영역입니다. 문서 기반이 아닌 동작이 되는 프로그램을 기반으로 테스트를 진행하게 되는데요. 단위 테스트 단계에서는 기능 구현이 잘 되는지, 즉 각 기능 구현에 대한 신뢰성을 테스트합니다. 다음 단계인 통합 테스트 단계에서는 정적 영역에서 검증한 상세 설계에 대한 부분이 유효한지 검수를 하고요. 시스템 테스트에서는 설계에 대한 검수를, 마지막 인수 테스트 단계에서는 정적 테스트의 분석에 해당하는 고객 요구 사항에 대한 만족도를 테스트 합니다.

 

 

 

소스 코드 정적 테스트

위에서 정적 테스트는 문서 같은 정적인 산출물을 대상으로 검증하는 것이라고 했습니다. 그런데 소스 코드는 어떻게 테스트를 수행하는 것일까요? 바로, 코드 리뷰입니다! 코드 리뷰도 이 정적 테스트의 일종이라고 볼 수 있습니다.

코드 리뷰는 피어 리뷰, 팀 리뷰 처럼 사람이 직접 리뷰 하는 것이 매우 일반적이죠. 일상적으로 진행하는 모든 코드 리뷰가 이러한 정적 테스트의 일환이었던 것입니다. 그런데 소스 코드를 테스트 할 때 이렇게 사람이 직접 하는 경우도 있지만 자동화 도구를 이용하는 경우도 있습니다. 자동화 도구는 코드의 복잡도를 계산하거나 버그에 대한 리포팅, 띄어쓰기, 줄 바꾸기 등 코딩 컨벤션에 맞지 않는 내용을 발견하기도 합니다. 자동화 도구를 사용하여 코드 테스트를 할 때는 패턴을 잘 정의해야 합니다. 코딩 컨벤션이 각 회사마다 다른데 자동화 툴이 이걸 다 알아서 할 수는 없으니 말이죠. 저도 이런 자동화 툴을 써보지는 않았지만 코딩 컨벤션이 스트릭하게 잘 적용되는 회사에서 쓴다면 시간을 많이 아끼고 정확도를 높여줄으로 보입니다. 

반응형
Comments