¿Cómo puede el personal de control de calidad probar la lógica de almacenamiento en caché que no pueden ver?

Acabo de implementar una capa de almacenamiento en caché en mi aplicación web, y ahora me pregunto cómo se supone que QA debe probarla, ya que el almacenamiento en caché es transparente para el usuario.

Una idea que tengo es poner el registro en los métodos que invocan el código que llena el caché, y registrar cuando un objeto se extrae del caché y cuando requiere recreación de la base de datos, y luego los evaluadores podrían ver los registros para ver si, por ejemplo, un objeto determinado se vuelve a cargar desde la base de datos cada 10 minutos, en lugar de cada vista de página.

Pero, ¿alguien puede sugerir algunas mejores prácticas para esta situación?

Una pregunta es si la memoria caché en sí misma es realmente un requisito que QA debería probar. El almacenamiento en caché mejora el rendimiento, por lo que podrían probar la diferencia en el rendimiento para garantizar que cumpla con algunos requisitos.

Pero es una buena idea tener algunas pruebas sobre el almacenamiento en caché, quien sea responsable de ello. Utilizamos contadores de rendimiento. Si su sistema de caché se aprovecha de estos, son sencillos. Si hay alguna forma de obtener un recuento de la memoria caché en sí, esa es otra opción.

Usar tu enfoque también es bueno. Si alguno de estos está envuelto en pruebas automatizadas que verifican los resultados, entonces nadie tiene que revisar los registros para encontrar respuestas.

Implementó un caché (supongo) porque el sistema no estaba funcionando lo suficientemente bien. Eso es algo relevante para el usuario. Aquí hay cosas que QA puede verificar:

• Que el sistema, después de que se introdujo el caché, sigue siendo correcto. Esto significa que deberían intentar engañar al caché para que proporcione datos obsoletos, que es algo que el control de calidad puede verificar, y asegurarse de que nada más esté roto.
• Que el sistema ahora cumple con los umbrales de rendimiento que no estaba cumpliendo cuando decidió mejorar el rendimiento. Pueden comparar las medidas antiguas y compararlas con las nuevas.

Recuerde, a los usuarios (y, por extensión, QA) no les importa cómo resolvió un problema. Solo les importa que el problema se haya resuelto y no haya creado nuevos problemas. Esto es cierto si implementó el almacenamiento en caché, mejoró el análisis de cadenas, realizó una actualización de hardware o roció polvo mágico de hadas en el servidor.

Enterrar la lógica comercial importante o el estado del sistema en una caja negra dificulta la verificación del comportamiento correcto del sistema. Es más fácil probar exhaustivamente el comportamiento de un solo componente en el sistema que el sistema completo. Estoy a favor de exponer tales cosas explícitamente a través de algún mecanismo para que se pueda probar la unidad / regresión / integración / QA de alguna manera significativa.

Una opción con un caché sería exponer una página especial que brinde algunos detalles sobre el caché (contenido, estado, etc.). Esto puede ayudar con la depuración en el desarrollo y potencialmente en la producción. El control de calidad también puede usar esta página para crear casos de prueba para la memoria caché si se les dan detalles sobre cuál es el comportamiento esperado de la memoria caché. El uso de contadores de rendimiento y / o archivos de registro para documentar explícitamente el comportamiento de la memoria caché es otro enfoque menos visible pero viable.

Tenga en cuenta que este enfoque no es un sustituto de las pruebas de rendimiento de extremo a extremo. Este es un mecanismo para garantizar que el caché se comporte correctamente. Las pruebas de rendimiento deben usarse para determinar si el almacenamiento en caché tiene el efecto deseado sobre el rendimiento.

También tenga en cuenta que intercambiar componentes del sistema por otros nuevos que implementen la misma interfaz, como la introducción de un caché, puede ser un cambio desestabilizador y engañosamente complejo. Con el ejemplo de caché, está introduciendo un estado en lo que anteriormente no tenía estado, lo que puede crear errores que son más difíciles de encontrar o reproducir. Tal cambio siempre debe ir acompañado de pruebas de regresión completas para verificar el comportamiento esperado del sistema.

Pruebe el rendimiento, como se indica en la respuesta de Andy.

Descubrí que el mayor obstáculo para implementar el almacenamiento en caché (y el rendimiento) en muchas organizaciones es tener un entorno en el que se puedan realizar buenas pruebas de rendimiento y ejecutar pruebas para varias pruebas de carga y rendimiento del mundo real.

Para tener esto, debe configurar un entorno de prueba de rendimiento que, lo más cerca posible, y que tenga en cuenta los costos, refleje la producción. Este probablemente NO será su entorno de desarrollo actual, que debería ser más pequeño y más autónomo para permitir el desarrollo rápido de aplicaciones. Los entornos de desarrollo también tienden a usar menos almacenamiento en caché y, por lo tanto, no representan bien la producción para las pruebas de rendimiento.

En el entorno de pruebas de rendimiento, la aplicación debería ejecutarse en 'modo' de producción. Debería tener más de un servidor si la producción lo hace, el grupo de conexión de la base de datos y el almacenamiento en caché deben configurarse para un entorno de producción, etc.

También querrás considerar una herramienta para ayudar con las pruebas de carga.
jmeter es muy popular, aunque me parece bastante hostil y primitivo de usar.
Otra ruta que he usado es simplemente url curl's con un script ruby.

Para ser claro

• la prueba de rendimiento de la línea base es para probar el tiempo que hace UNA solicitud.
• la prueba de carga es similar a la prueba de rendimiento, pero analiza la respuesta cuando el sistema también está bajo carga por otras solicitudes.

También puede encontrar útiles los siguientes enlaces:

• ¿Mejores prácticas para los métodos de prueba de unidad que usan mucho el caché?
• Metodología de prueba de carga para un caché
• ¿Hay alguna forma de probar cómo funcionará el sitio bajo carga?
• http://www.procata.com/cachetest/

Recuerde hacer que los evaluadores reinicien los servidores y verifiquen que los datos que han ingresado todavía están allí. Vi un sistema que tenía muchos meses de pruebas, ¡falló cuando se hizo eso!

La parte más difícil de probar es que, sin embargo, los datos se actualizan, nunca hay resultados desactualizados devueltos desde el caché.

Esto puede ser ayudado en parte usando siempre los datos en la memoria caché para llenar la página de confirmación que ve un usuario después de haber realizado un cambio. Por ejemplo, no use el objeto que usó para actualizar la base de datos, sino que solicite los datos del caché, que luego lo solicite de la base de datos. Un poco más lento, pero es mucho más probable que muestre errores más rápido.

Esta en realidad tiene una respuesta muy directa y está relacionada con el nivel de almacenamiento en caché. Lo que observará cuando el almacenamiento en caché sea correcto es la ausencia de solicitudes en el destino de las solicitudes. Por lo tanto, se trata de la frase de control de calidad de "resultados esperados".

Si implementa una memoria caché en el nivel web, entonces esperaría que los elementos sujetos a la memoria caché solo se muestren una vez para cada sesión de usuario probada (si implementa la memoria caché del cliente) o una vez para varios usuarios (si implementa una memoria caché de estilo CDN). Si está implementando un caché en el nivel de datos para obtener resultados comunes, entonces esperaría ver una alta proporción de aciertos de caché en su nivel de almacenamiento en caché junto con la ausencia de consultas en el registro de perfil para el nivel de datos.

etc ...

Algunas cosas son mejor probadas por un programador, quizás el que escribió el código, usando pruebas unitarias. Probar la exactitud de su código de almacenamiento en caché es una de esas cosas. (Por la forma en que hace esta pregunta, supongo que su personal de control de calidad trata la aplicación como un "recuadro negro" y la prueba a través de su interfaz externa).

La lógica de almacenamiento en caché es algo que el desarrollador debe probar unitariamente, ya que el control de calidad principalmente realiza pruebas de caja negra.

QA solo se preocuparía por los aspectos de rendimiento o cualquier solución que haya implementado, por lo tanto, puede proporcionar a QA un mecanismo para habilitar / deshabilitar el almacenamiento en caché o cualquier mecanismo que haya utilizado para mejorar el rendimiento, y luego pueden verificar la diferencia de rendimiento. Por supuesto, el control de calidad también podría verificar una versión anterior en comparación con su versión mejorada de rendimiento.

Cuando estaba probando la solución de almacenamiento en caché que implementamos, lo que probamos básicamente fue el rendimiento. Hemos hecho esa solución de almacenamiento en caché para resultados XML y después de la memoria caché, tarda muy poco tiempo en dar la respuesta. También lo hemos verificado con el registro del servidor comprobando las entradas del registro.