Como você testar programas que requerem dados de entrada complexos?

Question

Nós temos um conjunto de conversores que levam dados complexos e transformá-lo. Principalmente a entrada é EDI eo XML de saída, ou vice-versa, embora existam outros formatos.

Existem muitas interdependências nos dados. O métodos ou software estão disponíveis que podem gerar dados de entrada complexos como este?

Agora usamos dois métodos: (1) um conjunto de arquivos de amostra que temos construído ao longo dos anos principalmente a partir de arquivos de bugs e amostras na documentação, e (2) dados de teste geradores pseudo-aleatórios. Mas o ex-cobre apenas uma fração dos casos, e este último tem muitos compromissos e só testa um subconjunto dos campos.

Antes de ir mais longe no caminho da execução (reinventar?) Um gerador de dados orientado a tabela complexa, que opções têm você encontrou sucesso?

Answer 1

Bem, a resposta está na sua pergunta. A menos que você implementar um gerador de dados orientado a tabela complexa, você está fazendo as coisas certas com (1) e (2).

(1) abrange a regra de "um erro verificado, 1 novo caso de teste". E se a estrutura dos dados de teste pseudo-aleatórios de (2) corresponde qualquer em situações da vida real, é bom.

(2) pode sempre ser melhorado, e ele vai melhorar, principalmente, ao longo do tempo, quando se pensa em novos casos de ponta. O problema com dados aleatórios para testes é que ele só pode ser aleatória a um ponto em que se torna tão difícil de calcular o resultado esperado a partir dos dados aleatórios no caso de teste, que você tem que reescrever basicamente o algoritmo testado no caso de teste.

Assim, (2) será sempre corresponder a uma fração dos casos. Se um dia ele combina todos os casos, será, de facto, uma nova versão do seu algoritmo.

Answer 2

1. Eu aconselho contra o uso de dados aleatórios, uma vez que pode tornar difícil se não impossível de reproduzir o erro que informou (eu sei que você disse 'pseudo-aleatório', só não tenho certeza que você entende por que exatamente) .

2. Operando em arquivos inteiros de dados provavelmente seria considerando testes funcionais ou de integração. Eu gostaria de sugerir que o seu conjunto de arquivos com bugs conhecidos e traduzi-las em testes de unidade, ou pelo menos fazê-lo para futuras erros que você encontrar. Então você também pode estender esses testes de unidade para incluir a cobertura para as outras condições errôneas que você não tem qualquer tipo de 'dados de exemplo'. Este provavelmente será mais fácil, em seguida, chegando com um arquivo de dados totalmente novo cada vez que você pensar em uma violação condição / regra que deseja verificar.

3. Verifique se o seu análise do formato de dados é encapsulado a partir da interpretação dos dados no formato. Isso fará com que o teste de unidade como descrito acima muito mais fácil.

4. Se você definitivamente precisa para conduzir seu teste você pode querer considerar a obtenção de uma máquina descrição legível do formato de arquivo, e escrevendo um gerador de dados de teste que vai analisar o formato e gerar arquivos válidos / inválidos com base nela. Isso também irá permitir que seus dados de teste para evoluir como os formatos de arquivo fazer tão bem.