Quais cenários de teste são necessários e suficientes para testar a caixa preta exaustiva um modelo de nomeação recorrente?

Question

Eu tenho um modelo de Django para uma consulta em um calendário para o qual estou tentando escrever um driver de teste muito abrangente. A nomeação recorrente ocorre em algum momento e pode ser executada infinitamente ou se repetir por um número fixo de vezes. A nomeação reflete a funcionalidade disponível para uma consulta do Google Calendar (pode repetir mensalmente/anualmente/semanalmente, a cada duas semanas, a cada 3 anos.)

Estou tentando fazer um teste de unidade que testará exaustivamente o básico desta implementação. Estou procurando os casos de borda que definirão os testes mais básicos.

Eu tenho muitos básicos, mas estou procurando sugestões para ajudar a identificar os casos mais importantes: 1) Crie uma única nomeação 2) Crie uma consulta que recorre semanalmente 3) ... Relama mensalmente 4) Recorre a cada 2 semanas 5) Recorre a cada 2 meses 6) Recorre anualmente

Answer 1

Teste com os últimos dias de meses, anos bissextos e se ficará louco quando o ano tiver um segundo extra (este atingiu um motorista no Zune Player).

Teste, ele se comporta bem ao atravessar anos.

Dito isto, considere se você está testando novamente algo que faz parte da estrutura. A lógica da data de teste pode ficar feia muito rápido, então você deseja desenhar uma linha sobre o que faz parte do seu aplicativo e o que faz parte da estrutura.

Answer 2

Não se esqueça de testar a recorrência anual para 29 de fevereiro em um ano bissexto;)

Answer 3

Antes de começar a sair dos cenários, você realmente precisa encontrar um plano de teste com base na compreensão dos requisitos.

Considere sua base de usuários e quaisquer outras bases de usuários possíveis/futuras (como uma prioridade mais baixa). Para que eles o usarão principalmente e quanto esses casos de uso valem a eles em seus negócios?

Idealmente, crie um modelo do aplicativo e comece a partir daí.

Crie uma análise de risco do que você planeja fazer. Em seguida, planeje fazer testes funcionais, de segurança, localização, etc.

Então você pode começar a pensar em cenários com base em como eles são "arriscados" (a partir da análise de risco). Concentre -se em escrever e executar os "mais arriscados" primeiro.

Obtenha a entrada dos negócios (Signoff, se possível) em sua análise de risco e como pretende usá -lo.

Apenas jogar cenários aleatórios por aí não é uma boa prática de teste e merece todo o ridículo que você pode obter dos desenvolvedores. Os testes devem ser um exercício planejado mais projetado. Eles podem contratar qualquer pessoa fora da rua para executar cenários que chegam ao topo de sua cabeça.

Dito isto, concordo que os cenários mencionados anteriormente são testados e verdadeiros. Boas idéias. Também jogue em testes de poupança do dia. Use diferentes clientes de email. Tente publicar uma data gratuita/ocupada. Faça com que os desenvolvedores expliquem como estão publicando essas informações. É através de um serviço da web? Eles esperam que apenas trocar usuários usem isso? Alguém em diferentes países onde as datas são formatadas de maneira diferente? Você pode encontrar fraquezas e encontrar mais bugs.

Testes felizes.