다중 단계 웹 테스트Multi-step web tests

다단계 웹 테스트를 통해 웹 사이트와의 상호 작용 및 URL의 기록된 시퀀스를 모니터링할 수 있습니다.You can monitor a recorded sequence of URLs and interactions with a website via multi-step web tests. 이 문서에서는 Visual Studio Enterprise를 사용하여 다단계 웹 테스트를 만드는 과정을 안내합니다.This article will walk you through the process of creating a multi-step web test with Visual Studio Enterprise.

참고

다단계 웹 테스트는 Visual Studio webtest 파일에 따라 달라집니다.Multi-step web tests depend on Visual Studio webtest files. Visual Studio 2019가 웹 테스트 기능을 사용하는 마지막 버전이 될 것이라고 발표했습니다.It was announced that Visual Studio 2019 will be the last version with webtest functionality. 새 기능이 추가되는 것은 아니지만 Visual Studio 2019의 웹 테스트 기능은 현재 지원되며 제품의 지원 수명 주기 동안 계속 지원된다는 점을 이해해야 합니다.It is important to understand that while no new features will be added, webtest functionality in Visual Studio 2019 is still currently supported and will continue to be supported during the support lifecycle of the product. Azure Monitor 제품 팀은 여기에서 다단계 단계 가용성 테스트의 미래와 관련된 질문을 해결했습니다.The Azure Monitor product team has addressed questions regarding the future of multi-step availability tests here.

다단계 웹 테스트는 Azure Government 클라우드에서 지원되지 않습니다.Multi-step web tests are not supported in the Azure Government cloud.

필수 구성 요소Pre-requisites

  • Visual Studio 2017 Enterprise 이상Visual Studio 2017 Enterprise or greater.
  • Visual Studio 웹 성능 및 부하 테스트 도구Visual Studio web performance and load testing tools.

테스트 도구 필수 구성 요소를 찾으려면 다음을 실행합니다.To locate the testing tools pre-requisite. Visual Studio 설치 관리자 > 개별 구성 요소 > 디버깅 및 테스트 > 웹 성능 및 부하 테스트 도구를 시작합니다.Launch the Visual Studio Installer > Individual components > Debugging and testing > Web performance and load testing tools.

웹 성능 및 부하 테스트 도구 항목 옆에 있는 확인란을 선택하여 개별 구성 요소가 선택된 Visual Studio 설치 관리자 UI의 스크린샷

참고

다단계 웹 테스트에는 이와 관련된 추가 비용이 있습니다.Multi-step web tests have additional costs associated with them. 자세한 내용은 공식 가격 책정 가이드를 참조하세요.To learn more consult the official pricing guide.

다단계 웹 테스트 기록Record a multi-step web test

경고

다단계 레코더를 사용하는 것이 더 이상 권장되지 않습니다.We no longer recommend using the multi-step recorder. 이 레코더는 기본 상호 작용이 포함된 정적 HTML 페이지에 대해 개발되었으며, 최신 웹 페이지에 대한 기능 환경을 제공하지 않습니다.The recorder was developed for static HTML pages with basic interactions, and does not provide a functional experience for modern web pages.

Visual Studio 웹 테스트를 만드는 방법에 대한 지침은 공식 Visual Studio 2019 설명서를 참조하세요.For guidance on creating Visual Studio web tests consult the official Visual Studio 2019 documentation.

웹 테스트 업로드Upload the web test

  1. 가용성 창의 Application Insights 포털에서 테스트 만들기 > 테스트 형식 > 다단계 웹 테스트를 선택합니다.In the Application Insights portal on the Availability pane select Create Test > Test type > Multi-step web test.

  2. 테스트 위치, 빈도 및 경고 매개 변수를 설정합니다.Set the test locations, frequency, and alert parameters.

빈도 및 위치Frequency & location

설정Setting 설명Explanation
테스트 빈도Test frequency 각 테스트 위치에서 테스트를 실행하는 빈도를 설정합니다.Sets how often the test is run from each test location. 5분에 5번의 테스트를 하는 기본 빈도로 사이트를 평균 1분마다 테스트합니다.With a default frequency of five minutes and five test locations, your site is tested on average every minute.
테스트 위치Test locations 서버가 URL로 웹 요청을 보내는 곳입니다.Are the places from where our servers send web requests to your URL. 웹 사이트 문제를 네트워크 문제와 구분할 수 있도록 적어도 5개 이상의 테스트 위치를 권장합니다.Our minimum number of recommended test locations is five in order to insure that you can distinguish problems in your website from network issues. 최대 16 개의 위치를 선택할 수 있습니다.You can select up to 16 locations.

성공 조건Success criteria

설정Setting 설명Explanation
테스트 시간 제한Test timeout 느린 응답에 대한 알림을 받으려면 이 값을 감소시킵니다.Decrease this value to be alerted about slow responses. 해당 기간 내에 사이트에서 응답을 받지 못한 경우 테스트는 실패로 계산됩니다.The test is counted as a failure if the responses from your site have not been received within this period. 종속 요청 구문 분석을 선택한 경우 모든 이미지, 스타일 파일, 스크립트 및 다른 종속된 리소스도 해당 기간 내에 받아야 합니다.If you selected Parse dependent requests, then all the images, style files, scripts, and other dependent resources must have been received within this period.
HTTP 응답HTTP response 성공으로 계산되어 반환된 상태 코드입니다.The returned status code that is counted as a success. 200은 일반적인 웹 페이지의 반환을 나타내는 코드입니다.200 is the code that indicates that a normal web page has been returned.
콘텐츠 일치Content match "Welcome!"과 같은 문자열A string, like "Welcome!" 정확한 대/소문자 구분 일치가 모든 응답에서 발생하는지 테스트합니다.We test that an exact case-sensitive match occurs in every response. 와일드카드 없는 일반 문자열이어야 합니다.It must be a plain string, without wildcards. 페이지 내용이 변경되면 업데이트해야 할 수 있습니다.Don't forget that if your page content changes you might have to update it. 콘텐츠 일치에서는 영어 문자만 지원됩니다.Only English characters are supported with content match

경고Alerts

설정Setting 설명Explanation
거의 실시간(미리 보기)Near-realtime (Preview) 거의 실시간으로 경고를 사용하는 것이 좋습니다.We recommend using Near-realtime alerts. 이 유형의 경고 구성은 가용성 테스트를 만든 후에 수행됩니다.Configuring this type of alert is done after your availability test is created.
클래식Classic 새 가용성 테스트에 대한 클래식 경고를 사용하는 것이 더 이상 권장되지 않습니다.We no longer recommended using classic alerts for new availability tests.
경고 위치 임계값Alert location threshold 최소 3/5 위치를 사용하는 것이 좋습니다.We recommend a minimum of 3/5 locations. 경고 위치 임계값과 테스트 위치 수 사이의 최적 관계는 경고 위치 임계값 = 테스트 위치 수 - 2이고, 최소 테스트 위치 수는 5입니다.The optimal relationship between alert location threshold and the number of test locations is alert location threshold = number of test locations - 2, with a minimum of five test locations.

구성Configuration

테스트에 시간과 난수 연결Plugging time and random numbers into your test

외부 피드에서 주식과 같이 시간에 따라 변하는 데이터를 가져오는 도구를 테스트한다고 가정합니다.Suppose you're testing a tool that gets time-dependent data such as stocks from an external feed. 웹 테스트를 기록할 때 특정 시간을 사용해야 하지만 테스트 매개 변수로 StartTime 및 EndTime을 설정할 수 있습니다.When you record your web test, you have to use specific times, but you set them as parameters of the test, StartTime and EndTime.

내 뛰어난 재고 앱 스크린샷

테스트를 실행하면 EndTime이 항상 현재 시간이 되고 StartTime은 15분이 됩니다.When you run the test, you'd like EndTime always to be the present time, and StartTime should be 15 minutes ago.

웹 테스트 날짜 시간 플러그 인은 매개 변수화된 시간을 처리하는 방법을 제공합니다.The Web Test Date Time Plugin provides the way to handle parameterize times.

  1. 원하는 각 가변 매개 변수 값에 대한 웹 테스트 플러그 인을 추가합니다.Add a web test plug-in for each variable parameter value you want. 웹 테스트 도구 모음에서 웹 테스트 플러그 인 추가를 선택합니다.In the web test toolbar, choose Add Web Test Plugin.

    웹 테스트 플러그 인 추가

    이 예에서는 날짜 시간 플러그인의 두 인스턴스를 사용합니다.In this example, we use two instances of the Date Time Plug-in. 한 인스턴스는 "15분 전"이고 다른 하나는 "지금"입니다.One instance is for "15 minutes ago" and another for "now."

  2. 각 플러그인의 속성을 엽니다.Open the properties of each plug-in. 이름을 지정하고 현재 시간을 사용하도록 설정합니다.Give it a name and set it to use the current time. 둘 중 하나에 대해 Add Minutes = -15를 설정합니다.For one of them, set Add Minutes = -15.

    컨텍스트 매개 변수

  3. 웹 테스트 매개 변수에 {{플러그 인 이름}}을(를) 사용하여 플러그 인 이름을 참조합니다.In the web test parameters, use {{plug-in name}} to reference a plug-in name.

    StartTime

이제 테스트를 포털에 업로드합니다.Now, upload your test to the portal. 테스트의 모든 실행에 동적 값을 사용합니다.It will use the dynamic values on every run of the test.

로그인 처리Dealing with sign-in

사용자가 앱에 로그인하면 로그인 뒤에 페이지를 테스트할 수 있도록 로그인을 시뮬레이션하기 위한 여러 옵션이 있습니다.If your users sign in to your app, you have various options for simulating sign-in so that you can test pages behind the sign-in. 앱에서 제공하는 보안의 형식에 따라 사용하는 방법이 달라집니다.The approach you use depends on the type of security provided by the app.

모든 경우에 테스트하기 위해 애플리케이션에 계정을 만들어야 합니다.In all cases, you should create an account in your application just for the purpose of testing. 웹 테스트가 실제 사용자에 영향을 줄 가능성이 발생하지 않도록 가능하면 이 테스트 계정의 사용 권한을 제한합니다.If possible, restrict the permissions of this test account so that there's no possibility of the web tests affecting real users.

간단한 사용자 이름 및 암호 일반적인 방법으로 웹 테스트를 기록합니다.Simple username and password Record a web test in the usual way. 우선 쿠키를 삭제합니다.Delete cookies first.

SAML 인증SAML authentication

속성 이름Property name DescriptionDescription
대상 URIAudience Uri SAML 토큰에 대한 대상 URI입니다.The audience URI for the SAML token. ACS 네임스페이스 및 호스트 이름을 포함하여 ACS(Access Control Service)에 대한 URI입니다.This is the URI for the Access Control Service (ACS) – including ACS namespace and host name.
인증서 암호Certificate Password 포함된 프라이빗 키에 대한 액세스 권한을 부여하는 클라이언트 인증서의 암호입니다.The password for the client certificate which will grant access to the embedded private key.
클라이언트 인증서Client Certificate Base64 인코딩 형식의 프라이빗 키가 있는 클라이언트 인증서 값입니다.The client certificate value with private key in Base64 encoded format.
이름 식별자Name Identifier 토큰의 이름 식별자The name identifier for the token
다음 이후로는 아님Not After 토큰이 유효한 시간 간격입니다.The timespan for which the token will be valid. 기본값은 5분입니다.The default is 5 minutes.
이전이 아님Not Before 이전에 만든 토큰이 유효한 시간 범위입니다(시간 왜곡 문제 해결).The timespan for which a token created in the past will be valid (to address time skews). 기본값은 (음수) 5분입니다.The default is (negative) 5 minutes.
대상 컨텍스트 매개 변수 이름Target Context Parameter Name 생성된 어설션을 수신하는 컨텍스트 매개 변수입니다.The context parameter that will receive the generated assertion.

클라이언트 암호 앱에 클라이언트 암호를 포함하는 로그인 경로가 있는 경우 해당 경로를 사용합니다.Client secret If your app has a sign-in route that involves a client secret, use that route. AAD(Azure Active Directory)는 클라이언트 암호 로그인을 제공하는 서비스의 예입니다.Azure Active Directory (AAD) is an example of a service that provides a client secret sign-in. AAD에서 클라이언트 암호는 앱 키입니다.In AAD, the client secret is the App Key.

앱 키를 사용하는 Azure 웹앱의 샘플 웹 테스트는 다음과 같습니다.Here's a sample web test of an Azure web app using an app key:

샘플 스크린샷

클라이언트 암호(AppKey)를 사용하여 AAD에서 토큰을 가져옵니다.Get token from AAD using client secret (AppKey). 응답에서 전달자 토큰을 추출합니다.Extract bearer token from response. 인증 헤더에서 전달자 토큰을 사용하여 API를 호출합니다.Call API using bearer token in the authorization header. 웹 테스트는 실제 클라이언트여야 합니다. 즉, AAD에 고유한 앱이 있고 clientId + 앱 키를 사용합니다.Make sure that the web test is an actual client - that is, it has its own app in AAD - and use its clientId + app key. 테스트 대상 서비스는 AAD에 고유한 앱을 가집니다. 이 앱의 appID URI는 리소스 필드의 웹 테스트에 반영됩니다.Your service under test also has its own app in AAD: the appID URI of this app is reflected in the web test in the resource field.

공개 인증Open Authentication

공개 인증의 예는 Microsoft 또는 Google 계정으로 로그인하는 것입니다.An example of open authentication is signing in with your Microsoft or Google account. OAuth를 사용하는 많은 앱은 클라이언트 암호 대안을 제공하므로 첫 번째 방법으로 해당 가능성을 조사해야 합니다.Many apps that use OAuth provide the client secret alternative, so your first tactic should be to investigate that possibility.

테스트가 OAuth를 사용하여 로그인해야 하는 경우 일반적인 방법은 다음과 같습니다.If your test must sign in using OAuth, the general approach is:

Fiddler와 같은 도구를 사용하여 웹 브라우저, 인증 사이트 및 응용 프로그램 간의 트래픽을 검사합니다.Use a tool such as Fiddler to examine the traffic between your web browser, the authentication site, and your app. 다른 컴퓨터 또는 브라우저를 사용하거나 긴 간격으로 두 개 이상의 로그인을 수행합니다(토큰이 만료되도록 허용).Perform two or more sign-ins using different machines or browsers, or at long intervals (to allow tokens to expire). 다른 세션을 비교하여 인증 사이트에서 다시 전달된 토큰을 식별하고 이는 로그인한 후에 앱 서버에 전달됩니다.By comparing different sessions, identify the token passed back from the authenticating site, that is then passed to your app server after sign-in. Visual Studio Online을 사용하여 웹 테스트 기록Record a web test using Visual Studio. 토큰을 매개 변수화하고 토큰이 인증자에서 반환되면 매개 변수를 설정하고 사이트에 대한 쿼리에서 사용합니다.Parameterize the tokens, setting the parameter when the token is returned from the authenticator, and using it in the query to the site. (Visual Studio는 테스트를 매개 변수화하려고 하지만 올바르게 토큰을 매개 변수화하지 않습니다.)(Visual Studio attempts to parameterize the test, but does not correctly parameterize the tokens.)

문제 해결Troubleshooting

전용 문제 해결 문서Dedicated troubleshooting article.

다음 단계Next steps