L15-L16-Software Testing (Ch08)

Topics covered

• Development testing
• (개발 테스트)
• Test-driven development
• (테스트 주도 개발)
• Release testing
• (릴리스 테스트)
• User testing
• (사용자 테스트)

[1] Introduction

Program testing (프로그램 테스트)

• Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use
  (테스트는 프로그램이 의도한 대로 작동하는지 확인하고, 사용되기 전에 결함을 발견하기 위한 것이다.)
• When you test software, you execute a program using artificial data (test input for a test case).
  (소프트웨어를 테스트할 때는 인위적인 데이터(테스트 케이스의 입력 데이터)를 사용해 프로그램을 실행한다.)
• You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes.
  (테스트 실행 결과에서 오류, 이상 현상 또는 프로그램의 비기능적 속성에 대한 정보를 확인한다.)
• Can reveal the presence of errors NOT their absence.
  (테스트는 오류의 존재를 밝혀낼 수 있지만, 오류가 없음을 증명할 수는 없다.)
• Testing is part of a more general verification and validation process, which also includes static validation techniques.
  (테스트는 정적 검증 기술을 포함하는 더 넓은 검증(Verification) 및 확인(Validation) 과정의 일부이다.)

 

Program testing goals (프로그램 테스트 목표)

• First goal: To demonstrate to the developer and the customer that the software meets its requirements.
  (첫 번째 목표: 개발자와 고객에게 소프트웨어가 요구사항을 충족함을 보여주는 것)
  
  • For custom software, this means that there should be at least one test for every requirement in the requirements document.
    (맞춤형 소프트웨어의 경우, 요구사항 문서에 있는 모든 요구사항마다 적어도 하나의 테스트가 있어야 한다.)
  • For generic software products, it means that there should be tests for all of the system features, plus combinations of these features, that will be incorporated in the product release.
    (범용 소프트웨어 제품의 경우, 모든 시스템 기능 및 이 기능들의 조합에 대한 테스트가 제품 출시 전에 준비되어야 한다.)
• Second goal: To discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification.
  (두 번째 목표: 소프트웨어의 동작이 부정확하거나 바람직하지 않거나 명세를 따르지 않는 상황을 발견하는 것)
  
  • Defect testing is concerned with rooting out undesirable system behavior such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption.
    (결함 테스트는 시스템 충돌, 다른 시스템과의 비정상적 상호작용, 잘못된 계산, 데이터 손상과 같은 바람직하지 않은 시스템 동작을 찾아내는 것과 관련이 있다.)

 

Validation and defect testing (검증 테스트와 결함 테스트)

• The first goal leads to validation testing
  (첫 번째 목표는 검증(Validation) 테스트로 이어진다)
  
  • You expect the system to perform correctly using a given set of test cases that reflect the system’s expected use.
    (예상되는 시스템 사용을 반영하는 테스트 케이스를 사용해 시스템이 올바르게 작동하는지 확인한다.)
• The second goal leads to defect testing
  (두 번째 목표는 결합(Defect) 테스트로 이어진다)
  
  • The test cases are designed to expose defects. The test cases in defect testing can be deliberately obscure and need not reflect how the system is normally used.
    (테스트 케이스는 결함을 드러내기 위해 설계된다. 결함 테스트에서는 일부러 비정상적 상황을 만들어 시스템의 일반 사용 방식을 반영하지 않을 수도 있다.)

 

Testing process goals (테스트 프로세스의 목표)

• Validation testing (검증 테스트)
  • To demonstrate to the developer and the system customer that the software meets its requirements
    (소프트웨어가 요구사항을 충족하는지 개발자와 고객에게 입증하는 것)
  • A successful test shows that the system operates as intended.
    (성공적인 테스트는 시스템이 의도대로 작동함을 보여준다.)
• Defect testing (결함 테스트)
  • To discover faults or defects in the software where its behaviour is incorrect or not in conformance with its specification
    (소프트웨어의 동작이 잘못됐거나 명세를 따르지 않는 결함을 발견하는 것)
  • A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system.
    (성공적인 결함 테스트는 시스템이 잘못 작동하도록 유도하여 결함을 드러내는 테스트이다.)

 

An input-output model of program testing (프로그램 테스트의 입력-출력 모델)

 

 

Verification vs. validation (검증 vs. 확인)

• Verification: "Are we building the product right?”
  (검증: "우리는 제품을 올바르게 만들고 있는가?")
  
  • The software should conform to its specification.
    (소프트웨어는 명세에 부합해야 한다.)
• Validation: "Are we building the right product?”
  (확인: "우리는 올바른 제품을 만들고 있는가?")
  
  • The software should do what the user really requires.
    (소프트웨어는 사용자가 실제로 요구하는 기능을 수행해야 한다.)

 

V & V confidence (검증과 확인에 대한 신뢰 수준)

• Aim of V & V is to establish confidence that the system is ‘fit for purpose’.
  (검증 및 확인의 목적은 시스템이 '목적에 적합함'을 확신시키는 것이다.)
• The level of V & V confidence depends on system’s purpose, user expectations and marketing environment
  (신뢰 수준은 시스템 목적, 사용자 기대치, 시장 환경에 따라 달라진다.)
  
  • Software purpose (소프트웨어 목적)
    • The level of confidence depends on how critical the software is to an organisation.
      (소프트웨어가 조직에 얼마나 중요한지에 따라 신뢰 수준이 결정된다.)
  • User expectations (사용자 기대)
    • Users may have low expectations of certain kinds of software.
      (특정 종류의 소프트웨어에 대해 사용자의 기대치가 낮을 수도 있다.)
  • Marketing environment (시장 환경)
    • Getting a product to market early may be more important than finding defects in the program.
      (프로그램의 결함을 찾는 것보다 제품을 빨리 출시하는 것이 더 중요할 수 있다.)

 

Inspections and testing (검토와 테스트)

• Software inspections (소프트웨어 검토)
  • Concerned with analysis of the static system representation to discover problems (static verification)
    (시스템의 정적 표현을 분석하여 문제를 발견하는 것(정적 검증))
  • May be supplement by tool-based document and code analysis.
    (도구 기반의 문서 및 코드 분석으로 보완될 수 있다.)
• Software testing (소프트웨어 테스트)
  • Concerned with exercising and observing product behaviour (dynamic verification)
    (제품의 동작을 실행하고 관찰하는 것(동적 검증))
  • The system is executed with test data and its operational behaviour is observed.
    (테스트 데이터를 사용해 시스템을 실행하고 작동 행동을 관찰한다.)

 

Software inspections (소프트웨어 검토)

• These involve people examining the source representation with the aim of discovering anomalies and defects.
  (사람들이 소스 표현을 검토하여 이상과 결함을 발견하는 과정이다.)
• Inspections not require execution of a system so may be used before implementation.
  (검토는 시스템 실행이 필요하지 않으므로 구현 전에 사용할 수 있다.)
• They may be applied to any representation of the system (requirements, design, configuration data, test data, etc.).
  (요구사항, 설계, 설정 데이터, 테스트 데이터 등 시스템의 어떤 표현에도 적용할 수 있다.)
• They have been shown to be an effective technique for discovering program errors.
  (검토는 프로그램 오류를 발견하는 효과적인 방법으로 입증되었다.)

 

Advantages of inspections (검토의 장점)

• During testing, errors can mask (hide) other errors. Because inspection is a static process, you don’t have to be concerned with interactions between errors.
  (테스트 중에는 하나의 오류가 다른 오류를 가릴 수 있지만, 검토는 정적 과정이기 때문에 오류 간 상호작용을 걱정할 필요가 없다.)
  
  • A single inspection session may discover many errors.(하나의 검토 세션에서 많은 오류를 발견할 수 있다.)
• Incomplete versions of a system can be inspected without additional costs.
  (시스템의 불완전한 버전도 추가 비용 없이 검토할 수 있다.)
• As well as searching for program defects, an inspection can also consider broader quality attributes of a program, such as compliance with standards, portability and maintainability.
  (프로그램 결함 외에도, 표준 준수, 이식성, 유지보수성 같은 품질 특성도 검토할 수 있다.)

 

Inspections and testing (검토와 테스트 비교)

• Inspections and testing are complementary and not opposing verification techniques.
  (검토와 테스트는 서로 보완적인 검증 기술이다.)
• Both should be used during the V & V process.
  (V & V 과정에서는 둘 다 사용해야 한다.)
• Inspections can check conformance with a specification but not conformance with the customer’s real requirements.
  (검토는 명세 준수는 확인할 수 있지만 고객의 실제 요구사항 준수는 확인할 수 없다.)
• Inspections cannot check non-functional characteristics such as performance, usability, etc.
  (검토는 성능, 사용성 등 비기능적 특성은 확인할 수 없다.)

 

Limitations of inspections (검토의 한계)

• Not good for discovering defects that arise because of unexpected interactions between different parts of a program, timing problems, or problems with system performance.
  (프로그램 여러 부분 간 예상치 못한 상호작용, 타이밍 문제, 시스템 성능 문제로 인한 결함을 찾는 데는 부적합하다.)
  
  • So, software testing is required.
    (따라서 소프트웨어 테스트가 필요하다.)
• Difficult and expensive to put a separate inspection team.
  (별도의 검토 팀을 꾸리는 것은 어렵고 비용이 많이 든다.)
  
  • Static analysis can provide solutions for this limitation.
    (정적 분석 도구가 이 한계를 보완할 수 있다.)

 

A model of the software testing process (소프트웨어 테스트 프로세스 모델)

• Test case = test inputs (data) + expected results + what is being tested.
  (테스트 케이스 = 테스트 입력(데이터) + 기대 결과 + 테스트 대상)
• Automatic test case generation is impossible???
  (자동 테스트 케이스 생성은 불가능???)

 

Stages of testing (테스트 단계)

• Development testing, where the system is tested during development to discover bugs and defects.
  (개발 중에 버그와 결함을 찾기 위해 수행하는 테스트)
• Release testing, where a separate testing team test a complete version of the system before it is released to users.
  (사용자에게 출시하기 전, 별도 테스트 팀이 시스템 전체를 테스트하는 것)
• User testing, where users or potential users of a system test the system in their own environment.
  (사용자 또는 잠재 사용자들이 실제 환경에서 시스템을 테스트하는 것)

 

 

 

[2] Development testing

Development testing (개발 테스트)

• Development testing includes all testing activities that are carried out by the team developing the system.
  (개발 테스트는 시스템을 개발하는 팀이 수행하는 모든 테스트 활동을 포함한다.)
  
  • Unit testing, where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.
    (단위 테스트: 개별 프로그램 단위나 객체 클래스를 테스트하는 것. 객체나 메소드의 기능 테스트에 중점을 둔다.)
  • Component testing, where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces.
    (컴포넌트 테스트: 여러 개별 단위를 통합하여 복합 컴포넌트를 만드는 것. 컴포넌트 인터페이스 테스트에 중점을 둔다.)
  • System testing, where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions.
    (시스템 테스트: 시스템 내 일부 또는 모든 컴포넌트를 통합하여 시스템 전체를 테스트하는 것. 컴포넌트 간 상호작용 테스트에 중점을 둔다.)

 

Unit testing (단위 테스트)

• Unit testing is the process of testing individual components in isolation.
  (단위 테스트는 개별 컴포넌트를 독립적으로 테스트하는 과정이다.)
• It is a defect testing process.
  (이는 결함 테스트 과정이다.)
• Units may be:
  (단위는 다음을 포함할 수 있다:)
  
  • Individual functions or methods within an object
    (객체 내의 개별 함수나 메소드)
  • Object classes with several attributes and methods
    (여러 속성과 메소드를 가진 객체 클래스)
  • Composite components with defined interfaces used to access their functionality.
    (기능에 접근하기 위해 정의된 인터페이스를 사용하는 복합 컴포넌트)

 

Unit testing: Object class testing (단위 테스트: 객체 클래스 테스트)

• Complete test coverage of a class involves
  (클래스에 대한 완전한 테스트 커버리지는 다음을 포함한다)
  
  • Testing all operations associated with an object
    (객체와 관련된 모든 연산 테스트)
  • Setting and interrogating all object attributes
    (모든 객체 속성 설정 및 조회)
  • Exercising the object in all possible states.
    (객체를 모든 가능한 상태에서 테스트)
• Inheritance makes it more difficult to design object class tests as the information to be tested is not localised.
  (상속은 테스트해야 할 정보가 지역화되어 있지 않기 때문에 객체 클래스 테스트를 설계하기 어렵게 만든다.)

 

Unit testing: The weather station object interface (단위 테스트: 웨더 스테이션 객체 인터페이스)

 

Unit testing: Weather station testing (단위 테스트: 웨더 스테이션 테스트)

• Need to define test cases for all methods.
  (모든 메소드에 대한 테스트 케이스를 정의해야 한다.)
• Using a state model, identify sequences of state transitions to be tested and the event sequences to cause these transitions.
  (상태 모델을 사용하여 테스트할 상태 전이 순서와 이를 유발하는 이벤트 순서를 식별한다.)
• For example: (예를 들면)
  • Shutdown -> Running -> Shutdown
    (종료 -> 실행 -> 종료)
  • Configuring -> Running -> Testing -> Transmitting -> Running
    (구성 중 -> 실행 -> 테스트 중 -> 전송 중 -> 실행)
  • Running -> Collecting -> Running -> Summarizing -> Transmitting -> Running
    (실행 -> 수집 -> 실행 -> 요약 -> 전송 -> 실행)

 

Unit testing: Automated testing (단위 테스트: 자동화 테스트)

• Whenever possible, unit testing should be automated so that tests are run and checked without manual intervention.
  (가능한 경우 단위 테스트는 자동화되어야 하며 수동 개입 없이 실행되고 확인되어야 한다.)
• In automated unit testing, you make use of a test automation framework (such as JUnit) to write and run your program tests.
  (자동화 단위 테스트에서는 JUnit 같은 테스트 자동화 프레임워크를 사용하여 테스트를 작성하고 실행한다.)
• Unit testing frameworks provide generic test classes that you extend to create specific test cases. They can then run all of the tests that you have implemented and report, often through some GUI, on the success of otherwise of the tests.
  (단위 테스트 프레임워크는 특정 테스트 케이스를 만들기 위해 확장할 수 있는 일반 테스트 클래스를 제공한다. 이후 구현된 모든 테스트를 실행하고, 종종 GUI를 통해 성공 여부를 보고한다.)

 

Unit testing: Automated test components (단위 테스트: 자동화 테스트 구성요소)

• A setup part, where you initialize the system with the test case, namely the inputs and expected outputs.
  (시스템을 테스트 케이스로 초기화하는 설정 단계, 즉 입력과 기대 출력값을 설정하는 부분)
• A call part, where you call the object or method to be tested.
  (테스트할 객체나 메소드를 호출하는 부분)
• An assertion part where you compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful; if false, then it has failed.
  (호출 결과를 기대 결과와 비교하는 단언(assertion) 단계. 단언이 참이면 테스트 성공, 거짓이면 실패이다.)

 

Choosing unit test cases (단위 테스트 케이스 선택하기)

• The test cases should show that, when used as expected, the component that you are testing does what it is supposed to do.
  (테스트 케이스는 컴포넌트가 예상대로 작동함을 보여야 한다.)
• If there are defects in the component, these should be revealed by test cases.
  (컴포넌트에 결함이 있다면 테스트 케이스로 드러나야 한다.)
• This leads to 2 types of unit test case
  (이로 인해 두 가지 종류의 단위 테스트 케이스가 생긴다)
  
  • The first of these should reflect normal operation of a program and should show that the component works as expected.
    (첫 번째는 정상 작동을 반영하고 컴포넌트가 예상대로 작동하는 것을 보여야 한다.)
  • The other kind of test case should be based on testing experience of where common problems arise. It should use abnormal inputs to check that these are properly processed and do not crash the component.
    (다른 하나는 일반적으로 발생하는 문제 경험을 기반으로 하며, 비정상 입력을 사용하여 컴포넌트가 제대로 처리하고 크래시가 발생하지 않는지 확인해야 한다.)

 

Choosing unit test cases: Testing strategies (단위 테스트 케이스 선택: 테스트 전략)

• Partition testing, where you identify groups of inputs that have common characteristics and should be processed in the same way.
• (입력이 공통 특징을 가지는 그룹으로 나누어지고 동일하게 처리되어야 하는지 테스트하는 기법)
  
  • You should choose tests from within each of these groups.
    (각 그룹 내에서 테스트를 선택해야 한다.)
• Guideline-based testing, where you use testing guidelines to choose test cases.
  (테스트 지침을 기반으로 테스트 케이스를 선택하는 방식)
  
  • These guidelines reflect previous experience of the kinds of errors that programmers often make when developing components.
    (이 지침은 개발자가 컴포넌트를 개발할 때 자주 저지르는 오류 경험을 반영한다.)

 

Choosing unit test cases: Partition testing (단위 테스트 케이스 선택: 분할 테스트)

• Input data and output results often fall into different classes where all members of a class are related.
  (입력 데이터와 출력 결과는 종종 관련된 여러 클래스로 구분된다.)
• Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member.
  (각 클래스는 동등 분할(equivalence partition) 또는 도메인으로, 프로그램이 각 구성원에 대해 동일하게 작동한다.)
• Test cases should be chosen from each partition.
  (각 분할에서 테스트 케이스를 선택해야 한다.)

 

Equivalence partitioning (동등 분할)

 

Equivalence partitions (동등 분할 예시)

• The system accepts four to ten inputs which are five-digit integers.
  (시스템은 네 개에서 열 개 사이의 다섯 자리 정수를 입력으로 허용한다.)

 

Choosing unit test cases: Testing guidelines (sequences)

(단위 테스트 케이스 선택: 테스트 가이드라인 - 시퀀스)

• Test software with sequences which have only a single value.
  (값이 하나뿐인 시퀀스로 소프트웨어를 테스트하라.)
• Use sequences of different sizes in different tests.
  (다양한 크기의 시퀀스를 사용하여 테스트하라.)
• Derive tests so that the first, middle and last elements of the sequence are accessed.
  (시퀀스의 처음, 중간, 마지막 요소에 접근하는 테스트를 설계하라.)
• Test with sequences of zero length.
  (길이가 0인 시퀀스로 테스트하라.)

 

Choosing unit test cases: General testing guidelines

(단위 테스트 케이스 선택: 일반 테스트 가이드라인)

• Choose inputs that force the system to generate all error messages.
  (시스템이 모든 오류 메시지를 생성하도록 강제하는 입력을 선택하라.)
• Design inputs that cause input buffers to overflow.
  (입력 버퍼가 오버플로우되도록 입력을 설계하라.)
• Repeat the same input or series of inputs numerous times.
  (동일한 입력이나 입력 시퀀스를 여러 번 반복하라.)
• Force invalid outputs to be generated.
  (잘못된 출력이 생성되도록 강제하라.)
• Force computation results to be too large or too small.
  (계산 결과가 너무 크거나 작도록 강제하라.)

-> In short, try extreme cases!

(요약하면, 극단적인 케이스를 시도하라!)

 

Component testing (컴포넌트 테스트)

• Software components are often composite components that are made up of several interacting objects.
• (소프트웨어 컴포넌트는 종종 여러 상호작용하는 객체로 구성된 복합 컴포넌트이다.)
  
  • For example, in the weather station system, the reconfiguration component includes objects that deal with each aspect of the reconfiguration.
    (예를 들어, 웨더 스테이션 시스템에서 재구성 컴포넌트는 재구성의 각 측면을 다루는 객체들을 포함한다.)
• You access the functionality of these objects through the defined component interface.
  (이 객체들의 기능은 정의된 컴포넌트 인터페이스를 통해 접근한다.)
• Testing composite components should therefore focus on showing that the component interface behaves according to its specification.
  (따라서 복합 컴포넌트 테스트는 컴포넌트 인터페이스가 명세에 따라 동작하는지 보여주는 데 집중해야 한다.)
  
  • You can assume that unit tests on the individual objects within the component have been completed.
    (컴포넌트 내 개별 객체에 대한 단위 테스트는 완료되었다고 가정할 수 있다.)

 

Interface testing (인터페이스 테스트)

• Objectives are to detect faults due to interface errors or invalid assumptions about interfaces.
  (인터페이스 오류나 인터페이스에 대한 잘못된 가정으로 인한 결함을 발견하는 것이 목표이다.)
• Interface types (인터페이스 종류)
  • Parameter interfaces: Data passed from one method or procedure to another.
    (파라미터 인터페이스: 하나의 메소드나 프로시저에서 다른 곳으로 데이터를 전달)
  • Shared memory interfaces: Block of memory is shared between procedures or functions.
    (공유 메모리 인터페이스: 프로시저나 함수 간에 메모리 블록을 공유)
  • Procedural interfaces: Subsystem encapsulates a set of procedures to be called by other subsystems.
    (프로시저 인터페이스: 서브시스템이 다른 서브시스템에서 호출될 프로시저 집합을 캡슐화)
  • Message passing interfaces: Sub-systems request services from other subsystems
    (메시지 전달 인터페이스: 서브시스템이 다른 서브시스템에 서비스를 요청)

 

Interface testing (인터페이스 테스트)

 

Interface errors (인터페이스 오류)

• Interface misuse (인터페이스 오용)
  • A calling component calls another component and makes an error in its use of its interface, e.g. parameters in the wrong order.
    (호출 컴포넌트가 다른 컴포넌트를 호출할 때 인터페이스 사용 오류를 범함. 예: 파라미터 순서를 잘못 전달.)
• Interface misunderstanding (인터페이스 오해)
  • A calling component embeds assumptions about the behaviour of the called component which are incorrect.
    (호출 컴포넌트가 호출된 컴포넌트의 동작에 대해 잘못된 가정을 가짐.)
• Timing errors (타이밍 오류) 
  • The called and the calling component operate at different speeds and out-of-date information is accessed.
    (호출자와 호출 대상 컴포넌트가 서로 다른 속도로 작동하여 오래된 정보에 접근하게 됨.)

 

Interface testing guidelines (인터페이스 테스트 가이드라인)

• Design tests so that parameters to a called procedure are at the extreme ends of their ranges.
  (호출 프로시저의 파라미터가 허용 범위의 극단값을 갖도록 테스트를 설계하라.)
• Always test pointer parameters with null pointers.
  (포인터 파라미터는 항상 널(null) 포인터로도 테스트하라.)
• Design tests which cause the component to fail.
  (컴포넌트가 실패하도록 테스트를 설계하라.)
• Use stress testing in message passing systems.
  (메시지 전달 시스템에서는 스트레스 테스트를 사용하라.)
• In shared memory systems, vary the order in which components are activated.
  (공유 메모리 시스템에서는 컴포넌트가 활성화되는 순서를 다양하게 하라.)

 

System testing (시스템 테스트)

• System testing during development involves integrating components to create a version of the system and then testing the integrated system.
  (개발 중 시스템 테스트는 컴포넌트를 통합하여 시스템 버전을 만들고 이를 테스트하는 것이다.)
• The focus in system testing is testing the interactions between components.
  (시스템 테스트의 초점은 컴포넌트 간의 상호작용 테스트이다.)
• System testing checks that components are compatible, interact correctly and transfer the right data at the right time across their interfaces.
  (시스템 테스트는 컴포넌트가 호환되고 올바르게 상호작용하며 인터페이스를 통해 적절한 시점에 적절한 데이터를 전송하는지 확인한다.)
• System testing tests the emergent behaviour of a system.
  (시스템 테스트는 시스템의 출현적(emergent) 행동을 검증한다.)

 

System and component testing (시스템 및 컴포넌트 테스트)

• During system testing, reusable components that have been separately developed and off-the-shelf systems may be integrated with newly developed components. The complete system is then tested.
  (시스템 테스트 동안 별도로 개발된 재사용 컴포넌트와 상용(off-the-shelf) 시스템이 새로 개발된 컴포넌트와 통합될 수 있다. 이후 전체 시스템이 테스트된다.)
• Components developed by different team members or sub-teams may be integrated at this stage. System testing is a collective rather than an individual process.
  (다른 팀원이나 하위 팀이 개발한 컴포넌트가 이 단계에서 통합될 수 있다. 시스템 테스트는 개인이 아닌 집단적 프로세스이다.)
  
  • In some companies, system testing may involve a separate testing team with no involvement from designers and programmers.
    (일부 회사에서는 시스템 테스트를 전담하는 별도의 테스트 팀이 디자이너나 프로그래머와 별개로 운영되기도 한다.)

 

Use-case testing (유스케이스 테스트)

• The use-cases developed to identify system interactions can be used as a basis for system testing.
  (시스템 상호작용을 정의하기 위해 개발한 유스케이스를 시스템 테스트의 기반으로 사용할 수 있다.)
• Each use case usually involves several system components so testing the use case forces these interactions to occur.
  (각 유스케이스는 여러 시스템 컴포넌트를 포함하므로 유스케이스를 테스트하면 상호작용이 발생하게 된다.)
• The sequence diagrams associated with the use case documents the components and interactions that are being tested.
  (유스케이스에 연관된 시퀀스 다이어그램은 테스트되는 컴포넌트와 상호작용을 문서화한다.)

 

Collect weather data sequence chart (날씨 데이터 수집 시퀀스 차트)

 

Test cases derived from sequence diagram (시퀀스 다이어그램으로부터 파생된 테스트 케이스)

• An input of a request for a report should have an associated acknowledgement. A report should ultimately be returned from the request.
  (보고서 요청 입력에는 확인 응답이 있어야 하며, 요청으로부터 최종적으로 보고서가 반환되어야 한다.)
  
  • You should create summarized data that can be used to check that the report is correctly organized.
    (보고서가 올바르게 구성되었는지 확인할 수 있도록 요약 데이터를 준비해야 한다.)
• An input request for a report to WeatherStation results in a summarized report being generated.
  (WeatherStation에 보고서 요청 입력을 하면 요약된 보고서가 생성된다.)
  
  • Can be tested by creating raw data corresponding to the summary that you have prepared for the test of SatComms and checking that the WeatherStation object correctly produces this summary. This raw data is also used to test the WeatherData object.
    (SatComms 테스트를 위해 준비한 요약 데이터에 해당하는 원시 데이터를 생성하여 WeatherStation 객체가 올바르게 요약 보고서를 생성하는지 확인할 수 있다. 이 원시 데이터는 WeatherData 객체 테스트에도 사용된다.)

 

System Testing policies (시스템 테스트 정책)

• Exhaustive system testing is impossible so testing policies which define the required system test coverage may be developed.
  (모든 경우를 망라하는 시스템 테스트는 불가능하기 때문에, 필요한 테스트 커버리지를 정의하는 테스트 정책을 수립할 수 있다.)
• Examples of testing policies (테스트 정책 예시)
  • All system functions that are accessed through menus should be tested.
    (메뉴를 통해 접근 가능한 모든 시스템 기능을 테스트해야 한다.)
  • Combinations of functions (e.g. text formatting) that are accessed through the same menu must be tested.
    (같은 메뉴를 통해 접근하는 기능 조합(예: 텍스트 포맷팅)을 테스트해야 한다.)
  • Where user input is provided, all functions must be tested with both correct and incorrect input.
    (사용자 입력이 필요한 경우, 올바른 입력과 잘못된 입력 모두로 기능을 테스트해야 한다.)

 

[3] Test-driven development

Test-driven development (테스트 주도 개발)

• Test-driven development (TDD) is an approach to program development in which you inter-leave testing and code development.
  (테스트 주도 개발(TDD)은 테스트와 코드 개발을 번갈아 가며 진행하는 프로그램 개발 접근법이다.)
• Tests are written before code and ‘passing’ the tests is the critical driver of development.
  (코드를 작성하기 전에 테스트를 작성하고, 이 테스트를 통과하는 것이 개발의 핵심 동력이 된다.)
• You develop code incrementally, along with a test for that increment. You don’t move on to the next increment until the code that you have developed passes its test.
  (코드를 작은 단위로 점진적으로 개발하며, 해당 단위마다 테스트를 작성한다. 작성한 코드가 테스트를 통과하기 전까지는 다음 단위로 넘어가지 않는다.)
• TDD was introduced as part of agile methods such as Extreme Programming. However, it can also be used in plan-driven development processes.
  (TDD는 익스트림 프로그래밍(Extreme Programming) 같은 애자일 방법론의 일부로 도입되었지만, 계획 기반(plan-driven) 개발 프로세스에서도 사용할 수 있다.)

 

Test-driven development (테스트 주도 개발)

 

TDD process activities (TDD 프로세스 활동)

• Start by identifying the increment of functionality that is required. This should normally be small and implementable in a few lines of code.
  (필요한 기능의 작은 단위를 식별하는 것부터 시작한다. 이 단위는 보통 몇 줄의 코드로 구현 가능한 정도여야 한다.)
• Write a test for this functionality and implement this as an automated test.
  (이 기능을 위한 테스트를 작성하고, 자동화된 테스트로 구현한다.)
• Run the test, along with all other tests that have been implemented. Initially, you have not implemented the functionality so the new test will fail.
  (작성한 다른 테스트들과 함께 이 테스트를 실행한다. 처음에는 기능이 구현되지 않았기 때문에 새 테스트는 실패할 것이다.)
• Implement the functionality and re-run the test.
  (기능을 구현하고 다시 테스트를 실행한다.)
• Once all tests run successfully, you move on to implementing the next chunk of functionality.
  (모든 테스트가 성공하면 다음 기능 단위 구현으로 넘어간다.)

Benefits of test-driven development (TDD의 이점)

• Code coverage (코드 커버리지)
  • Every code segment that you write has at least one associated test so all code written has at least one test.
    (작성하는 모든 코드 구간마다 최소 하나의 테스트가 연결되기 때문에, 작성된 모든 코드에는 최소 하나 이상의 테스트가 존재한다.)
• Regression testing (회귀 테스트)
  • A regression test suite is developed incrementally as a program is developed.
    (프로그램 개발과 함께 점진적으로 회귀 테스트 스위트가 구축된다.)
• Simplified debugging (디버깅 단순화)
  • When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified.
    (테스트가 실패하면 문제의 위치를 쉽게 알 수 있다. 새로 작성한 코드를 점검하고 수정하면 된다.)
• System documentation (시스템 문서화)
  • The tests themselves are a form of documentation that describe what the code should be doing.
    (테스트 자체가 코드가 어떤 동작을 해야 하는지를 설명하는 문서의 역할을 한다.)

 

Regression testing (회귀 테스트)

• Regression testing is testing the system to check that changes have not ‘broken’ previously working code.
  (회귀 테스트는 변경 사항이 기존에 정상 작동하던 코드를 망치지 않았는지 확인하는 테스트이다.)
• In a manual testing process, regression testing is expensive but, with automated testing, it is simple and straightforward. All tests are rerun every time a change is made to the program.
  (수동 테스트에서는 회귀 테스트 비용이 많이 들지만, 자동화 테스트에서는 간단하고 직관적이다. 프로그램에 변경이 있을 때마다 모든 테스트가 다시 실행된다.)
• Tests must run ‘successfully’ before the change is committed.
  (변경 사항을 커밋하기 전에 테스트가 모두 성공해야 한다.)
  
  • In OSS development (오픈소스 개발에서는)
    
    • Submit pull request
      (풀 리퀘스트를 제출한다.)
      → Regression testing is conducted automatically in a continuous integration tool.
      (회귀 테스트는 지속적 통합(CI) 도구를 통해 자동으로 수행된다.)
      → A committee decides if the pull request can be merged or not.
      (위원회가 풀 리퀘스트를 병합할지 여부를 결정한다.)
      → Report a testing result(테스트 결과가 보고된다.)

 

 

 

[4] Release testing

Release testing (릴리스 테스트)

• Release testing is the process of testing a particular release of a system that is intended for use outside of the development team.
  (릴리스 테스트는 개발팀 외부 사용을 위해 준비된 시스템 릴리스를 테스트하는 과정이다.)
• The primary goal of the release testing process is to convince the supplier of the system that it is good enough for use.
  (릴리스 테스트의 주된 목표는 시스템 공급자에게 시스템이 사용하기에 충분히 괜찮다는 확신을 주는 것이다.)
  
  • Release testing, therefore, has to show that the system delivers its specified functionality, performance and dependability, and that it does not fail during normal use.
    (따라서 릴리스 테스트는 시스템이 명시된 기능, 성능, 신뢰성을 제공하며 정상 사용 중에 실패하지 않는다는 것을 보여야 한다.)
• Release testing is usually a black-box testing process where tests are only derived from the system specification.
  (릴리스 테스트는 보통 시스템 명세만을 기준으로 테스트를 작성하는 블랙박스 테스트 과정이다.)

 

Release testing and system testing (릴리스 테스트와 시스템 테스트)

• Release testing is a form of system testing.
  (릴리스 테스트는 시스템 테스트의 한 형태이다.)
• Important differences (중요한 차이점)
  
  • A separate team that has not been involved in the system development, should be responsible for release testing.
    (시스템 개발에 참여하지 않은 별도의 팀이 릴리스 테스트를 담당해야 한다.)
  • System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing).
    (개발팀의 시스템 테스트는 결함을 찾는 것(defect testing)에 집중해야 하고, 릴리스 테스트는 시스템이 요구사항을 충족하고 외부 사용에 충분히 적합한지 검증(validation testing)하는 것이 목표이다.)

 

Requirements based testing (요구사항 기반 테스트)

• Requirements-based testing involves examining each requirement and developing a test or tests for it.
  (요구사항 기반 테스트는 각 요구사항을 검토하고 이를 위한 테스트를 개발하는 것을 포함한다.)
• Mentcare system requirements (Mentcare 시스템 요구사항) 
  • If a patient is known to be allergic to any particular medication, then prescription of that medication shall result in a warning message being issued to the system user.
    (환자가 특정 약물에 알레르기가 있는 것으로 알려진 경우, 해당 약물 처방 시 시스템 사용자가 경고 메시지를 받도록 해야 한다.)
  • If a prescriber chooses to ignore an allergy warning, they shall provide a reason why this has been ignored.
    (처방자가 알레르기 경고를 무시하기로 선택한 경우, 그 이유를 입력해야 한다.)

 

Requirements tests (요구사항 테스트)

• Set up a patient record with no known allergies. Prescribe medication for allergies that are known to exist. Check that a warning message is not issued by the system.
  (알려진 알레르기가 없는 환자 기록을 설정하고, 기존 알레르기에 대해 약물을 처방한 후 경고 메시지가 발생하지 않는지 확인한다.)
• Set up a patient record with a known allergy. Prescribe the medication to that the patient is allergic to, and check that the warning is issued by the system.
  (알려진 알레르기가 있는 환자 기록을 설정하고, 해당 약물을 처방하여 경고 메시지가 발생하는지 확인한다.)
• Set up a patient record in which allergies to two or more drugs are recorded. Prescribe both of these drugs separately and check that the correct warning for each drug is issued.
  (두 가지 이상의 약물에 대한 알레르기가 기록된 환자 기록을 설정하고, 각각 약물을 처방하여 각각 올바른 경고가 발생하는지 확인한다.)
• Prescribe two drugs that the patient is allergic to. Check that two warnings are correctly issued.
  (환자가 알레르기가 있는 두 약물을 처방하고 두 개의 경고가 올바르게 발생하는지 확인한다.)
• Prescribe a drug that issues a warning and overrule that warning. Check that the system requires the user to provide information explaining why the warning was overruled.
  (경고가 발생하는 약물을 처방하고 경고를 무시한 후, 시스템이 경고를 무시한 이유를 입력하도록 요구하는지 확인한다.)

 

A usage scenario for the Mentcare system (Mentcare 시스템 사용 시나리오)

• George is a nurse who specializes in mental healthcare. One of his responsibilities is to visit patients at home to check that their treatment is effective and that they are not suffering from medication side effects.
  (조지는 정신 건강 관리 전문 간호사이다. 그의 업무 중 하나는 환자를 방문하여 치료 효과와 약물 부작용 여부를 확인하는 것이다.)
• On a day for home visits, George logs into the Mentcare system and uses it to print his schedule of home visits for that day, along with summary information about the patients to be visited. He requests that the records for these patients be downloaded to his laptop. He is prompted for his key phrase to encrypt the records on the laptop.
  (방문일에 조지는 Mentcare 시스템에 로그인하여 방문 일정을 출력하고, 방문할 환자들의 요약 정보를 출력한다. 환자 기록을 자신의 노트북에 다운로드하고, 기록 암호화를 위해 키 문구를 입력한다.)
• One of the patients that he visits is Jim, who is being treated with medication for depression. Jim feels that the medication is helping him but believes that it has the side effect of keeping him awake at night. George looks up Jim’s record and is prompted for his key phrase to decrypt the record. He checks the drug prescribed and queries its side effects. Sleeplessness is a known side effect so he notes the problem in Jim’s record and suggests that he visits the clinic to have his medication changed. Jim agrees so George enters a prompt to call him when he gets back to the clinic to make an appointment with a physician. George ends the consultation and the system re-encrypts Jim’s record.
  (조지가 방문한 환자 중 한 명은 우울증 치료를 받고 있는 짐이다. 짐은 약물이 도움이 되고 있지만 밤에 잠을 자지 못하게 한다고 느낀다. 조지는 짐의 기록을 열람하고, 암호 해독을 위해 키 문구를 입력한다. 그는 처방된 약을 확인하고 부작용을 조회한다. 불면증이 알려진 부작용이므로 짐의 기록에 이 문제를 기록하고 약물 변경을 위해 클리닉 방문을 제안한다. 짐이 동의하자, 조지는 짐이 클리닉에 돌아왔을 때 예약할 수 있도록 콜 프롬프트를 입력한다. 상담이 끝나면 시스템은 짐의 기록을 다시 암호화한다.)
• After finishing his consultations, George returns to the clinic and uploads the records of patients visited to the database. The system generates a call list for George of those patients who he has to contact for follow-up information and make clinic appointments.
  (조지는 상담을 마친 후 클리닉으로 돌아와 환자 기록을 데이터베이스에 업로드한다. 시스템은 조지가 후속 정보를 위해 연락해야 하는 환자들의 콜 리스트를 생성한다.)

 

Features tested by scenario (시나리오를 통해 테스트되는 기능)

• Authentication by logging on to the system.
  (시스템 로그인 인증)
• Downloading and uploading of specified patient records to a laptop.
  (지정된 환자 기록의 노트북 다운로드 및 업로드)
• Home visit scheduling.
  (방문 일정 관리)
• Encryption and decryption of patient records on a mobile device.
  (모바일 기기에서 환자 기록의 암호화 및 복호화)
• Record retrieval and modification.
  (기록 검색 및 수정)
• Links with the drugs database that maintains side-effect information.
  (부작용 정보를 유지하는 약물 데이터베이스 연동)
• The system for call prompting.
  (콜 프롬프트 시스템)

 

Performance testing (성능 테스트)

• Part of release testing may involve testing the emergent properties of a system, such as performance and reliability.
  (릴리스 테스트의 일부는 시스템의 성능 및 신뢰성과 같은 출현 속성을 테스트하는 것을 포함할 수 있다.)
• Tests should reflect the profile of use of the system.
  (테스트는 시스템 사용 프로파일을 반영해야 한다.)
• Performance tests usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable.
  (성능 테스트는 일반적으로 부하를 점진적으로 증가시키면서 시스템 성능이 수용할 수 없을 정도로 저하될 때까지 진행된다.)
• Stress testing is a form of performance testing where the system is deliberately overloaded to test its failure behaviour.
  (스트레스 테스트는 시스템에 일부러 과부하를 걸어 실패 동작을 테스트하는 성능 테스트의 한 형태이다.)

 

User testing (사용자 테스트)

• User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing.
  (사용자 또는 고객 테스트는 시스템 테스트에 대한 피드백과 조언을 제공하는 테스트 프로세스 단계이다.)
• User testing is essential, even when comprehensive system and release testing have been carried out.
  (포괄적인 시스템 및 릴리스 테스트를 수행했다 하더라도 사용자 테스트는 필수적이다.)
  
  • The reason for this is that influences from the user’s working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment.
    (이는 사용자의 실제 작업 환경이 시스템의 신뢰성, 성능, 사용성, 견고성에 큰 영향을 미치기 때문이다. 이런 환경은 테스트 환경에서 완전히 재현할 수 없다.)

 

Types of user testing (사용자 테스트 종류)

• Alpha testing (알파 테스트)
  • Users of the software work with the development team to test the software at the developer’s site.
    (소프트웨어 사용자가 개발자 사이트에서 개발팀과 함께 소프트웨어를 테스트하는 것)
• Beta testing (베타 테스트)
  • A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
  • (소프트웨어 릴리스를 사용자에게 제공하여 사용자가 시험하고 발견한 문제를 개발자에게 알리는 과정)
• Acceptance testing (인수 테스트)
  • Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.
  • (고객이 시스템을 테스트하여 시스템 개발자로부터 수용하고 고객 환경에 배포할 준비가 되었는지를 결정하는 과정. 주로 맞춤형 시스템에 해당)

 

The acceptance testing process (인수 테스트 프로세스)

 

Stages in the acceptance testing process (인수 테스트 과정의 단계)

• Define acceptance criteria
  (인수 기준 정의)
• Plan acceptance testing
  (인수 테스트 계획 수립)
• Derive acceptance tests
  (인수 테스트 도출)
• Run acceptance tests
  (인수 테스트 실행)
• Negotiate test results
  (테스트 결과 협상)
• Reject/accept system
  (시스템 수용 또는 거부 결정)

 

Agile methods and acceptance testing (애자일 방법론과 인수 테스트)

• In agile methods, the user/customer is part of the development team and is responsible for making decisions on the acceptability of the system.
  (애자일 방법론에서는 사용자/고객이 개발팀의 일원이며 시스템 수용 여부에 대한 결정을 내리는 책임을 진다.)
• Tests are defined by the user/customer and are integrated with other tests in that they are run automatically when changes are made.
  (테스트는 사용자/고객에 의해 정의되며, 다른 테스트와 통합되어 변경이 있을 때 자동으로 실행된다.)
• There is no separate acceptance testing process.
  (별도의 인수 테스트 프로세스가 존재하지 않는다.)
• Main problem here is whether or not the embedded user is ‘typical’ and can represent the interests of all system stakeholders.
  (여기서 주요 문제는 개발팀에 포함된 사용자가 '전형적인' 사용자이며 모든 이해관계자의 이익을 대표할 수 있는지 여부이다.)

 

Summary: Levels of software testing (commonly known these days) (요약: 소프트웨어 테스트 단계)

• Unit test: Test individual component
  (단위 테스트: 개별 컴포넌트를 테스트)
• Integration test: Test component groups
  (통합 테스트: 컴포넌트 그룹을 테스트)
• System test: Test the entire (integrated) system
  (시스템 테스트: 전체(통합된) 시스템을 테스트)
• Acceptance test: Test the final system by actual users
  (인수 테스트: 실제 사용자가 최종 시스템을 테스트)

C.f. In the textbook: (참고: 교재 기준 순서)

Unit testing >> Component testing >> System testing >> (Release testing) >> User testing (단위 테스트 >> 컴포넌트 테스트 >> 시스템 테스트 >> (릴리스 테스트) >> 사용자 테스트)

 

Key points (핵심 요점)

• Testing can only show the presence of errors in a program. It cannot demonstrate that there are no remaining faults.
  (테스트는 프로그램에 오류가 존재함을 보여줄 수는 있지만, 남은 결함이 없음을 증명할 수는 없다.)
• Development testing is the responsibility of the software development team. A separate team should be responsible for testing a system before it is released to customers.
  (개발 테스트는 소프트웨어 개발팀의 책임이다. 고객에게 시스템을 출시하기 전에 별도의 팀이 테스트를 담당해야 한다.)
• Development testing includes unit testing, in which you test individual objects and methods, component testing, in which you test related groups of objects, and system testing, in which you test partial or complete systems.
  (개발 테스트에는 개별 객체와 메소드를 테스트하는 단위 테스트, 관련 객체 그룹을 테스트하는 컴포넌트 테스트, 부분 또는 전체 시스템을 테스트하는 시스템 테스트가 포함된다.)
• When testing software, you should try to ‘break’ the software by using experience and guidelines to choose types of test case that have been effective in discovering defects in other systems.
  (소프트웨어 테스트 시에는 다른 시스템에서 결함을 잘 찾아낸 경험과 가이드를 활용하여 소프트웨어를 '깨뜨리는' 것을 목표로 해야 한다.)
• Wherever possible, you should write automated tests. The tests are embedded in a program that can be run every time a change is made to a system.
  (가능한 경우, 테스트를 자동화하여 시스템 변경 시마다 실행될 수 있도록 프로그램에 포함해야 한다.)
• Test-first development is an approach to development where tests are written before the code to be tested.
  (테스트 우선 개발은 코드를 작성하기 전에 테스트를 먼저 작성하는 개발 접근법이다.)
• Scenario testing involves inventing a typical usage scenario and using this to derive test cases.
  (시나리오 테스트는 일반적인 사용 시나리오를 만들어 이를 기반으로 테스트 케이스를 도출하는 것이다.)
• Acceptance testing is a user testing process where the aim is to decide if the software is good enough to be deployed and used in its operational environment.
  (인수 테스트는 소프트웨어가 운영 환경에 배포되고 사용되기에 충분히 적합한지 여부를 결정하는 사용자 테스트 과정이다.)