Cenário de aplicação
O desenvolvimento ainda não foi concluído, são as verificações do serviço, como sincronizar os testes? Assim que o servidor estiver configurado, o teste é obrigado a enviar um relatório. É hora extra?
Os testes parecem ser pós-trabalho. Somente depois que a versão for desenvolvida ou o servidor configurado é que a ação real pode ser tomada. E muitas vezes nesta fase também já chegou a data para o sistema (programa) ficar online. Realmente não é necessário fazer isso no estágio inicial, mas é exaustivo no estágio posterior.
Desta vez, usamos algumas ferramentas (MockServer, Rest Assured) para implementar testes de API (interface) prospectivos antes de o servidor ser iniciado. E quando o servidor real é iniciado, você só precisa conectar o código de teste ao servidor real para ser executado.
Lembrete: Se você quiser seguir o exemplo, certifique-se de configurar as seguintes ferramentas.
O caso de uso é principalmente combinar as funções básicas do rest-Assured e do MockServer para fazer testes de API pré-automatizados. Para aqueles que não sabem sobre o rest-Assured, faça alguns trabalhos de casa extras (você pode consultar o rest-Assured artigo que escrevi antes , há etapas detalhadas de configuração e aplicação, e o MockServer também tem artigos básicos ).
-
IDE: IntelliJ IDEA
-
Linguagem: Java
-
Desenvolvimento de teste de API: fique tranquilo
-
Servidor API: MockServer
-
Estrutura de teste: TestNg
-
Tipo de projeto: Maven
foco no conhecimento
Aplicativo MockServer: verifique a solicitação recebida pelo servidor
fique tranquilo: simule solicitações de API
Configuração do projeto Maven
Configure o MockServer, tenha certeza em POM.xml.
Conforme mostrado na figura abaixo: MockServer e rest-Assured precisam ser introduzidos corretamente no nó <dependency> do pom.xml.
Dica: Se a dependência não for carregada automaticamente, você poderá carregá-la manualmente e o pacote jar correspondente será baixado.
Servidor simulado:
tenha certeza:
Decomposição do caso de teste
caso de teste
A descrição do caso de uso a seguir deve ser familiar. É uma descrição típica do BDD. Aqui escrevo os parâmetros e a solicitação de verificação juntos para a conveniência desta explicação. O ambiente real pode separar os dados da cena, que ficará mais clara.
Dado: o servidor API está em execução
Quando: O servidor recebe uma solicitação da API (endereço da API: http://localhost:10800/testing.retry/{id})
E: O parâmetro é "?testParameter=false"
E:(cabeçalho)头字段：headerId="id"; headerVersion="versão"; headerName="nome"
Então: Verifique se o servidor recebeu a solicitação correta
Exemplo: vezes: 1,
(cabeçalho)头字段：headerId="id"; headerVersion="versão"; headerName="nome"
Parâmetro: "?testParameter=false"
E: Verifique o código de resposta do servidor (200)
análise de caso de uso
Primeiro, construa um servidor que aceite a API e possa responder com 200 às solicitações de API elegíveis.
Endereço: http://localhost:10800/testing.retry/{id}
Parâmetros: ?testParameter=false
(cabeçalho)头字段：headerId = "id"; headerVersion = "versão"; headerName = "nome";
Quando o servidor recebe a solicitação, ele precisa verificar se recebeu a solicitação correta, e o número de solicitações é 1 e retorna 200.
1. A resposta do código pode ser verificada pelo Rest-Assured.
2. Os dados recebidos pelo servidor são verificados pelo MockSever.
Com o entendimento acima, agora são as etapas de implementação:
1. Servidor API - MockServer.
2. Crie expectativas de resposta da API (expectativas ativas) - MockServer.
3. Simule a solicitação – fique tranquilo e verifique o status da devolução.
4. Verifique o número de solicitações, parâmetros, campos de cabeçalho - MockServer.
5. Feche o MockerServer.
Dica: Esta etapa é muito importante para organizar os testes subsequentes e organizar o código de teste de forma sistemática e lógica.
Script de caso de uso TestNg
De acordo com a análise acima, vejamos passo a passo a implementação do código.
Dica: Este exemplo usa Java + Maven + testNg (se você não está familiarizado com essa combinação, pode ler meus artigos básicos relacionados ).
O script de teste completo é mostrado na imagem abaixo.
Código detalhado
1. Parâmetros globais
Podemos definir informações compartilhadas como variáveis, e o escopo da aplicação considerada pode ser definido como variáveis locais ou variáveis globais.
O que devo fazer se não conseguir determinar o que define variáveis locais ou variáveis globais?
Dica: Este problema é encontrado ao começar a escrever o código de teste, mesmo uma pessoa experiente terá o mesmo problema. Não se preocupe com isso, normalmente escreverei primeiro como uma variável local ou como uma variável fixa sem definir a variável. No final, quando o código de um caso de uso for escrito completamente, ficará claro à primeira vista, ao verificar o código, que variáveis locais ou globais estão definidas.
String headerId = "id";
String headerVersion = "version";
String headerName = "name";
String queryParameter = "testParameter";
String queryParameterValue = "false";
String baseURI = "http://localhost:10800";
int requestTime = 1;
private ClientAndServer mockServer;2. Servidor API - Servidor Simulado
Conforme mostrado na imagem: primeiro criamos um método startMockServer(), este método é para iniciar uma porta MockServer 10800. O endereço padrão é esta máquina: http://localhost:10800. A variável MockServer é chamada por outros métodos. Variáveis globais são definidas aqui.
private void startMockServer() {
mockServer = startClientAndServer(10800);
}3. Crie expectativas de resposta da API (expectativas ativas) - MockServer
Conforme analisado acima, precisamos que o servidor API responda com 200 às seguintes solicitações.
Nota: O {id} do endereço da solicitação é uma variável e a variável pathId é parametrizada no código
O método mockServerActiveExpectations () inicia o servidor API e cria expectativas de resposta da API (Expectativas Ativas).
Endereço: http://localhost:10800/testing.retry/{id}
Parâmetros: ?testParameter=false
(cabeçalho)头字段：headerId = "id"; headerVersion = "versão"; headerName="nome"
O aplicativo mockServerActiveExpectations():
startMockerServer() inicia o servidor API http://localhost:10800.
O código mockServer.when(request().withPath.... é para criar um Active Expectations, esta é a sintaxe padrão do MockServer, não se preocupe em não entender, apenas experimente.
4. Solicitação simulada – fique tranquilo, código de resposta de verificação 200
Esta é a sintaxe do rest-Assured. Simplificando, ele simula o comportamento do usuário e envia uma solicitação de API ao servidor http://localhost:10800/.
Nota: O cabeçalho (campo de cabeçalho) contém todos os dados de teste e "teste" é usado.
log().all : Apenas para depuração, pode ser removido ou mantido posteriormente.
5. Verifique o número de solicitações, parâmetros, campos de cabeçalho - MockServer
Para tornar o código conciso e fácil de ler e, ao mesmo tempo, reutilizável, aqui está um método de verificação separado.
verifyReceivedRequestDataAndTimes(), através do código, podemos ver que aqui serão verificados o caminho, os parâmetros, os métodos, os dados específicos do campo do cabeçalho e a quantidade de solicitações recebidas.
Não se preocupe, essa também é a sintaxe do MockServer.
6. Feche o servidor mocker
Não se esqueça, esta etapa também é crítica. O ambiente de teste é muito importante, especialmente quando você possui um conjunto de casos de teste. Os problemas causados pela não limpeza do meio ambiente são inúmeros.
execução de caso de uso
Ok, vamos testar os resultados primeiro. Aqui eu executo diretamente no IDE.
Abra o painel do MockerSever ao mesmo tempo: http://localhost:10800/mockserver/dashboard
Dicas: O código é executado muito rápido. Para capturar os registros do painel, adicione um tempo de espera de 20 segundos antes que o código feche o MockerSever.
Para aqueles que não entendem como visualizar este painel, você pode consultar meu artigo anterior sobre configuração e construção do MockServer para uma introdução detalhada.
A figura abaixo mostra o resultado da verificação da solicitação do MockerSever.
1. Detalhes do pedido de verificação;
2. Número de solicitações de autenticação.
Os dados da solicitação da API simulada pelo rest-Assured podem ser visualizados no log do código em execução, conforme mostrado na figura a seguir:
Verificação de erros e otimização de código
Agora fazemos alguns testes negativos para verificar se este caso de uso pode detectar bugs sob a solicitação e expectativa "erradas".
Verificamos se o servidor API recebeu 2 solicitações
Depois de executar o código, obteremos o seguinte erro: Esperávamos que o servidor recebesse 2 solicitações, mas na verdade recebemos 1 solicitação, então o erro relatou que nenhuma solicitação correspondente foi encontrada.
Clique em clique para ver a diferença, o lado direito da nova janela mostra a solicitação real recebida pelo servidor (apenas uma vez). Outras diferenças podem ser ignoradas, pois não há validação aqui.
Com base nessa alteração, se você visualizar o painel, não poderá ver as informações de verificação. O código de validação falha e todo o script é interrompido.
Portanto, melhoramos verifyReceivedRequestDataAndTimes() e adicionamos try ...catch..
Nota: Este método foi alterado para retornar um valor booleano, pois precisamos desse valor booleano para verificar o sucesso e a falha do caso de teste. Caso contrário, a validação do teste mostra uma falha, mas o caso de teste é executado com êxito. Consulte SoftAssert descrito abaixo.
Execute o código novamente: o painel pode exibir as informações de falha na verificação.
O método de verificação adiciona SoftAssert, para que o código encontre uma falha de verificação e continue a ser executado. Adicione também assertAll() no final. Dessa forma, a validação falha e o caso de uso falha.
Para poder verificar rapidamente onde está o erro no resultado da execução, melhore try..catch.. para imprimir o erro (aqui eu uso print, e é recomendado usar Log no ambiente real). Desta forma, percebe-se que a verificação falha, o caso de uso falha e o motivo da falha.
Verificamos se o cabeçalho não corresponde
Por exemplo, esperamos que o valor do headerId da solicitação seja "ID", mas a solicitação recebida pelo servidor seja "teste".
Os resultados da falha de verificação são os seguintes:
Resumir
Bem, isso completa como colocar um elefante na geladeira, não é difícil!
Quando o servidor real está online, basta apontar a solicitação Rest-Assured para o servidor de teste real e comentar o MockServer, mesmo que o chefe queira reportar no mesmo dia, podemos entregá-lo.
O texto acima é uma introdução. O mais importante é usar vários tipos de ferramentas de teste para atender às suas próprias necessidades de teste. Todos os grandes testadores podem aplicá-lo com flexibilidade e tirar inferências de uma instância.
Finalmente: O vídeo tutorial completo de teste de software abaixo foi classificado e carregado, e amigos que precisarem dele podem obtê-lo sozinhos [Garantido 100% gratuito]
Documentação da entrevista de teste de software
Devemos estudar para encontrar um emprego bem remunerado. As perguntas da entrevista a seguir são os materiais de entrevista mais recentes de empresas de Internet de primeira linha, como Ali, Tencent e Byte, e alguns chefes da Byte deram respostas confiáveis. Conclua este conjunto Os materiais de entrevista acredito que todos podem encontrar um emprego satisfatório.
