한용희 님의 글에서 발췌 합니다.
항상 테스트를 어떻게 진행해야 할까 고민을 많이 했었습니다. 툴은 가지고 있긴 한데, 이용하질 못 했네요.
한용희 님께 감사드립니다.
월간 마이크로소프트웨어 2007년 5월호
—————————————————————————————————————
비주얼
스튜디오를 이용한 테스팅
‘IT’ 한국 발목잡는 부실 SW
보험금 과다 청구에 무더기 반품 사태도 일으켜
말썽나도 업계에선 쉬쉬
저가 경쟁에 검증 안거쳐
외국선 “한국산 못 믿어”
– 2007년 3월 28일 중앙일보 경제면 1면 기사
한용희
woom33@korea.com
롯데정보통신
정보기술연구소에 재직 중이며, 닷넷 기반의 여러 프로젝트에 참여했다. 현재 Microsoft Visual C# MVP이며 MSDN 세미나
강사로도 활동 중이다. 처음에는 2D,3D 게임 프로그래머로 시작하여 SQLServer 튜닝, 응용 애플리케이션 개발에 이르끼 까지 다양하게
경험하였으며, 주요 관심사는 DB와 애플리케이션의 연동부분 이다.
아래는
2007년 3월 28일 중앙일보 경제면 1면에 실린 기사의 일부이다.
————————————박스
시작——————————————–
D보험사는
지난해 말 수천여 명의 고객에게 약정된 보험료보다 더 많은 돈을 청구했다. 이 회사 금융전산망에 실린 소프트웨어(SW)가 말썽을 부려 빚어진
일이다. D사는 이 사실을 감춘 채 30여억원을 들여 일주일 동안 전산시스템을 샅샅이 조사했다. 그러나 SW 에러를 끝내 찾지 못했다. 이 회사
한 직원은 “회사 이미지가 떨어질까봐 선의의 피해자에게 몰래 보상해 입막음을 했지만 언제든지 이런 일이 재발될 가능성이 있다”고 말했다.
S정보기기는
부실 SW의 후폭풍으로 경영난을 겪고 있다. 이 회사는 지금까지 휴대용 정보기기를 800억원어치 팔았지만 제품에 쓰인 SW가 제대로 작동하지
않아 팔린 제품 대부분이 반품됐다.
————————————박스
끝———————————————-
왜
이런 일이 벌어지는 것일까? 개발 비용과 시간을 줄이다 보니 테스트를 제대로 하지 않고 출시한 SW가 많기 때문이다. 이런 관행은 국내 SW사가
외국에 나가서도 여전히 되풀이 되고 있다. 일본의 IT붐을 타고 진출한 한국의 SW업체 중 1/5 정도는 부실SW 문제가 불거져 현지 시장에서
퇴출을 당했다고 한다.
그렇다면
외국에서는 어느 정도의 예산을 테스트에 투자를 할까? 미국 Microsoft사의 경우 제품 개발비에서 60%까지 제품 테스트 비용으로 할당
한다고 한다. 하드웨어 업체의 경우도 점점 내장SW에 대한 투자 비용이 높아지고 있다. 일본 파나소닉의 경우 TV 제조원가의 절반을 내장SW
개발에 투자한다. 또한 북미 자동차 업체들은 연간 품질 보증 비용으로 100억 달러는 쓰는데 이중 30~40%는 전자기기 및 SW 고장 수리에
사용된다고 한다.
이처럼
SW의 신뢰성은 매우 중요하지만 한국의 현실에서는 비용과 시간에 쫒겨 많이 간과되고 있는 실정이다. 이 간과된 비용은 고스란히 유지보수 비용으로
발생하거나 나중에 시스템을 재개발 하기도 한다. 이러한 문제점을 극복하고자 몇 년 전부터 유행하는 것이 바로 테스트 주도 개발(Test
Driven Development)이다. TDD에서 가장 핵심적인 요소는 바로 신뢰성이다. TDD를 통해서 코드의 신뢰성을 보증하자는 것이다.
TDD의 또다른 장점은 바로 디커플링(decoupling)이다. 리팩터링을 용이하게 하기 위해서는 코드가 디커플링이 되어 있어야만 쉽게 변경 할
수 있다. 예를 들어 요구 사항의 변화가 있어 코드를 수정하는 경우나 코드의 품질을 높이기 위해 리팩터링 하는데 있어 어느 한 부분을
수정하였더니 다른 부분까지 문제가 되는 경우, TDD 방법을 통한 단위 테스트가 되어 있지 않다면 어디에 문제가 있는지 찾는 것이 쉽지 않다.
이러한 문제를 찾기 위해서는 코드를 하나하나 뜯어 봐야 한다. 하지만 TDD 방법론에 의한 단위 테스트 코드가 작성되어 있다면 이를 테스트
해보는 것 만으로도 어디에 문제가 있는지 쉽게 찾을 수 있다. 또한 이러한 단위 테스트 자체가 코드의 디커플링을 유발하는 효과까지 가져온다. 이
TDD에 대해서는 앞 코너에서 상세히 다루었으므로 이번 코너에서는 Microsoft의 비주얼 스튜디오를 이용한 실제 활용 방법에 대해 알아볼
것이다.
비주얼
스튜디오 팀 시스템 소개
과거
비주얼 스튜디오는 개발자를 위한 개발도구였다. 그러나 한 프로젝트를 하기 위해서는 프로젝트 매니저, 비즈니스 분석가, 애플리케이션 아키텍쳐,
개발자, 테스터와 같은 많은 사람들이 참여를 하게 되었고 이들은 서로 다른 도구를 사용해서 프로젝트를 진행하였다. 그러다보니 서로 다른 도구들은
통합이 안되어서 중복된 작업을 하게 되고 의사소통 문제가 불거지게 되면서 전체 프로젝트 개발 비용에서 무시할 수 없는 수준에 까지 이르렀다.
이제는 더 좋은 개발 도구를 만든다고 프로젝트의 개발 생산성이 향상 되는 것이 아니라, 프로젝트에 관계된 다른 사람들까지 고려를 해야만 전체적인
개발 생산성이 향상된다는 것을 Microsoft는 깨닫게 되었다. 그래서 나온 것이 바로 비주얼 스튜디오 팀 시스템이다. 제품명에서도 알수
있듯이 이제는 개발 도구(tool)가 아닌 시스템(system)이다.
팀
시스템을 여러 제품군으로 나누어져 있는데, 각 제품군별 구성은 <그림1>과 같다.
<그림1>
비주얼 스튜디오 팀 시스템 제품군
<그림1>을
보면 개발자와 테스터는 단위 테스트 도구(Unit Testing)와 코드 검사 도구(Code Coverage)가 함께 포함이 되어 있는 것을 볼
수 있을 것이다. 이는 개발자도 단위 테스트와 코드 검사를 해야 하기 때문이다. 이제 TDD 방법론을 이용한 비주얼 스튜디오의 개발 과정을
예제를 통하여 알아 보자.
클래스
디자인
이번
예제에서는 문자열 클래스를 하나 만들 것이다. 문자열을 삽입하고 삭제하는 기능을 가진 단순한 클래스이다. 먼저 클래스 디자인을 해보자. 비주얼
스튜디오에서 “클래스 라이브러리” 프로젝트를 만들고 만들어진 프로젝트의 클래스 파일에서 마우스 오른쪽 버튼을 누르면 “클래스 다이어그램 보기”
버튼이 나온다. 이를 누르면 직접 클래스 다이어그램을 그릴 수 있다. 이 다이어그램은 해당 코드 파일과 실시간으로 연동이 되는데, 다이어그램을
수정하든 코드를 수정하든 모두 양방향으로 실시간으로 업데이트가 된다. 먼저 다이어그램을 이용하여 <화면1>처럼 디자인을 해보자.
클래스의 세부 내용을 수정하기 위해서는 클래스 다이어그램에서 마우스 오른쪽 버튼으로 “클래스 세부 내용” 메뉴를 누르면 세부 내용을 편집 할 수
있다.
<화면1>
문자열 클래스 디자인
이렇게
디자인을 한 후 실제 코드를 보면 <리스트1>처럼 실제 구현 부분을 제외한 나머지 뼈대 부분이 자동으로 생성되어 있는 것을 볼 수
있다. 실제 구현 부분에는 아직 구현이 안 되어 있다는 예외를 리턴하게 되어 있는데, 실제로 구현 할 때에는 그 부분을 삭제하고 내용을 코딩
하면 된다.
<리스트1>
문자열 클래스 디자인한 결과 코드
namespace
StringSetLibrary
{
public class StringSet
{
private string _fullString;
public StringSet(string initialWord)
{
throw new System.NotImplementedException();
}
public string fullString
{
get
{
throw new System.NotImplementedException();
}
}
public void Insert(string word)
{
throw new System.NotImplementedException();
}
public void Delete(string word)
{
throw new System.NotImplementedException();
}
}
}
구현보다
테스트를 먼저!, 단위 테스트(Unit Test)
이제
클래스를 디자인 하였다면, 클래스의 내용을 구현하는 것이 일반적인 방법일 것이다. 하지만 TDD에서는 테스트 케이스부터 만들고 실제 구현을
한다. 클래스가 완성이 되었다면 통과해야 할 테스트 케이스를 먼저 만든 다음에 실제 구현을 하는 것이다. 사실 이런 테스트 케이스를 만들다 보면
오히려 클래스를 전체적으로 바라보게 되므로 클래스 디자인시에는 미처 발견하지 못했던 부분을 찾을 수 있어서 디자인을 더 자세하게 수정 할 수
있다. 즉, 구현하기 전에 미리 검증을 하므로 디자인을 더욱 완벽하게 할 수 있는 것이다. 이것이 구현 코드까지 만든 후에 디자인을 바꾸는 것
보다 몇배는 더 쉬울 것임은 의심할 여지가 없을 것이다. 그렇다면 이제 단위 테스트를 만들어 보자. 비주얼 스튜디오에서는 단위 테스트를 위한
기본적인 코드를 자동으로 생성해 주는 편리한 기능을 제공한다. 클래스의 코드에서 클래스 구문위에 마우스를 올려 놓고 오른쪽 버튼을 누르면 “단위
테스트 만들기”라는 메뉴가 나온다. 이를 눌러서 실행하면 기본적인 단위 테스트 코드의 뼈대가 만들어 진다.
단위
테스트를 위한 클래스는 클래스 속성으로 [TestClass()]라고 표기를 해야만 한다. 또한 각각의 단위 테스트 메소드도 메소드 속성에
[TestMethod()]라는 속성이 있어야만 테스트 메소드로 인식을 한다. 기본적으로 생성된 코드에서 테스트 케이스에 맞는 코드로 수정을
한다. 한 예로 문자열을 삽입하는 Insert 메소드의 단위 테스트 예제를 보자. <리스트2>는 자동으로 생성된 단위 테스트
코드이다.
<리스트2>
문자열 클래스에서 자동으로 생성된 삽입 메소드의 단위 테스트 구문
[TestMethod()]
public
void InsertTest()
{
string initialWord = null; // TODO: 적절한 값으로 초기화합니다.
StringSet target = new StringSet(initialWord);
string word = null; // TODO: 적절한 값으로 초기화합니다.
target.Insert(word);
Assert.Inconclusive(“값을 반환하지 않는 메서드는 확인할 수 없습니다.”);
}
우리의
예상은 삽입 메소드라면 문자열을 삽입한 이후 결과물이 합쳐진 상태로 나오게 하는 것이 목적이다. 따라서 위의 코드를 <리스트3>처럼
수정해 보자.
<리스트3>
문자열 클래스의 삽입 메소드에 대한 단위 테스트 코드
[TestMethod()]
public
void InsertTest()
{
string initialWord = “aaa”; // TODO: 적절한 값으로 초기화합니다.
StringSet target = new StringSet(initialWord);
string word = “bbb”; // TODO: 적절한 값으로 초기화합니다.
target.Insert(word);
Assert.AreEqual(“aaabbb”, target.fullString);
}
aaa
문자열에 bbb 문자열을 합치면 aaabbb가 되어야 한다. 이번에는 삭제 메소드에 대한 테스트 코드를 <리스트4>와 같이 만든다.
이런식으로 다른 메소드의 단위 테스트 코드도 완성을 한다.
<리스트4>
문자열 클래스의 삭제 메소드에 대한 단위 테스트 코드
[TestMethod()]
public
void DeleteTest()
{
string initialWord = “aaa”; // TODO: 적절한 값으로 초기화합니다.
StringSet target = new StringSet(initialWord);
string word = “aaa”; // TODO: 적절한 값으로 초기화합니다.
target.Delete(word);
Assert.AreEqual(“”, target.fullString);
}
단위
테스트 코드를 다 완성하면 이제 전체 단위 테스트를 해보자. 테스트 프로젝트를 선택한 후 비주얼 스튜디오 상단 메뉴에 보면 “테스트” 라는
메뉴가 있다. 그 하위 메뉴를 보면 “선택한 프로젝트를 디버거 없이 시작”이라는 메뉴가 있다. 이를 선택하면 테스트 디버거 없이 수행 할 수
있다. 물론 디버거 까지 같이 돌리면서 수행 할 수도 있다.
<화면2>
단위 테스트 결과
<화면2>를
보면 단위 테스트 결과가 나올 것이다. 이미 예상은 하였겠지만, 전부 실패다. 오류 원인은 아직 미구현이 되었다는 예외를 리턴했다는 것이다.
이제 실제 클래스의 내용을 <리스트5>처럼 채워 보자.
<리스트5>
문자열 클래스의 전체 구현 코드
public
class StringSet
{
private string _fullString;
public StringSet(string initialWord)
{
_fullString = initialWord;
}
public string fullString
{
get
{
return _fullString;
}
}
public void Insert(string word)
{
_fullString += word;
}
public void Delete(string word)
{
if (_fullString.IndexOf(word) < 0)
throw new Exception(“Cannot find word”);
_fullString = _fullString.Replace(word, “”);
}
}
삽입은
단순하게 문자열을 더하는 것이고 삭제는 단순하게 구현하기 위하여 해당 문자열을 공백으로 치환을 하였다. 이제 이 클래스 라이브러리를 빌드하고
테스트 프로젝트에서 테스트를 수행하면 4가지 메소드 테스트가 성공으로 끝나는 것을 확인 할 수 있을 것이다.
단위
테스트에 대한 검증, 코드 검사(Code Coverage)
단위
테스트를 잘 수행하였지만, 한가지 의문이 남을 수 있다. 단위 테스트 자체를 잘 만들었는지 검증을 해야 하는 것이다. 테스트 케이스를 빼먹으면
결국 테스트를 안 하는 것이 되기 때문이다. 따라서 단위 테스트 코드를 작성하는데에서 끝나면 안되고 그 단위 테스트 코드가 모든 클래스의 코드를
다 검증하는지 확인을 해야만 한다. 그때 사용하는 것이 바로 코드 검사(code coverage)이다. 이를 하기 위해서는 해당 솔루션에 보면
테스트 환경설정 정보를 설정해 주어야만 한다. 솔루션의 localtestrun.testrunconfig파일을 두 번 클릭하면 테스트 환경 설정을
하는 화면이 나오는데, 왼쪽의 “코드 검사” 메뉴를 누르고 오른쪽 화면에서 코드 검사를 하려는 DLL을 체크해 주면 된다. 우리는 문자열 클래스
라이브러리를 코드 검사할 것이므로 StringSetLibrary.dll을 선택하면 된다. 그러고 나서 다시 테스트를 수행한다. 수행 결과 창에서
마우스 오른쪽 버튼을 누르면 메뉴 중에 “코드 검사 결과”라는 메뉴가 있다. 이를 선택하면 코드 검사 결과를 볼 수 있다.
<화면3>
문자열 클래스에 대한 코드 검사 결과
<화면3>을
보면 전체 단위 테스트로 검사한 블록이 83.33%이고 검사 하지 않은 블록이 16.67%라고 나온다. 그렇다면 과연 어느 메소드에서 검사 안
한 부분이 있는 것일까? <화면3>을 자세히 보면 Delete 메소드만 검사율이 66.67%에 머물고 있다. 이를 더블 클릭하면 바로
해당 메소드를 이동하여 검사 안 한 부분을 빨간색으로 보여준다.
<화면4>
문자열 클래스의 삭제 메소드에서 단위 테스트를 안 한 부분
이에
대한 테스트 코드를 작성하면 코드 검사를 100%로 만들 수 있다.
코드
리뷰를 자동화한 정적 코드 분석(Code Analysis)
이제
단위 테스트를 통해서 모든 코드를 테스트 하였다. 하지만 테스트 코드를 모두 통과하였다고 모든 테스트를 완벽히 통과한 것은 아니다. 오류 라는
것은 단순 예측 결과물에 의한 테스트 뿐만 아니라 주변의 실행 환경이나 상황에 따라 많은 변수가 있기 마련이다. 이런 오류를 잡아내기 위해서는
코드를 분석해야 하는데 그 방법에는 두가지가 있다. 하나는 컴파일 이전에 코드를 하나하나 보면서 정적으로 분석하는 방법이 있고, 또 다른
방법으로는 코드를 컴파일 한 후 실행하면서 분석하는 동적 분석 방법이 있다. 먼저 정적인 방법은 보통 프로젝트에서 개발자가 만든 코드를 코드
리뷰라는 형식으로 분석하는 방법을 말한다. 하지만 이를 다 사람이 하기에는 시간이 많이 소요된다. 이를 어떤 규칙을 정해서 자동화 한 것이 바로
“코드 분석(Code Analysis)”이다. 과거 관리 코드(managed code)를 분석하는데 사용하였던 FxCop이라는 툴과
C/C++코드를 분석하는데 사용하였던 PREfast
툴을 합쳐서 코드 분석기라는 것으로 만들었다.
사용하는
방법은 어렵지 않은데, 분석하려는 프로젝트의 속성에 보면 “코드 분석”이라는 탭이 있다. 이를 선택한 후 “코드 분석 사용”이라는 체크 박스를
선택하면 코드 분석기가 작동하게 된다.
<화면5>
코드 분석기 화면 
<화면5>에
보면 이미 미리 정의되어 있는 각종 규칙들이 있는데, 기본적으로 이를 어기면 “경고”창이 나오도록 설정이 되어 있다. 이를 오류가 나도록
변경하는 것은 해당 상태를 더블 클릭하면 된다. 또한 이러한 규칙은 프로젝트의 성격에 맞게 새로 만들 수도 있다. 일단, 다른 규칙은 제외하고
“명명 규칙” 하나만 테스트 해 보자.
문자열
클래스에서 “명명 규칙” 하나만 남기고 모든 규칙은 제외 한다. 그리고 다시 빌드를 하면 <화면6>과 같은 결과가
나온다.
<화면6>
코드 분석기를 적용하여 컴파일한 결과
문자열
클래스에서 프라이빗 필드인 _fullString에 접근하는 속성 명칭을 fullString으로 정의해서 나온 경고문구 이다. 이를
FullString이라고 대문자로 바꾸어 주면 이 경고 문구는 사라진다. 이처럼 기존에 사람이 하던 코드 리뷰를 코드 분석을 통해서 어느 정도는
자동화 할 수 있다.
성능
분석을 통한 동적 분석(Code Profiling)
정적
분석은 실제 실행하기 이전에 코드를 분석하는 방법이다. 이와 반대로 동적 코드 분석 기법인 코드 프로파일링(Code Profiling)은 실제
실행환경에서 코드의 성능을 분석하는 방법이다. SQL Server를 사용하신 분들은 SQL Profiler라는 툴을 잘 알 것이다. 이는 실제
실행환경에서의 쿼리 구문에 대한 분석을 가능하게 해 주는 툴이다. 코드 프로파일러도 이와 비슷한 기능을 한다.
이를
수행하기 위해서 실제 실행 환경을 만들어 보자. 문자열 클래스를 사용하는 간단한 콘솔 응용 프로그램을 추가하고 <리스트6>과 같은
코드를 실행해 보자.
<리스트6>
문자열 클래스의 응용 프로그램 코드
static
void Test1()
{
StringSet s = new StringSet(“aaaaaaaaaa”);
for (int i = 0; i < 10000; i++)
{
s.Insert(“bbbbbbbbbb”);
}
Console.WriteLine(s.fullString.Length);
}
기능은
간단하다. bbbbbbbbbb라는 문자열을 만번 반복적으로 추가 하는 것이다. 이제 이에 대한 성능을 측정하려면 비주얼 스튜디오 상단의 메뉴중
“도구”에서 “성능 도구”-“성능 마법사”를 클릭한다. 그러면 성능을 측정할 프로젝트를 선택한 후 프로파일링 방법을 물어 본다. 프로파일링
방법은 샘플링(sampling)과 계측(instrument)라는 두가지가 방법이 있다. 샘플링은 전체 응용프로그램을 일정 시간 간격으로 성능을
측정하는 방법이다. 일정 시간 간격으로 체크 하므로 부하가 적게 발생하지만 상세 정보는 알 수 가 없다. 반면에 계측 방법은 해당 응용
프로그램의 함수에 시작과 끝을 체크하는 구문을 삽입하여 정확한 성능을 측정하는 방법이다. 전체적인 시스템 성능을 보는데 있어서는 샘플링 방법이
좋고, 응용 프로그램의 각각의 함수 마다 정확한 정보를 보기 위해서는 계측 방법이 더 좋다. 여기에서는 계측 방법을 사용하자. “마침”을
선택하고 “성능 탐색기”에서 해당 성능 측적을 시작하면 <화면7>과 같은 결과가 나온다.
<화면7>
문자열 클래스의 성능 검사 결과
Insert
메소드가 만번 호출이 되었으며, 약 2.6초의 시간이 걸렸다는 결과가 나왔다. 각기 화면을 더블 클릭하면 호출 트리를 볼 수도 있으며 각
메소드별 상세 성능 정보도 볼 수 있다. 이는 닷넷 튜닝 예제로 많이 알려진 사례인데, string 타입은 불변(immutable) 타입으로써
문자열을 더하면 기존 문자열에 새 문자열을 더하는 것이 아니라, 문자열을 합친 후 기존 문자열은 버리고 새로운 문자을 생성한다. 왜냐하면 기존
문자열은 수정 할 수 없는 불변 타입이기 때문이다. 그렇기 때문에 메모리 할당하는데 부하가 걸리는 것이다. 이를 튜닝하기 위해서는
StrignBuilder라는 클래스를 이용하면 된다. 이는 문자열을 위해서 미리 버퍼를 할당하기 때문에 기존 문자열을 수정 할 수 있다.
기존
StringSet 클래스와 비교를 위해서 이번 클래슨 StringSet2로 하여 <리스트7>과 같이 만들어 보자.
<리스트7>
기존 StringSet 클래스를 개선한 StringSet2 클래스
public
class StringSet2
{
private StringBuilder _fullString;
public StringSet2(string initialWord)
{
_fullString = new StringBuilder(initialWord);
}
public string fullString
{
get
{
return _fullString.ToString(); ;
}
}
public void Insert(string word)
{
_fullString.Append( word);
}
public void Delete(string word)
{
_fullString = _fullString.Replace(word, “”);
}
}
이번에는
삽입 메소드에서 단순 더하기가 아닌 append 구문을 이용해서 구현하고 있다. 이제 이 둘을 동시에 테스트 해보자. 마찬가지로 테스트를 하고
각 메소드에 대한 상세 정보를 보면 <화면8>과 같다.
<화면8>
두 문자열 클래스의 삽입 성능 비교
<화면8>을
보면 두 클래스의 삽입 메소드의 성능 차이가 극명하게 보인다. 처음에 만든 것은 약 2.6초가 걸렸으며, 나중에 만든 것은 0.003초가
걸렸다. 이와 같이 성능 테스트를 통하여 미리 성능을 검증할 수 있다.
웹
애플리케이션을 위한 웹 테스트
웹
애플리케이션은 그 환경이 일반 응용 프로그램과 사뭇 다르다. 기본적으로 네트웍에 연결이 된 상태로 클라이언트 브라우저를 통해서 서버에 접속하게
된다. 따라서 이러한 환경을 위한 별도의 테스트 툴이 필요한데 비주얼 스튜디오에서는 웹 테스트라는 툴을 제공한다. 이 웹 테스트는 익스플로러에
삽입이 되어서 함께 작동을 하는데, 사용자의 모든 액션을 다 녹화를 한다. 그리고 그 녹화된 결과에 대해 유효성 검사나 결과 검사를 수행 할 수
있다.
먼저
예제로 Northwind DB의 직원을 검색하는 웹 프로그램을 만들어 보자. 새로운 솔루션에서 “새 웹 사이트”로 파일 시스템 형식의 웹
사이트를 만든다. 이 강좌는 ASP.NET 2.0 강좌가 아니므로 자세한 구현은 생략한다. 단, 테스트를 위해서는 웹 프로젝트의 포트를
고정시켜야 한다. 솔루션에서 웹 사이트를 누르면 속성 메뉴에 “동적 포트 사용”이라는 메뉴가 있다. 이를 False로 변경해서 고정 포트를
사용해야만 웹 테스트시에 그 포트 번호로 접속해서 테스트를 할 수 있다. 물론 웹 사이트를 파일 시스템이 아닌 HTTP를 이용해서 만든 경우에는
해당하지 않는 내용이다.
<화면9>
NorthWind DB의 직원을 검색하는 웹 애플리케이션
<화면9>는
웹 애플리케이션의 디자인 뷰와 king이라는 사용자를 검색한 결과 화면 이다.이제 이 웹 애플리이션을 테스트 해보자. 새 테스트 프로젝트를
솔루션에 추가하고 새 항복으로 “웹 테스트”를 추가하면 익스플로러가 열린다. 여기에서 녹화하고자 하는 웹 페이지의 URL을 입력하면 자동으로
녹화가 시작된다. 이곳에 사용자 검색으로 king을 검색하는 행위를 하면 <화면10>과 같이 녹화가 된다.
<화면10>
king을 사용자 검색한 화면을 녹화한 장면
이제
녹화한 이 행위를 수정해서 다른 테스트를 해 볼 수도 있다. 파라메터를 바꿔서 유효성 검사를 할 수도 있다. 예를 들면 화면에 “환영합니다”라는
단어가 꼭 나와야만 테스트를 성공한 것으로 간주한다고 하는 유효성 검사 조건을 줄 수도 있다. 또한 파라메터도 동적으로 바꿀 수 있는데,
DB에서 파라메터를 읽어와서 동적으로 계속 바꿔 줄 수도 있다. 따라서 검색어로 king이 아닌, Fuller, Davolio와 같은 다양한
파라메터를 테스트 할 수 있다.
부하
테스트(Load Test)
한명의
사용자를 위한 테스트가 아닌 다수의 사용자를 동시에 테스트 하는 환경을 만들기 위해서는 부하 테스트를 해야만 한다. 특히 웹 애플리케이션의 경우
한 명이 아닌 다수가 동시에 접속하는 경우가 많기 때문에 부하 테스트는 필수적인 부분이다. 그렇다고 많은 사람을 불러다 놓고 특정 메뉴를 동시에
“자 누르세요~”라고 하기도 쉽지 않다. 따라서 이러한 행위를 대신 해주는 자동화 테스트 도구가 바로 부하 테스트 도구이다.
부하
테스트는 기본적으로 다른 테스트를 기반으로 테스트를 수행한다. 위에서 이미 만들어 둔 웹 테스트를 기반으로 부하 테스트를 해 보자. 새 항목으로
“부하 테스트”를 추가한다. 그러면 부하 테스트 마법사가 나온다.
첫
번째로 사용자를 어떻게 추가할 것인지 물어 본다. 일정한 수의 사용자로 부하 테스트를 할 수도 있고, 단계적으로 사용자 수를 늘릴 수도 있다.
두 번째로 어떤 테스트를 수행 할 것인지 묻는데 우리는 위에서 만든 웹 테스트를 수행 할 것이므로 해당 웹 테스트를 선택한다. 세 번째로는
브라우저를 선택하는 화면이 나오는데, 익스플로러 뿐만 아니라 넷스케이프, 스마트폰 브라우저까지 선택이 가능하다. 네 번째로는 네트워크 환경을
선택할 수 있는데, LAN, DSL, 전화 모뎀까지 다양한 환경을 선택할 수 있다. 마지막으로 어떤 컴퓨터의 성능 카운터를 수집할 것인지
컴퓨터의 이름을 적어 주면 된다. 이렇게 실제 수행 환경과 비슷한 경우를 <화면11>과 같이 만들 수 있다.
<화면11>
부하 테스트 설정 화면
여기에서
“실행 설정”의 속성 정보를 수정하면 SQL Server의 프로파일러도 추가하여 같이 추적할 수 있다. 따로 SQL Server의 프로파일러를
준비할 필요가 없는 것이다.
이제
부하 테스트를 수행해 보자. 부하 테스트를 수행하면 <화면12>와 같은 결과 화면이 나온다.
<화면12>
부하 테스트 결과 화면
<화면12>를
보면 사용자수는 단계적으로 계속 증가하는 화면이 보이며, 평균 응답 시간도 시간이 갈수록 전반적으로 나빠지고 있는 것을 확인 할 수 있을
것이다. 화면 왼쪽에 보면 성능 카운터를 확인 할 수 있다. 이중 빨간불이 들어온 것은 성능에 문제가 있는 부분이다.
<화면12>에서는 안 보이는데, 트리를 펼쳐보면 CPU 사용량이 100%에 도달해서 나온 부분이다. 노란불은 경고 부분으로 이 부분
또한 잠재적인 위험성이 있는 부분이므로 주의 깊게 살펴 보아야 하는 부분이다.
이러한
성능 카운터 말고도 SQL Server 프로필러 정보도 동시에 확인이 가능한데, 이전에 프로필러 옵션을 선택했다면 해당 폴더에 프로필러 결과
파일을 만들어 준다. 이를 열어 보면 <화면13>과 같다.
<화면13>
SQL Server 프로필러 결과 화면
결과를
보면 DB 서버에 직원 검색 쿼리를 계속 다른 파라메터로 날리고 있는 것을 확인 할 수 있을 것이다.
테스트를
위한 종합 선물 셋트
비주얼
스튜디오는 프로젝트에 관련된 모든 사람(프로젝트 매니저, 비즈니스 분석가, 애플리케이션 아키텍쳐, 개발자, 테스터 등)을 위한 통합된 도구를
제공한다. 테스트를 위해서도 각각의 목적에 맞게 따로 사용했던 단위 테스트, 코드 검사, 코드 분석, 코드 프로파일링, 부하 테스트 등과 같은
작업을 이제는 하나의 툴에서 통합적으로 사용할 수 있다. 또한 이렇게 테스트한 결과를 다른 프로젝트의 구성원과 쉽게 공유할 수 있도록 워크
아이템을 등록하여 손쉽게 공유도 가능하다.
비주얼
스튜디오의 이러한 기능은 참으로 편리한 기능이다. 하지만 서두에서 언급을 했듯이, 이러한 좋은 도구를 사용하기 위해서는 그에 걸맞는 개발 환경이
갖추어 져야만 한다. 개발 비용과 시간에 쫒겨서 테스트에 대한 고려를 충분히 하지 않는 다면 아무리 좋은 도구가 있어도 무용지물이 될 것이며,
결국은 부실한 SW를 양산하게 되는 결과를 초래하게 될 것이다.