Test Studio

  • 아티클

Test Studio를 사용하여 캔버스 앱의 종합적인 UI 테스트를 빌드합니다. 새 변경 내용 또는 업데이트가 배포될 때 앱이 예상대로 작동하는지 지속적으로 유효성을 검사하여 앱 품질을 유지 관리합니다.

개요

테스트는 소프트웨어 개발 수명 주기(SDLC)의 중요한 부분입니다. 테스트를 통해 고객에게 제공되는 앱의 품질을 보장할 수 있습니다. 테스트로 릴리스 프로세스 초기에 문제 또는 결함을 식별할 수 있으며 변경 내용을 릴리스하기 전에 앱을 보다 안정적으로 만들기 위해 관련 문제를 해결할 기회가 제공됩니다. 앱의 크기 및 사용량에 따라 새 변경 내용을 수동으로 테스트하는 것으로 충분할 수 있습니다. 그러나 앱의 복잡성과 사용량이 증가함에 따라 수동 테스트 대신 테스트 전략을 고려해야 할 수도 있습니다. 중요 업무용 앱인 경우에는 작은 실수도 큰 영향을 줄 수 있습니다.

앱 변경 내용이 증가하면 테스트 주기가 길어질 수 있습니다. 결국, 앱의 재발 테스트가 새로운 기능을 개발하는 데 걸린 시간보다 길어질 수 있습니다. 빠르게 진행되는 개발 과정에서 앱의 모든 기능을 철저하게 테스트하는 것은 소프트웨어 업데이트 릴리스에 대한 병목 상태를 초래합니다. 테스트 주기 중에, 그리고 재발 테스트 시 소요되는 시간을 줄이는 한 가지 옵션은 테스트 자동화입니다. 테스트 자동화를 사용하면 최소한의 노력으로 앱을 테스트할 수 있어 테스트 시간이 감소하고 릴리스 전에 중요한 문제가 식별됩니다.

Power Apps Test Studio는 캔버스 앱의 테스트를 작성, 구성 및 자동화하는 코드를 적게 사용하는 솔루션입니다. Test Studio에서 Power Apps 식을 사용하여 테스트를 작성하거나 레코더를 사용하여 자동으로 식을 생성하는 앱 상호 작용을 저장할 수 있습니다. Test Studio 내에서 작성된 테스트를 재생하여 앱 기능의 유효성을 검사하고, 웹 브라우저에서 테스트를 실행하고, 자동화된 테스트를 앱 배포 프로세스에 빌드할 수도 있습니다.

Test Studio

전제 조건

Test Studio로 앱을 테스트하려면 앱의 작성자 또는 공동 담당자여야 합니다.

Test Studio 용어

다음 섹션에서는 주요 Test Studio 용어에 대해 설명합니다.

테스트 사례

테스트 사례는 테스트 단계라는 일련의 지침 또는 작업으로 구성됩니다. 테스트 사례는 앱 또는 앱의 특정 기능이 예상대로 작동하는지 유효성을 검사하기 위해 실행합니다. 예를 들어 경비 앱에서 연결된 실제 비용을 포함하는 경비만 제출할 수 있도록 설정하려고 합니다. 테스트 사례를 통해 이 조건 또는 요구 사항이 항상 충족되는지 확인할 수 있습니다.

Test Studio에서 테스트 단계는 Power Apps 식 언어를 사용하여 작성됩니다. 테스트 식은 앱을 빌드할 때 사용할 수 있는 함수와 자동화된 테스트를 지원하는 추가 식으로 구성될 수 있습니다.

테스트 도구 모음

테스트 도구 모음은 테스트 사례를 함께 구성하거나 그룹화하는 데 사용됩니다. 앱의 테스트 사례 수가 증가함에 따라 테스트 사례를 특정 기능으로 구성하는 것을 고려할 수 있습니다. 예를 들어 경비 보고서 제출의 유효성을 검사하는 테스트 사례를 포함하는 하나의 테스트 도구 모음과 경비 승인에만 초점을 맞춘 또 다른 테스트 도구 모음을 구성할 수 있습니다.

테스트 도구 모음에 포함된 테스트 사례는 순차적으로 실행됩니다. 앱 상태는 도구 모음의 모든 테스트 사례에서 지속됩니다. 예를 들어 앱의 화면 5에서 완료되는 테스트 사례가 있는 경우 테스트 도구 모음의 다음 테스트 사례는 화면 5에서 실행되기 시작합니다. 단일 도구 모음 내에서 복잡한 테스트 시나리오를 여러 테스트 사례로 분류할 수 있으며 상태는 모든 테스트 사례에서 공유됩니다. 두 번째 테스트 사례가 앱의 시작 화면에서 시작될 것으로 예상되는 경우 테스트 사례의 첫 번째 단계인 시작 화면으로 이동할 수 있습니다. 테스트 실행을 계획하는 경우 테스트 도구 모음의 모든 테스트 사례가 시작될 때 앱은 다시 로드되지 않는다는 점을 기억해야 합니다.

테스트 어설션

모든 테스트 사례에는 예상 결과가 있어야 합니다. 테스트의 실제 결과와 비교하여 테스트의 예상 결과에 대한 유효성을 검사하려면 테스트 어설션을 작성하면 됩니다. 어설션은 테스트에서 true 또는 false로 평가되는 식입니다. 식이 false를 반환하는 경우 테스트 사례는 실패합니다.

위의 경비 앱 예제에서는 경비 라인 항목에 0 비용이 연결된 경비 보고서가 생성되었는지 유효성을 검사하는 어설션을 작성할 수 있습니다.

유용한 정보

Test Studio를 사용하여 캔버스 앱을 테스트하는 경우 다음 모범 사례를 최대한 활용하여 앱 품질을 개선하는 것이 좋습니다.

  1. 자동화해야 하는 테스트 사례를 결정합니다.

    모든 테스트를 자동화하는 것은 어려우므로 테스트 자동화에 전적으로 의존하지 않는 것이 좋습니다. 테스트 자동화 외에도 수동 테스트를 수행해야 합니다. 자동화에 가장 적합한 테스트는 다음과 같습니다.

    • 반복 테스트.
    • 비즈니스 영향이 큰 기능 테스트.
    • 안정적이며 진행 중인 큰 변경이 없는 기능.
    • 여러 데이터 집합이 필요한 기능.
    • 많은 시간과 노력이 필요한 수동 테스트.

  2. 테스트 사례를 작게 유지합니다.

    단일 테스트 사례가 앱의 모든 기능 테스트를 지원할 수 있지만, 모놀리식 테스트 사례를 작성하지 않고 여러 테스트 사례로 분할하는 것이 좋습니다. 각 테스트 사례는 앱의 특정 기능을 테스트할 수 있습니다. 하나의 큰 테스트 사례에서 어설션이 실패하면 다른 기능이 계속 테스트되지 않을 수 있습니다. 테스트 도구 모음에 포함된 여러 테스트 사례를 사용하면 이전 테스트 사례가 실패했는지 여부에 관계없이 다른 기능이 테스트될 수 있습니다. 이 전략을 사용하면 테스트 실패를 보다 쉽게 격리할 수 있습니다.

  3. 식을 단일 테스트 작업으로 유지합니다.

    테스트 작업에는 여러 식이 포함될 수 있습니다. 단일 단계에 대한 큰 다중 작업 테스트 식은 테스트 실패를 디버그하고 격리하는 기능에 영향을 줄 수 있습니다. 문제를 더 빠르게 식별하려면 여러 작업을 포함하는 테스트 단계를 여러 테스트 단계로 분할하는 것이 좋습니다.

  4. 모든 테스트 사례에는 예상 결과가 있어야 합니다.

    각 테스트 사례에는 하나 이상의 예상 결과가 있어야 합니다. 테스트 어설션을 통해 실제 결과와 비교하여 테스트의 예상 결과에 대한 유효성을 검사해야 합니다. 단일 테스트 사례에 대한 여러 어설션이 작성될 수 있습니다.

  5. 테스트 도구 모음을 사용합니다.

    유지 관리를 위해 비슷한 테스트 사례를 그룹화하거나 분류하고 테스트의 목적 및 예상 결과를 설명합니다.

알려진 제한 사항

Power Apps Test Studio에서 전체 제어 범위를 제공하는 작업이 진행되는 동안에는 현재 다음 기능을 사용할 수 없습니다.

  • 구성 요소.
  • Power Apps Component Framework에서 작성된 코드 구성 요소.
  • 중첩된 갤러리.
  • 미디어 컨트롤.
  • 앱에 대한 수식 수준 오류 관리 실험적 기능을 켜야 합니다.
  • Select 및 SetProperty 함수에 나열되지 않은 컨트롤 지원.
  • 인물 유형 열.
  • Test Studio는 실험적인 Git version 컨트롤 기능과 호환되지 않으며 해당 기능이 활성화된 경우 제대로 작동하지 않습니다.

다음 단계

참조 항목

참고

귀사의 설명서 언어 기본 설정에 대해 말씀해 주시겠습니까? 간단한 설문 조사에 응해주세요. (이 설문 조사는 영어로 되어 있습니다.)

이 설문 조사는 약 7분 정도 걸립니다. 개인 데이터는 수집되지 않습니다(개인정보처리방침).