본문 바로가기
학교/소프트웨어 테스팅이론

[소프트웨어테스팅 이론] 1. Introduction to SW Test

sami355 2023. 3. 24. 01:50

p4

퀄리티 있는 sw를 만드는 것은 어렵다.

  • 간단한 프로그램을 작성하는 것도 어렵다.
    • 정확성과 신뢰성 둘다 가지는 sw를 만드는 것은 쉽지도 않으면 어려운 일이다.
  • sw의 복잡도는 인간의 뇌의 역량에 비해 훨씬 복잡해져가고 있다.
    • 데이터의 크기 증가
    • 분산처리
    • 시스템이 동적으로 바뀐다 ex) malloc
    • 동시성, 멀티스레드 프로세싱

p5

삼각형을 판별하는 프로그램의 예제

  • 3변의 길이로 삼각형 유무 판별 result 뜻
    0 정삼각형
    1 이등변 삼각형
    2 삼각형 아님
    3 그 외 삼각형
    • 위와 같은 예제는 “Requirement Test” 혹은 “Black Box Test”라고 한다.
    • 그렇자면 해당 프로그램을 확인하기 위해 총 몇번의 Test가 필수인가.→ 올바른 인자가 들어왔는지에 대한 테스트
    • → 총 5번
    • → result 0~3 에 대한 테스트

p6

  • 만약 코드가 확인 가능하다 → white Test
  • Test case의 min과 max 사이에 적절하게 확인
  • 적합한 Test Case는 모른다.

p7

  • Test : Best Effort Test를 지향해야 한다.
  • 특정 프로그램의 controll flow Diagram이 있을 경우 몇번의 test가 필요한가?
    • min : Path를 확인하는것
    • max : 들어올수 있는 모든 경우의 수
    • ex) 삼각형 판별 프로그램의 경우 2^32 * 2^32 * 2^32이다. (int의 범위)

p9

  • sw의 퀄리티는 누구든 신경쓴다.
    • customer, developer, operator, enterpreneur, people in general..

p14

  • 테스팅로 모든 문제를 잡을 수 없다.
  • 테스트는 best-effort이다. (할 수 있는 최대한도)
  • 그럼에도 불구하고 테스팅은 필수적이다.
  • 충분하지는 않지만 그럼에도 불구하고 해야만 한다.

p16

  • best effort는 min과 maximun이 존재하며 이 사이에 존재하는 gap사이에서 적절한 값을 찾는 것이 필요하다

p18

  • Fault, Errors, failure이 3가지를 꼭 알아야 한다.
  • Software Fault
    • 소프트웨어 내에 존재하는 정적인 결함이며 코드만을 보고 확인이 가능하다.
    • 프르그래머 레벨에서는 부정확한 소스코드로 이야기할수있으며 Error가 생길수도 있음
      • (생길수도 있다고 한 이유는 fault가 존재하는 path를 타지 않으면 에러가 발생하지 않을수도 있기때문이다.)
  • Software Error
    • fault로 인해 발생되며 알맞지 않는 결과를 도출한다.
    • 프로그래머 레벨에서는 런타임 도중 영향을 미친다. 또한 Failure가 발생할수도 있다.
    • 타이핑 실수 같은 것들
    • 내부의 부정확한 state가 존재하는 것을 의미한다.
  • software Failure
    • 예상치 못한 결과가 도출된다.
    • 프로그래머 레벨에서는 프로그램이 실행하는 도중에 error가 프로그램 밖으로 나타난다.
    • error의 실행으로 예상치 못한 결과가 도출되는 것을 의미한다. 그러나 error가 실행한다고 해서 무조건 failure가 도출되는 것은 아니다.

chat-gpt

  • Fault (결함) : 코드의 오류, 즉 잘못된 코드 또는 버그를 의미합니다. 일반적으로 "결함"이라는 용어는 코드 내부에 존재하는 오류를 나타냅니다.
  • Error (에러) : 프로그램이 실행 중에 예기치 않은 동작을 하거나 불완전한 결과를 내는 것을 의미합니다. 에러는 일반적으로 결함으로 인해 발생합니다.
  • Failure (실패) : 소프트웨어 제품이 요구 사항을 충족시키지 못하거나 기대한 동작을 하지 못하는 것을 의미합니다. 실패는 일반적으로 결함과 에러로 인해 발생합니다.
  • 이러한 fault, error, failure는 논리적인 오류도 포함된다.
  • error는 프로그램의 특정 기능에 대해서 말하고 failure는 프로그램 전체적인 면에서의 문제를 말한다.

p20

예시

  • 해당 코드에서 Fault는 무엇인가?
    • i>0인 부분. cause x[0]인 부분에 대해서는 확인을 못하기 때문에 fault이다
  • Fault를 수행하지 않는 test case도 존재하는가?
    • x가 null일때는 Fault가 없다.
  • Fault를 수행하지만 error수행을 하지 않는 경우는 무엇인가?
    • x={1,2,3,4}이고 y=3일경우
  • Error는 수행하지만 failure는 아닌 경우는 무엇인가?
    • x[0] ≠ y일 때 and 배열 x에 y가 없을때

  • 해당 코드에서 fault는 무엇인가.
    • i=0 ; i<x.length
  • fault를 수행하지 않는 테스트 케이스도 존재하는가?
    • 배열 x가 null일때
  • fault를 수행하지만 error가 아닌 test case가 있는가
    • x배열에 0이 없을때
  • error를 수행하지만 failure는 아닌 test case가 있는가
    • x배열에 0이 하나 일때
    • ex) x = {0,1,2}

p23

  • 테스터의 목표는 fault를 최대한 빨리 찾아서 제거하는 것이다.
  • 테스팅을 통해 품질을 향상시키고, 비용을 감소시키며, 고객의 만족도를 보존한다.

p25

  • Testing : 실행을 통해 소프트웨어를 평가하는것
  • test failure : 테스트의 실행으로 소프트웨어가 failure하는 것
  • Debugging: failure를 유발한 fault를 찾는 과정
  • 모든 inputdms fault를 유발하지 않는다.

chat-gpt

  • testing은 소프트웨어가 예상대로 동작하는지 확인하기 위한 과정.
  • debugging은 소프트웨어에서 발생하는 버그를 찾고 수정하는 과정.

p26

  • fault & failure Model(RIPR)
  • failure를 관찰하기 위해서는 다음 4가지의 조건이 필요하다.
    • Reachability: fault가 발생하는 지점까지 도달 가능해야 한다.
    • Infection: 프로그램의 상태가 부정확해야 한다.
    • Propagation: infection된 상태가 전파 가능해야한다./ output이나 finalState까지 갈수 있어야 한다.
    • Reveal: 테스터가 프로그램의 부정확한 부분을 확인할 수 있어야 한다.

p27

  • coverage criteria : 프로그램이 얼마나 커버 가능한가에 대한 기준
  • 테스터는 최소한의 입력값과 최대한의 입력값사이를 찾아야 한다.
  • coverage criteria로 input의 규모를 정할수 있고 동일한 test를 반복하지 않을 수 있다.

p28

  • Coverage criteria로 인해 얻을 수 있는 장점은 다음과 같다.
    • 효율성을 극대화 할 수 있다.
    • 테스트에 대한 추적정을 제공해준다.
      • 소스코드, 요구사항, 디자인 모델..
    • 회귀 테스팅을 수월하게 해준다.
      • test input을 생성하는 기준이 존재하는가?, 만약 프로그램을 수정한다면 해당 프로그램에 대한 test case를 전부 수행한다.
    • 끝나는 기준을 제시 할 수 있다.
    • 강력한 도구가 될 수 있다.

p29

  • Test Criterion and requitrement
  • test criterion: 테스트 기준점
    • 모든 statement에 도달할수 있는가. - 메서드. 함수 내부적인 측면
    • 모든 기능적인 요구사항을 충족하는가 - 메서드, 함수 외부적인 측면
  • test requirement: 테스트 동안 만드시 만족해야 하는것들
    • 각 statement들이 반드시 test되는가
    • 각 기능적인 요구사항들이 충족 되는가

p32

  • types of test activities 디버깅은 포함 되지 않는다.
    1. test design(Criteria-based, Human-based) 테스트 디자인
    2. test automation 테스트 자동화
    3. test execution
    4. test evaluation

p33

  1. Test Design(criteria-based)
  • sw testing중에서 가장 technical할 일이다.
  • 요구되는 능력으로는
    • 이산수한
    • 프로그래밍
    • 테스팅
  • cs지식 많이 필요
  • chanllenging한 일이다.

p34

  1. Test design(human-based)
  • 도메인에 대한 지식을 필요로 한다.
  • 개발자보다 더 어려울수있다.
  • cs에 대한 지식은 거의 필요로 하지 않는다.
  • challenging한 일이다.

p35

  1. Test Automation
  • 덜 technical하다.
  • 프로그래밍에 대한 지식이 필요로 된다.

p38

  • test management
  • test maintenance : code가 변경되어도 test case 재사용 가능하도록 하는것.

티스토리툴바