Teste de caixa preta

Cada software, antes de se lançar no mercado, é testado para sua funcionalidade completamente. E é necessário também, como um monte de dinheiro está no rolo, para cada software que é feita para aplicações diversificadas, seja bancário, vias aéreas, ferrovias ou do sistema, mesmo educacional. Este é o lugar onde o teste de software vem em imagem, para verificar se há ou não um aplicativo está funcionando corretamente, usando toda a permutação e combinações de possibilidades que podem ou não ocorrer. Uma vez que um aplicativo é desenvolvido com um software especial, há muitos tipos de testes que são feitos sobre o software. Uma das metodologias de teste de software é teste de software caixa preta. Portanto, este artigo vai ajudar a entender o que é o teste de caixa-preta em detalhes.

Definição de teste Caixa Preta

Testes de software da caixa negra pode ser definida como um método de desenho de teste, o que ajuda a verificar os requisitos funcionais de uma aplicação, sem explicitamente usando o conhecimento da estrutura do núcleo da aplicação. Um conjunto de casos de teste são criados com uma combinação de entradas corretas e incorretas, dependendo do projeto, requisitos e especificações da aplicação desenvolvida. Este teste normalmente começa logo que o código de aplicação foi desenvolvida numa forma bruta. Outros nomes para este método de teste são:

* O teste funcional

* Teste de caixa fechada

* Teste de caixa opaca

* Teste Comportamental

Técnicas de Teste de Caixa Preta

Há certo conjunto de técnicas utilizadas em testes de caixa preta que especulam as várias saídas possíveis, a partir do qual as entradas e as funcionalidades do software de aplicação podem ser validados. Vá através das técnicas mencionadas abaixo para entender melhor este assunto.

Tabela de Decisão

Uma tabela de decisão como o nome sugere, é uma estratégia de teste caixa preta, o que dá saídas para os casos de teste, com base na decisão. É composto por uma tabela contendo quatro quadrantes, condições, entradas condição, declarações de ação e entradas de ação. Precisamente, todas as condições possíveis são testados para verificar se a saída desejada é alcançada depois de tentar entradas diferentes. Então, como fazer uma tabela de decisão? Siga as indicações abaixo para criar um.

* Primeiro antes de projetar uma tabela de decisão, eliminar todas as situações impossíveis, redundâncias e inconsistências que poderiam ser uma parte dos dados de entrada.

* Determinar o número de condições que têm um impacto sobre a decisão.

* Determine todas as possíveis ações que poderiam ser tomadas, bem como o número de alternativas de condição para cada condição. Considerando-se uma tabela de decisão simples, as alternativas são "sim" ou "não".

* Agora, tente descobrir as possíveis combinações únicas / possibilidades que podem ser calculados por encontrar possíveis valores para cada condição e multiplicando-los juntos. Isso também irá dar-lhe o número total de colunas para inserir na tabela.

* Entre todas as combinações possíveis derivados, nas colunas na parte superior da tabela de decisão.

* Para cada possibilidade única, marque um X no quadrante inferior direito na linha de ação apropriado. Este símbolo indica a interseção da ação necessária e uma combinação única.

* Uma vez que a mesa está completa, verifique se há contradições e removê-los. Reorganizar o conteúdo da tabela de acordo.

Vamos tomar um exemplo simples de teste caixa preta usando este método: Considere uma empresa de marketing que decidiu mercado quatro produtos (A, B, C e D), em função das três características: sexo (masculino - M ou feminino - F), morador da cidade (Sim - Y ou Não - N) e faixa etária (60 (Z)). Assim, o número total de colunas são: 2 (Sexo) x 2 (morador da cidade) x 3 (Grupo de idade) = 12 colunas. Agora conjunto de regras diz:

* Um produto para mulheres que moram na cidade

* Produto B para jovens do sexo feminino

* Produto C por meia idade clientes masculinos que não são moradores da cidade

* Produto D para todos, exceto fêmeas velhas

Condição alternativesProcess1

2

3

4

5

6

7

8

9

10

11

12

Sexo

F

M

F

M

F

M

F

M

F

M

F

M

Cidade

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Idade

X

X

X

X

Y

Y

Y

Y

Z

Z

Z

Z

Ação EntriesMarketing Produto1

2

3

4

5

6

7

8

9

10

11

12

Produto A

X

-

-

-

X

-

-

-

X

-

-

-

Produto B

X

-

X

-

-

-

-

-

-

-

-

-

Produto C

-

-

-

-

-

-

-

X

-

-

-

-

Produto D

X

X

X

X

X

X

X

X

-

X

-

X

Aqui, a tabela pode ser ainda mais simplificada. Como? Se você observar a tabela, as regras da coluna 2, 4, 6, 7, 10 e 12 têm os itens de ação mesmos. Da mesma forma, as regras de 2, 6 e 10 satisfazer duas das três entradas condição de gênero e morador da cidade. Regras para 4 e 12, embora tenham padrão de ação mesmo não podem ser mescladas devido aos critérios de idade diferentes. E, por último, faixa etária Y não é coberto. Então, a tabela de decisão modificada é a seguinte:

Condição alternativesProcess1

2

3

4

5

6

7

8

9

10

Sexo

F

M

F

M

F

F

M

F

F

M

Cidade

Y

Y

N

N

Y

N

N

Y

N

N

Idade

X

-

X

-

X

Y

Y

Y

Z

Z

Ação EntriesMarketing Produto1

2

3

4

5

6

7

8

9

10

Produto A

-

X

-

-

X

-

-

X

-

-

Produto B

X

-

X

-

-

-

-

-

-

-

Produto C

-

-

-

-

-

-

X

-

-

-

Produto D

X

X

X

X

X

X

X

-

-

X

Particionamento de Equivalência

Particionamento de equivalência é ainda outro método de teste da caixa preta destinada a reduzir o número total de casos de teste para o teste de software, dividindo os dados de entrada em partições. Este método é útil para determinar as entradas válidas e inválidas para testes de aplicação. Além disso, os casos de teste são preparadas em cada partição, para garantir que a aplicação processa os dados de entrada correcta quando uma entrada válida é inserida e contrário, gera uma mensagem de erro. Com base nas informações, onde os resultados são idênticos, os casos de teste são agrupados como uma classe de equivalência. Deixe-me explicar com um exemplo de caixa preta de testes para esta técnica: Há uma companhia aérea particular que oferece diferentes privilégios para os membros de várias, com base no número de voos aproveitado por um cliente do ar regular.

Número de FlightsMembership5-10

Prata

11-15

Ouro

16-20

Platina

21-40

Diamante

Assim, a partir dos dados acima, pode-se inferir que as condições estabelecidas para aplicar número de voos que variam entre 5-40. Qualquer número que é inferior a 5 ou mais do que 40 é uma entrada inválida para o programa. Então, aqui, os rendimentos de particionamento de equivalência 7 partições que incluem os acima mencionados quatro casos de teste válidos e 3 casos de teste que são mais inclusiva das entradas inválidas como, 40 e não valores numéricos. A razão pela qual as entradas são também considerados inválidos é calcular a cobertura de teste absoluta da aplicação a ser testada.

Análise de Valor Limite

Como o nome sugere, este método visa definir e reverificação dos limites definidos no método de particionamento de equivalência. Aqui, os casos de teste são projetados especialmente para incluir os valores limites para localizar erros no software de aplicação. Então o primeiro passo é identificar as entradas e as saídas possíveis, válidos e inválidos. Tem sido observado que a maioria dos erros detectados durante testes de caixa preta ocorrem nos limites do domínio de entrada. Por exemplo, vamos ter um olhar para o exemplo abaixo, onde o teste de caixa preta está sendo feito por uma caixa de entrada que aceita números entre 1-1000. Os casos de teste possíveis com variações nos limites incluem:

* Caso de teste com dados de teste 1 - 1000 (ambos os valores limite de entrada, inclusive)

* Caso de teste com dados de teste 0 - 999 (a partir de um a menos que os limites extremos)

* Caso de teste com dados de teste 2-1001 (começando a partir de um maior do que os limites extremos)

Testando o aplicativo com a combinação acima dos dados de teste é também uma parte de testes de estresse negativo ou que irá ajudar a avaliar o positivo eo negativo de cobertura de teste com precisão.

Graphing Causa e Efeito

Causa e Efeito Graphing como o método sugere, é sobre a identificação de uma causa e, em seguida, antecipando o efeito, convertendo o processo de leigo para um algoritmo de software baseado listando primeiro as causas e os efeitos, em seguida, gráficos los, convertendo o gráfico de uma tabela de decisão e em seguida, finalmente, nos casos de teste. Portanto, este método ajuda a identificar as entradas corretas para o método de particionamento de equivalência. Agora, siga os passos abaixo para causa e efeito gráfico e convertê-lo em uma tabela de decisão, como mencionado acima.

* Identificar os requisitos da aplicação e quebrá-las em subconjuntos de funcionalidades pequenos.

* Identificar a causa eo efeito para o conjunto de requisitos.

* Agora, crie uma relação lógica entre os subconjuntos de requisitos.

* Derive combinações possíveis e impossíveis de causa e efeito, duo e elaborar gráficos.

* Converta o gráfico em uma tabela de decisão, com a coluna significando o caso de teste e linha como a causa / efeito.

* Agora, as colunas podem ser convertidas em casos de teste que têm um conjunto definido de entradas válidas e inválidas, o que ajuda na determinação da cobertura do teste.

Diagrama de Transição de Estado

Para entender o comportamento de um aplicativo do sistema, diagramas de transição de estado são necessárias. Este método representa graficamente uma série de eventos que ocorrem em diferentes estados / condições. Usando esta técnica de teste caixa preta, um começa a compreender o projeto do sistema interno e requisitos. Se você tem uma compreensão clara de fluxogramas, um diagrama de transição de estado seria uma moleza para você. Este diagrama é composto por quatro estados:

* O estado atual

* Evento

* Ação

* O estado seguinte

Eventos que acontecem no estado atual sempre ter duas possibilidades, sim ou não. Então, com base nisso, as ações também são diferentes e, dependendo dessas ações, o próximo estado é identificado. Depois de representar graficamente o diagrama, pode-se facilmente criar uma tabela de transição de estado que ajuda a desenterrar algumas combinações não detectados, que podem não ter sido identificados ou documentado em outras técnicas como listado acima. Então, quando a criação de casos de teste, deve-se assegurar que todos os eventos do aplicativo são disparados pelo menos uma vez, e os caminhos que ligam os eventos e as ações são pisar pelo menos uma vez. Se existem laços internos criados na concepção de um diagrama de transição de estado, há uma possibilidade de bloqueios, perdas de memória, etc, que precisam ser trabalhadas. Este método é mais recomendado para aplicações em tempo real. Por exemplo, tomar um exemplo simples de encher uma garrafa.

* Você tem um frasco vazio que precisa ser preenchido. Este é um evento, que imediatamente pede ação de encher a garrafa.

* Agora a garrafa está a ser verificado, para saber se é ou não cheia. Se estiver cheia, a próxima ação é para selá-lo. Se ele não está cheio, o evento é redirecionado para enchê-lo primeiro.

* Uma vez que o frasco é cheio com água. Ele precisa ser verificado se há vazamentos. Se houver um vazamento, então ele está quebrado e é redirecionado para o primeiro evento do vazio.

* Caso contrário, a ação de selar a garrafa aparece como a última etapa.

Este foi um exemplo simples que ilustra o comportamento de um sistema. Para entender melhor este conceito, tem que ser bem versado com o tema da UML (Unified Modeling Language).

Caixa branco versus teste de caixa preta

Agora que sabemos algumas das técnicas de teste caixa preta, vamos entender a diferença entre o teste de caixa branca e testes de caixa-preta. Bem, ao contrário de teste de caixa preta, onde o testador não precisa ter um conhecimento sobre o funcionamento do código implementado na aplicação, para o teste de caixa branca, é uma obrigação. Especialmente, quando a interface gráfica do usuário continua a mudar durante fusões de código e implantações na fase de testes de software, o testador precisa introspect as mudanças que estão sendo feitas de vez em quando. Além disso, se um está seguindo o método de diagrama de transição de estado para testes de caixa-preta, então o teste de caixa branca vai ajudar a avaliar a reutilização dos casos de teste gerados e também vai ajudar a verificar se todos os caminhos que liga as ações e os eventos foram atravessados ​​pelo menos uma vez. Mas, tanto quanto o teste de software está em causa, estas duas técnicas de teste são muito importantes para verificar não apenas a funcionalidade geral da aplicação, mas também a qualidade do código e aplicação.

Espero que este artigo foi informativo em testes caixa preta. Teste de software é uma parte integrante do ciclo de vida de desenvolvimento. Sem a parte de teste, um aplicativo permanece incompleta. Existem muitas ferramentas de teste, disponível na internet, tanto para testes de caixa preta e teste de caixa branca, que ajudam na geração de casos de teste para suas aplicações. Mas certifique-se de que você compreende as técnicas de teste caixa preta bem, antes de implementá-los em sua aplicação. Boa sorte!...