Por que o posicionamento é tão importante?
Pode esclarecer se um problema é realmente um “bug”
Muitas vezes, encontramos a causa do problema, apenas para descobrir que não se trata de um bug. Quando a causa é clara, os falsos positivos são reduzidos
Vários sistemas interagem, o que pode apontar claramente qual sistema está com defeito, evitar "chutar a bola" e melhorar a eficiência da resolução de problemas
Aumente a confiança entre desenvolvimento e teste, comunique-se de forma mais eficaz, coopere melhor e melhore a oportunidade de desenvolvimento e modificação de bugs
Uma compreensão mais eficaz da lógica interna do sistema e do fluxo de processamento de dados pode melhorar o nível dos testadores.Depois que o defeito for reparado, a faixa de teste impactada pode ser avaliada com mais precisão e testada novamente com mais precisão.
Pode reduzir a taxa de defeitos
Este é sem dúvida o mais importante. No sistema de bugs, os desenvolvedores são obrigados a registrar a causa do bug. Somente quando tivermos uma compreensão mais abrangente dos bugs, poderemos julgar se o desenvolvimento e a escrita são os reais motivos, e isso também nos ajudará a analisar e classificar bugs no futuro. De acordo com a análise de bugs, podemos planejar com antecedência em um maneira direcionada e, em seguida, melhorar a qualidade do produto e reduzir defeitos
01. Antes de posicionar a causa
Ao encontrar um problema, não se apresse em localizar a causa.
1. Salve os registros gerados por bugs:
A primeira coisa a fazer é salvar os registros gerados pelo bug para garantir que ele possa ser reproduzido.
Por que manter registros? Porque se não puder ser reproduzido no futuro, não poderá provar a existência do bug.
2. Elimine problemas de baixo nível:
Depois, há problemas de baixo nível que excluem o controle de qualidade, problemas comuns de baixo nível:
[anfitriões errados]
O arquivo hosts serve principalmente para acelerar a velocidade de resolução de um determinado nome de domínio ou site, de forma a obter o efeito de acesso rápido, podendo também bloquear o site.
Hosts anormais podem fazer com que algumas páginas da web fiquem inacessíveis e possam ser carregadas, mas a página da web não pode ser exibida normalmente.
[Falha de rede]: captura de pacotes, ping
Causado pelo impacto de ferramentas, como o violinista
E postura operacional incorreta, etc.
3. Exclua problemas de dados (dados sujos):
Às vezes, o servidor relatará um erro 500. Após a verificação do log, um ponteiro nulo será relatado, portanto, é provável que os dados da tabela associada no banco de dados tenham sido excluídos artificialmente.
Dados sujos: os dados recuperados do destino expiraram, estão errados ou sem sentido, esse tipo de dados é chamado de dados sujos
Leitura suja: a leitura suja é chamada de leitura suja
02. A ideia de posicionar o problema
Verifique o pedido:
Nível de ambiente do usuário -> nível de apresentação -> nível de controle lógico -> nível de serviço -> nível de banco de dados
1. Nível do ambiente do usuário
Refere-se principalmente se o ambiente básico pode ser usado. por exemplo:
Se a rede recebeu ping
As configurações de ip e porta estão corretas?
A versão jdk atende ao padrão
Pode ser que o sistema funcione de forma anormal devido à incompatibilidade da versão do jdk.Esse tipo de problema depende da situação real para decidir se é compatível.
O proxy está configurado na rede
Rede fraca (como js/css não totalmente carregado, solicitação expirou)
navegador não suporta
A versão do sistema não suporta
banco de dados é excluído
Dados sujos do ambiente de teste
Chave de configuração do projeto
O ambiente de teste cortou galhos, etc.
Após a conclusão da inspeção, você pode ir para a segunda etapa
2. Camada de exibição do usuário
Alguns problemas encontrados pelos usuários através da visualização e outras operações durante o uso:
Estilos de página (problemas de estilo CSS)
Dicas para js durante a interação (problema de interação js)
Informações imediatas para controle do terminal
Exibição de texto (problema de texto HTML)
3. Camada de controle lógico
No processo de operação do usuário, se a lógica de processamento de negócios é implementada de acordo com o design anterior. Ou há uma exceção no link intermediário, como servidor de cache (como Redis), middleware de mensagem (como RabbitMQ), middleware de acesso a dados, etc.
4. Camada de serviço
A camada de serviço frequentemente verifica a configuração do servidor, por exemplo, pode ser um problema com a configuração do Tomcat, configuração do nginx, configuração do jdbc, etc. É melhor que os testadores entendam suas configurações.
5. Camada de banco de dados
Pode haver diferentes versões de banco de dados entre o ambiente de teste e o ambiente oficial, e diferentes formatos de dados e limites de comprimento para front-ends e back-ends. Após a conclusão da operação do usuário, o processo de transação é muito tranquilo, o que não significa que não haja problemas com toda a transação, e os testadores precisam verificar se as tabelas e campos cadastrados no banco de dados estão corretos
Caso você constate que os campos cadastrados estão inconsistentes com os resultados esperados, você pode consultar o log para verificar se os campos enviados na mensagem de solicitação estão corretos e consistentes com os preenchidos na recepção
Algumas operações irão registrar múltiplas tabelas, portanto é necessário verificar se o cadastro ou atualização de múltiplas tabelas está correto, e o testador também precisa estar familiarizado com a estrutura da tabela de dados do sistema em teste
6. Regras práticas
Testadores experientes já viram alguns bugs muitas vezes, podem encontrar rapidamente a causa raiz, ir direto ao tópico, relatar ou resolver o bug rapidamente
7. Outros
Bugs comuns também podem ter motivos de construção
Por exemplo, o código em si está correto, mas há um problema após mesclar o código no tronco
Por exemplo, quando há um conflito no código, ele é resolvido manualmente
03. Como localizar o problema
1. Estratégias de posicionamento comuns:
As estratégias de posicionamento comumente usadas são divididas em três categorias: classe original (força bruta), classe de retrocesso (retrocesso), classe de exclusão (eliminações de causa)
Método de localização de classe primitiva
O método de posicionamento de classe original é o método mais utilizado e menos eficiente. É utilizado apenas em situações desesperadoras. A ideia principal é "encontrar erros através do computador".
Retrocesso
O retrocesso pode ser usado com sucesso para depurar programas
O método consiste em rastrear manualmente ao longo do fluxo de controlo a partir do local onde ocorre o sintoma do erro,até que a causa raiz do erro seja encontrada.Infelizmente,quando o programa se torna maior,as possíveis rotas de rastreamento aumentam significativamente,de modo que o rastreamento manual é fora de alcance. .
Exclusão
Com base nos princípios da indução e da dedução, adota-se o conceito de “dividir para conquistar”.
Primeiro determine todos os dados relacionados à ocorrência do bug, imagine a causa do bug e use esses dados para prová-lo ou refutá-lo. Ou liste todas as causas possíveis de uma vez e descarte-as uma por uma por meio de testes. Contanto que um determinado resultado de teste mostre que uma determinada hipótese surgiu, refine imediatamente os dados e busque a vitória
2. Veja o código de status
Código de status 4xx: geralmente indica um problema no cliente (é claro, também pode ser um problema de configuração do servidor), como:
Se ocorrer 401, depende se as informações de autenticação corretas são trazidas
Se ocorrer 403, depende se você tem permissão para acessar
404 depende se o URL correspondente realmente existe
Código de status 5xx: geralmente indica que há um problema com o servidor. por exemplo:
Se ocorrer um erro 500, significa que é um erro interno do servidor. Neste momento, é necessário cooperar com o log do servidor para localizar
Se ocorrer um erro 502, o problema pode ser causado pelo servidor travando
Erros 503 podem ser causados por sobrecarga de rede
Se ocorrer um erro 504, pode ser que o tempo de execução do programa seja muito longo, resultando em um tempo limite
3. Verifique o log do servidor
Se ocorrer um problema 5xx ou se você precisar verificar se o SQL executado pela interface de back-end está correto, nosso método de solução de problemas mais comum é verificar o log do servidor, como o log do Tomcat. Os desenvolvedores geralmente digitam informações importantes e mensagens de erro para descobrir onde está o problema. Portanto, os testadores também devem desenvolver o hábito de ler logs.
4. Verifique a configuração
Em muitos casos, os bugs não são problemas de código, mas problemas de configuração do Tomcat, configuração do nginx, configuração do jdbc, etc. Nesse nível, é melhor que os testadores sejam capazes de compreender suas diversas configurações e possam pensar em problemas nessa área depois de descobrirem os problemas.
5. Visualize o documento de requisitos
Às vezes, a interação entre o front-end e o servidor está correta, mas não faz sentido do ponto de vista dos testes. Neste momento, devemos examinar o documento de requisitos. Se não corresponder ao documento de requisitos, então é necessário ver o que é mais razoável mudar, seja mudar o front-end, o servidor ou ambos.
Há um princípio aqui, ou seja, o front-end assume o mínimo de lógica possível e é responsável apenas pela renderização e exibição. Claro, não pense que o documento de requisitos está todo correto, ele também pode conter erros, também devemos encontrar bugs no documento de requisitos e, em seguida, coordenar com o PM para solicitar que FE ou RD façam alterações.
6. Busque suporte de testabilidade do desenvolvimento
Às vezes, alguns testes relacionados ao processo de desenvolvimento também exigem desenvolvimento para fornecer suporte à testabilidade.
Por exemplo, para verificar se a solicitação enviada por uma interface para outra interface está correta, você pode deixar o desenvolvimento imprimir o log completo da solicitação, bem como algumas opções lógicas, modificar o número de itens de dados na página, etc., todos pertencem à categoria de suporte à testabilidade.
04. Ferramentas comuns para localização de bugs
Firefox——firebug、desenvolvedor web、live http - headers、http fox
Plug-in do IE - httpwatch
Ferramenta de terceiros – violinista
Ferramenta de simulação de rede lenta - acelerador do Firefox
05. Como distinguir bugs de front-end/back-end
Por que distinguir bugs de front-end/back-end?
Se for um sistema desenvolvido por várias pessoas, é impossível localizar claramente quem causou o bug e é fácil submetê-lo ao desenvolvedor errado.
Ao mesmo tempo, ao enviar para os desenvolvedores front-end e back-end, todos terão uma mentalidade de dependência, e o bug será chutado pelo desenvolvedor como uma bola, atrasando o tempo de desenvolvimento para resolver o bug.
Além disso, se a equipe for grande ou composta por equipes de projeto de vários locais, isso inevitavelmente aumentará os custos de comunicação. Isso exige que primeiro indiquemos quais bugs são enviados ao enviar bugs em softwares de gerenciamento de projetos como ZenTao ou Jira • Evite chutar a bola um com o outro.
Portanto, o teste deve aprender a distinguir bugs de front-end ou back-end por si só.Após a classificação e processamento de bugs, a eficiência de toda a equipe será melhorada.
Quais são as características dos bugs de front-end e back-end?
1. Use ferramentas de captura de pacotes para análise
Geralmente, existem ferramentas de captura de pacotes (pacotes), como httpwatch, firebug, fiddler e charles.
Httpwatch e firebug são plug-ins de navegador que requerem downloads adicionais
violinista, Charles também precisa baixar o pacote de instalação e instalá-lo separadamente
Existe também uma ferramenta simples e prática de captura de pacotes, que é o depurador F12 do navegador
2. Localizando bugs de front-end
Bugs de front-end geralmente estão relacionados a funções, interfaces e compatibilidade e envolvem jstl, jsp, js, css e html. Existem dois bugs principais:
Relacionado a JS
página
3. Localizando bugs de back-end
O plano de fundo envolve servlet, jms, ejb e muitos frameworks struts, hibernate, spring, ibatis, etc.
Bugs são difíceis de corrigir, mas fáceis de encontrar. O principal é procurar erros no console e, em seguida, localizar o número da linha do erro. Se não houver problema com o arquivo de configuração, o erro geral é um ponteiro nulo ou o subscrito da matriz está fora dos limites. Observar as variáveis próximas e os parâmetros do método pode basicamente localizar o erro.
06. Após localizar o problema
Depois de encontrar o problema ou localizar a causa do problema, deve-se prosseguir, o que significa confirmar o problema novamente. O chamado problema de confirmação é descobrir se o problema ocorre sempre, é um evento probabilístico ou um problema relacionado à ferramenta:
Por exemplo, o navegador ainda aparece? Se outro navegador não aparecer, é provável que seja um problema de compatibilidade de front-end.
Por exemplo, o controle de virada de página, muitas páginas do sistema a ser testado possuem controles de virada de página, por isso é necessário verificar se esse problema ocorre em todas as páginas, e então fornecer uma explicação unificada ao relatar bugs, o que também é mais conveniente para os desenvolvedores processarem em lotes e evitarem vazamentos.
Por fim, gostaria de agradecer a todos que leram meu artigo com atenção. A reciprocidade é sempre necessária. Embora não seja algo muito valioso, você pode retirá-lo se precisar:
Applet de entrevista de teste de software
O banco de perguntas de teste de software esgotado por milhões de pessoas! ! ! Quem é quem sabe! ! ! O mini programa de quiz mais completo de toda rede, você pode usar seu celular para fazer os quizes, no metrô ou no ônibus, enrola!
As seguintes seções de perguntas da entrevista são abordadas:
1. Teoria básica de teste de software, 2. web, aplicativo, teste de função de interface, 3. rede, 4. banco de dados, 5. linux
6. web, aplicativo, automação de interface, 7. testes de desempenho, 8. noções básicas de programação, 9. perguntas da entrevista de hora, 10. perguntas de teste abertas, 11. testes de segurança, 12. noções básicas de informática
Esses materiais devem ser o armazém de preparação mais abrangente e completo para amigos [de teste de software]. Este armazém também acompanhou dezenas de milhares de engenheiros de teste na jornada mais difícil. Espero que possa ajudar você também!