• 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.
Nenhum comentário:
Postar um comentário