Teste de Software Não Destrutivo (NDT): O que é, Estratégia de Teste
Thomas Hamilton
⚡ Resumo Inteligente
Os testes não destrutivos verificam se uma aplicação se comporta corretamente ao receber entradas válidas, razão pela qual os testadores também os chamam de testes de caminho positivo ou de caminho feliz. Eles confirmam os resultados esperados em relação aos requisitos documentados.
O que são testes de software não destrutivos?
Teste não destrutivo é um tipo de teste de software que envolve testar e interagir corretamente com o aplicativo de software. Em outras palavras, o Teste Não Destrutivo de Software (NDT) também pode ser chamado de Teste Positivo ou Teste do Caminho Feliz. Fornece os resultados esperados e prova que o aplicativo de software está se comportando conforme o esperado.
O nome foi emprestado da engenharia, onde os testes não destrutivos inspecionam um componente físico sem danificá-lo. Em software, a ideia é a mesma: o aplicativo é executado da maneira como foi projetado para ser usado e permanece intacto após o teste.
Exemplo: Inserir os dados corretos em um módulo de login e verificar se as credenciais são aceitas e se a navegação para a próxima página é bem-sucedida.
A captura de tela abaixo mostra o formulário de login, com um valor válido digitado no campo de nome de usuário antes da execução do teste.
Para realizar testes não destrutivos no exemplo acima, insira um nome de usuário e senha válidos no formulário de login. Como a entrada corresponde ao que o requisito permite, o resultado desejado é positivo e o testador simplesmente confirma que o aplicativo avança para a próxima página.
Por que fazer testes não destrutivos de software (NDT)?
Os testes não destrutivos respondem à primeira pergunta que todos os stakeholders fazem sobre uma versão: o recurso realmente faz o que foi solicitado? Esses são os motivos pelos quais as equipes os executam.
- A principal vantagem do método NDT é a melhoria na qualidade do software, pois os defeitos encontrados no fluxo principal são corrigidos precocemente.
- Demonstrar que as funções do software estão funcionando de acordo com a especificação.
- Para verificar se os requisitos de desempenho foram atendidos.
- Verificar se os requisitos dos usuários finais foram atendidos.
- Para verificar se uma pequena seção de código ou funcionalidade está funcionando conforme o esperado e não está quebrando a funcionalidade relacionada.
- Para produzir provas que possam ser apresentadas em um Testes de aceitação do usuário Aprovação final, onde o cliente deseja ver o comportamento esperado em vez dos modos de falha.
Quando os testes não destrutivos (END) são realizados?
O momento certo é mais importante aqui do que na maioria das técnicas, porque o caminho ideal controla tudo o que vem depois.
- É a primeira forma de teste que um testador realiza em uma aplicação, ou seja, no estágio inicial do desenvolvimento. SDLC.
- Os ensaios não destrutivos são geralmente realizados quando não há tempo suficiente para um ciclo de testes completo, pois ainda assim comprovam que os critérios de aceitação foram atendidos.
- Ele é executado antes de cenários negativos e destrutivos. Se o fluxo principal for interrompido, os testes de tratamento de erros reportam ruído em vez de defeitos reais.
- É repetido após cada correção de defeito, e é aí que ocorre a sobreposição com teste de regressão.
Estratégia de Teste para Testes Não Destrutivos
A estratégia para testes não destrutivos é propositalmente simples, e a disciplina reside em manter uma atitude positiva, em vez de se concentrar em ferramentas.
- A abordagem aos testes não destrutivos deve ser positiva.
- O objetivo da técnica de END (Ensaios Não Destrutivos) é comprovar que uma aplicação funcionará quando receber dados de entrada válidos.
- Não há requisitos ou ambiente especiais necessários para realizar testes não destrutivos.
- A melhor prática para testes não destrutivos é verificar se o sistema faz o que deveria fazer.
O diagrama abaixo resume como essa estratégia é normalmente organizada ao longo de um ciclo de testes.
Como escrever casos de teste não destrutivos (positivos)
Um caso de teste não destrutivo só é útil quando sua entrada é comprovadamente válida e o resultado esperado decorre de um requisito, e não de uma suposição do testador. Os passos a seguir produzem esse tipo de resultado. caso de teste.
Passo 1) Escolha um critério de aceitação. Leia o requisito e reformule-o como uma única declaração verificável, por exemplo: "o campo de nome de usuário aceita de seis a vinte caracteres alfanuméricos".
Etapa 2) Selecione dados de entrada válidos. Selecione valores que estejam confortavelmente dentro do intervalo permitido. Particionamento equivalente Isso ajuda aqui — um valor representativo por partição válida normalmente é suficiente.
Passo 3) Escreva o resultado esperado antes de executar. O resultado esperado deve ser escrito a partir da especificação. Escrevê-lo após a execução transforma o teste em uma descrição do que quer que a compilação tenha feito.
Passo 4) Mantenha os passos na ordem do usuário. A sequência deve corresponder à forma como um usuário real completaria a tarefa, pois o objetivo da técnica é confirmar o percurso pretendido.
Etapa 5) Registre o identificador do requisito. TracO que permite à equipe comprovar a cobertura durante uma revisão é justamente o fato de o caso estar de acordo com seus critérios.
Um exemplo prático do módulo de login se parece com isto.
| Campo | Caso de teste não destrutivo |
|---|---|
| Exigência | O nome de usuário aceita de 6 a 20 caracteres alfanuméricos. |
| Dados de teste | Nome de Utilizador guru99tester, senha válida correspondente |
| Passos | Abra a página de login, insira as credenciais e selecione "Entrar". |
| Resultado esperado | As credenciais foram aceitas e a página inicial foi exibida. |
| Formato | Caminho positivo/feliz |
Observe que nada no caso tenta quebrar o campo. Um caso que insere cinco caracteres para ver a mensagem de erro é um teste negativo, não uma não destrutiva.
Exemplos de testes não destrutivos
O exemplo abaixo mostra como o teste não destrutivo se comporta em uma aplicação com múltiplos módulos após a correção de um defeito.
- Um aplicativo possui cinco módulos: página de login, página inicial, página de detalhes do usuário, criação de novo usuário e criação de tarefas.
- Suponha que haja um erro na página de login: o campo de nome de usuário aceita menos de seis caracteres alfanuméricos. Isso contraria o requisito estabelecido, que determina que o nome de usuário não deve aceitar menos de seis caracteres, portanto, esse comportamento é uma falha.
- O bug foi reportado à equipe de desenvolvimento pelos canais habituais. processo de gerenciamento de defeitosO problema foi corrigido e a versão foi enviada de volta para a equipe de testes.
- A equipe de testes não apenas verifica a página de login onde o defeito foi corrigido, mas também testa os outros módulos. Ao testar todos os módulos com dados válidos, realiza testes não destrutivos, simplesmente para confirmar que toda a aplicação ainda funciona corretamente.
Ensaios não destrutivos versus ensaios destrutivos
As duas técnicas são frequentemente ensinadas juntas porque respondem a perguntas opostas sobre a mesma construção. Teste destrutivo O teste de detecção de falhas busca identificar o ponto em que o software falha, enquanto os testes não destrutivos confirmam se o comportamento esperado se mantém.
| Aspecto | Teste não destrutivo | Teste destrutivo |
|---|---|---|
| Intenção | Interaja corretamente com o aplicativo e verifique os resultados positivos. | Forneça entradas incomuns ou inválidas para encontrar o ponto de falha. |
| Dados de entrada | Dados válidos extraídos do requisito | Dados inválidos, corrompidos ou fora de sequência |
| Requisitos necessários | Sim — os casos são escritos com base em critérios de aceitação. | Não necessariamente; os testadores trabalham sem o viés da história do usuário. |
| O que isso expõe | Deficiências de funcionalidade em relação à especificação | Pontos fracos no projeto, robustez e capacidade de recuperação. |
| Técnicas relacionadas | Teste de fumaça, teste funcional | Teste com macacos, testes exploratórios |
Os dois são complementares, não alternativos. Executar apenas testes não destrutivos deixa o tratamento de erros sem verificação, e executar apenas testes destrutivos nunca comprova que o produto cumpre sua função.
Vantagens e limitações dos testes de software não destrutivos
Saber onde a técnica deixa de ser útil é tão importante quanto saber o que ela abrange.
Vantagens
- Rápido de projetar e executar, porque os dados de teste vêm diretamente da especificação.
- Não requer ambiente especial, injeção de falhas ou conjunto de dados corrompido.
- Produz evidências que correspondem diretamente aos requisitos, o que é adequado para auditorias e aprovações.
- Funciona igualmente bem como teste manual e conforme o roteiro teste de automaçãoAssim, os mesmos casos podem ser reutilizados em um conjunto de testes de regressão.
- Fornece um sinal precoce e honesto sobre a saúde da construção em qualquer nível, da unidade ao topo. teste de integração para teste do sistema.
Limitações
- Uma aprovação completa não diz nada sobre como o aplicativo se comporta com entradas inválidas, portanto, defeitos graves no tratamento de erros podem passar despercebidos.
- A abrangência é limitada pela qualidade dos requisitos. Qualquer item não especificado nunca é testado.
- Isso pode gerar uma falsa sensação de segurança quando o caminho ideal é o único caminho percorrido antes de um lançamento.
- Não mede robustez, recuperação ou desempenho sob estresse, que exigem técnicas próprias provenientes de um conjunto mais amplo de ferramentas. tipos de teste de software.
Considere os testes não destrutivos como a base sobre a qual todas as outras técnicas se fundamentam e inclua-os em seu planejamento mais amplo. ciclo de vida de teste de software em vez de uma atividade isolada.
