Testes na Web de várias etapas
Monitore uma sequência registrada de URLs e interações com um site por meio de testes na Web de várias etapas. Este artigo explicará o processo de criação de um teste na Web de várias etapas com o Visual Studio Enterprise.
Importante
Os testes na Web de várias etapas foram preteridos. Recomendamos o uso de TrackAvailability() para enviar testes de disponibilidade personalizados em vez de testes na Web de várias etapas. Com o TrackAvailability() e os testes de disponibilidade personalizados, você pode executar testes em qualquer computação desejada e usar o C# para criar novos testes facilmente.
Os testes na Web de várias etapas são categorizados como testes clássicos e podem ser encontrados em Adicionar teste clássico no painel Disponibilidade.
Observação
Não há suporte para testes na Web de várias etapas na nuvem do Azure Government.
Alternativa ao teste na Web de várias etapas
Os testes na Web de várias etapas dependem de arquivos de teste na Web do Visual Studio. Foi anunciado que o Visual Studio 2019 será a última versão com a funcionalidade de teste na Web. Não haverá mais adição de novos recursos, mas ainda há suporte à funcionalidade de teste na Web no Visual Studio 2019, que continuará durante o ciclo de vida de suporte do produto.
Recomendamos o uso de TrackAvailability para enviar testes de disponibilidade personalizados em vez de testes na Web de várias etapas. Esta opção é a solução com suporte de longo prazo em cenários de teste de várias solicitações ou autenticações. Com o TrackAvailability() e os testes de disponibilidade personalizados, você pode executar testes em qualquer computação desejada e usar o C# para criar novos testes facilmente.
Pré-requisitos
Você precisa de:
- Visual Studio 2017 Enterprise ou superior.
- Ferramentas de teste de carga e desempenho Web do Visual Studio.
Para localizar o pré-requisito das ferramentas de teste, selecione Instalador do Visual Studio>Componentes individuais>Depuração e teste>Ferramentas de teste de carga e desempenho na Web.
Observação
Os testes na Web de várias etapas têm custos adicionais associados. Para saber mais, confira o guia de preços oficial.
Importante
O teste da Web de várias etapas depende da infraestrutura DNS da Internet pública para resolver os nomes de domínio dos pontos de extremidade testados. Se estiver usando DNS privado, você precisará confirmar se os servidores de nome de domínio público podem resolver todos os nomes de domínio do teste. Quando não for possível, você poderá usar os testes de TrackAvailability personalizados em vez disso.
Gravação de um teste na Web de várias etapas
Aviso
Não é mais recomendado o uso do gravador de várias etapas. O gravador foi desenvolvido para páginas HTML estáticas com interações básicas. Ele não fornece uma experiência funcional para páginas da Web modernas.
Para obter diretrizes de como criar testes na Web do Visual Studio, confira a documentação oficial do Visual Studio 2019.
Carregamento do teste na Web
- No portal do Application Insights, no painel Disponibilidade, selecione Adicionar teste clássico. Depois, selecione Várias etapas como o SKU.
- Carregue o teste na Web de várias etapas.
- Defina os locais, a frequência e os parâmetros de alerta do teste.
- Selecione Criar.
Frequência e localização
| Configuração | Descrição |
|---|---|
| Frequência do teste | define a frequência com que o teste é executado em cada localização de teste. Com uma frequência padrão de cinco minutos e cinco locais de teste, seu site é testado em média a cada minuto. |
| Locais de teste | Os locais de onde nossos servidores enviam solicitações da Web para a sua URL. O número mínimo de locais de teste recomendado é cinco para garantir que você possa diferenciar problemas no seu site de problemas na rede. Você pode selecionar até 16 locais. |
Critérios de êxito
| Configuração | Descrição |
|---|---|
| Tempo limite de teste | diminua esse valor para ser alertado sobre respostas lentas. O teste é considerado uma falha se as respostas de seu site não forem recebidas dentro desse período. Se você tiver selecionado Analisar solicitações dependentes, todas as imagens, arquivos de estilo, scripts e outros recursos dependentes devem ter sido recebidos dentro desse período. |
| Resposta HTTP | O código de status retornado que é contado como êxito. O código 200 indica que uma página da Web normal foi retornada. |
| Correspondência de conteúdo | Uma cadeia de caracteres, como "Boas vindas!". Fazemos o teste para verificar se uma correspondência exata de maiúsculas e minúsculas ocorre em cada resposta. É necessário que seja uma cadeia de caracteres simples, sem curingas. Lembre-se de que se o conteúdo da sua página for alterado, talvez seja necessário atualizá-la. Somente os caracteres da língua inglesa são compatíveis com a correspondência de conteúdo. |
Alertas
| Configuração | Descrição |
|---|---|
| Quase em tempo real (versão prévia) | É recomendável usar alertas quase em tempo real. A configuração desse tipo de alerta é feita após a criação do teste de disponibilidade. |
| Limite de locais de alerta | é recomendável um mínimo de 3/5 locais. A relação ideal entre o limite de locais de alerta e o número de locais de teste é o limite de locais de alerta = número de locais de teste - 2, com no mínimo cinco locais de teste. |
Configuração
Siga estas etapas de configuração.
Tempo de conexão e números aleatórios no teste
Suponha que você esteja testando uma ferramenta que obtém dados dependentes de tempo, como ações de um feed externo. Ao gravar o teste na Web você deve usar horários específicos, definindo-os como parâmetros do teste, StartTime e EndTime.
Ao executar o teste, você deseja que EndTime sempre seja a hora atual. StartTime deve ser 15 minutos antes.
O plug-in de data e hora do teste na Web fornece a maneira de lidar com os tempos de parametrização.
Adicione um plug-in de teste na Web para cada valor de parâmetro variável desejado. Na barra de ferramentas de teste na Web, selecione Adicionar Plug-in de Teste na Web.
Neste exemplo, usamos duas instâncias do plug-in de Data e Hora. Uma instância é de "15 minutos atrás" e outra de "agora".
Abra as propriedades de cada plug-in. Atribua um nome e configure-o para usar a hora atual. Para uma delas, defina Adicionar Minutos = -15.
Nos parâmetros de teste na Web, use
{{plug-in name}}para fazer referência a um nome de plug-in.
Agora, carregue seu teste no portal. Ele usará os valores dinâmicos em todas as execuções do teste.
Considere entrar
Se os usuários entrarem em seu aplicativo, você terá várias opções para simular entradas para poder testar as páginas por trás da entrada. A abordagem usada dependerá do tipo de segurança fornecida pelo aplicativo.
Em todos os casos, crie uma conta no aplicativo somente para teste. Se possível, restrinja as permissões da conta de teste para que não haja possibilidade de que os testes na Web afetem usuários reais.
Senha e nome de usuário simples
Grave um teste na Web da maneira usual. Exclua os cookies primeiro.
Autenticação de SAML
| Nome da propriedade | Descrição |
|---|---|
| URI de público-alvo | O URI de audiência do token SAML. Esse URI é para o Serviço de Controle de Acesso, incluindo o namespace e o nome do host do Controle de Acesso. |
| Senha de certificado | A senha do certificado do cliente que permitirá acesso à chave privada inserida. |
| Certificado do cliente | O valor do certificado do cliente com a chave privada no formato codificado em Base64. |
| Identificador de nome | O identificador de nome exclusivo do token. |
| Não após | O intervalo de tempo durante o qual o token será válido. O padrão é 5 minutos. |
| Não antes de | O intervalo de tempo durante o qual um token criado anteriormente será válido (para compensar distorções de tempo). O padrão é de 5 minutos (negativos). |
| Nome do parâmetro do contexto de destino | O parâmetro do contexto que receberá a declaração gerada. |
Segredo do cliente
Se seu aplicativo tiver uma rota de entrada que envolva um segredo do cliente, use-a. O Azure AD (Azure Active Directory) é um exemplo de serviço que fornece uma entrada com segredo do cliente. No Azure AD, o segredo do cliente é a chave de aplicativo.
Veja um teste na Web de exemplo de um aplicativo Web do Azure que usa uma chave de aplicativo.
- Obtenha um token do Azure AD usando o segredo do cliente (a chave de aplicativo).
- Extraia o token de portador da resposta.
- Chame a API usando o token de portador no cabeçalho de autorização.
- Verifique se o teste na Web é um cliente real. Ou seja, se ele tem o próprio aplicativo no Azure AD. Use a ID do cliente e a chave de aplicativo. O serviço em teste também tem o próprio aplicativo no Azure AD. O URI da ID desse aplicativo é refletido no teste na Web no campo de recurso.
Autenticação aberta
Um exemplo de autenticação aberta é entrar com a conta Microsoft ou a conta do Google. Muitos aplicativos que usam OAuth fornecem a alternativa de segredo do cliente. Portanto, sua primeira tática deve ser investigar essa possibilidade.
Se o teste precisar entrar usando OAuth, a abordagem geral será:
- Use uma ferramenta como o Fiddler para examinar o tráfego entre o navegador da web, o site de autenticação e seu aplicativo.
- Executar duas ou mais entradas usando computadores ou navegadores diferentes ou em longos intervalos (para permitir que os tokens expirem).
- Ao comparar sessões diferentes, identifique o token retornado do site de autenticação, que será enviado ao servidor de aplicativos após a entrada.
- Registre um teste na Web usando o Visual Studio.
- Parametrize os tokens. Defina o parâmetro quando o token for retornado do autenticador e use-o na consulta ao site. (O Visual Studio tenta parametrizar o teste, mas não parametriza os tokens corretamente).
Solução de problemas
Para obter ajuda na solução de problemas, confira o artigo Solução de problemas dedicado.