'전체'에 해당되는 글 193건
- 2012/03/17 SharePoint Tutorials
- 2012/03/08 Rhapsody :: event의 인자 접근 방법
- 2012/02/27 SPL
- 2012/02/21 Rhapsody :: Multicast with port
- 2012/01/12 CString FAQ
- 2012/01/12 VectorCAST :: Test Case 수행별 Global 변수들 Expected 값 체크 시점 조절
- 2011/12/09 윈도우용 시스템 백업 유틸리티 SyncBack
- 2011/12/04 첫 차, Cruze5
- 2011/11/18 VirtualBox Host-Only Ethernet Adapter Mac 주소 변경
- 2011/11/14 General Testing Principles
2012/03/08 19:35
params->arg1, params->arg2 와 같은 방식으로 사용한다.(간단한데 기록하지 않으면 꼭 까먹는다.)
2012/02/21 08:22
참고 홈페이지
Rhapsody 7.5.1 버전 이후 부터는 포트(Port)간 멀티 캐스트 매크로를 지원한다.
방법은 아래와 같다.
1. 객체를 아래와 같이 구성한다.
2. Sender의 State Diagram을 아래와 같이 구성한다.
1초마다 sendEvent() 함수를 호출하도록 구성한다.
처음에는 GEN 매크로를 사용하여 이벤트를 전송해본다.
3. Handler들의 State Diagram을 아래와 같이 구성한다.
evTrigger 이벤트를 수신하면, handleEvTrigger() 함수를 호출하도록 구성한다. 나머지의 Handler도 동일하게 구성한다.
Handler1의 handleEvTrigger()
Handler2의 handleEvTrigger()
Handler3의 handleEvTrigger()
4. MULTICAST를 사용하지 않고 동작시켰을때의 화면
Sender가 세개의 객체와 연결되어 있음에도 불구하도, 하나의 객체로만 이벤트가 전달됨을 확인할 수 있다.
5. MULTICAST를 사용했을때의 결과화면
Sender::sendEvent() 함수를 아래와 같이 수정한다.
세개의 객체로 이벤트가 전달됨을 볼수 있다.
Rhapsody 7.5.1 버전 이후 부터는 포트(Port)간 멀티 캐스트 매크로를 지원한다.
방법은 아래와 같다.
1. 객체를 아래와 같이 구성한다.
2. Sender의 State Diagram을 아래와 같이 구성한다.
1초마다 sendEvent() 함수를 호출하도록 구성한다.
처음에는 GEN 매크로를 사용하여 이벤트를 전송해본다.
3. Handler들의 State Diagram을 아래와 같이 구성한다.
evTrigger 이벤트를 수신하면, handleEvTrigger() 함수를 호출하도록 구성한다. 나머지의 Handler도 동일하게 구성한다.
Handler1의 handleEvTrigger()
Handler2의 handleEvTrigger()
Handler3의 handleEvTrigger()
4. MULTICAST를 사용하지 않고 동작시켰을때의 화면
Sender가 세개의 객체와 연결되어 있음에도 불구하도, 하나의 객체로만 이벤트가 전달됨을 확인할 수 있다.
5. MULTICAST를 사용했을때의 결과화면
Sender::sendEvent() 함수를 아래와 같이 수정한다.
세개의 객체로 이벤트가 전달됨을 볼수 있다.
TAG
2012/01/12 13:14
TAG
2012/01/12 09:58
VectorCAST를 사용하여 단위시험을 수행하다보면, Global 변수에 대한 비교를 각 이벤트마다 수행하게 되어있다.(기본값임)
이 방법의 문제점은 Global 변수에 대해 Expected Value에 값을 넣었을 경우 매 이벤트마다 비교를 수행하게 되므로, 의도치 않게 각 이벤트마다 Fail / Pass를 판단하는 결과를 보게 될 것이다.
관련 옵션은 Tools >> Options >> Report >> Display global data after 를
Each Event에서 Each Test Case로 변경.
이 방법의 문제점은 Global 변수에 대해 Expected Value에 값을 넣었을 경우 매 이벤트마다 비교를 수행하게 되므로, 의도치 않게 각 이벤트마다 Fail / Pass를 판단하는 결과를 보게 될 것이다.
관련 옵션은 Tools >> Options >> Report >> Display global data after 를
Each Event에서 Each Test Case로 변경.
TAG
2011/12/09 09:41
2011/11/18 09:18
CMD >> ipconfig /all 로 할당된 MAC 주소를 얻는다. 08-xx-xx-xx-xx-xx 주소를 얻는다.
regedit를 열어 해당 주소를 검색하여, 변경한다. 08xxxxxxxxxx 로 검색.
regedit를 열어 해당 주소를 검색하여, 변경한다. 08xxxxxxxxxx 로 검색.
TAG
2011/11/14 19:26
http://blog.naver.com/qlabcorp?Redirect=Log&logNo=90121618929
1. 테스팅은 결함의 존재를 밝히는 활동이다.(Testing shows presence of defects)
- 테스트는 최종 소프트웨어의 품질보증을 위해 결함을 밝혀내는 행위일 뿐, 결함이 없다는 것을 증명할 수는 없다.
2. 완벽한 테스팅은 불가능하다.(Exhaustive testing is impossible.)
- 소프트웨어 테스팅을 통해 모든 결함을 도출해 내는 것은 불가능하다. 리스크 분석과 결정된 우선순위에 따라 비중이 큰 부분을 중심으로 하는 테스팅(Risk-based Testing)이 이루어져야한다.
3. 테스트는 개발 초기에 시작된다.(Early testing)
- 실제 구현단계 이전의 요구조건명세, 기능설계서에 대한 리뷰(Review), 인스펙션(Inspection)과 같은 정적 테스팅이 매우 중요하다. 이는 개발 후반부 결함 검출에 따르는 테스팅 비용과 수정 일정의 단축을 가능하게 한다.
4. 결함 집중(Defect clustering)
- 신규 기술이 적용된 모듈, 상호작용의 인터페이스가 복잡한 컴포넌트 부분에 오류의 집중화가 발생할 가능성이 높다. 사전 테스팅 설계 단계에서 시스템 컴포넌트의 역할 기능과 구현에 대한 분석과 예측이 반영되어야 한다.
5. 살충제 패러독스(Pesticide paradox)
- 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행한다면 더 이상 새로운 버그를 찾아내지 못할 것이다. 이러한 '살충제 패러독스'를 극복하기 위해서는, 테스트 케이스를 정기적으로 리뷰하고 개선할 필요가 있고, 소프트웨어 또는 시스템의 다른 부분을 새롭고 다른 시각으로 테스트하는 것이 필요하다.
6. 테스트는 정황에 의존적이다. (Testing is context dependent.)
- 개발하는 소프트웨어의 도메인 분야, 목적 정황에 대한 분석을 통해 적절한 테스팅 기법이 선택되어야 한다. 소프트웨어 결과물의 기능적/정황적 특성을 반영한 테스팅 설계가 이루어져야 효율적인 테스트가 가능하다.
7. 오류 부재의 궤변(Absence-of-errors fallacy)
- 아무리 테스팅 과정을 잘 수행한다고 해도, 최종 결과물이 고객의 필요와 기대에 부합되지 못하고 쓸모없다면, 결함을 찾고 수정하는 과정은 아무 소용이 없다.
1. 테스팅은 결함의 존재를 밝히는 활동이다.(Testing shows presence of defects)
- 테스트는 최종 소프트웨어의 품질보증을 위해 결함을 밝혀내는 행위일 뿐, 결함이 없다는 것을 증명할 수는 없다.
2. 완벽한 테스팅은 불가능하다.(Exhaustive testing is impossible.)
- 소프트웨어 테스팅을 통해 모든 결함을 도출해 내는 것은 불가능하다. 리스크 분석과 결정된 우선순위에 따라 비중이 큰 부분을 중심으로 하는 테스팅(Risk-based Testing)이 이루어져야한다.
3. 테스트는 개발 초기에 시작된다.(Early testing)
- 실제 구현단계 이전의 요구조건명세, 기능설계서에 대한 리뷰(Review), 인스펙션(Inspection)과 같은 정적 테스팅이 매우 중요하다. 이는 개발 후반부 결함 검출에 따르는 테스팅 비용과 수정 일정의 단축을 가능하게 한다.
4. 결함 집중(Defect clustering)
- 신규 기술이 적용된 모듈, 상호작용의 인터페이스가 복잡한 컴포넌트 부분에 오류의 집중화가 발생할 가능성이 높다. 사전 테스팅 설계 단계에서 시스템 컴포넌트의 역할 기능과 구현에 대한 분석과 예측이 반영되어야 한다.
5. 살충제 패러독스(Pesticide paradox)
- 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행한다면 더 이상 새로운 버그를 찾아내지 못할 것이다. 이러한 '살충제 패러독스'를 극복하기 위해서는, 테스트 케이스를 정기적으로 리뷰하고 개선할 필요가 있고, 소프트웨어 또는 시스템의 다른 부분을 새롭고 다른 시각으로 테스트하는 것이 필요하다.
6. 테스트는 정황에 의존적이다. (Testing is context dependent.)
- 개발하는 소프트웨어의 도메인 분야, 목적 정황에 대한 분석을 통해 적절한 테스팅 기법이 선택되어야 한다. 소프트웨어 결과물의 기능적/정황적 특성을 반영한 테스팅 설계가 이루어져야 효율적인 테스트가 가능하다.
7. 오류 부재의 궤변(Absence-of-errors fallacy)
- 아무리 테스팅 과정을 잘 수행한다고 해도, 최종 결과물이 고객의 필요와 기대에 부합되지 못하고 쓸모없다면, 결함을 찾고 수정하는 과정은 아무 소용이 없다.