Testes Web de vários passos
Você pode monitorar uma sequência gravada de URLs e interações com um site por meio de testes da Web em várias etapas. Este artigo orienta você pelo processo de criação de um teste da Web de várias etapas com o Visual Studio Enterprise.
Importante
Os testes da Web em várias etapas foram preteridos. Recomendamos a utilização de TrackAvailability() para submeter testes de disponibilidade personalizados em vez de testes Web de vários passos. Com TrackAvailability() e os testes de disponibilidade personalizados, pode executar testes em qualquer computação que deseje e utilizar C# para criar facilmente novos testes.
Os testes da Web em várias etapas são categorizados como testes clássicos e podem ser encontrados em Adicionar teste clássico no painel Disponibilidade .
Nota
Não há suporte para testes da Web em várias etapas na nuvem do Azure Government.
Alternativa de teste da Web em várias etapas
Os testes da Web em várias etapas dependem dos arquivos de teste da Web do Visual Studio. Foi anunciado que o Visual Studio 2019 será a última versão com funcionalidade de teste da Web. Embora nenhum novo recurso seja adicionado, a funcionalidade de teste da Web no Visual Studio 2019 ainda é suportada atualmente e continuará a ser suportada durante o ciclo de vida de suporte do produto.
Recomendamos o uso de TrackAvailability para enviar testes de disponibilidade personalizados em vez de testes da Web em várias etapas. Esta opção é a solução suportada a longo prazo para cenários de teste de autenticação ou solicitação múltipla. Com TrackAvailability() e os testes de disponibilidade personalizados, pode executar testes em qualquer computação que deseje e utilizar C# para criar facilmente novos testes.
Pré-requisitos
Necessita de:
- Visual Studio 2017 Enterprise ou superior.
- Ferramentas de teste de carga e desempenho da Web do Visual Studio.
Para localizar o pré-requisito das ferramentas de teste, selecione Visual Studio Installer>Componentes>individuais Depurando e testando>o desempenho da Web e as ferramentas de teste de carga.
Nota
Os testes Web em várias etapas têm custos adicionais associados. Para saber mais, consulte o guia de preços oficial.
Importante
O teste da Web em várias etapas depende da infraestrutura DNS da Internet pública para resolver os nomes de domínio dos pontos de extremidade testados. Se você estiver usando DNS privado, deverá garantir que os servidores de nomes de domínio público possam resolver todos os nomes de domínio do teste. Quando isso não for possível, você pode usar testes personalizados de TrackAvailability em vez disso.
Gravar um teste da Web em várias etapas
Aviso
Não recomendamos mais 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 orientação sobre como criar testes da Web do Visual Studio, consulte a documentação oficial do Visual Studio 2019.
Carregue o teste da Web
- No portal do Application Insights, no painel Disponibilidade , selecione Adicionar teste clássico. Em seguida, selecione Várias etapas como a SKU.
- Carregue o seu teste Web em várias etapas.
- Defina os locais de teste, a frequência e os parâmetros de alerta.
- Selecione Criar.
Frequência e localização
| Definição | Descrição |
|---|---|
| Frequência de teste | Define a frequência com que o teste é executado a partir de cada local de teste. Com uma frequência predefinida de cinco minutos e cinco localizações de teste, o site é testado, em média, a cada minuto. |
| Localizações de teste | Os locais a partir dos quais os nossos servidores enviam pedidos Web para o seu URL. Nosso número mínimo de locais de teste recomendados é cinco para garantir que você possa distinguir problemas em seu site de problemas de rede. Pode selecionar até 16 localizações. |
Critérios de êxito
| Definição | Descrição |
|---|---|
| Tempo limite de teste | Diminua esse valor para ser alertado sobre respostas lentas. O teste é contado como uma falha se as respostas do seu site não tiverem sido recebidas dentro desse período. Se você selecionou Analisar solicitações dependentes, todas as imagens, arquivos de estilo, scripts e outros recursos dependentes devem ter sido recebidos dentro desse período. |
| HTTP response | O código de status retornado que é contado como um sucesso. O código 200 indica que uma página da Web normal foi retornada. |
| Correspondência de conteúdo | Uma corda, como "Bem-vindo!" Testamos se uma correspondência exata que diferencia maiúsculas de minúsculas ocorre em todas as respostas. Tem de ser uma cadeia simples, sem carateres universais. Não se esqueça de que, se o conteúdo da sua página for alterado, talvez seja necessário atualizá-lo. Apenas caracteres em inglês são suportados com correspondência de conteúdo. |
Alertas
| Definição | Descrição |
|---|---|
| Quase em tempo real (pré-visualização) | Recomendamos o uso de alertas quase em tempo real. A configuração desse tipo de alerta é feita após a criação do teste de disponibilidade. |
| Limite de localização de alerta | Recomendamos um mínimo de 3/5 locais. A relação ideal entre o limite de local de alerta e o número de locais de teste é o número = de locais de teste de local de alerta - 2, com um mínimo de cinco locais de teste. |
Configuração
Siga estas etapas de configuração.
Conecte o tempo e números aleatórios ao seu teste
Suponha que você esteja testando uma ferramenta que obtém dados dependentes do tempo, como preços de ações, de um feed externo. Quando você grava seu teste da Web, você tem que usar horários específicos, mas você defini-los como parâmetros do teste, StartTime e EndTime.
Quando você executa o teste, você quer EndTime sempre ser o tempo presente. StartTime deve ser 15 minutos antes.
O plug-in Web Test Date Time fornece a maneira de lidar com tempos de parâmetro.
Adicione um plug-in de teste da Web para cada valor de parâmetro variável desejado. Na barra de ferramentas de teste da Web, selecione Adicionar plug-in de teste da Web.
Neste exemplo, utilizamos duas instâncias do Plug-in Data/Hora. Um exemplo é para "15 minutos atrás" e outro é para "agora".
Abra as propriedades de cada plug-in. Atribua um nome e defina-o para utilizar a hora atual. Para um deles, defina Adicionar minutos = -15.
Nos parâmetros de teste da Web, use
{{plug-in name}}para fazer referência a um nome de plug-in.
Agora, carregue o teste no portal. Ele usará valores dinâmicos em cada execução do teste.
Considere iniciar sessão
Se os seus utilizadores iniciarem sessão na sua aplicação, terá várias opções para simular o início de sessão, de modo a poder testar páginas depois do início de sessão. A abordagem que utiliza depende do tipo de segurança fornecida pela aplicação.
Em todos os casos, crie uma conta em seu aplicativo apenas para teste. Se possível, restrinja as permissões da conta neste teste, para que não haja nenhuma possibilidade de os testes Web afetarem os utilizadores reais.
Nome de utilizador e palavra-passe simples
Grave um teste Web como habitualmente. Elimine primeiro os cookies.
Autenticação SAML
| Property name | Description |
|---|---|
| URI do público | O URI de audiência para o token SAML. Esse URI é para o serviço Controle de Acesso, incluindo o namespace do Controle de Acesso e o nome do host. |
| Palavra-passe do certificado | A senha para o certificado do cliente, que concederá acesso à chave privada incorporada. |
| Certificado de cliente | O valor do certificado do cliente com chave privada no formato codificado em Base64. |
| Identificador de nome | O identificador de nome para o token. |
| Não depois | O período de tempo durante o qual o token será válido. O padrão é 5 minutos. |
| Não antes | O período de tempo para o qual um token criado no passado será válido (para lidar com distorções de tempo). O padrão é (negativo) 5 minutos. |
| Nome do parâmetro de contexto de destino | O parâmetro de contexto que receberá a asserção gerada. |
Segredo do cliente
Se a sua aplicação tiver uma rota de início de sessão que envolva um segredo do cliente, utilize-a. O Azure Ative Directory (Azure AD) é um exemplo de um serviço que fornece um início de sessão secreto do cliente. No Azure AD, o segredo do cliente é a chave do aplicativo.
Aqui está um exemplo de teste da Web de um aplicativo Web do Azure usando uma chave de aplicativo.
- Obtenha um token do Azure AD usando o segredo do cliente (a chave do aplicativo).
- Extraia um token de portador da resposta.
- Chame a API usando o token de portador no cabeçalho de autorização.
- Certifique-se de que o teste da Web é um cliente real. Ou seja, que ele tem seu próprio aplicativo no Azure AD. Use sua ID de cliente e chave de aplicativo. Seu serviço em teste também tem seu próprio aplicativo no Azure AD. O URI do ID do aplicativo deste aplicativo é refletido no teste da Web no campo de recurso.
Autenticação aberta
Um exemplo de autenticação aberta é o ato de iniciar sessão com a sua conta Microsoft ou Google. Muitas aplicações que utilizam a OAuth fornecem uma alternativa ao segredo do cliente. Por isso, a primeira tática deve ser investigar essa possibilidade.
Se o teste precisar entrar usando OAuth, a abordagem geral é:
- Utilizar uma ferramenta como o Fiddler para examinar o tráfego entre o browser, o site de autenticação e a aplicação.
- Iniciar duas sessões ou mais com computadores ou browsers diferentes ou com longos intervalos (para permitir a expiração dos tokens).
- Ao comparar diferentes sessões, identifique o token passado de volta do site de autenticação que, em seguida, é passado para o servidor de aplicativos após o login.
- Grave um teste da 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 corretamente os tokens.)
Resolução de Problemas
Para obter ajuda na solução de problemas, consulte o artigo dedicado à solução de problemas .