포스트를 시작하기 전, 신입 개발자가 작성한 포스트임을 알립니다 👼🏻

1. 소프트웨어 테스트 기법을 몇 가지 숙지합니다.
출처 : https://parksh86.tistory.com/166
출처 : https://www.oss.kr/info_test/show/afda9e9d-3be7-471a-9c55-9e2c3ac58221
위 출처들에는 프로그래머 개인이 혼자 진행할 수 없는 테스트 기법을 포함한 정말 모든 기법들이 나와 있습니다. 저는 프로그래머가 앉은 자리에서 간단하게 자기 프로그램을 테스트 할 수 있는 방법에 대해 포스트하고 싶습니다. 따라서 인수 테스트(계약 조건이 만족되었는지 확인하기 위해 구입자와 납품자가 모두 보는 앞에서 시행하는 테스트) 등의 테스트는 생략하고 기입했습니다.
아래 표를 보고, 어떤 기법이 있는지 테스트 전 주르륵 읽어 보는 것만으로도 테스트 계획이 머리속에 정립됩니다.
No. | 테스트 기법 이름 | 테스트 기법 설명 |
1 | 블랙박스 테스트 | input과 output을 주고, 그 값이 나오는지 확인하는 방법 |
2 | 화이트박스 테스트 | 코드를 보며 내부 구조를 해석하고 알맞게 작성되었는지 확인하는 테스트 |
3 | 단위 테스트 | 모듈 테스트라고도 하며, 테스트 가능한 가장 작은 단위인 함수 단위로 테스트를 수행 |
4 | 통합 테스트 | 단위들을 결합한 모듈 단위로 테스트 |
5 | 시스템 테스트 | 실제 운용 환경에서 제대로 작동하는지 테스트 |
6 | 등가분할 | 테스트 범위를 동등하게 쪼개 테스트하는 기법 |
7 | 경계값 분석 | 다른 분기로 갈라져야 하는 경계선 부분의 값을 넣어 분기가 제대로 나눠지고 있는지 테스트 |
8 | 분류 트리 | 데이터를 분류할 때, 트리 구조로 분류 구조를 그려 보고 잘 분류되는지 확인하는 테스트 |
9 | 상태 전이 테스트 | FSM 을 사용할 때, 각 상태 전이가 잘 이루어지는지 확인하는 테스트 |
10 | 결정 테이블 테스팅 | 여러 사항을 분류할 때, 각 사항이 잘 분류되었는지 확인 |
11 | 조합 테스트 기법 | 가능한 모든 input 의 조합을 테스트 케이스로 생성하는 기법 |
12 | 시나리오 테스트 기법 | 흐름을 기반으로 시나리오를 작성하고, 해당 시나리오대로 잘 작동하는지 확인하는 기법 |
13 | 오류 추정 | '여러 경험에 의해, 이 시점에서는 이런 오류가 발생할 것이다.' 하는 부분을 테스트하는 기법 |
처음에는 모든 테스트 기법을 사용해 보려 했으나, 테스트 환경을 세팅하는 시간이 굉장히 오래 걸려 불필요하다고 느꼈습니다. 따라서 저는 아래 두 가지 방법만 사용하는 것이 제일 좋은 것 같습니다.
순서 | 테스트 방법 | 목적 |
1 | 단위 화이트박스 테스트 | 불필요한 DB 반복 접근을 하고 있는지 확인 어떤 테스트를 해 보면 좋을지 리스트 작성 |
2 | 통합 블랙박스 테스트 | 다양한 기법을 활용하여 테스트 |
2. 테스트 계획을 수립하기 위해 단위 화이트박스 테스트를 실시합니다.
방법은 이렇습니다.
모든 함수를 한줄 한줄 읽으며
- 테스트를 해 보아야 할 것 같은 부분을 기록합니다.
- 특별히 사용할 기법이 있다면 기법도 적어 주도록 합니다.
- 작성한 내용에 따른 테스트 계획을 적어 봅니다.

3. 통합 블랙박스 테스트를 위한 문서를 작성합니다.
문서를 작성하지 않고 테스트하는 것은 위험합니다. 나중에 어떤 테스트를 했는지 까먹을 수도 있고, 불필요한 테스트를 하게 되기도 합니다. 위에서 적은 테스트 리스트를 기반으로, 테스트 케이스를 설계해 봅니다.
위 예시를 기반으로 설계해 보겠습니다.
# 상자 열기 조건 경계값 분석을 위해,
input 의 열쇠 개수를 다르게 입력해야 할 것 같습니다.
상자를 여는 데 필요한 열쇠 개수가 100개일 때, 경계값 분석을 위해 99,100,101을 테스트 입력값으로 넣도록 하겠습니다.
그리고, 다른 조건들을 기입할 수 있도록 '기타' 컬럼도 추가해 두도록 하겠습니다.

# 열쇠 개수 차감 확인을 위해,
결과값 변동을 확인해야 할 것 같습니다.
결과가 어떻게 변화는지 컬럼을 추가합니다.
그리고, 다른 기타 출력들을 기록할 수 있도록 '출력'컬럼도 만들어 둡니다.

마지막으로, 테스트 결과를 기록할 컬럼을 추가했습니다.
4. 통합 블랙박스 테스트를 실시합니다.
설계한 대로 테스트를 수행하고, 결과를 기록합니다.

위 경우에서는, 실패가 1건 발생했습니다. 에러 원인을 분석하고, 기입해 둡니다.
테스트가 실패했으므로 코드를 수정하고, 다시 테스트합니다.

위 경우에서는, 테스트에 성공했습니다. 주의할 점으로는 '테스트 범위'가 있는데요, 기존에 단위 테스트를 실시했던 항목에 대해서는 테스트를 번복하지 않도록 합니다. 이것이 테스트 기록을 남겨야 하는 이유이기도 합니다! 이전에 어떤 테스트를 해 보았는지 기록해 둔다면, 불필요하게 낭비되는 시간을 단축할 수 있습니다!
끝
'Server > C#' 카테고리의 다른 글
진짜 오랫동안 삽질했던, 프로그램 비정상 종료 대처법 (0) | 2023.10.11 |
---|---|
C#의 장점 (2) | 2023.08.03 |
[C#] out of range 에러에 대처하는 천재적인 방법 (0) | 2023.07.04 |
[C#] ??= (0) | 2023.06.20 |
[C#] FirstOrDefault (0) | 2023.06.20 |
포스트를 시작하기 전, 신입 개발자가 작성한 포스트임을 알립니다 👼🏻

1. 소프트웨어 테스트 기법을 몇 가지 숙지합니다.
출처 : https://parksh86.tistory.com/166
출처 : https://www.oss.kr/info_test/show/afda9e9d-3be7-471a-9c55-9e2c3ac58221
위 출처들에는 프로그래머 개인이 혼자 진행할 수 없는 테스트 기법을 포함한 정말 모든 기법들이 나와 있습니다. 저는 프로그래머가 앉은 자리에서 간단하게 자기 프로그램을 테스트 할 수 있는 방법에 대해 포스트하고 싶습니다. 따라서 인수 테스트(계약 조건이 만족되었는지 확인하기 위해 구입자와 납품자가 모두 보는 앞에서 시행하는 테스트) 등의 테스트는 생략하고 기입했습니다.
아래 표를 보고, 어떤 기법이 있는지 테스트 전 주르륵 읽어 보는 것만으로도 테스트 계획이 머리속에 정립됩니다.
No. | 테스트 기법 이름 | 테스트 기법 설명 |
1 | 블랙박스 테스트 | input과 output을 주고, 그 값이 나오는지 확인하는 방법 |
2 | 화이트박스 테스트 | 코드를 보며 내부 구조를 해석하고 알맞게 작성되었는지 확인하는 테스트 |
3 | 단위 테스트 | 모듈 테스트라고도 하며, 테스트 가능한 가장 작은 단위인 함수 단위로 테스트를 수행 |
4 | 통합 테스트 | 단위들을 결합한 모듈 단위로 테스트 |
5 | 시스템 테스트 | 실제 운용 환경에서 제대로 작동하는지 테스트 |
6 | 등가분할 | 테스트 범위를 동등하게 쪼개 테스트하는 기법 |
7 | 경계값 분석 | 다른 분기로 갈라져야 하는 경계선 부분의 값을 넣어 분기가 제대로 나눠지고 있는지 테스트 |
8 | 분류 트리 | 데이터를 분류할 때, 트리 구조로 분류 구조를 그려 보고 잘 분류되는지 확인하는 테스트 |
9 | 상태 전이 테스트 | FSM 을 사용할 때, 각 상태 전이가 잘 이루어지는지 확인하는 테스트 |
10 | 결정 테이블 테스팅 | 여러 사항을 분류할 때, 각 사항이 잘 분류되었는지 확인 |
11 | 조합 테스트 기법 | 가능한 모든 input 의 조합을 테스트 케이스로 생성하는 기법 |
12 | 시나리오 테스트 기법 | 흐름을 기반으로 시나리오를 작성하고, 해당 시나리오대로 잘 작동하는지 확인하는 기법 |
13 | 오류 추정 | '여러 경험에 의해, 이 시점에서는 이런 오류가 발생할 것이다.' 하는 부분을 테스트하는 기법 |
처음에는 모든 테스트 기법을 사용해 보려 했으나, 테스트 환경을 세팅하는 시간이 굉장히 오래 걸려 불필요하다고 느꼈습니다. 따라서 저는 아래 두 가지 방법만 사용하는 것이 제일 좋은 것 같습니다.
순서 | 테스트 방법 | 목적 |
1 | 단위 화이트박스 테스트 | 불필요한 DB 반복 접근을 하고 있는지 확인 어떤 테스트를 해 보면 좋을지 리스트 작성 |
2 | 통합 블랙박스 테스트 | 다양한 기법을 활용하여 테스트 |
2. 테스트 계획을 수립하기 위해 단위 화이트박스 테스트를 실시합니다.
방법은 이렇습니다.
모든 함수를 한줄 한줄 읽으며
- 테스트를 해 보아야 할 것 같은 부분을 기록합니다.
- 특별히 사용할 기법이 있다면 기법도 적어 주도록 합니다.
- 작성한 내용에 따른 테스트 계획을 적어 봅니다.

3. 통합 블랙박스 테스트를 위한 문서를 작성합니다.
문서를 작성하지 않고 테스트하는 것은 위험합니다. 나중에 어떤 테스트를 했는지 까먹을 수도 있고, 불필요한 테스트를 하게 되기도 합니다. 위에서 적은 테스트 리스트를 기반으로, 테스트 케이스를 설계해 봅니다.
위 예시를 기반으로 설계해 보겠습니다.
# 상자 열기 조건 경계값 분석을 위해,
input 의 열쇠 개수를 다르게 입력해야 할 것 같습니다.
상자를 여는 데 필요한 열쇠 개수가 100개일 때, 경계값 분석을 위해 99,100,101을 테스트 입력값으로 넣도록 하겠습니다.
그리고, 다른 조건들을 기입할 수 있도록 '기타' 컬럼도 추가해 두도록 하겠습니다.

# 열쇠 개수 차감 확인을 위해,
결과값 변동을 확인해야 할 것 같습니다.
결과가 어떻게 변화는지 컬럼을 추가합니다.
그리고, 다른 기타 출력들을 기록할 수 있도록 '출력'컬럼도 만들어 둡니다.

마지막으로, 테스트 결과를 기록할 컬럼을 추가했습니다.
4. 통합 블랙박스 테스트를 실시합니다.
설계한 대로 테스트를 수행하고, 결과를 기록합니다.

위 경우에서는, 실패가 1건 발생했습니다. 에러 원인을 분석하고, 기입해 둡니다.
테스트가 실패했으므로 코드를 수정하고, 다시 테스트합니다.

위 경우에서는, 테스트에 성공했습니다. 주의할 점으로는 '테스트 범위'가 있는데요, 기존에 단위 테스트를 실시했던 항목에 대해서는 테스트를 번복하지 않도록 합니다. 이것이 테스트 기록을 남겨야 하는 이유이기도 합니다! 이전에 어떤 테스트를 해 보았는지 기록해 둔다면, 불필요하게 낭비되는 시간을 단축할 수 있습니다!
끝
'Server > C#' 카테고리의 다른 글
진짜 오랫동안 삽질했던, 프로그램 비정상 종료 대처법 (0) | 2023.10.11 |
---|---|
C#의 장점 (2) | 2023.08.03 |
[C#] out of range 에러에 대처하는 천재적인 방법 (0) | 2023.07.04 |
[C#] ??= (0) | 2023.06.20 |
[C#] FirstOrDefault (0) | 2023.06.20 |