Topics covered

• Program Testing
• Development testing
• Test-driven development
• Release testing
• User testing

Program Testing

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.
• 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.

프로그램 테스트(Program Testing)
프로그램 테스트의 목적은 프로그램이 의도한대로 작동하는지 확인하고 사용하기 전에 프로그램 결함을 발견하는 것입니다. 소프트웨어를 테스트할 때 인위적인 데이터를 사용하여 프로그램을 실행합니다. 테스트 실행 결과에서 오류, 이상 현상 또는 프로그램의 비기능적 속성에 대한 정보를 확인합니다. 테스트는 오류의 존재를 드러낼 수 있지만, 오류의 부재를 보장할 수는 없습니다. 테스트는 정적 검증 기법을 포함하는 더 일반적인 검증 및 검사 과정의 일부입니다.

Program testing goals

• 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.
• To discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification.
• 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.

프로그램 테스트 목표

• 개발자와 고객에게 소프트웨어가 요구 사항을 충족함을 보여주는 것입니다.
  • 맞춤형 소프트웨어의 경우, 요구 사항 문서에 있는 모든 요구 사항에 대해 최소한 하나의 테스트가 있어야 합니다.
  • 일반 소프트웨어 제품의 경우, 제품 출시에 포함될 시스템 기능 및 이러한 기능의 조합에 대한 테스트가 있어야 합니다.
• 소프트웨어의 작동이 잘못되거나, 바람직하지 않거나, 사양에 부합하지 않는 상황을 발견하는 것입니다.
• 검증 테스트(Validation testing)
  • 개발자와 시스템 사용자에게 소프트웨어가 요구 사항을 충족함을 보여주는 것입니다.
  • 성공적인 테스트는 시스템이 의도한대로 작동함을 보여줍니다.
• 결함 테스트(Defect testing)
  • 소프트웨어의 작동이 잘못되거나 사양에 부합하지 않는 결함을 찾아내는 것입니다.
  • 성공적인 테스트는 시스템의 작동이 잘못되어 시스템의 결함을 드러내는 테스트입니다.

An input-output model of program testing

위 그림은 입력 테스트 데이터에 이상한 작동을 일으키는 입력이 있고, 이것이 시스템으로 들어가서, 출력 테스트 결과에 결함의 존재를 드러내는 출력이 나타나는 것을 보여줍니다. 이러한 테스트 과정을 통해 소프트웨어의 결함을 찾아낼 수 있습니다.

Verification vs validation

• 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.

검증(Verification) vs 검사(Validation)

• 검증(Verification)
  • "제품을 올바르게 구축하고 있는가".
  • 소프트웨어는 사양에 따라야 합니다.
• 검사(Validation)
  • "올바른 제품을 구축하고 있는가".
  • 소프트웨어는 사용자가 실제로 필요로 하는 작업을 수행해야 합니다.

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 do 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.
• Incomplete versions of a system can be inspected without additional costs.
  • If a program is incomplete, then you need to develop specialized test harnesses to test the parts that are available.
• 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.
• 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.

검사와 테스트

• 검사와 테스트는 상호 보완적이며, 대립하는 검증 기법이 아닙니다.
• V & V 프로세스 동안 두 가지 모두 사용해야 합니다.
• 검사는 사양과의 일치 여부를 확인할 수 있지만, 고객의 실제 요구 사항과의 일치 여부는 확인할 수 없습니다.
• 검사는 비기능적 특성을 확인할 수 없습니다. 예를 들어 성능, 사용성 등입니다.

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.

테스트 단계

• 개발 테스트(Development testing): 버그와 결함을 발견하기 위해 개발 중인 시스템을 테스트하는 단계입니다.
• 릴리스 테스트(Release testing): 사용자에게 릴리스되기 전에 독립된 테스트 팀이 완전한 시스템 버전을 테스트하는 단계입니다.
• 사용자 테스트(User testing): 시스템 사용자 또는 잠재 사용자가 자신의 환경에서 시스템을 테스트하는 단계입니다.

각 테스트 단계는 소프트웨어 개발 및 출시 과정에서 다양한 목적을 위해 수행됩니다. 개발 테스트는 개발자가 결함을 조기에 발견하고 수정할 수 있도록 돕습니다. 릴리스 테스트는 제품이 사용자 요구 사항과 기능적, 비기능적 목표를 충족하는지 확인하는 데 중점을 둡니다. 사용자 테스트는 실제 사용자가 시스템을 사용하면서 발견되는 문제를 파악하고 개선할 수 있도록 합니다. 이러한 과정을 통해 소프트웨어의 품질과 안정성이 향상됩니다.

Development testing

Development testing

• Development testing includes all testing activities that are carried out by the team developing the system.
• Testing activities can be categorized based on the level of components being tested.
• 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): 개별 프로그램 유닛 또는 객체 클래스를 테스트합니다.
  • 유닛 테스트는 객체나 메서드의 기능 테스트에 초점을 맞춰야 합니다.
• 컴포넌트 테스트(Component testing): 여러 개별 유닛을 통합하여 복합 컴포넌트를 생성합니다.
  • 컴포넌트 테스트는 컴포넌트 인터페이스 테스트에 초점을 맞춰야 합니다.
• 시스템 테스트(System testing): 시스템 내 일부 또는 모든 컴포넌트가 통합되어 전체 시스템이 테스트됩니다.
  • 시스템 테스트는 컴포넌트 간 상호 작용 테스트에 초점을 맞춰야 합니다.

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.

유닛 테스트

• 유닛 테스트는 개별 컴포넌트를 독립적으로 테스트하는 프로세스입니다.
• 이는 결함 테스트 프로세스입니다.
• 유닛은 다음과 같습니다:
  • 객체 내 개별 함수 또는 메서드
  • 여러 속성과 메서드가 있는 객체 클래스
  • 기능에 접근하기 위해 정의된 인터페이스를 사용하는 복합 컴포넌트

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

객체 클래스 테스트

• 클래스의 완전한 테스트 커버리지는 다음을 포함합니다.
  • 객체와 관련된 모든 작업 테스트
  • 모든 객체 속성 설정 및 조회
  • 모든 가능한 상태에서 객체 사용
• 상속은 테스트할 정보가 로컬화되지 않아 객체 클래스 테스트 설계를 더 어렵게 만듭니다.

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.
• 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.

자동화된 테스트

• 가능한 경우, 유닛 테스트는 수동 개입 없이 테스트를 실행하고 확인할 수 있도록 자동화해야 합니다.
• 자동화된 유닛 테스트에서는 테스트 자동화 프레임워크(예: JUnit)를 사용하여 프로그램 테스트를 작성하고 실행합니다.
• 유닛 테스트 프레임워크는 특정 테스트 케이스를 작성하기 위해 확장하는 일반적인 테스트 클래스를 제공합니다.
  • 그런 다음 구현한 모든 테스트를 실행하고, 종종 GUI를 통해 테스트의 성공 여부를 보고할 수 있습니다.

자동화된 테스트는 테스트 프로세스를 효율적으로 수행하고, 개발자가 프로젝트 전반에 걸쳐 일관된 테스트를 실시할 수 있도록 돕습니다. 이는 소프트웨어 개발 프로세스에서 품질 관리를 향상시키는 데 중요한 역할을 합니다. 전체적으로, 개발 테스트는 소프트웨어의 안정성과 신뢰성을 높이기 위해 필수적인 단계로 간주됩니다.

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.
• A tear-down part, which restores system states back to the beginning, such as releasing resources or clean up temporary files.
• The first two parts have more attention in automated testing research.

자동화된 테스트 구성 요소

• 설정(setup) 부분: 테스트 케이스, 즉 입력 및 예상 출력으로 시스템을 초기화합니다.
• 호출(call) 부분: 테스트할 객체나 메서드를 호출합니다.
• 단언(assertion) 부분: 호출 결과와 예상 결과를 비교합니다.
  • 단언이 참이면 테스트가 성공한 것이고, 거짓이면 실패한 것입니다.
• 해체(tear-down) 부분: 시스템 상태를 원래대로 되돌립니다. 예를 들어 리소스를 해제하거나 임시 파일을 정리합니다.
• 자동화된 테스트 연구에서 첫 번째와 두 번째 부분이 더 많은 관심을 받습니다.

Types of 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 two 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.

유닛 테스트 케이스 유형

• 테스트 케이스는 예상대로 사용될 때, 테스트하는 컴포넌트가 예상대로 작동한다는 것을 보여야 합니다.
• 컴포넌트에 결함이 있다면, 이러한 결함은 테스트 케이스에 의해 발견되어야 합니다.
• 이로 인해 유닛 테스트 케이스는 두 가지 유형으로 나뉩니다:
  • 첫 번째 유형은 프로그램의 정상 작동을 반영하고 컴포넌트가 예상대로 작동한다는 것을 보여줍니다.
  • 다른 유형의 테스트 케이스는 일반적으로 문제가 발생하는 경험에 기반한 테스트입니다.
    • 이상한 입력을 사용하여 이러한 입력이 제대로 처리되고 컴포넌트가 중단되지 않는지 확인해야 합니다.

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.

테스트 전략

• 분할 테스트(partition testing)는 입력이 공통 특성을 갖고 동일한 방식으로 처리되어야 하는 그룹을 식별하는 전략입니다.
  • 이러한 그룹 각각에서 테스트를 선택해야 합니다.
• 지침 기반 테스트(guideline-based testing) 는 테스트 지침을 사용하여 테스트 케이스를 선택합니다.
  • 이러한 지침은 프로그래머가 컴포넌트를 개발할 때 종종 발생하는 오류 유형에 대한 이전 경험을 반영합니다.

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.
• Test cases should be chosen from each partition.

분할 테스트

• 입력 데이터와 출력 결과는 종종 서로 다른 클래스에 속하며, 각 클래스의 모든 멤버가 관련됩니다.
• 이러한 클래스 각각은 동일성 분할(equivalence partition) 또는 도메인이며, 프로그램이 각 클래스 멤버에 대해 동일한 방식으로 작동합니다.
• 각 분할에서 테스트 케이스를 선택해야 합니다.

Equivalence partitioning

동치 분할법(equivalence partitioning)

• 가능한 입력에는 입력 동치 분할이 있고, 시스템을 통해 가능한 출력에 올바른 출력과 출력 분할이 있습니다.

Testing guidelines (collections)

• Test software with collections which have only a single value.
  • e.g.) List list = new ArrayList(); list.add(0);
• Use collections of different sizes in different tests.
• Derive tests so that the first, middle and last elements of the collection are accessed.
• Test with collections of zero length.

테스트 지침 (컬렉션)

• 단일 값만 있는 컬렉션으로 소프트웨어를 테스트합니다.
  • 예) List list = new ArrayList(); list.add(0);
• 다양한 크기의 컬렉션을 다른 테스트에서 사용합니다.
• 컬렉션의 첫 번째, 중간, 마지막 요소에 액세스하는 테스트를 도출합니다.
• 길이가 0인 컬렉션으로 테스트합니다.

General testing guidelines

• Choose inputs that force the system to generate all error messages.
  • e.g.) Java try/catch. Consider all catch blocks.
• 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.

General Testing Guidelines

이 방침들은 일반적으로 모든 소프트웨어 테스팅에 적용될 수 있습니다. 간단하게 각 항목을 살펴보겠습니다:

• 시스템이 모든 오류 메시지를 생성하도록 하는 입력을 선택하십시오. 이것은 소프트웨어의 예외 처리 기능을 확인하는 데 중요합니다. Java의 try/catch 블록을 고려하는 것이 좋은 예입니다. 각 catch 블록은 특정 오류 유형을 처리하므로, 각각의 catch 블록이 제대로 동작하는지 확인하기 위해 해당 오류를 유발하는 입력을 제공해야 합니다.
• 입력 버퍼가 오버플로우되게 하는 입력을 설계하십시오. 버퍼 오버플로우는 심각한 보안 문제를 일으킬 수 있으므로, 소프트웨어가 큰 데이터를 적절하게 처리하는지 확인하는 것이 중요합니다.
• 같은 입력이나 입력 시리즈를 여러 번 반복하십시오. 소프트웨어가 같은 입력에 일관된 방식으로 반응하는지 확인하는 것이 중요합니다. 또한, 동일한 입력에 대한 반복적인 처리가 성능에 영향을 미치는지 확인하려면 스트레스 테스팅을 수행해야 합니다.
• 유효하지 않은 출력이 생성되도록 강제하십시오. 소프트웨어가 잘못된 입력이나 예상치 못한 상황을 적절하게 처리하는지 확인하는 것이 중요합니다. 이는 소프트웨어의 견고성을 검증하는데 중요한 부분입니다.
• 계산 결과가 너무 크거나 작게 나오도록 강제하십시오. 이는 소프트웨어가 극단적인 결과를 제대로 처리하는지 확인하는 데 중요합니다. 예를 들어, 수치 연산을 수행하는 소프트웨어가 오버플로우나 언더플로우를 적절하게 처리하는지 확인해야 할 수 있습니다.

Component testing

• Software components are often composite components that are made up of several interacting objects.
  • For example, a software may have separate parts to obtain or read user data and analyze the data, so that data obtained from various source can be analyzed by the same technique.
• 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.

Component Testing

• 예를 들어, 소프트웨어는 사용자 데이터를 얻거나 읽는 부분과 이 데이터를 분석하는 부분으로 나뉘어져 있을 수 있습니다. 이렇게 구성된 컴포넌트는 다양한 소스에서 얻은 데이터를 동일한 방법으로 분석할 수 있게 해줍니다.
• 이러한 객체의 기능에 접근하는 것은 정의된 컴포넌트 인터페이스를 통해 이루어집니다. 따라서 컴포넌트 테스트는 컴포넌트 인터페이스가 명세서에 따라 동작하는지를 확인하는 데 집중해야 합니다. 이는 사용자나 다른 컴포넌트가 이 인터페이스를 통해 컴포넌트와 상호작용하게 되므로 매우 중요합니다.
• 컴포넌트 내부의 개별 객체에 대한 단위 테스트가 완료되었다고 가정합니다. 즉, 개별 객체들이 제대로 동작하는지에 대한 테스트는 이미 끝났으므로, 이제 컴포넌트 전체가 잘 동작하는지, 그리고 객체들이 상호작용할 때 문제가 없는지를 확인해야 합니다.

컴포넌트 테스팅은 컴포넌트의 동작이 전체 시스템의 기능과 어떻게 연관되는지, 또한 컴포넌트가 시스템의 다른 부분과 어떻게 상호작용하는지 이해하는 데 도움이 됩니다. 이는 소프트웨어 시스템이 효과적으로 작동하기 위해 개별 컴포넌트들이 잘 조화롭게 작동해야하기 때문입니다.

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: Sub-system encapsulates a set of procedures to be called by other sub-systems.
  • Message passing interfaces: Sub-systems request services from other sub-systems.

Interface Testing

이것은 컴포넌트 간의 상호작용을 테스트하는 과정입니다. 테스트의 목표는 인터페이스 오류 또는 인터페이스에 대한 잘못된 가정으로 인한 오류를 감지하는 것입니다. 인터페이스의 종류에는 다음과 같은 것들이 있습니다:

• Parameter interfaces: 하나의 메서드나 절차에서 다른 메서드나 절차로 데이터가 전달됩니다. 이 인터페이스의 테스트는 주로 매개변수의 유효성과 메서드 호출의 정확성에 초점을 맞춥니다.
• Shared memory interfaces: 메모리 블록이 절차나 함수들 사이에서 공유됩니다. 이 인터페이스의 테스트는 메모리 사용이 올바른지 확인하고, 동시성 문제가 없는지 확인합니다.
• Procedural interfaces: 하위 시스템은 다른 하위 시스템이 호출할 수 있는 일련의 절차를 캡슐화합니다. 이 인터페이스의 테스트는 절차의 호출이 올바르게 이루어지는지 확인하고, 호출 결과가 예상대로인지 확인합니다.
• Message passing interfaces: 하위 시스템이 다른 하위 시스템에게 서비스를 요청합니다. 이 인터페이스의 테스트는 메시지가 올바르게 전송되고 받아들여지는지 확인합니다.

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.
  • e.g.) returning an empty or default object instead of null.
• Timing errors
  • The called and the calling component operate at different speeds and out-ofdate information is accessed.

Interface Errors

인터페이스 테스트 과정에서 발견될 수 있는 주요 오류 유형은 다음과 같습니다:

• Interface misuse: 호출하는 컴포넌트가 다른 컴포넌트를 호출하면서 그 인터페이스의 사용에 오류를 만듭니다. 예를 들어, 매개변수를 잘못된 순서로 전달하는 경우가 있습니다.
• Interface misunderstanding: 호출하는 컴포넌트가 호출된 컴포넌트의 동작에 대해 잘못된 가정을 내포시킵니다. 예를 들어, null 대신 빈 객체나 기본 객체를 반환하는 것을 예상하는 경우가 있습니다.
• Timing errors: 호출된 컴포넌트와 호출하는 컴포넌트가 다른 속도로 작동하여, 만료된 정보가 접근되는 경우입니다. 이는 동기화 문제로, 예를 들어, 데이터가 너무 빨리 또는 너무 늦게 도착하는 경우 발생할 수 있습니다.

Interface testing guidelines

• Design tests so that parameters to a called procedure are at the extreme ends of their ranges.
  • corner cases or boundary cases.
• Always test pointer parameters with null pointers.
• 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.

Interface Testing Guidelines

인터페이스 테스팅 지침은 인터페이스의 특성을 테스트하는 방법을 제공합니다:

• 호출된 절차의 매개변수가 그들의 범위의 극단에 있도록 테스트를 설계하십시오. 이는 "corner cases" 또는 "boundary cases"를 테스트하는 것을 의미합니다. 이런 경우들은 일반적인 동작을 벗어나는 경우이며, 이들을 테스트하면 소프트웨어의 강건성을 검증할 수 있습니다.
• 항상 null 포인터로 포인터 매개변수를 테스트하십시오. null 포인터를 처리하는 능력은 소프트웨어의 안정성과 관련이 있습니다. null 포인터를 받아들일 수 없는 함수는 오류를 적절하게 처리해야 합니다.
• 컴포넌트가 실패하게 만드는 테스트를 설계하십시오. 이것은 소프트웨어가 예외 상황을 적절하게 처리하는지 확인하는 데 도움이 됩니다.
• 메시지 패싱 시스템에서 스트레스 테스팅을 사용하십시오. 이것은 시스템이 과부하 상태에서도 올바르게 동작하는지 확인하는 데 도움이 됩니다.
• 공유 메모리 시스템에서는 컴포넌트가 활성화되는 순서를 변경하십시오. 이는 동시성 문제를 찾아내는 데 도움이 됩니다.

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.

System Testing

시스템 테스트는 모든 컴포넌트가 통합된 후에 전체 시스템의 기능을 검증하는 단계입니다. 이 단계는 전체적인 시스템 품질을 평가하고 실제 사용자 시나리오와 가장 유사한 환경에서 시스템이 정상적으로 작동하는지 확인하는 것이 목표입니다.

시스템 테스트의 중요한 부분 중 하나는 "emergent properties"를 테스트하는 것입니다. 이것은 시스템 전체에서만 관찰할 수 있는 속성이며, 개별 컴포넌트 수준에서는 확인할 수 없습니다. 이러한 속성은 시스템의 안정성, 성능, 안전성 및 보안성을 포함할 수 있습니다.

시스템 테스트의 다양한 유형이 있습니다:

• Performance Testing: 시스템의 성능과 응답 시간을 측정합니다.
• Load Testing: 시스템이 예상 최대 작업량을 처리할 수 있는지 확인합니다.
• Stress Testing: 시스템의 한계를 찾기 위해 과도한 양의 작업을 시스템에 부과합니다.
• Security Testing: 시스템의 보안 취약성을 찾아냅니다.
• Usability Testing: 사용자 인터페이스가 사용하기 쉬운지 평가합니다.

이러한 테스트는 시스템이 실제 운영 환경에서 어떻게 동작할지에 대한 신뢰성 있는 정보를 제공합니다. 그리고 이는 또한, 시스템이 사용자의 기대와 일치하고 비즈니스 요구 사항을 충족시키는지 확인하는데 도움이 됩니다.

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.
• Components developed by different team members or subteams 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.

System and Component Testing

시스템 테스트 단계에서는 독립적으로 개발된 재사용 가능한 컴포넌트와 상품화된 시스템이 새로 개발된 컴포넌트와 통합될 수 있습니다:

• 이렇게 통합된 완전한 시스템이 테스트됩니다. 이것은 시스템의 모든 컴포넌트가 서로 통신하고 올바르게 작동하는지 확인합니다.
• 이 단계에서는 다른 팀원이나 하위 팀이 개발한 컴포넌트들도 통합될 수 있습니다. 이것은 시스템 테스트가 개인적인 과정이 아닌, 팀이 함께 진행하는 과정임을 나타냅니다. 모든 컴포넌트가 함께 작동하면서 전체 시스템이 명세에 따라 동작하는지를 확인하는 것이 중요합니다.
• 일부 회사에서는 시스템 테스트가 디자이너와 프로그래머의 참여 없이 별도의 테스팅 팀에 의해 수행될 수 있습니다. 이렇게 하는 이유는 테스팅의 객관성을 유지하고, 개발자가 아닌 사람들의 관점에서 시스템을 테스트하기 위함입니다. 개발팀이 아닌 독립된 테스팅 팀이 테스트를 수행하면, 사용자의 시각에서 발생할 수 있는 문제를 더 잘 발견할 수 있을 것입니다.

이러한 과정을 통해, 시스템이 실제 운영 환경에서 예상대로 작동하는지 확인할 수 있습니다. 시스템 테스트는 개별 컴포넌트들이 아닌, 전체 시스템의 동작을 검증합니다. 이는 시스템 내의 컴포넌트들 간의 상호작용을 통해 발생하는 복잡한 동작을 캡처하기 때문에 매우 중요한 과정입니다.

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 can describe the components and interactions that are being tested.

Use-case Testing

Use-case 테스팅은 시스템 상호작용을 식별하기 위해 개발된 유스케이스를 시스템 테스팅의 기초로 사용하는 것을 의미합니다:

• 각 유스케이스는 일반적으로 여러 시스템 컴포넌트를 포함하므로, 유스케이스를 테스트하면 이러한 상호작용이 강제로 일어나게 됩니다.
• 유스케이스 문서와 연관된 시퀀스 다이어그램은 테스트되는 컴포넌트와 상호작용을 설명할 수 있습니다.

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 inputs.

Testing Policies

완벽한 시스템 테스트는 불가능하므로, 필요한 시스템 테스트 커버리지를 정의하는 테스트 정책이 개발될 수 있습니다:

• 예를 들어, 테스트 정책의 예로는 다음과 같은 사항들이 있을 수 있습니다:
  • 메뉴를 통해 액세스하는 모든 시스템 기능은 테스트되어야 합니다.
  • 동일한 메뉴를 통해 액세스하는 기능들의 조합(예: 텍스트 포매팅)은 반드시 테스트되어야 합니다.
  • 사용자 입력이 제공되는 경우, 모든 함수는 올바른 입력과 올바르지 않은 입력 모두로 테스트되어야 합니다.

이러한 정책은 테스트의 우선 순위를 결정하고, 어떤 유형의 테스트가 필요한지, 어떤 부분을 놓치지 않았는지 확인하는데 도움이 됩니다. 이렇게 하면 테스팅 작업이 효율적이고 일관된 방식으로 수행될 수 있습니다.

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.
• 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.

Test-driven Development (TDD)

테스트 주도 개발(TDD)은 프로그램 개발에 대한 접근법으로, 테스팅과 코드 개발을 번갈아 수행하는 방식입니다.

• 코드를 작성하기 전에 테스트를 작성하며, '테스트 통과'가 개발의 중요한 원동력이 됩니다.
• 당신은 코드를 점진적으로 개발하며, 그 증분에 대한 테스트를 작성합니다.
  • 개발한 코드가 테스트를 통과할 때까지 다음 증분으로 넘어가지 않습니다.
• TDD는 Extreme Programming과 같은 애자일 방법론의 일부로 도입되었습니다.
  • 그러나 계획 주도 개발 프로세스에서도 사용될 수 있습니다.

그림에 표시된 바와 같이 TDD의 기본 워크플로우는 다음과 같습니다:

1. 새로운 기능에 대한 테스트 작성: 개발자는 처음에 실패하는 새로운 기능에 대한 자동화된 테스트를 작성합니다. 이 테스트는 원하는 새로운 기능을 명확하게 설명하고, 그 기능이 성공적으로 구현되었음을 입증하는 역할을 합니다.
2. 테스트를 통과하는 코드 작성: 개발자는 이제 테스트를 통과할 수 있을 만큼만 코드를 작성합니다. 이 단계에서는 아직 완벽하게 최적화되지 않은 코드를 작성하는 것이 일반적입니다.
3. 코드 리팩토링: 개발자는 코드를 정리하고 통합합니다. 이 단계에서는 코드의 품질을 향상시키고 중복을 제거하는데 중점을 둡니다. 테스트가 있는 덕분에 이 리팩토링이 코드의 동작에 부정적인 영향을 미치지 않음을 확신할 수 있습니다.

이러한 접근법은 매우 빠른 피드백 사이클을 제공하며, 버그를 빠르게 발견하고 수정하는 데 도움이 됩니다. 또한 TDD는 잘 정의된 요구사항과 함께 작동하기 때문에, 코드에 대한 테스트가 실제로 코드의 문서화를 제공하는 효과도 있습니다.

TDD process activities

• 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.

TDD Process Activities

TDD는 다음과 같은 일련의 작업으로 구성됩니다:

1. 기능 증분 식별: 필요한 기능 증분을 먼저 식별합니다. 일반적으로 이 증분은 작고, 몇 줄의 코드로 구현할 수 있어야 합니다.
2. 테스트 작성: 이 기능에 대한 테스트를 작성하고 이를 자동화된 테스트로 구현합니다.
3. 테스트 실행: 이 테스트를 실행하고, 그동안 구현한 모든 테스트를 함께 실행합니다. 처음에는 기능을 구현하지 않았기 때문에, 새로운 테스트는 실패하게 됩니다.
4. 기능 구현과 테스트 재실행: 기능을 구현한 다음, 테스트를 다시 실행합니다.
5. 모든 테스트가 성공적으로 실행되면, 다음 기능 증분의 구현으로 넘어갑니다.

TDD Example

Benefits of test-driven development

• 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.

Test-Driven Development(TDD)의 이점

TDD는 여러 가지 이점을 가지고 있습니다:

• 코드 커버리지: TDD는 모든 코드 세그먼트에 최소 하나의 연관된 테스트가 있도록 보장하므로, 작성된 모든 코드는 최소한 하나의 테스트를 가집니다. 이는 코드의 모든 부분이 테스트를 통해 검증되며, 높은 품질의 코드를 보장하는데 도움이 됩니다.
• 회귀 테스트: 프로그램이 개발되는 동안 회귀 테스트 스위트는 점진적으로 개발됩니다. 즉, 코드의 변화에 따라 테스트 스위트가 갱신되므로, 이전에 개발된 기능들이 여전히 잘 작동하는지 확인할 수 있습니다.
• 디버깅 간소화: 테스트가 실패하면 문제가 발생한 위치를 파악하기가 쉽습니다. 즉, 새롭게 작성된 코드를 검사하고 수정하는 것으로 문제를 해결할 수 있습니다. 이로 인해 디버깅 시간이 크게 줄어들 수 있습니다.
• 시스템 문서화: 테스트 자체는 코드가 어떤 작업을 수행해야 하는지를 설명하는 문서의 형태가 될 수 있습니다. 이는 시스템의 기능에 대한 이해를 돕고, 미래의 유지보수 작업을 쉽게 만드는데 도움이 됩니다.

즉, TDD는 코드 품질 향상, 문제 해결의 용이성, 좋은 문서화 등을 통해 소프트웨어 개발의 전반적인 효율성과 품질을 높이는 방법입니다.

Code Coverage

• Statement Coverage (or Line Coverage)
  • Satisfied if a statement is executed.
• Branch Coverage (or Decision Coverage)
  • Satisfied if each branch is executed.
• Condition Coverage
  • Satisfied if each condition in a branch is tested.

코드 커버리지(Code Coverage)

코드 커버리지는 단위 테스트가 소프트웨어의 어떤 부분을 커버하는지를 측정하는 방법입니다. 코드 커버리지를 측정하는 여러 가지 방법이 있습니다:

1. 문장 커버리지(Statement Coverage 또는 Line Coverage): 이는 소프트웨어 코드의 각 문장이 최소한 한 번은 실행되는지를 확인합니다. 이 방법은 코드의 어떤 부분이 테스트되었는지에 대한 기본적인 지표를 제공합니다.
2. 브랜치 커버리지(Branch Coverage 또는 Decision Coverage): 이는 코드의 각 분기(조건문 등)가 모두 테스트되었는지를 확인합니다. 즉, 'if'나 'switch' 문과 같은 결정 점들이 모든 가능한 방향으로 실행되는지를 확인합니다.
3. 조건 커버리지(Condition Coverage): 이는 각 분기에 있는 모든 조건이 테스트되었는지를 확인합니다. 이 방법은 브랜치 커버리지를 한 단계 더 나아가, 불리언 표현식 내의 각 개별 조건이 참과 거짓을 모두 반환하는지를 확인합니다.

Code Coverage

• Code coverage can be obtained by adding probes to code and check whether the probes are reached.
  • There are many tools which perform such tasks automatically.
• Usually you can use IDE to compute code coverage.
  • In our case, we can use pytestcov and Coverage Gutter extension.
• Right-click on the source code, then choose display coverage.
  • You can see green/red marking for covered/uncovered lines respectively.
  • Coverage can be found at the bottom.

코드 커버리지 도구

코드 커버리지는 코드에 프로브를 추가하고 해당 프로브가 도달되는지 확인함으로써 얻을 수 있습니다. 이런 작업을 자동으로 수행하는 많은 도구들이 있습니다.

일반적으로 IDE(통합 개발 환경)를 사용하여 코드 커버리지를 계산할 수 있습니다. 예를 들어, pytestcov나 Coverage Gutter 확장 기능 등을 사용할 수 있습니다.

소스 코드에서 마우스 오른쪽 버튼을 클릭하고 '커버리지 표시'를 선택하면 커버리지를 확인할 수 있습니다. 커버된/커버되지 않은 라인에 대한 초록색/빨간색 표시를 볼 수 있습니다. 또한 화면 하단에서 커버리지를 확인할 수 있습니다. 이러한 도구들은 개발자가 소프트웨어의 어느 부분이 테스트되었는지, 어느 부분이 누락되었는지를 파악하는 데 도움이 됩니다.

Increasing Code Coverage

• You can increase code coverage by designing setup and call parts of test cases carefully.
• In Java, private methods must be called by public methods.
  • If your tests call all public methods, and take all the branches in the methods,
    • then theoretically you can achieve 100% line/branch coverage.
• For this purpose, it is important to create appropriate object instances, which can be used to call methods.
  • Good modularization makes it easier to write test cases for each unit of a program.

코드 커버리지 증가

코드 커버리지를 높이려면 테스트 케이스의 설정과 호출 부분을 신중하게 설계해야 합니다.

예를 들어, Java에서는 private 메서드는 public 메서드에 의해 호출되어야 합니다. 테스트가 모든 public 메서드를 호출하고, 해당 메서드 내의 모든 브랜치를 수행한다면 이론적으로 100%의 라인/브랜치 커버리지를 달성할 수 있습니다.

이를 위해 메서드를 호출하는 데 사용할 수 있는 적절한 객체 인스턴스를 생성하는 것이 중요합니다. 좋은 모듈화는 프로그램의 각 단위에 대해 테스트 케이스를 작성하기 쉽게 만듭니다.

Limitation of Code Coverage

• Code coverage is used to assess your test suite's quality or performance.
  • How much portion of the code has been tested?
• Automated testing research often uses branch coverage.
  • Randoop / EvoSuite for JUnit test case generation.
• Recent studies showed that code coverage is not enough for test suite evaluation.
  • Does it really detect faults?
• Mutation testing: automatically mutate your code to plant faults, and see if your tests can detect the faults.
  • PIT for Java mutation testing.

코드 커버리지의 한계

코드 커버리지는 테스트 스위트의 품질이나 성능을 평가하는 데 사용됩니다. 코드의 어느 부분이 테스트되었는지를 측정합니다.

자동화된 테스트 연구에서는 종종 브랜치 커버리지를 사용합니다. 예를 들어, JUnit 테스트 케이스 생성을 위해 Randoop이나 EvoSuite와 같은 도구를 사용할 수 있습니다.

하지만 최근의 연구에서는 코드 커버리지만으로는 테스트 스위트 평가에 충분하지 않다는 결과를 보여주었습니다. 테스트가 실제로 결함을 탐지하는지에 대한 문제를 제기했습니다.

변이 테스트(Mutation Testing)

변이 테스팅은 코드에 자동으로 변이를 가하여 결함을 심어보고, 테스트가 이러한 결함을 탐지할 수 있는지 확인하는 방법입니다. 예를 들어, Java 변이 테스팅에는 PIT와 같은 도구를 사용할 수 있습니다.

변이 테스팅은 테스트 스위트가 결함을 잘 탐지할 수 있는지, 다시 말해 테스트 스위트의 품질을 측정하는 또 다른 방법을 제공합니다. 이러한 방법은 코드 커버리지만으로는 부족한 테스트 스위트 평가를 보완할 수 있습니다.

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.
• TDD is a good practice to secure regression tests.

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.
  • vs. white-box testing

릴리스 테스팅

릴리스 테스팅은 개발 팀 외부에서 사용하려는 시스템의 특정 릴리스를 테스트하는 과정입니다.

릴리스 테스팅의 주요 목표는 시스템의 공급자에게 이 시스템이 사용하기에 충분히 좋은지 확신을 줄 수 있도록 하는 것입니다. 따라서 릴리스 테스팅은 시스템이 명세된 기능, 성능, 신뢰성을 제공하며, 정상 사용 중에는 실패하지 않음을 보여야 합니다.

릴리스 테스팅은 일반적으로 검은 상자(black-box) 테스팅 과정이며, 테스트는 시스템 명세서로부터만 파생됩니다. 이는 시스템의 내부 작동 방식을 보지 않고 입력과 출력만을 바탕으로 테스트를 수행하는 방식입니다. 반면에 흰 상자(white-box) 테스팅은 시스템의 내부 구조를 고려하여 테스트를 수행합니다.

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.
• We've already experienced requirements based testing, by verifying each requirement in the list for an intermediate release.
• A developed test is not necessarily an automated test.
  • You can simply define a scenario to use the system and verify the requirements are satisfied.

요구사항 기반 테스팅

요구사항 기반 테스팅은 각 요구사항을 검토하고 그에 대한 테스트나 테스트들을 개발하는 것을 포함합니다. 이는 중간 릴리스의 요구사항 목록을 검증함으로써 이미 우리가 경험한 요구사항 기반 테스팅입니다.

개발된 테스트는 반드시 자동화된 테스트일 필요는 없습니다. 시스템 사용 시나리오를 단순히 정의하고 요구사항이 충족되는지 확인할 수 있습니다.

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 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.

사용자 테스팅의 종류

• 알파 테스팅
  • 소프트웨어의 사용자들이 개발 팀과 함께 작업하여 개발자의 사이트에서 소프트웨어를 테스트합니다. 이는 일반적으로 개발 중인 소프트웨어에 대한 초기 피드백을 얻기 위한 것이며, 제품의 품질 향상에 도움이 됩니다.
• 베타 테스팅
  • 소프트웨어의 릴리스가 사용자에게 제공되어 그들이 실험하고, 시스템 개발자에게 발견한 문제를 제기할 수 있게 합니다. 이는 실제 사용자 환경에서 소프트웨어가 어떻게 작동하는지 확인하고, 사용자가 발견할 수 있는 잠재적인 문제를 파악하는 데 도움이 됩니다.
• 수용 테스팅
  • 고객들이 시스템을 테스트하여 시스템 개발자로부터 받아들일 준비가 되었는지, 고객 환경에 배포할 준비가 되었는지 결정합니다. 이는 주로 맞춤형 시스템에 대해 진행됩니다. 이는 고객이 소프트웨어를 사용하여 필요한 요구 사항이 충족되는지 확인하는 과정입니다.

User Testing for Different Types of Software

• Although a software has been developed enough for in user testing, it is still in its testing stage.
• Undiscovered errors might happen during this period.
• Hence it is necessary to design and conduct user testing differently for different types of software.
  • For instance, beta testing of online games can be more easily conducted, compare to autonomous driving software or financial software.

다른 유형의 소프트웨어를 위한 사용자 테스팅

사용자 테스팅에 충분히 개발된 소프트웨어라도 여전히 테스팅 단계에 있습니다. 이 기간 동안 아직 발견되지 않은 오류가 발생할 수 있습니다. 따라서 다른 유형의 소프트웨어에 대해 사용자 테스팅을 다르게 설계하고 실시하는 것이 필요합니다. 예를 들어, 온라인 게임의 베타 테스팅은 자율 주행 소프트웨어 또는 금융 소프트웨어에 비해 더 쉽게 실시될 수 있습니다.

The acceptance testing process

수용 테스트 과정

해당 이미지는 수용 테스트 과정을 설명하고 있습니다. 이 과정은 다음과 같습니다:

1. 테스트 계획 수립: 이 단계에서는 테스트의 범위와 목적, 테스트를 진행할 자원, 테스트 일정 등을 계획합니다.
2. 테스트 케이스 설계: 시스템이 어떤 기능을 수행해야 하는지에 대한 예상치와 시나리오를 포함하는 테스트 케이스를 설계합니다.
3. 시스템 배포: 개발한 시스템을 테스트 환경에 배포합니다.
4. 테스트 수행: 설계한 테스트 케이스를 이용하여 시스템을 테스트합니다.
5. 테스트 결과 기록: 테스트 결과를 기록하고, 발견한 문제를 추적합니다.
6. 시스템 수정: 테스트 과정에서 발견된 문제를 수정하고, 수정 사항을 반영한 시스템을 다시 테스트합니다.
7. 시스템 수용/거부: 테스트 결과를 바탕으로 시스템을 수용하거나 거부합니다.

이 과정은 수용 테스트가 효과적으로 진행되도록 보장하며, 시스템이 사용자의 요구사항을 만족시키는지 확인하는 데 도움이 됩니다.

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

• Program testing is a crucial part of verification and validation process.
  • Two main goals of testing are to check requirement conformation and discover defects.
• Software inspection is static verification to discover problems and software testing is dynamic verification to observe program behaviour.
• Program testing consists of development testing, release testing and user testing.
• TDD is an approach to inter-leave testing and code development, starts with writing test cases which must be passed by the developed program.

요약

프로그램 테스팅은 검증 및 유효성 검사 과정의 중요한 부분입니다. 테스팅의 두 가지 주요 목표는 요구사항 준수를 확인하고 결함을 발견하는 것입니다. 소프트웨어 검사는 문제를 발견하는 정적 검증이며, 소프트웨어 테스팅은 프로그램의 동작을 관찰하는 동적 검증입니다. 프로그램 테스팅은 개발 테스팅, 릴리즈 테스팅, 사용자 테스팅으로 구성됩니다. TDD(Test-driven development)는 테스팅과 코드 개발을 교차로 수행하는 접근 방식으로, 개발된 프로그램이 통과해야 하는 테스트 케이스 작성부터 시작합니다.