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

33

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?

Joshua Frank
fuente
66
relacionado: Metodología de prueba de carga
mosquito
55
Trabajo en rendimiento todo el día y "¿cómo puede QA probar su cambio?" es una pregunta que me hacen constantemente.
Brandon
1
Bueno, generalmente una memoria caché está destinada a acelerar una operación almacenando resultados en la memoria que de otro modo provendría de otra fuente (db, servidor remoto, método computacionalmente costoso, etc.). Por lo tanto, medir el tiempo que se supone que deben tomar las cosas al golpear el caché parece ser la forma más simple. Compruebe también si hay problemas de caché obsoletos (las actualizaciones de los datos reales no aparecen porque la versión anterior todavía está en caché)
GordonM

Respuestas:

37

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.

Andy Wiesendanger
fuente
+1 para probar el rendimiento en lugar del almacenamiento en caché. ¿Qué valor comercial está almacenando en caché por sí solo? (Ninguno.) Seguramente está trabajando para lograr un impacto notable en algo, ¿por qué más pasaría el tiempo implementando? Prueba de ese impacto.
alexanderbird
74

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.

durron597
fuente
1
Afirmar que a QA no le importa cómo resuelve el problema es una visión muy simplista de lo que le interesa a QA. Les importa si realmente mejoró el rendimiento, si introdujo deuda técnica adicional, riesgo o defectos, etc.
Eric
44
@Eric En el desarrollo de software, "QA" como grupo generalmente no se refiere a desarrolladores / ingenieros. La deuda técnica es una preocupación del desarrollador / ingeniero (y una preocupación de la administración ya que puede afectar los plazos, los costos, etc.). Lo mismo se aplica al riesgo. El trabajo de QA es asegurarse de que el software cumpla con los requisitos (y posiblemente incidentalmente ayudar en el proceso de eliminar requisitos que no estaban claros). Si les importa la implementación, solo debe ser como un medio para descubrir formas creativas de romper el sistema.
jpmc26
3
@ Eric No estoy confundiendo nada. "QA" se refiere a probadores en software. Está interpretando el término de manera tan amplia que debería incluir a toda la compañía que desarrolla la pieza de software e incluso al cliente si es un sistema creado a medida para ellos, ya que todos tienen una mano en la calidad.
jpmc26
1
@Eric Por favor, no me hagas discutir cómo el lenguaje y la semántica funcionan contigo. Te desafío a que encuentres 5 instancias en este StackExchange donde el término se use de esa manera en menos de 30 minutos. Además, incluso según esa definición, lo mejor que puede hacer un grupo de control de calidad separado para abordar problemas más allá del producto en sí es imponer políticas a los desarrolladores, y cuando las políticas y los procesos se elevan por encima de la fabricación de buenos productos, generalmente terminan con malos productos. Además, puedo asegurarle que las personas de "QA" con las que trabajo definitivamente son evaluadores y tienen poco que decir sobre mi proceso de desarrollo.
jpmc26
44
@Eric: no hay nada que detenga a una empresa o grupo de personas que definen "QA" como una visión más holística. Sin embargo, en mi experiencia (a través de 5 empresas muy diferentes) la etapa de control de calidad como se llamaba - y los que se especializan en ella - en el desarrollo de software por lo general se centra en las pruebas de recuadro negro del comportamiento del sistema. Si bien también podemos tener "Control de calidad", "Kwalitee" y más nombres inventados para cubrir ángulos especializados en temas de calidad más amplios.
Neil Slater
3

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.

Eric
fuente
3

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:

Michael Durrant
fuente
2

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.

Ian
fuente
1

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 ...

James Pulley
fuente
0

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).

Alex D
fuente
0

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.

Fred Thomsen
fuente
-4

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.

user204667
fuente
3
No estoy seguro de entender lo que está diciendo, o lo que dice su respuesta que no está en las siete respuestas anteriores.