quarta-feira, 13 de maio de 2020

Tipos de Testes de Software (continuação)


• Teste de integridade dos dados: idem teste de integridade do banco de dados (Testa os métodos, processos e regras usados para acessar e gerenciar os (bancos de) dados, para garantir que eles funcionem como esperado, e que, durante o acesso ao banco de dados, os dados não são corrompidos, apagados, alterados ou criados de forma inesperada).

• Teste de interface: Um tipo do teste de integração que trata do teste das interfaces entre os componentes ou sistemas.

• Teste de interoperabilidade: Teste que determina a interoperabilidade do sistema. Veja também teste de funcionalidade.

• Teste de LCSAJ: Uma técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar os LCSAJs.

• Teste de ligação: idem teste de integração de componentes (Testes executados para revelar defeitos nas interfaces e interações entre componentes integrados).

• Teste de manutenção: Teste das alterações em um sistema ou dos impactos de um ambiente modificado em um sistema.

• Teste de manutenibilidade: Teste que determina a manutenibilidade de um sistema.

• Teste de mesa: Teste que simula manualmente a execução de um software ou especificação.

• Teste de migração: idem teste de conversão (Teste usado para converter dados de um sistema existente para serem usados em sistemas que o substituam).

• Teste de módulos: idem teste de componente (Teste dos componentes de software individuais).

• Teste de mutação: idem teste back-to-back (Testes onde duas ou mais variantes de um sistema são executadas com as mesmas entradas. As saídas são comparadas e analisadas caso haja discrepância).

• Teste de padrão: idem teste de complacência (Processo de teste para determinar a complacência de um sistema).

• Teste de partição: idem particionamento por equivalência (Reduz um conjunto de entradas de grande (infinito) a um conjuto finito: pequeno, mas eficiente. Divide o domínio de entrada de um software (ou programa) em classes de dados a partir das quais os casos de teste podem ser derivados).

• Teste de particionamento por equivalência: Reduz um conjunto de entradas de grande (infinito) a um conjunto finito: pequeno, mas eficiente. Divide o domínio de entrada de um software (ou programa) em classes de dados a partir das quais os casos de teste podem ser derivados.

• Teste de portabilidade: Teste que determina a portabilidade de um sistema.

• Teste de ramos: Teste que executa os ramos do software.

• Teste de recuperação: idem teste de capacidade de recuperação (Processo de teste para determinar a capacidade de recuperação de um sistema).

• Teste de regressão: Teste de um programa previamente testado e que foi alterado para garantir que todas as partes não modificadas foram cobertas ou que não foram introduzidos defeitos nas partes não modificadas do software. Ele deve ser executado quando o software ou o ambiente for modificado.

• Teste de robustez: Teste que determina a robustez do sistema.

• Teste de sanidade: idem teste de fumaça (Subconjunto de todos os casos de teste definidos/planejados que cobrem as principais funcionalidades do sistema, para verificar se eles funcionam, mas sem se preocupar com detalhes. Uma construção diária e o teste de sanidade estão entre as boas práticas da indústria).

• Teste de segurança: Teste que determina o quão seguro é um sistema. Veja também teste de funcionalidade.

• Teste de sintaxe: Técnica de projeto de teste caixa preta onde os casos de testes são projetados com base na definição dos domínios de entrada e/ou saída.

• Teste de sistema: Processo de testar um sistema integrado para verificar se ele atende aos requisitos especificados.

• Teste de tabela de decisão: Técnica de projeto de teste caixa preta onde os casos de teste são projetados para executar as combinações de entradas e/ou estímulos (causas) mostrados na tabela de decisão.

• Teste de threads: Uma variação do teste de integração de componentes onde a integração progressiva segue a implementação de subconjuntos de requisitos e não níveis de hierarquia.

• Teste de transição de estados: Teste que executa transições de estados válidas e inválidas.

• Teste de usabilidade: Teste que determina o quanto o sistema é entendido, fácil de aprender, fácil de ser operado e atraente para o usuário.

• Teste de utilização de recursos: Teste que determina a utilização de recursos de um sistema.

• Teste de valor limite: é uma técnica de teste de software utilizada para exercitar os limites do domínio de entrada. Considerada um complemento do Particionamento de Equivalência, focalizando a seleção de Casos de Teste nas bordas da classe, ou seja, nos valores próximos às extremidades das classes.


• Teste de volume: Teste que submete o sistema a grandes volumes de dados.

• Teste dinâmico: Teste que envolve a execução de um software.

• Teste dirigido pela lógica: idem teste caixa branca (é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte).

• Teste dirigido por dados: Técnica de roteirização que armazena os dados de entrada e os resultados esperados dos testes em uma tabela ou planilha, assim, um script único de controle pode executar todos os testes da tabela. Esse teste normalmente é usado para apoiar o uso de ferramentas de execução de teste tais como ferramentas de captura/reprodução dos testes.

• Teste dirigido por palavra-chave: Técnica que usa arquivos de dados para armazenar os dados de teste, os resultados esperados e as palavras chave relacionadas à aplicação que está sendo testada. As palavras-chave são interpretadas por scripts especiais de apoio que são chamados pelos scripts de controle para o teste.

• Teste do ciclo do processo: Teste que executa procedimentos e processos de negócio.

• Teste do perfil operacional: Teste estatístico que usa um modelo de operações do sistema (atividade de curta duração) e sua probabilidade de uso.

• Teste do programa: idem teste de componente (Teste dos componentes de software individuais).

• Teste do regulamento: idem teste de complacência (Processo de teste para determinar a complacência de um sistema).

• Teste do usuário: Teste onde os usuários reais avaliam a usabilidade do sistema.

• Teste estático: Teste de um sistema na fase de especificação ou implementação sem executar o software (exemplo, revisão ou análise estática do código).

• Teste estatístico: Teste que usa um modelo de distribuição estatística das entradas para construir casos de testes representativos. Veja também teste do perfil operacional.

• Teste estrutural: idem teste caixa branca (é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte).

• Teste exaustivo: Teste que inclui todas as combinações possíveis de valores de entrada e precondições.

• Teste exploratório: Teste informal onde o testador controla ativamente os testes e como eles serão executados. Usa a informação obtida enquanto testa para projetar testes novos e melhores.

• Teste funcional: Teste baseado na análise da especificação da funcionalidade do sistema.

• Tes te glass-box: idem teste caixa branca (é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte).

• Teste incremental: Teste onde os sistemas são integrados e testados um (ou alguns) de cada vez, até que todos os sistemas tenham sido integrados e testados.

• Teste inválido: Teste que usa valores de entrada que devem ser rejeitados pelo sistema.

• Teste isolado: Teste dos componentes isolados dos componentes vizinhos. Esses últimos são simulados por drivers e stubs, se necessário. Teste não-funcional: Teste dos atributos de qualidade, e não de funcionalidade, de um sistema tais como confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade.

• Teste negativo: Seu objetivo é mostrar que o sistema não funciona. O teste negativo está mais relacionado à atitude dos testadores do que a alguma técnica de teste ou de projeto de teste específica. Por exemplo, testar com valores de entrada inválidos ou exceções.

• Teste N-switch: Um tipo de teste de transição de estados onde o teste executa todas as sequências válidas das N+1 transições.

• Teste operacional: Teste que avalia um sistema em seu ambiente operacional.

• Teste aos pares: Duas pessoas, por exemplo, dois testadores, um desenvolvedor e um testador ou um usuário final e um testador, trabalhando juntas para encontrar defeitos. Normalmente, eles usam o mesmo computador e negociam o controle do mesmo enquanto testam.

• Teste “sujo”: idem teste negativo (Seu objetivo é mostrar que o sistema não funciona. O teste negativo está mais relacionado à atitude dos testadores do que a alguma técnica de teste ou de projeto de teste específica. Por exemplo, testar com valores de entrada inválidos ou exceções).

• Teste top-down: Um tipo de teste de integração incremental onde o componente do alto da hierarquia é testado primeiro, com os componentes do nível mais baixo sendo simulados por stubs. Os componentes testados são usados testar os componentes dos níveis mais baixos. O processo é repetido até que os componentes do nível o mais baixo estejam testados.

• Teste unitário: idem teste de componente (Teste dos componentes de software individuais).

terça-feira, 12 de maio de 2020

Tipos de Testes de Software

Existem diversos tipos de testes de software.

• Teste aleatório: Técnica de teste caixa preta onde os casos de teste são selecionados de acordo com um perfil operacional, normalmente usando um algoritmo de geração pseudo-aleatória. Esta técnica pode ser usada para testar atributos não funcionais, como confiabilidade e performance.

• Teste alfa: Teste operacional, simulado ou real, executado por usuários/clientes em potencial ou por uma equipe independente de teste (de fora da organização) nas instalações do desenvolvedor. O teste alfa normalmente é usado como teste de aceite interno para softwares de prateleira.

• Teste back-to-back: Testes onde duas ou mais variantes de um sistema são executadas com as mesmas entradas. As saídas são comparadas e analisadas caso haja discrepância.

• Teste baseado em código: idem teste caixa branca (Teste de caixa-branca é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte).

• Teste baseado em projetos: Técnica de teste onde os casos de teste são projetados com base na arquitetura e/ou projeto detalhado do sistema (por exemplo: testes de interface entre componentes ou sistemas).

• Teste baseado em requisitos: Técnica de teste onde os casos de teste são definidos com base nos objetivos do teste e as condições de teste derivadas dos requisitos. Por exemplo, testes que exercitam funções específicas ou investigam atributos não funcionais como confiabilidade ou usabilidade.

• Teste baseado em riscos: Testes orientados para explorar e fornecer informação a respeito dos riscos do produto.

• Teste baseado na especificação: idem teste caixa preta (Teste de caixa-preta é um teste de software para verificar a saída dos dados usando entradas de vários tipos. Tais entradas não são escolhidas conforme a estrutura do programa. Quanto mais entradas são fornecidas, mais rico será o teste).

• Teste baseado no processo do negócio: Técnica de teste onde os casos de teste são projetados com base nas descrições e/ou conhecimento do processo do negócio.

• Teste beta: Teste operacional realizado por usuários/clientes em potencial, fora das instalações do desenvolvedor, para determinar se um sistema satisfaz ou não suas necessidades e se encaixa nos processos do negócio. O teste beta normalmente é usado como um teste de aceite externo para softwares de prateleira para obter feedback do mercado.

• Teste big-bang: Um tipo de teste de integração onde os elementos do software ou hardware (ou ambos) são combinados todos de uma vez em um sistema, ao invés de serem combinados em etapas.

• Teste bottom-up: Um tipo de teste de integração incremental onde os componentes do nível mais baixo são testados e integrados primeiro. Este processo é repetido até que o componente do nível mais alto na hierarquia esteja testado. Facilita os testes dos componentes de nível mais alto.

• Teste comparativo: (1) Um padrão com o qual as medidas ou comparações podem ser feitas. (2) Um teste que pode ser usado para comparar componentes ou sistemas entre si ou com um padrão como em (1).

• Teste completo: idem teste exaustivo (Teste que inclui todas as combinações possíveis de valores de entrada e precondições).

• Testes de aceitação: Tem como objetivo confirmar que o sistema funciona de acordo com a especificação. Cada história deve estar associada a um conjunto de testes de aceitação. Tem como objetivo deixar claro para todos qual a expectativa do dono do produto (product owner) em relação ao requisito e a história do usuário.

• Teste de aceite: Teste formal das necessidades, exigências e processos de negócio do usuário conduzidos para determinar se um sistema satisfaz ou não os critérios de aceite e para permitir que o usuário, cliente ou outra entidade autorizada determinem se aceitam ou não o sistema.

• Teste de aceite do usuário: idem teste de aceite (Teste formal das necessidades, exigências e processos de negócio do usuário conduzidos para determinar se um sistema satisfaz ou não os critérios de aceite e para permitir que o usuário, cliente ou outra entidade autorizada determinem se aceitam ou não o sistema).

• Teste de aceite local: Teste de aceite executado por usuários/clientes nas suas instalações para determinar se o sistema satisfaz ou não as suas necessidades e se encaixa nos processos de negócio. Normalmente inclui hardware e software.

• Teste de acessibilidade: Teste para determinar qual o grau de facilidade com que usuários com necessidades especiais conseguem usar o sistema em teste.

• Teste de algoritmos [TMap]: idem teste de ramos (Teste que executa os ramos do software).

• Teste de arcos: idem teste de ramos (Teste que executa os ramos do software).

• Teste de armazenamento: idem teste de utilização de recursos (Teste que determina a utilização de recursos de um sistema).

• Teste de caixa-branca: é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte.

• Teste de caixa-preta: é um teste de software para verificar a saída dos dados usando entradas de vários tipos. Tais entradas não são escolhidas conforme a estrutura do programa. Quanto mais entradas são fornecidas, mais rico será o teste.

• Teste de caminhos: Técnica de projeto de teste caixa branca onde os casos de testes são projetados para executar caminhos no software.

• Teste de campos: idem teste beta (Teste operacional realizado por usuários/clientes em potencial, fora das instalações do desenvolvedor, para determinar se um sistema satisfaz ou não suas necessidades e se encaixa nos processos do negócio. O teste beta normalmente é usado como um teste de aceite externo para softwares de prateleira para obter feedback do mercado).

• Teste de capacidade de recuperação: Processo de teste para determinar a capacidade de recuperação de um sistema.

• Teste de capacidade de serviço de manutenção: idem teste de manutenibilidade.

• Teste de casos de uso: Técnica de teste caixa preta onde os testes são projetados para executar cenários.

• Teste de cenário: idem teste de casos de uso (Técnica de teste caixa preta onde os testes são projetados para executar cenários).

• Teste de cobertura da lógica: idem teste caixa branca (teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte).

• Teste de comandos: Técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar comandos.

• Teste de combinações de condições: idem teste de condições múltiplas (Uma técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar combinações das consequências de cada condição (dentro de um comando)).

• Teste de combinações de condições dos ramos: idem teste de condições múltiplas (Uma técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar combinações das consequências de cada condição (dentro de um comando)).

• Teste de comparação elementar: Técnica de projeto de teste caixa preta onde os casos de teste são projetados para executar combinações de entradas usando o conceito da cobertura de determinação de condições.

• Teste de compatibilidade: idem teste de interoperabilidade (Teste que determina a interoperabilidade do sistema).

• Teste de complacência: Processo de teste para determinar a complacência de um sistema.

• Teste de componente: Teste dos componentes de software individuais.

• Teste de concorrência: Teste para determinar como a ocorrência de duas ou mais atividades, no mesmo intervalo de tempo, iniciadas por intercalação de atividades ou execuções simultâneas, são tratadas pelo sistema.

• Teste de condições: Técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar as consequências das condições.

• Teste de condições de decisão: Técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar as consequências das condições e das decisões.

• Teste de condições múltiplas: Uma técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar combinações das consequências de cada condição (dentro de um comando)

• Teste de confiabilidade: Processo de teste para determinar a confiabilidade de um sistema.

• Teste de confiança: idem teste de fumaça (Subconjunto de todos os casos de teste definidos/planejados que cobrem as principais funcionalidades do sistema, para verificar se eles funcionam, mas sem se preocupar com detalhes. Uma construção diária e o teste de sanidade estão entre as boas práticas da indústria).

• Teste de configuração: idem teste de portabilidade (Teste que determina a portabilidade de um sistema).

• Teste de confirmação: idem reteste (Teste de um programa previamente testado e que foi alterado para garantir que todas as partes não modificadas foram cobertas ou que não foram introduzidos defeitos nas partes não modificadas do software. Ele deve ser executado quando o software ou o ambiente for modificado).

• Teste de conformidade: idem teste de complacência (Processo de teste para determinar a complacência de um sistema).

• Teste de conversão: Teste usado para converter dados de um sistema existente para serem usados em sistemas que o substituam.

• Teste de decisão: Teste que executa as consequências das decisões.

• Teste de desenvolvimento: Teste formal ou informal conduzido durante a implementação do sistema. Geralmente é executado pelos desenvolvedores no ambiente de desenvolvimento.

• Teste de determinação de condições: Teste que executa uma condição cuja consequência afeta independentemente a consequência de uma decisão.

• Teste de documentação: Testa a qualidade dos documentos como, por exemplo, guia do usuário ou de instalação.

• Teste de eficiência: Teste que determina a eficiência do produto do software.

• Teste de entrada: Uma instância do teste de sanidade que decide se o sistema está pronto para testes mais detalhados. Um teste de entrada normalmente é feito no início da fase da execução do teste.

• Teste de escalabilidade: Teste que determina a escalabilidade de um sistema.

• Teste de estados: idem teste de transição de estados (Teste que executa transições de estados válidas e inválidas).

• Teste de fluxo de dados: Teste que executa definições e usa pares de variáveis.

• Teste de fumaça: Subconjunto de todos os casos de teste definidos/planejados que cobrem as principais funcionalidades do sistema, para verificar se eles funcionam, mas sem se preocupar com detalhes. Uma construção diária e o teste de sanidade estão entre as boas práticas da indústria.

• Teste de funcionalidade: Teste que verifica a funcionalidade de um sistema.

• Teste de grafos causa-efeito: Uma técnica de projeto de teste caixa preta onde os casos de teste são definidos a partir de grafos causa-efeito.

• Teste de instalabilidade: Testa a instalabilidade de um sistema.

• Teste de integração: Teste executado para encontrar defeitos nas interfaces e nas interações entre componentes ou sistemas integrados.

• Teste de integração de componentes: Testes executados para revelar defeitos nas interfaces e interações entre componentes integrados.

• Teste de integração de sistemas: Testa a integração dos sistemas e pacotes; testa as interfaces com organizações externas (por exemplo, troca eletrônica de dados, Internet).

• Teste de integração no grande: idem teste de integração de sistemas (Testa a integração dos sistemas e pacotes; testa as interfaces com organizações externas (por exemplo, troca eletrônica de dados, Internet)).

• Teste de integração no pequeno: idem teste de integração de componentes (Testes executados para revelar defeitos nas interfaces e interações entre componentes integrados).

• Teste de integridade do banco de dados: Testa os métodos, processos e regras usados para acessar e gerenciar os (bancos de) dados, para garantir que eles funcionem como esperado, e que, durante o acesso ao banco de dados, os dados não são corrompidos, apagados, alterados ou criados de forma inesperada.