Teste automatizado da interface Python - resumo de perguntas comuns da entrevista

1. Qual é a interface do software?

Classes ou funções para transferência de dados e processamento entre diferentes módulos do programa

2. Qual é a diferença entre os protocolos HTTP e HTTPS?

Resposta: O protocolo https exige que uma CA (Autoridade de Certificação) se inscreva para obter um certificado. Geralmente, há menos certificados gratuitos, então uma certa taxa é exigida; http é um protocolo de transferência de hipertexto e as informações são transmitidas em texto simples. O protocolo Https é construído pelo protocolo SSL + Http O protocolo de rede para transmissão criptografada e autenticação de identidade é mais seguro do que o protocolo http; http e https usam métodos de conexão completamente diferentes e portas diferentes. O primeiro é 80 e o último é 443;

3. Em qual camada está o HTTPS?

Eu gostava de fazer perguntas sobre protocolos de rede nas entrevistas, alguns amigos disseram que instalei o X, o que não é prático. Um pouco de pesquisa sobre o conhecimento da rede, não é difícil responder de fato.
R: HTTPS na camada de aplicativo
Teste automatizado da interface Python - resumo de perguntas comuns da entrevista

4. Qual é a diferença entre get e post?

Resposta: POST e GET enviam dados ao servidor e ambos obtêm dados do servidor. Diferenças: 1) Método de transmissão: get é transmitido através da barra de endereço, post é transmitido através da mensagem 2) Comprimento de transmissão: O parâmetro get tem um limite de comprimento (limitado pelo comprimento da url) e post não tem limite 3) GET gera um pacote de dados TCP (para Para solicitações GET, o navegador enviará o cabeçalho http e os dados juntos, e o servidor responderá com 200 e retornará dados. O POST gerará dois pacotes TCP (para POST, o navegador enviará o cabeçalho primeiro e o servidor responderá com 100 para continuar. Enviar dados, o servidor responde com 200 ok para retornar os dados) 4) Os parâmetros da solicitação de obtenção serão totalmente retidos no histórico de navegação, mas os parâmetros no post não serão retidos 5) Ao fazer consulta de dados, é recomendado usar GET; ao fazer Ao adicionar, modificar ou excluir dados, a postagem é recomendada

5. Métodos comuns de envio de dados POST

Resposta: Existem quatro métodos principais: application / x-www-form-urlencoded, multipart / form-data, application / json, text / xml, etc.

6. O que é o protocolo sem estado do protocolo Http? Como resolver o protocolo sem estado do protocolo HTTP

Resposta: Stateless significa que o protocolo não tem capacidade de memória para o processamento de transações e o servidor não sabe o estado do cliente. Ou seja, após enviarmos uma solicitação HTTP ao servidor, o servidor nos enviará os dados de acordo com a solicitação, mas após o envio, nenhuma informação será gravada. HTTP é um protocolo sem estado, o que significa que cada solicitação é independente, e Keep-Alive não alterou esse resultado. A falta de status significa que se a informação anterior for necessária para um processamento posterior, ela deve ser retransmitida, o que pode resultar em um aumento na quantidade de dados transmitidos por conexão. Por outro lado, quando o servidor não necessita de informações prévias, sua resposta é mais rápida. Esta característica do protocolo HTTP tem vantagens e desvantagens. A vantagem é que libera o servidor. Cada requisição "ponto-a-parada" não causará ocupação desnecessária de conexão. A desvantagem é que cada requisição transmitirá uma grande quantidade de informação de conteúdo repetido. Após o surgimento de aplicativos da web em que o cliente e o servidor interagem dinamicamente, a natureza sem estado do HTTP dificultou seriamente a implementação desses aplicativos. Afinal, a interação requer uma ligação entre o passado e o futuro. Um programa de carrinho de compras simples também deve saber o que o usuário escolheu antes. mercadoria. Assim, surgiram duas tecnologias para manter o status da conexão HTTP, uma é Cookie e a outra é Session.

7. A diferença entre cookie e sessão

Resposta: Os dados do cookie são armazenados no navegador do cliente. Os dados da sessão no servidor não são muito seguros. Outros podem analisar os cookies armazenados localmente e realizar spoofing de cookies. Considerando a segurança, você deve usar a sessão da sessão. A sessão será armazenada por um determinado período de tempo. No servidor. Quando o número de visitas aumenta, o desempenho do seu servidor é afetado. Os cookies devem ser usados ​​para reduzir o desempenho do servidor. Um único cookie não pode armazenar mais de 4 K dados. Muitos navegadores limitam um site a salvar até 20 cookies. Você pode armazenar informações importantes, como informações de login. É uma sessão; outras informações precisam ser salvas e podem ser colocadas no cookie

8. Códigos de status de retorno comuns em interfaces de solicitação

Resposta:
1xx-Solicitação de informação (indicando uma resposta temporária. O cliente está pronto para receber uma ou mais respostas 1xx antes de receber uma resposta regular)
2xx-Sucesso (indicando que o servidor aceitou com sucesso a solicitação do cliente)
3xx-Redirecionamento (cliente O navegador do cliente deve realizar mais ações para atender à solicitação. Por exemplo, o navegador pode ter que solicitar uma página diferente no servidor ou repetir a solicitação por meio de um servidor proxy)
4xx-Erro do cliente (erro de envio, o cliente tem um problema. Por exemplo, , O cliente solicita uma página que não existe, e o cliente não fornece informações de verificação de ID válidas) 5xx-server error (o servidor não pode concluir a solicitação devido a um erro)
os códigos de retorno comuns são:
 200 OK- [GET]: O servidor retornou com sucesso os dados solicitados pelo usuário
 201 CREATED- [POST / PUT / PATCH]: O usuário criou ou modificou os dados com sucesso 
202 Aceepted- []: Indica que uma solicitação entrou na fila de fundo (tarefa assíncrona)
 204 SEM CONTEÚDO- [EXCLUIR ]: O usuário exclui os dados com sucesso
 400 INVALID REQUEST- [POST / PUT / PATCH]: A solicitação enviada pelo usuário tem um erro e o servidor não cria ou modifica os dados.  401 Unauthorized - []: Indica que o usuário não tem autoridade (token, Erro de nome de usuário, senha)
 403 Proibido - []: indica que o usuário está autorizado (ao contrário do erro 401), mas o acesso é proibido
 404 NÃO ENCONTRADO - []: A solicitação enviada pelo usuário é para um registro que não existe, e o servidor não Execute uma operação que seja idempotente
 406 Não Aceitável- [GET]: O formato solicitado pelo usuário não está disponível (por exemplo, o usuário solicita o formato JSON, mas apenas no formato XML)
 500 ERRO DO SERVIDOR INTERNO - [*]: O servidor tem um erro e o usuário não será capaz de determinar se a solicitação foi bem-sucedida

9. O que é DNS?

Resposta: DNS é o Sistema de Nome de Domínio. DNS é usado para resolução de nome de domínio. Depois de inserir o endereço da web na Internet, ele irá convertê-lo em um IP e, em seguida, irá para o servidor da outra parte; sem ele, você só quer ir para o Baidu Lembre-se do IP do Baidu, mas com o processamento de DNS, você só precisa lembrar o nome de domínio do site correspondente, ou seja, a URL.

10. Como sua empresa faz testes de interface?

Resposta: O teste de interface real é diferente do teste geral na parte de design do caso de teste. ① Obtenha as especificações da interface.
② Casos de uso de função de teste de interface de design (principalmente da perspectiva dos usuários para ver se a interface pode atender aos requisitos de negócios, design de caso de uso é o conjunto de casos de uso de caixa preta).
③ Verificação de vários parâmetros de entrada (condições normais, condições anormais incluem número incorreto de parâmetros de entrada, tipo incorreto, opcional / obrigatório e consideração de parâmetros mutuamente exclusivos ou relacionados).
④Várias verificações dos valores de retorno da interface (de acordo com os requisitos do documento da interface)
⑤ Compreender a lógica da implementação da interface e realizar a cobertura da lógica (declarações / condições / ramificação / julgamentos / ...)
⑥ A interface pode ser executada simultaneamente, é segura e o desempenho atende aos requisitos?
⑦ Ferramentas ou código autoescrito para verificação.
⑧ Encontrar o problema é o mesmo que o teste de função, o bug deve ser relatado e o status de rastreamento deve ser rastreado.

11. Como projetar casos de teste de interface?

Resposta: Geralmente, os seguintes aspectos precisam ser considerados ao projetar casos de teste de interface:
①Se as pré-condições são atendidas.Algumas interfaces precisam atender às pré-condições antes de poderem obter dados com sucesso. Normalmente, é necessário fazer login no caso de uso do Token Reverse: design 0 ~ n casos de uso para verificar se as pré-condições são atendidas (assumindo n condições)
② Se para carregar parâmetros de valor padrão Caso de uso futuro: os parâmetros com valores padrão não são preenchidos ou passados Parâmetro, parâmetros obrigatórios são preenchidos com valores "normais" corretos e existentes, outros não são preenchidos, design 1 caso de uso
③Regras de negócios, requisitos funcionais Aqui, de acordo com a situação de tempo, combinado com a descrição do parâmetro de interface, pode ser necessário projetar N casos de uso direto e reverso Caso de uso
④Se o parâmetro for necessário. Caso de uso reverso: para cada parâmetro necessário, crie um caso de uso reverso com valor de parâmetro vazio.
⑤ Se há correlações entre os parâmetros. Alguns parâmetros são mutuamente restritivos.
⑥ Limite de tipo de dados de parâmetro reverso Caso de uso: crie um caso de uso reverso para cada parâmetro que não corresponda ao tipo de valor do parâmetro
⑦ O valor do intervalo de dados do próprio tipo de dados do parâmetro é limitado. Caso de uso positivo: para todos os parâmetros, crie um valor de parâmetro de cada parâmetro para ser o maior dentro do intervalo de dados Caso de uso positivo

12. O que você testa para a interface?

Resposta:
Teste de usabilidade de acordo com o protocolo acordado, método, formato de conteúdo, transferência de dados para a interface e retorno do resultado esperado após o processamento:
 Se a função da interface está implementada corretamente;
 Teste de valor de retorno - O valor de retorno deve estar correto além do conteúdo e tipo. Certifique-se de que o chamador pode analisar corretamente;
 Valor limite do valor do parâmetro, teste de classe de equivalência; Teste de manipulação de erros e exceções
 Valor anormal de entrada (valor nulo, caractere especial, excedendo o comprimento acordado, etc.), a interface pode manipulá-lo corretamente e responder conforme o esperado ;
 parâmetros de entrada incorretos, a interface pode lidar corretamente, como resposta esperada;
 multi-entrada, menos parâmetros de entrada, a interface pode lidar corretamente e a resposta esperada
(por exemplo, formato de formato json escrito) formato teste de erro de transmissão de dados ; segurança O teste de segurança refere-se principalmente à segurança dos dados transmitidos:
 Se os dados confidenciais (como senhas, chaves secretas), etc. são criptografados para transmissão;
 Se os dados retornados contêm dados confidenciais, como senhas de usuário, informações completas da conta bancária do usuário, etc .;
 Se a interface está correta Os dados de entrada são verificados quanto à segurança, como ID de identidade mais verificação semelhante de token;
 Se a interface evita solicitações maliciosas (como um grande número de solicitações falsificadas que fazem o servidor travar); Teste de desempenho, como tempo de resposta da interface, recursos de processamento simultâneo, teste de estresse Situação de manuseio:
 Solicitações simultâneas para a mesma interface (especialmente solicitações POST), manuseio da interface (como inserir o mesmo registro, causando erros de dados e falhas do sistema); Code Testing Institute
 O tempo de resposta da interface está dentro da tolerância do usuário  Realizar teste de estresse na interface com uma grande quantidade de solicitações para determinar se o maior ponto de gargalo atende às necessidades atuais do negócio;

13. Quais ferramentas são comumente usadas para testar interfaces?

Resposta: Ferramentas de teste de interface de protocolo http comumente usadas, como: postman, fiddler, jmeter; a interface webService usa SoapUI, jmeter, etc.

14. Se não houver documento de interface, como fazer o teste de interface?

Esta pergunta testa principalmente a inteligência emocional, que é a capacidade de enganar o entrevistador em geral. Também é um teste cego quando você entra. Esteja pronto para voltar a qualquer momento. Claro, você não deve responder à
resposta inesperada do entrevistador : use a ferramenta de captura de pacotes Pegue a interface e, em seguida, conduza o teste direcionado; se as informações de campo na interface não estiverem claras, encontre um tempo para se
concentrar na busca de soluções de desenvolvimento. (Ferramentas de captura comumente usadas Fiddler, Charles, etc.)

15. No processo de teste manual de interface ou teste automatizado de interface, como lidar com as dependências de dados nas interfaces upstream e downstream?

Resposta: Use uma variável global para processar dados dependentes, como retornar um token após o login. Outras interfaces precisam desse token e, em seguida, usam variáveis ​​globais para passar os parâmetros do token.

16. Como testar interfaces que dependem de dados de terceiros?

Resposta: Simulação O entrevistador perguntará se é uma simulação e você continuará a cavar ao longo do poço e a construir um serviço simulado. Consulte http://www.51ste.com/share/det-485.html

17. No teste de interface, como testar a interface que depende do status do login?

Resposta: A natureza da interface que depende do status de login é que você precisa trazer uma sessão ou cookie sempre que enviar uma solicitação para enviá-la com sucesso. Adicione a sessão ou o cookie necessário ao construir uma solicitação POST

18. Como simular uma rede fraca para teste

? Resposta: Fiddler e Charles podem simular um teste de rede fraco.A simulação usual de perda de pacotes também é uma simulação de um teste de rede fraco. Com
o corpo pode ser visto "vários métodos de simulação de rede fraca, há sempre um certo para você."

19. Que bugs você encontrou no processo de teste de interface?

O entrevistador fez esta pergunta principalmente para saber se você realmente fez o teste de interface. Afinal, muitos currículos de pequenos parceiros estão empacotados (sem embalagem, não há oportunidade de entrevista, não há como, para sobreviver, entender)
R:
Erros gerais , A interface não está implementada, o resultado não é retornado conforme o combinado, o erro de processamento do valor limite, etc. Valores anormais de entrada (valores nulos, caracteres especiais, excedendo o comprimento acordado, etc.), a interface gera erros e nenhum encapsulamento é executado; parâmetros incorretos de entrada, mais entrada, menos parâmetros de entrada,
possíveis erros na interface; problemas de segurança, como transmissão de texto simples , O resultado retornado contém informações confidenciais, nenhuma verificação de informações de identidade do usuário, nenhuma interceptação de solicitação mal-intencionada, etc.;
Problemas de desempenho, como inserção simultânea de várias operações idênticas na interface, tempo de resposta muito longo e gargalos no teste de pressão da interface;

20. Quando uma interface é anormal, como você analisa a anormalidade?

Resposta: primeiro capture o pacote, use a ferramenta fiddler (charles) para capturar o pacote ou a ferramenta de depuração F12 no navegador; se estiver no APP, use o Fiddler como proxy, defina o proxy por meio do telefone celular para visualizar a solicitação e retornar mensagens; visualize o log de back-end , Por exemplo, se o sistema Linux se conecta ao servidor por meio do xhell, verifique o log da interface para ver se há alguma mensagem de erro (comando: tail -f log file);

21. Como analisar se um bug é front-end ou back-end?

Resposta: Quando geralmente mencionamos bugs, o desenvolvimento front-end e o desenvolvimento back-end estão sempre discutindo, não admitindo que seja o bug do outro. Essa situação é fácil de julgar. Primeiro, pegue o pacote e observe a mensagem de solicitação e verifique o documento de interface para ver se há algum problema com a mensagem de solicitação. Se houver um problema, os dados enviados pelo front-end estão incorretos; a mensagem de solicitação está ok e, em seguida, observe a mensagem de retorno. Os dados retornados estão errados, esse é o problema do desenvolvimento de back-end.

22. Você automatiza o teste de interface?

Resposta: Para um grande número de aplicativos, geralmente é recomendado automatizar o teste de interface, que tem baixos custos de manutenção e altos retornos. Existem muitas ferramentas comumente usadas, como Jmeter, Robot Framework, pytest, etc.

23. Quantos ouvintes JMeter estão listados?

Alguns ouvintes JMeter são: Relatório de resumo do relatório de coleção Exibir árvore de resultados Exibir resultados em tabelas Resultados do gráfico Relatórios de resumo do Listener BeanShell etc.

24. Teste baseado em dados em python

Em unittest, não há driver de dados embutido, temos que usar ddt para alcançá-lo. Primeiro, temos que instalar o ddt no ambiente de tempo de execução python e usar o seguinte comando para instalar pip install ddt. Outra estrutura de teste, pytest, tem sua própria implementação orientada a dados. É parametrizado por @ pytest.mark.parametrize (argnames, argvalues). Você também pode usar o python para ler e conduzir dados de acordo com suas necessidades.

25. Como lidar com a associação na automação de interface?

Passe o resultado retornado pela solicitação anterior para os parâmetros da próxima solicitação, reflita o resultado da solicitação para um atributo de classe (usando a função setattr ()) e chame este atributo de classe na próxima solicitação

26. Como verificar os resultados dos testes automatizados?

Assert, o resultado esperado é comparado com o resultado real
e os dados no banco de dados são verificados de acordo com o cenário de teste e os dados antes da solicitação são comparados.

27. Qual é a estrutura de teste usada para automação?

Descreva resumidamente o design e a manutenção da estrutura de automação. A
estrutura de teste: python + unittest + solicitações + ddt + openpyxl + pymysql + logging
python: entrada simples, sintaxe simples
unittest: defina uma classe de caso de teste e métodos específicos para manter o ciclo de vida dos casos de teste, Comportamento do cenário de teste, pré-cenário do caso de teste, comportamento, resultado esperado, resultado real, método de asserção,
solicitações de método de desmontagem de configuração : chamada de interface, biblioteca de suporte a solicitação de http, API concisa, fornecendo diferentes métodos de solicitação de http, sessão de suporte, cookies,
ddt: orientado a dados, decorador de classe ddt, decorador de método de teste de dados desempacotar tipos de dados iteráveis,
usuários comuns, bancos de dados,
arquivos de configuração - (dados básicos) openpyxl: gerenciamento de dados dados de gerenciamento do Excel, use o módulo openpyxl para executar dados do Excel
Leitura e gravação (excle, csv, json, yaml, txt pode gerenciar dados de teste) pymysql: interação de banco de dados, verificação de dados
eval, json: conversão de formato de dados Eval converte o formato suportado por python no formato correspondente
logging: log Processamento, formato de saída de log unificado, canal, nível, registro de resultados de execução, fácil localizar o problema
jenkins: integração contínua
2 / ideias de design de estrutura: orientado a dados + camadas estruturais (legibilidade, manutenção, escalabilidade)
orientado a dados : Separe os dados de manutenção do código, comportamento de chamada de interface consistente, conduza diferentes cenários de teste para diferentes combinações de parâmetros e reduza a redundância de código
Camada de estrutura: camada de dados + camada de caso de uso + camada lógica Camada de
dados: dados de suporte de dados de teste.xls
Camada de caso de uso: execução de caso de uso test_register.py test_recharge.py
camada lógica: encapsulamento e extração de método público doexcle.py do_mysql.py http_requests.py logger.py e outros módulos
3 / etapas de design de estrutura:
preparar dados de teste: tabela EXCEL prepara para teste Caso de uso - leitura de dados do Excel -
solicitação iniciada pelo instituto de teste de código de substituição de valor de parâmetro : método de solicitação (método get / post para encapsulamento - splicing de URL (diferente - parâmetros são convertidos em dicionário
para obter o valor de retorno da solicitação: análise do código de valor de retorno, Status, benefícios de
asserção de informações de mensagem
:
1. A combinação perfeita de casos de teste automatizados e casos de teste manuais, reduzindo o trabalho repetitivo
2. Configuração flexível, você pode alternar ambientes de teste e executar casos de teste independentemente
3. Funções comuns são encapsuladas, a lógica é clara e fácil de manter
4 , Entrada de execução unificada, gerenciamento de conjunto de casos de teste: O
módulo run.py seleciona os casos de teste que precisam ser executados por meio de pesquisa difusa
5. Integração contínua, construção regular, feedback rápido

28. Especificamente, como aplicar a automação ao real neste projeto e sua análise dos resultados da automação

Depois de concluir o design e a implementação de todas as estruturas de teste automatizadas, execute o teste de interface e, em seguida, integre-o ao
jenkins, configure a execução do tempo, gere relatórios html, visualize as taxas de aprovação do teste e visualize as funções de interface
. O teste de regressão é realizado toda vez que a versão é lançada Antes do desenvolvimento e teste

Acho que você gosta

Origin blog.51cto.com/11959825/2597098
Recomendado
Clasificación