complete functional testing guide with its types
유형, 기술 및 예가 포함 된 심층 포괄적 인 기능 테스트 자습서 :
기능 테스트 란 무엇입니까?
기능 테스트는 응용 프로그램이나 시스템의 기능이 예상대로 작동하는지 확인하기 위해 수행되는 일종의 블랙 박스 테스트입니다.
응용 프로그램의 모든 기능을 확인하기 위해 수행됩니다.
이 시리즈에서 다루는 자습서 목록 :
튜토리얼 # 1 : 기능 테스트 란? (이 튜토리얼)
튜토리얼 # 2 : 기능 테스트 인터뷰 질문
튜토리얼 # 3 : 최고의 기능 자동화 테스트 도구
튜토리얼 # 4 : 비 기능 테스트 란 무엇입니까?
튜토리얼 # 5 : 단위, 기능 및 완성 테스팅
튜토리얼 # 6 : 기능 및 성능 테스트를 동시에 수행해야하는 이유
도구 :
튜토리얼 # 7 : Ranorex Studio를 사용한 기능 테스트 자동화
튜토리얼 # 8 : UFT 기능 도구의 새로운 기능
튜토리얼 # 9 : Parrot QA 도구를 사용한 크로스 브라우저 기능 자동화
튜토리얼 # 10 : 기능 테스트를위한 Jubula 오픈 소스 도구 자습서
학습 내용 :
기능 테스트 소개
허용되는 행동과 그렇지 않은 행동을 정의하는 무언가가 있어야합니다.
이는 기능 또는 요구 사항 사양에 지정되어 있습니다. 사용자가 그렇게 할 수있는 작업을 설명하는 문서로, 응용 프로그램이나 시스템의 적합성을 결정할 수 있습니다. 또한 때로는 실제 비즈니스 측면 시나리오의 유효성을 검사해야 할 수도 있습니다.
따라서 기능 테스트는 다음을 통해 수행 할 수 있습니다. 두 가지 인기있는 기술 :
- 요구 사항에 따른 테스트 : 수행 할 모든 테스트의 기초를 형성하는 모든 기능 사양을 포함합니다.
- 비즈니스 시나리오를 기반으로 한 테스트 : 비즈니스 프로세스 관점에서 시스템을 인식하는 방법에 대한 정보를 포함합니다.
테스트 및 품질 보증은 SDLC 프로세스의 큰 부분입니다. 테스터로서 우리는 매일 직접 관여하지 않더라도 모든 유형의 테스트를 인식해야합니다.
테스트는 바다이기 때문에 그 범위는 참으로 방대합니다. 다양한 종류의 테스트 . 대부분의 우리 모두는 대부분의 개념에 익숙해야하지만 여기에서 모두 구성하는 것은 나쁘지 않습니다.
기능 테스트 유형
기능 테스트에는 여러 범주가 있으며 이러한 범주는 시나리오에 따라 사용할 수 있습니다.
가장 눈에 띄는 유형은 아래에서 간략하게 설명합니다.
단위 테스트 :
단위 테스트는 일반적으로 특정 기능을 달성하기 위해 관련되거나 관련이 없을 수있는 다른 코드 단위를 작성하는 개발자가 수행합니다. 그의, 이것은 일반적으로 각 단위의 메소드를 호출하고 필요한 매개 변수가 전달 될 때이를 검증하는 단위 테스트를 작성하는 것을 수반하며 리턴 값은 예상대로입니다.
코드 커버리지는 아래 세 가지를 다루기 위해 테스트 케이스가 존재해야하는 단위 테스트의 중요한 부분입니다.
i) 라인 커버리지
ii) 코드 경로 범위
iii) 분석법 적용
온 전성 테스트 : 애플리케이션 / 시스템의 모든 주요 기능과 핵심 기능이 올바르게 작동하는지 확인하기 위해 수행되는 테스트입니다. 이것은 일반적으로 연기 테스트 후에 수행됩니다.
연기 테스트 : 빌드 안정성을 확인하기 위해 각 빌드가 릴리스 된 후 수행되는 테스트입니다. 빌드 검증 테스트라고도합니다.
회귀 테스트 : 새 코드 추가, 개선 사항, 버그 수정이 기존 기능을 손상 시키거나 불안정성을 유발하지 않고 사양에 따라 작동하는지 확인하기 위해 수행 된 테스트입니다.
회귀 테스트는 실제 기능 테스트만큼 광범위 할 필요는 없지만 기능이 안정적이라는 것을 증명하기 위해 범위의 양만 보장해야합니다.
통합 테스트 : 시스템이 개별적으로 완벽하게 작동 할 수있는 여러 기능 모듈에 의존하지만 엔드 투 엔드 시나리오를 달성하기 위해 함께 결합 할 때 일관되게 작동해야하는 경우 이러한 시나리오의 검증을 통합 테스트라고합니다.
베타 / 유용성 테스트 : 제품은 환경과 같은 프로덕션에서 실제 고객에게 노출되고 제품을 테스트합니다. 사용자의 편안함은 이것에서 비롯되며 피드백을받습니다. 이는 사용자 수락 테스트와 유사합니다.
이것을 간단한 흐름도로 표현해 보겠습니다.
기능 시스템 테스트 :
시스템 테스트 모든 모듈 또는 구성 요소가 통합되면 예상대로 작동하는지 확인하기 위해 전체 시스템에서 수행되는 테스트입니다.
종단 간 테스트 제품의 기능을 확인하기 위해 수행됩니다. 이 테스트는 기능 및 비 기능 요구 사항을 모두 포함하여 시스템 통합 테스트가 완료된 경우에만 수행됩니다.
방법
이 테스트 프로세스에는 세 가지 주요 단계가 있습니다.
접근 방식, 기법 및 예
eps 파일 사용 방법
기능 또는 동작 테스트는 주어진 입력을 기반으로 출력을 생성하고 시스템이 사양에 따라 올바르게 작동하는지 확인합니다.
따라서 그림 표현은 다음과 같이 보입니다.
입출국 기준
참가 기준 :
- 요구 사항 사양 문서가 정의되고 승인되었습니다.
- 테스트 케이스가 준비되었습니다.
- 테스트 데이터가 생성되었습니다.
- 테스트 환경이 준비되었으며 필요한 모든 도구를 사용할 수 있으며 준비되었습니다.
- 전체 또는 부분 응용 프로그램이 개발되고 단위 테스트를 거쳐 테스트 할 준비가되었습니다.
종료 기준 :
- 모든 기능 테스트 케이스의 실행이 완료되었습니다.
- 중요하지 않거나 P1, P2 버그가 열려 있지 않습니다.
- 보고 된 버그가 확인되었습니다.
관련 단계
이 테스트와 관련된 다양한 단계는 다음과 같습니다.
- 관련된 첫 번째 단계는 테스트해야 할 제품의 기능을 결정하는 것이며 주요 기능, 오류 상태 및 메시지 테스트, 사용성 테스트 (예 : 제품이 사용자 친화적인지 여부 등)를 포함합니다.
- 다음 단계는 요구 사항 사양에 따라 테스트 할 기능에 대한 입력 데이터를 만드는 것입니다.
- 나중에 요구 사항 사양에서 테스트중인 기능에 대한 출력이 결정됩니다.
- 준비된 테스트 케이스가 실행됩니다.
- 실제 출력, 즉 테스트 케이스 실행 후 출력과 예상 출력 (요구 사양에서 결정됨)을 비교하여 기능이 예상대로 작동하는지 여부를 찾습니다.
접근하다
다양한 종류의 시나리오를 '테스트 사례'의 형태로 생각하고 작성할 수 있습니다. QA 직원으로서 우리 모두는 테스트 케이스의 골격이 어떻게 보이는지 알고 있습니다.
주로 네 부분으로 구성됩니다.
- 테스트 요약
- 전제 조건
- 테스트 단계 및
- 예상 결과.
모든 종류의 테스트를 작성하려는 시도는 불가능할뿐만 아니라 시간과 비용이 많이 듭니다.
일반적으로 기존 테스트로 이스케이프없이 최대 버그를 발견하려고합니다. 따라서 QA는 최적화 기술을 사용하고 테스트에 접근하는 방법을 전략화해야합니다.
이것을 예.
기능 테스트 사용 사례 예 :
직원이 자신의 사용자 계정과 암호로 로그인하는 온라인 HRMS 포털을 사용하십시오. 로그인 페이지에는 사용자 이름 및 암호를위한 두 개의 텍스트 필드와 로그인 및 취소의 두 개의 버튼이 있습니다. 로그인에 성공하면 HRMS 홈페이지로 이동하고 취소하면 로그인이 취소됩니다.
사양은 다음과 같습니다.
#1 ) 사용자 ID 필드는 최소 6 자, 최대 10 자, 숫자 (0-9), 문자 (a-z, A-z), 특수 문자 (밑줄, 마침표, 하이픈 만 허용)이며 비워 둘 수 없습니다. 사용자 ID는 특수 문자가 아닌 문자 또는 숫자로 시작해야합니다.
#두) 비밀번호 필드는 최소 6 자, 최대 8 자, 숫자 (0-9), 문자 (a-z, A-Z), 특수 문자 (모두)를 사용하며 공백 일 수 없습니다.
이 시나리오를 테스트하는 기본 접근 방식은 크게 두 가지 범주로 분류 할 수 있습니다.
- 긍정적 인 테스트 및
- 부정적인 테스트
물론 이러한 각 범주에는 수행 될 테스트의 하위 섹션이 있습니다.
양성 테스트 제품이 최소한 고객 사용에 필수적인 기본 요구 사항을 충족하는지 확인하기 위해 수행되는 행복한 경로 테스트입니다.
부정적인 시나리오 예상치 못한 데이터에 노출 된 경우에도 제품이 올바르게 작동하는지 확인하십시오.
추천 읽기 => 네거티브 테스트 란 무엇이며 네거티브 테스트 케이스를 작성하는 방법
이제 아래 순서도를 사용하여 테스트 기술을 구성 해 보겠습니다. 각 테스트에 대해 자세히 살펴 보겠습니다.
기능 테스트 기법
# 1) 최종 사용자 기반 / 시스템 테스트
테스트중인 시스템에는 함께 결합 될 때 사용자 시나리오를 달성하는 많은 구성 요소가있을 수 있습니다.
에서 예 , 고객 시나리오에는 HRMS 애플리케이션로드, 올바른 자격 증명 입력, 홈 페이지로 이동, 일부 작업 수행 및 시스템 로그 아웃과 같은 작업이 포함됩니다. 이 특정 흐름은 기본 비즈니스 시나리오에서 오류없이 작동해야합니다.
다음은 몇 가지 샘플입니다.
| Sl 아니오 | 요약 | 전제 조건 | 테스트 케이스 | 예상 결과. |
|---|---|---|---|---|
| 1. | 완전한 권한을 가진 사용자는 계정을 변경할 수 있습니다. | 1) 사용자 계정이 있어야합니다. 2) 사용자는 필요한 권한이 있어야합니다. | 1) 사용자가 사용자 ID와 비밀번호를 입력합니다. 2) 사용자는 계정 자체를 수정할 수있는 수정 권한을 확인합니다. 3) 사용자가 계정 정보를 수정하고 저장합니다. 4) 사용자가 로그 아웃합니다. | 1) 사용자가 홈페이지에 로그인했습니다. 2) 편집 화면이 사용자에게 표시됩니다. 3) 계정 정보가 저장됩니다. 4) 사용자가 로그인 페이지로 돌아갑니다. |
| 두. | 전체 권한이없는 다른 유효한 사용자 | 1) 사용자 계정이 있어야합니다. 2) 사용자는 최소한의 권한이 있어야합니다. | 1) 사용자가 사용자 ID와 비밀번호를 입력합니다. 2) 사용자는 특정 필드 만 수정할 수있는 수정 권한을 볼 수 있습니다. 3) 사용자가 해당 필드 만 수정하고 저장합니다. 4) 사용자가 로그 아웃합니다. | 1) 사용자가 홈페이지에 로그인했습니다. 2) 편집 화면은 특정 필드에서만 사용자에게 표시됩니다. 계정 필드는 회색으로 표시됩니다. 3) 수정 된 필드가 저장됩니다. 4) 사용자가 로그인 페이지로 돌아갑니다. |
이것은 상황에 대해 테스트 케이스를 작성하는 방법의 기본 예입니다. 위의 형식은 아래의 모든 테스트에도 적용됩니다. 강력한 개념적 접지를 위해 위와 아래에 몇 가지 간단한 테스트 만 넣었습니다.
# 2) 동등성 테스트
에 등가 분할 , 테스트 데이터는 등가 데이터 클래스라는 다양한 파티션으로 분리됩니다. 각 파티션의 데이터는 동일한 방식으로 작동해야하므로 하나의 조건 만 테스트하면됩니다. 마찬가지로 파티션의 한 조건이 작동하지 않으면 다른 조건이 작동하지 않습니다.
예를 들어 , 위 시나리오에서 사용자 ID 필드는 최대 10 자일 수 있으므로 10보다 큰 데이터 입력은 동일한 방식으로 작동해야합니다.
# 3) 경계 값 테스트
경계 테스트는 응용 프로그램에 대한 데이터 제한을 의미하고 작동 방식을 검증합니다.
따라서 입력이 경계 값을 초과하여 공급되면 음성 테스트로 간주됩니다. 따라서 사용자의 최소 6자가 경계 제한을 설정합니다. 사용자 ID를 갖도록 작성된 테스트<6 characters are boundary analysis tests.
# 4) 의사 결정 기반 테스트
의사 결정 기반 테스트는 특정 조건이 충족 될 때 시스템의 가능한 결과에 대한 이념을 중심으로 이루어집니다.
위의 시나리오에서 다음과 같은 의사 결정 기반 테스트를 즉시 도출 할 수 있습니다.
- 잘못된 자격 증명을 입력하면 사용자에게이를 알리고 로그인 페이지를 다시로드해야합니다.
- 사용자가 올바른 자격 증명을 입력하면 다음 UI로 이동해야합니다.
- 사용자가 올바른 자격 증명을 입력했지만 로그인을 취소하려는 경우 다음 UI로 이동하여 로그인 페이지를 다시로드하면 안됩니다.
# 5) 대체 흐름 테스트
대체 경로 테스트를 실행하여 기능을 수행하는 기본 흐름을 제외하고 존재하는 모든 가능한 방법을 검증합니다.
# 6) 임시 테스트
위의 기술을 통해 대부분의 버그가 발견되면 임시 테스트 이전에 관찰되지 않은 불일치를 발견 할 수있는 좋은 방법입니다. 이러한 작업은 시스템을 무너 뜨리고 정상적으로 응답하는지 확인하려는 마음가짐으로 수행됩니다.
예를 들어 , 샘플 테스트 케이스는 다음과 같습니다.
- 사용자가 로그인되었지만 관리자가 일부 작업을 수행하는 동안 사용자 계정을 삭제합니다. 응용 프로그램이 이것을 우아하게 처리하는 방법을 보는 것은 흥미로울 것입니다.
기능 테스트와 비 기능 테스트 :
비 기능 테스트 전체 애플리케이션 / 시스템의 품질에 중점을 둡니다. 따라서 시스템이 수행하는 기능과 달리 고객 요구 사항에 따라 시스템이 얼마나 잘 수행되는지 추론하려고합니다.
기능 테스트 자동화
기능 테스트를 자동화 할 수 있습니까?
자동화를 통해 수동 작업을 줄이고 시간을 절약 할 수 있으며 버그 미끄러짐을 피할 수 있으며 효율성을 높일 수 있습니다.
그러나 모든 것을 자동화하는 것은 불가능합니다. 이 테스트는 자동화 될 수 있지만 자동화를 수행하려면 사용자가 테스트 케이스를 준비해야합니다. 적절한 도구와 함께 자동화 할 올바른 테스트 사례를 찾는 것이 중요합니다.
기능적 사례를 자동화하는 것은 테스트 사례의 수가 훨씬 더 많고 반복해서 회귀하는 경우 (완료해야 함) 개발자가 코드 변경 사항을 커밋하는 데 문제가 발생할 수있는 단점이있을 수 있습니다.
결함 이스케이프 분석을 수행하는 동안 여러 번, 이탈의 현저하고 지속적인 원인이 특정 기능에 대한 테스트 범위가 부족한 것으로 보입니다.
다시 말하지만, 환경 부족, 테스터 부족, 너무 많은 기능 제공, 모든 테스트 측면을 다룰 시간 감소, 때로는 단순히 간과하는 등 여러 가지 원인이 있습니다.
전담 테스트 팀이 각 스프린트 또는 각 테스트주기에 대해 자세한 테스트를 수행 할 수 있지만 결함은 항상 존재하며 놓칠 수있는 결함이 항상 있습니다. 이는 테스트 자동화를 갖추기위한 기본적인 요구 사항 중 하나이며, 따라서 전체 테스트 프로세스 및 테스트 케이스 범위의 효율성이 현저하게 향상됩니다.
자동화 된 테스트가 수동 테스트를 대체 할 수는 없지만 두 가지를 이상적으로 조합하는 것은 소프트웨어 프로젝트에서 원하는 품질을 유지하는 데 필수적입니다.
자동화 고려 사항 :
#1) 올바른 자동화 도구 선택 : 시장에는 몇 가지 도구가 있습니다. 자동화 도구를 선택하는 것은 정말 어려운 작업입니다! 그러나 사용할 자동화 도구를 선택할 수있는 요구 사항 목록을 만들 수 있습니다.
고려해야 할 몇 가지 주요 측면은 다음과 같습니다.
- 필요한 기술이 아직없는 경우 팀의 모든 QA 구성원이 사용하기 쉬운 도구를 선택합니다.
- 이 도구는 다양한 환경에서 사용할 수 있습니다. 에 대한 예 : 스크립트를 한 OS 플랫폼에서 생성하고 다른 플랫폼에서 실행할 수 있습니까? CLI 자동화, UI 자동화, 모바일 애플리케이션 자동화 또는 모두가 필요합니까?
- 도구에는 필요한 모든 기능이 있어야합니다. 에 대한 예 : 일부 테스터가 스크립팅 언어에 능숙하지 않은 경우 도구에 녹음 및 재생 기능이 있어야하며 녹음 된 스크립트를 원하는 스크립팅 언어로 변환 할 수 있어야합니다. 마찬가지로 자동화 된 빌드 테스트, 특정보고 및 로깅을 지원하는 도구가 필요한 경우에도이를 수행 할 수 있어야합니다.
- 이 도구는 UI 변경시 테스트 케이스의 재사용 성을 지원할 수 있어야합니다.
자동화 도구 : 기능 자동화에 사용할 수있는 도구가 많이 있습니다. Selenium은 아마도 인기가 많 겠지만 Sahi, Watir, Robotium, AutoIt 등과 같은 다른 오픈 소스 도구가 있습니다.
시장에서 여러 테스트 자동화 도구를 사용할 수 있습니다. 그러나 적절한 도구를 선택하는 것은 조직에 매우 중요합니다. 요구 사항, 사용 용이성 및 비용에 따라 달라질 수 있습니다.
다음은 최고의 기능 테스트 도구 중 일부입니다.
- 셀렌
- QTP
- Junit
- 로드 러너
- 비누
- TestComplete
=> 최고의 기능 자동화 도구의 전체 목록을 확인하십시오.
#두) 자동화 할 올바른 테스트 사례 선택 : 자동화를 최대한 활용하려면 자동화하기 위해 선택한 테스트 유형에 대해 현명하게 대처하는 것이 중요합니다. 테스트 실행 중에 일부 설정 및 구성을 켜고 끄는 테스트가있는 경우 자동화되지 않은 상태로 두는 것이 가장 좋습니다.
따라서 다음과 같은 테스트를 자동화 할 수 있습니다.
- 반복적으로 실행해야합니다.
- 다양한 종류의 데이터로 실행합니다.
- 일부 P1, P2 테스트 케이스는 많은 노력과 시간이 소요됩니다.
- 오류가 발생하기 쉬운 테스트.
- 다양한 환경, 브라우저 등에서 실행해야하는 테스트 세트입니다.
# 3) 전담 자동화 팀 : 이것은 대부분의 조직에서 간과되고 자동화는 QA 팀의 모든 구성원에게 부과됩니다.
각 팀원은 다양한 경험 수준, 기술 세트, 관심 수준, 자동화를 지원하는 대역폭 등을 가지고 있습니다. 일부 개인은 수동 테스트 실행에 더 능숙한 반면 다른 일부는 스크립팅 및 자동화 도구를 알고있을 수 있습니다.
이와 같은 상황에서는 팀의 모든 구성원을 분석하고 일부 구성원은 자동화 만 수행하도록하는 것이 좋습니다.
자동화 활동에는 시간, 노력, 지식 및 전담 팀이 필요합니다. 이는 팀의 모든 구성원에게 수동 및 자동화 테스트를 모두 과부하시키는 대신 필요한 결과를 달성하는 데 도움이됩니다.
# 4) 데이터 기반 테스트 : 여러 데이터 세트가 필요한 자동화 된 테스트 케이스는 재사용 가능하도록 잘 작성되어야합니다. 데이터는 텍스트 또는 속성 파일, XML 파일과 같은 소스로 작성되거나 데이터베이스에서 읽을 수 있습니다.
데이터 소스가 무엇이든 잘 구조화 된 자동화 데이터를 생성하면 프레임 워크를보다 쉽게 유지 관리하고 기존 테스트 스크립트를 최대한 활용할 수 있습니다.
회사 웹 사이트에서 세부 정보를 가로 채기 위해 어떤 유틸리티를 사용할 수 있습니까?
# 5) UI 변경이 테스트를 중단해서는 안됩니다. 선택한 도구를 사용하여 생성하는 테스트 케이스는 잠재적 인 UI 변경을 처리 할 수 있어야합니다. 예를 들어 이전 버전의 셀레늄은 페이지 요소를 식별하기 위해 위치를 사용했습니다.
따라서 UI가 변경되면 해당 요소가 해당 위치에서 더 이상 발견되지 않았으며 결과적으로 테스트의 대량 실패로 이어집니다.
따라서 도구의 단점을 미리 이해하고 UI 변경시 최소한의 변경 만 필요하도록 테스트 케이스를 작성하는 것이 중요합니다.
# 6) 빈번한 테스트 : 기본 자동화 테스트 버킷이 준비되면이 버킷을 더 자주 실행하도록 계획하십시오. 여기에는 양방향 이점이 있습니다. 하나는 자동화 프레임 워크를 향상시키고 더 강력하게 만들 수 있다는 것이고 두 번째는 프로세스에서 더 많은 버그를 포착 할 수 있다는 것입니다.
장점
기능 테스트의 다양한 장점은 다음과 같습니다.
- 이 테스트는 실제 시스템을 재현하거나 복제 한 것입니다. 즉, 실제 환경에있는 제품의 복제입니다. 테스트는 고객 사용량 (예 : 시스템 사양, 운영 체제, 브라우저 등)에 따른 사양에 중점을 둡니다.
- 시스템 구조에 대한 if 및 buts 또는 가정에서는 작동하지 않습니다.
- 이 테스트는 고객 요구 사항을 충족하는 고품질 제품을 제공하고 고객이 최종 결과에 만족하는지 확인합니다.
- 고객 요구 사항에 따라 모든 기능이 작동하는 버그없는 제품을 제공합니다.
- 위험 기반 테스트는 제품에서 모든 종류의 위험 가능성을 줄이기 위해 수행됩니다.
한계
이 테스트는 제품이 예상대로 작동하고 전체 요구 사항이 구현되고 제품이 고객 요구 사항에 정확히 맞는지 확인하기 위해 수행됩니다.
그러나 제품을 출시하기 전에 테스트의 일부가되어야하는 중요하고 매우 중요한 제품의 성능, 즉 응답 성, 처리 시간 등과 같은 다른 요소는 고려하지 않습니다.
단점
- 중복 테스트를 수행 할 가능성이 많습니다.
- 제품에서 논리적 오류가 누락 될 수 있습니다.
- 이 테스트는 요구 사항을 기반으로합니다. 요구 사항이 완전하지 않거나 복잡하거나 명확하지 않은 경우 이러한 시나리오에서이 테스트를 수행하는 것이 어려워지고 시간이 많이 걸릴 수 있습니다.
따라서 기본적으로 이러한 유형의 테스트는 모두 고품질 제품에 필요합니다.
결론
이 튜토리얼은 기능 테스트에 대해 알아야 할 모든 것을 기본부터 포괄적으로 논의했습니다.
기능 테스트는 제품 또는 응용 프로그램에서 가장 필요하고 실제로 중요한 측면 인 제품의 기능을 확인하므로 중요한 테스트 프로세스 중 하나입니다.
저자 정보 : Sanjay Zalavadia – 클라이언트 서비스 부사장 미풍 , IT 및 기술 지원 서비스 분야에서 15 년 이상의 리더십 경험을 보유하고 있습니다.
우리가 제안한 기술 중 일부가 모든 독자에게 도움이되기를 바랍니다. 아래 의견에 귀하의 생각을 알려주십시오.
추천 읽기 => 기능 테스트 튜토리얼