Software Testing Overview

Software Testing

소프트웨어의 품질을 보장하기 위해 다양한 방법과 절차를 통해 오류를 발견하고 수정하는 것을 목표

• the process of executing program or system with intent of finding errors.

  오류를 찾기 위해 프로그램이나 시스템을 실행하는 과정

• the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item.
  소프트웨어 항목을 분석하여 기존 조건과 요구 조건 사이의 차이(즉, 버그)를 감지하고 소프트웨어 항목의 기능을 평가하는 과정

• activity in which a system or component is executed under specified conditions, the results are observed and recorded, and an evaluation is made of some aspect of the system or component
  시스템 또는 구성 요소를 특정 조건에서 실행하고, 결과를 관찰하고 기록하며, 시스템 또는 구성 요소의 일부 측면을 평가하는 활동

Evolution of SW Test Engineering

Terminology: Testing vs. Debugging

• Testing : Unknown Defect의 발견
  by 테스터 (또는 개발자)
  • 소프트웨어의 오류나 결함을 발견하기 위해 소프트웨어를 실행하고 분석하는 활동
  • 이 활동은 소프트웨어가 예상대로 작동하지 않거나 요구사항을 충족하지 못하는 부분을 찾아내는 것을 목표
• Debugging : Known Defect의 수정
  by 개발자
  • 디버깅은 테스트를 통해 발견된 결함을 분석하고 수정하는 과정
  • 결함의 원인을 파악하여 코드나 시스템을 수정하는 것

Terminology: Verification vs. Validation

• Verification(검증) : Are we doing a thing right?
  • 우리는 일을 제대로 하고 있는가?
  • 소프트웨어가 명세(specification) 또는 요구사항에 따라 올바르게 구현되었는지 확인하는 것
• Validation(확인) : Are we doing a right thing?
  • 우리는 올바른 일을 하고 있는가?
  • 소프트웨어가 최종 사용자나 고객의 요구를 충족하는지 확인하는 것

Terminology: Error, Fault, Failure

오류 (Error)

• 개발자의 설계 또는 코딩 실수로 인해 발생하는 문제
• 예를 들어, 잘못된 알고리즘 설계, 논리 오류, 요구사항의 잘못된 해석 등

결함 (Fault)

• 결함은 오류로 인해 소프트웨어 내에 존재하게 된 잘못된 코드나 설계 요소
• 오류가 코드나 시스템에 반영된 상태. 이 결함은 테스트 단계에서 발견될 수 있습니다.

장애 (Failure)

• 결함이 실행되어 시스템의 동작 이상이 감지된 상태

Static vs. Dynamic testing

Static

소프트웨어 시스템 또는 구성 요소를 실행하지 않고 그 형식, 구조, 내용, 문서를 기반으로 평가하는 과정.

• Static Analysis : process of evaluating a system or component based on its form, structure, content, or documentation
  소스 코드, 디자인 문서, 요구사항 명세서를 분석하여 결함을 찾아내는 활동
  

• Review: process, which can include a meeting, in which work products are presented to some stakeholders for comment or approval
  작업 산출물을 관련 이해관계자에게 제시하고, 이들이 코멘트를 제공하거나 승인을 하는 과정

Dynamic

소프트웨어 시스템 또는 구성 요소의 실행 중에 그 동작을 기반으로 평가하는 과정

• Dynamic Analysis: process of evaluating a system or component based on its behavior during execution
  시스템이 실행되는 동안 동작을 모니터링하고 평가하는 활동
  -- Call graph, Resource usage, Memory leak, performance tuning

• Dynamic Testing : testing that requires the execution of the test item
  테스트 항목의 실행을 필요로 하는 테스트로, 시스템이 예상대로 동작하는지 확인하기 위해 실제로 소프트웨어를 실행

동적 분석은 주로 성능 최적화와 리소스 사용량 분석에 중점을 두는 반면, 동적 테스트는 소프트웨어의 기능적 및 비기능적 요구사항을 검증하고 결함을 발견하는 데 중점을 둡니다.

Testing Principles

1. It’s impossible to test a program completely
2. Testing can’t show that bugs don’t exist
3. The more bugs you find, the more bugs there are
4. Pesticide Paradox
5. Early Testing
6. Absence of errors – fallacy
7. Testing is context dependent

It’s impossible to test a program completely

완전한 테스팅은 불가능하다
모든 입력 조합과 실행 경로를 테스트하려면 무한히 많은 시간이 필요할 수 있습니다. 소프트웨어의 복잡성으로 인해 모든 가능한 시나리오를 테스트하는 것은 현실적으로 불가능합니다.

Testing can’t show that bugs don’t exist

Bug가 존재함을 확인할 수는 있으나, Bug가 존재하지 않음을 확인할 수는 없다.

• 설명: 테스트는 소프트웨어가 오류 없이 완벽하게 작동함을 증명할 수 없습니다. 테스트를 통해 발견된 버그는 수정할 수 있지만, 모든 버그가 발견되었다고 확신할 수는 없습니다.
• 예시: 소프트웨어가 100번의 테스트에서 모두 정상적으로 작동했더라도, 101번째 테스트에서 버그가 나타날 수 있습니다.

The more bugs you find, the more bugs there are

• 한 부분에서 많은 버그가 발견된다면, 그 근처에 더 많은 버그가 숨어 있을 가능성이 높습니다.

결함 집중 현상 (Defect Clustering)

• 소프트웨어 시스템의 특정 모듈이나 구성 요소가 다른 모듈에 비해 더 많은 결함을 포함하고 있는 현상입니다. 이는 해당 모듈이 복잡하거나, 잘못 설계되었거나, 개발자가 익숙하지 않은 기술을 사용했기 때문일 수 있습니다.

모듈 A에서 더 많은 결함이 발견되었다면, 이는 결함 클러스터링 현상에 따라 모듈 A에 더 많은 결함이 숨어 있을 가능성이 높다는 것을 의미합니다. 따라서 모듈 B에 비해 모듈 A가 더 많은 결함을 포함할 가능성이 큽니다.

살충제 패러독스 (Pesticide Paradox)

동일한 테스트 케이스를 반복해서 사용하면 더 이상 새로운 버그를 찾지 못하게 됩니다. 소프트웨어에 대한 새로운 결함을 발견하려면 테스트 케이스를 주기적으로 업데이트하고 다양화해야 합니다.

Early Testing

소프트웨어 개발 초기 단계부터 테스트를 시작하는 것이 중요합니다. 초기 단계에서 결함을 발견하고 수정하면 비용과 시간을 절약할 수 있습니다.

Absence of errors – fallacy (오류가 없다는 것의 오류)

결함이 없다는 것이 소프트웨어가 사용자의 요구사항을 충족하는지를 의미하지는 않습니다. 소프트웨어가 정확히 요구사항을 반영하고 있는지 확인하는 것이 중요합니다.
품질의 정의

• 사용용도에 대한 적합성
• 시스템이 다양한 이해관계자의 명시적/암무적 필요을 충족하여 가치를 제공할 수 있는 정도
• 제품/서비스/시스템/컴포넌트/프로세스가 고객 및 사용자의 필요, 기대사항, 요구사항을 충족할 수 있는 능력

Testing is context dependent

테스트는 상황에 따라 다르다

• 테스트 접근 방식은 소프트웨어의 성격, 목적, 환경에 따라 달라져야 합니다. 예를 들어, 안전-critical 시스템과 웹 애플리케이션의 테스트 방법은 매우 다릅니다.
• 각 프로젝트, 조직, 제품은 서로 다른 테스팅 니즈를 가짐. 이에
  따라 테스트 활동은 적절한 테일러링이 필요함

Kinds of Testing

Test Level
테스트 레벨은 테스트가 수행되는 범위와 관련이 있습니다
• Unit testing, integration testing, system testing, acceptance testing
Test Type
테스트 타입은 테스트가 수행하는 목표나 방법에 따라 분류됩니다.
• Performance testing, security testing, usability testing etc.
Test design approach
테스트 케이스를 작성하거나 테스트를 계획하는 방법에 대한 구분입니다.
• black box testing vs. white box testing
• Experience-based testing
Others
• Risk-based testing
• Scripted testing vs. exploratory testing

Test Level, Test Phase

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
• Maintenance Testing

Unit Testing

가장 작고 독립적으로 테스트할 수 있는 단위인 함수, 클래스 또는 개별 컴포넌트를 테스트하는 과정

• (1) testing of individual routines and modules by the developer or an independent tester (ISO/IEC/IEEE 24765)
개발자나 독립된 테스터에 의해 수행되는 개별 루틴 및 모듈의 테스트를 의미

• (2) test of individual programs or modules in order to ensure that there are no analysis or programming errors (ISO/IEC 2382)
개별 프로그램이나 모듈을 테스트하여 분석이나 프로그래밍 오류가 없는지 확인하는 과정

• Unit : 소프트웨어의 가장 작은 독립적으로 테스트 가능한 단위(function, class) 또는 개별 컴포넌트

• 소프트웨어의 각 단위(component, module, function, class)가 개별적으로 테스트 됨

• 테스트 수행을 위해서는 주로 stub, driver가 필요함

• Driver : function that call module under test
  드라이버는 특정 모듈 또는 컴포넌트를 호출하여 테스트를 수행하는 함수
• Stub : function called by module under test
  테스트 대상 모듈이 호출하는 외부 함수를 대신하는 역할

• 주로 개발 당사자에 의해 수행됨
• 발견된 결함이 공식적으로 관리되지 않는 경우가 많음
• 각 단위에 대한 정의와 테스트 방법, 관리 수준은
아키텍쳐 설계 단계에서 계획 수립함

Integration Testing

testing in which software components, hardware components, or both are combined and tested to evaluate the interaction among them
여러 개별 소프트웨어 구성 요소나 하드웨어 구성 요소를 결합하여 상호 작용을 평가하는 테스트 과정

• 각 Unit을 통합하여 테스트 수행 (전체 시스템의 통합까지)
• 개발자 및 테스터에 의해 수행됨
• 통합 Approach

  • Big Bang : 테스트된 각 Unit을 한꺼번에 통합하고 테스트 수행

    • 결함 발견시, 어디에서 문제가 있는지 발견하기 어려움

  • Top-down or Bottom-up : 위 또는 아래에서부터 통합을 진행함.

    • Stub(Top-down) 및 Driver (Bottom-up) 활용
      상위 모듈을 테스트할 때, 하위 모듈을 대체하는 스텁(Stub)을 사용
      하위 모듈을 테스트할 때, 상위 모듈을 대체하는 드라이버(Driver)를 사용

    • Bug Isolation이 용이함. But, critical한 이슈가 top이나 bottom에 있다면?

  • Sandwich : Top-down과 bottom-up testing의 조합

  • Backbone : 중요 모듈부터 시작, backbone을 구성하고 리스크 순으로 통합을 하며 테스트

    • Bug isolation에 좋고, 리스크 순으로 통합 결함 발견
• SW 아키텍쳐를 고려하여, 테스트 대상과 테스트방법과 통합순서, 테스트 환경의 사전 계획이 필요함
  • 통합 테스트에는 소프트웨어 시스템 내의 여러 수준의 통합 테스트가 포함되므로 테스트 환경에 대한 신중한 계획이 필요합니다.

System Testing

testing conducted on a complete, integrated system to evaluate the system's
compliance with its specified requirements
완전히 통합된 시스템을 평가하여 지정된 요구 사항을 충족시키는지 확인하는 과정

• 단위 또는 일부가 아닌 전체 시스템을 대상으로 테스트를 수행함
• 기능 뿐 아니라 security, performance, reliability, usability, portability 등 다양한 품질요소를 테스트
• 실 환경과 동일한 또는 유사한 환경에서 테스트 수행
• 가능하면, 실제 사용자의 Usage를 나타내는 Operational Profile을 기반으로 한 테스트 수행도 포함하는 것이 바람직
  • 실제 사용자 사용 패턴을 반영하는 운용 프로파일을 기반으로 계획되어야 함
• 보통 독립적인 테스터에 의해 수행됨
  • 일반적으로 시스템 개발에 직접적으로 참여하지 않는 독립적인 테스터들에 의해 수행됨

Acceptance Testing

(1) testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system (ISO/IEC/IEEE 24765:2017)
시스템이 수용 기준을 충족하는지를 평가하고, 고객이 시스템을 수용할 수 있도록 하는 테스트 과정

(2) formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component (IEEE 1012-2017)
시스템이 사용자 요구 사항을 충족하며, 실제 운영 환경 또는 그와 유사한 환경에서 예상대로 작동하는지를 확인

• 전체 시스템이, 실사용 환경 또는 그와 유사한 환경에서 테스트 됨
• 주로 사용자, 고객에 의해 수행되나, 독립적인 테스트 조직/회사에 의해 수행되기도 함
• 다양한 테스트
  ▫ User Acceptance Testing : 최종 사용자가 시스템의 사용성과 기능을 평가
  ▫ Operational Testing : 시스템 운영자 (backup, disaster recovery, maintenance 등)
  ▫ Contract & Regulation Testing :계약 조건과 관련 규정을 준수하는지를 검증
  ▫ Alpha, Beta, Field Testing
  ▫ 잠재 사용자/고객 또는 실 고객에 의해 개발 사이트(alpha) 또는 실 사용 환경에서 테스트
  

Maintenance Testing

시스템이 이미 출시된 후에 발생하는 변경 사항에 대응하여 시스템의 정상적인 작동을 보장하기 위해 수행되는 테스팅

• 시스템이 릴리즈 된 이후, 시스템에 변경(개선, 결함수정, 운영환경 변화 등)이 발생했을 때 수행하는 테스트
• 변경된 부분에 대한 테스트도 중요하지만, 전체시스템에 대한 영향 평가 및 Regression Testing이 중요함
• Cf. Regression Testing (회귀 테스트)
  • 변경 사항이 이전에 정상적으로 작동하던 기능에 회귀(결함 발생)를 일으키지 않는지 확인
  • Automated Test의 좋은 후보임
    • 변경 사항에 대한 테스트 케이스를 자동화하여 반복적이고 일관된 테스트 수행을 가능하게 하며, 효율성을 높이고 인력을 절감할 수 있습니다. 특히 회귀 테스팅에서 자동화된 테스트 스위트를 실행하여 이전에 확인한 기능의 정상 작동 여부를 신속하게 검증할 수 있습니다.

Test Type

Test Design approach

• Specification-based testing (Black-box testing)
• Structure-based testing (White-box testing)
• Experience-based testing

Specification-based testing (Black-box testing)

• 요구사항, 기능명세, 품질요구사항에 기반한 테스팅
• 소프트웨어 내부구조를 Black box로 간주하여 블랙박스 테스팅 이라고도 함
• SW의 내부 구조에 대한 지식은 필요 없음.
• 소프트웨어 개발프로세스의 모든 단계에 적용 가능함.
• 아무리 테스트를 해도 실제로 코드의 얼마가 테스트되었는지는 알 수 없음.
• 많은 결함을 찾기 위해 Input의 모든 가능한 조합을 하고자 하겠지만, 완전한 테스팅은 불가함. 따라서 일부의 조합만 테스트 할 수 밖에 없음

Structure-based testing (White-box testing)

• White box testing 라고도 함
• 내부 흐름, 구조 등 SW 구현코드에 기반한 테스트
• 테스트를 위해서는 프로그래밍 스킬이 요구됨
• 소프트웨어 개발의 모든 단계에 적용 가능하나, 주로 개발자의 Unit Testing시 주로 수행됨.
• 가능한 경로를 모두 테스트하는 것은 불가능함.
• 요구사항에 대한 미구현 오류를 발견할 수 없음.
  • 주로 코드의 내부 구현을 기반으로 하기 때문에, 소프트웨어가 요구 사항을 정확히 충족하지 못하는 경우를 감지하기 어렵습니다

Experience-based testing

• Error Guessing
  • Test Analyst uses his/her experience to guess the problematic areas of the application
  테스트 분석가가 자신의 경험과 직관을 활용하여 응용 프로그램의 문제가 발생할 가능성이 높은 영역을 예측

• Exploratory testing
  • the tester simultaneously learning about the test object and its defects, planning the testing work to be done, designing and executing the tests, and reporting the results.
  소프트웨어를 동시에 학습하고, 테스트 계획을 수립하며, 테스트를 설계하고 실행하며, 결과를 보고하는 방식의 테스트 접근법

• Checklist-based testing
  • Test Analyst uses a high-level, generalized list of items to be noted, checked, or remembered. E.g., user interface standard checklist
  테스트 분석가가 사전에 작성된 체크리스트를 사용하여 중요한 사항이나 검토해야 할 항목을 체크하는 방법

• Defect-Based Test Techniques
  테스트 분석가가 이미 알려진 결함이나 문제점을 중심으로 테스트 케이스를 설계하고 수행하는 방법을 의미

Scripted Testing vs. Exploratory Testing

• Scripted Testing : 스크립트 테스팅은 사전에 정의된 테스트 케이스에 기반한 체계적인 테스트를 제공

• Exploratory Testing: 스크립트 테스팅은 사전에 정의된 테스트 케이스에 기반한 체계적인 테스트를 제공

Risk-based testing

• Risk Assessment

• Risk exposure = Technical risk * Business risk

• Technical risk : 발생 가능성 (likelihood)
  소프트웨어 개발 또는 운영 중에 발생할 수 있는 기술적 문제나 결함의 가능성
• Business risk : 영향 (impact)
  기술적 문제나 결함이 비즈니스 목표 또는 전략에 미치는 영향의 정도

Software Testing Process

• Test planning
• Test monitoring and control
• Test analysis
• Test design
• Test implementation
• Test execution
• Test completion