¿Qué escenarios de prueba son necesarios y suficientes para probar exhaustivamente la caja negra en un modelo de cita recurrente?

Question

Tengo un modelo django para una cita en un calendario para el que estoy intentando escribir un controlador de prueba muy completo. La cita recurrente ocurre en algún momento en el tiempo y puede ejecutarse en forma infinita o recurrir por un número fijo de veces. La cita refleja la funcionalidad disponible para una cita de Google Calendar (puede repetirse mensualmente / anualmente / semanalmente, cada dos semanas, cada 3 años).

Estoy tratando de encontrar una prueba unitaria que pruebe exhaustivamente los conceptos básicos de esta implementación. Estoy buscando los casos de borde que definirán las pruebas más básicas.

Tengo muchos básicos, pero estoy buscando sugerencias para ayudar a identificar los casos más importantes: 1) Crear una sola cita. 2) Crear una cita que se repita semanalmente. 3) ... se repite mensualmente 4) se repite cada 2 semanas 5) se repite cada 2 meses 6) se repite anualmente

Answer 1

Prueba con los últimos días de meses, años bisiestos y si se volverá loco cuando el año tenga un segundo extra (este golpeó a un conductor en el reproductor zune).

Prueba que se comporta bien al cruzar años.

Dicho esto, considera si estás volviendo a probar algo que forma parte del marco. La lógica de la fecha de prueba puede volverse realmente fea, por lo que debe dibujar una línea sobre lo que forma parte de su aplicación y lo que forma parte del marco.

Answer 2

No se olvide de probar la recurrencia anual para el 29 de febrero en un año bisiesto;)

Answer 3

Antes de comenzar a hablar de escenarios, realmente necesita elaborar un plan de prueba basado en su comprensión de los Requisitos.

Considere su base de usuarios y cualquier otra base de usuarios posible / futura (como una prioridad más baja). ¿Para qué la usarán principalmente y cuánto valen esos casos de uso para ellos en su negocio?

Lo ideal es crear un modelo de la aplicación y comenzar desde allí.

Cree un análisis de riesgo de lo que planea hacer. Luego planee realizar pruebas funcionales, de seguridad, localización, etc.

Luego, puedes comenzar a pensar en los escenarios en función de la forma " riesgosa " son (a partir del análisis de riesgo). Concéntrese en escribir y ejecutar el " más riesgoso " los primeros

Obtenga información comercial (firme si es posible) sobre su análisis de riesgo y cómo pretende utilizarlo.

Simplemente lanzar escenarios aleatorios no es una buena práctica de prueba y merece todo el ridículo que los desarrolladores pueden obtener. Las pruebas deben ser un ejercicio planificado más diseñado. Pueden contratar a cualquier persona que salga de la calle para ejecutar escenarios que lleguen a lo más alto de su cabeza.

Dicho esto, estoy de acuerdo en que los escenarios mencionados anteriormente se han probado y son verdaderos. Buenas ideas. También tirar en las pruebas de ahorro de luz diurna. Utilice diferentes clientes de correo electrónico. Trate de publicar la fecha libre / ocupado. Haga que los desarrolladores expliquen cómo están publicando esta información. ¿Es a través de un servicio web? ¿Esperan que solo los usuarios de Exchange usen esto? ¿Alguien en diferentes países donde las fechas tienen un formato diferente? Luego puedes encontrar puntos débiles y encontrar más errores.

Pruebas felices.