테스트 효과성을 검증하기 위한 방법은 여러가지 방법이 있습니다! 크게 3가지로 나눠 볼 수 있는데요. TC기반 / 결함기반 / 커버리지 기반 요렇게 3개로 나눌 수 있습니다. 테스트 케이스 기반 테스트 케이스 실패율로 판단하기 ⇒ 결함을 검출한 테스트 케이스의 비율이 높으면 효과적인 테스트라고 판단 ⇒ 그럼 결함 검출한 테스트 케이스의 비율이 높으면, 비효율적인 테스트라고 판단하게된다. 근데 이미 SW품질이 높거나 예외 테스트케이스가 없어서 실패율이 낮을 수도 있고, 특정 테스트만 편중해서 실패율이 높게 나올 수도 있다.. 테스트 케이스 효율성으로 판단하기 ⇒하나의 결함을 검출하기 위해 사용된 TC개수로 판단 ⇒ 하나의 결함을 검출하는데, 많은 수의 TC가 사용되면 효율이 낮은 것. ⇒ 왜냐하면 여러 테..
- Wb 에 대한 정의와 필요성에 대해서 학습하고 Bb와의 차이점에 대해 이해한다. - Control flow test, Data Flow test 차이 - 다양한 Coverage 유형을 학습하고 개별 예제와 비교하여 이해한다. - 사이클로매틱 복잡도 정의에 대해서 학습하고 예제를 통해서 계산법을 습득한다. - 화이트박스 테스트란? : 제품의 내부 작용 특히 코드의 논리와 구조를 완전하게 볼 수 있다는 것을 의미함 - 필요성? : 기능 테스트에 의해 완성된 커버리지를 분석해서 기능테스트의 효율성을 평가하는 방법으로 사용될 수 있다. 정적테스트: 프로그램 실행안하고 수행 동적테스트: 블랙박스, 화이트박스 등의 프로그램의 실행을 통해서 테스트 - Control Flow Test : 프로그램의 제어 흐름을 이..
- 블랙박스 테스팅이란 : 내부를 알필요없이 입,출력을 통해서 기능을 테스트 : 시스템의 요구사항의 명세게 따라 동작하지 않는 환경이나 조건을 발견하는데 집중하는 테스팅 방법 : 명세기반 테스팅이라고도 불림 - 장점 : 테스트 대상인 코드의 규모가 크고 복잡한 경우에 wb보다 더 효과적이다 : wb방법은 단위 테스트 이상의 규모에서는 한계가 있고 이론적이다. : 테스터가 프로그래밍 언어 및 프로그램 통합에 대한 지식을 꼭 가지고 있을 필요가없어서 테스트 확보가 유리하다. : 테스트가 사용자의 관점에서 진행가능 : 명세의 모호성이나 모순을 발견하는데 도움 : 명세작성이 되면 테스트케이스가 바로 설계가능 : 테스터와 프로그래머가 서로 독립적이라서 테스트 진행 및 결과 도출이 객관적일 수 있음 - 단점 : 프..
- sw 오류란 무엇인가? 1. sw가 요구사항에서 명시된 일을 수행하고 있지 않다. 2. sw가 요구사항에서 동작하지 않도록 명시된 일을 수행하고 있다. 3. sw가 요구사항에서 언급하지 않은 일을 수행하고 있다. 4. sw가 요구사항에서 언급하고 있지는 않지만 해야 하는 일을 수행하고 있지 않다. 5. sw가 테스터의 관점에서 이해하기 어렵고, 사용하기 힘들고, 느리다면 사용자에게 직관적으로 편리하게 보이지 않을 것이다. - sw 오류가 발생하는 이유 1. 인간이 범하기 쉬운 실수 2. 수많은 시스템 상호간의 연동 3. 시간적인 압박 4. 기반환경의 복잡성 5. 복잡한 코드 6. 기술 또는 시스템의 변경 - 테스트의 목적 1. 명세 충족을 확인 2. 결함을 발견 3. 사용자의 명세 및 비즈니스의 요구..
학습 목표 1. SW 공학이라고 부르는 이유에 대해 이해할 수 있다. 2. SW 필수 문제 4가지에 대해 이해하고 각각을 설명할 수 있다. 3. SW 공학을 배우는 주된 이유를 이해하고, 유지보수 비용을 줄이는 방법의 하나로서 SW 테스팅을 이해할 수 있다. 4. SW 테스팅의 목적과 원리를 알고, control-flow 기반 테스트 기법이랑 data-flow 기반 테스트 기법을 이해한다. - 왜 SW과학이 아니라 소프트웨어 공학이라고 부르는가? => 과학은 법칙을 찾는것이고, 공학은 최적의 조합을 찾는것. => sw를 만드는 행위는 프로그래머의 독창성이 바로 드러나는 행위이기 때문이다. ==> art와 가깝다 ===> sw를 만드는 것을 과학적으로 법칙이 있게 만들고 싶다. ====> 그래서 sw만드는..
pineoc.github.io/study/study/agile-study/Scrum-Kanban.html 칸반과 스크럼 공부 저장소 pineoc.github.io 스크럼 - 조직을 작고, 교차 기능적이며 자기 조직적인 팀으로 쪼개라. - 일을 출시 가능한 작은 단위의 목록으로 나누어라. - 목록을 우선순위에 따라 정렬하고 각 항목에 대해 상대적인 노력을 추정하라 - 시간을 짧고 고정된 길이의 이터레이션으로 나누고, 이터레이션을 마칠 때 잠재적으로 출시가능한 코드를 시연하라. - 출시 계획을 최적화하고, 매 이터레이션 이후 결과물을 검토하면서 얻어진 지식을 바탕으로 고객과 협업을 통해서 우선순위를 수정하라. - 이터레이션을 마칠 때마다 회고를 실시하여 프로세스를 최적화하라. * 소규모 팀에서 짧은 시간 동..
출처: ddanx2.tistory.com/45 테스팅: 결함을 발견하기 위한 활동 - 테스트는 공정상의 결함을 발견할 수 있다. - 시스템이 정지되는 결함과 정지가 되지 않는 결함이 모두 포함된다. 디버깅: 결함의 원인을 찾고, 코드를 수정하는 개발활동 - 디버깅 후 테스터에 의해 확인 테스팅을 수행하여 결함이 제대로 고쳐졌는지 확인이 필요하다.
소프트웨어 개발은 다음과 같이 동작한다. 요구사항정리 => 분석 => 설계 => 코딩 => 테스트 (정적테스트) ( 동적테스트 ) 정적테스팅 vs 동적테스팅 - 동적테스팅 : 프로그램을 실제로 실행하여 결과를 확인하는 방법 : 주어진 입력 값에 대해 예상한 결과 값이 출력되는지 확인 : Validation : 정적 테스팅에 비해 정확성을 뛰어나나 완전하진 않음 - 정적 테스팅 : 프로그램을 실제로 실행하지 않고, SW의 정ㅈ거인 형태를 검사, 검토, 분석하여 결함을 찾는 활동 : Run-time 시 발생할 수 있는 문제 현상에 대한 원인ㅇ르 파악하고 프로그램 코드를 분석하는 방법 : Verification : Checklist나 자동화된 도구를 사용하여 산출물 검증 정적테스트 => 리뷰 => 동료 검토 ..
