//구글콘솔 광고 추가가

나는 산타를 믿는다. 그렇기에 크리스마스를 매년 기다리고, 어딘가에서 산타는 돌아다니고 있을 거라 확신하며 나름대로의 크리스마스를 즐긴다. 12월에 만나는 나의 주변 친구들에게는 몇 개의 초콜릿과 크리스마스를 기념할 만한 오브젝트를 준비해서 선물 꾸러미를 만들어 선물해 준다. 마치 산타의 조수가 된 것 같은 기분도 드는데, 내가 그런 선물을 준비하는 이유는 선물을 받는 모두가 나처럼 설레는 크리스마스를 보내길 바라는 마음이다. 친구들에게 설레는 기분을 느끼게 해 주겠다는 그 기쁜 마음은 어느덧 12월이 시작되는 첫날부터 대외비로 비밀리에 진행되는, 나 말고는 아무도 모르는 선물 리스트를 작성하고 은밀하게 주문하여 포장까지 완료하는 행동으로 연결된다. 선물을 받는 친구들 중 어느 몇 명은 나에게 크리스마스 편지를 준비해 주는데, 봉투에서부터 크리스마스가 가득 담겨있는 편지를 받아 든 그 순간 딱 이런 기분이 든다. 온갖 연기를 뚫고 굴뚝으로 나온 직후, 산타클로스를 위해 준비해 둔 알록달록한 버터 쿠키를 발견한 기분이랄까.
 
그렇게 12월이 끝나고 산타의 계절 같은 겨울이 지나갈 때쯤, 과연 산타는 나머지 계절을 어떻게 살고 있는 걸까라는 궁금증이 생긴다. 겨울엔 눈사람도 만들고, 썰매도 타고, 키우는 루돌프들에게 각소금도 주면서 산책도 할 테고, 조수들이라고 있는 엘프라거나 요정들이라거나 그 누가 되었든, 조수들과도 함께 이번 시즌의 선물들은 어떤 걸로 구성할 건지, 선물 받을 아이들의 착함 기준치에 대해 토론을 하던지, 나쁜 애들도 구제방안이 있어야겠다거나 이런저런 이야기들도 할 것 같다. 
시즌이 끝난 나머지 계절엔 과연 그들은 무얼 하면서 살 것인가.
 
일단 이 부분에 대해서 예전에 생각해 본 걸 간단하게 말하자면 행정구역 별로 시의원처럼 산타들이 존재하는데 그들이 정년퇴임하기 전에 자신을 이을 산타를 찾아 키운다거나 하는 그런 생각들을 해본 적이 있었다. 산타가 되고자 하는 산타 지망생들을 손수 골라 장학금을 주며 최우수 산타로 키워내는 육성시스템. 자신을 이을 산타를 찾지 못한다면 영원히 퇴직할 수 없는 끔찍한 노동의 현장을 생각한다면, 산타들은 계절과 상관없이 눈에 불을 켜고 열심히 후임을 찾아낼 것이다. 그러다 산타가 되겠다 생각했던 초기의 마음을 저버리고 타락해 버리는 순간이 온다면 그 산타들은 어떻게 해야 할까.
 
이 생각에선 나름 타락한 산타들에 대해 몇 가지 갱생 루트를 생각을 해봤었는데, 대략 3개 정도였다.
우선 타락 산타들이 가장 처음에 해야 할 일은 선물 포장이다. 타락한 마음으로 선물을 전해주는 행동도 어쩌면 아이들에게 부정적인 모습을 보여줄 수 있기에 더 이상 아이들을 만나지도 못하고 선물 공장에 박혀 오로지 선물만 하루 종일 포장만 하며 단순한 일만 반복적으로 하는 것이다. 물론 조수라고 생각했던 포장 전문직들과 함께 해야 하기에 눈치 보며 일을 해야 한다는 게 약간은 정신적으로 힘들 수도 있겠다.
그다음은 빨래하기. 선물 포장을 하면서 내가 왜 타락했을까를 생각해 보는 시간이었다면 "빨래하기"는 감사함을 느껴보는 시간이다. 타락하지만 않았어도 빨래를 할 필요도 없었을 상태에서 주구 장창 내가 입지도 않은, 내가 신지도 않은, 내가 쓰지도 않은 빨래만 해야 하는 상황이 놓인다면 내가 왜 그랬을까라는 생각을 해볼 수 있지 않을까?
일단 산타 하면 생각나는 그들의 전용 출구는 바로 굴뚝. 지금은 다른 출구도 있을 수 있겠지만 어찌 되었든 산타의 옷은 새것 같은 빨간색으로 보여야 하기에 빨래는 필수다. 그리고 무엇보다 수많은 아이들에게 선물을 주기 위해 동분서주 뛰어다닐 산타들을 생각하면 이상하게 발냄새가 날 것 같은 기분이다. 잠자고 있는 아이들을 발냄새로 깨우고 싶지 않다면 양말도 꼭 빨아서 신어야 될 테니 빨래는 필수랄까. 또 루돌프를 생각해 보자. 루돌프가 아무리 산타가 키우는 애완동물이라 해도 야생의 냄새는 어쩔 수 없이 날 테고 그런 루돌프에게 선물을 실어 나르려면 각소금을 얼마나 주면서 꼬드겨야 할지 아찔하다. 바쁜 산타의 입장에서 각소금을 줄 때마다 장갑을 빼고 줄리는 없을 테고, 아마 장갑엔 루돌프 침이 한가득 묻어있을 것이다. 그런 장갑으로 아이들의 선물을 들고 있기엔 청결이 별로일 것 같지 않은 가. 그래서 쉴 새 없이 빨래를 하고 있을 누군가가 필요하지 않을까란 생각을 했다.
마지막은 아이들과 사진 찍어주기. 크리스마스 시즌에 산타 복장을 하고 백화점이나 놀이공원이나 언제나 가짜 산타가 등장한다. 난 그들을 보면서 어쩌면 진짜 산타들이 숨어 있진 않을까란 생각을 했다.
그렇게 아이들과 사진을 찍어주면서 호호호 웃고 있는 산타들을 보며 저 중에 진짜 타락산타들이 있다고 생각하면, 이게 사실 제일 힘들 것 같다.
가뜩이나 타락한 마음이 한가득인데 그런 마음으로 평생을 봐왔을 아이들과 함께 사진 찍어주기라니, 하루라도 표정관리가 안되면 타락 증거자료로 바로 쓰일 수 있는 사진으로도 남을 테고 말 그대로 감정 노동이기에 가장 끔찍한 행동일 것이라 짐작했다. 그렇기에 타락 산타들이 다시 산타로 복귀하기 전 마지막으로 반드시 수행해야 되는 행동이랄까. 이 정도까지 하면 다시 산타로 복귀하기엔 충분할 것 같다.
 
뭐 어쨌든 생각보다 산타라는 지위는 쉽지 않을 것 같다. 딱 한 명만 있을 것 같지도 않고 그렇다고 무수히 많을 것 같지도 않다. 무수히 많은 산타가 있다면 내가 크리스마스에 가족들 말고 진짜 산타에게 선물을 단 한 개도 못 받을 정도로 인생을 막살진 않았기 때문이다. 분명히 엄청나게 바빠서 아직 못 찾아온 것이라 생각한다.
 
언젠가 만날 산타에게. 
난 널 진짜 믿고 있었다. 언젠가 만나자고.

728x90
반응형

테스트 케이스 추가

numbers(long[]) Return
[1001, 337, 0, 1, 333, 673, 343, 221, 898, 997, 121, 1015, 665, 779, 891, 421, 222, 256, 512, 128, 100] [1002, 338, 1, 2, 334, 674, 347, 222, 899, 998, 122, 1019, 666, 781, 893, 422, 223, 257, 513, 129, 101]
2개 이하로 다른 비트 문제

내 코드
using System;
using System.Linq;
using System.Collections.Generic;

//+6
public class Solution {
    public long[] solution(long[] numbers) {
        long[] answer = new long[numbers.Length];
        for (int i = 0; i < numbers.Length; i++)
        {
            string numStr = Convert.ToString(numbers[i], 2);
            int startIndex = numStr.IndexOf("1");

            int zeroPoint = numStr.LastIndexOf("0");
            if (zeroPoint == -1)
            {
                string sub = numStr.Substring(startIndex+1);
                numStr = "10" + sub;
            }
            else
            {
                char[] chArr = numStr.ToCharArray();
                chArr[zeroPoint] = '1';
                if(zeroPoint +1 < numStr.Length) 
                    chArr[zeroPoint+1] = '0';
                numStr = new string(chArr);
            }
            answer[i] = Convert.ToInt64(numStr, 2);
        }
        return answer;
    }
}
728x90
반응형

3월이 된 지 어느덧 20일이 넘어간다. 계절은 참 신기하다.

겨울에서 봄이 되는 그 순간들이 뭐라고 사람들은 봄을 기다린다.

추웠던 온도에 웅크리고 있던 몸이 내 감정보다 먼저 봄을 느끼는지 자연스럽게 입는 옷이 얇아졌다.

 

입춘의 뜻이 봄이 서다는 의미란 걸 알고 있는가?

봄이 서다.

난 봄이 섰다는 생각을 하면서 문득 그런 상상을 하게 됐다.

서있는 봄 곁에 마치 "딱 지금이야!" 하는 것처럼 꽃이 피고 건조했던 모든 식물들이 싹을 피우면서 초록초록해지는 세상.

그걸 바라보고 있는 봄은 무슨 생각을 하고 있을까?

사실 봄의 생각도 궁금하지만 가장 궁금한 건 겨울의 생각이다.

 

내가 가장 좋아하는 계절은 겨울이다.

크리스마스가 있으며, 하얀 눈이 펑펑 내리는 창문을 볼 수 있다는 그 기쁨이 좋다.

그리고 무엇보다 내가 아직 산타를 믿고 있다는 사실이, 겨울을 좋아하는 가장 큰 이유가 되지 않을까 싶기도 하다.

 

겨울의 입장에선 봄이 서있는 그 시간은 삶에서 유일하게 외롭단 생각을 하는 시간이 아닐까?

모두가 자신이 지나가길 바라는 시간이 될까 봐 그런 생각을 하게 된 것 같다.

 

만약 내가 어떤 길을 걸어가고 있는데 그 길에 서있는 모두가 내가 빨리 지나가길 바란다면 아마 나도 모르게 부끄러워져서 빠르게 뛰어가지 않을까.

처음 보는 사이도 아닌데 그럼에도 모두가 날 외면 하는 순간이 온다면 나는 F4처럼 사계절 중 하나라는 중대한 입장에서도 더 이상 계절임을 포기하고 아무도 모르는 곳에 혼자 있고 싶다는 생각을 할 것 같다. 

그렇게 생각하면 겨울이란 계절은 다른 모든 계절들보다 멘탈이 강하지 않을까.

어쩌면 그 길에서 변덕이 생겨서 꽃샘추위라거나 뜬금없는 어느 날, 갑자기 눈이 내리는 광경을 보게 되는 게 아닐까 싶은데, 만약 이유가 그런 거라면 그런 겨울의 모습은 본받을 만한 것 같다.

 

벚꽃이 가득 피고, 싱그러운 바람들이 잔뜩 부는 봄이 된다 해도, 나는 내가 좋아하는 겨울을 다시 기다릴 것 같다.

겨울이 내 마음을 알아주면 참 좋겠다.

728x90
반응형
4.4.2 구조 기반 기법
4.4.2.1 분할 방법으로 접근한 조건 / 결정 커버리지

 - 분할 

   >> 논리적 테스트 컬럼의 각각을 선택한 커버리지로 생성한 모든 논리적 조합으로 분할하여 테스트 케이스를 작성하는 방식.

   >> 모든 조합을 분할해서 나열하기 때문에 결함 원인매우 빨리 발견할 수 있지만 테스트 케이스 수가 크게 증가함.

 - 포함

   >> 논리적 테스트 컬럼의 각각의 선택한 커버리지

   >> 생성한 조합 중에서 단 하나만 선택하여 하나의 논리적 테스트 케이스로 작성하는 1:1 전환 방식(테스트 케이스 줄임)

 - 결정 테이블을 분할로도 만들수 있고 분할돼있는 걸 포함해서 다시 만들어낼 수 있음.

4.4.3 경험 기반 기법
4.4.3.1 오류 추정

 - 테스터가 테스트 할 시스템에 대하여 완전히 이해한다는 전제로 적용되는 기법.

 - 취약점 식별 작업에 기반한 테스트.

 - 테스트 프로세스의 마지막 단계에서 사용.

 - 일반적인 유용성

   >> 테스트에 참고할 명세가 없거나 불충분할 경우, 시간적인 압박이 심한 경우 유용.

   >> 다른 기법이나 공식적인 테스트보완할 때 유용하게 사용.

   >> 가장 심각한 결함을 찾았다는 확신이 필요한 경우 사용함으로써 테스트 프로세스 및 완성도확인하는 기준을 제공.

4.4.3.2 체크리스트

체크리스트

 - 테스팅 절차와 테스트 대상 기능 및 시스템 요소 등을 체크리스트로 작성함.

 - 일반 체크리스트 : 수행해야 할 테스트 목록과 절차를 나열함.

 - 기능(블랙) 체크리스트

   >> 전체 시스템의 최상위 기능 체크

   >> 개별적인 컴포넌트 기능

   >> 서로 다른 레벨의 기능과 그룹핑

 - 시스템 요소 체크리스트

   >> 상위 레벨 서브 - 시스템이나 모듈

   >> 개인 구문이나 데이터 아이템 체크

   >> 서로 다른 레벨의 시스템 요소와 그룹핑 체크

체크 리스트와 테스트 케이스 비교

 - 체크 리스트

   >> 경험과 노하우반영물이어서 테스트를 효율적으로 진행할 수 있음.

   >> 효과성은 없음.

   >> 테스트 베이시스에서 결함을 발견하는 데 주로 사용되어서 정적 테스트기법의 주요 도구 사용.

 - 테스트 케이스

   >> 동적 테스팅의 주요 도구가 됨.

   >> 기법을 적용하여 도출되는 경우가 대부분이고 기법이 보장하는 범위에서 효과성보장해줌.

4.5 테스트 기법의 선택
어떤 테스트 기법을 사용할지 결정할 때 고려할 사항
 - 시스템 유형 및 특징
 - 강제적 표준 또는 법적 기준 적용 여부
 - 고객 또는 계약상의 요구사항
 - 리스크 수준
 - 리스크 유형
 -테스트 목표
 - 문서(베이시스)의 존재 여부
 - 테스터의 지식수준
 - 시간과 예산
 - 테스트 레벨
 - 개발 생명 주기
 - 유즈케이스, 상태 다이어그램 등 개발 설계 모델 존재 여부(있다면 이용, 없다면 새로 만들어)
 - 발견된 결함 유형 등 이전의 경험

테스트 기법을 잘 사용하게 되면...

 - 테스트 전략을 구체적으로 해석해 적절한 기법을 적용

 - 임의로 테스트 케이스를 작성하는 것보다 결함을 발견할 수 있는 효과적인 테스트 케이스 작성 가능(결함 발견율 높아짐)

 - 테스트(케이스)의 높은 재사용성 보장

 - 테스트 강도(커버리지)와 품질에 대한 통찰을 제공

 


4장은 솔직히 시험에선 그렇게 안 중요하데. 시험에 잘 안 나오나 봐.

근데 중요한 내용이긴 하니까 알아두자고.

728x90
반응형

유튜브 김기태의 java를 자바의 sw 테스팅을 보면서 공부를 하고 있는데 아무래도 예전 강의라 그런지 실라버스에 있는 내용과 약간씩 달라지는 내용이 있는 것 같다. 올라와 있는 강의를 다 보고 최신 버전으로 나온 실라버스로 다시 정리를 하면서 공부를 해야겠다. 그래도 이쪽 공부를 새롭게 하다 보니 점점 재밌어지고 있어서 나름 만족감과 즐거움을 느끼고 있다.


4.4.1.2 명세기반 기법 - 페어와이즈 조합 테스팅

페어와이즈 조합 테스팅

 - 페어와이즈 관찰 결과 대부분의 결함이 2개 요소의 상호 작용에 기인하여 나타남.

 - 페어와이즈는 테스트 하는데 필요한 각 값들이 다른 파라미터의 값과 최소한 한 번씩은 조합을 이루게 된다는 것.

 - 3개의 파라미터가 각 5,4,5가지 값을 가질 때 100가지에서 만약 테스트를 100가지 경로로 하게 되면 10000개의 테스트를 실행해야 함 --> 조합을 최소화 함.

페어와이즈 조합 테스팅 기법

* 동작 모드와 설정 파라미터의 각 값들을 중복되지 않게 배열하고, 이퀄라이저의 값을 동작모드와 설정 값과 순차적으로 중복되지 않게 배정하기.

4.4.1.3 직교 배열 테스팅 (거의 잘 안 써서 이런 게 있다 정도로만 알아두면 돼)

직교 배열 테스팅

 - 6-시그마 기법에 이용되고 있으며 소프트웨어 테스트에 적용하여 사용되고 있음.

(6-시그마 : 프로세스의 품질을 개선하기 위한 방법. 결함을 최소화하고 효율성을 높이기 위해 사용되는 통계적인 기법)

 - 직교 배열의 원리를 소프트웨어 테스트에 적용하여 조합의 수를 줄임으로써 테스트 케이스의 수를 합리적으로 줄임.

 - 직교 배열에서 열과 행이 페어와이즈 하다는 것은 직교 배열의 각 행과 열의 조합이 서로 다르다는 것을 의미함.

 - L4(2^3) 

궁금해서 찾아본 < L(런 수)(수준 수 ^ 요인 수) 표기 >
 - L(런 수) = 런 수 = 조합수(라인수) == 배열의 행 수. 즉 생성될 테스트 사례 수
 - (수준 수 ^ 요인 수) = 각 요인의 수준 수 ^ 요인 수
런수 : 조합수(라인수).
요인 : 처리할 수 있는 최대 변수 수로 변환되는 배열의 열 수. (파라미터)
수준 : 단일 요인에 사용할 수 있는 최대 값 수. (값)
ex) L8 설계에는 런이 8개 있음. (2^3) 또는 (2 3)은 수준이 2개인 요인이 3개 있음을 나타냄.
L(런 수)(숫자 ^ 지수 개수 ^ 지수) 형태의 표기인 경우 혼합 수준 설계를 나타낸다.
L18(2^1 3^7)은 설계에 런 18개와 수준이 2개인 요인 하나와 수준이 3개씩인 요인 7개가 있음을 나타낸다.

*참고 자료 - 직교 배열 테스트란 무엇인가.
https://www.guru99.com/ko/orthogonal-array-testing.html

 

 

728x90
반응형
4.3.3 경험 기반 기법(Experience-based)

경험 기반 테스팅
 - 이전에 테스터가 다루었던 유사 어플이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스 추출.
 - 공식적인 방식 아닌 특별한 테스트 케이스를 찾아내고 실행하는 데 유용 -- > 공식적인 기법과 같이 사용해야 효과적
 - 경험에 따라 효율성 및 효과성의 정도가 매우 달라짐(일관성 떨어짐)
 - 테스트 케이스를 문서화함
 - 또 다른 말로 에러 추정(Error guessing) 또는 색적 테스팅(Exploratory Testing) 접근법이라 함

4.3.3.1 탐색적 테스팅 기법

탐색적 테스팅 : 기법이 아닌 접근법
 - 테스트 케이스 작성 시간최소화하고 테스트 엔지니어의 발견적인(heuristic) 지적능력최대한 활용하여 테스트 수행
 - 다른 명칭으로 에드혹, 게릴라, 직관적 테스팅과 유사한 개념
   >> But, 정해진 임무와 목표, 결과물이 존재
 - 테스트를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서 익숙해지는 동시에 테스트를 설계하고 테스트를 계획한다.
   >> 테스트 차터를 기반으로 수행(60 ~ 120분 동안 몰입해서 수행)
   >> 제한된 시간(time-boxing)내에 테스팅의 목적을 정한 후  몰입하여 최소한의 설명 가능한 기록(note)을 남기며 테스트 수행하고, 수행 후 요약보고(debriefing)를 하는 것을 강조.
탐색적 테스팅
 - 경험적인 요소를 많이 반영하고 있는 체계화된 테스팅 접근법
 - 테스트 케이스 작성(문서화)하는데 들이는 노력을 최소화
 - 테스트 설계와 실행 최대화
 - 점진적 & 주기적 테스팅
탐색적 테스팅 절차
 - 제품의 목적 식별
 - 기능 식별
 - 잠재적으로 불안정한 부분 식별
 - 각각의 기능 테스트 및 문제점 기록
 - 일관성 검증 테스트 설계 및 기록
탐색적 테스팅의 구성 요소 (테스터 차터 >> 테스트 노트 >> 타임 박싱 >> 회고)
 - 테스터 차터
   >> 제품의 어느 부분어떻게 테스트하고 어떤 것을 중점적으로 봐야 할지 등을 기록 테스트 명령지
   >> 각 세션에 대해 명확한 임무를 설정
 - 테스터가 수행할 내용
   >> 정확한 리포팅
   >> 유연성 있는 일정 관리
   >> 테스트 방향 정정
   >> 견고한 테스팅
   >> 효율적인 요약 보고
- 테스트 노트
   >> 테스트 실행과 동시에 계획, 설계, 테스트 케이스 작성 --> 노트화 함
   >> 테스트 기록 및 발견 특이사항과 실행시간 등 기재 --> 테스트 케이스
   >> 내용 : 테스트한 제품에 대한 노트 및 기록, 발견한 결함과 장애에 대한 노트 및 기록, 어떻게 테스트하였는지를 기술하는 요약된 문서.
- 타임 박싱(60분 ~ 120분)
   >> 테스트 집중력을 높이기 위해 테스트 시간을 제한
   >> 테스트 시간을 제한하면 집중력이 높아지며, 테스트 일정 수립도 쉬움
- 회고(요약보고 - debriefing)
   >> 테스트 중 발견했던 결함과 이슈사항에 대해 보고
   >> 테스터의 경험과 지식을 공유
   >> 문서화 
테스트 케이스 기반 테스팅과 탐색적 테스팅 비교
 - 테스트 제품을 파악해 가면서 테스트 실시
 - 탐색적 테스트는 테스터의 성향에 많이 의존적임
 - 문서화 정도와 지적 능력의 활용 정도에 따른 비교 

   >> 테스팅 케이스 기반(연설문을 만든다 -문서화하는 능력) - 문서화가 잘 돼있을수록 테스트케이스 기반 테스팅 할 수 있음.
   >> 탐색적 테스팅(경험에 의해 하는거 - 지적 능력) - 지적능력이 있을수록 탐색적 테스팅할 수 있음.
 - 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교 (밑에 표)

테스트 케이스 기반 테스팅탐색적 테스팅
테스터 >> Test Scripts >> 테스터테스터의 테스트 아이디어와 Test Product가 왔다 갔다하는 거.
테스트가 먼저 설계되고 기록된다.
나중에(때에 따라) 다른 테스터가 이를 수행한다.
테스트가 설계됨과 동시에 수행된다. 테스트가 반드시 기록되어야 하는 것은 아니다.
[비유]준비된 연설을 하는 것과 같다. 테스트는 미리 착안된 생각에 따라 수행된다.대화를 하는 것과 같다. 테스트는 아이디어를 반영하고, 생각을 발전시키는 방향으로 수행된다.
테스트의 실행을 관리하는 것이다.(Controling test execution)테스트 설계를 향상 시키는 것이다(Improving test design)
테스트 실행을 시작하기 전에 테스트 케이스를 작성한다.프로젝트 기간 내내 테스트 계획/ 설계와 실행을 반복한다.
(그때 그때 필요할때마다 하는 거)
테스트 문서 작성, 검토에 많은 에너지를 소비함으로써, 테스트의 효율성이 감소하는 경우가 있다.테스트 문서 작성, 검토에 대한 필요성을 최소화하여 보다 많고 복접한 테스트에 상대적으로 많은 노력 투자가 가능하다.
테스터 간의 (특성, 능력) 차이를 제거하려는 노력테스터 간의(특성, 능력) 차이를 십분 활용하려는 노력
테스터가 아닐 수 있는 테스트 설계자가 테스트를 설계한다.테스트 설계자일 수 있는 테스터가 테스트를 설계한다.
완벽하게 한번에 테스팅을 수행한다.점진적이고 주기적으로 테스팅을 수행한다.

리스크 기반 테스팅과 연계한 탐색적 테스팅의 활용
 - 리스크 기반 전략에서의 탐색적 테스팅 접근법 활용 
테스트 전력 수립 시 제품의 리스크가 가장 높은 곳에 탐색적 테스팅을 추가, 그다음 높은 곳에 선택적 탐색적 테스팅 추가. 리스크가 가장 높은 곳에 테스팅 경험이 풍부하고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행하여야 함. 반대로 리스크가 가장 낮은 곳에 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행.
▶ 탐색적 테스팅 효과
 - 경험적 테스팅을 체계화 시킬 수 있음.
 - 테스트 케이스 작성 시간을 줄여 좀 더 많은 테스트 가능
 - 테스터 또는 테스트 엔지니어의 역량을 강화할 수 있음.
 - 적은 테스트 인력으로 많은 테스트를 수행할 수 있음.
 - 명세가 없고 시간 부족인 경우 테스트를 효과적으로 효율적으로 수행할 수 있음.

4.4.1 명세 기반 기법 - 분류 트리 기법

▶ 분류 트리 기법
 - 소프트웨어 일부 또는 전체를 트리구조분석 및 표현하고 이를 바탕으로 테스트 케이스를 도출하는 기법.

 < 분류 트리의 장점 >
1. 시각화해서 테스트 케이스 작성에 용이.
2. 트리 구조이므로 중복되거나 빠지는 테스트없음.
3. 복잡한 시스템이나 어플리케이션의 일부 또는 전체를 테스팅.
4. 개발 설계를 체크하는 용도로 사용이 가능함.
5. 테스트 케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능함.

 
 

728x90
반응형
4.3.1.5 유즈케이스 테스팅

 유즈케이스 테스팅

 - 액터와 액터 사이의 상호작용을 표현 --> 유저에게 결과값 전달.

 - 시스템(SW)이 유즈케이스로 모델링 되었을 때, 유즈 케이스를 활용해 테스트 케이스를 도출하는 테스트 설계 기법.

   >> 유즈케이스를 어떻게 작성하느냐에 따라 유즈 케이스의 테스트 용이성이 달라짐 --> 잘못 만들면 테스팅하기 어려울 수 있음

 - 프로세스 흐름을 기술

   >> 기본 흐름

   >> 대체 흐름

 - 유즈케이스 상세(description) 

 - 시나리오를 짬

 - 프로세스 흐름 기술

 - 유즈케이스를 통해 생성된 테스트 케이스를 통해 시스템이 실제 사용되는 프로세스 흐름에서 결함을 발견하는 데 유용.

 - 고객이나 유저 그룹을 참여시키는 인수 테스트를 설계할 때 유용.

 - 통합 테스트 단계에서 컴포넌트 사이의 통합 결함을 찾는데 도움.

 테스트 순서

 - 유즈케이스 상세를 문장별로 분석하여 테스트 케이스 도출 -- > 누락을 최소화하고 일정 수준의 보장성을 확보

  1.  어떤 흐름을 테스트 할지 고려하여 테스트 시나리오 구성
  2.  유즈케이스 상세에서 테스트에 필수적인 상황 선택
  3.  유즈케이스 상세 내용을 입력값, 출력값, 상황 처리 등으로 분류하여 테스팅에 관여하는 상황을 선택.
  4.  각각의 상황에 ID 부여
  5.  각각의 상황에 가능한 값을 결정

 컴포넌트(단위) 레벨 유즈케이스 테스팅

 - 유즈케이스 각각을 테스팅하는 방법

 시스템 레벨 유즈케이스 테스팅

 - 유즈케이스 상호 간의 활동을 테스트

 - 상태관점에서 파악하고 활동의 흐름을 전이로 간주하여 상태 전이 테스팅 기법의 컨셉을 활용.

   >> 활동 기반 커버리지 : 각각의 활동만을 테스팅

   >> 전이 기반 커버리지 : 활동의 흐름을 테스팅

   >> 경로 기반 커버리지 : 재귀적인 흐름도 고려한 테스팅

   >> 활동 기반 ⊂ 전이 기반 ⊂ 경로 기반 --> 포함관계 존재

4.3.2 구조기반 기법(Structure -based)

 화이트 박스 테스팅 --> 시스템의 구조를 중심으로 테스팅

 - SW코드나 설계  구조를 표현하는 정보로부터 테스트 케이스 도출

 - 작성한 테스트 케이스들로부터 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가

   >> 제어 흐름 테스트, 기본 경로 테스트, x커버리지 테스팅

테스트 레벨과 소프트웨어 구조와의 관계
테스트 레벨 소프트웨어 구조
컴포넌트 레벨 Statements(구문),Decisions(결정) 또는 Branches(분기)등 코드 구조
통합 레벨 콜 트리(모듈간의 호출 구조 다이어그램) 등
시스템 레벨 메뉴 구조, 비즈니스 프로세스 구조, 웹 페이지 구조 등
 - 구문 커버리지 (statement coverage)
   >> 테스트 스위트(테스트 케이스 모아둔 거)에 의해 실행된 구문이 몇 퍼센트(%)인지 측정(가장 약함)
 - 결정 커버리지 (decision coverage)
   >> 실행된 결정 포인트 내의 전체 조건식 최소한 참이 한 번 그리고 거짓이 한 번씩 선택되었는지 측정하여 퍼센트로 표현
 - 조건 커버리지
   >> 전체조건식의 결과와 관계없이 각 개별 조건식 참 한번, 거짓 한 번을 모두 갖도록 개별조건식을 조합 (결정 커버리지 보다 강력) 
4.3.2.1 구문 테스팅과 커버리지

 구문 커버리지

 - 테스트 스위트에 의해 실행된 구문이 몇 퍼센트 인지 측정

   >> 존재하는 가능한 경우를 모두 검증 못하는 보장성이 낮은 커버리지

 - 구문 테스팅은 구문 커버리지를 늘리기 위해 특정 구문을 테스트하는 테스트 케이스 도출

   >> 코드의 모든 구문을 실행할 수 있는 입력값이나 이벤트 등의 테스트 데이터를 제공해 주면 달성됨.

4.3.2.2 결정 테스팅과 커버리지

 결정 커버리지

 - 분기 테스팅과 관련

 - 테스트 스위트(suite, 묶음)에 의해 실행된 조건문 분기 (if문의 참/거짓)가 전체 가능한 분기의 몇 퍼센트인지를 측정하고 평가

 - 결정 포인트 내의 전체조건식이 참과 거짓의 모든 값을 갖게 되어 모든 분기로 흐르게 되면 달성

  결정 테스팅

 - 결정 커버리지를 늘리기 위해 특정 조건문의 분기를 테스트하는 테스트 케이스를 도출하는 것

 - 제어 흐름 테스트

 제어 흐름 테스트

 - 구조 기반 테스트 --> 코드 레벨의 커버리지 개념 필요

 - 프로그램 구조 테스트

 - 공식적인 화이트 박스 테스트 -- > 단위 / 통합 테스트에서 사용

   >> 테스트 깊이 레벨에 따라 강도 존재

   >> 테스트 케이스를 선택된 흐름에 따라 연속적인 구문의 집합으로 기술

   >> 테스트 깊이가 깊을수록 제품의 커버리지는 높아지는 반면 테스트 케이스가 기하급수적으로 많아져 비용, 시간, 리소스 많이 소요됨.

4.3.2.3 조건 테스팅과 커버리지

 조건 커버리지

 - 결정 포인트 내에 있는 개개의 개별 조건식이 참 / 거짓의 모든 값을 갖게 되면 달성

 - 조건 커버리지(강력, 견고한 테스트) > 결정 커버리지

 조건/ 결정 커버리지(응용버전)

 - 항상 결정과 조건 커버리지를 모두 만족시키는 것보다 강력

 - 결정과 조건 커버리지를 최소한 조합으로 달성하는 경우

   >> 항상 모든 개별 조건식이 참이고 이에 따른 전체 조건식이 참인 경우

   >> 모든 개별 조건식이 거짓이면서 이에 다른 전체 조건식이 거짓인 경우

 커버리지 레벨(depth level) - 밑으로 갈수록 완화됨

 - 다중 조건 커버리지(Multiple condition coverage) -- > 가장 강력

   >> 결정 포인트 내의 개별 조건식 결과(참/거짓)에 대한 모든 가능한 논리적인 조합을 적어도 한 번 수행.

 - 변형 조건/ 결정 커버리지(MC/DC)

   >> 결정 포인트 내에 다른 개별 조건식의 결과와는 독립적으로 해당 개별 조건식이 전체 조건식의 결과에 영향을 줌.

 - 조건/ 결정 커버리지 (COndition/ decision coverage)

   >> 모든 개별 조건식이 전체 조건식 판단문의 결과값 확정에 관여하는 경우를 모두 고려함.

 - 조건 커버리지(Condition coverage)

   >> 프로그램 내에 있는 결정 포인트 내의 모든 각 개별 조건식에 대한 모든 가능한 결과(참/ 거짓)에 대해 적어도 한번 수행.

 다중 조건 커버리지

 - 결정 포인트 내에 있는 모든 개별 조건식의 모든 가능한 논리적인 조합을 고려하여 100% 커버리지를 보장

 - 출시 전 모든 결함을 제거해야 하는 제품 테스트에서 주로 사용. 

4.3.2.4 변형 조건/ 결정 커버리지(MC/ DC)

 변형 조건 / 결정 커버리지(Modified Condition/ Decision)

 - 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함

 - 조건/ 결정 커버리지를 향상 시킴

 - 조건 커버리지나 결정 커버리지 보다 강력

   >> 프로그램에 있는 모든 결정 포인트 내의 전체 조건식은 적어도 한 번 모든 가능한 결과값(참, 거짓)을 취한다.

   >> 프로그램에 있는 결정 포인트 내의 모든 개별 조건식은 적어도 한번 모든 가능한 결과값(참,거짓)을 취한다.

   >> 결정 포인트에 있는 각각의 개별 조건식은 다른 개별 조건식에 영향을 받지 않고 그 결정 포인트의 결과값에 독립적으로 영향을 준다.

 - 가능한 의미 있게 조합의 수를 줄여 테스트 수행.

 

 

 

728x90
반응형
4.3.1.4 상태 전이 테스팅

상태 전이 테스팅 (state trasition)

 - 이벤트, 액션, 상태, 가드, 상태전이 사이의 관계를 검증.

 - 시스템/SW의 상태 기반 행위가 명세화(글자로 쓰여있던)된 내용과 일치함을 검증.

 - 상태기반 시스템의 결함은 상태, 상태전이, 가드, 이벤트 결함 등으로 분류.

 - "구현이 잘못된 경우"와 "명세가 잘못된 경우"의 결함으로 구분.

 - 모델(명세)상의 결함 -- > 인스펙션, 정적 분석으로 결함 발견.

   >> 초기 상태 누락

   >> 전이 또는 액션의 누락

   >> 가드를 "전이" 대신 상태에 표기

   >> 가드의 중복 또는 불일치

 - 구현상의 결함 -- > 테스트를 통해 결함 발견

   >> 여분/ 누락/ 훼손 상태(extra/ missing/ corrupt state)

   >> 액션이 틀리거나 누락됨

   >> 스니크 패스(sneak paths), 트랩 도어(trap doors)

      - 설계할 때 의도하지 않았으나 발생하여 정상적인 작동에 손상을 주는 경로.

  • 상태 다이어그램 표기법
구성요소 설명 표기법
상태 하나 또는 그 이상의 이벤트를 기다리는 시스템의 독립적인 모드 원으로 표기, 원안에 상태명 표시
전이 이벤트에 의해 현 상태에서 다른 상태로의 이동 또는 변경 화살표 형태의 선(link)으로 표시하며 상태와 상태를 연결함
이벤트 상태의 전이를 유발하는 요인 전이와 같이 표시하며 이벤트 이름을 표시함
(eg.ev 취소 >> 취소 이벤트)
가드 상태 전이 조건 이벤트와 함께 표시,'[ ]' 안에 조건이나 값으로 표시
(eg. ev 금액투입 [투입금액 < 가격] )
액션 상태 전이와 함께 시스템 또는 소프트웨어가 동작하는 행위나 출력 이벤트 뒤에 ' / '로 구분 후 표시
(eg. ev 음료 버튼 선택 / 잔액 반환() )

  • 상태: [대기], [금액 투입], [음료 선택]
  • [대기] 이벤트 : ev 금액투입[투입금액 < 가격], ev 금액투입[투입금액 >= 가격]
  • [금액 투입] 이벤트 : ev 취소, ev 금액투입[투입금액 >= 가격], ev 금액투입[투입금액 < 가격]
  • [음료 선택] 이벤트 : ev 취소, ev 음료버튼 선택

상태전이 테스트 케이스 절차

  1. 상태-이벤트 테이블 구성
  2. 전이 트리 구성
  3. 반응(Legal, 또는 유효(Valid)) 테스트 케이스 구성
  4. 무반응(Illegal, 또는 비유효(Invalid)) 테스트 케이스 구성
  5. 가드(Guard) 또는 조건 테스트 케이스 구성
  6. 테스트 프로시저(Test procedure) 구성

자판기로 상태전이 테스트 케이스를 알아보자.

1. 상태-이벤트 테이블

이벤트 상태 대기 금액 투입 음료 선택
ev 금액투입 [투입금액 >= 가격] 음료 선택 음료 선택  
ev 금액투입 [투입금액 < 가격] 금액 투입 금액 투입  
ev 음료버튼 선택     대기
ev 취소   대기 대기

* 동일한 이벤트지만 가드가 다르면, 서로 다른 이벤트로 구분해 상태-이벤트 테이블을 작성한다.

 

2. 전이 트리 구성

3. 반응(유효) 테스트 케이스

Valid TC 시작 상태 이벤트 액션 다음상태 이벤트 액션 종료상태
V001 대기 ev 금액 투입
[투입금액 >= 가격]
*투입금액 :1000
-
라이트 셋
음료선택 ev음료 선택 캔 방출, 잔액 반환(300), 잔량 업데이트(9), 라이트 리셋 대기
V002 대기 ev금액 투입
[투입금액 >=가격]
*투입금액:1000
-
라이트 셋
음료선택 ev 취소 투입금액반환(1000), 라이트리셋 대기
V003 대기 ev 금액 투입
[투입금액 < 가격]
*투입금액 : 500
- 금액투입 ev금액 투입
[투입금액 >= 가격]
* 투입금액:500
라이트 셋 음료 선택
V004 대기 ev 금액 투입
[투입금액 < 가격]
*투입금액 : 500
- 금액투입 ev금액 투입
[투입금액 < 가격]
*투입금액:100
  금액 투입
... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ...
V015 금액투입 ev 취소 투입금액 반환 대기 ev 금액 투입
[투입금액 >= 가격]
*투입금액 : 5000
- 음료 선택
V016 금액 투입 ev 취소 투입금액 반환 대기 ev 금액 투입
[투입금액 < 가격]
*투입금액:100
- 금액 투입

* 음료가격 700원으로 가정

 

4. 무반응(비유효) 테스트 케이스

ID 사전 조건 상태 이벤트 기대결과
IV001 V001 대기 ev 음료 버튼 선택 -
IV002 V001 대기 ev 취소 -
IV003 V004 금액 투입 ev 음료 버튼 선택 -
IV004 V003...V015 음료 선택 ev 금액투입[투입금액 >= 가격]
*투입금액 :1000
-
IV005 V003...V015 음료 선택 ev 금액투입[투입금액 < 가격]
*투입금액 : 100 
-

불가능한 상황들을 만들어서 테스트를 해보는 것.

 

5. 가드 테스트 케이스

ID 사전 조건 상태 이벤트 조건[가드] 기대결과
G001 V004 대기 ev 금액투입
* 투입금액: 100원
투입금액 = 음료가격
(투입금액= 700원)
음료 선택
G002 G001 음료 선택 ev 금액투입
* 투입금액:100원
투입금액 >= 음료가격
(투입금액= 800원)
음료 선택

* 음료가격 700원으로 가정 / 조건에 따라 기대결과가 달라짐.

 

6. 테스트 프로시저 구성  ( *가능한 겹치지 않으면서 내가 할 수 있는 모든 테스트 케이스를 만들어야 돼. )

  • TP1 = V001 -> IV001 -> IV002 -> V002 -> V003 -> V006 -> V007 -> V010
  • TP2 = V004 -> IV003 -> V011 -> V005
  • TP3 = V008 -> V009 -> V013 -> V016 -> V012
  • TP4 = V014 -> V004 -> G001 -> G002
  • TP5 = V015 -> IV004 -> IV005

 

728x90
반응형

+ Recent posts