Que cenários de teste são necessárias e suficientes para exaustivamente caixa preta testar um modelo de compromisso recorrente?

votos
3

Eu tenho um modelo django para um compromisso em um calendário que estou tentando escrever um piloto de testes muito abrangente para. O compromisso recorrente ocorre em algum ponto no tempo e pode ser executado em infinitamente ou recorrer para um número fixo de vezes. A nomeação espelha a funcionalidade disponível para um compromisso de calendário do Google (pode recorrer mensal / anual / semanais, a cada duas semanas, a cada 3 anos.)

Eu estou tentando chegar a um teste de unidade que será exaustivamente testar os fundamentos desta implementação. Eu estou olhando para os casos de ponta que irão definir os testes mais básicos.

Eu tenho um monte dos básicos, mas estou procurando sugestões para ajudar a identificar os casos mais importantes: 1) Criar um único compromisso 2) Crie um compromisso que se repete semanalmente 3) ... se repete mensalmente 4) repete a cada 2 semanas 5) repete a cada 2 meses 6) repete anualmente

Publicado 05/03/2009 em 23:11
fonte usuário
Em outras línguas...                            


3 respostas

votos
3

Teste com últimos dias de meses, anos bissextos, e se ele vai ficar louco quando o ano tem um segundo extra (este atingiu um motorista no player Zune).

Testá-lo se comporta bem ao cruzar anos.

Dito isto, considere se você estiver re-testar algo que faz parte do quadro. Testes lógica data pode ficar feia muito rápido, assim que você quer desenhar uma linha sobre o que é parte da sua aplicação e que faz parte do quadro.

Respondeu 05/03/2009 em 23:22
fonte usuário

votos
1

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

Respondeu 05/03/2009 em 23:16
fonte usuário

votos
0

Antes de começar despejando cenários, você realmente precisa para chegar a um plano de teste com base no seu entendimento dos requisitos.

Considere a sua base de usuários e quaisquer outras bases de usuários possíveis / futuras (como uma prioridade mais baixa). O que eles vão ser maioritariamente usando para isso e quanto são os casos de uso vale a pena para eles em seu negócio?

Idealmente, criar um modelo do aplicativo e começar a partir daí.

Come-se com a Análise de Risco do que você planeja fazer. Em seguida, pretendo fazer funcional, segurança, testes de localização, etc.

Então você pode começar a pensar em cenários com base em como "arriscado" eles são (a partir da Análise de Risco). Se concentrar em escrever e executar os "mais arriscados" em primeiro lugar.

Obter entrada de Negócios (signoff se possível) em sua análise de risco e como a intenção de usá-lo.

Apenas jogando cenários aleatórios lá fora, não é uma boa prática de teste e merece todo o ridículo que você pode começar a partir de desenvolvedores. O teste deve ser uma mais engenharia exercício, planejado. Eles podem contratar ninguém na rua para executar cenários que vêm para o topo da sua cabeça.

Dito isto, concordo que os cenários mencionados anteriormente são testadas e verdadeiras. Boas idéias. Também jogar em testes Daylight Savings. Use diferentes clientes de e-mail. Tente publicar data livre / ocupado. Obter os desenvolvedores para explicar como eles estão publicando esta informação. É através de um serviço web? Será que eles esperam que apenas os usuários do Exchange para usar esta? Qualquer pessoa em diferentes países onde as datas estão formatadas de maneira diferente? Você pode, então, encontrar pontos fracos e encontrar mais bugs.

Teste feliz.

Respondeu 06/03/2009 em 19:03
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more