Oct 06
alonesME/me2day #pragma, #pragma warning, iTunes, test case, Testing, 다세대, 빌라, 연립, 전처리, 테스트, 테스트 케이스, 테스팅
Sep 06
alonesComputerScience/SE/SQA Killed Mutant, Mutant, Mutant Score, Mutation Testing, SE, SQA, 뮤테이션 테스트, 테스트, 테스트 케이스 평가
테스트 케이스가 얼마나 잘 작성했는지 평가하는 것은 “보통 얼마나 많은 결함을 찾았나?” 또는 “커버리지 (Coverge)가 얼마나 되나?”를 통해서 평가 받을 수 있을 것이다.
그리고 또 하나 Mutation Testing을 통해서도 평가 받을 수 있을 것이다.
원본 프로그램을 수정 한 Mutant를 테스트 케이스를 수행해서 수정된 부분으로 인해 실패한 테스트 케이스가 있는지를 통해서 테스트 케이스가 얼마나 테스트를 잘 하고 있는지 평가 할 수 있다.
즉, c = a+b; 라는 코그를 c = a-b; 수정 후 테스트 케이스를 돌려 실패한 테스트 케이스가 있는지 확인하는 것이다.
보통 생성한 총 Mutant 분에 테스트 케이스가 실패해서 Mutant임이 밝혀진 Killed Mutant 수인 Mutant Scroe로 테스트 케이스 수준을 평가한다.
Mutant Score = # of Killed Mutant / # of Total Mutant
Ref
[1] Mutation Testing 관련 Papers http://ise.gmu.edu/~ofut/rsrch/mut.html
[2] Mutation Testing 소개 PDF http://agile.csc.ncsu.edu/testing/MutationTesting.pdf
Dec 11
alonesComputerScience/SE/SQA SE, SQA, Testing, 소프트웨어 테스트팅, 테스트, 패러다임
지극히 주관적인 의견이지만 전자 제품은 텔레비전 뿐인 산골에서의 망상 (illusion)은 아니라고 생각되어 몇 글자 적어 봅니다.
소프트웨어 테스트가 현실 (일정과 인력)을 만났을 때, 아마 가장 많이 연상되는 단어는 “트레이드 오프 (trade off)”일 것입니다.
- 출시가 얼마 남지 않았기 때문에
(어느 정도의 결함을 안고서라도 “타임 투 마켓”이 더 우위에 있기 때문에)
- 개발 인력이 턱없이 부족하기 때문에
와 같은 이유로 테스트는 (어쩔 수 없이) 뒷전으로 밀려나는 경우가 많은 것 같습니다.
그렇지 않은 경우를 찾는 것이 더 힘들겠죠.
저의 제목과 이 포스트에서 말하고자하는 것은 무엇일까요?
그 것은 무엇이라고 정의할 수는 없지만 그 “변화”가 “테스트”에 유리하게 흘러간다는 것입니다.
기존에 테스트를 어렵게 만든 것 큰 이유 중의 하나는, 개발 자체에 소요되는 비용 (인력/시간)일 것입니다.
제가 패러다임 운운한 것은 이 개발에 대한 비용이 점점 줄어들 것 같기 때문입니다.
즉, 개발 비용이 줄어들기 때문에 다른 것에 남는 비용을 (물론 전체 비용을 줄여 버릴 수도 있지만) 다른 곳으로 돌릴 여지가 많아진다는 것입니다.
동의할 수도 있고 동의하지 않을 수도 있지만 “개발 비용”이 줄어들 것 같다는 것에 대한 몇 가지 현상들을 거론해보면 다음과 같습니다.
※ 물론, SE나 공중 부양을하고 있는 몇몇 언어의 순수 이론자 (doctrinaire)들의 말을 하기 시작한다면 끝도 없을 것입니다. 저는 제가 주로 보고 느낀 것들에 대해서 쓰겠습니다.
- 통으로 만들던 것들을 점점 레이어를 나누어 프레임워크, 플랫폼이라는 말을 하면서 개발하려고 합니다. (reusability를 이용한 생산성 향상이겠죠?)
- Visual C++ Team 블로그에서도 C++의 미래를 system programming을 위한 최적화 언어로 이야기한 적이 있습니다. 즉, 그 만큼 system level 이상에서 무언가 만들기 위한 고급 언어들이 많아졌고 그들의 한결같은 특징은 높은 생산성입니다.
- Java, C/C++ 등으로 열심히 플랫폼 (or 프레임워크)를 만들던 사람들이 파이어폭스 (정확히는 Gecko 겠죠?)를 플랫폼 자체로 사용하려고 합니다. 안드로이드 (Android)를 보는 시각도 같겠죠.
- 일본의 어떤 회사들은 perl을 사용한다고 해도 모든 것들을 창조한다고 합니다. 하지만 점점 더 “잘 가져다 쓰는 사람”들의 창조물을 더 이상 구태의연한 변명으로 덮어 버릴 수 없게 되어갑니다.
- 이제는 특정 OS (e.g. MS Windows)에서 나 홀로 (standalone) 애플리케이션을 만들던 시대는 점점 가버리고 환상적인 웹 기반 애플리케이션의 시대가 오고 있는 것 같습니다.
- (불특정의) 내가 고집하고 대대로 계승할 것만 같던 기술들에 대해 정체성을 느끼기 시작합니다.
- 더 이상 Java는 예전의 달팽이에 볼품없던 외관을 가졌던 그 Java가 아닌것 같습니다.
좀 더 많은 것들을 이야기 할 수도 있겠지만, 왠지 어느 양심수의 독백과 같은 풍으로 글이 흘러가는 것 같아서 줄이겠습니다.
하지만 말하고 싶은 것은
너무나 빨리 (쉽게라는 말은 하지 않겠습니다) 멋진 것들을 만들 수 있게 되어가고
“잘 만드는 사람” 보다는 “잘 이용해서 가져다 쓰는 사람”이 필요해지고
개발 그 자체의 비용이 줄어 들어감에 따라 이제는 생각 (기획)하고 품질(테스트를 포함하는)을 위해 투자할 비용이 넉넉해지는 것 같습니다.
그렇습니다.
Oct 26
alonesComputerScience/SE/SQA ms, Software Testing, SQA, Testing, 테스트, 테스트 사례
최근 MS VC++ 라이브러리 개발팀의 테스트 자동화에 대해서 소개해 드렸습니다.
이 번엔 MS VC 컴파일러 개발팀의 QA팀에 대해서 소개해드리겠습니다.
이 전 포스트와 마찬가지로 Visual C++ Team Blog에 게시된 내용입니다.
먼저 두괄식으로 정리를 하면 다음과 같습니다.
■ QA (Quality Assurance)팀 일원들이 자신의 일을 자랑스럽게 여긴다.
■ SQA (Software Quality Assurance)팀은 우리가 잘 알고 있지만 행하지 않는 Software Testing의 해야 할 일들을 그 어떤 조직보다 체계적으로 잘 수행하고 있다.
글을 쓴 사람은 Smile Wei로 VC++ 컴파일러 팀 내에 있는 QA 팀 (SDET)에 3개월 반 전에 합류했고 VC 컴파일러에 대한 QA일을 하고 있습니다.
그는 자신의 포스트를 쓴 목적이 (위에서 정리한 것과 같이)
Microsoft, 특히 VC 팀에서일하는 것을 좋아하느냐? (정확히는 QA팀)
VC 팀의 QA팀에서는 매일 무슨 일을 하느냐?
에 대한 답변을 위해서 글을 쓴다고 합니다.
1. Microsoft, 특히 Visual C++ 컴파일러 팀에서일하는 것을 좋아하느냐? (정확히는 QA팀)
이에 대한 답변으로 Smile Wei는 (당연하겠지만) QA 일을 하는 것을 사랑하고 자랑스럽게 생각합니다.
그리고 “일반적으로 QA 엔지니어가 개발자보다 기술적으로 떨어진다는 생각을 여기서는 하지 말라” 라고 단호하게 이야기 합니다.
흔히 생각하는 메뉴얼 테스트나 단순한 테스트 input을 넣은 코드 베이스의 (like unit test) 테스트를 하는 일이 아니란 것입니다.
VC 컴파일러의 테스트니 당연히 테스트 input은 소스 코드이고 (이 것만으로 일반적인 테스트와는 구분될 것입니다), 테스트는 x86, amd64또는 ia64의 여러 형태의 머신에서 수행되고 수많은 컴파일러 옵션을 조합해서 테스트를 수행한다고 합니다.
즉, 동일한 테스트 케이스도 다른 머신, 다른 수행 환경 (컴파일러 옵션 등)에서 성공되기도 하고 실패하기도 하며 그것의 원인을 분석하는 것도 힘든 작업이라고 합니다.
그래서 QA팀에서는 테스트 input을 만들 때 내부에서도 고민을 많이 하지만 개발자와도 많은 논의를 한다고 합니다.
그래서 이와 같이 기술적으로 난이도 높은 (일반 개발자가 하기 힘든)일을 하는 것이 자랑스럽다고 하고 자기 주변의 개발자들이 한 주 씩 끙끙거리며 버그를 찾는 것을 자신이 쉽게 찾아 내는 것에 대해서 희열을 느낀다고 합니다.
※ [제 생각]잠시 생각해보면, 제 주위 뿐만 아니라 많은 사람들이 테스팅을 하든 테스트 기법을 연구든, 테스트 도구를 만들든 “테스트”와 관련된 일을 하는 것을 이와 같이 자랑스럽게 생각하는 것을 본적이 없습니다. 저도 마찬가지 이구요.
그 이유는 무엇일까요? 바로 (기술적) 전문성이 다른 분야에 비해 떨어져 보인다고 생각하기 때문일 것입니다. (일용직 아르바이트 또는 신입 사원에게 테스트를 맡기는 국내의 현실을 보면 당연하겠죠) 하지만 테스팅 (도구이든 기법이든, 행위든)이라는 분야가 그렇게 기술적 도메인 지식이 얕은 곳은 결코 아닌 것 같습니다. 이에 대해서는 다음에 포스팅 하겠습니다.
2. VC 팀의 QA팀에서는 매일 무슨 일을 하느냐?
(저는 이 부분이 무척 궁금했는데, 역시 기대 이상으로 멋진 부분들이 많았습니다)
Smile Wei는 그가 VC 컴파일러 팀의 QA팀으로 다음과 같은 7가지 정도의 일을 매일 수행한다고 합니다.
1. 버그 분석
말 그대로 테스트 수행 후 발견된 버그에 대해서 분석한다고 합니다. 그리고 예상하시는 것 처럼 MS에서는 Daily Testing 이 프로세스로 정착되어 매일 테스트가 수행되고 그에 대해 결과를 분석한다고 합니다. 물론 이를 위해 거의 대부분 테스트 자동화가 되었겠죠. (예전 저의 포스트에서 소개해드린 것처럼) 이 일이 최고 우선순위라고 합니다.
2. 테스트 케이스 수정과 Regression 테스트 케이스 작성
기존 작성되어 있는 테스트 케이스의 수정 뿐만 아니라 새로운 Regression (회귀) 테스트 케이스 작성을 의미하는데, 특이한 것은 Double Assurance Mechanism 이라는 프로세스 입니다.
개발자가 버그를 수정하고 자신의 테스트 케이스로 수정확인을 하고 QA팀에게 전달하면 QA팀에서는 좀 더 복잡하고 다양한 테스트 케이스를 수행해서 수정이 올바르게 되었는지 한 번 더 확인하는 것입니다.
앞에서 설명했듯이 다양한 환경과 컴파일러 옵션으로 더 복잡한 테스트 케이스를 이용해 수정된 부분이 올바르게 동작하는지 regression 테스트로 확인하는 것입니다.
즉, side effect가 발생했는지 확인하는 프로세스입니다.
누구나 알고 있는 것이지만 일정이나 인력을 핑계로 하지 않는 것을 실제로 잘 행하고 있는 것 같습니다.
실제로, 이와 같은 활동으로 인해 Smile Wei가 가지고 있는 테스트 케이스는 약 20,000개이고 이 것은 컴파일러 팀의 QA팀이 가지고 있는 10개의 test suite (test case의 집합) 중 하나라고 합니다. 하지만 이 것은 VC++ 컴파일러 팀이 가지고 있는 것이고 VC++ 라이브러리 개발팀이나 IDE 팀, 릴리즈 팀, Visual Basic 팀, C# 팀들도 이와 같은 팀들도 각각의 테스트 케이스를 확보하고 있다고 하니 놀랍습니다.
아무튼, 상상을 초월하는 테스트 케이스들이 매일 수행되어진다고 합니다. 물론 테스트 자동화 없이는 불가능 할 것입니다.
3. QFE (Quick Fix Engineering) 확인
QFE는 흔히들 말하는 hotfix (필수 업데이트. e.g. 윈도우 필수 업데이트)에 대한 검증 작업입니다.
QFE 또한 2차에 걸쳐서 수행된다고 합니다.
QFE 프로세스를 살펴보면,
지원 팀 (support team)에서 고객으로부터 버그 리포트를 수집하고 버그를 확인 후 개발팀에 버그 리포팅을 합니다. 개발팀은 버그를 수정 후 QA 팀에게 수정 여부를 알려 QA팀의 테스트가 시작되는데, 1차는 hotfix에서 버그를 발견한 고객에게 수정된 hotfix를 전달하기 전에 테스트를 수행하는 것이고 2차는 버그를 발견한 고객이 버그 수정을 확인 후 최종 릴리즈를 위해 전체 테스트를 수행하는 것이라고 한다.
(버그 수정 후 QA팀이 테스트를 수행하고 버그 발견 고객이 버그 수정이 올바르다고 확인하면 최종 릴리즈를 위해 전체 테스트를 다시 수행하는 프로세스입니다.)
고객과 직접적으로 관련된 일이기 때문에 QFE 확인은 최고의 우선 순위를 가지는 작업이라고 합니다.
4. 크로스 팀 테스트 지원 (cross-team test support)
글을 읽을 수록 MS의 QA팀은 테스트에 강박 관념을 가진 것 같습니다 (좋은 뜻).
VC 컴파일러 팀의 테스트 케이스를 다른 팀에게 제공하는 작업을 의미합니다. 예를 들어 Smile Wei는 최근 Visual Studio 2008 설치 프로세스를 위해 릴리즈 팀에게 자신의 테스트 케이스를 그들이 수행할 수 있게 제공했고 또한 라이브러리 팀을 위해 VS 2008 MSDN 테스트를 수행해줬다고 합니다. 두 작업을 통해서 몇 가지 버그를 발견했다고 합니다.
흔히 개발자가 자신의 관점에서만 테스트를 하기 때문에 제 3자의 다른 각도에서 테스트를 하는 것이 필요하다고 하고 그것을 위해 다른 조직 (QA팀)에서 테스트 케이스를 작성하고 테스트를 합니다. 이 것을 넘어 MS에서는 각 QA팀 간에도 서로 테스트 케이스를 공유해서 좀 더 다양한 뷰에서 테스트를 강도 있게 수행하고 있습니다.
5. 내부 테스트 도구 개발
(이 일은 제가 하는 일과도 유사합니다만..)
위에서 거론 한 것처럼 MS는 모든 제품에 대해서 매일 테스트를 수행하고 각 테스트 수 십만개 또는 수 백만개의 테스트 케이스를 수행합니다. 이 것을 위해서는 당연히 테스트 수행, 결과 수집, 결과 비교와 같은 모든 테스트 과정이 완전 자동화 되어야 할 것입니다. 이 것을 위해 아주 많은 테스트 도구들이 사용된다고 합니다.
MS에서는 각 연구원들이 여러 형태의 내부 테스트 도구를 개발해서 테스트 효율성을 높이는 것을 독려하고 그 중 몇 몇 도구는 모두 부서 또는 MS 전체에서 채택해서 사용하게 하기도 한답니다.
6. 새로운 기능에 대한 테스트 케이스 작성
현재 VS 팀은 VS2008의 차기 버전을 준비하고 있다고 합니다. QA팀은 모든 새로운 제품 및 기능에 대한 테스트 활동에 참여합니다.
또한 테스트 프로세스가 제품 개발 주기의 코드가 완료되기 훨씬 이전의 초기에 시작된다고 합니다. 즉, Waterfall 모델이 아닌 애자일 (Agile) 모델을 채택하고 있습니다. 누구나 알고 있는 “버그를 발견한 시점이 제품 개발 주기 후 반부로 갈 수록 비용은 훨씬 더 많이 증가”한다는 사실을 직접 실행해 옮긴 것입니다.
7. 기타
이 외에도 캠퍼스 리크루팅, 신입 사원을 위한 교육 자료와 비디오 작업, 면접 등을 수행합니다.
정말 많은 일을 하는 것 같습니다.
중요한 것은 Software Testing에서 흔히 말하고 Testing 분야에 조금이라도 관심이 있거나 관련 일을 하는 사람이면 누구나 알고 있는, 그렇지만 여러 가지 핑계로 행하지 않는 것을
MS의 QA팀은 체계적으로 수행한다는 것입니다.
우리는 성공하는 사람들의 위인전을 너무나 많이 읽고 심지어 그 방법도 머리 속에 다 알고 있지만, 여러 가지 현실과 그 것으로 만든 자신 (조직) 만의 핑계로 행하지 않습니다.
성공하는 사람들은 그 명백한 방법을 행동으로 옮긴 사람이겠죠? MS처럼
Oct 22
alonesComputerScience/SE/SQA Automation, SQA, Test Automation, test framework, Test Tool, 테스트, 테스트 자동화, 품질
Test Automation.
이와 관련된 일을 조금이라도 했던 사람이면 제가 무슨 말을 하고 싶은지 아실 겁니다.
테스트 자동화는 단위 시험 (Unit Test) 부터 통합 시험 (Integration Test), 시스템 테스트 (System Test)까지 어떤 시험에서도 필요할 것입니다.
JUnit, CUnit, CUTest, CppUnit, CppUnit2, NUnit 등과 같은 수 많은 open test framework들이 단위 시험과 통합 시험의 자동화를 도와 줍니다. 그리고 PARASOFT의 C++ Test와 같은 멋진 상용도구도 있습니다.
(※ XProgramming.com의 Software 페이지에 보면 수많은 Unit test framework들이 열거 되어 있습니다.)
그리고 TestQuest, TestDirector와 같은 시스템 테스트 자동화 도구도 있습니다.
그리고 위에 열거된 도구를 이용하든 자체 제작을 하든 자신들의 개발 소프트웨어를 위한 테스트 자동화를 위해 멋진 도구를 만들어보려고 (또는 보라고) 시도 했거나 하고 있을 겁니다.
(서두가 길었습니다)
하지만 문제는 주객이 전도되는 경우가 많고 테스트 자동화를 맹신해서 아주 어렵게 마련한 품질향상의 노력 (effort)을 낭비하는 경우를 종종 보아왔습니다.
테스트 자동화의 목적은 무엇일까요?
반복되는 작업을 줄이기 위한 것이지 아주 요상하고 복잡한 시나리오로 발생할 수 있는 버그 (defect)을 잡아주는 것이 아닙니다.
각 개발자들이 작성한 수 백개의 테스트를 밤새 회귀 테스트 (Regression Test)를 목적으로 자동으로 돌려주는 것,
MP3의 볼륨 업/다운을 만번씩 눌러보는 것을 자동으로 처리해주는 것,
이 와 같은 일들을 소프트웨어를 이용해서 (또는 하드웨어를 이용해) 자동으로 해주는 것이지 복잡한 Race condition을 자동으로 만들어 (만들었다 하더라도) 어떤 상황에서 문제가 발생했는지 짜잔하고 리포팅해주는 것이 테스트 자동화는 아닐 것입니다.
즉, 단순한 반복 작업을 자동화하는 것이 목적일 뿐입니다.
물론, 아주 smart한 도구 (가령 정적 분석 (Static Analysis) 을 잘 하거나 동적 분석을 잘 해서) 가 그런 어려운 것들을 해줄 수도 있겠지만, 그러한 멋진 일들은 돈을 안 들이고 오픈 소스 도구나 자체 개발을 통해서 이루어질 성격의 일들이 아닐 것입니다.
힘들게 짜낸 Effort는 어디다 써야 하는가?
여러 분의 조직은 Agile에 기반해 Regression Test를 잘 하고 있는 조직 (또는 과제)입니까?
여러 분의 과제는 규모가 크고, 기간 또한 넉넉합니까? 아니 테스트를 위한 시간이 충분합니까?
위 두 질문에 선뜻 답할 수 없다면 테스트 자동화는 잠시 미루어두는 것도 나쁘지 않은 것 같습니다.
테스트 자동화를 위한 시간 (Research든, Customizing이든, 새로 개발하든)은 Regression Test가 프로세스에 맞게 주기적으로 이루어질 때 빛을 발 할 수 있습니다.
어떤 논문을 보니 테스트 자동화를 위해 들인 시간은 초기 몇 번의 Regression Test 때는 그렇게 하지 못한 것 보다 시간이 더 많이 들어간다고 하더군요.
즉, WaterFall 모델로 부족한 시간과 인력으로 중.단기에 끝내야하는 과제에서 귀중하게 테스트를 위해 시간과 인력을 할애 했다면 테스트 자동화 보다는 매뉴얼 (수동으로) 로 블랙박스 시스템 테스트를 하는 것이 훨씬 더 효율적일 것입니다.
자동화를 하고 나면 테스트할 시간이 없거나 (대게의 경우 이런 성격의 프로젝트는) 모든 것이 변경되어 테스트 자동화를 새롭게 해야하는 난감한 상황을 맞이할 것입니다.
MS VC++ 개발팀의 테스트 자동화 사례를 소개해드렸듯이, 테스트 자동화는 시간과 노력을 줄여 줄 수 있는 유익하고 중요한 일입니다.
하지만 자동화 노력 이전에, 여러 분 프로젝트의 여건과 자동화를 위해서 얻을 수 있는 것이 무엇인지 먼저 생각해보아야 할 것입니다.
그리고 더 중요한 것은 테스트를 잘하겠다는 의지와 멋진 테스트 케이스일 것입니다.
![[iPhone][Tutorial #5] Http Request결과를 JSON으로 쉽게 파싱 해보기](http://alones.kr/wp-content/plugins/wordpress-popular-posts/no_thumb.jpg){kind=small}