Tipos de teste de software
Teste de unidade
O teste de unidade está testando em uma função, classe ou módulo individual de forma independente do que testar um software totalmente funcionando. Usando uma estrutura para testes de unidade, o programador pode criar casos de teste com entrada e saída esperada. Ao ter centenas, milhares ou dezenas de milhares de casos de teste de unidade para um grande projeto de software garante que todas as unidades individuais funcionem conforme o esperado, enquanto você continua a alterar o código. Ao alterar uma unidade que possui casos de teste, os casos de teste para esse módulo devem ser estudados e determinar se são necessários novos casos de teste, a saída foi alterada ou os casos de teste atuais podem ser removidos como não mais relevantes. Criar um grande volume de testes de unidade é a maneira mais fácil de obter uma alta cobertura de casos de teste para uma base de código de software, mas não garantirá que o produto final esteja funcionando como um sistema conforme esperado.
Teste funcional
O teste funcional é a forma mais comum de teste. Quando as pessoas se referem a testes de software sem muitos detalhes, geralmente significam testes funcionais. Os testes funcionais verificarão as principais funções do trabalho de software conforme o esperado. Um plano de teste pode ser escrito para descrever todos os casos de teste funcionais que serão testados, o que corresponde aos principais recursos e recursos do software. Os testes de funcionalidade primária serão “Caminho feliz ” Teste, que não tenta quebrar o software ou usá -lo em nenhum cenário desafiador. Este deve ser o mínimo absoluto de teste para qualquer projeto de software.
Teste de integração
Após o teste de unidade e o teste funcional, pode haver vários módulos ou todo o sistema que ainda não foi testado como um todo. Ou pode haver componentes que são amplamente independentes, mas ocasionalmente usados juntos. Sempre que os componentes ou módulos de tempo são testados de forma independente, mas não como um sistema inteiro, o teste de integração deve ser realizado para validar os componentes funcionando juntos como um sistema de trabalho de acordo com os requisitos e expectativas do usuário.
Teste de estresse
Pense em testes de estresse como se estivesse testando um ônibus espacial ou avião. O que significa colocar seu software ou sistema em "estresse"? O estresse nada mais é do que uma carga intensa de um tipo específico que provavelmente quebrará seu sistema. Isso pode ser semelhante ao "teste de carga" no sentido de colocar seu sistema em alta simultaneidade, com muitos usuários acessando o sistema. Mas enfatizar um sistema pode acontecer em outros vetores também. Por exemplo, a execução do firmware em um componente de hardware quando o hardware tem deterioração física e está operando em modo degradado. O estresse é exclusivo para todos os tipos de software, e os sistemas e a criação de testes de estresse devem estar sob a consideração do que as causas naturais ou não naturais têm maior probabilidade de enfatizar seu software ou sistema.
Teste de carga
O teste de carga é um tipo específico de teste de estresse, como discutido acima, pelo qual um grande número de conexões e acessos de usuário simultâneos são automatizados para gerar a simulação do efeito de um grande número de usuários autênticos que acessam seu sistema de software ao mesmo tempo. O objetivo é descobrir quantos usuários podem acessar seu sistema ao mesmo tempo sem que seu sistema de software quebre. Se o seu sistema puder lidar facilmente com o tráfego normal de 10.000 usuários, o que acontecerá se o seu site ou software se tornar viral e obtiver 1 milhão de usuários? Isso será inesperado "CARREGAR" Quebre seu site ou sistema? O teste de carga simulará isso, para que você se sinta confortável com o aumento futuro dos usuários porque sabe que seu sistema pode lidar com o aumento da carga.
Teste de performance
As pessoas podem ficar totalmente frustradas e desesperadas quando o software não está atendendo a seus requisitos de desempenho. O desempenho, geralmente, significa a rapidez com que as funções importantes podem ser concluídas. Quanto mais complexa e dinâmica as funções estão disponíveis em um sistema, mais importante e não óbvio se torna para testar seu desempenho, vamos dar um exemplo básico, Windows ou Linux Operating System. Um sistema operacional é um produto de software altamente complexo, e fazer testes de desempenho em seu sistema pode envolver a velocidade e o momento das funções como a inicialização, a instalação de um aplicativo, a pesquisa de um arquivo, executando cálculos em uma GPU e/ou qualquer outro de os milhões de ações que podem ser executadas. Deve -se tomar cuidado ao selecionar os casos de teste de desempenho, para garantir que os recursos importantes e propensos a funcionarem com falta de desempenho testados.
Teste de escalabilidade
Testar no seu laptop é bom, mas não é muito bom o suficiente quando você está construindo uma rede social, um sistema de e -mail ou software de supercomputador. Quando seu software deve ser implantado em 1000 servidores, todos funcionando em uníssono, os testes que você faz localmente em um sistema não descobrirá os bugs que ocorrem quando o software é implantado "em escala" em centenas de milhares de instâncias. Na realidade, seus testes provavelmente nunca serão capazes de executar em grande escala antes de serem lançados para a produção, porque seria muito caro e não é prático para construir um sistema de teste com 1000 servidores que custam milhões de dólares. Portanto, o teste de escalabilidade é feito em vários servidores, mas geralmente não o número completo de servidores de produção para tentar descobrir alguns dos defeitos que podem ser encontrados, pois seus sistemas são usados em infraestrutura maior.
Teste de análise estática
Análise estática está testando que é feito inspecionando o código do software sem realmente executá -lo. Para fazer uma análise estática, geralmente, você usaria uma ferramenta, há muitas, uma ferramenta famosa é a cobertura. A análise estática é fácil de executar antes de liberar seu software e pode encontrar muitos problemas de qualidade em seu código que podem ser corrigidos antes de liberar. Erros de memória, erros de manuseio de tipo de dados, desreferências de ponteiro nulo, variáveis não inicializadas e muitos outros defeitos podem ser encontrados. Idiomas como C e C ++ se beneficiam muito da análise estática, porque os idiomas oferecem grande liberdade aos programadores em troca de grande poder, mas isso também pode criar ótimos bugs e erros que podem ser encontrados usando testes de análise estática.
Teste de injeção de falha
Algumas condições de erro são muito difíceis de simular ou acionar, portanto, o software pode ser projetado para injetar artificialmente um problema ou falha no sistema sem o defeito naturalmente. O objetivo do teste de injeção de falha é ver como o software lida com essas falhas inesperadas. Isso responde graciosamente à situação, trava ou produz resultados problemáticos inesperados e imprevisíveis? Por exemplo, digamos que temos um sistema bancário, e há um módulo para transferir fundos internamente da conta A para a conta B. No entanto, esta operação de transferência é chamada apenas depois que o sistema já verificou que essas contas existiam antes de ligar para a operação de transferência. Embora assummos que ambas as contas existem, a operação de transferência tem um caso de falha em que um alvo ou conta de origem não existe e que pode causar um erro. Como em circunstâncias normais nunca recebemos esse erro devido ao pré-teste de entradas, para verificar o comportamento do sistema quando a transferência falhar devido a uma conta inexistente, injetaremos um erro falso no sistema que retorna uma conta inexistente Para uma transferência e teste como o restante do sistema responde nesse caso. É muito importante que o código de injeção de falha esteja disponível apenas em cenários de teste e não seja lançado na produção, onde poderia criar estragos.
Teste de excesso de memória
Ao usar idiomas como C ou C ++, o programador tem uma grande responsabilidade de abordar diretamente a memória, e isso pode causar erros fatais no software se os erros forem cometidos. Por exemplo, se um ponteiro for nulo e desreferenciado, o software falhará. Se a memória for alocada a um objeto e então uma string for copiada sobre o espaço da memória do objeto, referenciar o objeto pode causar um acidente ou mesmo comportamento errado não especificado. Portanto, é fundamental usar uma ferramenta para tentar capturar erros de acesso à memória em software que usa linguagens como C ou C ++, que podem ter esses problemas em potencial. As ferramentas que podem fazer esse tipo de teste incluem ferramentas de código aberto ou ferramentas proprietárias como PurifyPlus. Essas ferramentas podem salvar o dia em que não está claro por que o software está travando ou se comportando mal e apontar diretamente para o local no código que tem o bug. Incrível, certo?
Teste de casos de limite
É fácil cometer erros na codificação quando você está no que é chamado de limite. Por exemplo, uma máquina de caixa automatizada do banco diz que você pode retirar um máximo de US $ 300. Então, imagine que o codificador escreveu o seguinte código naturalmente ao criar esse requisito:
If (amt < 300)
StartWithDrawl ()
outro
erro ("Você pode retirar %s", AMT);
Você pode identificar o erro? O usuário que tenta retirar US $ 300 receberá um erro porque não é inferior a US $ 300. Isso é um bug. Portanto, o teste de limite é feito naturalmente. Limites de requisitos Certifique -se de que, em ambos os lados do limite e do limite, o software está funcionando corretamente.
Teste de fuzz
A geração de entrada de alta velocidade para o software pode produzir o maior número possível de combinações de entrada, mesmo que essas combinações de entrada sejam bobagens totais e nunca seriam fornecidas por um usuário real. Esse tipo de teste de fuzz pode encontrar bugs e vulnerabilidades de segurança não encontradas por outros meios devido ao alto volume de entradas e cenários testados rapidamente sem geração de casos de teste manual.
Teste exploratório
Feche os olhos e visualize o que significa a palavra "explorar". Você está observando e investigando um sistema para descobrir como ele realmente funciona. Imagine que você recebe uma nova cadeira de mesa em ordem de correspondência e possui 28 partes em sacos plásticos separados sem instruções. Você deve explorar sua nova chegada para descobrir como funciona e como é montado. Com este espírito, você pode se tornar um testador exploratório. Você não terá um plano de teste bem definido de casos de teste. Você explorará e investigará seu software procurando coisas que fazem você dizer a palavra maravilhosa: “Interessante!”. Ao aprender, você investiga ainda mais e encontra maneiras de quebrar o software em que os designers nunca pensaram e depois entregam um relatório que detalha inúmeras suposições, falhas e riscos ruins no software. Saiba mais sobre isso no livro chamado Explore It.
Teste de penetração
No mundo da segurança de software, o teste de penetração é um dos principais meios de teste. Todos os sistemas, biológicos, físicos ou software têm fronteiras e limites. Esses limites devem permitir apenas mensagens, pessoas ou componentes específicos para entrar no sistema. Mais concretamente, vamos considerar um sistema bancário on -line que usa a autenticação do usuário para entrar no site. Se o site puder ser invadido e inserido no back -end sem a autenticação adequada que seria uma penetração, que precisa ser protegida contra. O objetivo do teste de penetração é usar técnicas conhecidas e experimentais para ignorar o limite de segurança normal de um sistema de software ou site. Os testes de penetração geralmente envolvem verificar todas as portas que estão ouvindo e tentando entrar em um sistema por meio de uma porta aberta. Outras técnicas comuns incluem injeção de SQL ou rachaduras de senha.
Teste de regressão
Depois de ter um software de trabalho que é implantado em campo, é fundamental impedir a introdução de bugs na funcionalidade que já estava funcionando. O objetivo do desenvolvimento de software é aumentar a capacidade do seu produto, introduzir bugs ou fazer com que a funcionalidade antiga pare de funcionar, o que é chamado de regressão. A regressão é um bug ou defeito que foi introduzido quando anteriormente a capacidade estava funcionando como esperado. Nada pode arruinar a reputação do seu software ou marca mais rápido do que introduzir bugs de regressão em seu software e fazer com que usuários reais encontrem esses bugs após uma versão.
Casos de teste de regressão e planos de teste devem ser construídos em torno da funcionalidade principal que precisa continuar trabalhando para garantir que os usuários tenham uma boa experiência com seu aplicativo. Todas as funções principais do seu software que os usuários esperam funcionar de uma certa maneira devem ter um caso de teste de regressão que possa ser executado para impedir que a funcionalidade quebre em uma nova versão. Isso pode ser de 50 a 50.000 casos de teste que cobrem a funcionalidade principal do seu software ou aplicativo.
Teste de bissecção de código -fonte
Um bug foi introduzido no software, mas não é óbvio qual versão do lançamento introduziu o novo bug. Imagine que havia 50 softwares, desde o último horário conhecido, o software estava funcionando sem o bug, até agora quando ..
Teste de localização
Imagine uma aplicação climática que mostre o clima atual e projetado em sua localização, bem como uma descrição das condições climáticas. A primeira parte dos testes de localização é garantir que o idioma correto, o alfabeto e os caracteres sejam exibidos corretamente, dependendo da geolocalização do usuário. O aplicativo no Reino Unido deve ser exibido em inglês com caracteres latinos; O mesmo aplicativo na China deve ser exibido em caracteres chineses na língua chinesa. Testes de localização mais elaborados realizados, a gama mais ampla de pessoas de diferentes geolocações irá interface com o aplicativo.
Teste de acessibilidade
Alguns dos cidadãos de nossa comunidade têm deficiências e, portanto, podem ter problemas para usar o software que está sendo criado, portanto, o teste de acessibilidade é feito para garantir que as populações com deficiência ainda possam acessar a funcionalidade do sistema. Por exemplo, se assumirmos que 1% da população é daltônico, e nossa interface de software assume que os usuários podem distinguir entre vermelho e verde, mas esses indivíduos com cor que não podem dizer a diferença. Portanto, uma interface bem-software terá dicas adicionais além da cor para indicar significado. Outros cenários, além do teste de dores de cor, também seriam incluídos nos testes de acessibilidade de software, como cegueira visual total, surdez e muitos outros cenários. Um bom produto de software deve ser acessível por uma porcentagem máxima de usuários em potencial.
Teste de atualização
Aplicativos simples em um telefone, sistemas operacionais como Ubuntu, Windows ou Mint Linux e software que executa submarinos nucleares precisam de atualizações frequentes. O processo da atualização em si poderia introduzir bugs e defeitos que não existiriam em uma nova instalação porque o estado do ambiente era diferente e o processo de introdução do novo software no topo do antigo poderia ter introduzido bugs. Vamos dar um exemplo simples, temos um laptop executando o Ubuntu 18.04, e queremos atualizar para o Ubuntu 20.04. Este é um processo diferente de instalação do sistema operacional do que limpar diretamente o disco rígido e instalar o Ubuntu 20.04. Portanto, depois que o software é instalado ou qualquer uma de suas funções derivadas, pode não estar funcionando 100% conforme o esperado ou o mesmo que quando o software foi instalado recentemente. Portanto, devemos primeiro considerar testar a própria atualização em muitos casos e cenários diferentes para garantir que a atualização funcione para a conclusão. E então, também devemos considerar testar a atualização real do sistema para garantir que o software fosse estabelecido e funcionando conforme o esperado. Não repetiríamos todos os casos de teste de um sistema recém -instalado, o que seria uma perda de tempo, mas pensaremos cuidadosamente com nosso conhecimento do sistema do que poderia quebrar durante uma atualização e adicionar estrategicamente casos de teste para essas funções.
Teste de caixa preta e caixa branca
Caixa preta e caixa branca são metodologias de teste menos específicas e mais dos tipos de teste de categorizações. Essencialmente, o teste de caixa preta, que pressupõe que o testador não saiba nada sobre o trabalho interno do software e cria um plano de teste e casos de teste que apenas olham para o sistema de fora para verificar sua função. Os testes de caixa branca são feitos por arquitetos de software que entendem o funcionamento interno de um sistema de software e projetam os casos com conhecimento do que poderia,. Os testes de caixa preta e branca provavelmente encontrarão diferentes tipos de defeitos.
Blogs e artigos sobre teste de software
O teste de software é um campo dinâmico e muitas publicações e artigos interessantes que atualizam a comunidade sobre o pensamento de última geração sobre testes de software. Todos nós podemos nos beneficiar desse conhecimento. Aqui está uma amostra de artigos interessantes de diferentes fontes de blog que você pode querer seguir:
- 7 dicas a seguir antes de testar sem requisitos; http: // www.TestingJournals.coma
- 60 melhores ferramentas de teste de automação: o melhor guia da lista; https: // testguild.coma
- Ferramentas de teste de banco de dados de código aberto; https: // www.softwaretestingmagazine.coma
- 100 % de cobertura de teste de unidade não é suficiente; https: // www.stickyminds.coma
- Testes escamosos no Google e como os mitigamos; https: // testes.Googleblog.coma
- O que é teste de regressão? ; https: // teste.io/blog/
- 5 Principais etapas de teste de software que todo engenheiro deve executar; https: // techbeacon.coma
Produtos para teste de software
A maioria das valiosas tarefas de teste pode ser automatizada, portanto, não é de surpreender que o uso de ferramentas e produtos para executar as inúmeras tarefas de garantia de qualidade de software seja uma boa ideia. Abaixo, listaremos algumas ferramentas de software importantes e altamente valiosas para testes de software que você pode explorar e ver se eles podem ajudar.
Junit
Para testar o software baseado em Java, o Junit fornece um conjunto de testes abrangente para o teste de unidade e funcional do código que é amigável ao ambiente Java.
Selênio
Para testar aplicativos da Web, o Selenium oferece a capacidade de automatizar interações com navegadores da Web, incluindo testes de compatibilidade de navegadores cruzados. Esta é uma infraestrutura de teste principal para automação de testes na web.
Pepino
Uma estrutura de teste orientada a comportamento permite que usuários empresariais, gerentes de produto e desenvolvedores expliquem a funcionalidade esperada na linguagem natural e depois defina esse comportamento nos casos de teste. Isso faz casos de teste mais legíveis e mapeamento claro para a funcionalidade esperada do usuário.
Purificar
Encontre vazamentos de memória e corrupções de memória no tempo de execução, executando seu software com a instrumentação Purify Plus incorporada que rastreia seu uso de memória e aponta erros no seu código que não são fáceis de encontrar sem instrumentação.
Valgrind
Ferramentas de código aberto que executam seu software e permitirão que você interaja com ele enquanto aponta um relatório de erro de erros de codificação, como vazamentos de memória e corrupções. Não há necessidade de recompilar ou adicionar instrumentação ao processo de compilação, pois Valgrind tem inteligência para entender dinamicamente o código da sua máquina e injetar a instrumentação sem problemas para encontrar erros de codificação e ajudá -lo a melhorar seu código.
Cobertura
Ferramenta de análise estática que encontrará erros de codificação em seu software antes mesmo de você compilar e executar seu código. A cobertura pode encontrar vulnerabilidades de segurança, violações de convenções de codificação, bem como bugs e defeitos que seu compilador não encontrará. Código morto pode ser encontrado, variáveis não inicializadas e milhares de outros tipos de defeito. É vital limpar seu código com análise estática antes de liberá -lo para a produção.
Jmeter
Uma estrutura de código aberto para testes de desempenho orientado para desenvolvedores baseados em Java, daí o j no nome. O teste do site é um dos principais casos de uso para JMeter, além de testes de desempenho de bancos de dados, sistemas de correio e muitos outros aplicativos baseados em servidor.
Metasploit
Para testes de segurança e penetração, o metasploit é uma estrutura genérica com milhares de recursos e recursos. Use o console de interação para acessar explorações pré-codificadas e tente verificar a segurança do seu aplicativo.
Pesquisa acadêmica sobre teste de software
- Grupo de Pesquisa de Testes da Universidade de Sheffield
- Laboratório de Verificação e Validação da Universidade de Kentucky
- Grupo de Pesquisa de Teste de Software da Universidade Estadual de Dakota do Norte
- Testando o System Intelligent Lab; Praga da Universidade Técnica Tcheca
- NASA: Jon McBride Software Testing and Research (JSTAR)
- Universidade McMaster; Laboratório de Pesquisa de Qualidade de Software
- Universidade de Tecnologia de Ontário; Laboratório de Pesquisa de Qualidade de Software
- A Universidade do Texas @ Dallas; STQA
Conclusão
O papel do software na sociedade continua a crescer e, ao mesmo tempo, o software do mundo se torna mais complexo. Para que o mundo funcione, devemos ter métodos e estratégias para testar e validar o software que criamos, desempenhando as funções que se destina a executar. Para cada sistema de software complexo, uma estratégia de teste e um plano de teste devem estar em vigor para continuar a validar a funcionalidade do software à medida que eles continuam a melhorar e fornecer sua função.