안녕하세요 QA 인데 qa자료가 제일없는거 같아서 조금 그렇네용...



오늘은 IE11버전 이하 IE 10버전 부터 발생하는 이슈 중 특이한 이슈가 있어서 작성하게 되었습니다.


시작은 즉슨 .. IE 9 버전에서 기능이 이상합니다.! 라는 이야기와 함께 찾아봤습니다.


준비물


window.onbeforeunload  && a 태그와 href 속성


요약 

a태그가 눌릴때마다 window.onbeforeunload 가 호출되는 현상 IE 구버전에서 발생하게됩니다.


내용 

<a href="javascript:pay();" class="btn_b btn_red"><span>결제하기</span></a>


 와 같은 코드가 있을때


해당 DOM 에 만약에 window.onbeforeunload 가 들어가 있을 경우


해당 a태그가 클릭될때마다 onbeforeunlaod에서 작성된 함수가 계속 실행됩니다.


노답 버그!


해결법

1번 href를 쓰지 말고 onClick 을 사용합니다. 


2번 의 경우는 오류가 났던 사이트 개발자 분이 직접 이렇게 사용하여서 해결했다고 합니다. 


jQuery 를 사용한 방법인데요


$(window).data('beforeunload',window.onbeforeunload);

     $('a[href^="javascript:"]').hover( 

        function(){window.onbeforeunload=null;},

        function(){window.onbeforeunload=$(window).data('beforeunload');}

    );

약간의 꼼수(?) 느낌으로 이렇게 해결했다고하네요


약간의 설명이들어가자면     $('a[href^="javascript:"]').hover( 

는 a태그중 href속성에서 javascript: 로 시작하는 모든속성에 대한 .hover 작업입니다.


아래의 hover 속성에 보면 param 으로 2개가 들어가있죠 , 로 나눠져있는걸 보면


jQuery 를 안쓰는 요즘 분들? 또는 jQuery 자체를 안쓰시는 분들은 이해가 안되실수도 있으니


jQuery doc를 확인해보면


.hover( handlerIn, handlerOut )


이렇게 되어있습니다.


말그대로 들어올때, 나갈때인거죠 


클릭하기위해서 마우스가 올라왔을때 window.onbeforeunload를 빼버립니다. 그리고 클릭하면서 href가 실행된 후


밖으로 나갈때 다시 원래의 값을 붙여줍니다. 



부족한 글 읽어 주셔서 감사합니다.~




'QA > QA 활동' 카테고리의 다른 글

QA 업무 중 자료 구조?  (0) 2019.01.28
좋은 테스트 코드 및 테스트의 특성  (0) 2018.11.15
Daily note  (0) 2016.09.28
윈도우즈 GPT Convert MBR  (0) 2016.07.05
Back ground 쉘  (0) 2016.06.21

안녕하세요 오늘은 제가 테스트 하는 툴중에 Windows Application 이있는데


사용하다보니 자꾸 느려지고 (오래 사용도 안했는데) 이에 대한 케이스도 정확하지 않고



매번 연구소에다가 


" .. A작업 하다가 느려지는거같아요 .. 이부분 확인 좀 .. 부탁 드릴게요 .."


".. A하다가 -> B하고 D하면 느려지는거 같은데요?? "


아 이런거는 뭔가 내가 생각해도 사용자가 제품 쓰고 Q&A 하는 느낌이였다.


아 물론 QA활동 중 에 사용자 경험을 위주로 하는 활동도 있기 때문에 틀린 행동이나 작업은 아닌데


QA라면 뭔가 더 전문적이여야 하지않을까


"A작업시에 갑자기 heap memory 가 튀는거 같은데  이부분 동적 할당 (malloc) 처리가 제대로 됐는지 코드 확인 부탁 드립니다."


아.. 너무 좋은거같네요 뭔가 일한 느낌


메모리 는 Heap 만 생각 하겠지만


생각보다 더 복잡 합니다. 


그래서 메모리 모니터링툴을 하나씩 찾아서 포스팅 할 예정인데


가장 먼저 나오는


Windows VMMap 을 사용해보려고 합니다.


해당 모니터링 해주는 트리는 되게 많습니다.


Image, 

Mapped File

Shareable

Heap

Managed Heap

Stack

Private Data

Page Table

Unsuable

Free


제대로 사용하려고 마음먹었다면 위의 메모리 저장소나 관리 사용 하는 위치 등에 대해서 자세하게 쓸 것 같은데


결론적으로는 저는 이 툴 사용은 안하기로했습니다.


사용시간은 2시간 내외 입니다. (처음 사용시 최소한의 모니터링은 할수 있어야 된다고 생각 합니다.)


1. Interval 형식으로 View를 해주지 않습니다.


물론 옵션은 있습니다. Options -> Trace Snapshot Interval - [1 Second], [ 2 Second ] 5 10 등등

그런데 이게 되는건지 확인이 잘 안됩니다. 우측 하단에 Trace.. 라는 메뉴가 있긴한데 따로 출력되거나 입력

되는것도 있지 않고 여튼..  계속 확인하려면 F5키를 눌러줘야되는데 실시간 모니터링 해주는 다른 툴이 있을거라

생각합니다. ... (후)


2. 메모리 사용량이 너무 높습니다.

아니 메모리 모니터링 하는 툴이 메모리 사용량이 기하학적으로 높아집니다. 

인터벌로 뿌려주는것도 아니고!

제가 사용하는 램이 16G를 쓰는데 이거 혼자서 14G까지 먹습니다. 20분 정도 틀었을시에

메모리 분석하는 툴이 메모리 누수가 있다니요 (추측)  별론거 같아요 Windows 7 64비트 기준입니다.

분석 결과 보기전에 제 PC가 죽겠습니다.

(시나리오 확인결과 현재 메모리 확인이 안되니까 -> F5로 새로고침해서 확인할때마다 누수가 발생.. 하는것 같습니다.)


메모리 사용값 분석해서 화면에 뿌려주는  툴이 용량이 이렇게 올라가는건 좀 아닌거 같아요 ㅋㅋㅋ

3. ETC

잠깐만 썻지만 뭔가 사용성에는 적합하지 않다고 생각합니다. (QA입장에서)

개발자 입장에선 나쁘지않을것 같은게 메모리 leak 이 의심되는 구간에 대한 코드를 돌리기전에 한번 확인하고

돌린 후에 확인시에 메모리 변동 추이는 확실하게 확인이 가능하니까요 

하지만 사용성을 확인하면서 메모리 튀는 부분을 확인하는 QA 입장에선 별로 좋다고는 못 느껴서 일단 다른 툴들을

찾아 보도록 하겠습니다. (다른게 더 별로면 VMMap 으로 돌아올수도있고.. )


정말 없으면.. 모니터링해서 숫자로 표현하는 정도는 뭐.. 만들어서 쓰죠 


글 읽어주셔서 감사합니다.









'QA > 테스팅 관련 툴' 카테고리의 다른 글

vscode remote 사용 후기  (0) 2018.06.27
UNIX signal  (0) 2016.07.15
QA_테스팅의 종류  (0) 2016.06.21

2018년 7월 25일 크롬 68 버전이 업데이트 되었습니다. (Stable)버전이죠


not Stable 버전인 Dev 버전은 지금 69.0.3497.12 for Windows, Mac and Linux라고 표기되어있네요


그래서! 오늘은 68버전에 뭐가 변경되어있나 확인해보려고 합니다.


우선


크롬 패치에 대한 로그 사이트입니다.


// 크롬 로그 사이트 69 버전이기 때문에 참고만 하시는게 좋을것 같습니다.

https://chromium.googlesource.com/chromium/src/+log/69.0.3493.3..69.0.3497.12?pretty=fuller&n=10000


우선 68버전의 공식 명칭은


Chrome 68.0.3440.75 이며 해당 에 대한 수정 사항은 위의 로그를 통해서 확인할수 있으며


Chrome 또는 Chromium 블로그 에서  68에 대한 기능 및 큰 변화들을 제공하기 떄문에 참고 하여도 좋을 것 같습니다.


1. HTTP Sites Marked as 'Not Secure'


대표적인 안건으로 되어있네요 SSL(Secure Socket Layer) 를 입히지 않은 사이트에 대해서는 Not Secure 마크를 붙이겠다 라는 거같습니다. 68버전 부터는 이제 안전하지 않은 사이트로 취급이 되겠네요 제 티스토리도 마찬가지...


크롬 블로그 내용 입니다.


'Chrome 68 에서는 모든 HTTP 페이지에 대한 Not Secure("안전하지않음") 이라는 마크를 붙일 겁니다. 그리고 이에 대한 해당 내용은 2월 8일 의 Google Chromium 및 ONline Security 블로그에 게시하여 이를 발표 하였습니다.'


'또한 Chrome에서 보안되지않음 (Not Secure) 경고 페이지를 보지 않기 위해서는 HTTPS로 마이그레이션 하는것이 좋습니다. HTTPS는 SEO,광고 수익 및 실적 영향등 문제를 해결해 줍니다.' 


라네요


이미 공표 된 패치였나보네요


** 업뎃 하니 나타납니다.






2. Security Fixed and Rewards


이외의 자잘한 보안 수정 관련 로그입니다. 약 42개의 보안 패치를 적용 하였으며 


// 해당 내용은 아래의 URL에서 보안 패치에 대한 내용을 읽을수 있습니다.

https://sites.google.com/a/chromium.org/dev/Home/chromium-security



여기까지는 Google Chrome 블로그에 게시된 내용이였으며


New in Chrome 68  로 게시된 개발자 사이트에서 변경된 점을 포스팅하려 합니다.


대표적인 카테고리 부터 보고 들어가자면


Add to Home Screen behavior


Page Lifecycle API


Payment Handler API


3가지가 있겠네요  해당 내용은 크롬 개발 도구창에 들어가면 나타납니다.



1. Add to Home Screen changes


정해진 웹사이트가 Chrome에서 지정한 추가 기준을 충족시에는 홈 화면에서 추가 배너가 나타나지 않습니다.


또는 사용자에게 언제 어떻게 프롬프트 창을 표시할지도 정할수 있습니다.



* 사용자에게 프롬프트 창을 표시하기 위해서는 beforeinstallprompt 이벤트를 리스너로 추가한 후에


버튼 또는 UI요소를 추가하여 설치 가능 여부를 나타낼수 있습니다.


// 프롬프트 코드 


let installPromptEvent;

window.addEventListener('beforeinstallprompt', (event) => {
  // Prevent Chrome <= 67 from automatically showing the prompt
  event.preventDefault();
  // Stash the event so it can be triggered later.
  installPromptEvent = event;
  // Update the install UI to notify the user app can be installed
  document.querySelector('#install-button').disabled = false;
});





해당 에서 ADD버튼을 클릭하게되면 beforeinstall 이벤트에서 prompt를 호출시 Chrome 에 홈 화면 추가 대화상자가 표시됩니다.



btnInstall.addEventListener('click', () => {
  // Update the install UI to remove the install button
  document.querySelector('#install-button').disabled = true;
  // Show the modal add to home screen dialog
  installPromptEvent.prompt();
  // Wait for the user to respond to the prompt
  installPromptEvent.userChoice.then(handleInstall);
});






이에 대한 자세한 내용에 대해서는


사이트를 참조 바랍니다. 풀 코드가 있습니다.

// 홈 화면 배너 관련 

https://developers.google.com/web/updates/2018/06/a2hs-updates



2. Page Lifecycle API


페이지 라이프 사이클 관련 API 입니다. 이에 대한 해당 내용은 좀더 분석하고 따로 한번 더 포스팅 하도록 해야 될거 같아서 따로 하겠습니다.


러프하게 말씀드리자면




(이미지를 누르시면 원본으로..)


FROZEN -> HIDDEN 부분에 보시면 resume 과 freeze라는 개념이도입되었습니다. 


크롬 사이프 사이클 중 freeze -> resume -> freeze가 가능하게 되어있네요 무슨 의미인지는 모르겠지만 좀더 봐야겠네요


내용 전문입니다.


"사용자가 다수의 탭을 실행하게 되면 메모리,CPU,배터리 및 네트워크와 같은 중요한 리소스가 과도하게 발생할수 있기 때문에 사용자 환경은 매우 좋지 않습니다."

"만약에 사이트가 백그라운드에서 실행 중이면 시스템 리소스를 절약하기 위해서 사이트를 일시 중지 할수 있습니다.

새로운 Page LifeCycle API 를 사용하면 이러한 이벤트를 수신 및 응답이 가능합니다."


"예를 들면 잠시 동안 백그라운드에서 탭이있는 경우 브라우저를 해당 페이지에서 스크립트 실행을 일시 중단하여 리소스를 절약 할수 있습니다."


" 그전에 Freeze 이벤트를 실행하여 열려있는 IndexedDB 또는 네트워크 연결을 닫거나 저장하지 않은 보기 상태를 저장할 수 있습니다. 그 후 -> 사용자가 탭을 다시 초점 맞추면 다시 시작 이벤트가 발생하여 해체된 항목을 다시 초기화 할수 있습니다."


// 관련 freeze -> resume 코드 


const prepareForFreeze = () => {
  // Close any open IndexedDB connections.
  // Release any web locks.
  // Stop timers or polling.
};
const reInitializeApp = () => {
  // Restore IndexedDB connections.
  // Re-acquire any needed web locks.
  // Restart timers or polling.
};
document.addEventListener('freeze', prepareForFreeze);
document.addEventListener('resume', reInitializeApp);




이와관련 된 문서가 있습니다.


// Page Lifecycle API doc

https://developers.google.com/web/updates/2018/07/page-lifecycle-api

// Page Lifecycle 1 Spec

https://wicg.github.io/page-lifecycle/spec.html

// 해당 git hub

https://github.com/WICG/page-lifecycle



3. Payment Handler API


표준 방식의 결재를 받아들이는 결재 관련 요청 API 가 오픈되었습니다. 


결재 API 는 웹 기반 결재 응용 프로그램이 결재 환경에서 직접 결재 할수 있도록 용이하게 함으로 결재의 범위를 확장합니다.


크롬팀에서 이렇게 말하네요

"기존의 웹 에 결재 기능을 추가하는 것은 supportedMethod 등록 정보에 항목 추가하는 것 만큼 쉽습니다."


// 관련 결재 코드 



const request = new PaymentRequest([{
  // Your custom payment method identifier comes here
  supportedMethods: 'https://bobpay.xyz/pay'
}], {
  total: {
    label: 'total',
    amount: { value: '10', currency: 'USD' }
  }
});




결재 를 처리할수 있는 서비스 워커(Service Worker) 가 설치되면 결재관련 UI가 나타나며 사용자는 결재를 할수 있습니다.


이와관련하여서 Eiji 는 훌륭한 내용을 담고 있습니다.


// Eiji URL 

https://developers.google.com/web/updates/2018/06/payment-handler-api



이번 내용은 너무 광범위해서 포스팅을 러프하게 가져오는 정도로는 애매한거 같네요 시간이 된다면 꼭 LifeCycle 관련은 한번 더 쓰려고 합니다.


감사합니다





simple-ftp ( 파일 전송 X 다운로드 X)


사용불가



sftp(사용자가 가장 많음)


폴더 채로 전송시 잘되지 않음 sync 문제도 맞춰지지않음


json 파일은 읽어오지 못함


사용X


이클립스 Remote 보다 나은건 아직 못찾음


(파일다운로드 O 업로드 O 마우스 드래그로 가능 실시간 적용 , 권한 적용 여러 창 분할 가능)




더 좋은 remote 사용 툴 있으면 추천 좀 부탁드립니다.



안녕하세요 오늘은 Chrome 64 업데이트 노트 에 대해서 확인해보려고합니다.


** 해당 내용은 아래의 URL에 전부 다 나와있는 내용입니다.

Update Release Note URL

https://developers.google.com/web/updates/2017/11/devtools-release-notes



2018년 1월 19일 에 업데이트 되었으며 크게 바뀐점은


1. Performance Monitor : 페이지 성능을 실시간으로 확인


2. Console Sidebar : 콘솔에 필요없는 것들은 줄이고 중요 한 메시지들에 집중


3. Group Similar Console message : 유사한 콘솔 메시지들에 대한 그룹화 


** chrome://version/ 을 url에 입력하면 Chrome 버전에 대한 정보가 나타납니다. 


확인 후 진행시 가장 최 상단에


Chrome64.0.3282.119 (공식 빌드) (64비트) (cohort: 64_119_win)

이와 같이 나타납니다. 



1. Performance Monitor 


성능 테스트를 하고 싶은 페이지를 Chrome으로 접속 후 F12(개발자 도구창)


을 연 후에


Ctrl + Shift + P 를 누릅니다.



해당과 같은 창이 나타나게 되는데 이부분에서 Performance Monitor를 검색하게 되면 



해당메뉴가 나타나며 엔터를 치게 되면 개발자 도구창 하위에




해당과 같은 성능 모니터링이 나타나게 됩니다.


현재는 무난하지만 특정 이벤트를 마구 지정해보겠습니다. ( 해당 사이트에 )


특정 데이터를 실시간으로 받아서 차트 2개를 그리는 작업을 하였습니다.


CPU Usage 가 순간적으로 올라가는 것이 확인됩니다. 아직 무리가 되는 작업은 아닌것으로 보입니다.


앞으로 Chrome 브라우저에서의 성능은 이것으로 확인하면 될것 같네요 


**





Ctrl + Shift + P 를 누른 후에 


FPS를 입력하게 되면 해당 페이지 창에서 해당과 같은 화면도 같이 확인이 가능합니다. 


2. Console SideBar


개발하다보면 Console.log Console.warn Console.error 등을 많이 사용하게 되는데


해당사용에 대한 편리함을 제공 해줍니다.




해당 빨간줄을 클릭하게되면



해당과 같이 콘솔 사이드 바를 통해서 원하는 콘솔 오류만 골라서볼수 있게 됩니다.




3. Group Similar Console messages


많은 유사 메시지들이 나타나는 것들에 대해서 묶어서 보여주게 되는 기능이며 아래 와 같은 체크 메뉴로 enabled disabled 가 가능합니다.


enabled 시에 묶여있는 메시지들을 클릭시에 Expand 도 가능하니 참고 바랍니다.







**   CSS3 Hover Effects



transition :box-shadow  0.2s;   참조 



해당 에러는 해당 push 하려는 branch 가 Protected로 설정 되어있기 때문에가 많습니다.


대부분 의 경우는 Master Branch 가 이런 경우가 많고 


아니면 다른 브랜치에 대한 Permission 을 주는 경우가 이에 해당되는데


사용중인 Project 에 들어가서 해당 Protected를 해제 하거나 권한을 설정 하면 됩니다.



- GitLab Project -> Settings -> Repository -> Protected Branches -> [Expand] 버튼 클릭


하단에 Protected Branches  리스트에 우측 UnProtected를 클릭 혹은


Allowed to merge   Allowed to push 에서 권한을 설정 한다.






Unicode - 문자 하나당 2바이트의 공간을- 확보

멀티 바이트 : ANSI 에서는 1바이트 공간을 다국어에서는 2바이트의 공간을 확보

영어는 1바이트 한글은 2바이트를 사용 한다.

char , wchar_t ,TCHAR

유니코드상에서 char을 쓰면 문제발생 한문자를 쓰는데 2바이트를 사용하므로

char는 문자 하나당 1바이트 한문자를 쓰지만 실제는 2바이트를 쓰기때문에 글자가 깨져서 나온다.

멀티바이트상에서는 wchar_t 를 사용 할 떄 문제가 발생한다.

wchar_t는 한글자를 쓰는데 2바이트를 사용하므로 영어를 담고있다면

영어는 멀티바이트상에서 1바이트만 표현이 가능하므로 나머지는 0으로 채워진다.

그런데 멀티바이트에서는 NULL 로 인식하기 떄문에 영어 한글자만 출력이 된다.


TCHAR는 멀티바이트상에서는 char로 유니코드상에서는 wchar_t로 바뀐다.

wchar_t를 사용할 경우 앞에 L(매크로)을 붙여준다.


async 파일시스템에 대한 I/O가 비동기적으로 이루어짐

// 비동기 ; 이벤트 큐에 추가된 후 실행이 된다. 

sync 파일 시스템에 대한 I/O가 동기적으로 이루어짐 

// 동기 호출의 끝날때까지 블록 상태를 유지한 후 스레드로 제어가 넘어온다.

메인 이벤트 스레드를 블록하거나 너무 많은 백그라운드 스레드를 실행할 경우 성능의 저하를 가져올 수 있다.  // sync의 경우에는 지속적으로 읽거나 쓰기를 반복할때 최적의 효과를 보여준다.

.core 덤프를 찾기 위해서


ulimit -c unlimited 를 실행하게 되면 core가 떨어지게 되며 해당 코어에 대해서 gdb 실행 실행.core 로


segv를 확인할 수 있다.


1. SIGHUP: 연결된terminal이hangup하였을때(terminate)

2. SIGINT: interrupt key(^C)를입력하였을때(terminate)

3. SIGQUIT: quit key(^\)를입력하였을때(terminate+core)

4. SIGILL: illegal instruction을수행하였을때(terminate+core)

5. SIGTRAP: implementation defined hardware fault (terminate+core)

6. SIGABRT: abort시스템호출을불렀을때(terminate+core)

7. SIGBUS: implementation defined hardware fault (terminate+core)

8. SIGFPE: arithmetic exception, /0, floating-point overflow (terminate+core)

9. SIGKILL: process를kill하기위핚signal, catch 혹은ignore될수없는signal임(terminate)

10. SIGUSR1: user defined signal 1 (terminate)

11. SIGSEGV: invalid memory reference (terminate+core)

12. SIGUSR2: user defined signal 2 (terminate)

13. SIGPIPE: reader가terminate된pipe에write핚경우발생(terminate)

14. SIGALRM: alarm시스템호출후timer가expire된경우(terminate)

15. SIGTERM: kill시스템호출이보내는software termination signal (terminate)

16. SIGCHLD: child가stop or exit되었을때parent에게전달되는신호(ignore)

17. SIGCONT: continue a stopped process (continue/ignore)

18. SIGSTOP: sendable stop signal, cannot be caught or ignored (stop process)

19. SIGTSTP: stop key(^Z)를입력하였을때(stop process)

20. SIGTTIN: background process가control tty로부터read핛경우(stop process)

21. SIGTTOU: background process가control tty로write핛경우(stop process)

22. SIGURG: urgent condition on IO, socket의OOB data (ignore)

23. SIGXCPU: exceeded CPU time limit (terminate+core/ignore)

24. SIGXFSZ: exceeded file size limit (terminate+core/ignore)

25. SIGVTALRM: virtual time alarm, setitimer, (terminate)

26. SIGPROF: profiling time alarm, setitimer, (terminate)

27. SIGWINCH: terminal window size changed, (ignore)

28. SIGIO: 어떤fd에서asynchronous I/O event가발생하였을경우(terminate/ignore)

29. SIGPWR: system power fail (terminate/ignore)

30. SIGSYS: bad argument to system call (terminate+core)


기본적인 Signal 처리 방식은 아래와 같다.

1. SIG_DFL (SIG_PF)0

2. SIG_ERR (SIG_PF)-1

3. SIG_IGN (SIG_PF)1

4. SIG_HOLD (SIG_PF)2





윈도우즈 특정 버전 이상부터는 MBR 디스크가 아닌 GPT디스크에서 설치가 가능하도록 되어있다.


윈도우즈 인스톨러 중 설치 하기전에 윈도우 복구 창 누르고 -> CMD 명령 프롬포트 혹은


Shift + F10으로 들어갈수 있다.


1. diskpart 입력


2. list disk (디스크 개체 목록 확인)


3. 바꿀 디스크 선택 select disk N


N 디스크가 선택한 디스크입니다.


4. Clean 


5. convert gpt (gpt로 변경) || mbr로 변경시에는 conver mbr


혹시 디스크의 파티션이나 볼륨이 있는 경우는


select disk N 후에 


list volume 하여 select volume N 후에 delete volume 으로 삭제를 진행해 주어야 합니다. 


하핳

**** 추가 사항

// 아 또한 UEFI 모드로 부팅시에는 GPT 디스크에 설치가 되지 않기 때문에 MBR형식으로 바꿔 주어야 한다.


또한 설치할때 2개의 물리적인 HDD 혹은 SSD가 있을때


부트 옵션이 우선권이 있는 곳에만 깔리게 되니

0 SSD

1 HDD 일때


HDD에는 설치가 되지 않기 때문에 깔고 싶을때는 부팅 옵션을


0 HDD

1 SSD 로 바꾸거나


0 SSD의 부팅 에서 disable 혹은 off로 주어놓고 설치후에 다시 On으로하게 되면 된다. 





블랙 박스 테스팅(Black box testing) – 시스템의 내부 설계(Internal system design)는 이 테스팅 유형에서 고려할 대상이 아니다. 테스트는 요구사항(Requirement) 및 기능성(Functionality)에 기반해서 이루어진다.

 

화이트 박스 테스팅(White box testing) – 이 테스팅은 애플리케이션의 코드 내부의 로직(Logic)에 대한 지식을 기반으로 수행된다. 글래스 박스(유리상자 혹은 투명상자) 테스팅으로도 알려져 있다. 이 유형의 테스팅을 수행하기 위해서는 내부적으로 소프트웨어와 코드가 어떻게 동작하는지를 알고 있어야만 한다. 화이트 박스 테스트는 코드 구문(Statements), 분기(Branches), 경로(Paths), 조건(Conditions) 커버리지 등으로 분류할 수 있다.

 

유닛 테스팅(Unit testing) – 각각의 소프트웨어 컴포넌트나 모듈 대상 테스팅을 의미한다. 일반적으로 테스터가 아니라 프로그래머에 의해 수행되며, 이를 수행하기 위해서는 프로그램 내부에서 수행되는 코드와 프로그램 설계에 대해 매우 해박한 지식을 가지고 있어야 한다. 테스트 드라이브 모듈(Test drive modules)이나 테스트 하네스(Test harnesses) 개발이 필요할 수도 있다.

 

점진적인 통합 테스팅(Incremental integration testing) – 바텀업(Bottom up) 방식의 테스팅. 예를 들어, 애플리케이션에 새로운 기능이 추가되는 것에 대해 지속적으로 이어지는 테스팅과 같은 것이다. 애플리케이션의 기능성과 모듈은 이미 각각 충분히 테스트 되어있는 상태여야 한다. 프로그래머 혹은 테스터에 의해 수행된다.

 

통합 테스팅(Integration testing) – 통합 이후에 결합된 기능들을 검증하기 위한 통합 모듈 테스팅. 여기서 모듈은 일반적으로 코드 모듈, 개별 애플리케이션, 네트워크 상의 클라이언트와 서버 애플리케이션 등이 될 수 있다. 이 유형의 테스팅은 특히 클라이언트/서버 및 분산 환경 시스템에 적절하다.

 

기능 테스팅(Functional testing) – 이 유형의 테스팅은 내부적인 부분을 무시하고 결과값이 요구사항대로 나왔는지, 혹은 그렇지 않은지에 초점을 맞춘다. 블랙박스 타입의 테스팅이 애플리케이션의 기능 요구사항 검증에 적합하다.  

 

시스템 테스팅(System testing) – 각각의 요구사항에 대해 전체 시스템이 테스트된다. 전체 요구사항 명세에 기반한 블랙 박스 타입의 테스팅으로 모든 조합 가능한 시스템의 부분들을 커버한다.

 

엔드-투-엔드 테스팅(End-to-end testing) – 시스템 테스팅과 유사하며, 데이터베이스와 네트워크 커뮤니케이션의 사용, 혹은 다른 종류의 하드웨어, 애플리케이션, 혹은 시스템에 대한 상호 작용과 같은 실제 사용자 환경을 모방한 환경에서 사용되는 모든 애플리케이션에 대한 테스팅을 포함한다.

 

새너티 테스팅(Sanity testing) – 새로운 소프트웨어 버전이 주요 테스팅 업무를 수행하기에 충분히 적합한가를 판단하기 위해 수행하는 테스트. 만약 애플리케이션에서 사용 초기에 크래시(Crash)가 발생한다면, 시스템은 더 이상의 테스팅을 수행할 정도로 충분히 안정적이라고 말할 수 없으며, 빌드 혹은 애플리케이션은 이 부분을 수정해야 한다.

 

리그레션 테스팅(Regression testing) – 애플리케이션의 모든 모듈 및 기능에 대한 수정 사항을 테스팅 하는 것. 리그레션 테스팅에서 모든 시스템을 커버하는 것은 무척 어려운 일이므로 일반적으로 이러한 유형의 테스팅에는 자동화 테스팅이 사용된다.

 

인수 테스팅(Acceptance testing) – 일반적으로 이 유형의 테스팅은 시스템이 고객이 명세한 요구사항을 충족했는지를 검증하기 위해 사용된다. 사용자 혹은 고객이 애플리케이션을 인수(Accept)할 것인지를 결정하기 위해 수행한다.

 

부하 테스팅(Load testing) – 어느 지점에서부터 시스템의 반응 시간이 지연되거나(Degrades), 혹은 반응이 실패하는지를 알아보기 위해 부하의 범위 안에서 웹 사이트를 테스트 하는 것과 같은, 부하가 걸리는 상황 하에서 시스템의 동작을 검사하기 위해 수행하는 일종의 퍼포먼스 테스트.

 

스트레스 테스팅(Stress testing) – 명세에서 허용된 것 이상의 스트레스를 가해서 어떻게 그리고 언제 시스템에서 장애가 발생하는지를 체크하기 위한 테스트. 저장 용량을 초과하는 데이터를 저장하거나, 복잡한 데이터베이스 쿼리를 입력하거나, 시스템에 지속적으로 입력값을 입력하거나 혹은 데이터베이스에 부하를 거는 것과 같은 심각한 부하를 주는 테스트를 수행한다.

 

퍼포먼스 테스팅(Performance testing) – ‘스트레스’ 혹은 ‘부하’ 테스팅과 종종 혼용되어 사용되는 단어. 시스템이 퍼포먼스 요구사항을 충족하는지 검증하는 행위이다. 이를 위해 각기 다른 퍼포먼스와 부하 툴을 사용한다.

 

사용성 테스팅(Usability testing) – 사용자 친화적(User-friendliness)인지를 점검하는 것. 애플리케이션의 플로우와 신규 사용자들이 쉽게 애플리케이션을 이해할 수 있는지, 사용자가 원하는 어떤 시점에서도 적합한 도움말이 제공되는지 등이 테스트된다.

 

설치/삭제 테스팅(Install/uninstall testing) – 각기 다른 하드웨어와 소프트웨어 환경 및 다른 OS 하에서 전체, 부분, 혹은 업그레이드 설치/삭제 프로세스를 테스트한다.

 

회복 테스팅(Recovery testing) – 크래쉬, 하드웨어 장애 혹은 다른 심각한 문제들로부터 시스템이 어떻게 복구되는지를 테스트 하는 것

 

보안 테스팅(Security testing) – 해킹이 시스템을 뚫고 들어갈 수 있는지를 검증하는 것. 인가 받지 않은 내부 혹은 외부의 액세스로부터 시스템이 어떻게 스스로를 방어하는지에 대해 테스트한다. 외부 공격으로부터 시스템, 데이터베이스가 안전한지를 체크한다.

 

호환성 테스팅(Compatibility testing) – 특정한 하드웨어/소프트웨어/OS/네트워크 환경 및 각기 다른 조합 하에서 소프트웨어가 어떻게 동작하는지를 테스트한다.

 

비교 테스팅(Comparison testing) – 앞서 출시된 제품 혹은 유사한 제품과 비교해 제품의 장단점을 비교함

 

알파 테스팅(Alpha testing) – 이 유형의 테스팅을 위해 사내에서 가상 유저 환경이 조성될 수 있다. 개발의 마지막 부분에서 이 테스트가 수행된다. 이 테스팅의 결과로 사소한 디자인 변경 등이 이루어 질 수 있다.

 

베타 테스팅(Beta testing) – 일반적으로 엔드 유저에 의해 완료되는 테스팅. 상용화를 위한 애플리케이션 릴리즈 이전의 최종 테스팅이다.



출처 - http://angel927.tistory.com/77

+ Recent posts