일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- test
- RBT
- 비기능테스트
- 애자일
- 테스트 설계 기법에 따른 분류
- Software life cycle model
- 파이썬
- Python
- Test Case
- 위험 기반 테스트
- agile
- maintainability test
- 자동화
- 품질
- selenium
- 테스트 케이스
- SQA
- csts
- testing method
- 테스트케이스
- QA
- seleium
- 테스트
- 셀레니움
- ISTQB
- testcase
- 유지보수성 테스트
- risk-based testing
- Testing
- regression test
- Today
- Total
목록CSTS (46)
Study_Note
테스트 원칙 (test principle) "The Art of Software Testing"에서는 소프트웨어 테스트를 수행할 때 기본적으로 지켜야 할 여러 원칙들이 소개되었습니다. 이 중 몇 가지 중요한 원칙을 간략히 소개하겠습니다. 테스트는 개발자나 개발 팀과 독립된 그룹에 의해 수행되어야 합니다. 사람의 심리 상 자신이 작성한 프로그램에 대해서는 방어적인 경향을 띨 수밖에 없다. 또한, 자신이 담당한 부분의 요구사항을 제대로 해석하지 못했을 가능성이 있으므로 테스트를 철저하게 수행하더라도 결함을 발견하지 못할 가능성이 크다. 테스트 계획을 수립할 때 결함이 발견되지 않을 것이라는 가정은 피해야 합니다. 프로그램을 실행하는 과정은 단순히 올바른 동작을 확인하는 것이 아니라, 결함을 찾기 위한 의도를..
갤퍼린(gelperinn) 과 헤첼(hetzel) 의 소프트웨어 테스트 개념의 진화과정 (the evolutionary process of testing) Level_1 Debugging Oriented ( ~ 1956) 이 수준에서는 테스트와 디버깅 간에 명확한 차이가 없습니다. 주로 발견된 결함을 수정하는 디버깅에 중점을 두며, 프로그램의 결함을 찾기 위한 별도의 노력을 기울이지 않습니다. Level_2 Demonstration Oriented (1957 ~1878) 프로그램이 정상적으로 동작하는 것을 입증하기 위해 테스트를 진행합니다. 이에 따라 결함을 찾을 가능성이 높은 테스트 케이스를 만들기보다는 시스템이 올바르게 작동하는지 입증하는 데 중점을 두려는 경향이 있습니다. Level_3 Destru..
테스팅 디버깅, 재검증(테스팅) (testing, debugging, re_testing) Testting 목적: 소프트웨어의 품질을 평가하고 문제를 식별하기 위해 시스템을 실행하는 과정. 활동: 소프트웨어를 실행하고, 입력 데이터를 제공하며, 예상된 출력과 실제 출력을 비교함으로써 소프트웨어의 동작을 확인함. 종류: 기능 테스트, 성능 테스트, 사용자 인터페이스 테스트 등 다양한 종류의 테스트가 있음. 테스팅은 소프트웨어의 동작과 요구사항 간의 일치 여부를 확인하는 과정입니다. 특히, 동적 테스트는 결함의 발견을 목적으로 프로그램을 실행하며, 이때 발생한 소프트웨어 장애를 통해 내부에 결함이 있을 것으로 가정합니다.프로그램이 예상한 결과와 다르게 동작할 때, 즉, 장애가 발생했을 때, 테스팅은 해당 문..
결함유형 (type of defects) 테스트를 통하여 결함을 효과적, 효율적으로 검출하기 위해서는 먼저 소프트웨어에 어떤 종류의 결함이 존재할 수 있는지 이해해야 한다. 아래 이미지는 소프트웨어 결함을 누락, 비관련, 부정확한 구현이라는 세 가지 유형으로 분류한 개념을 보여 준다. 누락(Omission) 요구 명세에 명시된 요구사항이 시스템의 구현에 반영되지 않은 결함을 말한다. 예를 들어, 어떤 시스템의 요구 명세에 특정 입력에 대하여 출력하도록 명시되어 있지만 소프트웨어네느 구현되지 않았다면 이는 누락에 해당한다. 누락 결함에는 기능적인 것뿐만 아니라 성능, 보안, 안전, 신뢰도 등 품질 요소에 관란 누락도 포함된다. 부정확한(Incorrect)구현 요구 명세에 명시된 요구사항이 소프트웨어에 부정..
개발 단계별 결함 (defects by development stage) 결함이 마치 소스 코드에만 존재한다고 생각할 수 있다.하지만 결함은 소스 코드를 포함해서 최종적으로 소프트웨어 동작의 장애를 유발할 수 있는 모든 개발 산출물에 존재할 수 있다. 예를 들어, 소스 코드에서 발견된 결함이 소스 코드를 작성하는 구현 단계가 아니라 설계 명세서의 부정확한 알고리즘에 기인한 것일 수도 있는데, 이러한 경우에는 소스 코드의 결함이라기보다는 설계의 결함이라고 볼 수 있다. 일반화하면 개발자는 소프트웨어를 개발하는 각 단계에서 오류를 범할 수 있으므로 각 단계의 산출물에는 결함이 존재할 가능성이 있는 것이다. 아래 이미지는 전체 결함에 대하여 소프트웨어 주요 개발 단계별 결함의 발생 비율을 보여준다. 결함의 3..
오류, 결함, 장애의 개념 (concept of error, defect, failure) 소프트웨어를 개발할 때 기대, 약속된 소프트웨어의 동작에 대한 기준이 주어지는데, 이 동작 기준을 정의한 것을 소프트웨어 요구사항이라고 한다. 소프트웨어가 요구사항과 다르게 동작했다면 이를 장애가 발생했다고 한다. 즉, 장애는 프로그램의 실행 결과와 요구사항에 명시된 결과에 차이가 있음을 의미하는 것이다. 이러한 장애는 결국 소프트웨어를 구성하는 요소에 부족한 점이 있어서 발생한 것이다. 이는, 부정확한 구현 때문일 수도 있고, 필요한 기능이 포함되지 않았기 때문일 수도 있다.이와같이, 소프트웨어 내에 장애를 유발할 수 있는 문제를 결함 이라고 한다.이렇게 결함 때문에 장애가 발생하지만 결함이 있다고 해서 반드시 ..