Phenquestions
Teste de Unidade
O Teste de Unidade é o teste feito em uma função individual, classe ou módulo independentemente do que testar um software totalmente funcional. Usando uma estrutura para teste 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 tem casos de teste, os casos de teste para esse módulo devem ser estudados e determinar se novos casos de teste são necessários, a saída foi alterada ou os casos de teste atuais podem ser removidos como não mais relevantes. A criação de um grande volume de testes de unidade é a maneira mais fácil de alcançar 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 o esperado.
Teste funcional
O teste funcional é a forma mais comum de teste. Quando as pessoas se referem a testes de software sem muitos detalhes, muitas vezes se referem a testes funcionais. O teste funcional irá verificar se as funções principais do software funcionam conforme o esperado. Um plano de teste pode ser escrito para descrever todos os casos de teste funcional que serão testados, o que corresponde aos principais recursos e capacidades do software. O teste de funcionalidade primária será “caminho feliz ” teste, que não tenta quebrar o software ou usá-lo em qualquer 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 são testados independentemente, mas não como um sistema inteiro, o teste de integração deve ser realizado para validar a função dos componentes juntos como um sistema de trabalho de acordo com os requisitos e expectativas do usuário.
Teste de Estresse
Pense no teste de estresse como se estivesse testando um ônibus espacial ou avião. O que significa colocar seu software ou sistema em “STRESS”? O estresse nada mais é do que uma carga intensa de um tipo específico que provavelmente quebrará seu sistema. Isso pode ser semelhante a "Teste de carga" no sentido de colocar seu sistema sob alta simultaneidade com muitos usuários acessando o sistema. Mas estressar um sistema também pode acontecer em outros vetores. Por exemplo, a execução de firmware em um componente de hardware quando o hardware apresenta deterioração física e está operando em modo degradado. O estresse é exclusivo para todos os tipos de software, e os sistemas e os testes de projeto de estresse devem levar em consideração quais causas naturais ou não naturais têm maior probabilidade de estressar seu software ou sistema.
Teste de carga
O teste de carga é um tipo específico de teste de estresse, conforme discutido acima, em que um grande número de conexões e acessos de usuários simultâneos são automatizados para gerar a simulação do efeito de um grande número de usuários autênticos acessando seu sistema de software ao mesmo tempo. O objetivo é descobrir quantos usuários podem acessar seu sistema ao mesmo tempo sem que o sistema de software seja interrompido. Se o seu sistema pode 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? Será que isso é inesperado? "CARREGAR" quebrar seu site ou sistema? O teste de carga simulará isso, então você se sente confortável com o aumento futuro de usuários porque sabe que seu sistema pode lidar com o aumento de carga.
Teste de performance
As pessoas podem ficar totalmente frustradas e desesperadas quando o software não está atendendo aos seus requisitos de desempenho. Desempenho, geralmente, significa a rapidez com que funções importantes podem ser concluídas. Quanto mais complexas e dinâmicas as funções estão disponíveis em um sistema, mais importante e não óbvio se torna testar seu desempenho, vamos dar um exemplo básico, sistema operacional Windows ou Linux. Um sistema operacional é um produto de software altamente complexo, e fazer testes de desempenho em seu sistema pode envolver a velocidade e o tempo de funções como inicialização, instalação de um aplicativo, pesquisa de arquivo, execução de cálculos em uma GPU e / ou qualquer outro os milhões de ações que podem ser realizadas. Deve-se tomar cuidado ao selecionar os casos de teste de desempenho, para garantir os recursos de desempenho testados importantes e com probabilidade de mau funcionamento.
Teste de Escalabilidade
Testar em seu laptop é bom, mas não é realmente 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, o teste 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, seu teste provavelmente nunca será capaz de ser executado em escala total antes de ser lançado em produção porque seria muito caro e não prático construir um sistema de teste com 1000 servidores que custaria milhões de dólares. Portanto, o teste de escalabilidade é feito em vários servidores, mas geralmente não no número total de servidores de produção para tentar descobrir alguns dos defeitos que podem ser encontrados quando seus sistemas são usados em uma infraestrutura maior.
Teste de análise estática
A análise estática é o teste que é feito inspecionando o código do software sem realmente executá-lo. Para fazer análise estática, geralmente, você usaria uma ferramenta, existem muitas, uma ferramenta famosa é Coverity. A análise estática é fácil de executar antes de lançar seu software e pode encontrar muitos problemas de qualidade em seu código que podem ser corrigidos antes de lançar. Erros de memória, erros de manipulação de tipo de dados, desreferências de ponteiro nulo, variáveis não inicializadas e muitos outros defeitos podem ser encontrados. Linguagens como C e C ++ se beneficiam muito da análise estática porque as linguagens fornecem grande liberdade aos programadores em troca de grande poder, mas isso também pode criar grandes 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 que o defeito ocorra naturalmente. O objetivo do teste de injeção de falha é ver como o software lida com essas falhas inesperadas. Ele responde perfeitamente à situação, trava ou produz resultados problemáticos inesperados e imprevisíveis? Por exemplo, digamos que temos um sistema bancário e existe um módulo para transferir fundos internamente da CONTA A para a CONTA B. No entanto, esta operação de transferência só é chamada após o sistema já ter verificado que essas contas existiam antes de chamar a operação de transferência. Embora presumamos que ambas as contas existem, a operação de transferência tem um caso de falha em que uma conta de destino ou de origem não existe e pode gerar um erro. Como em circunstâncias normais nunca obtemos esse erro devido ao pré-teste de entradas, para verificar o comportamento do sistema quando a transferência falha devido a uma conta inexistente, injetamos um erro falso no sistema que retorna uma conta inexistente para uma transferência e teste como o resto do sistema responde nesse caso. É muito importante que o código de injeção de falha só esteja disponível em cenários de teste e não seja liberado para produção, onde pode criar confusão.
Teste de sobrecarga de memória
Ao usar linguagens como C ou C ++, o programador tem uma grande responsabilidade de endereçar diretamente a memória, e isso pode causar bugs fatais no software se erros forem cometidos. Por exemplo, se um ponteiro for nulo e não referenciado, o software irá travar. Se a memória for alocada para um objeto e, em seguida, uma string for copiada sobre o espaço de memória do objeto, fazer referência ao objeto pode causar um travamento ou até mesmo um comportamento incorreto não especificado. Portanto, é fundamental usar uma ferramenta para tentar detectar erros de acesso à memória em software que usa linguagens como C ou C ++, que podem ter esses problemas potenciais. Ferramentas que podem fazer este tipo de teste incluem Open Source Valgrind ou ferramentas proprietárias como PurifyPlus. Essas ferramentas podem salvar o dia quando não está claro por que o software está travando ou se comportando mal e apontam diretamente para o local no código que contém o bug. Incrível né?
Teste de caso de limite
É fácil cometer erros na codificação quando você está no que é chamado de limite. Por exemplo, um caixa eletrônico de banco diz que você pode sacar no máximo $ 300. Então, imagine que o codificador escreveu o código a seguir naturalmente ao construir esse requisito:
If (amt < 300)startWithdrawl ()
senão
erro (“Você pode retirar% s”, amt);
Você pode identificar o erro? O usuário que tentar sacar $ 300 receberá um erro porque não é inferior a $ 300. Isso é um bug. Portanto, o teste de limite é feito naturalmente. Limites de requisitos, em seguida, certifique-se de que em ambos os lados do limite e do limite, o software está funcionando corretamente.
Teste Fuzz
A geração de entrada em alta velocidade para o software pode produzir tantas combinações de entrada possíveis, mesmo se essas combinações de entrada forem totalmente sem sentido e nunca seriam fornecidas por um usuário real. Este tipo de teste de difusão pode encontrar bugs e vulnerabilidades de segurança não encontrados por outros meios devido ao alto volume de entradas e cenários testados rapidamente sem geração manual de casos de teste.
Teste Exploratório
Feche os olhos e visualize o que a palavra “Explorar” significa. Você está observando e sondando um sistema para descobrir como ele realmente funciona. Imagine que você receba uma nova cadeira de mesa pelo correio, e ela tem 28 peças, todas em sacos plásticos separados, sem instruções. Você deve explorar sua nova chegada para descobrir como ela funciona e como é montada. Com esse 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 o façam dizer a palavra maravilhosa: “INTERESSANTE!”. Ao aprender, você investiga mais e encontra maneiras de quebrar o software que os designers nunca pensaram e, em seguida, entrega um relatório que detalha várias suposições, falhas e riscos incorretos no software. Saiba mais sobre isso no livro 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, sejam biológicos, físicos ou de software têm fronteiras e limites. Esses limites têm como objetivo permitir que apenas mensagens, pessoas ou componentes específicos entrem no sistema. Mais concretamente, vamos considerar um sistema de banco online que usa autenticação de usuário para entrar no site. Se o site puder ser hackeado e inserido no back-end sem a autenticação adequada, isso seria uma invasão, que precisa ser protegida contra. O objetivo do teste de penetração é usar técnicas conhecidas e experimentais para contornar o limite de segurança normal de um sistema de software ou site. O teste de penetração muitas vezes envolve a verificação de todas as portas que estão escutando e tentando entrar em um sistema através de uma porta aberta. Outras técnicas comuns incluem injeção de SQL ou quebra de senha.
Teste de Regressão
Depois de ter o software em funcionamento que é implantado no campo, é fundamental evitar 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 funcionalidades antigas parem de funcionar, o que é chamado de REGRESSÃO. A regressão é um bug ou defeito que foi introduzido quando anteriormente a capacidade estava funcionando conforme o 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 o lançamento.
Casos de teste de regressão e planos de teste devem ser construídos em torno da funcionalidade central que precisa continuar trabalhando para garantir que os usuários tenham uma boa experiência com seu aplicativo. Todas as funções centrais do seu software que os usuários esperam que funcionem de uma certa maneira devem ter um caso de teste de regressão que pode ser executado para evitar que a funcionalidade seja interrompida em uma nova versão. Isso pode ser de 50 a 50.000 casos de teste que cobrem a funcionalidade central do seu software ou aplicativo.
Teste de divisão do 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 houvesse 50 commits de software desde a última vez em que o software estava funcionando sem o bug, até agora quando ..
Teste de localização
Imagine um aplicativo de clima que mostra o clima atual e projetado em sua localização, bem como uma descrição das condições meteorológicas. A primeira parte do teste de localização é garantir que o idioma, o alfabeto e os caracteres corretos 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 no idioma chinês. Testes de localização mais elaborados feitos, uma gama mais ampla de pessoas de diferentes geolocalização farão a interface com o aplicativo.
Teste de Acessibilidade
Alguns dos cidadãos em nossa comunidade têm deficiências e, portanto, podem ter problemas para usar o software que está sendo criado, então 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ônica e nossa interface de software presume que os usuários podem distinguir entre vermelho e verde, mas esses indivíduos daltônicos NÃO PODEM dizer a diferença. Portanto, uma interface de bom software terá pistas adicionais além da cor para indicar o significado. Outros cenários além do teste de daltonismo também seriam incluídos no teste de acessibilidade de software, como cegueira visual total, surdez e muitos outros cenários. Um bom produto de software deve ser acessível a uma porcentagem máxima de usuários em potencial.
Teste de atualização
Aplicativos simples em um telefone, sistemas operacionais como Ubuntu, Windows ou Linux Mint e software que executa submarinos nucleares precisam de atualizações frequentes. O próprio processo de atualização pode 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 sobre o 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, ele pode não estar funcionando 100% como esperado ou o mesmo que quando o software foi instalado recentemente. Portanto, devemos primeiro considerar o teste da própria atualização em muitos casos e cenários diferentes para garantir que a atualização funcione até a conclusão. E então, devemos também considerar o teste do sistema real após a atualização para garantir que o software foi instalado 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 sobre o que PODERIA quebrar durante uma atualização e adicionar estrategicamente casos de teste para essas funções.
Teste de caixa preta e caixa branca
A caixa preta e a caixa branca são metodologias de teste menos específicas e mais tipos de categorizações de teste. Essencialmente, o teste de caixa preta, que assume que o testador não sabe nada sobre o funcionamento interno do software e constrói um plano de teste e casos de teste que apenas olham para o sistema de fora para verificar sua função. O teste de caixa branca é feito por arquitetos de software que entendem o funcionamento interno de um sistema de software e projetam os casos com conhecimento do que poderia, iria, deveria e provavelmente quebraria. 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 mais moderno sobre teste de software. Todos nós podemos nos beneficiar deste conhecimento. Aqui está um exemplo de artigos interessantes de diferentes fontes de blogs que você pode querer seguir:
- 7 dicas para seguir antes de testar sem requisitos; http: // www.testando diários.com /
- 60 Best Automation Testing Tools: The Ultimate List Guide; https: // testguild.com /
- Ferramentas de teste de banco de dados de código aberto; https: // www.softwaretestingmagazine.com /
- 100% de cobertura de teste unitário não é suficiente; https: // www.stickyminds.com /
- Testes instáveis no Google e como os mitigamos; https: // teste.googleblog.com /
- O que é teste de regressão? ; https: // teste.io / blog /
- 27 melhores extensões do Chrome para desenvolvedores em 2020; https: // www.lambdatest.com /
- 5 etapas principais de teste de software que todo engenheiro deve executar; https: // techbeacon.com /
Produtos para teste de software
A maioria das tarefas de teste valiosas pode ser automatizada, então não deve ser surpresa que usar ferramentas e produtos para realizar as inúmeras tarefas de garantia de qualidade de software é uma boa ideia. Abaixo, listaremos algumas ferramentas de software importantes e altamente valiosas para teste de software que você pode explorar e ver se podem ajudar.
JUnit
Para testar software baseado em Java, JUnit fornece um conjunto de teste abrangente para teste de unidade e funcional do código que é amigável para o ambiente Java.
Selênio
Para testar aplicativos da web, o Selenium fornece a capacidade de automatizar interações com navegadores da web, incluindo testes de compatibilidade entre navegadores. Esta é uma infraestrutura de teste de primeira para automação de teste da web.
Pepino
Uma estrutura de teste orientada por comportamento permite que usuários de negócios, gerentes de produto e desenvolvedores expliquem a funcionalidade esperada em linguagem natural e, em seguida, definam esse comportamento em casos de teste. Isso torna os casos de teste mais legíveis e o mapeamento claro para a funcionalidade esperada do usuário.
Purificar
Encontre vazamentos e corrupções de memória em tempo de execução executando seu software com a instrumentação Purify Plus incorporada que rastreia o uso de memória e aponta erros em seu código que não são fáceis de encontrar sem instrumentação.
Valgrind
Ferramentas de código aberto que irão executar o seu software e permitir 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 seu código de máquina e injetar instrumentação perfeitamente para encontrar erros de codificação e ajudá-lo a melhorar seu código.
Coverity
Ferramenta de análise estática que encontrará erros de codificação em seu software antes mesmo de compilar e executar seu código. Coverity 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á. O código morto pode ser encontrado, variáveis não inicializadas e milhares de outros tipos de defeitos. É vital limpar seu código com análise estática antes de liberá-lo para produção.
JMeter
Uma estrutura de código aberto para testes de desempenho orientados para desenvolvedores baseados em Java, daí o J no nome. O teste de site é um dos principais casos de uso do JMeter, além do teste de desempenho de bancos de dados, sistemas de e-mail e muitos outros aplicativos baseados em servidor.
Metasploit
Para testes de segurança e penetração, Metasploit é uma estrutura genérica com milhares de recursos e capacidades. Use o console de interação para acessar exploits pré-codificados e tente verificar a segurança de seu aplicativo.
Pesquisa acadêmica em teste de software
- Grupo de pesquisa de testes da Universidade de Sheffield
- Laboratório de validação e verificação de software da University of Kentucky
- Grupo de pesquisa de teste de software da North Dakota State University
- Laboratório inteligente de teste de sistema; Universidade Técnica Tcheca de Praga
- NASA: Jon McBride Teste e Pesquisa de Software (JSTAR)
- McMaster University; Laboratório de Pesquisa de Qualidade de Software
- Ontario Tech University; Laboratório de pesquisa de qualidade de software
- The University of 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, executando as funções que se pretende realizar. 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 a fornecer sua função.
