1. Teste de interface
Teste de interface, ou seja, teste da API.
Problemas típicos que podem ocorrer no processo de teste de interface:
(1) O manuseio inadequado dos parâmetros de entrada faz com que o programa falhe
(2) Estouro de tipo, resultando em leitura e gravação de dados inconsistentes
(3) Como as permissões do objeto não foram verificadas, é possível acessar informações confidenciais de outros usuários
(4) A manipulação de estado imprópria leva à confusão lógica
(5) A verificação lógica não é perfeita e brechas podem ser exploradas para obter direitos e interesses ilegais e legítimos
2. Projeto de caso de teste de interface
No processo de teste de interface, geralmente é necessário escrever primeiro os casos de teste para garantir a abrangência e precisão do teste.
A qualidade de um caso de uso determina a precisão e cobertura de sua interface de teste.
O design de casos de uso para teste de interface é considerado principalmente a partir de dois aspectos de entrada e saída de interface:
1. Para o projeto de entrada, a entrada é o parâmetro. Os tipos de parâmetros comuns são:
Tipo numérico (int, long, float, double)
· Tipo de string
· Arrays e listas encadeadas
· Estrutura (struct é uma combinação de alguns elementos, e os elementos são realmente numéricos, string, array ou lista ligada, três tipos de parâmetros, design de caso de uso)
Suplemento: Para o projeto de entrada, também é necessário cobrir os parâmetros obrigatórios e os parâmetros opcionais.
numérico
Se o parâmetro especifica o intervalo de valores, você precisa considerar o intervalo de valores da classe de equivalência, fora do intervalo de valores e o limite do valor.Se necessário, cada valor dentro do intervalo de valores pode ser percorrido.
Por exemplo: a interface para verificação de permissões: o intervalo de valores de TaskID é de 1 a 35, portanto, o design precisa considerar:
· Valores dentro e fora do intervalo 1-35;
1-35 limites: 0,1,35,36;
valores especiais do tipo: -1,0;
O valor limite do tipo de dados: os valores mínimo e máximo de int;
· Os IDs de permissão dos códigos 1-35 são diferentes e cada valor de 1-35 pode precisar ser percorrido.
Problemas e riscos comuns:
1) O manuseio inadequado de valores especiais faz com que o programa saia de forma anormal;
2) Digite estouro de limite;
3) O valor fora da faixa de valores não retorna a mensagem de erro correta.
Tipo de string:
· Parâmetros de string, considerando principalmente o comprimento e o conteúdo da string;
· Por exemplo: conversão de interface para definir a string de interface ddhh do despertador, o caso de uso precisa ser considerado:
· Comprimento: comprimento é de 4 dígitos, menos de 4 dígitos, mais de 4 dígitos
Valor limite: o comprimento máximo da string
Valor especial: caractere nulo
O tipo de conteúdo string pode ser considerado: números, não números;
· Caracteres especiais;
· Se o usuário inserir um conteúdo visível para outros usuários, é necessário considerar se as palavras sensíveis são normalmente filtradas.
Problemas e riscos comuns:
1) Passe em um tipo não específico e o programa sai de forma anormal.
2) Os caracteres extralongos não são processados, resultando em anormalidades como armazenamento e exibição.
3) Palavras sensíveis definidas visíveis para outros usuários.
tipo array ou lista encadeada
Quando o tipo de parâmetro é uma matriz ou uma lista encadeada, os casos de uso podem ser considerados:
Por exemplo: a interface submitTask(int[] taskID) para enviar tarefas em lotes, considerações de design de caso de uso de parâmetro:
· Valor normal: 1-5 permissões, fora do intervalo: 6 permissões;
· Valor limite: o valor limite de 1-35, os valores máximo e mínimo permitidos para a solicitação;
Valor especial: 0;
· id legal e ilegal;
· ID duplicado, etc.
Problemas e riscos comuns:
1) 0 itens significa que o programa foi encerrado de forma anormal.
2) Itens duplicados não são desduplicados durante o processamento, resultando em exceções de dados.
2. Para projeto lógico
A interface requer algum processamento lógico. De acordo com o design lógico do caso de uso, ela pode ser analisada sob os seguintes ângulos:
· Análise de condição de restrição
· Análise de restrições de relacionamento
· Análise de restrição de permissão
· Análise de objeto de operação
· Análise de transição de estado
· Análise de séries temporais
Análise de restrição:
Restrições numéricas: restrições de pontuação, restrições de moedas de ouro, restrições de nível, etc.
Por exemplo: A troca de moeda Q requer pontos > 50 para participar.
Restrições de status: status de login, etc.
Por exemplo: para sincronizar as informações do usuário, primeiro você precisa fazer login na conta.
Restrições de relacionamento:
Relacionamento vinculativo, relacionamento de amizade, etc.
Por exemplo: a função de ajudar os familiares a prevenir fraudes pode apenas consultar as informações de chamadas recebidas de familiares vinculados.
Restrições de permissão:
administrador etc
O teste de restrição é frequentemente encontrado em testes funcionais e é mais importante em testes de interface. Seu significado é: quando o usuário realiza uma operação, o front-end da operação pode ter sido restringido por restrições, de modo que o usuário acionou diretamente a solicitação da interface.
Mas, de fato, se houver outros meios, como bugs de interface do usuário ou chamadas diretas para meios por meios técnicos, é particularmente importante se a interface é restrita para essas condições.
Por exemplo: são necessários 200 pontos para trocar moedas 5Q, mas meus pontos são insuficientes, então o botão de troca é cinza e não pode ser clicado.
Os usuários normais não podem operá-lo, mas a troca é na verdade uma interface para ajustar o plano de fundo. E se a restrição do botão de página for ignorada e a interface de plano de fundo for chamada diretamente para a troca? Pode ser trocado? Claro que as expectativas não podem ser resgatadas, então o limite numérico de pontos precisa ser testado na interface, e isso é muito importante.
Outras restrições são semelhantes:
Restrição de horário: antes das 22:00;
Restrições numéricas: 200 pontos, limitado a 5;
Restrições de status: restrições semelhantes, como fazer login no Mobile Manager.
Problemas e riscos comuns:
Restrições insuficientes permitem que os usuários obtenham benefícios por meios especiais.
Análise de objeto de operação:
As operações geralmente são direcionadas a objetos. Por exemplo, quando um usuário vincula um número de telefone, o número de telefone é o objeto da operação e as tarifas de chamada e o tráfego de dados desse número de telefone também são objetos.
A análise de objetos opera principalmente em objetos legais e ilegais. Por exemplo:
· O usuário A pergunta sobre as tarifas de chamada do telefone P1
· O usuário A consulta o tráfego P1 do telefone
· O usuário A pergunta sobre tarifas de chamadas P2
· O usuário A consulta o tráfego P2 do telefone
Processamento lógico em segundo plano, se um telefone foi vinculado, você pode consultar as tarifas de chamada e o tráfego do telefone do ponto de vista de segundo plano, mas do lado do usuário, deve ser o telefone que A vinculou, para que A pode consultar o telefone.Contas de telefone, portanto, o teste de objetos semelhantes também é essencial.
Problemas e riscos comuns:
Os usuários podem acessar outras informações do usuário e informações confidenciais fora de sua autoridade, de modo a usar essas informações para fins lucrativos.
Análise de Transição de Estado
A lógica a ser testada pode ser abstraída em uma máquina de estado, e cada estado é alternado de um estado para outro de acordo com a lógica funcional. Se interrompermos essa ordem e mudarmos de um estado para outro que não esteja em seu próximo estado definido, a lógica será interrompida e surgirão problemas de lógica.
A mudança de um determinado estado para um novo estado depende da interface de transição. Para uma interface de conversão, seu estado de entrada é determinado, como Fun23, esta função só pode converter o estado 2 para o estado 3, mas não pode converter o estado 1 para o estado 3, então o ponto de teste pode ser:
O estado é 2, a interface é chamada e o estado é alterado para 23
· Quando o estado é 1, 3, etc., chame a interface, e o estado não pode ser trocado
Então ele pode ser projetado assim:
Mudança de estado normal: estado não solicitado, após receber a tarefa, torna-se o estado recebido; depois que a tarefa recebida atende às condições da tarefa e é enviada, torna-se o estado concluído; após a conclusão, a tarefa pode ser reivindicada novamente.
Mudança de estado anormal: enviar a tarefa sem receber a tarefa e atender às condições da tarefa; receber a tarefa novamente quando a tarefa for recebida, etc.
Problemas e riscos comuns:
É possível alcançar um estado que não foi possível por meios especiais, de modo a buscar benefícios.
Análise de tempo:
Em algumas atividades complexas, uma atividade é executada por uma série de ações em uma ordem especificada, e essas ações formam um fluxo de ação, e somente nessa ordem os resultados esperados podem ser obtidos.
No processo normal, essas ações são executadas na sequência de acordo com a chamada do programa, e não serão interrompidas.Ao testar a interface, é necessário considerar se haverá problemas caso ela não seja executada na sequência.
Por exemplo: a sincronização de dados do cliente é acionada pelo cliente, durante a qual o usuário da sincronização não pode intervir. Durante o teste funcional, pode-se ver se a sincronização pode ser realizada normalmente, e uma análise mais aprofundada mostra que a realização da sincronização suave envolve um conjunto de ações:
Como pode ser visto no diagrama de sequência, existem três interfaces em segundo plano: faça o login para obter o ID do usuário, reporte ao banco de dados local e relate conflitos locais. As três interfaces precisam ser chamadas e executadas em sequência para completar a sincronização. Em seguida, no teste de interface, você pode considerar interromper a ordem de execução da interface de recurso a ser executada, que tipo de interface haverá e se haverá exceções. Por exemplo: relatar diretamente o conflito local sem relatar os dados locais após obter o ID do usuário.
Problemas e riscos comuns:
1) Após a execução não sequencial, os dados são anormais e outras anormalidades do programa também podem ocorrer.
2) Obtenha benefícios interrompendo a ordem.
3. Design para resultados de saída
Pode haver apenas um resultado correto do processamento da interface, mas há muitos casos e muitos valores para a interface de retorno de erro e exceção. Se você sabe que existem muitos tipos de resultados retornados, pode criar casos de uso para diferentes resultados .
Por exemplo: ao enviar uma tarefa integral, geralmente pensamos em retornar correção e erro. Para erros, podemos pensar em: tarefa inválida, estado de login inválido, mas pode não ser capaz de cobrir completamente todos os códigos de erro e o código de retorno definido pelo retorno da interface pode ser projetado mais casos de uso múltiplo.
Cobrir o código de retorno também é uma ideia de design de caso de uso.
Problemas e riscos comuns:
1) O processamento insuficiente de erros no front-end leva a exceções no front-end.
2) Tratamento inadequado de prompts de erro, fazendo com que os usuários vejam códigos de erro obscuros.
3) O prompt de erro é inadequado, fazendo com que o usuário não saiba onde está o problema e como resolvê-lo.
Condições de tempo limite da interface:
Em circunstâncias normais, a interface tentará retornar. Se a interface não retornar, ou seja, o processamento após o timeout da interface também faz parte do teste que precisa ser considerado. Se o timeout não for tratado adequadamente, pode acarretar os seguintes problemas:
· O processamento por timeout não é realizado, fazendo com que todo o processo seja bloqueado;
· Recebi o retorno da interface após timeout, resultando em confusão lógica.
[A seguir está o diagrama de sistema de arquitetura de conhecimento de aprendizado de engenheiro de teste de software mais completo em 2023 que eu compilei]
1. Da entrada ao domínio da programação Python
2. Combate real do projeto de automação da interface
3. Combate Real do Projeto de Automação Web
4. Combate real do projeto de automação de aplicativos
5. Currículo de fabricantes de primeira linha
6. Testar e desenvolver o sistema DevOps
7. Ferramentas de teste automatizadas comumente usadas
Oito, teste de desempenho do JMeter
9. Resumo (pequena surpresa no final)
a vida é longa, então adicione óleo. Todo esforço não será decepcionado, desde que você persevere, haverá recompensas no final. Valorize seu tempo e persiga seus sonhos. Não se esqueça da intenção original, siga em frente. O seu futuro está nas suas mãos!
A vida é curta, o tempo é precioso, não podemos prever o que acontecerá no futuro, mas podemos compreender o momento presente. Valorize todos os dias e trabalhe duro para se tornar mais forte e melhor. Crença firme, busca persistente, o sucesso acabará por pertencer a você!
Somente desafiando-se constantemente você pode se superar constantemente. Persista em perseguir seus sonhos e siga em frente com bravura, e você descobrirá que o processo de luta é tão bonito e valioso. Acredite em você, você consegue!