Deja tu comentario

El contenido de este campo se mantiene privado y no se mostrará públicamente.

HTML Restringido

  • Etiquetas HTML permitidas: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Saltos automáticos de líneas y de párrafos.
  • Las direcciones de correos electrónicos y páginas web se convierten en enlaces automáticamente.

Posts relacionados

Artefacto Maven - SDOS
Cómo crear desplegar un artefacto con Maven
QA en metodologías ágiles
¿Qué papel tiene QA en las metodologías ágiles?
Comentarios
Victor
30 Jul 2018

Muy didáctico. Normalmente, la gente confunde pruebas de carga con pruebas de estrés, y no terminan de ver claro la diferencia de concepto con respecto a unas pruebas funcionales, por la dificultad añadida de la concurrencia, entre otras cosas. Quien vaya a hacer unas pruebas de rendimiento, tiene que tener claro que no son pruebas funcionales, pero a su vez conviene disponer de un conocimiento funcional profundo y la necesidad de disponer de un juego válido de datos que permita repetir una secuencia de ejecuciones representativa sin necesidad de validar el rendimiento de todas las funcionalidades. Disponer de este conocimiento funcional, tambien ayuda a identificar errores funcionales en la generación de los scripts de carga y en la ejecución de las pruebas.
Por mi experiencia realizando pruebas de rendimiento, también diría que es conveniente planificarse desde la ejecución del caso más sencillo probando directamente el componente en el que se intuya que pueda haber un cuello de botella, y extender las pruebas al resto del sistema según se certifica el rendimiento de componentes más sencillos.
También es muy importante poder probar en un entorno estable o aislado en el que no interfieran ciclos de pruebas y desarrollos correctivos o evolutivos, o cualquier otra actualización de datos o configuraciones parametricas, ya que esto desconcierta a los técnicos ante la aparición de errores y puede suponer pérdidas de días enteros hasta que se detecta el origen del error.
Finalmete, comentar que, si bien el caso ideal las pruebas se deberían hacer en entornos productivos, en la práctica real esto resulta prácticamente imposible. La siguiente aproximación, que sería probar en un entorno preproductivo y escalar a un entorno de producción, también será raramente practicable si no es que se ha planteado un sistema escalable desde el principio. Aquí, lo que nos encontraremos en la mayoría de ocasiones son sistemas preexistentes en los que no podremos probar en entornos productivos, y en los que no será posible obtener un ratio de mejora sobre las pruebas que hagamos en entornos o reproductivos. Lo que podemos hacer en estas situaciones es aprovechar las pruebas en entornos reproductivos para identificar cuellos de botella que seguramente se reproducirán en entornos productivos, y tratar de implicar al propietario de la aplicación para conseguir hacer algún tipo de prueba representativa en los entornos de producción, que podría ir de una monitorizacion y análisis de la carga habitual, hasta una ejecución de pruebas con una carga medida en horarios de poca afluencia para evitar posibles daños colaterales.