ware, ou parte dele, e comparar se o resultado obtido (saída obtida) é diferente do resultado esperado (saída esperada).
De uma forma geral é impossível, através do Teste de Software, afirmar que um Sistema seja 100% livre de erros. Para tanto, seria necessário que um Sistema fosse testado com todos os possíveis dados de entrada.
Como a quantidade de dados de entrada costuma ser muito grande para que todos sejam utilizados durante os testes, torna-se impraticável realizar um conjunto de testes que prove a inexistência de erros em um software.
Mas se o Teste de Software não garante que um Sistema jamais apresentará resultados impróprios, seu objetivo não é provar que seja 100% livre de erros e, sim, encontrar erros. Erro é a diferença entre o valor esperado e o valor obtido.
Um teste bem sucedido é aquele que encontra um erro. Se o profissional realizar um conjunto de testes e não encontrar um erro, o teste não foi bem sucedido.
Uma questão importante é: se o Teste de Software não prova que um software é livre de erros, como proceder com os testes? O que deve ser focado? Como saber que o software foi suficientemente testado para que, pelo menos, seja considerado confiável, isto é, com baixa probabilidade de apresentar erros?
Se considerar todos os possíveis dados de entrada de um Software como um conjunto, chamado Domínio de Entrada (representado pela Figura 1), poder-se-ia tentar dividir este conjunto de forma que cada subconjunto representasse um grupo de dados de entrada para o teste. O ideal seria que cada representante de um subconjunto possuísse a mesma relevância para o teste, isto é, se um representante de um subconjunto detectasse um erro no software, todos os demais representantes deste mesmo subconjunto deveriam encontrar este mesmo erro. Assim, em vez do usuário de teste precisar usar todos os dados de entrada, bastaria que escolhesse apenas um representante de cada subconjunto (em vermelho, na Figura 2).
