깍돌이

안녕하세요 오늘은 제가 테스트 하는 툴중에 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 으로 돌아올수도있고.. )

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

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

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

사용불가

sftp(사용자가 가장 많음)

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

json 파일은 읽어오지 못함

사용X

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

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

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

.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

블랙 박스 테스팅(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